Når man har drevet en ISP gennem et stykke tid, begynder man at få en fornemmelse af, hvilke fejl der udløser hvilke symptomer. Oftest klager en kunde over lav hastighed eller ustabil forbindelse, og fejlene kan deles op i følgende grupper:
- Fejl på kundens eget udstyr (computer, wifi m.v.)
- Fejl på internetforbindelsen
- Fejl i vores netværk eller hos vores peers
Den sidste kategori er sjælden, da de fejl, der opstår, som regel løser sig selv uden vores indgriben - fx brød Telias backbone ned forleden og skabte store dønninger overalt på internettet, men Telia fik løst problemerne i løbet af relativt kort tid, og vi kunne fra vores side blot se til og glæde os over, at det ikke var os, der havde sat verden i brand.
Fejl på internetforbindelsen skyldes for DSL-forbindelser oftest et dårligt telefonstik eller et beskadiget kabel, og set fra vores side er løsningen at sende en TDC-tekniker ud, der retter fejlen.
Fejl på kundens eget udstyr er modsat de andre fejltyper svære for os at debugge, og selv om vi i teorien burde være ligeglade, da det ikke er vores ansvarsområde, giver vi det som regel adskillige forsøg, dels for at give kunden en god oplevelse, men også for at udelukke, at fejlen ligger inden for vores område.
Fejlfinding, runde 1
Forleden havde vi en interessant sag, hvor en lille fejl hos en virksomhed havde generet direktøren gennem længere tid. Sagen havde givet grå hår hos virksomhedens eksterne IT-mand, der spurgte os, om vi kunne hjælpe.
Efter en kort samtale med direktøren besluttede jeg mig for at tage ud og se giraffen. Hans problem var, at han med jævne mellemrum oplevede, at hans browser frøs, når han gik på nettet, og nogle gange ville det resultere i, at den pågældende side ikke kunne vises, mens det andre gange ville betyde, at siden først blev vist efter et halvt eller et helt minut.
Jeg var imponeret over hans tålmodighed - selv havde jeg nok ligget og bidt i gulvtæppet efter flere måneders problemer af den slags, men han var helt rolig, mens han viste mig nogle eksempler på sider, hvor han ofte så problemer:
- bold.dk
- youtube.com
- tinglysning.dk
En ting, jeg bed mærke i, var, at der ofte var noget, der så forkert ud på de pågældende sider. Der manglede et banner hist og pist, og der var røde krydser i stedet. Problemet så ud til at være en smule værre i Internet Explorer end i Chrome, men der var helt sikkert et problem begge steder.
En test på bold.dk uden adblocker viste i øvrigt, at man skal lede længe efter en ligeså reklame- og tracking-befængt side: Det væltede ind med forbindelser, når jeg kørte en wireshark-trace på PC'en, og jeg begyndte at mistænke, at der kunne være et problem med et højere antal samtidige forbindelser.
En well-behaved browser vil som udgangspunkt kun oprette to forbindelser til samme server, men hvis en side som bold.dk har content, der hentes fra mange forskellige eksterne sites, er det naturligt, at browseren opretter mange samtidige forbindelser for at hente siden hurtigere. En sløv router hos kunden kunne muligvis være årsagen.
Jeg udførte standard-testen med det samme: Af med kundens egen router og på med min egen PC. Ingen problemer - så problemet lå med stor sandsynlighed i kundens eget netværk. Kundens firewall var en ældre sag, en gammel Juniper Netscreen 5GT, og jeg blev enig med kundens IT-mand om, at de nok burde skifte denne.
Fejlfinding, runde 2
Et par dage efter blev jeg ringet op igen. Firewall'en var skiftet, og fejlen var der stadig.
Så måtte jeg ud til kunden igen og grave lidt dybere ned i problemet - og efter at have testet med min egen PC direkte på forbindelsen, var konklusionen den samme: Der måtte være et eller andet galt på deres interne netværk, der fik direktørens browser til at gå i stå.
Jeg kom i tanke om, at jeg havde lagt mærke til de manglende reklame-bannere sidste gang, og jeg besluttede mig for at dykke lidt ned i dette. Der var bare et problem - tinglysning.dk var også ramt af problemet, og de måtte alt andet lige forventes ikke at køre med reklamer.
Indsigten ramte mig som et lyn, og koldsveden sprang frem på panden, mens jeg tænkte tanken til ende: Fællesnævneren for alle disse sites kunne være allestedsnærværende Google, der overvåger os alle sammen, om vi vil det eller ej.
Frem med browseren, og ind på tinglysning.dk. Ingen fejl - reloadede et par gange uden problemer, og pludselig var den der igen: Siden stod og hang, og der gik små 5 sekunder, før den endelig kom frem.
Frem med Inspect-tab'en i Chrome, og lad os se hvad der sker:
Aha! csi.gstatic.com var unreachable. Altså VAR det Google, der var fællesnævneren her.
Jeg blev helt nervøs - havde vi sat noget forkert op i vores peering, så Googles tracking ikke kunne nås fra vores netværk? Det kunne jo næsten betegnes som en service over for kunderne, men ikke hvis resultatet var timeouts og sløve websites.
Men hvorfor var der kun tale om en periodisk fejl? Nogle gange virkede det fint, andre gange gjorde det ikke. Well, lad os se hvad der sker:
Alt så jo fint ud - eller hov, vent lidt, der var jo faktisk noget, der så lidt spøjst ud. Nogle af adresserne skiller sig ud og minder lidt om noget, vi har set før:
Når adresserne ser bekendt ud, er det fordi der findes et privat adresserum, der ligger meget tæt på, nemlig 172.16.0.0/12. Kunne der være en ledetråd her? Lad os prøve at se, om vi kan nå adresserne:
Aha - så pakkerne til disse adresser bliver routed til en anden router på netværket, hvorfra de ikke kommer videre. Nu vidste jeg, hvad der var galt: Nogen havde lavet en fejl i route-tabellen på virksomhedens firewall.
Ind i firewall'en og tag et kig på route-tabellen - og ganske rigtigt, der var en route til et internt produktions-netværk, der var sat forkert op:
Jeg rettede routen til det rigtige:
Nu virkede alt som det skulle - direktøren kunne igen komme på nettet, og Google kunne atter tracke alle hans bevægelser.
Hvad kan vi lære af denne historie?
I dette tilfælde var det en simpel tastefejl, der var blevet overført fra den gamle firewall til den nye, uden at den pågældende IT-mand havde lagt mærke til den. Resultatet var, at en mindre portion af det offentlige internet blev routed til et privat subnet i stedet for internetudbyderen. Tilfældigvis blev lige netop den del af internettet anvendt af Google til tracking på mange forskellige websites.
Problemet blev forstærket af, at Google kører round robin på deres DNS records. Det var således tæt på at være en Heisenbug, som kan være forbistret svær at finde, medmindre man går metodisk til værks.
Samtidig var fejlsøgningen i første omgang blevet koncentreret omkring direktørens egen computer, indtil man opdagede, at resten af medarbejderne slet ikke brugte den lokale internetforbindelse, men i stedet gik på internettet via en ekstern terminalserver.
Hvis vi skal opsummere erfaringerne til nogle brugbare punkter, der kan bruges i en anden fejlsøgning, kan de se sådan ud:
- Få et holistisk overblik over problemerne - hvad er det, kunden oplever, og kan fejlen genskabes, så vi udelukker personlig bias?
- Tag den tid, der skal til, når man de-briefer kunden - ikke ulig en politiafhøring kan vigtige detaljer gå tabt, hvis man forcerer den
- Lad være med at antage, at hardware er defekt pga. alder, hvis det ikke virker - forsøg at analysere problemet til bunds
Vi kan kalde dem bud nummer 1, 2 og 3 i IT-mandens ERFA-bibel.
Er der andre bud, vi skal have med?
...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.
