Al 32 dagen 's avonds geen internet

Frans-Jan · 30 september 2022 om 19:19

TL;DR: de routers van Tweak’s netwerk voor mijn glasvezelverbinding lijkt overbelast, maar Tweak’s naam is al wekenlang Haas.

Wij konden vorige maand eindelijk overstappen naar glasvezel, dus we hebben onze oude vertrouwde DSL verbinding achter ons gelaten en van onze oude vertrouwde provider (Tweak) een nieuw abonnement via de glasvezel van KPN Netwerk (Reggefiber) gekregen.

Wat heb ik daar spijt van.

Sinds dag één hebben we dagelijks enorme latency problemen die het internet compleet onbruikbaar maken. Deze doen zich vooral in de avonden voor, als Nederland lekker aan het internetten gaat. Voelt dus duidelijk als overbelasting ergens op de lijn. In het weekend hebben we dit ook wat vaker overdag. “Grappig” om te zien dat de problemen verdwijnen als Nederland een interland speelt of Max over Zandvoort raast. Aangezien ICMP (ping) nergens last van heeft voelt het duidelijk als een overbelaste router die bepaald prioriteitsverkeer wel doorlaat, maar TCP en UDP redelijk consequent niet sneller dan met een seconde of 5-10 kan afhandelen.

In eerste instantie heb ik al mijn eigen spullen doorgelopen, zonder resultaat. Ik heb vervolgens Tweak gebeld, die mij vertelden dat hun technische dienst niets kon vinden en dat men zich afvroeg of het niet aan mijn thuisnetwerk lag. Kan natuurlijk altijd, dus ik heb alles van de Fritz!Box afgekoppeld op één mobiel apparaat na, maar nog steeds hommeles. Vervolgens is KPN gevraagd of zij iets konden zien. Niets, helaas. Daarna heb ik nog (op eigen suggestie) de Fritz!Box van de ONT afgehaald, een laptop direct aan de ONT gehangen en daarmee het probleem ook kunnen vaststellen. De Fritz!Box (en alles daarachter) is dus ook de schuldige niet, tcpdump doorgemaild en afgewacht. Na meerdere dagen nog maar eens gebeld: of het niet aan mijn thuisnetwerk lag? Toen toch even uit mijn slof geschoten, want daar had ik toch de tcpdump voor gemaakt dacht ik zo.

Tweak heeft vervolgens KPN Netwerk een monteur laten komen. Vriendelijke gast, die alles doorgemeten heeft, de ONT voor de zekerheid heeft vervangen, twee koppen koffie heeft genuttigd en de glaskoppeling in de centrale nog eens extra heeft opgepoetst. Geen soelaas. Vervolgens Tweak voor de zoveelste keer gebeld, en voor de zoveelste keer de vraag gekregen of het niet toch aan mijn thuisnetwerk ligt. Erg duidelijk gemaakt dat dit niet het geval is, ze zouden er op terug komen.

Na dagen van frustratie en zonder bericht vandaag nog maar eens gebeld. Het verhaal volgens de servicedesk is duidelijk: de technische dienst geeft aan dat er bij Tweak sowieso niets aan de hand is, KPN geeft aan dat er bij hun ook niets aan de hand is en de klant beweert dat het niet aan het thuisnetwerk ligt, dus niemand weet iets en niemand kan niets. Gevraagd of de technische dienst mij dan wilde bellen, maar dat gaat niet, kan niet en mag niet. Gevraagd of ik maandag teruggebeld kan worden, maar dat kan ook niet.

Ik kon wel een bericht op dit forum achterlaten, zeiden ze. De technische dienst, in de vorm van “Johan” reageert hier wél op klanten. Wie weet dat dat zou helpen, of dat één van de andere klanten actief op dit forum iets kon zien. Prima, bij deze.

Zojuist nog even wat testen gedraaid met een laptop direct aan de ONT. Geen thuisnetwerk, geen Fritz!Box, zo kaal als maar kan. Ping komt altijd door, dus getest met een DNS look-up:

