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

nosek_tomas2004 · 2021-04-12T18:01:43+00:00

Ahoj všichni, jdu zde poprosit o radu se situací, ve které si už vůbec nevím rady ☹️. Stávající situace: RB1100AHx2 jako hlavní domácí GW RoS i FW je 6.48.1...

nosek_tomas2004

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

brody

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

jchudoba

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.

liquidcz

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.

nosek_tomas2004

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

jchudoba

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

liquidcz

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

jchudoba

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

liquidcz

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

jchudoba

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?

liquidcz

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, ...).

jchudoba

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?).

jchudoba

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?

liquidcz

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

jchudoba

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.

jchudoba

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.

liquidcz

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

iTomB

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.

zajdee

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.

liquidcz

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/

jchudoba

nosek_tomas2004 Ale po opětovném zapojení ETH se jenom tak nenaváže. V logu to pořád řve:

To asi už vysvětlil zajdee (odpojení kabelu nepředcházelo zavěšení, proto až do timeoutu další tunel CETIN nedovolí). Kdybys to chtěl dále rozpracovávat, napadá mne položit si vedle dalšího Mikrotika s připravenou PPPoE konfigurací a ten ETH kabel rychle prohodit do toho druhého. Pokud se nepřipojí ani ten, bude to zcela jistě nějaká ochrana o které píše zajdee. Pokud by se na jiném kusu okamžitě chytl tak ... sám nevím. Ale není důvod pochybovat o zajdeeho vysvětlení. Navíc tohle by asi šlo vyzkoušet bez čekání na závadný stav - je-li to ochrana na straně CETINu, projeví se to vždy.

nosek_tomas2004

zajdee liquidcz když ten txt přejmenuju .pcap a otevřu ho ve wiresharku, tak se to otevře. Díky moc 😀 😊. Díky moc za odkaz, síťové prostředí by to určitě umožňovat mělo. Vyzkouším. Díky 😊

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

Přesně toto jsem si myslel (ač jsem to neměl odnikud potvrzené) taky. Díky za potvrzení.
Když se vrátíme k "původní" paketožravé ( i když to vlastně žere rámce 🤔😅) teorii @jchudoba, tak by to do ní zapadalo (pokud teda uvažuju správně, že při nekorektně ukončené PPPoE session se vygeneruje nové "SESSION_ID" - což by asi měla být pravda, pokud jsem dobře pochopil to, co jsem na webu o PPPoE přečetl).

Mám řekněme PPPoE tunel s SESSION_ID "X" na něm sedí ta paketožravá potvora. Když tunel nekorektně ukončím (vyrvu drát), tak se sice déle navazuje/nenavazuje/navazuje/.... až se nakonec naváže, ale s jiným, novým SESSION_ID "Y". A o něm zatím ta potvora "neví". Takže jede všechno v pohodě. A pak prostě za nějakou dobu ta potvora "najde" to SESSION_ID "Y" a zasedne si na něm.

Otázkou zůstává, pokud je tato teorie správná, co je ta ona mystická potvra. Protože pochybuju, že po drátech CETINu běhá nějaký skřet, který se tím živí 😅 🤣

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

V tu dobu, když jsem na hlavní RB1100AHx2 udělal ten disable/enable ethernetovýho portu, tak tam ta 800ka BYLA. Ale zkusit udělat disable/enable eth3 na té 800ce mě, se přiznám, nenapadlo. V dalším stavu určitě zkusím 😉. Díky moc za tip 😊

nosek_tomas2004

jchudoba tam ještě jeden rozdíl v konfiguraci v závislosti na (ne)přítomnosti Terminátoru, a to že se to (ne)vytáčí nad VLAN848.

Pravda, na to jsem zapomněl.

Nicméně...asi jsem to zakřikl 😂. Dnes v 12:35 se to stalo opět. Zkusil jsem, co psal @iTomB:

iTomB Pripadne muzes zkusit zakazat port na tom RB800 eth3. Pak by zmenu pocitil terminator a ne mikrotik.

Přesně toto jsem udělal, PPPoE tunel ale ještě minutu visel running, protože mám nastaveno "Keepalive Timeout = 60" (už ani nevím proč). Když jsem předtím dal disable na hlavním RB, tak PPPoE spadlo hned (asi závislost na fyzickém portu).
Až tunel zdechnul, tak jsem eth3 na RB800 zpět povolil a tunel se navázal a to funkčně. Takže takto to lze "resuscitovat taky".

Nicméně jsem pořídil ten sniff "vadné" komunikace. Bohužel jsem tak nestihl ten "přelom" z funkční do vadné, jak psal liquidcz .
Po celou dobu, co jsem dělal sniff mi běžel z NTB ping na 1.1.1.1 (samozřejmě bez odpovědí). .PCAP je dostupný zde. Tentokrát jsem sniff udělal nad ETH3, nikoli nad ETH2, což bylo na obrázcích výše (pouze kvůli jednoduššímu RX/TX "dovozování")....

Ještě bych chtěl osvětlit pár věcí, které jsou v tom sniffu vidět a předejít tak nějakým "zbytečným pochybám":
Lze tam vidět, že přes PPPoE tečou i nějaká data na lokální 192.168.0.0/16 adresy. Ty by tam správně neměly co dělat. Je to dáno tím, že tyto některé adresy (namátkou 192.168.3.10) jsou za VPN tunelem, který ale spadnul, takže se "znefunkčněla" i routa, která tento provoz posílá do L2TP tunelu XY. Takže paket vyhověl až defaultní routě 0.0.0.0/0, která vede do PPPoE. Proto tam takovýto nějaký provoz je.

Sice bych to možná měl mít nějak ošetřené, aby se tam ty pakety vůbec nedostaly, ale co už 😁

Edit: jenom doplním, že ten sniff běžel jenom krátce, přišli mi zbytečné nechat to běžet třeba minutu. Proto tam ty pingy na 1.1.1.1 jsou asi jenom 3 - (trvaly déle, protože spadly do timeoutu)

« Předchozí stránka Další stránka »