Hvordan trivielle data i store mængder kan give ny indsigt

Hvad er det egentlig vi går og roder med i netværksafdelingen hos en ISP? Det kan være svært at forklare for de uindviede. En bygningsingeniør kan pege og sige “den bro”, men det er noget mere ‘fluffy’ når man dimser med data. Når folk spørger hvad jeg laver, plejer jeg derfor at bruge den lette forklaring: “Jeg sikrer at Danskerne kan streame pr0n, uden at det hakker!”.

Stabilitet er derfor en vigtig parameter, og som jeg har beskrevet tidligere så er netop stabilitet en udfordring når vi snakker internet over telefonkabler. Men last-mile er kun en lille del af det samlede billede: Selv en perfekt DSL, COAX eller fiber linje kan jo også rammes af større fejl i netværket. Kabler graves over, switche, etc. på centralerne brænder sammen, XFP’er fejler, softwarenedbrud opstår i core-routere og BRAS, og hvad der ellers regelmæssigt sker af sjove ting og sager i ethvert netværk.

Vi arbejder professionelt og derfor har vi naturligvis etableret overvågning af vores netværkselementer. F.eks. hvis en fiber graves over vil tabet af link på de pågældende fiber porte resultere i en alarm, og vi har en vagtordning så der kan reageres døgnet rundt, året rundt.

Vi har i Fullrate i omegnen af 500 aktive fiberporte der binder vores corenet og centraler sammen i Danmark. Nogle netværkselementer har hundreder af kunder under sig. Andre har titusindevis af kunder.

Men hvordan vurderer man omfanget af et nedbrud? Hvor mange og hvilke kunder er berørt? Dette spørgsmål skal besvares, og det er vigtigt at få besvaret absolut hurtigst muligt. Grunden til dette er flerfold: For det første er det vigtigt at vi har en retvisende og prompte opdatering af vores driftinformation, så de berørte kunder kan få bedst mulig indsigt i hvad der foregår.

Dernæst, når et område er omfattet af et større nedbrud er det vigtigt at supporterne ved dette hurtigst muligt, så når en kunde fra det pågældende område ringer, så ved supporteren allerede at denne kunde sandsynligvis er omfattet af det pågældende problem. Derved sparer vi tid og minimerer f.eks. unødvendige ombytninger af udstyr.

Men hvordan kan man vide hvilke kunder der er berørt af f.eks. en linkfejl et sted i core-nettet? Vel at mærke på en hurtig, nem og intuitiv måde?

Hvis nu min telefon ringer klokken lort om natten og jeg i en kæmpebrandert skal overskue omfanget at et link-down event på mr1-ar,xe-5/3/0, hvordan gør jeg så lige det?

Det krævede normalt et indgående kendskab til netværkstopologien, og en søgen rundt i diverse databaser at besvare et spørgsmål som “Er en kunde i Høsterkøb en del af Birkerød eller Hørsholm central?” Og hvad nu hvis det er en stakkels supporter, som kun har været i biksen i 4 måneder der lige skal finde ud af det i en håndevending med en sur kunde i røret?

Til det har vi udviklet et værktøj vi kalder CPEmap, som i realtime viser online status for samtlige routere (pånær nogle ældre modeller) i vores netværk. Vejen frem til dette værktøj er ret sjov, så den vil jeg lige beskrive for jer. Det er i realiteten en sideeffekt af et andet værktøj som vi udviklede til indsamling af statistikker om link hastighed og kvalitet, samt system-stats for vores routere, CPEmon.

CPEmon består af noget kode som vi deployer ud på den enkelte router. Denne kode vågner regelmæssigt, samler en række informationer ind om hvordan routeren og linket har det og sender dem til en server i vores datacenter og falder så i søvn igen. Denne proaktive tilgang betyder, at vi har historiske data for alle vores routere, hvilket gør det langt nemmere at foretage en korrekt diagnose af et problem – som i mange tilfælde når vi snakker accesslaget er af periodisk/sporadisk natur, og giver os mulighed for at detektere problemer før kunden ringer og klager.

Da CPEmon blev lanceret viste det sig hurtigt at være et værdifuldt værktøj som bl.a. supporterne benytter i hverdagen, med de deraf følgende krav til oppetid og driftsstabilitet. Derfor introducerede vi overvågning af tilstanden for CPEmon på de enkelte routere. Er CPEmon deployet på router X, hvornår så vi sidst data fra CPE Y, osv.

De grafer for deployment status viste sig at være et værdifuldt værktøj for netværksingeniørerne i coreafdelingen, f.eks. ved natarbejde/netværksomlægninger at vurdere om alle kunder er kommet online igen efter en ændring er foretaget. Det foregik traditionelt ved at tilfældigt at udvælge nogle kunder i hvert segment/VLAN og prøve at pinge routerne på de forskellige interfaces. Men det er en manuel process og dermed både tidskrævende og med risiko for at et VLAN glemmes/overses.

Men med en CPEmon deploymentgraf er det særdeles let med et enkelt øjekast, at se om alle de linjer der var online før ændringer er kommet online igen, som I kan se i dette eksempel. Kl. 03.15 foretages ændringen, hvorved omkring 8000 kunder går offline. Kl 05.15 er de alle online igen.