% while sleep 1; do time nslookup google.com 1.1.1.1 > /dev/null; done
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.04s system 54% cpu 0.103 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 44% cpu 0.051 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 65% cpu 0.072 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 0% cpu 5.077 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 0% cpu 5.074 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.02s system 0% cpu 5.055 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 0% cpu 10.082 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.02s system 44% cpu 0.053 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 59% cpu 0.069 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 60% cpu 0.079 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 1% cpu 5.082 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 60% cpu 0.077 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 1% cpu 5.078 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 62% cpu 0.075 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 5.078 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 61% cpu 0.075 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 61% cpu 0.073 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 60% cpu 0.070 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 61% cpu 0.075 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 62% cpu 0.079 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 58% cpu 0.073 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 1% cpu 5.082 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 1% cpu 5.079 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 61% cpu 0.078 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 0% cpu 10.079 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 0% cpu 15.062 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 0% cpu 5.080 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 0% cpu 20.309 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 55% cpu 0.030 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 0% cpu 10.062 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 47% cpu 0.046 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 0% cpu 10.310 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 69% cpu 0.072 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 15.061 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 0% cpu 5.297 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.02s system 0% cpu 10.050 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 47% cpu 0.046 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 67% cpu 0.069 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 63% cpu 0.068 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 68% cpu 0.069 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 0% cpu 20.301 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.02s system 49% cpu 0.047 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 65% cpu 0.068 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 66% cpu 0.071 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.03s system 0% cpu 15.303 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 5.311 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 5.304 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 10.306 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 67% cpu 0.072 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 0% cpu 5.069 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 48% cpu 0.044 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 77% cpu 0.062 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 67% cpu 0.072 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 64% cpu 0.071 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 68% cpu 0.069 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 48% cpu 0.043 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 47% cpu 0.043 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 66% cpu 0.069 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 5.306 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 68% cpu 0.072 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 5.073 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.03s system 0% cpu 10.074 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.02s system 0% cpu 10.291 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 66% cpu 0.069 total

De tcpdump van tijdens deze test is te vinden op https://files.fst.li/tcpdump
~~Als je goed naar de tijden kijkt komt er dus regelmatig 5, 10, 15 of 20 seconden bij de tijd die je eigenlijk zou verwachten. Geen 2, geen 13, altijd meervouden van 5.~~ [EDIT: dat is natuurlijk vanwege de retry-timeout van nslookup]

Nog een test naar een andere DNS server:

% while sleep 1; do time nslookup google.com 8.8.8.8 > /dev/null; done
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 61% cpu 0.075 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 1% cpu 5.078 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 62% cpu 0.079 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 62% cpu 0.081 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 0% cpu 5.073 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.03s system 0% cpu 20.321 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 0% cpu 10.308 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 61% cpu 0.080 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 1% cpu 5.078 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 63% cpu 0.075 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 63% cpu 0.077 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 63% cpu 0.076 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 0% cpu 10.079 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 62% cpu 0.080 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 62% cpu 0.075 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.03s system 0% cpu 15.070 total
nslookup google.com 8.8.8.8 > /dev/null  0.01s user 0.01s system 8% cpu 0.295 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 0% cpu 5.312 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 65% cpu 0.071 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 1% cpu 5.083 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 65% cpu 0.072 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 62% cpu 0.079 total
nslookup google.com 8.8.8.8 > /dev/null  0.01s user 0.01s system 43% cpu 0.054 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 63% cpu 0.074 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 65% cpu 0.072 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 59% cpu 0.082 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.02s system 60% cpu 0.078 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.02s system 61% cpu 0.073 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 61% cpu 0.081 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.02s system 63% cpu 0.073 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.03s system 68% cpu 0.072 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.03s system 1% cpu 5.081 total
nslookup google.com 8.8.8.8 > /dev/null  0.01s user 0.01s system 46% cpu 0.051 total
nslookup google.com 8.8.8.8 > /dev/null  0.02s user 0.02s system 63% cpu 0.075 total
nslookup google.com 8.8.8.8 > /dev/null  0.01s user 0.01s system 45% cpu 0.051 total
nslookup google.com 8.8.8.8 > /dev/null  0.03s user 0.02s system 0% cpu 5.311 total

De tcpdump hiervan staat op https://files.fst.li/tcpdump2

Nou Johan, ik hoop dat je meeleest. En dat er iets gebeurt, want na een maand en twee dagen 's avonds overgeleverd te zijn aan 4G van Tele2 en vervolgens meermaals te horen dat het waarschijnlijk toch echt aan mijzelf ligt ben ik he-le-maal klaar met Tweak.

Frans-Jan · 30 september 2022 om 19:20

Hier nog een tweetal exports van een Grafana dashboard waarop de issues goed te zien zijn:

johan · 1 oktober 2022 om 13:40

Ik lees je
Het is nogal een vaag probleem en KPN vermoedt dat je je lijn voltrekt omdat er volgens hun geen bandbreedteproblemen zijn in jouw omgeving. Ik heb daarom een tijdelijke upgrade gedaan naar 200 Mbit zodat je kunt zien of dat het probleem verhelpt. Als dat inderdaad het probleem verhelpt, is het toch aannemelijk dat er iets lokaal aan de hand is.

