Om de oorzaak of oorzaken te achterhalen gestructureerd te werk gaan en onderscheid maken in de verschillende netwerkbouwstenen en netwerklagen, zie OSI model

Simpel te zeggen is al dat, als de packetloss oorzaak in PHY zou zitten (DSL), je dan voor alle hosts in dat mtr rijtje min of meer dezelfde packetloss zou moetren zien. Maar het is alleen maar voor node/host 139.*

Dus alle FW zaken m.b.t. DSL doen er eigenlijk niet toe, je zou ook met een ExperiaBox met niks erachter behalve een pfSense/router als DMZ host hetzelfde moeten zien.

Heb je ook een daadwerkelijke applicatie (b.v. youtube via HTTP3/QUIC) als voorbeeld van het probleem?

Het zit in ieder geval niet bij jouw thuis en KPN (1 van de vele bedrijven in de holding) is aan zet om er voor te zorgen dat ergens rondom die 139.* node o.i.d. zaken worden gefixed.

Ik snap dat het inderdaad lastig te pinpointen is, maar ik heb het idee dat het slechter is geworden sinds ik de ExperiaBox er tussenuit heb gehaald. 

Ik heb inderdaad lasten van network issues in applicaties, waaronder ook youtube. Maar ik heb zelf redelijk wat uitgaand ICMP en UDP verkeer, en daar merk ik het het best aan. 

Ook merk ik dat de snelheid minder is dan op de ExperiaBox, nou vind ik dat niet zo erg, maar ik heb het idee dat hij ook heel erg fluctueert. 

Naast packet loss buiten de deur kan het tegelijkertijd zo zijn dat DSL niet optimaal loopt. Daarvoor moet je dan diep in de DSL zaken duiken, dus welk DSL profile is actief, enz, enz. En eerst specs vergelijken, de EBv10 en EBv10a en https://www.draytek.com/products/vigor2860/#specs zijn alle 3 verschillend voor zover ik nu weet. Waarom gebruik je de Draytek? Wil je bridgemode? Is DMZ niet voldoende?

Ik had op de EBv10 het 17a profile. Op de draytek gaat hij ook automatisch hierop, dus dat lijkt het probleem niet. 

De reden dat ik naar draytek toe ben gegaan is idd de bridgemode. Ik heb applicaties draaien die niet met double NAT overweg kunnen (dus ook DMZ niet). Tevens is de experiabox zo erg beperkt in functionaliteiten dat dit voor mijn doeleinden niet toereikend is. (Simpel voorbeeld: DNS resolver).

Als KPN met een modem kwam dat ik bridge mode kan, zouden er heel veel problemen opgelost zijn voor heel veel gebruikers (verwacht ik). 

Ik ga vandaag of morgen nog maar wat andere firmware versies testen, wellicht heb ik daar betere resultaten mee.

Als je andere firmware gebruikt of wilt testen zul je ook criteria of meetmethodes moeten hebben. Dus kijken of je de DSL logs o.i.d. een aantal uren of dagen kan opslaan zodat je op het 1 en ander kan doorzoeken en vergelijken op een andere/latere meetsessie.

Persoonlijk zou ik alle apllicaties die niet met NAT om kunnen kunnen gaan eruit werken, vervangen door iets moderners. Ondanks dat wellicht bij KPN binnen afzienbare tijd bridgemode op eigen modemrouter formeel tot de mogelijkheden behoort.

NAT is geen probleem, maar double NAT wel.

Betreffende die instabiele host in de trace. Kan ik KPN daar over benaderen? Of gaat dit zo een ding worden wat over een jaar een keer wordt opgemerkt en iets aan wordt gedaan?

Misschien duurt het lang, geen idee, maar je bent niet de enige:

https://forum.kpn.com/internet-9/hoge-packetloss-bij-kpn-server-490733

Hoi Ginjo, welkom! Ik had nog niet eerder gereageerd omdat je gebruik maakt van een Draytek, wat officieel buiten onze ondersteuning valt. Maar over de ‘packet loss’ kan ik nog wel aangeven dat  onze core servers, in de 13x-range, beperkt reagern op pingverzoeken. Dat betekent dat op momenten dat zij niet reageren, je daar in een pingplotter packet loss ziet. De data wordt echter wel gewoon doorgezet. Dus een test als deze kan niet als definitief bewijs worden gezien dat er bij ons iets aan de hand is.

