UPC se topí v problémech

Předem upozorňuji, že tento článek je subjektivní. Po vzoru druhé strany se zříkám veškeré odpovědnosti za přímé či nepřímé škody, které tento text může komukoli způsobit. Jsem zákazník a za dodávané služby si platím. Pokud by došlo k výpadku mých plateb, dodavatel by patrně také nebyl vůči tomuto stavu tolerantní – nevidím tedy důvod, proč bych já (jako platící zákazník) k závadám dodavatele tolerantní být měl. Kdyby se se společností UPC dalo normálně komunikovat a neprovolal bych kvůli jejich neschopnosti zcela zbytečně nemálo peněz, asi bych tento text nenapsal a nepublikoval. Tento článek prezentuje pouze mé soukromé názory a není v žádné spojitosti s jakýmikoli komerčními aktivitami jiných subjektů než těch, které jsou v tomto textu doslova zmíněny.

V neděli 20. července spadla UPC síť užívaná pro poskytování internetových služeb, prodávaných pod obchodním jménem Mistral. Výpadek se nekonal nikde na poslední míli, tcpdumpem vidím ARP requesty ostatních uživatelů sítě a dokonce vidím na druhé vrstvě i svoji default gateway (edge router UPC):

# arp -a -n
Address                 HWtype  HWaddress           Flags Mask            Iface
62.24.73.1              ether   00:00:0C:07:AC:67   C     *               eth1

A toto zařízení dokonce reaguje na ping:

# ping 62.24.73.1
PING 62.24.73.1 (62.24.73.1): 56 data bytes
64 bytes from 62.24.73.1: icmp_seq=0 ttl=255 time=8.0 ms
64 bytes from 62.24.73.1: icmp_seq=1 ttl=255 time=9.4 ms
64 bytes from 62.24.73.1: icmp_seq=2 ttl=255 time=8.0 ms
64 bytes from 62.24.73.1: icmp_seq=3 ttl=255 time=23.2 ms
64 bytes from 62.24.73.1: icmp_seq=4 ttl=255 time=9.2 ms
64 bytes from 62.24.73.1: icmp_seq=5 ttl=255 time=9.0 ms
64 bytes from 62.24.73.1: icmp_seq=6 ttl=255 time=9.4 ms




--- 62.24.73.1 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 8.0/10.8/23.2 ms

Ale to je bohužel vše – nic jiného se neděje (výše uvedené zařízení není dostupné už ani pomocí utility traceroute). Komunikace kamkoli jinam mimo síť Mistralu není možná. Jedná se tedy zcela jasně o výpadek páteřní sítě Mistralu a podle níže uvedených informací zcela zjevně o výpadek celé páteřní sítě Mistralu, nebo ještě přesněji: všech zařízení, která obstarávají konektivitu Mistralu se zbytkem světa (tranzit i NIX.CZ).

Mám monitorovací systém, jenž hlídá dostupnost a průchodnost sítí, které spadají do mé kompetence, a tento monitorovací systém mi hlídá i dostupnost mého domácího systému, připojeného právě přes Mistral. Monitorovací systém hlásí začátek výpadku v 20.7. 00:23 CEST a o této skutečnosti mě zpravuje SMSkou.

Ráno nacházím na svém mobilu informaci, že dohledový systém „nevidí“ můj domácí systém (slovo systém bych měl asi rozvést – jedná se o postarší PC s procesorem 486, 8 MB RAM a jádrem 2.0.39, sloužící jako firewall, router a občas také k dalším účelům). Samozřejmě mě nejprve napadá, že se ten starý krám kousnul (ač se to ještě nikdy nestalo), nicméně funguje – mému notebooku dhcpd přidělí adresu a dokonce se na něj dá z vnitřní sítě přihlásit pomocí ssh. Během půl minuty zjišťuji, že chyba asi není u nás a tedy patrně bude vhodné informovat poskytovatele, že cosi nefunguje tak, jak by mělo.

Poprvé volám UPC v 8:58 – automatický odpovídač mi sděluje, že jsem se dovolal mimo provozní dobu (v neděli v UPC fungují až od 10:00) a hodlá mě přesměrovat na záznamník. Se záznamníky se nebavím, zavěšuji. Možná dělám chybu, takový záznamník je často chytřejší, než bývají slečny v call-centrech.