Ik zit zelf ook op het KPN WBA-netwerk thuis en heb 0 loss en 0 latency-problemen. Ik kan bij andere WBA-klanten hetzelfde constateren en daarom kan ik met enige zekerheid zeggen dat het probleem lokaal of regionaal is. Zodra het regionaal of lokaal wordt, kom ik er zelf eigenlijk niet meer aan te pas.

Ter illustratie mijn smokeping-grafiek die de gateway pingt:

Verder kan ik niet zoveel met tcpdumps om latency of packetloss te debuggen. Een degelijke set traceroutes is handiger.

Frans-Jan · 1 oktober 2022 om 14:44

Hallo Johan, prettig kennis te maken.

Op dit moment doen de problemen zich ook voor en doen wij niet of nauwelijks iets met de verbinding. Tijdens de issues trekken wij de lijn niet vol, en ik heb ondertussen ook meermaals ons thuisnetwerk (en dus ons gebruik) uitgesloten door de Fritz!Box van de ONT af te halen, een laptop aan te sluiten en niets anders te doen dan een DNS lookup (en misschien wat NTP op de achtergrond). De tcpdumps dienen o.a. om duidelijk te maken dat er nagenoeg geen verkeer en wel gigantische latency is.

Nogmaals en met nadruk: ik heb al heel vaak gehoord dat het probleem lokaal aan onze kant zou liggen. Het lijkt regel één uit het servicedesk script. Maar dan hoort alles gewoon te werken als ik met één apparaat aan de ONT niets anders doe dan een serie DNS resoluties. Toch? Zo niet, hoe dan?

Zoals ik al eerder aangaf zegt ping ook niet zoveel, omdat dit geprioriteert lijkt te worden. Zal wel in de QoS staan (logisch ook). Momenteel heb ik een met ping een round-trip latency naar 1.1.1.1 van zo’n 7ms, prima dus. Op hetzelfde moment ziet een regelmatige nslookup er weer als vanouds waardeloos uit:

% while sleep 1; do time nslookup google.com 1.1.1.1 > /dev/null; done
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.02s system 0% cpu 10.050 total
nslookup google.com 1.1.1.1 > /dev/null  0.03s user 0.02s system 0% cpu 5.078 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 40% cpu 0.048 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 41% cpu 0.046 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 42% cpu 0.046 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 0% cpu 5.050 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 42% cpu 0.043 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 0% cpu 10.071 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 54% cpu 0.061 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 0% cpu 5.074 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.02s system 60% cpu 0.065 total
nslookup google.com 1.1.1.1 > /dev/null  0.02s user 0.01s system 0% cpu 15.037 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 42% cpu 0.045 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 0% cpu 10.053 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 0% cpu 10.055 total
nslookup google.com 1.1.1.1 > /dev/null  0.01s user 0.01s system 35% cpu 0.047 total

Nog een ander voorbeeld van een request die normaal gesproken niet meer dan 400ms zou mogen kosten:

% while sleep 1; do time curl https://ip.fst.li > /dev/null 2>&1; done
curl https://ip.fst.li > /dev/null 2>&1  0.07s user 0.01s system 3% cpu 2.405 total
curl https://ip.fst.li > /dev/null 2>&1  0.06s user 0.02s system 1% cpu 3.808 total
curl https://ip.fst.li > /dev/null 2>&1  0.10s user 0.03s system 1% cpu 10.163 total
curl https://ip.fst.li > /dev/null 2>&1  0.07s user 0.01s system 4% cpu 1.957 total
curl https://ip.fst.li > /dev/null 2>&1  0.08s user 0.01s system 2% cpu 3.501 total
curl https://ip.fst.li > /dev/null 2>&1  0.14s user 0.03s system 4% cpu 3.410 total
curl https://ip.fst.li > /dev/null 2>&1  0.07s user 0.02s system 1% cpu 5.112 total
curl https://ip.fst.li > /dev/null 2>&1  0.07s user 0.03s system 1% cpu 7.617 total
curl https://ip.fst.li > /dev/null 2>&1  0.16s user 0.04s system 0% cpu 42.249 total
curl https://ip.fst.li > /dev/null 2>&1  0.08s user 0.01s system 2% cpu 3.877 total
curl https://ip.fst.li > /dev/null 2>&1  0.10s user 0.02s system 1% cpu 7.369 total

