Dotaz: blokované icmp fragmentation needed?

[rastos]

Mám nasledovnú situáciu:

Klient----{NAT-ujúci router1}----{ISP1}----{Internet?}----{ISP2}----{bridge}----{NAT-ujúci router2}----WebServer

Klient sa pripája na webmail na WebServeri. Bez problému sa pripojí a zobrazí stránku, môže prechádzať z jednej na druhú a podobne. Problém nastane, keď sa pokúsi vyplniť formulár a poslať mail. Pre užívateľa to vyzerá, že odosielanie trvá dlho a nakoniec sa nepodarí. Podarí sa však, ak Klient zníži svoje MTU z 1500 na 1000.

• {router1} je klasický domáci router. Webový interface. Nijak moc inteligentný. Na ISP1 je pripojený optikou.
• {bridge} je ADSL modem v bridge móde.
• {router2} je Linux a na ISP2 sa pripája cez PPP (ppp interface má MTU 1492)
• {Klient} je Linux. Jeho defaultné MTU je 1500.
• {WebServer} sú XP

Tie všetky sú pod mojou kontrolou. ISP1 tvrdí, že nič neblokuje. S ISP2 som ešte nehovoril.

Odosielanie mailu znamená, že Klient prenáša na WebServer "väčšie" množstvo dát. Nie len krátku požiadavku na jednoduchú URL, ale aj dáta zadané do formuláru. Keďže zníženie MTU na Klientovi umožní prenesenie tohto väčšieho množstva dát, domnievam sa, že mi niekto cestou zablokuje ICMP paket s požiadavkou na fragmentovanie pod úroveň 1492 (ten počet vyžaduje ppp).

Otázka znie: ako túto teóriu overiť a ak je pravdivá, ako zistiť, kto mi tie pakety zahadzuje?

Odpovědi

[NN]

Otestovat se to da pomoci ping(zakazani fragmentace a patricne velikosti paketu) a postupovat stroj po stroji.

NN

[rastos]

Klient aj WebServer sa vedia navzájom pingnúť aj s "-s 1600".

[rastos]

"-M do -s 1600" povie na Klientovi

....
From 192.168.2.221 icmp_seq=1 Frag needed and DF set (mtu = 1500)
^C
--- 212.5.197.56 ping statistics ---
0 packets transmitted, 0 received, +26427 errors

na strane WebServera to isté, len s IP adresou toho ppp0 a mtu = 1492

[vencour]

A při pohledu na provoz vidíte nastavené "don't fragment"?

[rastos]

Momentálne hej. A prekvapuje ma to. Nech komunikujem kamkoľvek, tak všetky pakety čo vidím majú nastavene don't fragment.

Navyše sa to celé v tejto chvíli funguje. Vrátim sa k tomu, keď ten problém znova nastane.

[petr_p]

Dejte si pozor na směrovací cache, do které si jádro schovává PMTU. Po každé změně MTU rozhraní je dobré ji vyprázdnit.