Podruhé volám UPC v 10:34, dostává se mi odpovědi „všichni naši operátoři momentálně hovoří, čekejte prosím“. Čekám déle než jedenáct minut, stále mi jen hraje hudba, zavěšuji (tohle umí totiž i moje tranzistorové rádio a hraje výrazně levněji než za šest korun za minutu, což si účtuje Eurotel za hovor na pevnou linku).

Potřetí volám UPC v 11:23, na hlásce již je nahráno, že pokud volám kvůli poruše v lokalitách Praha a Brno (nikde jinde tuto službu neposkytují, takže mi není jasné, proč jsou tato dvě města explicitně zmíněna), jsem žádán o strpení, protože technici UPC již pracují na odstranění závady.

V 15:10 síť nabíhá a po výpadku dlouhém téměř 15 hodin po dobu deseti minut funguje.

V 15:20 se opět pokládá a v 15:24 znovu na několik hodin nabíhá. Další několikaminutový výpadek nastává kolem 20:38 a další zase v pondělí 21. července v 00:45 a trvá opět mnoho hodin, nicméně jde pouze o výpadek NIX.CZ. Je však velmi zvláštní, že i když vypadlo spojení do NIX.CZ, zjevně nespadly BGP peery s ostatními partnery v NIX.CZ a routery tedy směrují packety pro prefixy oznamované v NIX.CZ tudy a nikoli přes funkční tranzitní konektivitu (že jsem při té příležitosti náhodou našel v jednom případě i problém v routingu, způsobený patrně neaktuálně nastaveným as-path access-listem vůči jednomu z peeringových partnerů na routerech Mistralu, ponechám stranou, to není záležitost k řešení před internetovou veřejností). Zde jsou příklady toho, jak to dopadne, když od peeringových partnerů v NIX.CZ sice prefixy dostáváte, ale jinak vám tam neprocházejí data:

# traceroute 194.50.6.66
traceroute to 194.50.6.66 (194.50.6.66), 30 hops max, 40 byte packets
 1  s2.mistral.cz (62.24.84.2)  9.17 ms  9.892 ms  8.85 ms
 2  * * *
 3  * * *

# traceroute 217.11.224.1
traceroute to 217.11.224.1 (217.11.224.1), 30 hops max, 40 byte packets
 1  s2.mistral.cz (62.24.84.2)  8.785 ms  19.343 ms  9.752 ms
 2  1hopven-fe4-0.dkm.cz (62.24.68.69)  9.104 ms  9.895 ms  8.761 ms
 3  * * *
 4  * * *

V neděli odpoledne procházím diskuse Mistralu a překvapuje mě, že ač uživatelé sítě ve fórech svorně nadávají, co jim síly stačí, z UPC se nikdo nenamáhá ani zde oficiálně informovat o tom, co se děje a jak dlouho bude UPC trvat, než závadu odstraní, a zda byla či nebyla přijata alespoň nějaká provizorní opatření, aby se situace nemohla opakovat.

Tím končí ověřitelné skutečnosti. Položme si (a také UPC) několik otázek na tělo.

Nejprve je třeba se zeptat, jak je možné, že UPC zjistí, že má výpadek, až téměř jedenáct hodin poté, co výpadek nastal (a velmi podobný scénář se zopakuje i další den). Vzhledem k tomu, že se rozlehlými sítěmi postavenými na protokolu IP dost úspěšně živím, vím, že dohled každé produktivní sítě (tj. sítě, do níž jsou připojeni platící zákazníci) je zcela zásadní záležitostí, bez níž si poskytování kvalitních služeb téměř nelze představit (máte pak totiž jednu zásadní výhodu: často stihnete odstranit závadu dříve, než si jí všimne zákazník). Jak je tedy možné, že síť UPC není podrobena nepřetržitému dohledu? UPC tvrdí, že služba Mistral má již přes 20 tisíc zákazníků, tedy i kdyby všichni zákazníci Mistralu platili nejmenší měsíční paušál 1080 korun, jedná se o měsíční obrat minimálně 21.600.000 korun (velmi pravděpodobně je však nejméně o 30 procent vyšší). Ať mi nikdo netvrdí, že takový obrat a při tom poměrně nízké provozní náklady (OPEX), neboť infrastrukturu má UPC z velké většiny svou vlastní (dokonce část své optické sítě nabízí k pronájmu dalším operátorům), brání UPC provozovat nepřetržitý dohled své sítě.

