yoel caspersen blog bloghoved

Case study: Fejlfinding på en ustabil forbindelse

Af 20

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.

Illustration: Privatfoto

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:

$ host csi.gstatic.com
csi.gstatic.com has address 216.58.212.131
csi.gstatic.com has address 216.58.212.163
csi.gstatic.com has address 216.58.212.195
csi.gstatic.com has address 216.58.212.227
csi.gstatic.com has address 172.217.18.131
csi.gstatic.com has address 216.58.201.163
csi.gstatic.com has address 216.58.209.99
csi.gstatic.com has address 216.58.209.131
csi.gstatic.com has address 172.217.1.131
csi.gstatic.com has address 216.58.193.131
csi.gstatic.com has address 216.58.217.227
csi.gstatic.com has address 216.58.218.3
csi.gstatic.com has address 172.217.17.227
csi.gstatic.com has address 216.58.201.195
csi.gstatic.com has address 216.58.213.3
csi.gstatic.com has address 216.58.213.35
csi.gstatic.com has IPv6 address 2a00:1450:400e:800::2003

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:

csi.gstatic.com has address 172.217.18.131
csi.gstatic.com has address 172.217.1.131
csi.gstatic.com has address 172.217.17.227

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:

$ traceroute 172.217.17.227
traceroute to 172.217.17.227 (172.217.17.227), 30 hops max, 60 byte packets
 1  192.168.2.1 (192.168.2.1)  4.050 ms     4.072 ms     4.063 ms   
 2  192.168.2.2 (192.168.2.2)  7.095 ms !N  7.083 ms !N  6.024 ms !N

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:

172.0.0.0 255.0.0.0 192.168.2.2

Jeg rettede routen til det rigtige:

172.16.0.0 255.240.0.0 192.168.2.2

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?

Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jn Madsen

I novenber 1986 startede jeg som telefonmand i et større teleselskab.
På teleskolen lærte vi om trinvis fejlretning og skarpe grænseflader at måle på.

Meget vand er løbet gennem åen siden, - PABC'ere, optiske netværk, PDH, SDH og WDM, i de sidste mange år netværk/software udvikling/routere/BGP og IGP'ere/Linux og alt det der.

Som ISP'er er kunsten at være sikker nok til at frikende sit netværk og kunne/turde sige til kunden: "Fejlen er hos dig, ikke hos os".

Ellers drukner man i de elendigheder som kunders netværk er begravet i. Der er meget skrammel der ude.

Nu har du en meget glad kunde, - både han og hans venneskreds vil nu forvente sublim, kyndig og især gratis fejlretning fra din side :-)
Men godt fundet - den fejl. Som nystartet er man nok tilbøjelig til at yde lidt ekstra service.

Yoel Caspersen Blogger

Som ISP'er er kunsten at være sikker nok til at frikende sit netværk og kunne/turde sige til kunden: "Fejlen er hos dig, ikke hos os".

Ellers drukner man i de elendigheder som kunders netværk er begravet i. Der er meget skrammel der ude.

Jeg er meget enig, men det fungerer desværre ikke så godt i disse sociale netværk-tider: En sur kunde fra facebook-generationen, der ikke tror på os, vil skynde sig at råbe sin frustration ud på samtlige medier, han kan få fat i. Hvis vi er rigtig uheldige, er han samtidig en god agitator som får vennerne til at dele hans sure opdateringer.

Så virkeligheden er desværre, at vi må lægge en del gratis arbejde i at hjælpe kunderne, men forhåbentlig giver det pote i sidste ende, når kunden føler sig godt behandlet. De sociale medier er jo et tveægget sværd, når det kommer til den slags, og selv om negative budskaber virker bedre end positive, er tiden ikke spildt, når kunden er glad i sidste ende.

Den pågældende kunde i min historie er nu i øvrigt en yderst rimelig og behagelig person, så når vi hjælper ham er det også for at bevare en god relation til både ham og hans IT-mand.

Jn Madsen

Jammen, vi er rørende enige :-)
Der er så ikke noget ændret i at de sociale medier er så udbredte nu. Sure kunder har altid været en grim ting.

Kunsten er den samme som altid:
At kunne afvise ydeligere fejlretning, fordi man er i stand til meget tydeligt at retfærdiggøre det. At forklare at det simpelthen er umuligt at ISP'en har fejlen.

Så kan man komme med gode råd og ideer,- men man kan af hensyn til firmaets drift være nødt til at afvise at hjælpe mere.
Det er noget med psykologi og at "læse" kunden.
Vi er jo alle lidt nørder, og vi elsker at finde fejlen. Når der er tid til det.

En svendestykke i forklarings-psykologi er at forklare til en (ikke-meget-teknisk) kunde, hvorfor han med et kredsløb på 100mb i Danmark og den anden ende er i Australien, også på 100mb, så får han kun 30-40mb igennem. Og det har været hundedyrt for ham.
Efter nogle stykker af den slags kunder, så har man links og dokumenter klar til at sende kunden. Ellers er det et rent mareridt at forklare til en der har "sund fornuft".
Men lille snak om lysets hastighed, afstande og fordelen ved at kunne skrue på en computers TCP vindues størrelse er altid sjov, især hvis han er stået af ved "lys" :-)