Ik kan met tracepath ook niet een duidelijk beeld maken van het probleem, wie weet dat dit ook ergens prio krijgt. Juist het feit dat ping en consorten wel doormogen en ander regulier verkeer (DNS, HTTP) tegen vertraging aanlopen doet mij vermoeden dat het probleem zich op laag drie voordoet, in de routering dus, en dat is volgens mij toch echt een Tweak ding, geen KPN ding.

Er is met de wijziging naar 200MBit weinig veranderd, hier een snapshot van de status van de laatste drie uur. De Fritz!Box laat op dit moment minimaal verkeer zien:

Frans-Jan · 1 oktober 2022 om 15:01

Hier nog een voorbeeld, dit keer naar de Tweak DNS servers:

% while sleep 1; do time nslookup google.com 82.197.196.182 > /dev/null; sleep 1; time nslookup google.com 82.197.196.183 > /dev/null; done
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 40% cpu 0.046 total
nslookup google.com 82.197.196.183 > /dev/null  0.01s user 0.01s system 0% cpu 15.046 total
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 37% cpu 0.043 total
nslookup google.com 82.197.196.183 > /dev/null  0.01s user 0.01s system 0% cpu 15.039 total
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 0% cpu 15.025 total
nslookup google.com 82.197.196.183 > /dev/null  0.01s user 0.01s system 37% cpu 0.039 total
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 0% cpu 10.056 total
nslookup google.com 82.197.196.183 > /dev/null  0.02s user 0.02s system 0% cpu 10.071 total
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 0% cpu 5.046 total
nslookup google.com 82.197.196.183 > /dev/null  0.01s user 0.01s system 0% cpu 5.046 total
nslookup google.com 82.197.196.182 > /dev/null  0.02s user 0.02s system 0% cpu 15.053 total
nslookup google.com 82.197.196.183 > /dev/null  0.02s user 0.02s system 0% cpu 5.071 total
nslookup google.com 82.197.196.182 > /dev/null  0.02s user 0.03s system 0% cpu 5.072 total
nslookup google.com 82.197.196.183 > /dev/null  0.02s user 0.02s system 0% cpu 15.068 total
nslookup google.com 82.197.196.182 > /dev/null  0.02s user 0.02s system 57% cpu 0.066 total
nslookup google.com 82.197.196.183 > /dev/null  0.01s user 0.02s system 0% cpu 5.058 total
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 0% cpu 5.044 total
nslookup google.com 82.197.196.183 > /dev/null  0.01s user 0.02s system 0% cpu 20.052 total
nslookup google.com 82.197.196.182 > /dev/null  0.01s user 0.01s system 0% cpu 15.043 total
nslookup google.com 82.197.196.183 > /dev/null  0.02s user 0.02s system 0% cpu 15.074 total
nslookup google.com 82.197.196.182 > /dev/null  0.02s user 0.02s system 57% cpu 0.063 total
nslookup google.com 82.197.196.183 > /dev/null  0.02s user 0.02s system 57% cpu 0.066 total

ping en tracepath op hetzelfde moment:

% ping 82.197.196.182
PING 82.197.196.182 (82.197.196.182) 56(84) bytes of data.
64 bytes from 82.197.196.182: icmp_seq=1 ttl=60 time=9.16 ms
64 bytes from 82.197.196.182: icmp_seq=2 ttl=60 time=6.57 ms
64 bytes from 82.197.196.182: icmp_seq=3 ttl=60 time=6.52 ms
64 bytes from 82.197.196.182: icmp_seq=4 ttl=60 time=8.91 ms
64 bytes from 82.197.196.182: icmp_seq=5 ttl=60 time=7.72 ms
64 bytes from 82.197.196.182: icmp_seq=6 ttl=60 time=9.28 ms
64 bytes from 82.197.196.182: icmp_seq=7 ttl=60 time=7.98 ms
64 bytes from 82.197.196.182: icmp_seq=8 ttl=60 time=7.51 ms
64 bytes from 82.197.196.182: icmp_seq=9 ttl=60 time=9.08 ms
64 bytes from 82.197.196.182: icmp_seq=10 ttl=60 time=8.46 ms
64 bytes from 82.197.196.182: icmp_seq=11 ttl=60 time=6.43 ms
64 bytes from 82.197.196.182: icmp_seq=12 ttl=60 time=8.99 ms
64 bytes from 82.197.196.182: icmp_seq=13 ttl=60 time=7.55 ms
64 bytes from 82.197.196.182: icmp_seq=14 ttl=60 time=5.33 ms
64 bytes from 82.197.196.182: icmp_seq=15 ttl=60 time=8.06 ms
64 bytes from 82.197.196.182: icmp_seq=16 ttl=60 time=6.32 ms
^C
--- 82.197.196.182 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15022ms
rtt min/avg/max/mdev = 5.334/7.741/9.284/1.179 ms

