

Problem s MTU (v GRE tunelu)
Zdravím síťaře. Mám takový jeden problémek v sítí a asi jsem vyčerpal všechny své možnosti k nápravě, tak se zkusím obrátit sem.
Jde mi o PtP bezdrátový spoj. Kvůli prostupu multicastu wifi spojem je přes PtP spoj veden GRE tunel, který má na obou stranách IP adresy a skrz tuto trasu jde OSPF, a je jím routovaný kompletní provoz PtP spoje. MTU GRE rozhraní, kvůli hlavičce navíc je sníženo na 1476.
A tu je ten problém. Z nějakého mě neznámého důvodu nefunguje ani na TCP spojeních zjištění nejnižšího MTU trasy, pakety chodí o velikosti 1500, dochází k fragmentaci, což jednak snižuje kapacitu spoje, ale, jak jsem zjistil, některé webové serveru (například rajče nebo fejsbuk) nelibě nesou fragmentaci a například rajče nenaběhne vůbec. Po ručním snížení MTU na síťovce (linux, žádný problém) na 1476 se provoz najednou krásně rozběhne.
Co jsem zkoušel:
Kompletní rodina ICMP povolené všude
Zkoušel jsem zmenšit MTU na fyzickém rozhraní, na které se na druhé straně spoje připojují klienti, tedy rozhraní, na které je připojený AccessPoint, na 1476. Měl jsem podezření, že by GRE tunnel nějakým způsobem nedával vědět o fragmentaci, ale ani zde nedošlo ke zmeněně k lepšímu.
Zkoušel jsem přes DHCP vnutit (Option 26) klientům MTU na síťovce, ale to mi windows úspěšně ignorují. Myslím, že linux to vzal, ale musel bych si to několikrát opakovaně ověřit.
Na straně, kde jsou klienti je routrem (a iniciatorem GRE tunelu) routerboard s mikrotikem , na druhé straně je routrem EdgeMax router od Ubiquiti, který dělá směrem do internetu i překlad adres.
Díky za jakékoli nakopnutí schůdným směrem.
JR
Asi to bude úvaha k ničemu, ale co kdyby:
Není hlavička 28 bitů (1500-28=1472)? Tedy paket o délce 1500 musí být fragmentován.
No, vycházím z toho, že když nastavím na síťovce fyzické MTU 1476, tak se vše bez problémů rozjede. Nene, GRE hlavicka je 4B a dalsi IP adresa je 20B, takze dohromady 24, tech 1476 sedi.
Zkuste schválně z nějakého Win stroje ping www.facebook.com -f -l 1448 a pak ping www.facebook.com -f -l 1449. Pokud je má úvaha správná, tak první paket projde a druhý ne - ale přiznám se, trochu Vás teď zneužívám ke svým studijním záměrům :)
EDIT:
pokud to je opravdu, jak píší, zkuste na Win stroji zkontrolovat MTU na příslušném rozhraní (Win 7): netsh interface ipv4 show interfaces. Pokud tam bude oněch 1476, začínám chápat Váš problém :)
S facebookem je problém trošku odlišný, tam samotný FB funguje, ten nakonec naběhne, ale s hrozným zpoždením. Tam to má příčinu pravděpodobně na serverech, kde jsou nekteré části stránky - reklamy, fotky - nevím přesně která. Po tom, co to vyhučí na timeoutu, tak se zbytek donačte. U rajčete to končí na timeoutu rovnou.
Pokus s pingem na rajče jsem dělal, dělící hranicí je skutečne 1476. Což potvrzuje i nastavování MTU na síťovce počítače (linux). Paket velikostí 1476 projde, paket velikosti 1477 už končí na timeoutu.
I kdyby dochazelo k fragmentaci GRE provozu, tak vnitrni obsah by to nemelo ovlivnit a na vystupu z routru by mel byt paket opet kompletni, jestli nad tim premyslim ze spravne strany.
Aha, omlouvám se, až teď jsem to pochopil (něco čtu a nevnímám). Problém může být zdá se v PMTUD (ostatně jste to již popisoval). Nevím nakolik je to čisté řešení, nicméně co to obejít na Mikrotiku títmo:
http://www.minihowto.eu/mikrotik-change-mss-on-tun nel-interface
kurňa, byls rychlejší
edit: stejný problém jsem řešil na PPPoE tunelu vystaveném z Linuxového routeru - lokálně OK, stroje routované měly problém.
Napadla me moznost zvetsit MTU na fyzicke ceste mezi routry, aby GRE tunnel mel 1500B, ale to nechci delat, nez kompletne vymenim spoj (ted to neni ani mozne), vyzaduje to nastaveni MTU na obou sitovkach bezdratovych pojitek, porty routru a zvetseni MTU na switchi.
1. ohledně fragmentace a ICMP fragmentation: ty to možná povolené máš, ale po celé cestě tomu tak být nemusí.
2. jak máš nastaveno MSS?
http://www.linuxtopia.org/Linux_Firewall_iptables/ x4700.html
Ou, magle tabulky... hmmm
ja myslel, ze to pujde bez podvadeni. Jistou nadeji vkladam do postupneho prechodu klienskych siti na IPv6 only.
Jsem zvedavy, jestli to pujde na tom UBNT routru nastavit.
jo, "máklé" tabulky
To je obecně problém GRE tunelu, tunelu, mikrotiku, jinde? Při lovení paketů i jen v rámco mojí sítě, navíc ze sítí, kde je povolený veškerý provoz jsem nezaznamenal žádný požadavek na změnu MSS, přestože komunikace prochází GRE tunelem. Nevybavuju se, že bych měl podobnou zkušenost s předchozím mikrotikýckým EoIP tunelem.
A co když dorazí paket, který má být směrován do tunelu a už má MSS menší než MTU tunelu (někde po cestě je něco užšího), i tam dojde k přepisu?
Tak ten workaround s mangle tabulkama funguje. Da se to nastavit i na tom EdgeRouter, ale jen s pevnym MTU? nejde tam clamp-mss-to-pmtu. Respektive ono by slo, pod tim jsou normalni iptables na linuxu, ale ja to radeji budu konfigurovat jen z cli.
Diky moc
PS: to je snad poprvé, co se mi na úzce odbornou otázku zde na poradně dostalo odpovědi
tak tvoje otázky jsou většinou obdobou toho, co z fyzikálna řeší Stephen Hawking