Bemærk, at her benytter vi ikke selve “payload data” fra CPEmon, men metadata om systemet CPEmon’s deployment til at konkludere på tilstanden af netværket.

Det viste sig, at vi på samme måde kunne benytte CPEmon metadata til at vurdere omfanget af et netværksnedbrud. Her er et eksempel, hvor vi oplevede et kortvarigt udfald i BGP (den centrale routningsprotokol i corenetværket). Dette påvirkede omkring 14.000 kunder, og varigheden kan også let fastslås til ca. 30 minutter.

Det var lidt en aha-oplevelse for os, og vi begyndte at lege med data for at se om vi kunne se andre ting. Det blev hurtigt klart for os, at det ville forøge værdien af værktøjet tusindfold, hvis vi kunne forædle data med geografiske informationer.

For eksemplet med BGP udfaldet kan vi så ikke bare se hvor mange kunder der blev ramt, men også hvilke geografiske områder der var berørt (Fyn, Sjælland og Bornholm).

 Alt dette var fint nok, men det krævede en del fiflen rundt med data helt nede i mavsen på systemerne. Det er fint nok når vi nørder i net afdelingen sidder og leger, men det er ikke proaktivt, og det tager tid at foretage en analyse.

“Hvor mange BLEV ramt” er absolut relevant, men det er et spørgsmål til en retrospektiv efter et nedbrud. “Hvor mange ER ramt” er spørgsmålet vi løbende vil have besvaret, og derfor satte vi os for, at udvikle et interaktivt kort som kunne vise disse data i realtime: CPEmap.

Kortet vises på TV skærme i net og supportafdelingerne i Fullrate, og det er meningen at man i hastig forbigang med et enkelt øjekast skal kunne se om der er noget usædvanligt. Derfor er det mørke tema bevidst valgt for at fremhæve den relevante information.

En blå prik er en router som er online, en rød prik er en router der er offline. Få sekunder efter en router går offline vil det kunne ses på kortet.

Her kan I se et eksempel på CPEmap ‘in action’. Øjet drages lynhurtigt mod den røde plamage sydvest for Aalborg.

dk_all

Zoomer vi lidt ind kan vi se at samtlige linjer i Farsø er gået offline:

farsoe_zoom1

Her ses styrken i denne måde at vise data på virkelig! I dette tilfælde er omfanget af udfaldet på ca. 130 linjer. Det er en promille af det samlede antal linjer under CPEmon monitorering, og derfor ville diskrepansen være tæt på umulig at spotte på en graf der blot viser online CPE’er, som f.eks. denne:

Her kan man også se at udsving i antal online CPE’er er helt normalt. Folk slukker deres router, et eller andet støjer og fremprovokerer en reinitialisering af linket, osv. Dette resulterer i et støjgulv, som betyder at ret mange linjer skal gå offline samtidig før det tydeligt kan ses på en en-dimensionel online-graf.

I samme øjeblik vi introducerer en geografisk dimension på data, så springer udfald med så lidt som 20-30 kunder tydeligt i øjnene.

Her er et lidt mere spektakulært eksempel, hvor et en større del af Sjælland kortvarigt flippes i forbindelse med noget planlagt natarbejde.

cpemap_natarbejde

At mappe datapunkterne ned på et kort kan i øvrigt bruges i andre sammenhænge.

Her er et eksempel, hvor hvert datapunkt farves efter om der har været CRC fejl på linket i den foregående måleperiode. Denne timelapse foregår hen over et større tordenvejr der gik over Danmark tilbage i juni.

Det gav 12.245 lyn. De voldsomme elektriske udladninger som lyn består af kan give forstyrrelser på telefonkablerne, og det kan udmønte sig i midlertidige transmissionsfejl på DSL linjerne. 

Hvis der er tale om en direkte lyn-træffer i telefonkablet er du ikke i tvivl: Din router dør en dramatisk død (sammen med de fleste andre elektriske apparater i hjemmet). Det er dog forholdsvist sjældent at det sker, da telefonkablerne er gravet ned. 

Men selv hvis lynnedslaget er langt væk fra telefonkablet, så sker der en kobling af det stærke elektromagnetiske felt til telefonkablerne. Det betyder at en stor overspænding (som sagtens kan være mange tusinde volt) løber ind ad telefonkablet til din router. Routerne har indbygget beskyttelse mod overspænding, og derfor vil det for langt de fleste routere blot betyde at der opstår nogle kortvarige fejl i data, og så kører linjen ellers videre uden problemer. 

Videoen viser tordenvejret, som det blev oplevet af Fullrate’s routere. Røde prikker er routere som har haft mindst et fejlbehæftet sekund i det pågældende tidsinterval. Tidsserien begynder om morgenen, så tordenvejret ser I først i slutningen af videoen. 

Her ser I kortet i drift på en 4k skærm på kontoret:

Her tænker du på “Hvordan trivielle data i store mængder kan give ny indsigt”

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *

This site uses Akismet to reduce spam. Learn how your comment data is processed.