Dotaz: Frag reassembly time exceeded

[Taras]

Ahoj,

na novem 5GHz spoji pozoruji pri pingu nasledujici hlasku, se kterou jsem se nikdy nesetkal

From 192.168.10.1 icmp_seq=3292 Frag reassembly time exceeded

doposavad jsem si hral jen s wifi tj. 2,4 GHz a na zadnem spoji se toto neprojevilo. Je mozny ze to souvisi s nastavenim ACK u 5GHz??? a nebo je "zakopanej pes" zcela jinde?

za pripadne objasneni teto hlasky dekuji..

Odpovědi

[Michal Kubeček]

Jak velké ty pakety posíláte?

[Taras]

Sorry, to zasadni jsem tam nenapsal.. Samozrejme, ze se to projevuje az u vetsich paketu a to kolem 2048B a vice. "Obycejny" ping projde v zasade bez problemu... packet loss < 1%. U paketu kolem 2kB je packet loss uz nekde kolem 15%

[Michal Kubeček]

A proč se snažíte posílat ICMP echo delší než je vaše vlastní MTU (předpokládám, že máte obvyklou hodnotu tj. něco kolem 1500)? Vždyť vám přeci musí být jasné, že to nemá žádný smysl, když ho bude muset fragmentovat hned váš vlastní počítač. Pak je celkem logické, že místo ztracených paketů budete dostávat reassembly timeout.

[Taras]

MTUcko mam tech 1500, ale na tech vetsich paketech jsem si zkousel co ten spoj "vydrzi" nebot jakakoliv slabina se vzdy projevi vyrazneji na tech vetsich paketech. Co ta hlaska presne znamena? Jde o to ze ten cilovy comp to nedokazal z rozfragmentovat za nejakou rozumnou dobu?

[Ja.]

Rekl bych, ze mu vyprsel cas, ktery mel na znovuslozeni ICMP paketu ze dvou paketu, na ktere ho musel kvuli MTU rozdelit.(krasna veta!)

Alespon si to myslim.

Pokud chces vyzkouset co spoj vydrzi, doporucuji spis pomoci SCP mezi dvema PC prenaset VELIKE soubory. Paket u sifrovaneho provozu je vzdy delsi nez normalni pakety (jasne...co je normalni paket?:))

[Michal Kubeček]

Ale pochopte, že i kdybyste se postavil na hlavu, váš počítač stejně delší paket než MTU neodešle, proto se ta hodnota jmenuje MTU (Maximum Transmission Unit). Takže když si myslíte, že odesíláte paket o délce 2048 B (záleží samozřejmě na tom, na které vrstvě tu délku uvádíte), ve skutečnosti se rozdělí na dva a ty se pošlou každý zvlášť. Příjemce je pak zase musí složit dohromady. Když obdrží první fragment (což docela klidně může být ten, který jste odeslal jako druhý), alokuje si buffer, do kterého jednotlivé fragmenty skládá, dokud nemá paket celý. Pokud se do určitého limitu (v Linuxu /proc/sys/net/ipv4/ipfrag_time) nepodaří paket sestavit celý, jsou dosud posbírané fragmenty zahozeny a odesílateli se pošle ICMP message fragment reassembly time exceeded (typ 11, kód 1). Viz RFC 791, RFC 792.

[Taras]

Mockrat diky... detailnejsi objasneni problematiky MTU jsem uz ani necekal Ja jsem ty dlouhy pakety posilal hlavne proto abych "otestoval" ten spoj, ale jak vidim, tak on si to stejne vzdycky poslal po 1500B a vic ani tuk.. akorat to poslal vicekrat.

Diky

[Michal Kubeček]

Možná ani to ne. Nezkoumal jsem, podle jakého algoritmu dělí pakety do fragmentů Linux, ale jeden z možných přístupů je ten, že paket o velikosti 2048 (2028+20) se rozdělí na dva po 1034 (1014+20). Takže v domnění, že posíláte delší pakety, posíláte ve skutečnosti kratší… Na druhou stranu to svým způsobem funguje: pravděpodobnost, že projdou oba fragmenty je přibližně stejná jako pravděpodobnost, že by prošel celý paket (kdyby ho bylo možné poslat najednou).

Obecně se dá říct, že na zarušeném spoji můžete snížením MTU dosáhnout nižší ztrátovosti za cenu zvýšení režie.

[Jooky (inactive)]

Radsej ako giganticke pakety skuste pouzit velkost max do MTU a volbu -f (Flood ping).

PS: pokial nieste admin tak ho radsej informujte o tomto :o)