yoel caspersen blog bloghoved

Case study: Pakketab målt i Gram

Af 29

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:

$ host ebay.com
ebay.com has address 66.135.216.190
ebay.com has address 66.211.181.123
ebay.com has address 66.211.185.25
ebay.com has address 66.211.160.86
ebay.com has address 66.211.162.12
ebay.com has address 66.135.209.52
ebay.com mail is handled by 10 mx2.hc2186-24.iphmx.com.
ebay.com mail is handled by 10 mx1.hc2186-24.iphmx.com.
 
$ whois 66.135.216.190
....
NetRange:       66.135.192.0 - 66.135.223.255
CIDR:           66.135.192.0/19
NetName:        EBAY-1
NetHandle:      NET-66-135-192-0-1
Parent:         NET66 (NET-66-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       
Organization:   eBay, Inc (EBAY)
RegDate:        2001-07-12
Updated:        2012-03-02
Ref:            https://rdap.arin.net/registry/ip/66.135.192.0

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:

# ping -s 1472 100.65.92.4
PING 100.65.92.4 (100.65.92.4) 1472(1500) bytes of data.
^C
--- 100.65.92.4 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9072ms

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:

# ping -s 1438 100.65.92.4
PING 100.65.92.4 (100.65.92.4) 1438(1466) bytes of data.
1446 bytes from 100.65.92.4: icmp_seq=1 ttl=63 time=9.44 ms
1446 bytes from 100.65.92.4: icmp_seq=2 ttl=63 time=9.49 ms
^C
--- 100.65.92.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.447/9.468/9.490/0.099 ms

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:

#show interface xgei-0/0/1/8.68
xgei-0/0/1/8.00000068 is up, line protocol is up, IPv4 protocol is up, IPv6 protocol is up
  Description is "Gram L3" 
  Hardware is XGigabit Ethernet, address is cc1a.fae7.47c0
  Internet address is 212.237.180.113/28 
  BW 10000000 Kbps
  IP MTU 1500 bytes
  MTU 1600 bytes
  IPv6 MTU 1500 bytes
  MPLS MTU 1550 bytes
  ARP type ARP
  ARP Timeout 04:00:00

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:

$ nmap -n -sP -v -iL /tmp/ip_list.txt

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:

$ fping -b1472 -q -C 1 < /tmp/ip_list.txt

Kommandoen resulterer i en nydelig liste, der er nem at parse med et script:

100.64.164.131 : 28.22
100.64.164.132 : 19.03
100.64.164.133 : 29.32
100.64.164.134 : 6.00
100.64.164.135 : -

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.

Relateret indhold

Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jens-Peter Vraa Jensen

God fortælling og beskrivelse af fejlsøgning! Det kunne være spændende at høre, hvordan/hvorfor sådan en fejl opstår hos en professionel leverandør.

Det minder mig om en sag jeg engang havde hos en kunde for en 7-8 år siden: Alt så perfekt ud, men synkronisering af data "hang" og fejlen var meget inkonsistent.

Efter at have fejlsøgt r.... ud af bukserne på min egen installation (for resten kørte jo fint for kunden) fandt jeg ud af, at pakker over en bestemt størrelse "forsvandt".

Ping var også dengang værktøjet til at finde problemet og kommandoen virker også fint under Windows (MS har faktisk en KB artikel: https://support.microsoft.com/en-sg/help/159211/diagnoses-and-treatment-...).

Der var gået en del timer med fejlsøgning/kontrol af installationen, og da jeg lidt ud på natten sagde til deres IT administrator, at de havde et problem med bestemte pakkestørrelser sagde han: Nå ja, vi plejer jo også at sænke MTU på vores servere. (SUK!).

En registry ændring senere kørte alt som det skulle.

  • 1
  • 0
Michael Kjærsgård

MTU problemer er noget fanden har skabt - specielt når det er uden for eget net så man er afhængige af andres fejlsøgning :( Lykkedes det at blive klog på hvordan iPad'en hos Kunde1 opførte sig anderledes siden den ikke var berørt af problemet?

  • 1
  • 0
Yoel Caspersen Blogger

Det kunne være spændende at høre, hvordan/hvorfor sådan en fejl opstår hos en professionel leverandør.

Helt enig, men vi har ikke fået forklaringen endnu.

Der er selvfølgelig den simple mulighed, at nogen har sat en lav MTU på en port manuelt, men jeg har svært ved at se use-casen for dette, og det ville være en ret åbenlys fejl at lave, som man burde spotte med det samme.

Personligt gætter jeg derfor på, det er noget encapsulation, der er gået galt - fx en eller anden form for tunnel, der implicit har medført en lavere MTU.

  • 1
  • 0
Yoel Caspersen Blogger

Lykkedes det at blive klog på hvordan iPad'en hos Kunde1 opførte sig anderledes siden den ikke var berørt af problemet?

Nej, og den var netop medvirkende til at sløre billedet af fejlen til at starte med. Når nogle enheder virker, mens andre ikke gør, lugter det oftest af, at problemet skal findes lokalt hos den enkelte kunde.

Mit eget gæt er, at iPad'en måske har været koblet på naboens WiFi-netværk - der har næppe været fejlsøgt særlig meget på den, når nu den umiddelbart virkede som den skulle.

  • 1
  • 0
Peter Krüpl

Når der nu mangler hele 34 byte MTU, så er det ikke bare et vlan tag for meget. Så er det et andet sted man skal lede, som feks. en MPLS pseudowire hvor den oprindelige ramme(frame) pakkes i MPLS.

Af bitter erfaring, griber jeg instinktivt til en ping med "-s 1472" når jeg hører om websurf der går langsomt, eller i klumper eller downloads der fryser.

Som regel mangler der kun 4 byte. Grunden til at der netop mangler 4 byte er at det er den størrelse et vlan tag har, og kører man QinQ i access nettet så skal man huske at hæve standard MTU på sine switche.
Sådan en fejl opstår fordi nogen har glemt at hæve MTU i konfigurationen.

Det undrer mig meget at fejlen alligevel var så subtil. Men det er op til TCP stakken i endepunkterne, og evt. routere/firewalls undervejs som mener de skal begrænse TCP MSS.

  • 4
  • 0
Lars Petersen

Når Kviknet bliver en stor ISP, så vil de måle pakketab i kg!!!

PS: Thumbs up for god click-bait overskrift. Havde man lissom bemærket et versal 'G', var man jo ikke hoppet på den :)

PS2: Når I får kunde nr. tusinde i Gram, må I godt skrive om det. (bor der så mange?)

  • 5
  • 0
Anders Dahl

Hej Yoel
Læser dine indlæg med fornøjelse. Både fordi de er interessante, og fordi du er en god formidler.
Men men men, køleskabsfabrikken Gram er altså grundlagt i Vojens af Hans Gram. Tror nok lige du må læse lidt op på din lokalhistorie. Vi sønderjyder tager ikke let på den slags ;)

  • 3
  • 0
Baldur Norddahl

Personligt gætter jeg derfor på, det er noget encapsulation, der er gået galt - fx en eller anden form for tunnel, der implicit har medført en lavere MTU.

Det er naturligvis en tunnel. Vi kan gætte på hvilken tunnel teknologi ved at se på størrelsen af overhead.

Du går fra MTU 1500 til MTU 1466.

Tjek denne beregner: https://baturin.org/tools/encapcalc/

Tilføj følgende ekstra headere:

IPv4 20 bytes
GRE 4 bytes
Ethernet 14 bytes

Det giver en MTU på 1462. Det er ikke et match.

Faktisk kan jeg ikke helt finde et match, så måske jeg overser noget her.

  • 4
  • 0
Yoel Caspersen Blogger

Det giver en MTU på 1462. Det er ikke et match.

Faktisk kan jeg ikke helt finde et match, så måske jeg overser noget her.

Cool beregner :)

