ADSL: proč nešlo FTP?

Začnu nejprve zprávou o slevě: na včerejším setkání s novináři zaznělo, že ČTc poskytne jednorázovou slevu ve výši 30 procent z velkoobchodní služby Carrier ADSL, v rámci které se závada projevila nefunkčností protokolu FTP. „Příjemcem“ této slevy budou jednotliví ISP, kteří Telecomu za tuto službu platí – a bude tak na nich, jak tuto slevu přenesou na své koncové zákazníky.

Pro představu, o co a o kolik jde: služba Carrier ADSL pokrývá vše od koncového zákazníka po datovou síť mezi ČTc a příslušným ISP a je zdaleka nejdražší složkou vstupních nákladů. U nejrozšířenější přípojky 192/64 kbps přijde na 980,– Kč na jednoho uživatele a měsíc, takže jednorázová sleva ve výší 30% obnáší 294,– Kč. Pokud bychom vyšli z toho, že se týká cca 1000 přípojek (k 15.4. jich Telecom hlásil „přes 900“), přijde tím Telecom o výnosy v řádu cca 300 000,– Kč.

Sleva by se zřejmě měla týkat jen služby Carrier ADSL Basic, na které jsou postaveny přípojky 192/64 kbps a 320/128 kbps (s overbookingem 1:50). Jak totiž včera zaznělo, závada se týkala jen těchto přípojek (Basic) a nikoli těch, které jsou založeny na službě Carrier ADSL Profi (což jsou přípojky 256/64, 512/128 a 1024/256 kbps s overbookingem 1:20).

Co bylo příčinou závady?

Pokud jde o samotnou příčinu závady, pak zde se potvrdily neoficiální informace které jsem zmiňoval již v článku ze 17. dubna: ke „ztrátě“ protokolu FTP došlo zapnutím režimu CEF (Cisco Express Forwarding) na směrovačích Cisco. Nikoli ovšem na „samostatných“ směrovačích na okraji MPLS sítě, ale na „zabudovaných“ směrovačích uvnitř prvku SSG (Service Selection Gateway).

Pro správné docenění nejprve malá exkurze do způsobu realizace ADSL na straně Českého Telecomu (viz obrázek):

Technologie ADSL, nasazená na jednotlivé místní smyčky, „končí“ na prvcích DSLAM (DSL Access Multiplexor), na obrázku zcela vlevo. Výstupy těchto DSLAM-ů, nacházejících se bezprostředně u jednotlivých místních ústředen, jsou svedeny do menšího počtu lokalit pomocí ATM sítě, skrze kterou vede patřičný počet pevných virtuálních okruhů (ATM PVC). Tyto se sbíhají v tzv. Service Selection Gateway (SSG), kterou si můžeme prozatím představit jako kombinaci ATM switche (umožňuje napojení na ATM síť, na obrázku z levé strany) a směrovače (pro napojení na paketovou síť, na obrázku z pravé strany). Výstup SSG (na obrázku zprava) je napojen pomocí dvou samostatných spojů (uplinků, po jednom pro služby Basic a Profi) na další IP směrovač, označovaný jako PE směrovač (Provider Edge router). Právě mezi SSG a tímto PE směrovačem, přesněji na vstupu/výstupu z SSG, přitom dochází k hlavní části agregace neboli „slévání“ datového toku od většího počtu uživatelů do kapacity sdílené v příslušném agregačním poměru.

Z druhé strany PE směrovače je IP síť vedoucí k jednotlivým ISP a realizovaná pomocí MPLS sítě. Skrz ni jsou vytvořeny virtuální privátní IP sítě (IP VPN) pro jednotlivé providery, umožňující „protáhnout“ adresový prostor providera až k PE směrovači a u přípojek Profi až ke koncovému zákazníkovi (který dostává přiděleny IP adresy z adresového prostoru svého ISP). U přípojek Basic adresový prostor providera „končí“ na SSG, kde dochází k překladu IP adres pomocí mechanismu NAT.

Po této malé exkurzi do způsobu implementace si již můžeme snáze naznačit, kde mělo dojít k chybě. Nebylo to na PE směrovači a za ním, v MPLS síti, jak se mohlo zdát z předchozího článku. Zde CEF (Cisco Express Forwarding) zřejmě nezpůsoboval problémy a byl spuštěn hned od počátku (jako nutný předpoklad k fungování MPLS mezi PE směrovačem a směrovačem na straně ISP).

