PPPoE interface se nerozpojí - při výpadku je neustále "R-runing"
-je running protože není důvod zavěšovat-až na PPPoE BRAS linka běží, tak proč zavěšovat. Přece nebude zavěšovat funkční linku (to by byl teprve bug).

Všechny VPNky se (pochopitelně) rozpojí
-protože pakety s daty jsou velké a démon je slupne jako malinu, následně to vytimeoutuje.

Ping na Veřejnou IP na Mikrotiku ale jde (nechápu 🥴)
-protože je to malý paket s dvouciferný velikostí, trpajzlíky démon nežere

Pokud se zkusím připojit VPNkou na NAS doma z mobilu (na datech) tak countery na DST-NATovském pravidlu se točí
-protože TCP SYN je malý paket s dvoucifernou velikostí (cca 60), trpajzlíky démon nežere

Pokud PPPoE interface disablnu a potom enablnu, znovu se naváže, ale stav je pořád stejný
-kolik sekund uběhne mezi enable/disable? jaký je timeout démona v sekundách než zjistí že je linka zavěšena a jde se krmit něčím jiným ?

Domácí úkoly pro chytráky:
-Ping z MK do světa též nic, tracert to samé
Proč platí toto? Je to jednoduché, koho to napadne jako prvního? (Ne, verzí ani Mikrotikem to není)