Nu er det jo ikke sikkert, at 1500 nødvendigvis er udgangspunktet. Vi ved blot, at MTU i transportnettet normalt >= 1500.

Der kan også være tale om en manuelt sat MTU > 1500 i kombination med en form for encapsulation, der implicit giver MTU 1466. En sådan fejl ville være sværere at spotte for den, der laver den, end hvis MTU'en manuelt er sat til < 1500.

  • 1
  • 0
Leif Neland

Jeg har lavet et lille shellscript, der laver en binær søgning på max pakkelængde via "nmap -nsn -sP -data-length $mtu $ip"

Jeg har lokation A med host a og lokation B med host b, der er forbundet med hver sin openVPN til datacenter C med host c

Fra a til c , via den ene VPN, får jeg mtu på 1460
Fra c til b, via den anden VPN, får jeg mtu på 1472
Fra a til b, via begge VPN får jeg mtu på 512.
(Jeg har ikke en linux på lokation B, jeg lige kan køre mit script på)

A og C kører OpenVPN på pfsense, B OpenVPN på Tomato.

Nu har jeg sjældent (aldrig) brug for at kommunikere direkte mellem a og b, men det er da underligt...

(Jeg er ikke low-level nok til lige at se om mtu er den rette betegnelse for værdien af parameteren --data-length, men det kommer ikke denne sag ved)

