Ondrej1

V práci mám na Compalu uptime 127 dní, doma to bude dost podobné, v obou případech shozené do bridge. Ve srovnání s předchozím Ubee mě štve spotřeba elektřiny, ale jinak spokojenost.

Tady je to jednodušší, na WAN (nebo ether1 nebo patřičném) rozhraní Mikrotiku nechat DHCP klienta a o víc se o IP adresu nestarat.

Firemní i domácí odpovídají (compal v bridgi, za ním různé Mikrotiky). Zkoušeno vzájemně na sebe, čili v síti Vodafonu jenom přes pár hopů, odpoledne to zkusím odněkud hodně zvenku.

Taky po mnoha letech nová IP.

Speedtest na brněnský Vodafone naměří správně 500/50.

RB4011 je bezpochyby nádherný kousek hardwaru, ale pokud jde jenom o to uroutovat 1Gbit, tak by to ze stáje Mikrotiku měly dávat i RBD52G (hAP ac2) a pokud není potřeba wifi, tak RB750Gr3 (hEX). Oba mi tu routují 500 Mb a dávají to s obrovskou rezervou.

Díky za zprávu, závěr je celkem jasný, pro tenhle use case je Vodafone nepoužitelný. Přiznám se, že já osobně, kdybych měl možnost optiky, tak o DOCSISu vůbec neuvažuji. Tož všecko nélepší s tem pertinaxem.

K původnímu dotazu - určitě není pravda, že to dělají všechny routery/oblasti. Za zbridgeovaným Compalem mám Mikrotik a ten restartuji při jeho každém updatu (minimálně jednou měsíčně) a už několik let se mi IP adresa nezměnila. Ohledně důvodu častých restartů routeru, sice dobře rozumím důvodu tohoto počínání, ale podle mě je to Špatné Řešení. Pokud mám spolehlivý router a spojení vyhnije na straně klienta (v případě IoT téměř jistota), je lepší restartovat jenom to(ta) rozhraní routeru, kde jsou IoTy připojeny a nikoli celý router. Navíc z hlediska (ne)bezpečnosti se stejně doporučuje mít IoT na jednom virtuálním rozhraní a pak je ten restart ještě jednodušší.

Taky mi to volalo, velice špatná angličtina v nějakém call centru, buď podvod, nebo nesmysl. Položit, neřešit.

Sekundového zpoždění u 3-way handshaku při otevírání TCP spojení si ve škole nemá nikdo šanci všimnout. Byl jsem první, kdo na ispforu navrhnul PUMA 6 bug, ale nejsem si tím moc jistý. Zaprvé, to zdržení se projevuje pouze u 3 way handshaku při otevírání TCP spojení (a všechno ostatní je s určitostí nezpožděné), nebo může být i jinde (jenom ho tam nepozorujeme)? V tom prvním případě to totiž na PUMA 6 bug moc nevypadá (v tom druhém ano). Asi by bylo nejlepší nechat všechno (mikrotik, konfiguraci, servery) tak jak je a zkusit to na záložním (neDOCSIS) připojení, optimálně ADSL (a nejlépe od Vodafonu 😀). Pokud problémy vymizí, je to jasné. Při tomhle scénáři (600 spojení) může být až příliš mnoho chyb na příliš mnoha místech. Já jsem to včera otestoval u nás (bílý Compal v bridgi, za ním RouterBOARD 750G r2) dostal jsem se na 700 spojení (většina TCP, něco málo UDP, dle Mikrotiku) a problémy jsem nepozoroval. Každopádně výsledek mě moc zajímá. A pro úplnost dodám odkaz na PUMA 6 bug test: http://www.dslreports.com/tools/puma6 (u nás to máme červené jak muletu, ale nikomu to nevadí.)

Pokud to se starým notebookem fungovalo bez problémů (i na 5 GHz ?) na současném notebooku to bezproblémově funguje po kabelu, tak to poměrně jednoznačně ukazuje na problémový ovladač wifi na novém notebooku. Začal bych tím, že bych popátral po nejnovějším/spolehlivém ovladači, pokračoval pátráním v logu (win11, router i synology) jestli to nedá hint co se děje.