K chybě došlo na prvku SSG (Service Selection Gateway), kde CEF být zapnut nemusí (a podle dokumentace CISCO je standardně vypnut). Telecom jej však, prý z kapacitních důvodů, musel zapnout, protože směrovač obsažený v SSG již „nestíhal“ (a zapnutím CEF-u fakticky přešel do výkonnějšího režimu přepínání na úrovni síťové vrstvy, neboli tzv. L3 switchingu).

Příčina problémů na SSG zřejmě souvisela i s fungováním mechanismu NAT, protože se měla projevovat pouze u služeb Basic využívávajících NAT a nikoli u služeb na bázi Carrier ADSL Profi, které NAT nepoužívají (pokud má někdo ze čtenářů opačnou zkušenost, tj. že FTP nebylo dostupné ani na přípojkách 256, 512 a 1024, prosím o reakci).

Konkrétní způsob, jakým se závada projevovala, byl identifikován takto: v rámci protokolu FTP navazuje klient řídící spojení se serverem na tzv. dobře známý port 21. Protokol FTP přitom na transportní úrovni využívá spolehlivý a spojovaný protokol TCP, který navazuje svá spojení pomocí poměrně komplikované třífázového „handshake“. Začíná výzvou k synchronizaci pozice v bitovém proudu, zasláním TCP segmentu s nastaveným příznakem SYN. Odpovědí serveru by měla být potvrzující zpráva s nastaveným příznakem ACK – ale právě tato odpověď (po spuštění CEF na SSG) již nepřicházela, což neumožnilo navázat TCP spojení a vedlo k nedostupnosti protokolu FTP.

Tato závada se očividně netýkala navazování TCP spojení na jiné dobře známé porty (např. na port 80, na kterém je dostupný WWW server – zde vše fungovalo).

Příliš dlouhé těhotenství

Na včerejším setkání zástupců Telecomu (a také firmy Cisco) se pochopitelně diskutovalo i o tom, proč odstranění chyby trvalo tak dlouho a proč k ní vůbec došlo – to má Telecom tak nestandardní řešení, že se takto zásadní chyba projevila až jemu?

Odpovědi se nesly v tom duchu, že koncepce zvolená Telecomem je zcela standardní. Na druhé straně zástupci Telecomu připustili, že byla realizováno postupně, ve více časových etapách, kdy se celkové záměry a koncepce měnily. Dnes proto způsobuje určité komplikace vzájemné „sladění“ prvků z různých časových etap.

Dokonce v této souvislosti padlo i výstižné přirovnání k příliš dlouhému těhotenství celé služby ADSL.

       

Co na to firma Cisco?

K chybě se postavila čelem také firma Cisco. Když zjistila, do jakých problémů se dostal Telecom jako její významný zákazník, získalo hledání nápravy nejvyšší prioritu a technici CISCO si prý dokonce postavili malou repliku sítě ČTc, na které problém studovali a hledali řešení. To se posléze podařilo najít a v pátek 25.4. mohlo být konečně použito, díky čemuž FTP v rámci ADSL opět začalo fungovat.

Tuzemské oddělení technické podpory Cisco poskytlo k celému problému toto vyjádření, na základě analýzy zpracované mateřským Technical Assistance Centrem:

Jednalo se o velice specifický a minimálně deterministický softwarový problém NAT (Network Address Translation) v kombinaci s SSG (Service Selection Gateway) a záchytným portálem. Tyto bloky pracují mj. na úrovni TCP toků, a proto speciálním způsobem zacházejí s úvodními segmenty toku (tzv. sestavení toku), přičemž si vzájemně předávají segment ke zpracování na základě konfigurace. Pouze při aplikaci v určitém pořadí se projevila chyba, díky které nebyl aplikován NAT na jeden z úvodních segmentů toku a s následně byl daný IP paket vyfiltrován bezpečnostními filtry TCP/IP sítě.

Chyba se týkala pouze některých portů, pro něž byla použita postižená rutina, např. FTP, RCP a řady dalších. Naopak se netýkala portů použitých v kontextu SSG, např. HTTP a podobně. Po identifikaci problému bylo navrženo funkční náhradní řešení a následně poskytnut opravený kód operačního systému Cisco IOS.