Jak jsme pomáhali Vodafone: řešení problému (část 2/2)

Druhá část našeho příběhu s Vodafonem, který jsem rozvyprávěl ve článku „Jak jsme pomáhali Vodafone: diagnostika problému (část 1/2)“. Již víme, že problém je na straně Vodafone. Bohužel se jedná o klasickou korporaci a z mých zkušeností jsou takováto vyjednávání problém.

Prokletí korporátu

Volal jsem na ISP a problém jim vysvětlil (resp. snažil jsem se o to). Popsal jsem, co vše jsme již vyloučili a že problém bude u nich. Pán na podpoře mi poděkoval a řekl, že vše zařídí. Byl jsem příjemně překvapen, jak to šlo hladce.

Jelikož má zákazník vysoké SLA, dojel do pár hodin k zákazníkovi technik subdodavatele ISP (subdodavatel poskytující bezdrátovou last mile) a proměřil linku. Během proměřování primární linky byl zákazník přepojen na záložní linku. Shodou náhod vše přes záložní spoj fungovalo (což jen potvrzuje, že je problém na straně ISP).

Další den nám přišla informace od ISP, že linka byla proměřena a vše je v pořádku … tedy alespoň pro ně – zákazníkovi stále IPSec VPN nešlo.

Udělal jsem další telefonát na ISP:

• Já: „…chci vědět, co technik proměřoval“
• ISP: „… běžné parametry linky …“
• Já: „My ale nemáme běžné problémy s linkou. My máme problémy s latencí u IPSec provozu. Nikdy jsem neřekl že má linka výpadky.“
• ISP: „Dobře, pošleme tam technika ještě jednou.“
• Já: „Děkuji. Prosím, vysvětlete mu, že máme problémy s IPSec latencemi. Vše ostatní je na lince v pořádku.“

O tři hodiny později:

• Technik: „… tak jsem tady, jedu proměřit tu linku.“
• Já: „Dobře, můžete mi prosím jenom pro pořádek říci, co budete měřit.“
• Technik: „… prý máte nějaké problémy s latencí …“
• Já: „My nemáme problémy s běžnou latencí. My máme problémy s latencí IPSec spojení. Řekli Vám to? Můžete mi říct, jak to budete proměřovat?“
• Technik: „To mi nikdo neřekl. Já mám jen změřit základní parametry linky.“

Následovala ještě další zbytečná návštěva technika. Hodiny telefonátů na ISP, debata s techniky na všech pozicích, kontrola jejich routerů a infrastruktury. Nezúčastněným to může připadat jako veselá historka „boje s větrnými mlýny“. Bohužel se to již táhlo přes dva týdny a zákazníkovi vznikala finanční škoda.

Až jednoho dne vše eskalovalo telekonferencí: nás, vrcholového vedení zákazníka, vyššího vedení ISP a hlavního technika ISP. ISP se přiznal, že neví, co s tím. Zároveň (kvůli blížícím se Vánocům) má stop na veškeré změny v infrastruktuře. Jelikož jsem čekal, že něco podobného se může stát, měl jsem připravený záložní plán. Záložní plán spočíval v postupu, jak chybu blíže diagnostikovat, aniž by došlo k ohrožení infrastruktury ISP. ISP se náš záložní plán líbil a potvrdil úhradu všech nákladů.

PATRON-IT –  Vodafone 1:0

Asi si říkáte, co jsem měl vymyšleno za technologii.

Zde jsou mé myšlenkové pochody:

• Věděl jsem, že zpoždění vzniká pouze na IPSec provozu.
• Nevěděl jsem však kde přesně.
• Naměřili jsme zpoždění na IPSecu po výměně routeru za jinou značku. Zároveň docházelo ke zpoždění IPSecu při testování tunelu oproti jinému endpointu. Chyba tedy musí být někde na infrastruktuře Vodafonu.
• Kdyby byla latence na veškerém trafficu, mohl bych pomocí tracert doměřit, kde k ní došlo (resp. jak je na trase proložená).
• Kdybych mohl použít tracert, který by měl jako payload IPSec traffic, tak bych mohl přijít na to, kde latence vzniká… takový nástroj jsem však nenašel.
• Řekl jsem si, že bych si ho mohl nějakým způsobem nasimulovat.
• Pak jsem přemýšlel, že by to ale s jakýmkoliv IPSec traficem nemuselo fungovat (chyba by se neprojevila).

Řešení prosté a rychlé:

• Nakonec jsem našel nástroj Ostinato. Ten umožňuje vytvořit si jakékoliv ethernetové pakety a poslat je skrze síťovou kartu.
• Udělal jsem packet capture reálného IPSec provozu zákazníka.
• Zachycené packety jsem upravil: rozkopíroval, upravil L2 (MACs, CRC) a L3 (IP TTL), abych simuloval traceroute.
• Zapojil jsem místo zákazníkových routerů svůj NB a provedl odeslání paketů skrze síťovou kartu a zároveň dělal packet capture, abych viděl, jak chodí ICMP zprávy o jejich expiraci.

Jak velké však bylo mé překvapení, když se ukázalo vše být v pořádku. Patnáct minut jsem tiše seděl a přemýšlel, co jsem mohl udělat špatně. Pak mi však došlo, že ten test byl pouze jednosměrný (tzn. zpoždění IPSec packetů směrem zákazník –> internet. Zpoždění by však mohlo být i opačným směrem. Test jsem tedy zopakoval jiným směrem. Bingo! Zpoždění způsoboval router ISP umístěný přímo u zákazníka. Závěry a důkazy jsme předali ISP. Ten router vyměnil za jiný a vše začalo fungovat.

Bohužel nikdo neví, jaká technologie, nebo chyba způsobila toto divné chování na routeru. Trochu mě to mrzí a stále by mě to zajímalo. Pro nás však bylo nejdůležitější, že zákazník má opět funkční síť.

Závěr

Jak jsem psal již v počátku. Toto byl ten typ problému, který když se objeví, tak můžete začít v kalendáři škrtat dny, kdy nebudete moci dělat nic jiného a jen pracovat na hledání řešení. Přičemž nevíte, jestli jej budete řešit jen pět hodin, nebo sto. Navíc se nedá očekávat, že Vám někdo s problémem zázračně pomůže, jelikož se jedná o problém mimo všechny příručky.