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

nosek_tomas2004 · 5. kvě 2021

liquidcz na MK jej taky nemám na "tvrdo", takže se tam vždycky hodí 1480.

jchudoba Zkusím si s tím MTU nějak pohrát (zvyšovat/snižovat), ale teď to momentálně nechám tak, jak to je, když to mám rozřešený s technikem .

Bbrody · 5. kvě 2021

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

Jjchudoba · 5. kvě 2021

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.

Lliquidcz · 5. kvě 2021

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.

Jjchudoba · 5. kvě 2021

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í.

Lliquidcz · 5. kvě 2021

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

Jjchudoba · 5. kvě 2021

Ano, hranici na 1452/1453 mám i já na všech Mikrotik linkách. Takže teď jen čekat...

Lliquidcz · 7. kvě 2021

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;
...
....
`

Jjchudoba · 7. kvě 2021

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?

Lliquidcz · 7. kvě 2021

jchudoba Otázka: Mohla by principielně existovat chyba v ROS, která by se ovšem nikterak neprojevila na sniffnuté komunikaci?

Můj skromný názor nepodložený žádným důkazem je, že ano.

Myslím si, že k problémům může docházet spíš na úrovni ppp komunikaci (LCP, BCP, IPCP, ...).

Jjchudoba · 7. kvě 2021

liquidcz Můj skromný názor nepodložený žádným důkazem je, že ano.

Když na topologii budeš nahlížet že router je prostě černá skříňka (nebo schrodingerova krabice) do které putují pakety a úlohou routeru je na pakety vypouštět ven reakci ... poznáš podle reakcí zda je uvnitř funční mikrotik, nefunkční mikrotik, nebo brambora, pokud reagují správně (a reakce se prohliží a posuzuje snifferem?).

Jjchudoba · 7. kvě 2021

liquidcz Myslím si, že k problémům může docházet spíš na úrovni ppp komunikaci (LCP, BCP, IPCP, ...

Naznačuješ že by pakety těchto protokolů byly pro sniffer neviditelné?
Tome, jak hluboko jsi šel?

Lliquidcz · 7. kvě 2021

jchudoba Naznačuješ že by pakety těchto protokolů byly pro sniffer neviditelné?
Tome, jak hluboko jsi šel?

Naznačuji spíš to, že pokud si to odfiltroval SRC IP / DST IP, tak tam tuhle komunikaci nemusel vidět a porovnávat. A také nevím jak poznat, že ppp komunikace je správně. Mylsím si, že každá implementace protokolu ppp v jiných OS nebo dokonce zařízení je odlišná. K těmto protokolům v ppp komunikaci můžou přistupovat odlišně. Usuzuji tak i jen podle pár řádků v UI Luci na Turrisu kde lze nastavit toto:

LCP echo failure threshold - 0 - Presume peer to be dead after given amount of LCP echo failures, use 0 to ignore failures
LCP echo interval - 5 - Send LCP echo requests at the given interval in seconds, only effective in conjunction with failure threshold
Host-Uniq tag content - auto - Raw hex-encoded bytes. Leave empty unless your ISP require this

Jjchudoba · 7. kvě 2021

Na Mikrotiku je u pppoe parametr keepalive-timeout, myslím že dělá to že občas pošle LCP echo request a pokud nedostane odpověď, zavěsí, což by mohlo být jiným způsobem popsané to z Turrisu. Ale hlouběji jsem to nezkoumal.

Počkal bych teď na Tomáše až nám řekne jak hluboko tu komunikaci sledoval, potom bych se k tomu případně vrátil.

Jjchudoba · 7. kvě 2021

liquidcz Naznačuji spíš to, že pokud si to odfiltroval SRC IP / DST IP, tak tam tuhle komunikaci nemusel vidět a porovnávat.

Moment, on se přece díval do komunikace mezi Mikrotikem a Terminátorem, tedy v úseku kde už to putuje zabalené do PPPoE. Nezabalenou komunikaci by tam vůbec neměl vidět. No, uvidíme co napíše.

Lliquidcz · 7. kvě 2021

jchudoba Moment, on se přece díval do komunikace mezi Mikrotikem a Terminátorem, tedy v úseku kde už to putuje zabalené do PPPoE. Nezabalenou komunikaci by tam vůbec neměl vidět. No, uvidíme co napíše.

Možná se pletu, ale Cetin nemá zapnuté encryption pro pppoe, takže ty frejmy budou v čitelné podobě.

nosek_tomas2004 · 7. kvě 2021

jchudoba
Ano - "odchytávám" komunikaci mezi Hlavním RB (které vytáčí PPPoE) a terminátorem. Zapojené je to (pro případ nějakého nedorozumění) takto (na té 800ce jsou eth2 a eth3 v bridgi):

liquidcz jchudoba
Z toho, co jsem na té 800ce odchytil si myslím, že to šifrovaný je (zejména ten poslední screen):

Teď to je funkční. Komunikace s MetroNet technikem dopadla prozatím tak, že se mi ozval specialista, který si prý nasadí monitoring na moji linku. Ale ozval se až dnes. V průběhu týdne jsem to "uvedl" do funkčního stavu. Zkusil jsem tam tedy dle jchudoba dát MTU 1492. Od té doby (tuším středa) zatím v pohodě. Ale z toho bych zatím nic úplně nevyvozoval - někdy se to objeví do dvou dnů, jindy zase až za 14 dní. Mometálně se to tváří úplně stejně jako:

liquidcz 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

Jinak - jen tak pro info - ověřoval jsem si konfiguraci v MK, který byl dodaný přímo (i s configem) MetroNetem a PPPoE mají bez fixního MTU, takže si Mikrotik navolí těch 1480.

Ještě jeden poznatek (vše je popsáno, pokud jsem v onom záhadném "závadném" stavu):

pokud PPPoE dám disable a za chvíli (zkoušel jsem max 3 minuty) enable, tak se na stavu nezmění vůbec nic. Tunel se celkem rychle naváže (+- max 2 sekundy), ale odchozí komunikace opět do cíle nedorazí (ale na meziRB vidět je)
pokud ale "vyrvu" drát z fyzickýho portu ETH1 (do kterého je připojena celá ta větev směrem k Terminátorovi) tak se tunel, logicky, rozpojí. Ale po opětovném zapojení ETH se jenom tak nenaváže. V logu to pořád řve:
Tunel se naváže až asi po 1 - 2 minutách. Mezi tím celou dobu lítá v logu to, co je na obrázku výše. Ale jakmile se tunel naváže, tak už vše funguje
pokud dám jenom krátký diable/enable fyzického interfacu ETH1, tak se to zachová úplně stejně jako bych z něj vytáhnul drát. Tedy to, co jsem popsal v druhé odrážce.

Takže pro uvedení do funkčního stavu se nemusí MK restartovat, stačí disable/enable ETH1.

jchudoba 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?

Až se dostanu do toho závadného stavu tak to určitě pošlu. Nebo mám poslat sniff i za funkční situace, ať je to s čím porovnávat?
OT: Ten export ze snifferu, co se po mě chce má opravdu vypadat nějak takto ?

iTomB · 7. kvě 2021

nosek_tomas2004 Tome kdyz jsi zkousel dat dis/en portu, byl mezi jeste zapojen RB800? Pripadne muzes zkusit zakazat port na tom RB800 eth3. Pak by zmenu pocitil terminator a ne mikrotik.
Dalsi vec je, zda se i pri rozpadlem spojeni posilaji nejaka data a neresetuji timeout u session v conntract tabulce.

Zzajdee · 7. kvě 2021

nosek_tomas2004 sniffer by mel ukladat data do souboru .pcap a ten se prohlizi Wiresharkem.
Pozor na ty reconnecty. CETIN umoznuje jednu aktivni PPPoE session, takze pri vytrhnutem kabelu chvili trva, nez si protistrana vsimne, ze session byla nekorektne ukoncena. Az pak umozni dalsi session.
Zaroven CETIN aplikuje antihammering, doporuceno je nezkouset vytaceni casteji nez jednou za minutu. Kdysi to byl tvrdy limit, dneska oficialne lze PPPoE vytacet kazdych 5 sekund, ale pri 1440 neuspesnych pokusech za 48 hodin muze CETIN pripojku uplne zablokovat.

Lliquidcz · 7. kvě 2021

nosek_tomas2004

Jak psal @zajdee ,pohodlné prohlížení nachytaného provozu lze provádět ve Wiresharku. Případně, pokud to síťové zapojení dovoluje, si packet sniffer z Mikrotiku rovnou posílat na Wireshark běžící na tvém stroji.

Popsáno to je zde: https://www.wizzycom.net/traffic-capture-from-a-mikrotik-device-to-wireshark/