Názory k článku Velké trable s malým MTU
-
alikarch (neregistrovaný)
ping -M do -s 1472 www.seznam.cz
pokud projde, tak je to OK , pokud ne , snižuj velikost paketu -
Ondřej CaletkaZlatý podporovatelNení třeba, aby měla přesně 1500, stačí, aby byla vetší nebo rovna. K tomu můžou posloužit třeba testovací záznamy pro projekt DNSSEC tester. Na připojení se správně funkčním PMTUD budou bez problému fungovat tyto příkazy:
$ dig +bufsize=8192 huge.dnstester.cz TXT +ignore @194.0.12.1 $ dig +bufsize=8192 huge.dnstester.cz TXT +ignore @2001:678:f::1
Ty IP adresy patří serveru a.ns.nic.cz, který je jako jediný ochoten vracet velké UDP odpovědi. Ostatní autoritativní servery b.ns.nic.cz a d.ns.nic.cz vrátí prázdnou odpověď s příznakem tc a donutí klienta k přenosu pomocí TCP.
-
Abych pravdu řekl, tak mi oba dva ty příkazy vrátí prázdnou odpověď s nastaveným příznakem TC a nemyslím si, že by byla chyba v připojení. Sice mám doma přípojku od UPC, kterou bych považoval přinejmenším za možný problém, nicméně i z jiných míst se to chovalo stejně. Nevrací UDP odpovědi pouze do velikosti 4096 bytů?
-
Ondřej CaletkaZlatý podporovatel
Pravda, mně už taky. Ještě včera to fungovalo. Zkusím zjistit u CZ.NICu, jak to je.
-
Ondřej CaletkaZlatý podporovatel
A nemáte nějaký veřejně dostupný testovací server, který by omezení velikosti UDP datagramu neměl?
-
Ondřej CaletkaZlatý podporovatel
Ještě můžu posloužit odkazem na obrázek, který se bez MSS clampingu na lince s menším MTU než 1500 nestáhne. Problém je v tomto případě kdesi na druhé straně.
-
Oskare, jako vždy krásně napsaný článek - bez zbytečného balastu, jasně a stručně k věci. Super, díky moc.
Jenom jedna drobná chybička se vloudila:
každý směrovač na cestě, který nebude schopen IP datagram pro svou velikost poslat dál
Od jaké _své_ velikosti směrovač už datagramy dál neposílá? 1U, 2U? ;)
viz http://petrkrcmar.blog.root.cz/2010/03/29/jeho-svou-nebo-vasi-aneb-cesky-gulas/
-
> Interaktivní relace jako SSH nebo telnet fungují bez problému, zatímco přenos souborů prostřednictvím FTP nebo SFTP (tedy stejným spojením jako SSH) selhává.
Problém u FTP bych chápal, ale proč by měl vzniknout problém u SFTP? Nejde tím samým tunelem, co SSH? Nebo jde o to, že SSH typicky posílá menší pakety v interaktivní session?
-
Ondřej CaletkaZlatý podporovatel
Ano, přesně o to jde. Při interaktivní práci se posílají krátké pakety, třeba i jen s jedním znakem zapsaným na klávesnici. Při bulk přenosu se naopak v zájmu efektivity posílají pakety co nejdelší.
-
Ondřej CaletkaZlatý podporovatel
U UDP není nikdy jisté, že projde :). Možné jsou v zásadě dvě cesty:
- Využít mechanizmus IP fragmentace a odesílat UDP zprávy s velikostí podle potřeby. Takhle údajně funguje třeba NFS (neručím za to nezkoumal jsem to, jen jsem to někde četl), které údajně pracuje interně s 8000 B dlouhými zprávami.
- Vyrobit si vlastní fragmentaci nad UDP a posílat zprávy o takové maximální velikosti, aby nikdy k fragmentaci nedošlo, U IPv6 to může být až 1254* B (+8B UDP +40B IPv6), u IPv4 je ale minimální hodnota 68 B, takže tam je potřeba v tichosti předpokládát, že většina IPv4 provozu také zvládne alespoň 1200 B.
První varianta je čistější z hlediska vrstvového modelu, druhá bude nejspíše spolehlivější, ale vždycky záleží na konkrétní aplikaci.
*) Ani 1254 není úplně bezpečné, někdo na cestě může do paketů přidávat další hlavičky s volbami.
-
> *) Ani 1254 není úplně bezpečné, někdo na cestě může do paketů přidávat další hlavičky s volbami
No, já teda nevím, ale IP hlavička je konstantní velikosti při průchodu Internetem, nic se do ní přidávat nemůže, volby mají tu stejnou velikost už od zdroje. (Nebo alespoň nevím o IP option, která by to dělala)
-
To ale není zásah do IP hlaviček původního paketu.
(minimálně u příchozího konce tunelu bych dokonce tvrdil, že tunelující paket je nově vytvořený paket, který končí svou životnost na konci tunelu a tedy už se jedná spíš o úroveň nad L3, kde se obsah paketu předá aplikační úrovni, která s ním potom něco udělá)
-
Ivan (neregistrovaný)
Uz jsem videl, ze Cisco VPN koncentrator propisoval nektere flagy TCP hlavicky z/do vnitrni IP hlavicky. Jedna strana TCP spojeni pak pouzivala Window Scaling, zatimco druha ne.
Cisco ma dokonce pro tyhle "chyby" option, kterym muzete ocurat MTU discovery.
Muzete prochazejicim spojenim navrdro vnutit max. velikost packetu na kterou prijdou. -
Cisco VPN koncentrátor není technicky vzato router, ale aplikační brána.
A navíc moc nechápu to přepisování z vnitřní hlavičky do vnější nebo naopak. Pokud se bavíme o standardním routovaném provozu, tak tam žádná vnitřní hlavička není. Taky se třeba nebavíme o NAT, kde se tím taky dalo argumentovat.
-
Ondřej CaletkaZlatý podporovatel
Přesně tak, může se objevit třeba nějaká rozšiřující IPv6 hlavička, která se kdesi přidá a jinde zase odebere. Předpokládám, že se tak stane třeba, bude-li někde v cestě IPSEC v transportním režimu.
-
Ondřej CaletkaZlatý podporovatel
Jasně, napsal jsem blbost, omlouvám se. Všechno od IPv6 záhlaví dál se na routerech nepřepisuje, jenom maximálně analyzuje. Správně tedy v hvězdičce u původního příspěvku mělo být uvedeno toto:
*) Ani 1254 není úplně bezpečné, někdo může mít operační systém nastaven tak, aby přidával další volitelné hlavičky.
-
jx zero (neregistrovaný)
Asi me unikla pointa.
Poslu dlouhej paket, ten se cestou rozseka na kratsi a na konci ho prislusna vrstva slozi. Tak v cem je problem? (Ze nejaky fragment dorazi pozde nebo nebo nedorazi vubec? To ale asi neni problem MTU...?)
Priznam se, ze s tim nemam zadnou praktickou zkusenost. (Jenom kdysi jsem programoval jednoho brouka, ve kterem jsem mel v pameti misto asi tak na ctyri pakety o cca 800 bajtech. Ale posilal jsem kratsi pakety, takze s tim fakt zkusenost nemam.)
-
Problém je, že u IPv6 žádná fragmentace neexistuje. Tím se výrazně zjednodušuje implementace směrování. Pokud velký paket dorazí na úzké hrdlo, router ho zahodí a pošle ICMP zprávu packet too big. Jestliže je ale po cestě zablokované ICMP (obvykle z pochybných bezpečnostních důvodů), pak tato zpráva nedorazí a je tma. Vy nevíte, co se děje, prohlížeč (třeba) točí a točí a nikdy nedotočí, protože netuší, že je něco špatně.
-
Ondřej CaletkaZlatý podporovatel
A ještě bych dodal (ale je to napsané v článku), že se to týká nejen IPv6, ale i IPv4, protože naprostá většina dnešních TCP/IP stacků posílá IPv4 datagramy s nastaveným příznakem DF.
A ještě mimochodem, na linuxu můžete staré chování s vypnutým příznakem DF vyvolat příkazem:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
-
jx zero (neregistrovaný)
Dekuji vsem za odpovedi, ale jeste chvili budu predstirat (nebo taky ne) hloupeho a furt to nechapu.
IPv6 ted neresim (to je v moji profesi daleka budoucnost), ale kdo a proc ma potrebu u IPv4 vypinat fragmentaci?
U TCP to nechapu vubec. Vzdyt prece tim, ze se (aplikacni) programator rozhodne pouzit TCP, tak od toho v podstate dava ruce pryc se slovy "delejte si s tim cestou, co chcete, hlavne at do dorazi neporuseny a ve spravnem poradi".
A u UDP uz programator tak nejak pocita s tim, ze se cestou muze stat cokoliv. A kdyz se boji, tak bude odesilat minimalni pakety, aby to proslo vzdycky.
-
Santiago (neregistrovaný)
> ale kdo a proc ma potrebu u IPv4 vypinat fragmentaci?
Bezne TCP/IP implementace v operacnich systemech standardne vypinaji fragmentaci u TCP paketu (flagem do not fragment) prave proto, ze fragmentace u TCP nema moc smysl - je lepsi rovnou ten proud dat od aplikace rozdelit do optimalne velkych TCP paketu, nez ho rozdelit do zbytecne moc velkych TCP paketu a ty nasledne po ceste nechat fragmentovat.
-
jx zero (neregistrovaný)
(Opet dekuji za odpoved. Prestoze me otazky nejspis vypadaji jako provokace, tak diky teto a podobnym diskuzim si "doplnuji vzdelani".)
Jenze pak se musi resit, co je "optimalne velke", protoze pro ruzne useky cesty je to optimum jine. Navic v case se muzou zmenit i useky cesty.
-
V pořádku :). Vzhledem k tomu, že IP je paketová síť, tak je nutné poslat paket, který se vejde po celé cestě. Je tedy potřeba zjistit optimum (maximální velikost) pro trasu jako celek.
Navíc typicky nejvíc zdržují úseky s nižším MTU (i když to tak nemusí být), takže i kdyby kritické uzly pracovali se čtvrtou vrstvou (TCP), fungovaly tedy jako TCP proxy a tím umožnily různou velikost paketů před proxy a za proxy, nepomohli bychom si tím.
-
Ondřej CaletkaZlatý podporovatel
Odpověď na tyto otázky jsem vložil do odstavce nad podnadpisem „Objevování MTU cesty,“ zkusím to tedy napsat ještě jinak a podrobněji.
U TCP to nechapu vubec. Vzdyt prece tim, ze se (aplikacni) programator rozhodne pouzit TCP, tak od toho v podstate dava ruce pryc se slovy "delejte si s tim cestou, co chcete, hlavne at do dorazi neporuseny a ve spravnem poradi".
Ano, a taky takový programátor chce, aby spojení fungovalo co nejkvalitněji. A k tomu právě pomůže vypnutí fragmentace. Fragmentace totiž neobsahuje žádné opravné prostředky pro náhradu ztracených fragmentů. Když se TCP segment velikosti 3000 B rozdělí na 1200, 1200 a 600 B dlouhé fragmenty a kterýkoli z nich se ztratí, je celý segment ztracený. Proto se snaží TCP stack přizpůsobit velikost segmentu MTU cesty, aby se segmenty dále nefragmentovaly.
Jenže TCP stack vidí jen MTU rozhraní, aby mohl zjistit MTU cesty, musí nutně odesílat pakety s flagem DF (a doufat v to, že obdrží ICMP zprávu při zahození). Kdyby přizpůsobil velikost segmentu pouze MTU rozhraní, dopadlo by to třeba u xDSL dost tragicky - odeslal by segment 1460+20(TCP)+20(IPv4) B, který by se hned na xDSL modemu rozfragmentoval na 1452+20+20 a 8+20+20 B. Takže i když by nebyl problém se ztrátovostí, rozhodně by přenos neprobíhal hospodárně a tedy ani nedosahoval maximální možné rychlosti.
A u UDP uz programator tak nejak pocita s tim, ze se cestou muze stat cokoliv. A kdyz se boji, tak bude odesilat minimalni pakety, aby to proslo vzdycky.
Ano, u UDP musí programátor počítat s tím, že se může kterýkoli paket ztratit. Zároveň ale předpokládá, že procento ztracených paketů se nebude blížit stovce. Odesílat vždy dostatečně krátké UDP zprávy je možnost (rozebíral jsem to ve vedlejším příspěvku), ale v podstatě to znamená vybudovat si v aplikaci něco jako TCP. Spousta aplikací pro UDP protokol je ale zprávově orientovaná (například DNS) a každá UDP zpráva je právě tak dlouhá, kolik v ní je potřeba přenést dat.
Mimochodem, pokud taková velká UDP zpráva někde na cestě zahozena (a odesílatel obdrží ICMP zprávu o zahození), odesílatelův UDP/IP stack stejně už nemá možnost zprávu rozdělit na fragmenty znovu, protože odesláním zprávy je vymazána z bufferu. Stane se tedy jenom to, že odesílatel si poznamená snížené MTU cesty k danému cíli a čeká na aplikační vrstvu, až se rozhodne UDP zprávu poslat znovu.
-
Ondřej CaletkaZlatý podporovatel
Oops, trochu mi nevyšly ty délky − v druhém fragmentu už nebude TCP záhlaví, takže správně má být 1452 + 20 + 20 a 8 + 20.
-
jx zero (neregistrovaný)
Dekuji. Ted jste to napsal lepe.
(V puvodnim textu je pouze: "Pokud jsou obsahem IP datagramů segmenty protokolu TCP (což je dnes pravděpodobně většina internetového provozu), je používání IP fragmentace nevhodné." Bez vysvetleni, proc.)Cele to tedy chapu tak, ze odesilateluv TCP/IP stack holt potlaci mechanismus fragmentace a misto toho musi byt tak chytry, aby nejak poznal spravne optimalni MTU pro danou cestu. (No, je to jeho vec. Ja to nastesti programovat nemusim.)
-
Ondřej CaletkaZlatý podporovatel
V puvodnim textu je pouze: "Pokud jsou obsahem IP datagramů segmenty protokolu TCP (což je dnes pravděpodobně většina internetového provozu), je používání IP fragmentace nevhodné." Bez vysvetleni, proc.
Já v článku vysvětlení vidím, dvě věty před a čtyři věty po citované větě. Ale nevadí, hlavně, že si rozumíme. :)
-
Jarda (neregistrovaný)
Když jsme se připojovali v roce 1992 do Internetu, používali jsme softwarový router KA9Q. Na sériové lince (19 200 b/s) nám běhal protokol SLIP (PPP ještě neexistoval) a MTU bylo pokud si dobře vzpomínám 576 B - procpat delší pakety se nedařilo.
Router bylo PC/AT bez HD, bootovalo z diskety; její kapacita postačovala a že start trval o něco déle nevadilo - nedělal se příliš často. Bonusem byl bezhlučný provoz, spotřeba byla tak malá, že bylo možno odpojit větrák ve zdroji.
-
faha (neregistrovaný)
Velmi pekny clanek, diky.
mss fix se cas od casu aplikuje na ruznych VPN, aby to makalo tak jak ma.Jeste pridam jeden odkaz na obsahly clanek, mohl by se pripadnemu zajemci hodit.
Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml -
Malo informovany uzivatel aplikaci (neregistrovaný)
Dobry den,
Neplanujete clanek o tom jak probiha tunelovani IPv6 skrze IPv4?
Zajimala by mne zejmena sluzba Teredo (default standard na Windows kdyz skutecne IPv6 neexistuje, na Linuxu se priznam ze nevim, IPv4 mi zatim staci). Co se deje, jak je to s platnosti, probiha casem overovani nezmenenosti cile jemuz byla IPv6 adresa pridelena, co je cilem: IPv4 adresa ci MAC, problemy s dynamicky pridelovanou IP, mozne problemy pri pouziti se vzdalenou spravou/plochou,...?
-
Ondřej CaletkaZlatý podporovatel
Díky za námět, ale nemyslím si, že stojí za to nějak podrobněji popisovat technologie jako Teredo či 6to4. Spousta lidí od internetu si myslí, že už svůj účel splnily a měly by se spíše utlumovat. K tomu taky přispívají statistiky, které ukazují že snad 30 % 6to4 provozu není úspěšně spojeno.
Nicméně, co se týče návodů na zprovoznění, tak ty už vyšly a stále platí, konkrétně: -
Malo informovany uzivatel aplikaci (neregistrovaný)
Co se týká firewallu ve Windows (od Vist výše), tak mohu potvrdit, že jsou ve výchozím nastavení aktivní následující předdefinována pravidla týkající se protokolu ICMP ve veřejných sítích:
-cíl nedostupný (ICMPv6-In)
-příliš velký paket (ICMPv6-In/Out)
-čas překročen (ICMPv6-In/Out)
-chyba parametru (ICMPv6-In/Out)
-dotaz posluchače vícesměrového vysílání (ICMPv6-In/Out)
-zpráva posluchače výcesměrového vysílání (ICMPv6-In/Out)
-posluchač vícesměrového vysílání dokončen (ICMPv6-In/Out)
-oslovení směrovače (ICMPv6-In/Out)
-inzerování směrovače (ICMPv6-In/Out)
-oslovení vyhledávání sousedů (ICMPv6-In/Out)
-inzerce vyhledávání sousedů (ICMPv6-In/Out)
-zpráva v2 posluchače vícesměrového vysílání (ICMPv6-In/Out)-typ 3 kód 4, tedy: cíl nedostupný, nutná fragmentace (ICMPv4-In)
Tuto informaci uvádím jen z důvodu, že "rozšířený" firewall má na rozdíl od přechozí verze firewallu/filtru (Windows XP) složitější nastavování protokolu ICMP. Tak aby hned někdo nevyšiloval že neví jak ICMP povolit - není třeba, základní komunikace je již nastavena. Směrovače po cestě pod kontolou stejně nemáme.
Kromě zmíněných pravidel existuje ještě pravidlo pro doménu a soukromou síť (požadavek na odezvu: ICMv4/6-In/Out), které se uplatní při sdílení souborů a tiskáren.
--
Co se týká Tereda a 6to4, tak děkuji za odkazy.
Hodně detailů lze pochopit také pokud si prostudujete (na Windows) nastavení parametrů služby (děje se pomocí netsh) a problematiku nastavení a poskytnutí vzdálené pomoci. Mimochodem, služby Teredo využívá například i klient uTorrent k tomu aby překonal případný NAT vytvořený ISP (to je podle mne to na co níže v diskusi "SB" narážel, ne na to že ISP má v provozu IPv6). V různých "manuálech" k síti torrent je problematika NAT rozebrána docela do hloubky a přitom formou, kterou může pochopit i člověk který o sítích neví vůbec nic. Nicméně nastíněných řešení bývá málo, protože v tom množství uživatelů sítě Torrent se vždy najde dost lidí s veřejnou IP adresou, a když ne tak je tu ještě server.
ČLÁNKY DO MAILU
