Problém s PPPoE - "rozpojování"/"poloprůchodnost"
- Upraveno
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.
presne tak.
- Upraveno
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 velikost MTU si s Metronetem řešil? Oni sice píšou 1492 (1500 - PPPoE header 8 byte), ale otázkou je zda se to někde ještě netuneluje. Pokud máš ozkoušeno že ti proleze jen 1400 bytů pomocí pingu, tak je to dost divný a moc to 1492 bytů neodpovídá. Pokud je max 1400, tak + 28 bytu je eth(20) + icmp(8) a máš tam 1422 co by mělo být teoreticky ne tom PPPoE. Což by znamenalo, že tam probíhá ještě něco po cestě.
Mám příklad třeba z naší sítě:
Mamé PPPoE přes EOIP tunely vedoucí na site. EOIP sežere 42 bytů, PPPoE 8. Takže na PPPoE klientu je nastaveno 1500-50 = 1450 MTU. Když pustím ping na seznam na IPv4 a zkusím co se nefragmentuje, tak max je to 1422 bytů (právě 1450 - 20 eth - 8 icmp). To všechno s obalí + PPPoE 8 byte + 42 EOIP a celé se to vleze do 1500byte fyzických.
Kdyby se řešilo to aby prolezlo celých 1500, museli bychom po cestě zvedat MTU na všech zařízeních po cestě. Nemůže to být i tvůj problém na tom iface směr CETIN/METRONET atd? Vím, že pokud u nás měli lidi pevnou IP adresu na interfacu (třeba veřejku) a nepoužili ty PPPoE = tudíž tam oni měli standradních 1500 MTU, tak docházelo k podivným jevům - napříkald rozpojování session na SSH. Ale ne stylem že by se to právě nenavázalo, ale například pak při šifrovaném přenosu více dat na cloud. Ve chvili kdy upravili MTU řádně, tak bylo po problému.
Ber to jen jako radu, nemám čas a ni náladu se tu s ostatními dohadovat na téma Mikrotik sucks, kdo má delší vedení a kdo je lepší guru, ale když tě to pomůže budu rád. Pokud je to jiný problém (nebo jiný problém kombinovaným s tímhle, rád si přečtu až to vyřešíš).
PS: Nevím jestli řešíš i IPv6, ale je u té je nutné to správně MTU nastavit i v ND aby to fungovalo korektně i pro připojovaná zařízení na Ipv6.
Měj se a hodně zdaru. Brody
brody Díky moc za myšlenku, nad něčím podobným jsem už taky laboroval/přemýšlel 
.
Já mám "Actual MTU" na PPPoE na 1480
MetroNet má těch 1480 tuším i ve své defaultní konfiguraci (doufám, že so to teda pamatuju dobře 
), kterou mají v MKčkách, nebo posílají mailem. Ale ještě to ověřím.
Nicméně si myslím, že tento problém to asi nebude. Protože "najednou z ničeho nic" nefunguje žádná komunikace od mne do internetu (ale od mne odejde) a to i pokud pošlu velice malé pakety.
Ale něco (velmi vzdáleně) podobného jsem už před delší dobou řešil na jednom routeru, kdy z "nějakého" důvodu nefungoval konkrétně stream videa z ivysilani.cz a internetové bankovnictví komerčky. Po třech hodinách jsem na to MTU přišel a opravil to. Nicméně to bylo jen právě "některá" komunikace, ne všechna.
brody Vím, že pokud u nás měli lidi pevnou IP adresu na interfacu (třeba veřejku) a nepoužili ty PPPoE = tudíž tam oni měli standradních 1500 MTU, tak docházelo k podivným jevům - napříkald rozpojování session na SSH. Ale ne stylem že by se to právě nenavázalo, ale například pak při šifrovaném přenosu více dat na cloud. Ve chvili kdy upravili MTU řádně, tak bylo po problému.
Myslím, že to je něco podobného, co jsem výše popisoval, ale ještě se nad tím jednou pořádně zamyslím .
IPv6 balíček mám zatím vypnutý. Chci si o tom první něco nastudovat, než to pustím, abych nevyrobil nějaký "průser", ale zatím se na to jaksi nenašel čas....
Každopádně díky moc za myšlenku . Ještě zkontroluju to MTU 
brody Dobrý point. Při typově podobném (ale ne zcela shodném) brněnském problému to s velikostí paketu dost souviselo a proto jsem na začátku vlákna slídil po té hraniční velikosti paketu "která ještě projde"-jakkoli tam nakonec snížení MTU nepomohlo. Ale to bylo na non-Terminátor lince, a chovalo se to v malých detailech odlišně. Nicméně závěr "něco blbě fragmentuje" se tam nabízel.
Liquidcz píše že mu to po výměně za Turris nedělá-možná by stálo zato poměřit si MTU Turris vs Mikrotik, to by nezabralo moc času, případně následně srovnat MTU.
Intuitivně mám dojem že je brody dost blízko, navíc mi něco říká že možná Terminátor (nebo protikus na straně ústředny) něco hůře zprocesuje když je na nebondované lince (nějaký bug v algoritmu rozkládání paketů mezi dvě linky, že by část šla za určitých okolností tou druhou linkou, která tam ale není?), ale tady vařím dost z vody, berte to jako divokou spekulaci k dopracování. Další bod je že tyhle paketožravé problémy se (na mém statistickém vzorku) začaly objevovat tam kde začal být lokalitě nabízen bonding (a to nezávisle na tom zda byl na dané lince využíván). Ale to je také vaření z vody, zatím to nedokážu vyargumentovat.
nosek_tomas2004 Nicméně si myslím, že tento problém to asi nebude. Protože "najednou z ničeho nic" nefunguje žádná komunikace od mne do internetu (ale od mne odejde) a to i pokud pošlu velice malé pakety.
Tome, ono by ale mohlo být skutečně tak že něco přeteče někde po trase při nějakém chybném tunelingu-fragmentaci-kompresi. Ostatně i brody píše že se to dělo jen někdy a vydráždil to jen nějaký provoz. Úplně bych jeho námět nezahazoval.
Podle mne poměřit si MTU s luqiudcz na Turrisu nebo zkusis MTU dočasně snížit by mohl být zajímavý pokus. Nikdo neříká že je to ono, ale je to věc která se dá udělat rychle a levně, tak přinejhorším to ničemu neuškodí. Nevázal bych se na to jako na hlavní vyšetřovací verzi, ale zkusil bych to.
Ad MTU.
Právě jsem to překontroloval.
- Na Mikrotiku, už nevím proč, jsem neměl nastavené manuálně MTU, a při spojení se zobrazovalo 1480.
- Na Turrisu je výchozí hodnota pro pppoe 1492.
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.
Testy z lokálního serveru přes 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
.- Upraveno
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
- Upraveno
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.
- Upraveno
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.
liquidcz 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.
Díky. Na otázku odpovědět nedovedu, ale přeji si aby to tak bylo. Už jen proto že na tento problém jinou rozumnou teorii nemáme :/ Navíc ta MTU teorie je elegantní.
Abych Turris dostal do co nejvíce podobného stavu s Mikrotikem, nastavil jsem "Override MTU" na 1488, a výsledné MTU pro pppoe interace je těch 1480.
Pak jsou následující výsledky testů.
Turris, pppoe MTU 1488(1480)
ping -M do -s 1452 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1452(1480) bytes of data.
1460 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=8.42 ms
1460 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=8.45 ms
1460 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=8.67 ms
1460 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=8.63 ms
ping -M do -s 1453 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1453(1481) bytes of data.
ping: local error: Message too long, mtu=1480
ping: local error: Message too long, mtu=1480
ping: local error: Message too long, mtu=1480
ping: local error: Message too long, mtu=1480
ping: local error: Message too long, mtu=1480
Ano, hranici na 1452/1453 mám i já na všech Mikrotik linkách. Takže teď jen čekat...
Tak Turris s MTU 1488/1480 se zdá být stále stabilní.
Při nahlédnutí do Mikrotik release notes pro Testing větev, tak jsem tam našel jednu zajímavou věc:
[https://mikrotik.com/download/changelogs/testing-release-tree]
`
Changes in this release:
*) system - improved resource allocation (improves several service stability e.g. HTTPS, PPPoE, VPN);
Other changes since v6.48.2:
...
...
*) ppp - improved stability when receiving bogus response on modem channel;
...
....
`
- Upraveno
Hmhm. Nezajímavé to není, ale pokud by to byl náš případ, musel by být Tomáš schopen na sniffnuté komunikaci odlišit komunikační tok (zejména odpovědi) závadného stavu od nezávadného.
Otázka: Mohla by principielně existovat chyba v ROS, která by se ovšem nikterak neprojevila na sniffnuté komunikaci?
EDIT: (Teoreticky kdybych místo Mikrotiku zapojil kouzelnou bramboru a tato kouzelná brambora by na příchozí pakety správně reagovala (tak že sniffer mezi bramborou a Terminátorem by viděl správné pakety), dokázal by sniffer odlišit zda je zapojený do brambory nebo do Mikrotiku?)
Nicméně kdybychom chtěli jít touto cestou - Tome kdybys nám sem dal to co jsi sniffnul, kouknul by se někdo šikovný (třeba brody) zda je ta snifflá komunikace vážně OK?
