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

                          nosek_tomas2004 Neptej se a vyzkoušej si to ... je to pět minut práce a i kdyby byla odpověď "ne", znalost jak funguje ten sniffer se ti bude v životě ještě mnohokrát hodit při dalších diagnostikách, ušetří ti to spoustu wiresharků. Nemůžeš na tom prodělat. Čímž nijak neříkám ani že to jde, ani že to nejde-jen tě nechci rozmazlovat informací kterou zvládneš zjistit sám.

                            iTomB Velmi přínosný příspěvek - to říkám od začátku.

                            liquidcz Dotáhni to do konce s providerem. To je jediné systémové řešení.

                                  jchudoba ty tu mas registraci 18 dni a budes tu o necem takovem kecat? 😃 LOOL Pokud by byla chyba v mikrotiku, tak po restartu a stane se to znova, tak je pravdepodobnost, ze je to mikrotik 0,000prd %.

                                    Po týdnu pravidelného zasekávání linky, každé ráno, jsem na sprosťáka předřadil Turris MOX, jen proto, aby pppoe klientem byl jiný systém než mikrotik. A taky proto, že se mi nechtělo celou síť za mikrotikem překonfigurovat (vpn, routing, pravidla, rezervace, DNS...). Výsledkem jsou dvě rána, kdy se spojení nezaseklo a stále jede. Nechám to běžet týden a uvidím zda-li se něco stane, zopakuje se situace.

                                    Pokud bude vše stabilní, zkusím zase nasadit napřímo mikrotik a uvidím, zda-li se situace bude opakovat. Tím budu chtít vyvrátit možnou náhodnou součinnost na straně Cetinu. (...že by si toho někdo všimnul a sám od sebe "to" opravil ve stejný čas jako já vyměnil HW) :-)

                                    Pokud se rozpadání spojení opět vyskytne při zapojení mikrotiku jako pppoe klienta, tak ještě zkusím prohodit mikrotik HW kus za kus. Tím se mi podaří potvrdit nebo vyvrátit, že zakopaný pes je někde v ROS nebo v mojí konfiguraci. I když si myslím, že se na tom nedá nic zkazit tak, aby se mi to spojení takto zasekávalo.

                                    Tak jsem mezi RB1100AHx2 a Terminátora vložil RB800 (která se mi tu válela).....

                                    Dneska jsem se do "onoho" záhadného stavu dostal znovu, takže jsem udělal ještě diagnostiku na tom "mezi RB". O výsledek se potvrdil. Z hlavního MK (ze kterého je vytáčeno PPPoE) pakety odchází. Při "zaseklém" stavu, vidím v PacketSnifferu na RB800 PPPoE jak RX, tak TX provoz.

                                    Ještě jsem udělal jeden "potvrzující" test:

                                    • Přepnul jsem si konektivitu na záložní --> internet funkční.

                                    • Z PC v lokální sítí jsem pustil packet-generator (s malou velikostí) na jednu veřejnou IP (X.X.X.X) (která je úplně mimo infrastrukturu MetroNetu/CETINu) na které mám MikroTik SXT.

                                    • Paket generátor jsem pustil a na tu veřejku X.X.X.X a požadovaný datový tok, který jsem vygeneroval se objevil na fyzickém interface SXTčka. Tím jsem si ověřil, že to generování funguje a je "vidět"

                                    • Nyní jsem přepnul konektivitu zpět na nefunkční VDSL a packet generátor opět pustil. V tuto chvíli to začlo býti trošku zajímavější:

                                    • Požadovaný datový rok směrem VEN (cca 20Mbit/s) jsem viděl jak na PPPoE, tak i na ETH interface hlavní RB1100AHx2

                                    • Tok byl vidět i na tom mezikusu tvořeným RB800 (jak na fyzických iface, tak i ve snifferu). Z toho usuzuji, že pakety ode mne odcházejí. Co s tím dělá Terminátor už ale asi nezjistím. ....

                                    • Každopádně na tom veřejném SXTčku bylo "ticho po pěšině". Přestože od mne to "valilo" 20Mbit/s, tak na vzdáleném SXTčku po nějakém takovém provozu nebylo ani vidu, ani slechu.

                                    Z toho usuzuji že to záhadné "ono/něco", žere pakety, které putují směrem ode mne.

                                    Pokud packet-generátor udělám opačným směrem (možná jsem to už výše popisoval) - tj. z internetu na moji Metronet veřejnou IP, tak i v nefunkčním stavu datový tok ta PPPoE interface dorazí.

                                    Z tohoto zase usuzuji, že cesta ke mě je (zjevně) v pořádku.

                                    Už to mám v řešení s technikem od Metronetu, uvidím(e), jak to dopadne 😀.

                                    Každopádně moc děkuju všem za pomoc, rady, nasměrování a i za naučení některých (pro mne) nových věcí 😊😀

                                      nosek_tomas2004 Super, to zcela vylučuje problém na Mikrotiku (jak jsem ostatně předpokládal, ale sniffnutí komunikace to postavilo najisto). Zkus tedy dotáhnout toho Metronet technika, předpokládám že takto sesbírané podklady mu nedovolí to zamést pod koberec. Rozhodně dej vědět jak jsi dopadl-i kdyby to neklaplo s Metronetem, stálo by za to to sepsat a poslat na CETIN rovnou.

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

                                          jchudoba Tohle lze vyloučit, resp. potvrdit velmi jednoduše: na přípojku kde se to děje zkušebně nasadit router od jiného výrobce. To by snad neměl být takový problém, ne?

                                            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.

                                              📡 Telekomunikace.cz