Ik raad je aan om met Draytek in overleg te gaan welke van de firmwareversies in jouw situatie het beste gaat werken.

Hallo Erik, Bedankt voor je antwoord. Inmiddels ben ik naar een vigor 165 met VVDSL overgestapt en heb een veel stabielere verbinding. 

Echter heb ik alsnog problemen op het gebied van packet-loss. In de bijlage zie je de monitoring-probes die we hebben draaien om externe connecties te checken. Je ziet veel icmp, udp en soms zelfs tcp packetloss. 

Ook met de EB ertussen heb ik dit probleem nog.

Fijn dat de verbinding wel stabieler is. Deze probes, monitoren die daadwerkelijk verkeer, of doen ze pingtests? In dat laatste geval zou ik verwachten dat het hier alsnog gaat om niet-reageren-op-ping in plaats van daadwerkelijke problemen. Ook wel opvallend dat het steeds 16% is. 

Pingtests en regulier traffic (zowel udp als tcp).

16% Is omdat de probes enkele pings uitvoeren en er dan 1  van de pings mislukken. Soms is dit ook hoger. 

Toevallig heb ik ook zo’n zelfde soort probleem met het uploaden van bestanden naar een Server in het Coloclue netwerk in het euNetworks datacenter (Amsterdam). Dan heb ik op een gegeven moment ook een packetloss van 80%+ en mijn uploadsnelheid varieert tussen de 5MB/s - 8MB/s op mijn 200/200mbit verbinding (Glasvezel).

Daarbij heb ik een iperf3 uitgevoerd richting een iperf3 server in Frankrijk en Estland en daar krijg ik zo rond de 13 - 17MB/s transfer. Dus waar ligt dit nou uiteindelijk aan? Ben inmiddels ook al een paar dagen aan het troubleshooten en begin er wel gek van te worden om soms mensen lastig te vallen met deze vraag en ik met dit probleem blijf zitten.

Coloclue netwerk en thuisnetwerk hebben qua snelheden geen problemen.

Probleem met dit soort dingen is dat het voor ons ook heel lastig is om de vinger op te leggen. Dit zijn in de basis problemen waar de klantenservice in het algemeen eigenlijk niet mee kan helpen. Niet omdat de collega's niet willen, maar omdat het iets is wat niet door onze technische systemen gezien kan worden.

Nu hebben we hier op het forum het voordeel dat je wel makkelijk meer info kunt geven (als klant zijnde) qua tekst en afbeeldingen. En hebben wij wat meer tijd om naar dingen te kijken. Maar dan blijft wel dat het toch vaak een zaak van de lange adem is. En ik ook niet kan garanderen dat we hier uit gaan komen.

Dat allemaal gezegd hebbende:

Ginojo: jouw situatie is lastiger omdat je de Draytek gebruikt. Dat ondersteunen we officieel niet, waardoor ik eigenlijk niet kan troubleshooten bij en met jou zolang je de Draytek gebruikt. Vanuit die richtlijn kan ik je wel wijzen op de Techdesk. Dat is een optie die je aan je abonnement kunt toevoegen voor €5 per maand (nu nog alleen bij Hussel abonnementen, op korte termijn ook bij de rest). Als je dan belt wordt je in alle gevallen doorverbonden naar hen. Die collega's kunnen wel helpen. Is alsnog geen garantie dat het dan opgelost kan worden terwijl de Draytek aangesloten zit, maar ze kunnen het in ieder geval met je gaan bekijken.

Apollo: gebruik jij ook eigen apparatuur, of een Experia Box? Als je géén Experia Box gebruikt, dan is de eerste vraag die ik ga stellen toch: ervaar je dit ook met een Experia Box?

Als je het ook hebt met een Experia Box, plaats hier dan je testresultaten, metingen, etc… Geef ook even aan hoe je eigen netwerk in elkaar zit, of daar dingen zijn die van invloed kunnen zijn, etc...

Het is de zwakste schakel op de route tussen jouw PC en de server die bepaalt wat de gerealiseerde download snelheid is.

Laatst moest ik een backup van een Microsoft SQL database downloaden met een grootte van ongeveer 180GB vanaf een Azure cloud.

Mijn 200Mbps lijntje was 2,5 uur lang tot het randje gevuld waarbij er constant 20MB per seconde gedownload werd. En ondertussen bleef de televisie probleemloos werken. 

