Case study: Pakketab målt i Gram
Hvis man i Sønderjylland kører ad landevejen fra Vojens mod Ribe, kommer man igennem en lille by ved navn Gram, som ikke har noget med køleskabsfabrikken at gøre.
Byen er også hjemsted for ca. 20 kunder hos Kviknet, som i den forgangne uge har oplevet et spøjst problem, vi skal kigge nærmere på i dag.
Sporadiske fejl på streaming-services
Vi hørte første gang om problemet, da en kunde kontaktede vores kundeservice og klagede over, at streaming fra Netflix og Viaplay ikke virkede på hendes iPhone og TV, men fungerede fint på hendes iPad.
Der var ingen brugbare fejlkoder eller lignende - blot en ikke-teknisk melding fra Netflix- og Viaplay-app'en om, at noget gik galt under streaming. Kunden kunne fint åbne de pågældende tjenesters websites i en browser.
Vores kunde havde ingen problemer på sin iPhone, når hun deaktiverede WiFi og brugte sin 4G-forbindelse i stedet.
Efter at have gennemført de sædvanlige øvelser med genstart af iPhone og TV, hard-reset af WiFi-router m.v. måtte vores medarbejder konstatere, at det ikke gjorde nogen forskel.
En test af forbindelsen hos TDC viste også, at alt så fint ud - ingen umiddelbare forstyrrelser på kundens DSL-forbindelse, og en traceroute fra kundens CPE til hhv. Netflix og Viaplay så helt normal ud.
Vi kunne dog se, at både Netflix og Viaplay bruger Amazon til en del af deres infrastruktur, og et spørgsmål meldte sig derfor: Kunne der være en generel fejl i nettet mellem Amazon og Kviknet?
En sådan fejl ville dog umiddelbart ramme mange brugere, medmindre den var relateret til lige præcis den IP-adresse, vores kunde brugte - der kunne være tale om en intern blacklisting hos Amazon, vi ikke havde hørt om.
Vi prøvede derfor at skifte kundens offentlige IP-adresse, men det gjorde heller ingen forskel.
Det ville være håbløst at få Amazon til at undersøge problemet i deres ende, og vi var derfor ved at overveje alternative løsninger, da en anden kunde henvendte sig og fortalte om et lignende problem med at tilgå streaming services.
I hans tilfælde var der dog en vigtig information mere - det var ikke kun Netflix, der ikke virkede, han havde også problemer med at tilgå www.ebay.com.
Vi undersøgte derfor, hvilke IP-adresser eBay bruger:
eBay benytter umiddelbart deres egne IP-adresser til deres website, så vi forkastede teorien om, at problemet havde noget med Amazon at gøre, og vi begyndte i stedet at se på, om de to kunder i øvrigt havde nogen fællesnævnere, der kunne hjælpe os:
Første kunde:
- Netflix og Viaplay virker ikke
- iPhone og TV fejler, men iPad virker
- 4G-forbindelse virker
- Inteno DG200-router fra Kviknet
- Carrier Grade NAT
- IPv6 aktiveret
- DSLAM: TDC Agerskov (ao)
Anden kunde:
- Netflix og eBay virker ikke
- Naboens trådløse Stofa-forbindelse virker
- Anvender egen router
- Offentlig IP-adresse
- IPv6 ikke aktiveret
- DSLAM: TDC Gram (gby)
Hvilke problemer kunne give de symptomer, kunderne oplevede? Begge kunders udstyr kunne pinges, og vi kunne fra kundernes udstyr også traceroute til både Netflix, Viaplay og eBay.
SSH til kundernes CPE'er virkede også, så vi måtte gå ud fra, vores forbindelse til kundens udstyr var i orden.
Eller... her var der måske et clue. En SSH-forbindelse, der anvendes til små opgaver som traceroute via en CLI, overfører beskedne datamængder. Det samme gør visse websites - men en streaming-service vil overføre store mængder data, og dermed vil IP-pakkerne også være større end normalt.
Kunne der være et problem med MTU'en et eller andet sted i nettet?
MTU angiver, hvor store ethernet-pakker må være, når de passerer en netværksport, og hvis pakkerne er for store, bliver de droppet. Det passede umiddelbart på symptomerne.
Standard MTU på internettet er 1500 bytes, og man skal ikke forvente at kunne sende pakker, der er større end dette.
En ICMP ping-pakke anvender 20 bytes til IP-headeren, så i realiteten kan en ICMP-pakke være 1480 bytes lang - men i praksis er den normalt kun på 64 bytes.
Hvis MTU'en på kundens port er mindre end normalt, men stadig større end 64 bytes, vil en almindelig ping-test virke fint, mens anden trafik med større pakker vil fejle.
Vi testede derfor, om vi kunne sende store ping-pakker til vores kunder - i Linux kan man angive størrelsen på en ping-pakke med parameteren -s, som angiver størrelsen på pakken minus ICMP-headeren på 8 bytes:
Store ping-pakker kom ikke igennem.
Vi prøvede at skrue ned for størrelsen, og kunne konstatere, at vi skulle ned på 1438 bytes (dvs. en MTU på 1466 bytes), før pakkerne kom igennem:
Så langt, så godt - vi havde nu fundet årsagen, men vi skulle nu finde ud af, hvor i nettet flaskehalsen var.
Vores mistanke rettede sig mod TDC-centralen i Gram, da begge kunders trafik løber gennem denne. Vi kunne gennem ping-tests med store pakker konstatere, at andre Kviknet-kunder, som også var koblet op gennem TDC-centralen i Gram, havde samme problem, selv om de ikke havde henvendt sig til os endnu.
På TDC-centralen i Gram har vi et såkaldt POI (Point of Interconnect), hvor TDC udveksler trafikken med GlobalConnect, som leverer vores backbone-strækning mellem Gram i Sønderjylland og København.
GlobalConnect leverer i forvejen backbone-net til en række andre TDC-centraler i landet, og det hele samles i Taastrup og Ballerup, hvor vi udveksler trafikken med GlobalConnect.
På porten i Taastrup havde vi umiddelbart ingen problemer med for lille MTU:
Det var således sandsynligt, at MTU-fejlen lå i udstyret på TDC-centralen i Gram - enten i TDC's ende eller i GlobalConnects.
Vi fejlmeldte derfor sagen til både TDC og GlobalConnect, og det lykkedes relativt hurtigt GlobalConnect at identificere og rette fejlen, som lå i deres udstyr. TDC var også klar på at fejlsøge i deres ende, men det blev heldigvis ikke nødvendigt.
En forbedret ping-test
Som internetudbyder er det træls, når kunderne opdager fejlene, før vi selv gør. Det er umuligt at undgå fejl, men jo hurtigere, vi retter dem, jo mindre impact når de at få.
Vi pinger i forvejen alle vores kunder, vi selv leverer IP-adresser til, hvert 5. minut.
Det gør vi for at få alarmer, når der sker nedbrud hos vores underleverandører, herunder TDC og GlobalConnect - men ping-testen fangede ikke, at MTU'en var sat ned med 34 bytes.
Den oplagte forbedring af vores ping-test er derfor at sikre, at vi altid pinger med pakker, der udnytter hele MTU'en på 1500 bytes.
Gennem længere tid har vi anvendt portscanneren nmap til ping-test, mest af alt fordi nmap kunne teste forbindelsen til coax-routere på YouSees net, selv om YouSee indtil 22. maj 2018 blokerede for ICMP-forespørgsler udefra.
Det skyldes, at nmap anvender en række tests, der er mere sofistikerede end ICMP ping - fx at sende TCP SYN-pakker til en IP-adresse og se, om der kommer svar.
Dertil kommer, at nmap kan pinge et større antal IP-adresser, som hentes fra en fil:
Desværre ser det ikke ud til, at vi kan tvinge nmap til at anvende store ICMP-pakker, så vi er nødt til at finde et alternativ.
Det kommer i form af fping, hvor man kan sætte størrelsen på ping-pakkerne:
Kommandoen resulterer i en nydelig liste, der er nem at parse med et script:
Man skal dog være opmærksom på, at listen bliver skrevet til stderr og ikke stdout.
Vi har nu sat fping-løsningen i drift, og vi kan konstatere, at ca. 2 procent af vores kunder nu står som offline - det skyldes, at de anvender egne CPE'er, typisk fra Linksys, DLink og Netgear, som ikke svarer på ICMP ping som standard.
En anden interessant observation er, at fping på vores coax-kunder indikerer en pingtid, der i gennemsnit er ca. 1 millisekund højere end den pingtid, nmap rapporterer.
Til gengæld får vi nu en alarm, hvis nogen en anden gang skulle komme til at sætte en for lav MTU på et kredsløb i backbone-nettet.
Rettelse: Blogindlægget har tidligere påstået, at Gram er kendt for køleskabe. Det passer desværre ikke - køleskabsfabrikken Gram stammer ikke fra Gram, men blev grundlagt i Vojens.
