Protokol IPv6 byl na DSL službách T-Mobilu spuštěn v srpnu 2014, tedy přibližně dva roky poté, co IPv6 začal nabízet operátor O2. Oproti O2, které spolu se zavedením IPv6 přestalo nabízet veřejné IPv4 adresy v ceně služby a přidělované bloky IPv6 adres má dynamické a malé, je podoba IPv6 u T-Mobilu jiná: veřejné IPv4 adresy jsou dodnes součástí služby, příděl IPv6 adres je oproti O2 mnohem větší (přesně 256krát) a přidělené adresy obou protokolů jsou de facto statické. I proto je DSL od T-Mobilu oblíbené u technicky zdatnějších uživatelů.
Přeprodávané DSL, základ nabídky
T-Mobile historicky nabízel dva druhy DSL služeb: služby na základě zpřístupnění místní smyčky (LLU) a služby přeprodávaného DSL. Vzhledem k vysokým nákladům na zpřístupnění místní smyčky a rozvoj vlastní ADSL technologie se společnost před několika lety rozhodla převést zákazníky se službou Internet ADSL a Profi ADSL na služby VDSL/ADSL zajišťované kompletně formou přeprodeje produktů O2 (později CETIN). Nyní je tedy přeprodávané DSL od CETIN základem nabídky tarifů Pevný internet (s technologií ADSL/VDSL).
Podpora protokolu IPv6 byla svého času implementována pro přeprodávané ADSL/VDSL i LLU ADSL. Protože však byla služba LLU ADSL postupně opuštěna, vztahují se následující řádky pouze na služby na infrastruktuře CETIN.
Služba přeprodávaného DSL je založena na referenčním modelu velkoobchodní nabídky CETIN, ve kterém službu mezi zákaznickou přípojkou a centrálním předávacím bodem mezi CETIN a ISP (zde T-Mobile) kompletně obsluhuje CETIN. ISP pak přiděluje IPv4 adresy a IPv6 prefixy zákazníkům pomocí RADIUS serveru a standardizovaných RADIUS atributů ( Framed-IP-Address, Framed-IPv6-Prefix, Delegated-IPv6-Prefix). Routery CETIN oznamují agregované IP prefixy routerům T-Mobile a tyto pak směrují IP provoz pro oznamované IP prefixy z/do sítě CETIN.
Referenční propojení sítí ISP a CETIN (zdroj: MMO CETIN)
Integrace GTS a první problémy
K 2. lednu 2015 oficiálně proběhla administrativní fúze, při které byla společnost GTS Czech s.r.o. integrována do T-Mobile Czech Republic a.s. Kromě administrativní fúze ovšem bylo třeba provést i fúze další – kromě jiného i technickou. Jedním z přímých efektů pozdější technické fúze sítě GTS se sítí T-Mobilu bylo i nahrazení části směrovací infrastruktury, která se stará o propojení se sítí CETIN.
Integrace ale pravděpodobně neproběhla úplně hladce. Na začátku roku 2018 jsem si po zřízení nové DSL linky všiml, že z ní nefunguje příkaz traceroute. Místo toho, aby příkaz správně vypisoval routery po cestě na základě odpovědi ICMPv6 Time Exceeded, Hop Limit Exceeded (Type 3, Code 0), kterou routery obvykle odesílají, odpovídal jeden z routerů ( 2001:af0:f::1d8) zprávou ICMP Destination Unreachable, Administratively Prohibited (Type 1, Code 1). To způsobovalo předčasné ukončení příkazu traceroute, ale konektivita na úrovni TCP/UDP byla bezproblémová.
Nekorektní ICMP odpověď od routeru exGTS
Problém po čase zmizel zároveň s přesměrováním provozu přes jiné routery. Ty navenek vystupují pod IPv6 adresami 2001:af0:f::1db a 2001:af0:f::1da a pravděpodobně měly (mají) jinou konfiguraci. Následující obrázek znázorňuje pozorovatelnou topologii a tok paketů mezi DSL sítí a NIX.CZ. (Topologie může být ve skutečnosti mnohem složitější, routery jsou součástí zfúzované MPLS sítě.)
Zjednodušený diagram toku paketů mezi NIX.CZ a hraničním routerem CETIN
Opakované výpadky a dlouhodobá nestabilita
Svou linku jsem poté z několika důvodů převedl k jinému poskytovateli a situaci považoval za vyřešenou. Ovšem jen do doby, než jsem se v půlce března dozvěděl o nepříjemném chování IPv6 konektivity na DSL službách od T-Mobilu.
Po bližším zkoumání jsem zjistil, že provoz po roce stále tekl přes dva výše zmíněné routery, tj. 2001:af0:f::1db a 2001:af0:f::1da. Nyní ovšem tyto routery neodpovídaly na ICMP pakety s nízkým TTL z některých směrů vůbec, v jiném směru jen v intervalu jednou za deset sekund.
Výpadky pohledem RIPE Atlas sondy za DSL přípojkou
Horší byly ale celkové problémy s konektivitou. Přibližně každých pět až deset minut docházelo na jednu až dvě desítky sekund ke kompletní ztrátě IPv6 konektivity z DSL linek.
Na 5 sekund, jo? pic.twitter.com/hUNYKSiTLc
— Liška (@Liska2019) 15. března 2019
Problém podle informací na sociální síti Twitter trvá již několik měsíců:
Mně to bylo poprvé ohlášeno na konci ledna. Dotyčný to řešil s podporou, ta mu nakonec poradila vypnout IPv6. Tak si pořídil UPC s DS-lite a je spokojený.
— Ondřej Caletka (@Oskar456) 17. března 2019
Tak kvůli tomuto už několik měsíců nemůžu dělat z domu do práce přes RDP? Každých pár minut musím zabít okno a spustit novou session...
— Petr Stehlík (@joysfera) 15. března 2019
Ačkoli by bylo možné namítnout, že se uživatel s problémem přímo nesetká, protože výpadky jsou krátké, nebo je odstíní mechanismus Happy Eyeballs v prohlížečích, opak je pravdou. Některé webové stránky se mohou načíst s rozbitým rozložením obsahu, jiné služby se mohou nepříjemně odpojovat nebo zasekávat:
Zítra ráno začnu reklamovat službu, když mi nejede internet (resp. jede, ale vždycky jen na pár sekund), ale jak jim napovědět, aby to u sebe našli? Např. stránky https://t.co/lGcV3FOHln se pravidelně načtou bez CSS. Trkne je to?
— Petr Stehlík (@joysfera) 17. března 2019
Trvá to už relativně dlouho, ale přesný začátek si nevzpomenu. Každopádně příznaky jsou jasné. RDP komunikace se zasekne tak, že musím celý rdesktop killnout a pak znovu spustit. 30x za hodinu a neudělám nic. Spravíš to? :-)
— Petr Stehlík (@joysfera) 15. března 2019
Technická podpora, které byl problém už dříve nahlášen, bohužel zvolila nejhorší možnou variantu – místo hledání skutečné příčiny poradila nejméně jednomu uživateli, aby na své straně IPv6 deaktivoval. Ten nicméně IPv6 potřeboval, a tak problém vyřešil po svém – službu od T-Mobile zrušil a poohlédl se po konkurenci:
Mně to bylo poprvé ohlášeno na konci ledna. Dotyčný to řešil s podporou, ta mu nakonec poradila vypnout IPv6. Tak si pořídil UPC s DS-lite a je spokojený.
— Ondřej Caletka (@Oskar456) 17. března 2019
Po technické stránce se pohledem z DSL přípojky zdá, že je konektivita až po router 2001:af0:f::1db funkční, ale router 2001:af0:f::1da v okamžiku problému přestane odpovídat. Pohledem zvenku router 2001:af0:f::1da neodpovídá nikdy. Router 2001:af0:f::1db odpovídá až do okamžiku výpadku, pak odpovídat přestane, a po obnovení konektivity opět odpovídat začne.
Po hodinách měření a pozorování se nedostupnost DSL přípojek pohybuje na úrovni 5,5 %, tedy přibližně 200 nesouvislých sekund z každé hodiny.
Dvouhodinové měření pomocí My Traceroute
Bez znalosti interní topologie je těžké odhalit přesnou příčinu. Zdá se ale, že v síti T-Mobile dochází buď k občasnému nasměrování provozu cestou, ve které jsou pakety zahozeny, nebo se v MPLS síti ztratí informace o správné cestě mezi předávacími routery CETINu, 2001:af0:f::1da a 2001:af0:f::1db, což má opět za následek zahození paketů. Poté, co se situace uklidní, je provoz nasměrován cestou, která je funkční, a data opět na chvíli tečou.
V některých případech dojde k situaci, kdy je konektivita přes router 2001:af0:f::1db na chvíli zcela ztracena, pak je pravděpodobně přesměrována do sítě CETIN jinou cestou, načež se opět vrátí na svou původní trasu přes router 2001:af0:f::1db.
Následující dva obrázky demonstrují sedmisekundový úplný výpadek (v okamžiku sekvenčního čísla 837 je ještě konektivita funkční), částečné přesměrování provozu (router 2001:1ae9:fff:ff00:9::2 v síti CETIN začne v sekvenčním čísle 844 odpovídat) a následnou obnovu původní trasy (router 2001:af0:f::1db začne v sekvenčním čísle 854 odpovídat). Pro ladění byl využit příkaz ping s úmyslně sníženou hodnotou Hop Limit (TTL), aby bylo vidět, které z míst v síti ještě odpovídá, a které už nikoli.
Test ze zdroje mimo síť TMCZ – odpovědi routeru TMCZ
Test ze zdroje mimo síť TMCZ – odpovědi routeru CETIN
Rozsah problému a jeho řešení
Protože je IPv6 aktivována všem DSL přípojkám T-Mobilu automaticky, využívá ji každý, kdo má kompatibilní router. Podle mých aktuálních dat má tento problém dopad na více než třicet tisíc DSL přípojek s aktivní IPv6 konektivitou – o to podivuhodnější je, že zůstával pár měsíců bez povšimnutí.
T-Mobilu jsem nejprve zaslal detailní technický popis problému přes twitterovou technickou podporu, posléze pak i na novinářský e-mail odešla informace, že chystám článek o uvedeném problému, s prosbou o zodpovězení několika věcných otázek. Twitterová podpora reagovala během dne s informací, že zaslané informace byly předány.
Za tiskové oddělení zareagovala Pavla Hobíková: „Celou situaci v současné době analyzujeme, zjišťujeme další detaily a ve spojení jsme také se společností CETIN.“
Po pěti pracovních dnech od nahlášení byl provoz z DSL sítě přesměrován a dnes je asymetrický – ve směru ze sítě CETIN do Internetu jde přes routery 2001:af0:f::1d9 a 2001:af0:f::1d8, v opačném směru pak přes 2001:af0:f::1da a 2001:af0:f::1db.
O vyjádření, zda je situace již stabilizována, jsem tak opět požádal paní Hobíkovou. Podle aktuálního vyjádření společnost „o věci ví a pracuje na jejím co nejrychlejším vyřešení. Na řešení pracuje s dodavatelem a výrobcem dané technologie.“
Problém tak ještě nejspíš není úplně vyřešen. Z pohledu zákazníků a uživatelů DSL služeb je ale důležité, že okamžikem přesměrování provozu přestalo docházet k opakovaným výpadkům.
Graf Ondřeje Caletky ukazuje, že se problém projevoval přinejmenším od konce října 2018 a nikdo se mu od té doby nevěnoval. IPv6 je tedy, zdá se, stále občanem druhé kategorie.
To je skvělá zpráva, nicméně přetrvává pachuť toho, že takový zásadní problém u existoval už přinejmenším od konce října 2018 a skončil nejspíš až po intenzivním nátlaku od @zajdee (díky, za všechny!)
— Ondřej Caletka (@Oskar456) 23. března 2019
Kdyby se stejný problém objevil s IPv4, bude opraven jistě v řádu hodin. :(pic.twitter.com/jKQD7Aa1SS
Celou situaci tak budeme i nadále sledovat a v případě nových skutečností se k tématu vrátíme.
DISCLAIMER: Autor textu se v letech 2013 až 2014 podílel na zavedení IPv6 na službách T-Mobile ADSL/VDSL.
ČLÁNKY DO MAILU