Problém s PPPoE - "rozpojování"/"poloprůchodnost"

Hele nechci vám kazit diskuzi, ale na mých přípojkách co jsou přes Metronet (s Terminátorem) se nic takového neděje. Jako koncová zařízení používám výhradně ASUS routery s Merlinem nebo pfSense. Obávám se že chyba není na straně CETINu/Metronetu, ale na straně Tiku...

Fajn, a jak se vypořádáš s faktem že to z Tiku to teče v pořádku, což bylo prokázáno snifferem? Zkus prosím rozepsat nějaké vysvětlení kdy platí současně že [na příchodu sniffnuto že je to OK, v logu Mikrotiku je to OK, sniffnuto na odchozím směru je to také OK], a současně "je to chyba Tiku".

Kde je tedy potom v Tiku chyba, když na příchjozí pakety reaguje správně, což prokázal sniffer?

(nehledě k tomu že tohle se mi děje per lokalita, mám i terminátor+mikrotik s uptimem 180dnů, a to jen kvůli updatům).

Jinak nevylučuji že Mikrotik může ten jev nějak vydráždit (třeba způsob fragmentace?, v Terminátoru něco přeteče a sesype se to?) a že s jiným zařízením by se nedělo, ale dokud to sniffnuto teče tam i zpět v pořádku, tak si s tím Terminátor a to co je za ním musí poradit.

Tvrdím že pokud by byla "chyba v Tiku", tak budu schopen ve sniffnutém odchozím provozu najít buď absenci dat, nebo vadná data. Prokázal toto někdo?

A pozor, nikdo netrvdí že je to Metronetem - mi to dělá i na jiných providerech a problém bych lokalizoval na něčem co patří CETINu.

Věříš-li že je to Mikrotikem, je snadný způsob jak to prokázat - nech si od Tomáše poslat uložený sniffnutý provoz a řekni nám co Mikrotik odesílá špatně. Na to stačí sniffnout jeden SYN paket zevnitř ven (který na cílovou IP už nedoleze), pár bajtů, žádná složitá analýza. To ti Tomáš určite rád sniffne.

Nakonec Tome můžeš to sem hodit veřejně, jeden sniffnutý SYN zevnitř ven, ať kdokoli kdo si myslí že to Mikrotik na Terminátor špatně odesílá má možnost to zanalyzovat a buď říct kde je chyba (potom ji rád předám na support), nebo ať mlčí navěky. Bude to hozená rukavice pro všechny zastánce teorie "je to Mikrotikem",

Držme se prosím toho že takovéto diagnostiky se dělají snifferem a z něj získanou analýzou tvrdých dat, nikoli statistikami co se komu hryže nebo nehryže. (Když bych se pouštěl do úvah které nejsou postaveny na měkkých datech, aktuálně se mi to neděje na ani jedné ze stovek bondovaných xDSL s Terminátorem. Nebondované aktuálně nemám, oba diskutující zde mají Terminátor nebondovaný. Ale zda je tam souvislost by bylo odvážné dovozovat, byť jistá statistika tam je.)

To by byl postup který bych zcela jistě poradil na mimibazaru nějaké bydlence kterou zlobí internet. Od člena odborného fóra bych však očekával postup odborný - a tím je sniffnutí komunikace, analýza zachyceného provozu a výrok "provoz je OK, je třeba hleda za sniffovaným zařízením" nebo "paket X má chybu v hlavičce Y, hodnota Z tam nedává smysl".

Prosím, nedělejme z tohoto vláka mimibazar.

Různí ajťáci to dotáhnou různě daleko. Někomu stačí umět "vypnout a zapnout", ti o něco málo šikovnější umí "vyměnit za jiné zařízení", ještě o něco šikovnější "downgradovat". Ano, i s tímto repertoárem se dá před méně znalými uživateli předstírat že jsem ajťák. Potom se ale nedivme že tak jako se o policistech vykládají vtipy že jeden umí číst a jeden psát, o ajťácích se točí seriály jak umí jen vypínat a zapínat.

Kdo na tomto levelu zamrznout nechce, ten si zanalyzuje problém hlouběji. Každému dle jeho mentální kapacity, ochoty se učit, rozvíjet, rozpočtu, míry priorit ...

