Podle mě to tak být nemá. Jakým MTU pak komunikuje takový klient po lokální síti (přes switch)? MTU má mít klient na 1500, pokud komunikuje skrz něco, co má menší MTU, tak se mají fragmentovat. Ne že má mít klient za každých okolností MTU nejmenší, které má zařízení, které je po cestě v komunikaci.
Beru, to je moje blbá a příliš kategorická formulace v tomhle kontextu. Teoreticky máte samozřejmě pravdu a není to optimální přesně z důvodů, co jste popisoval. Na stranu druhou, pokud tazatel opravdu neblokuje ICMP6, mělo by tedy fungovat PMTUD, a přesto se mu něco ztrácí a má problémy s připojením, tak by to bylo první, co bych za dané situace zkusil. A mít na PPPoE klientu MTU 1480 a v RA pak 1492 nedává smysl. Buď tedy nechat RA na 1500 a zkoumat proč přesně nechodí v konkrétních spojeních PMTUD, nebo srovnat to inzerované MTU s upstream spojením, případně ještě zkusit MSS clamping (v iptables je to clamp-mss-to-pmtu, neznám přesně syntaxi téhož v RouterOS), jak je i zmíněno v linkovaném článku od p. Caletky.
Já jsem primárně vycházel z toho, že většina "běžných" modem/routerů (jak přímo od providerů, tak koupené ve volném prodeji), co jsem viděl na XDSL linkách od Cetinu, prostě v tom RA inzeruje MTU z WAN rozhraní, případně je tam pak i rovnou zapnutý ten zmíněný clamping (to je třeba případ ASUSWRT), přestože je zároveň průchozí ICMP6 a ty PTB pakety. Jestli to dělají jen pro sichr a nemuselo by to být, nebo tím třeba obcházejí potíže u některých specifických klientů (op. systémů), je věc druhá.
Nevím, jak daleko je s problémem tazatel, nějak se už neozval, pokud to úplně nevzdal.
Můj troubleshooting by šel tak, že bych si na úvod potvrdil, že to souvisí s MTU a není to jiný problém, třeba tím, že na test sundám MTU na lokální síťovce v počítači - klidně i třeba na 1400. Pokud by se mi pak stránky načítaly, vrátil bych to zpět a řešil až návazně jak to udělat dál, donastavit ten router, monitorovat ICMP6, ozkoušet i ostatní klienty (telefony, televize atp.).
Poslední příspěvky