Leif Neland

Engang havde jeg den mystiske fejl at en server kunne nå en betalingsgateway "ude i byen", mens en anden ikke kunne.

Det viste sig at vi havde et /28-netværk, men den ramte server var sat op med netmaske /24.
Så den troede at betalingsgatewayen lå på vores eget netværk, og ikke på den anden side af default gateway.

Uheldigvis lå betalingsgatewayen i en anden /28, i den samme /24.

"Of all the C-classes in the world, she walks into mine."

Yoel Caspersen Blogger

Efter nogle stykker af den slags kunder, så har man links og dokumenter klar til at sende kunden. Ellers er det et rent mareridt at forklare til en der har "sund fornuft".
Men lille snak om lysets hastighed, afstande og fordelen ved at kunne skrue på en computers TCP vindues størrelse er altid sjov, især hvis han er stået af ved "lys" :-)

Bandwidth-delay-product er et klassisk eksempel på en leaky abstraction, hvor fysikkens love stikker deres ækle fjæs op og forstyrrer vores illusion om at verden er blevet mindre på grund af internettet.

Det er mit indtryk, at de fleste ikke-tekniske kunder tror, at internettet er et stort warp-hul, hvor der på magisk vis kan flyde ubegrænset data fra A til B, og at det eneste, det kræver, er at internetudbyderen gider fjerne klemmen på kundens kabel. ;-)

Jeg savner en meget pædagogisk video, der på simpelt dansk kan forklare, at det faktisk er et mindre mirakel, at det overhovedet kan lade sig gøre at kommunikere med nogen på den anden side af jorden i noget nær realtid. Det er lidt vildt at tænke på alle de ting, der kan gå galt - men alligevel ikke gør det, fordi rigtig mange mennesker har tænkt sig rigtig godt om.

Jesper Nielsen

Jeg savner en meget pædagogisk video, der på simpelt dansk kan forklare, at det faktisk er et mindre mirakel, at det overhovedet kan lade sig gøre at kommunikere med nogen på den anden side af jorden i noget nær realtid. Det er lidt vildt at tænke på alle de ting, der kan gå galt - men alligevel ikke gør det, fordi rigtig mange mennesker har tænkt sig rigtig godt om.

Du kan finde en god animator på https://www.upwork.com/o/profiles/browse/c/design-creative/sc/animation/ :)

Manuskript er du så nok nødt til at få lavet her i landet inden.

Bent Jensen

Som ISP'er er kunsten at være sikker nok til at frikende sit netværk og kunne/turde sige til kunden: "Fejlen er hos dig, ikke hos os".


De fleste STØRE IPS og telefonselskaber jeg har kenskab til, laver ifølge dem selv aldrig fejl. Fejlen ligger ALTID, et andet sted. Fra at Postvæsnet har forsinkket pakken, selv om de ikke har modtaget pakken. At det dårlige, gamle, defekte kabel, som altid lige er blevet ram af LYN. (Det er dt sikkert mange gange, og derfor er det så dårligt at hele linje bør skiftes). Til opsætningsfejl som altid ligger ved andre.

Jens Jönsson

Engang havde jeg den mystiske fejl at en server kunne nå en betalingsgateway "ude i byen", mens en anden ikke kunne.

Det viste sig at vi havde et /28-netværk, men den ramte server var sat op med netmaske /24.
Så den troede at betalingsgatewayen lå på vores eget netværk, og ikke på den anden side af default gateway.

Det har jeg oplevet noget tilsvarende af mange gange. F.eks. firmaer der har brugt en eller anden public IP range internt på deres netværk, istedet for RFC1918 adresser.

Bent Jensen

Enig i at sure kunder altid har været en grim ting.


Ja se på Jensens Bøfhus.
Som i forhåbenligt også holder jer fra. Ikke på grund af sagen om navn på en fiskerestaurant. Men fordi deres bøffer er seje, for små og alt fordyre.
Vil anbefale at lægge en 50 oven i, også prøve flammen i stedet for.

Ja, jeg er født vendelbo, vi husker lang tid, eller glemer aldrig. En hævn nydes bedst kold. :-)

Michael T. Jensen

Jeg skulle montere nogle netværksstik i en ny bygning hvor ledningerne allerede var trukket. Det gik ganske glimrende i 13 ud af 16 tilfælde, hvor min netværkstester gav fine resultater. De sidste tre stik var dog helt anderledes: netværkstesteren gav nogle ret forvirrende resultater. Nogle ledere gav intet signal og andre ledere var byttet rundt...