Tomáše zjevně baví se učit, já bych mu to přál, jednou bude vydělávat více než ten kdo bude umět jen restartovat, měnit a downgradovat. Ale i to tahání kabelů bude potřeba aby někdo uměl, takže cajk, nikdo neříká že všichni musí u práce přemýšlet.

nosek_tomas2004 @liquidcz

EDIT: Koukam že jsem chytře odpověděl Tomášovi na koment od Liquid - On tam opravdu psal snad 1400 bytů? No prostě bych si tohle ověřil.

Od Mikrotik tě tam hodí snad vždycky 1480. je to nějaký jeho vnitřní algroitmus výpočtu tak aby se to nefragmentovalo ale nepřijde mi, že by to nějak moc fungovalo. Většinou to ale nevadí. Ale třeba v Našem případě to musíme nastavit staticky a 1480 nám pak pro IPv6 (páč ji tunelujeme přes ten EOIP) nefungovalo. Každopádně jesltli tě proleze přes TURIS 1464 a jede to OK, pak by to mělo i přes TIK. 1464 + 20 eth + 8 ping = 1492 to by mělo byt na PPPOE , přidáš 8 byte (PPPoE) a máš 1500. Takže by to takhle mělo být OK. Mě zmátlo, že si psal, že tě proleze jen 1400 - což mi přišlo docela málo (možná jsem to jen blbě pochopil). Jinak podle mě Metronet má v předáváku 1492, ale linky tam nemam máme vlastního virtuála nad CETINEM a dáváme taky 1492. Zkušenost z bondingem a terminátorem já osobně nemám, tady neporadím. Nicméně se rád přiučím pokud na to přijdete. Brody

liquidcz Aktuálně mám zapojený Turris, o víkendu přepojím zpět Mikrotik a udělám testy jak při 1480 tak 1492 na pppoe.

Pod vlivem posledního vývoje diskuse bych si dovolil navrhnout ke zvážení nic fyzicky neprohazovat, ale jen změnit MTU na stejné jako má Tomáš. Pokud se ti to začne sypat tak jako před výměnou za Turris, jsme doma.

(A Tomáš (až mu to Metronet technik dovolí) udělá opačnou kontrolu, tedy se navzájem křížově doplníte každý z opačné strany téže teorie a buďto se potkáte nebo ne).

Ušetřil by sis fyzické prohazování hardwaru a současně bys do řešení dodal výsledek křížové kontroly-z toho by se dalo vytěžit o malinko více než z původního plánu-nicméně ani ten není špatný.

Pokud to bude ono, nesmíme potom zapomenout na konfrontaci s dokumentací CETINu. Ale to předbíhám.

jchudoba
Taky možnost. Nastavil jsem na Turris pppoe overvrite MTU na 1480, což je ta výchozí hodnota na Mikrotiku. pppoe se navázalo, ale Turris nyní ukazuje místo těch mnou očekávaných 1480, pouze 1472.

EDIT:
Zjistil jsem, že pokud v Turris (OpenWRT), nastavím u WAN (pppoe) Override MTU na 1480, tak ta hodnota se nastavila na tom podkladovém interface VLAN848 (eth0.848). Pak je jasné že výsledkem samotného pppoe interface je 1472.

A očekávané výsledky testů ze serveru za Turrisem.

Turris, pppoe MTU 1480(1472)

ping -M do -s 1444 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1444(1472) bytes of data.
1452 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=8.68 ms
1452 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=8.68 ms
1452 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=8.89 ms
1452 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=9.12 ms
1452 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=8.88 ms
1452 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=8.65 ms
1452 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=8.68 ms

ping -M do -s 1445 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1445(1473) bytes of data.
ping: local error: Message too long, mtu=1472
ping: local error: Message too long, mtu=1472
ping: local error: Message too long, mtu=1472
ping: local error: Message too long, mtu=1472
ping: local error: Message too long, mtu=1472
ping: local error: Message too long, mtu=1472
ping: local error: Message too long, mtu=1472

Turris, pppoe MTU 1492

ping -M do -s 1464 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1464(1492) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=8.68 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=8.67 ms
1472 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=8.71 ms
1472 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=8.32 ms
1472 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=8.74 ms

ping -M do -s 1465 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1465(1493) bytes of data.
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492

Otázkou zůstává zda-li i Turris, nyní s MTU 1480/1472 jako Mikrotik, dokáže vyprovokovat infrastrukturu Cetinu tak, aby se linka dostala do "problémového" stavu.