Na firemním účtu mi to dává termín začátek ledna, u domácího mi to píše Změna termínu - převedení vámi využívaných služeb do systému Vodafonu proběhne v jiném termínu. Dáme vám vědět hned, jakmile ho přeplánujeme.

Ještě ke včerejšímu výpadku Facebooku a spol - indukovaně exUPC. Celé odpoledne a večer jsem pracoval jsa připojen přes exUPC a bez jediného zakoktání. Je fakt, že používám Google DNS 8.8.8.8. Vypadá to že: Nasadili jsme náhradní řešení, všechny části naší pevné sítě jsou navzdory přetrvávajícímu masivnímu výpadku Facebooku plně funkční. (z Twitteru Vodafonu) se týká jen přetíženého DNS serveru exUPC. Jednou bylo zase lepší mít googlovský DNS, tak to příště bude naopak 😀.

Jak psali přede mnou, IP adresu vždy dostat přes DHCP, nikdy nenastavovat ručně. Když jsem před pár lety měnil router, tak stačil jeden telefonát na infolinku/techniky, kde jsem jim nadiktoval novou MAC adresu (oni ji navíc viděli, že ano, tak jsme ji jen zverifikovali) a nastavili ji jako novou kanonickou. Klonování MAC adresy bych bral až jako úplně poslední možnost, pokud selže všechno.

U business adres to nefungovalo nikdy, ani za UPC. Teď jsem cvičně zkusil svoji adresu v několika databázích a dostal jsem Prahu (nejčastěji), Plzeň a Ostravu, přičemž jsem ve Zlíně. S tím ale nemá Vodafone (UPC) zas tak moc do činění, to je iniciativa těch společností poskytujících geolokační informace, a zatímco u home přípojek dělají s většími adresními bloky, tak u business jsou buď malinkaté bloky (nebo dokonce jednotlivé adresy ?) a nestojí jim to za tu drbačku. Jak píše @Adolf.Shitler, vzít na vědomí a neřešit. Nebo vyřešit jinak (u mapy.cz zapamatovanou pozicí, nebo linkem, nebo vyhledáváním).

V evidencích je nepořádek odedávna. Měl jsem podobnou situaci před 10+ lety ještě za časů Karnevalu, tam to ale bylo naopak. Ve sklepě mi trčely ze zdi dva zelené koaxiály, ale Karneval tvrdil, že máme doma nainstalované zásuvky. Natěstí se nechali přesvědčit, poslali technika a ten zřídil zásuvku a od té doby pohoda. Využil buch nabídku @Marek-26 a řešil to s ním, má asi nejlepší přístupy do systémů a k technikům, ale souhlas s @tomus, že to vypadá nadějně.

Den je moc, teď jsem něco připisoval do tématu Veřejná IP po 18 hodinách, příspěvky to spojilo a moc smysl to nedává, chtělo by to fakt jak chce @tomus, příspěvek označit nepřečtený a spojovat je jen v řádu několika málo hodin.

Před chvilkou objednáno, slečna na infolince se dušovala, že se nic nezmění. Každopádně do 24 hodin dám vědět, jak to dopadlo. @tomus a @Marek-26 zatím díky. Nedočkavě jsem ráno restartoval modem, výsledek je 500/30 a ip adresa je veřejná, a to dokonce (poměrně logicky) ta původní. (Dynamická, co se už dva roky nezměnila).

Netuší někdo jaký je současný stav? Jsem ještě v systémech UPC, uvažuji, že bych upgradoval na Internet 500 (ať Vodafone vydělá), ale potřebuji bridge a veřejnou dynamickou (chacha) IPv4. Jde to hladce / Jde to, ale dře to / Nejde to vůbec?