K této otázce se váže i otázka další – a sice proč si UPC neváží svých zákazníků? Jak jinak si lze vysvětlit, že linka technické podpory není nepřetržitá a bezplatná a že doba čekání na této lince je tak vysoká, že pod vidinou obrovského telefonního účtu to volající raději vzdá? I to pochopitelně může být součástí firemní strategie. Kolik operátorů pracuje na technické podpoře? A kolik jich tam pracuje v sobotu nebo v neděli? Jak je možné, že i mnohem menší ISP a telekomunikační společnosti, než je UPC, svoji bezplatnou linku telefonické podpory mají a velký operátor s desítkami tisíc zákazníků si jí dovolit nemůže?

A teď konkrétní dotazy ohledně výpadku – v zařízeních společnosti Cisco Systems, využívajících operační systém IOS a pracujících s IPv4, byla v minulém týdnu nalezena závažná bezpečnostní chyba, která umožňuje zahltit rozhraní směrovače nebo přepínače – ano, postižena jsou i zařízení Cisco Catalyst z řad 2950 a 3550, která sice jsou výrobcem určena pro využití jako desktop switche, avšak Mistral je na své páteřní síti dle informací čerpaných ze schématu této sítě hojně a s oblibou používá. Ale jsou postižena také zařízení řady Cisco 7200 (avšak také 7300, 7400, 7500 a 7600 – a tím soupis postižených typů zařízení ani zdaleka není úplný), která Mistral na své páteřní síti používá též. Nemůže být současný výpadek páteřní sítě způsoben útokem na zařízení v páteřní síti Mistralu s využitím právě této chyby? Pokud tomu tak je, jde o katastrofální selhání správců sítě Mistral (popis chyby je k dispozici zde, a to již od 17. července. Podle mně dostupných informací například CESNET, ale i řada dalších sítí, tuto chybu odstranil již 17. nebo 18. července).

Podle mého názoru je právě tato varianta nejpravděpodobnější a právě opakování výpadků a frekvence tohoto opakování o této skutečnosti svědčí – a scénář řešení poruchy pak může vypadat asi tak, že administrátor se přihlásí po management interface do routeru, zjistí, že tento v podstatě funguje, jak má (CPU load je normální, teplota je normální, množství volné paměti je dostatečné, operační systém se chová normálně), nicméně rozhraní jsou beznadějně zahlcena, učiní celou řadu pokusů o vyřešení problému, z nichž posledním je příkaz reload, který provede restart routeru. Po restartu směrovač naběhne a vše se zdá být v pořádku, administrátor si pogratuluje k úspěšnému vyřešení problému a jde domů. Po několika minutách či hodinách (dle naturelu útočníka) se celá záležitost opakuje. Vzhledem k tomu, že pondělní výpadek je jen výpadek obou připojení UPC do NIX.CZ, lze usuzovat (i když pochopitelně nikoli na 100 procent), že cesta útočníka do sítě UPC vede právě tudy a že se tedy nalézá v adresním prostoru některé ze sítí, které jsou do NIX.CZ připojené (a z toho lze se značnou pravděpodobností dovozovat, že se nalézá na území České republiky, i když do NIX.CZ jsou oznamovány i prefixy některých sítí v celé řadě dalších evropských zemí).

V této domněnce mě dále utvrzují hodnoty uptime na páteřních směrovačích Mistralu, které lze získat ze schématu této sítě, zveřejněného na webových stránkách. Dalším důkazem toho, že problém je vlastně na routerech a nikoli na spoji do NIX.CZ, je to, že ač na úrovni BGP peerů spojení do NIX.CZ v pondělí ráno zjevně fungovalo, žádná nebo téměř žádná další data tudy netekla.

Kromě této výše uvedené možnosti je zde ještě možnost druhá. Mistral nedávno oznámil, že spouští systém registrace MAC adresy zařízení, které bude připojeno na straně zákazníka za kabelovým modemem. Není současný výpadek páteřní sítě Mistralu způsoben zcela exemplárním nezvládnutím implementace systému registrace MAC adres do stávající sítě? Osobně sice tuto možnost nepovažuji za pravděpodobnou, nicméně zcela ji vyloučit nemohu.

