Der er altid to sider af en mønt, og i det meste af den tid, jeg har haft æren af at skrive på version2, har jeg fortalt om vores optur, vores succes og alle de ting, vi generelt er lykkes med.
I dag skal det handle om det modsatte - et nedbrud, vi har haft i den forløbne uge, som har trukket tænder ud.
Det trækker op til storm
Det startede, da vores kundeservice en formiddag begyndte at modtage mange opkald fra brugere i et specifikt område i København.
Kunderne klagede over, at de lige pludselig ikke kunne komme på internettet.
Vores overvågningssystem, der pinger samtlige kunder hvert 5. minut og holder øje med kundernes DHCP leases, havde ikke registreret nogen udfald. De kunder, som klagede, svarede på ping, og de havde også en DHCP-lease, hvilket måtte betyde, at der i hvert fald var en eller anden form for hul igennem.
Når vi loggede ind på en fejlramt kundes router og foretog en række tests derfra, kunne vi se, at trafikken tog den helt forkerte vej ud på internettet.
I stedet for at blive routed gennem vores samarbejdspartners netværk og ind til os, blev trafikken sendt direkte ud på internettet gennem samarbejdspartnerens egne peering-links.
Det burde ikke kunne ske, da vores samarbejdspartner kører vores trafik i en separat VRF, som er en virtuel routing-instans.
Det svarer til, at man adskiller et fysisk netværk i to adskilte netværk, som ikke kommunikerer med hinanden, selv om begge netværk anvender det samme fysiske hardware.
Kontrol af samarbejdspartnerens routere viste, at alt så normalt ud - men ikke desto mindre kunne vi konstatere, at trafikken fra kunderne endte i den forkerte VRF.
Konfigurationen så helt korrekt ud, og der var ikke foretaget nogen ændringer, der åbenlyst kunne forklare, hvad der gik galt.
Vi nåede derfor frem til, at der måtte være tale om en softwarefejl i routerens firmware, som fik den til at smide trafikken over i den forkerte VRF.
Det er en kritisk fejl, for de af vores kunder, som ikke har en offentlig IP-adresse, skal routes forbi vores CGN-routere for at komme på internettet - hvis de routes direkte på internettet, vil trafikken blive droppet med det samme, da de IP-adresser, der anvendes til CGN, ikke kan bruges på det offentlige internet.
Damned if you do - damned if you don't
Nu var gode råd dyre - vi kunne vælge at genstarte en specifik router hos vores samarbejdspartner, men det ville gå ud over mange flere end blot de fejlramte kunder, da en af opkoblingerne fra vores samarbejdspartner til TDC ikke er redundant.
Og generelt er en genstart af fysisk hardware den sidste udvej, medmindre man kører Windows.
Vi startede derfor med at genstarte nogle specifikke interfaces - det tager kortere tid, og håbet var, at det ville trigge en ændring i routerens tilstand, så den ville virke korrekt igen.
Det gjorde ingen forskel - og da vi var tæt på middagstid, og de berørte kunder havde været uden internet i en times tid eller to, måtte vi tage den tunge beslutning at genstarte den router, vi mistænkte for at være fejlramt.
Efter genstarten, som tog ca. 15 minutter, måtte vi konstatere, at det kun havde løst problemet for nogle af de berørte kunder, mens andre kunder stadig var ramt.
Nu begyndte det at blive rigtig træls, for at sige det på godt jysk - i alt var det ca. 400 kunder, der var ramt, og selv om vi holdt vores kunder opdaterede om situationen via Facebook, kunne vi mærke, at henvendelserne til kundeservice blev flere og flere.
Og hvad værre var, vi havde ingen løsning på problemet, for alt så korrekt ud i vores samarbejdspartners konfiguration.
Et nødvendigt hack
Når man står over for et uløseligt problem, kan man reagere på mange måder. Man kan blive frustreret, man kan give op, man kan skyde skylden på andre eller på sig selv - men ingen af disse reaktioner får problemet til at gå væk.
Det kan derfor være nødvendigt at improvisere, når man står i situationen.
Mens vi sad i de indledende faser og fejlsøgte, var der en mulig løsning, som begyndte at materialisere sig i mit baghoved.
I november 2016 købte vi et /21-scope af offentlige IP-adresser fra Styrelsen for IT og Læring, som solgte ud af deres IP-adresser, og det scope havde vi endnu ikke taget hul på.
Et /21-scope er 2.048 IP-adresser, og vi havde ca. 400 fejlramte kunder.
Hvis nu vi kunne give hver af disse fejlramte kunder en offentlig IP-adresse, kunne de i det mindste komme på nettet, selv om trafikken ikke blev routed gennem vores eget netværk.
Mens vores samarbejdspartner fortsatte fejlsøgningen på deres netværk, gik vi derfor i gang med at tildele offentlige IP-adresser til de berørte kunder.
Det er ikke en simpel opgave, når man kæmper mod uret og skal være kreativ på kommando - ideelt set skulle det løses med et script, men vi skulle også passe alvorligt på, det ikke gik ud over resten af vores adskillige tusinde kunder, hvis internet virkede fint.
Hvert minut, der bruges på at udtænke en kreativ løsning, kunne have været brugt på at løse opgaven på lavpraktisk maner, og i en krisesituation er man derfor nødt til at prioritere, om man har tid til at løse problemet på smukkeste vis, eller om man skal bruge en mere primitiv, men til gengæld let tilgængelig løsning.
Derfor besluttede jeg mig for at gennemføre opgaven manuelt med en række SQL-kommandoer og en CLI til databasen i vores CRM-system.
Det tog lige knap en time at tildele offentlige IP-adresser, og de fejlramte kunder begyndte lige så stille at komme på igen.
Lidt for stille.
Det viste sig, at vores DHCP-servere stadig uddelte de gamle CGN-adresser til visse af kunderne, og så måtte jeg i gang med at debugge på dem også.
En fejl i synkroniserings-mekanismen mellem vores CRM-system og database-clusteret bag DHCP-serverne havde gjort, at visse kunde-abonnementer var oprettet to gange - og opdateringen af kundens IP-adresse var kun slået igennem på den ene kopi.
Efter en hurtig oprydning i databasen kom resten af kunderne online i løbet af få minutter, og vi kunne begynde at trække vejret normalt igen.
Stilhed efter stormen
Vores samarbejdspartner arbejder lige nu sammen med hardwareproducenten om at finde en permanent løsning på softwareproblemet i den pågældende router.
Vi har en mistanke om, at fejlen skyldes en halv-bagt implementation af et såkaldt BVI-interface, der anvendes som et virtuelt loopback-kabel, men før vi begynder at rykke for meget rundt på netværket, skal vi have konstateret, om der er hold i vores mistanke.
I mellemtiden har jeg dannet nogle konklusioner i vores ende:
- Det er vigtigt at have en proaktiv kommunikation med kunderne, især når der er problemer. Drengene i vores kundeservice gjorde en fremragende indsats med at holde kunderne opdateret, men en automatiseret besked direkte pr. SMS til de berørte kunder havde hjulpet dem meget
- Pingtest af kunders udstyr er ikke nok. Det skal også testes, om de har hul igennem til internettet generelt
- Man må aldrig gå ned på cola
- At kunne skrive hurtigt på et tastatur er generelt guld værd, men er ekstra vigtigt, når man har travlt. Jeg sender en dybfølt tak til Ingrid, som i 6. klasse hev os igennem de ugentlige lektioner i elektronisk tekstbehandling. Det er nok det skolefag, der har haft den bedste ratio mellem tidsforbrug og nytteværdi nogensinde!
Kære læser - har du selv stået midt i et nedbrud, og hvad gjorde du for at holde hovedet koldt og løse problemet - mens chefen stod og rev sig i håret, og kollegerne løb i cirkler?
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
