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

17
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.

Líbí se vám témata, o kterých píši?

Abyste nemuseli kontrolovat, jestli už vyšel nový článek, rád vám ho ihned po zveřejnění pošlu do e-mailu. Každý kontakt, který mi poskytnete, si nechám vždy jen pro sebe.

  1. ja bych jeste pred vymenou routeru zkusil snizit na zacatku IPsec tunelu MTU, je mozne ze IPsecem narostl paket nad ramec MTU nektereho z prvku po ceste, nasledne musel byt na tomto prvku fragmentovan a to prave muze zpusobit zvyseni latence. ale to je jen takove teoreticke IMHO….

    • Dobrý postřeh :).

      Přemýšlel jsem nad tím a říkám si. Kdyby to bylo způsobeno MTU a fragmentací, tak by zpoždění nemělo být podle mne u PINGu. Ten má +-74B a tudíž by se měl vejít skoro všude.

      Jaký je Váš názor?

      • muj nazor je, ze IPsec muze kumulovat vsechny pakety smerujici do tunelu. tz. pokud je mezi uzly tunelu vice nez jen ICMP paket o defaultni velikosti 56+8B, tak je vsechny IPsec uhledne zabali do jednoho baliku, ten jeste nabobtna rezii kterou IPsec ma, a tento zabaleny a zasifrovany paket putuje skrz sit ISP.

        pokud se bavime o laboratornich podminkach, kde skutecne posleme jeden 64B ICMP paket za vterinu, tak tam by se problem objevit skutecne nemel. tady muze hrat roli to, ze provajdr posila ESP a AH pakety jinou (lacinejsi) trasou, nez rodinu TCP/UDP/ICMP.

        nicmene reseni (vymena routeru za posledni mili) nasvedcuje spise tomu ze puvodni router mel problemy poskladat fragmentovane pakety a dost mozna cekal tech 500ms na cast ktera nikdy nedorazila, zatimco novy router je schopen celistvost fragmentovaneho paketu urcit jinak nez tim ze 500ms nic dlasiho nedorazilo.

        ale plati stale to co pisu v prvnim prispevku, je to jen IMHO.

        • To je zajímavý postřeh. Nepřemýšlel jsem nad tím, že by routery kumulovaly packety jdoucí do tunelu. Myslíte, že je to možné/resp. implementované/standardizované? Koukal jsem do https://tools.ietf.org/html/rfc4303#section-2.3 ale tato možnost mi z toho nevyplývá.

          Ještě jsem si vzpomněl, že budu mít nejspíše ty materiály v e-mailu, a taky že jo. Našel jsem ten capture, který jsem Vodafone posílal jako důkaz. Ty IPSec packety měly 134B délku, takže MTU by nemělo hrát problém.

          • jak jsem psal, bylo to jen takove moje imho. paket <800B zcela urcite nebude fragmentovan, pak me uz jen napada, ze stary router tomu ESP nebo AH paketu nerozumel a chybne ho vyhodnotil jako fragmentovany (tehle myslenky se proste nehodlam vzdat :)) a cekal zda nedorazi zbytek – ten cas 500ms je az prilis malo nahodily na to aby to byla jen nahoda.

        • Však v pohodě, já to celé beru jako spolupráci za cílem přijít tomu na kloub. Ještě jsem nad tím přemýšlel a ta myšlenka, že by router čekal na jiný fragment mi přijde nepravděpodobná. Pokud by šlo čistě o ISO OSI L3/4 tak pouze cílový router/zařízení smí dávat fragmentovaný paket dohromady. Žádný jiný router nemůže mít totiž jistotu, že všechny fragmenty půjdou přes něj (data mohou k cíli jít více cestami).

          • s tim se neda nez souhlasit. na druhou stranu existuje mnoho vyrobcu at uz hw nebo sw, kteri si s RFC nelamou halvu (napriklad M$ :)) na stranu prvni cisco mezi ne nepatri…. abych Vas tak trochu parafrazoval:

            ZAVER: pripad stale neni uzavren. ale pro priste muze byt uzitecne pohrat si s MTU – nizka cena a muze prinest zajimave informace.

  2. Před pár lety jsem řešil podobný problém, kdy nefungoval IPSecový tunel do jedné asijské země. Až po odchytání provozu na obou stranách bylo vidět, že IKE provoz nedorazil na druhou stranu. Kolega poslal pomocí Wiresharku (aspoň myslím) odchycené IKE pakety z jiné veřejné IP adresy, kontrola antipoofingu (podvržení IP adres) v síti ISP nebyla zapnuta a firewal v Asii ukázal, že pakety dorazily. Zjevně něco po cestě pakety s IKE zahazovalo. Oba poskytovatelé Internetu říkali, že s tím nemohou nic dělat. Traceroute byl v každém směru jiný. Směr, kde se zahazoval provoz, vedl přes Katar. Podle Wikipedi zde uplatňují cenzuru Internetu, takže možná preventivně zahazují šifrovaný provoz, taková byla pracovní hypotéza. Po několika týdnech tunel začal fungovat, traceroute ukázal, že provoz jde jinudy mimo Katar. Šlo o záložní tunel, takže jeho nefunčnost nebyla tak kritická.

  3. Možná jsem přehlédl, výměna HW byla kus za kus ( stejný typ)? Klidně bych se klonil i k verzi ( já říkám umřel kondík) , že chcíp HW . Mam pár zkušeností třeba se switchema kde „poloumřely“ některé porty. Taky se to blbě hledalo 🙂

    • To jestli to byl stejný model (případně i HW revize) si už bohužel nepamatuji :-/.

      Tou HW závadou (kondíkem) si nejsem jistý – router byl plně stabilní a k problému (latencím) docházelo jen při předávání IPSec packetů a to ještě jen jedním směrem. U HW závady bych neočekával takovou „sofistikovanost“ chyby :), ale člověk nikdy neví.

Napsat komentář