Do značné míry podobný příklad jako tady nedávno, až na to, že by měl být podstatně jednodušší k vyřešení, ale tak úplně nebyl. V šest ráno doma nejde internet (UPC domácí tarif), modem hlásí spojení, při zběžné diagnostice to vypadá, že druhý hop (81.27.207.193) zahazuje pakety na Google DNS (8.8.8.8), tím pádem nejde skoro nic. Během vypravování synka do školy není čas na rekonfiguraci sítě, ale zkouším na lince hlásit poruchu. Celkem dle očekávání se mi dostane jenom usual corporate bullshit (resetovat modem, vypojit vlastní router,....). Musím říct, že to jsem i čekal, stejně musím doma končit (čtvrt na osm), pokračování z práce (jenom o ulici vedle). Beru si servisní notebook, bude asi potřeba. Takže je půl osmé, v práci kolegové, že nejede internet (UPC Business). Přepojuji síť na záložní konektivitu, zmocňuji se modemu připojuji napřímo notebook a pátrám. Vše se zdá být jasné. Něco jde pěkně C:\Users\Ója>tracert -d www.idnes.cz Výpis trasy k c1.idnes.cz [185.17.117.32] s nejvýše 30 směrováními: 1 * * * Vypršel časový limit žádosti. 2 7 ms 7 ms 7 ms 81.27.207.193 3 12 ms 11 ms 13 ms 84.116.221.162 4 19 ms 13 ms 12 ms 84.116.221.166 5 13 ms 11 ms 12 ms 84.116.221.37 6 * * * Vypršel časový limit žádosti. 7 * * * Vypršel časový limit žádosti. 8 14 ms 14 ms 14 ms 31.30.190.10 9 15 ms 13 ms 14 ms 194.228.21.245 10 12 ms 19 ms 28 ms 90.181.223.142 11 13 ms 13 ms 12 ms 185.17.117.32 Trasování bylo dokončeno. něco vůbec (Google DNS, Cloudflare DNS) C:\Users\Ója>tracert -d dns.google.com Výpis trasy k dns.google.com [8.8.8.8] s nejvýše 30 směrováními: 1 * * * Vypršel časový limit žádosti. 2 7 ms 7 ms 6 ms 81.27.207.193 3 * * * Vypršel časový limit žádosti. 4 * * * Vypršel časový limit žádosti. 5 * * * Vypršel časový limit žádosti. 6 * * * Vypršel časový limit žádosti. 7 * * * Vypršel časový limit žádosti. 8 * * * Vypršel časový limit žádosti. 9 * * * Vypršel časový limit žádosti. 10 * * * Vypršel časový limit žádosti. 11 * * * Vypršel časový limit žádosti. 12 * * * Vypršel časový limit žádosti. 13 * * * Vypršel časový limit žádosti. 14 * * * Vypršel časový limit žádosti. 15 * * * Vypršel časový limit žádosti. 16 * * * Vypršel časový limit žádosti. 17 * * * Vypršel časový limit žádosti. 18 * * * Vypršel časový limit žádosti. 19 * * * Vypršel časový limit žádosti. 20 * * * Vypršel časový limit žádosti. 21 * * * Vypršel časový limit žádosti. 22 * * * Vypršel časový limit žádosti. 23 * * * Vypršel časový limit žádosti. 24 * * * Vypršel časový limit žádosti. 25 * * * Vypršel časový limit žádosti. 26 * * * Vypršel časový limit žádosti. 27 * * * Vypršel časový limit žádosti. 28 * * * Vypršel časový limit žádosti. 29 * * * Vypršel časový limit žádosti. 30 * * * Vypršel časový limit žádosti. Trasování bylo dokončeno. každopádně se to ztrácí ještě u Vodafonu. Volám na business linku (díky Adolfovi za potvrzení čísla), za UPC by to byla brnkačka, jak se ukazuje, nikoli za Vodafonu. Za prvé, na spojení s operátorem čekám dvacet minut, nepamatuji si, že bych za UPC na business lince čekal. No konečně, projdeme si ověřovacím kolečkem a snažím se vysvětlit problém. No moc to nejde, operátor netuší rozdíl mezi traceroute a ping, tvrdí mi, že někdy DNS ping blokují (ano, ale nikoli Google). Nakonec ale operátor někam volá (haleluja) a potvrzuje, že podobný problém už mají hlášený (haleluja), ale že by technici potřebovali seznam webů, které nejdou (WTF?). OK, tak nějaké vymyslím, ale podle mě nic loženějšího, než jsou dva výpisy výše není. Po chvíli (v cca 9 hodin) mi volají a problém se zdá být vyřešen. Sice se chvíli dohadujeme, komu patří který uzel, ale ve výsledku to po třech hodinách jede. Přiznám se, že jsem z celé akce značně rozpačitý hned z několika důvodů Nepamatuji špatné routování za UPC. Teď tu máme v krátkosti druhý případ. A tenhle je podle mě ložený. Business linka nefunguje. Dvacet minut čekání je moc i na rezidenční linku, natož na business. Domluvit se na business lince není jednoduché, dříve bývalo, protože za UPC člověka z business linky přepojili na někoho, kdo tomu rozuměl a s ním to vyřešil Kvůli nekomunikaci se problém na pět minut řešil tři hodiny Dá se s tím něco dělat, nebo je Vodafone totálně korporátně ztracen?