% tracepath -np 53 82.197.196.182 
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.0.1.1                                              1.449ms 
 1:  10.0.1.1                                              1.199ms 
 2:  10.0.0.1                                              1.700ms 
 3:  217.19.17.85                                          6.095ms 
 4:  217.19.17.80                                          6.770ms 
 5:  82.197.196.182                                        7.260ms reached
     Resume: pmtu 1500 hops 5 back 5

Repeterende traces zien er allemaal nagenoeg hetzelfde uit. In dit geval is het wel vanuit mijn thuisnetwerk, over mijn eigen router (10.0.1.1) en de Fritz!Box (10.0.0.1) naar buiten. Ik kan dit 100% reproduceren via een laptop met een andere kabel direct op de ONT, maar daar heb ik momenteel geen zin meer in.

Frans-Jan · 3 oktober 2022 om 08:13

Ik begreep dat jullie het verkeer aan het bijhouden zijn. Om de data te kunnen vergelijken, hier een nieuw snapshot van de afgelopen 48 uur.

josn · 5 oktober 2022 om 06:35

Hoi Frans-Jan, ik heb ook even naar de tcpdump gekeken van de eerste serie nslookup. En er komt regelmatig geen response terug. Ik neem aan dat je inkomende ICMP pakketten niet filtert. Dan worden blijkbaar de queries, of de responses daarom stilzwijgend ergens gedropt. Nslookup queried de server met UDP pakketten. Kan je datzelfde experiment eens herhalen met TCP requests? Daar heeft (mijn) nslookup geen optie voor, maar host (-T) en dig (+tcp) wel. Ben benieuwd of je dan ook delays ziet, en of die dan wel resulteren in ICMP responses.
Het valt me ook op in de dump dat je geen enkel ICMP pakket ontvangt. Je stuurt alleen. Misschien toch eens kijken of je toch iets van filtering aan hebt staan… Ik heb eens een traceroute, een tcptraceroute, en een ping naar jouw IP-adres (volgens de dump) gestuurd, en daar komt ook niks van aan. Dus iemand filtert dat… Voor de volledigheid: als je al het inkomend ICMP verkeer dropt kan je dat een hoop problemen opleveren, ook in het uitgaande verkeer…

johan · 5 oktober 2022 om 11:57

Er is geen voor mij geen enkele reden om aan te nemen dat dit in ons netwerk zit. Ten eerste prioriteren we alleen VoIP- en IPTV-verkeer en ten tweede kan ik met enige zekerheid zeggen dat KPN ook geen verkeer prioriteert anders dan IPTV (maar dat zit op een ander vlan). Dit is een individueel probleem, geen netwerkwijd probleem aangezien we anders aanzienlijk meer klachten zouden moeten ontvangen wat dus niet het geval is.

Ik kan hier verder niks mee op afstand en laat de verdere communicatie via de servicedesk verlopen. Zij nemen binnenkort contact op voor een afspraak.

Frans-Jan · 5 oktober 2022 om 12:30

@josn
De dumps kwamen vanaf een laptop direct aangesloten op de ONT, daar zat geen ander apparaat meer tussen. De laptop krijgt op dat moment een ander IP dan de Fritz!Box die normaliter aangesloten is, dus dat IP is inderdaad niet up. Ik filter zelf ook nooit ICMP, na een paar jaar als Network Engineer in een DC leer je dat soort fratsen wel af

@johan
Teleurstellend. Er is voor mij geen enkele reden om aan te nemen dat het niet aan de provider kant zit, aangezien ik de problemen heb ongeacht welk apparaat ik aan de ONT hang. Vanaf de ONT is het probleem van Tweak of van KPN, niet van mij. Tweak hoort hierin KPN aan te sturen, want ik betaal een maandbedrag aan Tweak in ruil voor werkend internet. Dat krijg ik echter niet van jullie terug.

johan · 5 oktober 2022 om 12:35

Dat zal allemaal wel zo zijn, maar ik ben hier niet de servicedesk. Als je klachten hebt moet je niet bij mij zijn. Ik zit hier best-effort op het forum en bied wat ondersteuning waar ik dat direct kan bieden. Dat kan ik hier niet (laat staan andere forumbezoekers), dus ik laat het hierbij. Ik gooi dit topic op slot aangezien het wat mij betreft geen nut heeft om hier op dit medium over verder te discussiëren of te communiceren.

johan · 5 oktober 2022 om 12:35