Jeg regnede selvfølgelig med at jeg havde monteret nogle stik forkert og skiftede derfor disse ud. Samme resultat. Herefter monterede jeg andre stik i den anden ende, med lige så nedslående resultat til følge.

Jeg måtte nu konkludere, at der måtte være fejl på kablerne, og vi skiftede et af disse ud. Da vi gjorde det opdagede vi, at elektrikeren (som havde trukket kablerne) havde forlænget tre af netværkskablerne med en kabelsamling inde i en kabelbakke, idet de åbenbart ikke var lange nok... Han havde så bare ikke lige samlet dem rigtigt.

Jeg glemte fuldstændig at sige tak.

Yoel Caspersen Blogger

Da vi gjorde det opdagede vi, at elektrikeren (som havde trukket kablerne) havde forlænget tre af netværkskablerne med en kabelsamling inde i en kabelbakke, idet de åbenbart ikke var lange nok... Han havde så bare ikke lige samlet dem rigtigt.

Du skal nok bare være glad for han ikke daisy-chain'ede alle dine stik og effektivt forvandlede din stjernestruktur til en bus - det havde jo sparet en masse kabel, og det virker jo fint for 230 V strøm :-)

Var de andre 13 andre kabler samlet korrekt - eller passede længden fra starten?

Historien viser, hvor vigtigt det er at teste sine stik, når man har monteret dem. Uden en test, ved man reelt ikke, om de virker som de skal, og en fejl på et PDS-stik kan være svær at finde. Fx kan man koble op til 4 ud af de 8 ledere fra, og der vil stadig være link, hvis det er de rigtige, der sidder tilbage - hastigheden vil bare være reduceret til 100 Mbit/s.

Michael T. Jensen

Du skal nok bare være glad for han ikke daisy-chain'ede alle dine stik og effektivt forvandlede din stjernestruktur til en bus - det havde jo sparet en masse kabel, og det virker jo fint for 230 V strøm :-)


Jeg synes nu nok han hjalp mig rigeligt. Da jeg opdagede fejlen tænkte jeg slet ikke på at jeg kunne have fået mere hjælp, end jeg allerede havde været så heldig at modtage ;-)

Var de andre 13 andre kabler samlet korrekt - eller passede længden fra starten?

De 13 kabler var lange nok. Der var åbenbart bare 3 som manglede nogle få meter i at nå helt hen til X-feltet.

Historien viser, hvor vigtigt det er at teste sine stik, når man har monteret dem. Uden en test, ved man reelt ikke, om de virker som de skal, og en fejl på et PDS-stik kan være svær at finde. Fx kan man koble op til 4 ud af de 8 ledere fra, og der vil stadig være link, hvis det er de rigtige, der sidder tilbage - hastigheden vil bare være reduceret til 100 Mbit/s.

Ja, jeg tester også altid mine stik, når de er monteret. Enten ved at måle på det eller ved at kontrollere hastigheden i switch'en, når de er forbundet.
Jeg troede i øvrigt kun man kunne nå op på 10Mb/s på 4 ledere...?

Yoel Caspersen Blogger

Jeg troede i øvrigt kun man kunne nå op på 10Mb/s på 4 ledere...?

100BASE-TX kører på 4 ledere, så du kan godt køre to stk. 100 Mbit/s forbindelser over det samme netværkskabel, hvis alle 8 ledere er tilgængelige.

Noget kineser-udstyr kommer også med et patchkabel med kun 4 ledere - det er typisk tilfældet, når udstyret kun har 100 Mbit/s netværksport. Man skal skynde sig at smide et sådant kabel ud, da det ellers med garanti vil forvilde sig ind i en gigabit-installation en dag og forårsage problemer.

1000BASE-T kører på alle 8 ledere.

Enten ved at måle på det eller ved at kontrollere hastigheden i switch'en, når de er forbundet.

Du kan faktisk godt have en fejlbehæftet installation og stadig opnå 1 Gbit/s på dit kabel. De fleste moderne switches kører auto MDI/MDIX, som eliminerer behovet for krydsede kabler, hvis man kobler to switches sammen. Det betyder så også, at man kan have et krydset kabel, der virker, selv om det burde have været et "straight" kabel.

Baldur Norddahl

De fleste moderne switches kører auto MDI/MDIX, som eliminerer behovet for krydsede kabler,

Min udlejer satte selv stik på et kabel ind til stuen, men fik byttet om på nogle ledere. Resultatet var at kablet fungerede med min laptop men ikke med min gamle router. Hvorfor? Fordi computerens netkort er et moderne 1000 Mbit/s der kan bytte rundt elektrisk. Routeren har en 100 Mbit/s port.

Han havde i øvrigt forbundet lederne helt tilfældigt, så det var ikke blot krydset. Netkortet fandt ud af det alligevel. Jeg måtte lave det om i begge ender. Jeg klippede naturligvis stikkene og monterede dåser i stedet.

Log ind eller Opret konto for at kommentere
Tip redaktionen
Brugerundersøgelse Version2
maximize minimize