I øvrigt kørte køleskabsfabrikken med slogannet "Der kan være mange kilo i et Gram"
http://tilbagetildatiden.blogspot.com/2012/04/der-kan-vre-mange-kilo-i-e...

  • 1
  • 0
Jan Thomsen

Det forekommer mig at problemet ikke ville have forekommet hvis Path MTU discovery protokollen havde fungeret ? Men det fordrer jo at alle routere og endpoint understøtter passende ICMP pakke typer - vistnok type 3 .
I indlægget nævnes vist netop at ICMP var disablet på visse strækninger. Men det er jo i givet fald ikke specielt smart hvis man har lukket af for at sende ICMP beskeder tilbage til afsenderen med besked om at pakken er for stor.
Path MTU discovery var netop ofundet for at gøre internette robust mod variatioer i MTU størrelser. Jeg har dog selv tidligere observeret fejlkonfigurerede routere som svarede ukorrekt størrelse på Path MTU, så måske var det det der var problemet her.
Et af problemerne er at der efterhånden er mange der mener at man skal lukke firewalls for ICMP trafik, men type 3 er een af dem man ikke bør lukke ned for.

  • 1
  • 0
Yoel Caspersen Blogger

Fra a til c , via den ene VPN, får jeg mtu på 1460
Fra c til b, via den anden VPN, får jeg mtu på 1472
Fra a til b, via begge VPN får jeg mtu på 512.

Enig, det lyder noget mystisk at du så får 512 mellem a og b. Det burde være den laveste fællesnævner, dvs. 1460.

Har du prøvet at teste med ping -s <size> i stedet for nmap? Bare for at være helt sikker?

Alternativt kan du prøve at køre en tcpdump samtidig, så du kan se hvad der reelt sendes gennem netkortet.

  • 0
  • 0
Yoel Caspersen Blogger

Det forekommer mig at problemet ikke ville have forekommet hvis Path MTU discovery protokollen havde fungeret ? Men det fordrer jo at alle routere og endpoint understøtter passende ICMP pakke typer - vistnok type 3 .

Principielt har du ret, men jeg kunne forestille mig, en del af problemet i denne case er, at trafikken løber gennem en L2VPN-tunnel i et MPLS-netværk. Det er et rent gæt, men man kunne forestille sig, at ICMP-pakken, der sendes retur fra porten med lavere MTU, blot sendes til det ene endpoint af L2VPN'en og ikke til den oprindelige afsender af trafikken.

Dertil kommer så også, at PMTUD i mange cases som du ganske rigtigt påpeger forstyrres af (for) strikse firewall-regler.

  • 0
  • 0
Børge Müller

Har lige testen min internet forbindelse:
Pinging 8.8.8.8 with 1468 bytes of data:
Reply from 8.8.8.8: bytes=1468 time=38ms TTL=122
Reply from 8.8.8.8: bytes=1468 time=38ms TTL=122

1468 er det højeste antal der kommer igennem, er det ok?

  • 0
  • 0
Børge Müller

Tak, Yoel
nej - jeg bruger ikke VPN.
Min internet udbyder et TDC (ADSL-2 pair bonded)

C:\>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 10.39.1.1
2 2 ms 1 ms 1 ms 10.99.2.1
3 38 ms 32 ms 31 ms lo0-0.stmnqe10.dk.ip.tdc.net [93.162.120.1]
4 35 ms 32 ms 31 ms ae1-0.stkm2nqp7.se.ip.tdc.net [83.88.2.131]
5 32 ms 32 ms 32 ms peer-as15169.stkm2nqp7.se.ip.tdc.net [128.76.59.41]
6 * * * Request timed out.
7 34 ms 35 ms 34 ms 72.14.238.12
8 33 ms 32 ms 32 ms 216.239.58.41
9 31 ms 31 ms 32 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

C:\>ping -l 1468 8.8.8.8
Pinging 8.8.8.8 with 1468 bytes of data:
Reply from 8.8.8.8: bytes=1468 time=37ms TTL=122
Reply from 8.8.8.8: bytes=1468 time=38ms TTL=122

  • 0
  • 0