Podobné chování jsem zažil u jednoho mírně historického Mikrotiku. Na 240 jel naplno, když nás přepli na 350, tak jsem se nedostal ani na 150, přičemž procesor nevykazoval extrémní zátěž, což bylo nejzvláštnější. Pomohlo začít fasttrackovat/fastpathovat, v tu chvíli se to rozjelo naplno. Čili ano, nezvládala to odbavit standardní sběrnice (respektive standardní zpracování paketů).

Teď jsem to zkoušel a je to OK: Úplně optimální není konektivita zahraniční (Visual Studio portál), ale i tam to jede přes 100 Mbps.

Před pár lety jsme řešili totéž, při rekonstrukci baráku se řemeslníkům podařilo zlikvidovat zásuvku. Co si vybavuji a) věděli jsme, kde končí koax UPC a rozhodně je to jednodušší. b) technik věděl z objednávky, že bude instalovat zásuvku a bez problémů to čistě udělal, včetně nutného vrtání. Myslím, že se za to něco platilo, ale ve srovnání s náklady na rekonstrukci to byly drobné (stokoruny?), tak to nikdo z nás neřešil.

Mám obojí, domácí na rodné číslo a spravuji připojení v malé firmě (10 lidí), shodou okolností jsou obě místa asi 50 metrů od sebe. Souhlas s předřečníky, SLA je dost o ničem, zálohování připojení jinými prostředky je víceméně nutnost. Za časů UPC mívaly byznys tarify ještě jednu podstatnou výhodu – vlastní zákaznickou linku. Na ní se nečekalo a celkem ochotně přepojovali na techniky. Když byl problém s internetem doma, tak se vyplatilo skočit do práce a pokud byl problém i tam, tak volat byznys zákaznickou linku. Vlastní zákaznickou linku máme sice pořád, ale její úroveň šla někam na úroveň běžné zákaznické linky za časů UPC (stalo se mi, že jsem musel čekat, dokonce jsem se nedovolal).

Teď jsem měl půlhodinový výpadek "internetu". Místní připojení v porádku, ale nešlo se dostat na DNS server googlu (8.8.8.8), podle traceroutu to nejdřív vracel 84.116.138.145 (cz-prg02b-ri1-ae-18-0.aorta.net), pak se situace trochu vylepšila a zahazoval to až 108.170.245.50. Po více než půlhodině se to rozjelo, a to na dvou místech připojených exUPC. V danou chvíli se nešlo dovolat ani na business linku, přepojovali na operátora, ale hrála pořád hudba. Někdo má podobnou zkušenost? Zatím si odpovím sám, na downdetectoru je toho v onu hodinu (18 - 19) poměrně hodně, třeba se něco dozvíme.