Problém s PPPoE - "rozpojování"/"poloprůchodnost"
- Upraveno
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.
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.
- Upraveno
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...
- Upraveno
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.)
- 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