Z pohledu Video On Line (dále jen VOL) by se uplynulý víkend dal nazvat pěkně smolným. Vše začalo již v pátek, kdy se objevily první krátkodobé výpadky na lince k UUNETu, přes kterou je realizována zahraniční konektivita. Na vině byly pravděpodobně výpadky v propojení mezi UUNETem a VOLem. Z hlediska VOLu to znamenalo, že veškerá zahraniční konektivita musela být realizována záložním spojením přes Nextru. Problémy však nepostihly pouze VOL – např. Euroweb musel svoji konektivitu krátkodobě zálohovat přes InWay. Tyto problémy dočasně přetrvávaly ještě v sobotu (pravděpodobně problémy s BGP u UUNETu), neboť výsledkem podobných rychlých změn v routovací politice BGP (route flap) bývá již tradiční problém, tedy dampening. Příkladem budiž výpis BGP ze soboty po obědě:
1 701 702 6706, (suppressed due to dampening)
Dampinfo: penalty 1752,
flapped 8 times in 00:33:43,
reuse in 00:18:20
AS:
1 je BBN 701 UUnet USA 702 UUnet Evropa 6706 VOL
Jde o technologii, která se snaží zabránit rychlým změnám směrování nastavením časových limitů. Výpadky zahraniční konektivity se tedy podařilo v součinosti s Nextrou bez celkem výraznějších problémů zvládnout.
Podstatně větší starosti měl VOL v neděli. Nejprve se dopoledne „zbláznilo“ připojení přes dialup. Termín zbláznilo zde volím záměrně, protože se mi i přes maximální snahu nepodařilo přijít na to, v čem by mohla být chyba a vzhledem k tomu, že VOL s tím měl problémy ještě večer, nejsem pravděpodobně sám. Chyba totiž měla poměrně zajímavý průběh. Nešlo spojení k žádnému jinému českému ISP přes NIX.CZ, a to pouze z dialupu, avšak ani jedním směrem. Spojení se servery u VOLu a přes zahraniční linku fungovalo normálně. Ještě zajímavější však je, že tento problém se vyskytoval opravdu pouze u dialupu a navíc pravděpodobně ne uplně u všech – pevné linky i všechny servery umístěné na páteřní síti VOLu byly normálně dostupné z celého českého Internetu. Jedním z možných vysvětlení by byly problémy se směrovaním BGP způsobené předešlými výpadky zahraniční konektivity. To však neodpovídá tomu, že server www.vol.cz (195.250.155.29) je umístěn ve stejném bloku IP adres (195.250.128.0/19, konkrétně 192.250.128.0–255, což je SERVERSOUTERNETWORK, Praha POP) jako terminálový server pro dialup datelb.vol.cz (195.250.155.7). Rozdíl mezi traceroute je patrný:
traceroute to www.vol.cz (195.250.155.29) 1 Pra-nr21.eunet.cz 0.763 ms 2 pra-nr01.kpnqwest.cz 1.122 ms 3 nixcz.vol.cz 3.183 ms 4 www.vol.cz 2.464 ms
traceroute to datelb.vol.cz (195.250.155.7) 1 Pra-nr21.eunet.cz 0.676 ms 2 pra-nr01.kpnqwest.cz 1.051 ms 3 nixcz.vol.cz 7.229 ms 4 * * *
Problém byl tedy pravděpodobně někde v hlavním směrovači Cisco na páteřní síti. Aby toho však nebylo málo, v neděli začaly také problémy s pevnými linkami. Nejprve měli smůlu zákazníci s pronajatými okruhy Českého Telecomu, později přišla řada i na klienty Aliatelu. Postupně tak nešlo: „modemákům“ spojení se zbytkem českého Internetu a služby uživatelům na pevných linkách obou největších dodavatelů digitálních datových okruhů. Problémy tak postihly většinu zákazníků VOLu.
Postupně se podařilo zjistit, že se problém nachází pravděpodobně někde na ATM. Bohužel sehnat o víkendu technika znalého tohoto protokolu je stále ještě problém a obávám se, že ne pouze u VOLu… Jako dočasné řešení byl přesměrován veškerý provoz na linku k UUNETu, respektive bylo zablokováno spojení do NIX.CZ na úrovni ATM. Možná právě problém s ATM na jednom z routerů Cisco zavinil podivné chování dialupu. Výsledkem změny směrování bylo, že spojení do Čech šlo skrze VOL → UUNET → NIX.CZ:
3 14 ms atm-plzen.vol.cz 4 18 ms ATM9-0-0.401.GW2.PRG1.ALTER.NET 5 90 ms 422.ATM12-0-0.CR1.PRG1.Alter.Net 6 41 ms 411.ATM6-0-0.BR1.PRG1.Alter.Net 7 22 ms NIX.PRG1.ALTER.NET 8 * Request timed out. 9 156 ms nix.ten.cz
V opačném směru pak šlo veškeré spojení výhradně přes zahraniční konektivitu UUNETu, nikoliv přes jeho linku do NIX.CZ. Vše bylo do normálu vráceno pravděpodobně někdy kolem půl sedmé večer v neděli, problémy na dialupu se pak již při směrování přes NIX.CZ po nějakou dobu neprojevovaly. Nárazově však výpadky přetrvávaly i v pozdních večerních hodinách.
Celý VOL tak prožil opravdu perný víkend. O tom, zda spolu všechny problémy nějak souvisejí si nedovolím spekulovat, možná jde pouze o náhodu. Bylo by jich však příliš mnoho najednou. Problémem je také to, že prakticky není možno získat žádné podrobnější informace. O víkendu se na místech ochotných k problémům vyjadřovat nepracuje a technici mají zpravidla plné ruce práce s jejich řešením. Proto všechny výše uvedené informace vycházejí především z pokusů několika zákazníků VOL a jejich komunikace s technickou podporou, nejde tedy o informace ověřené oficiální cestou.
Co se týče technické podpory, ta měla v neděli opravdu na pilno. Proto se není co divit, že spojení s jedním ze tří operátorů občas trvalo trochu déle než by bylo zdrávo. Mně osobně se postupně podařilo spojit se dvěma operátory: první se mi snažil namluvit, že moje problémy s nefungujícím spojením přes NIX.CZ vyřeší nastavení proxy cache serveru, což měl pravdu. Neměl však pravdu v tom, že to vyřeší i problémy s nefungující poštou a ssh. Tyto protokoly se přes standardně nastavenou proxy dostávají opravdu težko… Druhého jsem zaskočil pravděpodobně hned po jeho příchodu na pracoviště, takže ani nevěděl, že nějaké problémy jsou. Postupně se však stačil informovat, takže už mi při dalším volání poskytl některé zajímavé informace. Celkově tak helpdesk působí dobrým dojmem.
ČLÁNKY DO MAILU