Dit is zo ongeveer de enige locatie vanwaar ik dergelijke snelheden heb mogen ervaren, vaak mag je blij zijn als je 5MB binnenhaalt omdat er ergens op het pad nog wel een zandweggetje overbrugt moet worden.

@ginojo Kijk of je een VPS (tijdelijk) kan regelen waarop je dezelfde mogelijkheden hebt als met een allround (virtuele) computer thuis. Of iemand anders met een computer die je wil helpen. Dan kun je met b.v. netcat een groot bestand via UDP overdragen (van de VPS/iemand anders naar jouw thuis). Als het bestand bij de bron maar bekende grootte heeft. Als na beeindiging van de transfer aan de bron kant, het bestand thuis kleiner is, weet je genoeg. E.v.t. kan je de transfer flink knijpen tot een paar kbps (met b.v. de tool pv) zodat het urenlang duurt en het een echte uitdaging voor de gehele netwerkinfrastructuur kan worden. Desgewenst aan beide zijden een sha256sum genereren en vergelijken.

Aan een TCP link zelf kun je ook wel zien of er paketten verloren gaan, b.v. met wireshark en dan iets van "Follow TCP Stream" instellen op een transfer via TCP. Heb je dus geen 2 eindpunten nodig, alleen jouw thuis.

Een tijd terug was er voor SIB4G (mobiel) klanten ook nogal packetloss, wat duidelijk impact op DNS had (faalde gewoon, websurfen werkt gewoon niet). Workaround was DNS via HTTPS (dus via TCP, met hetrtransmissie dus).

Toevallig vandaag de storingsmonteur langsgekomen na een belletje naar KPN over deze kwestie. Iemand heeft voor mij een meting kunnen doen binnen mijn IP range en het schijnt dat er iets met mijn WBA aan de hand is. Waarschijnlijk komt dit door het verhuizen of doordat ik een paar maanden terug van 100mbit naar 200mbit glasvezel ben gegaan. De monteur kwam met het volgende: “Je apparatuur ziet er prima uit, alles ziet er goed uit. Verbindingslijn ziet er ook goed uit is helemaal groen en iemand anders heeft die test ook gedaan en kreeg hetzelfde”. Terwijl de persoon die ik afgelopen woensdag aan de lijn had totaal iets anders zei, maar goed. Hij zei tevens dat er 2 IP adressen zijn geregistreerd op mijn adres, toen dacht ik al van huh, kan het hierdoor komen dat mijn uploadsnelheid niet hoger dan 5MiB/s komt??

Monteur kon verder niks doen maar wil er wel voor zorgen dat het wordt opgelost, dus hij zet het door naar een team wat mijn klantprofiel zal nakijken en de oorzaak van de 2 IP adressen zal achterhalen.

@Erik_  Ik heb eigen apparatuur alleen ik gebruik de ExperiaBox V10 nog voor het bellen (KPN kan deze box ook bereiken kwam ik achter). Heb de uploadsnelheid ook met de ExperiaBox V10 getest en dit blijkt hetzelfde te wezen (Jammer)… Ik zal KPN af moeten wachten waarschijnlijk en kijken waar zij mee komen…

Tevens de testresultaten dat zijn er een hele boel, speedtest geeft overigens wel gewoon 200mbit down en 300mbit up aan, wat heel raar is.

Met de server in Amsterdam heb ik bijna een directe verbinding met amper wat hops (5 MAX).

Dat is ook wel logisch immers de Experia Box staat dan bridged op vlan 7 en is op dat vlan dan ook prima te benaderen. 

Ik ben wel benieuwd hoe jij die Experia Box aangesloten hebt en of daar alleen vlan 7 gebridged op aangeboden wordt.

Ik heb de Edgerouter X en het script gebruikt hiervoor gebruikt.

Hierbij de config:

Ben alsnog benieuwd wat de reden kan wezen van die dubbele IP adressen, lijkt me niet dat dit door een simpele ‘upgrade’ komt..

Dat ziet er goed uit, de Experia Box is op eth1 aangesloten en zit dus alleen op vlan 7.

Dat is dus niet een mogelijke oorzaak voor de 2 IP adressen.

Is dat in iedergeval uitgesloten, ik denk dat het toch iets te maken heeft met onze verhuizing en dat wij de experiabox hebben meegenomen of dat we een upgrade in internet snelheid hebben begaan...