Børge Müller

Her til formiddag får jeg dette resultat:

C:\>ping -l 1500 8.8.8.8
Pinging 8.8.8.8 with 1500 bytes of data:
Reply from 8.8.8.8: bytes=1500 time=48ms TTL=122
Reply from 8.8.8.8: bytes=1500 time=47ms TTL=122
Reply from 8.8.8.8: bytes=1500 time=47ms TTL=122
Reply from 8.8.8.8: bytes=1500 time=47ms TTL=122
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 48ms, Average = 47ms

DET GJORDE JEG SÅ IKKE ALLIGEVEL, NU FÅR JEG IGEN KUN 1468....

  • 0
  • 0
Jari Mikkelsen

Hey Yoel. Og resten af V2

Jeg læser af og til din blog, da jeg synes de er ganske spændene. 👍

Jeg er tilfældigvis kunden fra Gram, og i sidste ende sikkert ret urellevant for casen og resultatet, var mit scenarie en smule anderledes end du beskriver, omend detaljer forbyttet tror jeg.

En onsdag går det galt så vidt jeg husker. Om morgenen inden jeg går i seng, ser jeg gerne et lille afsnit på min netflix. Som jeg falder ganske nemt i søvn på 🤪 og da jeg vågner om efter middagen og lige vil se afsnittet færdoig, er mine chromecast død. Jeg prøver i stuen på mit smart tv (samsung tizen os) men ak, ligledes får jeg bare en fejl. Og der opdager jeg det faktisk er alle mine streaming tjenester der er døde, pånær stofa tv og plex! Viaplay, netflix, yousee app, youtube, you name it. De er døde. Pånær på min ipad, og pc Wooot!

Jeg resetter alt jeg ejer af netværksudstyr, inkl chromecasts, tv, min egen netgear r6300 og kviknets router som kører bridge mode (modem). Lige lidt nytter det. Samt forsøger jeg også at skifte dns 8.8.8.8 og 1.1.1.1. (ja hvad ved jeg 😂)

Da weekenden nærmer sig, og mine børn kommer på besøg, og tv trangen ophober sig, og stofa tv (som kører dårligt nok i forvejen) også strjeker, fejlmelder jeg linjen, og får dog et negativt svar igen, at linjen ser fin ud og at fejlen lagde hos mig eller netflix. Men da alle tjenester var væk, udelukkede jeg den sidste del.

Jeg trods svaret, gav ikke op, og konfigurede jeg mit huawei 4G callme mobil router, og så virkede alt bare spot on!, men pga. Manglende data mængde til en weekends stream med 3 unger, prøvede jeg at tilluske mig underboens Stofa linje, met et langt kabel, og igen virkede det hele. Satte jeg kviknet på som isp igen, så var chomecasts, tv, og det hele dødt igen, pånær browsers, apps osv virkede helt fint. Så noget hul var der da igennem. Hvor ebay dog lige kom ind i billedet henne ved jeg ikke. Bruger den ganske sjældent. Og mindes ikke st have nævnt det.

Da jeg fejlmelder igen med disse info, og her forholdsvis kort lunte efterhånden (undskyld for dette!) kommer der hul igennem senere lørdag aften.

Jeg er forstående for at man ikke lige spotter sådan en relativt sjælden fejl med det samme. Og jeg har heller ikke selv oplevet et lign scenarie før. Men synes da lige jeg ville komme med min historie.

God weekend!

  • 0
  • 0
Yoel Caspersen Blogger

Jeg er tilfældigvis kunden fra Gram, og i sidste ende sikkert ret urellevant for casen og resultatet, var mit scenarie en smule anderledes end du beskriver, omend detaljer forbyttet tror jeg.

Tak for rosen, og for delingen af din historie. Jeg skal ikke kunne afvise, at det var en af de andre kunder i Gram, der havde problemer med at komme ind på eBay, men pointen er, at det var den oplysning, der var med til at lede os i den rigtige retning - vi havde parallelle fejlsøgninger hos flere kunder i gang samtidig.

Da jeg fejlmelder igen med disse info, og her forholdsvis kort lunte efterhånden (undskyld for dette!) kommer der hul igennem senere lørdag aften.

Jeg håber, det lykkedes os at redde det meste af din weekend - det er træls, når tingene ikke spiller.

God weekend til dig også :-)

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Tip redaktionen
IT Company Rank
maximize minimize