A koho napadne co je vlastně tím paketožravým démonem? (Ne, není to Mikrotik).

    jchudoba Pokud PPPoE interface disablnu a potom enablnu, znovu se naváže, ale stav je pořád stejný

    Můžeš tedy, když tomu nikdo nerozumí vysvětlit, jakým problémem v konfiguraci MK docílím toho, že mi PPPoE jede dva dny a pak padne? Tedy krom nějakého scriptu, nebo adminazáškodníka? Já to nepoužívám.

    A stejně si myslíš, že jsem debil, takže k tomu pingu: jemu to z venku na IP toho mikrotiku pingem v tu nefunkční chvilku jde. Tedy malý paket tam a zpět. Ale opačný směr je problém tedy proč? Stejný malý paket, také ICMP, jen opačně typy. Nebo mikrotik posílá defaultně velké ICMP?

      o 13 dní později

      Zdravím ve spolek. Aktuálně řeším podobné problémy. ROS 6.48.2, pppoe přes vlan 848, terminator. Když se stane "výpadek" připojení tak směrem ven "nefunguje internet"(zpráva od uživatelů), testy z venku ukazují, že z některých sítí/ip funguje ping/traceroute, nicméně nějaké testovací TCP spojení neproházejí. Velikost průchozího icmp packetu jsem zatím netestoval. Debug log pppoe na MKT nevykazuje nic podezřelého. Vypadá to, jak kdyby linková vrstva a pppoe spojení fungovalo. Působí to na mě, jak kdyby nějaké síťové zařízení na cestě se rozhodlo filtrovat provoz, nebo neposílalo vše do sestaveného pppoe.

      @jchudoba Mohl bys mi prosím prozradit jak by měla znít ta správná magická prosba do hlubin Cetinu?

        1a) lokalita (stačí okres)?
        1b) ověř velikost ICMP která (ne)projde. Potom teprve má smysl předávat ať již na CETIN nebo jinam.
        2) prosím longterm verzi, pokud neexistuje silný důvod pro stable (nemyslím že to souvisí s verzí, ale jde o ten návyk na longterm. Když nic jiného, je mezi nimi delsí interval, tak proč to zákazníkům restartovat zbytečně často a kazit uptimy, že.)

        A pochvala za pěkný popis problému, už jen použití sousloví "linková vrtsva" napovídá že jsi na tom řádově lépe než "zkušení matadoři".

          jchudoba
          1a) Pardubice - AC name PA77B01PARDMA02
          1b) při příštím "výpadku" zkontroluju, při dnešním jsem to nestihnul. Rodina už je naučená rychle reagovat a automaticky restartovat terminator, a tím situaci vyřešit.
          2) Pokusím se. Na dálku tohle dělám nerad. Doma jsem si to otestoval a downgrade/migrace na long term prošel OK.

          Při dnešním "výpadku" jsem zjistil, že z monitoring webu "uptimerobot", byla dostupná ipv4 adresa, a ipv6 adresa nebyla. Takže mi to hlásilo výpadek pouze na ipv6.

          Taková perlička. Taky se Vám na ROS při změně komentářů u pppoe rozhraní restartuje to spojení?

              Shodou náhod se mi to stalo opět po 14 dnech dnes ráno. Ale zatím nemám čas to řešit (distanční výuka), tak jsem to zatím přepnul na záložní linku a tunel ponechal "v polofunkčním" stavu. Odpoledne/večer dám vědět, co jsem (snad) zjistil 😀.

              Nicméně ještě teď jsem si "ověřil" to, co píše liquidcz že při tomto stavu ping na veřejnou IPv4 adresu z některých sítí projde (např. mobilní data Vodafone) a z některých ne (místní WISP).... přiznám se, toto mě poprvé vyzkoušet nenapadlo 😀, takže díky liquidcz za, pro mne nový, poznatek 😉

                  liquidcz: Pokud Pardubice, tak na to bez dalšího otevři ticket s providerem, ať je to kdokoli. Přilož tam ten popis co jsi doposud nasbíral, jednak aby bylo jasné že nechceš radit restart routeru, jednak aby se to co nejdříve dostalo na CETIN. Přiložením exportu konfigurace (s hide-sensitive parametrem) nic nepokazíš. (Ne že by byla důležitá, ale urychlí to doputování problému na správný stůl).

                  @nosek_tomas2004 : Opatři si i traceroute z mikrotiku na nix.cz a potom na default gw pppoe tunelu. A moc prosím tu limitní velikost paketu. (I když poznatek že z některých sítí ano, z některých ne je pro mne nový. O to důležitejší je znát limitní velikost paketu (i na IPv6), tím se vyloučí jedna varianta, třeba ty pakety žere ještě něco jiného než žrávalo ty moje).

                  IPv6 vs IPv4 bych vysvětlit dokázal, různé sítě na IPv4 už ne. Budu nad tím přemýšlet. Co říká traceroute (oběma směry)?

                  Restart PPPoE při změne komentáře - ano, to mne také zlobí. Píšu si tam CaseID, které se mnohdy dozvím až při zřízení linky, a kazí mi to potom uptimy.

                  Downgrade na longterm není důvod se bát (pokud to není hAP lite r1).

                  Restartování je potřeba rodinu odnaučit - standardně není nic stabilnějšího než CETIN VDSL a pokud se přecijen hryzlo, je potřeba to dořešit s CETINem proč, jinak to budou restartovat do smrti. Panický restart akorát znehodnotí možnost diagnostiky a oddálí řešení.

                    Tak jsem z toho docela zmatený 🤨 🤯.

                    Hraniční hodnotu velikosti PINGu na veřejku jsem nenašel ☹️. I na paket o velikost 1400 (odeslaný z mobilních dat Vodafone, bez fragmentace) dostanu odpověď (také o velikosti 1400).

                    Nicméně mě napadlo zkusit ještě něco.
                    Na NTB, připojeným za telefonem na VF datech, jsem si nainstaloval jakýsi generátor paketů. Když jsem jej pustil na mou IP (na port 80) s rychlostí 1 MB/s, tak jsem na PPPoE interface na RX směru viděl tok opravdu něco okolo 9 Mbit/s. Na základě toho jsem si udělal představu jako "směrem dovnitř je cesta v pořádku, ale po cestě ven je někde problém"

                    Z toho mě napadla další věc:
                    Povolil jsem jsi input accept all ve FW. Na NTB na mobilních datech jsem si rozjel Wireshark a zkusil jít na {V.IPv4}:80, kde běží webfig.
                    Ve WireSharku byl vidět HTTP get požadavek, na MikroTikovi bylo vidět, že paket "docestoval". V tuto chvíli to začlo být zajímavé:

                    Na TX směru PPPoE interfacu najednou "vyskočil" datový tok (na chvíli). Z toho usuzuju, že MK odesílal HTML přihlašovací stránky. Nicméně na NTB do Wiresharku nedorazilo ani ň. Po chvíli NTB pokus zopakoval a stejná situace se zopakovala také.

                    Z tohoto usuzuju, že mi něco asi "žere" pakety po cestě ode mě do internetu, vyjma pingů z intenetu dovnitř(což mi hlava úplně nebere 🤔)

                    Ping z vnitřních sítí do internetu, nebo na "Remote Address" jsou vždy bez odezvy....

                    Dneska jsem mluvil s podporou MetroNetu - čekám než se mi ozve technik, takže to zatím v tomto "havarijním" stavu nechávám 😀.

                    Tak nějak jsem ještě zapomněl @jchudoba odespsat na "Active AC Name" - moc se omlouvám 😭. Posílám tedy teď:
                    "Active AC Name: PA77B01OLOMST01".

                    Díky moc všem 🤗😊

                    PS: O tom bugu s commentem jsem taky nevěděl 😁

                    Odvedl jsi kus dobré práce, je radost vidět že tu někdo umí udělat něco víc než blábolit o imaginárních chybách verzí.

                    Pokud jsi nenašel hraniční hodnotu, tak máš malinko jiný problém než jsem původně předpokládal, i když zárodek může být společný (ale to již spekuluji). Navíc AC je Olomouc, tam nedosáhnu.

                    Nicméně paketožravá hypotéza tam zůstává, byť má paketožravý démon jiné chutě. Začíná se mi rýsovat v hlavě teorie, ale není zralá na publikaci. (Dělá to někomu bez Terminátoru, jen s bridge modemem?)

                    Hele Tome když už jsi to takhle rozjel, co si sniffnout drát mezi terminátorem a Mikrotikem? Buď mezito switch s portmirroringem, nebo alespoň tool/packet sniffer. (nebo další mikrotik, dva porty do bridge a na něm tool/packet sniffer) Tím definivně potvrdíš že z MK to odchází OK (což si sice myslím, ale tvrdá data jsou tvrdá data). Tím bys mi jakoukoli pochybnost prokázal že pakety jsou sežrány v Terminátoru nebo CETINu (nebo bys to vyloučil, a potom by to bylo na ticket na support Mikrotiku). Ale pokud to teď máš v tom závadném stavu, zkus alespoň teď ten packetsniffer na stávajícím mikrotiku - zapojovat teď cokoli mezi by znamenalo rozbít závadný stav.

                    Také ten input lze logovat, stejně jako output, tedy můžeš toho pozovat více než jen objem dat.

                      jchudoba Doma, v jiné lokalitě než Pardubicko (PA77B01PRAHKZ0), mám také vdsl jako záložní linku, jiný ISP, bez terminatoru, stařičký modem Comtrend první verze v bridge modu, za tím opět Mikrotik, tentokráte bez definice vlan, pouze pppoe, ROS 6.48.2, nyní long term 6.47.9 ;-) , měsíce a měsíce stabilní, bez problémů.

                          No jo, Praha je Praha. Půl roku není problém.
                          https://imgur.com/a/afBVqg2

                          Pravda je že paketožravý démon když řádil v Brně tak to bylo na non-Terminátor linkách. (Ale přesně od doby kdy se v lokalitách zaváděl bonding, což tehdy nebylo nepodstatné). Ty a Tom máte velmi podobný (v malých detailech ovšem jiný) problém, ale na bondingu. Hmhm. Kdybych teď chtěl vypouštět laciné nepromyšlené výkřiky jako nejmenovaní matadoři, řekl bych že bonding za určitých okolností rozbíjí pořadí nebo obsah paketů a pak jsou rozbité (a že je třeba downgradovat na single linku (tohle už vůbec neberte nikdo vážně, jen trollím zdejší "matadory s letitou praxí"). Je to syrový blábol po dvou deci, zítra se nad tím zamyslím s čistou hlavou.

                          Vážně - je potřeba dotáhnout tu Tomovu diagnostiku, když to má teď dobře rozehrané i s domluveným technikem. I když i ten technik nejspíše jen poslouží jako odrazový můstek k předání na CETIN-nemám v tuto chvíli jediný důvod myslet si že by to bylo operátorem.

                            jchudoba Upřímně - ani jsem nevěděl, že něco takového (PacketSniffer) v MK je 😄. Tak jsem si o rom přečetl pár řádků na WiKině a zkusil jsem to nastavit 😀. Pokud jsem to udělal blbě, tak mě prosím nekamenujte - studuju první ročník střední školy, takže zjišťuji a učím se neustále nové věci 🤭🤗.

                            Každopádně packet-sniffer jsem hodil na ten PPPoE iface a pak z toho vyfiltroval provoz z/na IP 46.135.91.199, což byla v tu chvíli IP přidělená telefonu na datech. Vylezlo z toho toto:

                            Jestli se tedy nemýlím, tak opravdu pakety z MK odcházejí, ale nedoputují.
                            V této chvíli je to ale packet-sniff na té "problémové" GW 110AHx2. Jak jsi psal, tak se bojím, že pokud bych do cesty 1100AHx2 --- Terminator mrskl další zařízení, tak by mohla "paketožravá mrška" zmizet 😀 a já bych na ní musel s otevřenou náručí čekat další týden, abych jí mohl "zakroutit krkem" 😁.

                            Uvidím, co na to MetroNeťáckej technik. Sice od něj nějaké velké očekávání nemám, ale je to "vstupní krok" právě do řešení s CETINem.

                            Až se rozhodnu tento "závadný stav" zrušit (=restartovat MK), tak zkusím mezi MK GW a Terminátora vložit dalšího MikroTika, abych opravdu ověřil, zda tam ty pakety lítají. Ale momentálně si ještě chci nechat žravého démona na laborování 😁.

                            jchudoba Dělá to někomu bez Terminátoru, jen s bridge modemem?

                            Před tím, než jsem dělal upgrade na 250/25, tak jsem měl též nějakého Comtrenda (tuším VR-3031eu) v bridge (taky bez vlany, jak liquidcz) a vše běželo víceméně jako na drátkách (až na to, že se šíleně hřál).
                            Ještě před tím byl ale v "Router módu" a to byla katastrofa, každej měsíc vythul a musel se restartovat, proto jsem ho pak přepl do bridge - ale to do tohoto válkna nepatří 😉. Upgrade na Terminátora proběhl, neboť ten Comtrend má jenom 100Mbit porty (což se úplně neslučuje s 250tkou přípojkou)

                            jchudoba Ty a Tom máte velmi podobný (v malých detailech ovšem jiný) problém, ale na bondingu.

                            Teď nevím, jestli jsem špatně pochopil větu, nebo došlo k menšímu nedorozumění 😀. Já mám určitě přípojku bez bondingu (výš než na 50 Mbit ani bonding nedělají, ne 🤔?). I na Terminátorovi mi svítí jenom ledka "1", ledka "2" je zdechnutá 😉.

                            Ještě jednou Vám všem (zejména @jchudoba) děkuju za pomoc 😊

                                    Nemám co dodat, máš dobrý plán.

                                    Jen před restartem mikrotiku prosím napřed udělej ten test s mezizařízením doprostřed cesty - tím se sice restartuje pppoe link a démon nejspíš tak jako tak zmizí, ale získáš možnost vysledovat chování před restartem mikrotiku (který na to podle mne nemá vliv, ale takto získáš tvrdá data). Restartovat můžeš potom a chování porovnat, když už vůbec restartovat.

                                    To že máš bonding jsem si vyfabuloval já, moje chyba, příště budu číst pozorněji.

                                    Dej vědět jak bude další posun.

                                      Tak to máte oba linku bez bondingu (@liquidcz to tu nenapsal, ale má jednopárovou linku s terminátorem).

                                      Ano, to jsem nezmínil, problémová přípojka v Pardubicích je NONbonding, jeden link, jeden pár drátů s terminátorem.

                                      jchudoba
                                      Tak člověk míní, bůh mění ☹️.

                                      Včera u nás asi 8* bliknula elektrika (a protože děláme menší rekonstrukci sklepa, tak byl celý rack odpojený od UPSky ☹️).
                                      Takže to ve finále "vynutilo" restart a nyní vše (asi zase jen na chvíli) běží jak má. Nestihnul jsem zkusit tam vložit "meziRB" ještě před restartem.

                                      Zítra tam připojím dalšího MikroTika mezi hlavní RB a Terminátora, ať to můžu (až to znovu nastane) ještě zkusit vysledovat tam.
                                      K tomu bych měl ale ještě menší dotaz - Když dám na tom "meziRB" PacketSniffer na bridge (ve kterém budou všechny fyzické ETH porty), tak na něm uvidím ten provoz toho PPPoE tunelu? Bez toho aniž by to "meziRB" o nějakém PPPoE vůbec vědělo?

                                      Uvažuji tak na základě myšlenky, že i ten tunel se ve finále (asi) skládá z nějakých paketů/rámců, takže bych měl Sniffnout právě ty PPPoE pakety/rámce (ve kterých jsou zabaleny opravdové pakety/rámce) 😀? Je tato úvaha správná?

                                      Díky moc 😊

                                          Můj report.

                                          Situace se zhoršila natolik, že se výpadky začaly pravidelně opakovat každý den ráno mezi 5 a 7 hodinou ráno. A to i přes to, že mám nasazený ROS long term 6.47.9.

                                          Abych kompletně vyloučil chybu na mém zařízení, Mikrotik a jakákoliv verze ROS, nasadím náhradní router, Turris MOX.

                                            iTomB Taky si to myslím, ale potřebuju mít své doměnky potvrzené praktickou zkušeností.

                                                liquidcz tak si dej restart mikrotiku na 4 rano a uvidis ... 😉

                                                  📡 Telekomunikace.cz