Dalším problémem je nejen doba zjištění poruchy, ale také doba od jejího zjištění do jejího odstranění. Technici UPC problém podle toho, co sděluje zákazníkům technická podpora, odstraňovali zhruba šest hodin. Jsou skutečně lidé, kteří spravují síť Mistralu, dostatečně kompetentní?

Dále se ptám: jak je možné, že může dojít k výpadku celé páteřní sítě? UPC snad nestaví svoji síť odolnou proti výpadkům? To je přece úplně stejně důležitý parametr každé významnější síťové infrastruktury, jako je její dohledování, a vědí to i mnohem menší ISP, než je Mistral. Ale stejně jako u implementace dohledu sítě, i u zálohování infrastruktury UPC selhalo.

Předposlední otázka – vyvodí Mistral ze svého katastrofálního selhání nějaké důsledky? Dokáže se do budoucna poučit z vlastních chyb? Budou hnáni viníci tohoto selhání k odpovědnosti? Nebo se bude management UPC snažit celý problém bagatelizovat a zamést pod koberec?

A nakonec otázka poslední – najde se vůbec v UPC někdo, kdo se odváží na tyto otázky odpovědět? Odpovědět nikoli snůškou prázdných marketingových žvástů, ale tak, aby skutečně přiznal, kde se stala chyba, jak se vyřeší, že se již vícekrát nebude opakovat a kdo za tu chybu ponese osobní odpovědnost?

---

Vyjádření společnosti UPC:

Společnost UPC Česká republika, a. s. se omlouvá všem, kteří byli postiženi výpadkem sítě Mistral.

K tomuto výpadku došlo v neděli 20.7. Uživatelé se sice mohli připojit na registrační stránky, nemohli však získat připojení do zahraničí a na peeringová centra NIX.CZ.

Následné šetření stoprocentně vyloučilo problémy s implementací systému registrace síťových karet i bezpečnostní chybu v operačním systému IOS na některých směrovačích společnosti Cisco. Bezpečnostní patche/opravy systému IOS naše společnost implementovala na svých routerech ve čtvrtek 17.7. a v pátek 18.7.2003.

Důvodem nedělního výpadku byly dvě na sobě nezávislé chyby na páteřních směrovačích datové sítě Mistral.

V prvém případě došlo po půlnoci dne 20.7. k hardwarové poruše hlavní směrovací karty na jednom ze dvou hraničních směrovačů. Od 01:00 hodiny ráno již na odstranění poruchy pracovali dva technici společnosti.

Druhá příčina spočívala v nekorektním chování interního směrovacího protokolu uvnitř datové sítě Mistral. Po implementaci nového IOS totiž nedošlo k automatickému přechodu na záložní linky a to jak do zahraničí, tak do peeringových center NIX.CZ.

Celou záležitost řešila naše společnost od nedělního rána ve spolupráci s partnerskou firmou Cisco. Během odpoledne došlo k výměně vadného modulu za nový a bylo zprovozněno záložní zahraniční připojení. Ve večerních hodinách pak znovu došlo ke krátkému výpadku připojení, když byla zprovozňována hlavní linka do zahraničí. Po půlnoci z neděle na pondělí pak směrovací protokol „spadl“ na jednom ze směrovačů znovu. Došlo totiž k přerušení vazby interního routovacího protokolu mezi hraničním routerem a routerem ve vnitřní síti. Nedocházelo tak k propagování jednotlivých sítí a ty pak nebyly následně propagovány přes BGP k ostatním poskytovatelům. K odstranění všech poruch došlo přibližně v 9.45.

Otázka problémů nekorektního chování směrovacího protokolu v novém IOSu je zatím stále analyzována. V této věci doposud nemám k dispozici definitivní stanovisko k příčině selhání.

Zákaznické centrum naší společnosti pracuje v noci a v neděli systémem úsporného režimu, kdy stálá služba vybírá po určitém časovém období vzkazy z hlasové stránky a distribuuje je pohotovostním technikům. Je tomu tak proto, aby společnost držela provozní náklady a s tím související poplatky za službu na co nejpřijatelnější úrovni. Nicméně nedělní výpadek bude analyzován i z hlediska služeb a informovanosti zákazníků a jsem si jist, že v tomto směru dojde k určitým úpravám. Všem, kterým výpadek způsobil problémy, se upřímně jménem společnosti i jménem svým omlouvám.

František Malina
tiskový mluvčí