Packet loss en latencyproblemen op route naar Contabo cloudserver na de KPN server

Bij een traceroute moet je alleen naar het eindpunt kijken wat betreft packet loss. Alle tussenpunten zijn niet verplicht om (tijdig) op ICMP te reageren (die kun je alleen gebruiken om oplopende latency te diagnoticeren). Dus vaak zie je daar packet loss, wat helemaal niet erg is.

Maar bij jou zie ik bij het eindpunt een packet loss van 37% staan. Ja, dat is wel een probleem.

Maar ik zie dat je ook alleen op poort 443 test.
Wat doet diezelfde test zonder poort? (dus gewoon standaard ICMP ?)

Kan het dus niet aan een rate-limiting van de HTTPS server zijn op de doelserver?
(die vinden het meestal niet zo leuk om in 1 keer met 100 request gebombardeerd te worden 😂)

Overigens nog een overweging… je doet een MTR naar een HTTPS server?

Maar MTR voltooid de TLS handshake nooit. En dan zal de server vaak bij de volgende connectie, die connectie droppen. Dat is eigenlijk bij de meeste HTTPS server zo. Test het maar eens naar een andere server.

Als je echt wilt testen dan zou je gewoon een loopje moeten maken om HTTPS te testen.

Bijvoorbeeld dit (Linux voorbeeldje):

for i in {1..100}; do
  curl -o /dev/null -s -w "%{time_connect}s connect  %{http_code}\n" https://www.domein.com
  sleep 3
done

Je zou de sleep 3 eruit kunnen halen als je veel achter elkaar wilt testen (tot je eventueel tegen een ratelimit van de HTTPS server zelf aanloopt).

Hallo, bedankt dat u de tijd neemt om dit te bekijken en advies te geven.

In dit geval begint de packet loss op tussenliggende transit-hops (bijv. 84.116.x.x / 62.115.x.x), en niet bij de eindbestemming.  Aangezien dit TCP SYN-probes zijn, heeft dit geen betrekking op de HTTPS-dienst op de server zelf.

Zoals te zien is in de MTR uit mijn eerste bericht, worden pakketten vanaf KPN al in het netwerk gedropt voordat ze de server bereiken. Dit komt overeen met de time-outproblemen die ik heb waargenomen bij het doelsysteem.

Het is ook vermeldenswaardig dat dezelfde MTR-tests vanaf andere providers 0% packet loss laten zien op zowel de carrier-hops als de eindbestemming, bijvoorbeeld:

# mtr -T -P 443 -nrc 100 62.84.183.X

Start: 2026-04-02T21:12:42+0000
HOST: VM-05b3189b                 Loss%   Snt   Last   Avg  Best  Wrst StDev

  1.|-- 37.48.X.X                  0.0%   100    0.6   0.5   0.3   0.8   0.1

  2.|-- 5.79.X.X                   0.0%   100    0.4   0.4   0.3   1.1   0.1

  3.|-- 81.17.X.X                  0.0%   100    0.5   1.0   0.4   7.8   0.9

  4.|-- 62.115.48.X                0.0%   100    0.8   0.8   0.6   3.9   0.3

  5.|-- 62.115.116.X               0.0%   100    1.3   1.3   1.1   1.6   0.1

  6.|-- 62.115.120.X               0.0%   100    8.1   8.2   7.9   9.4   0.2

  7.|-- 62.115.136.X               0.0%   100   12.8  12.9  10.9  14.5   0.8

  8.|-- 213.248.67.X               0.0%   100   10.2  18.6  10.0 319.5  45.1

  9.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

 10.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

 11.|-- 62.84.183.X                0.0%   100   14.4  12.4  10.3  35.1   3.4

Wat we in de MTR in mijn eerste bericht zien, is congestie of instabiliteit in het upstream netwerkpad.

Dergelijke problemen kunnen meestal worden opgelost door het verkeer via een gezondere upstream carrier te routeren. Hoe gaat KPN om met dit soort situaties?

Dank voor je uitgebreide toelichting en de MTR-gegevens, dat helpt echt om een beter beeld te krijgen van wat er speelt.

Als ik zo naar je metingen kijk, dan lijkt het er inderdaad op dat het probleem niet in je eigen netwerk zit. De eerste hops binnen het KPN-netwerk zien er netjes uit, en de afwijkingen beginnen pas verderop in het pad, op transitniveau.

Wat daarbij wel belangrijk is om in het achterhoofd te houden, is dat packet loss op tussenliggende hops in een MTR niet altijd betekent dat daar ook daadwerkelijk verkeer wordt gedropt. Veel routers prioriteren forwarding boven het beantwoorden van dit soort probes, waardoor ze in dit soort tests “verlies” laten zien terwijl het daadwerkelijke verkeer gewoon doorgaat.

Dat gezegd hebbende: omdat je aangeeft dat je ook daadwerkelijk impact ervaart op TCP-verkeer én dat dezelfde tests via andere providers wél stabiel zijn, is het niet ondenkbaar dat er ergens in de keten sprake is van congestie of een minder optimale route. Dat hoeft overigens niet per se binnen het KPN-deel te zitten, maar kan net zo goed in een upstream/transitpartij liggen.

Hoe heb je dit trouwens met getest met andere providers als ik vragen mag?  En heeft de dienst waar je gebruik van maakt ook een forum of iets dergelijks? Heb je het issue daar ook al aangekaart?

Met betrekking tot jouw vraag: Hoe gaat KPN hier mee om.    Via de gewoon klantenservice zal je niet snel iets bereiken. Die zijn hier niet op ingericht.  Ik kan, als moderator wel een specialist inschakelen maar dan moet ik wek échte indicaties hebben dat het iets met het KPN Netwerk te maken heeft. Ik vind dat tot nu toe een beetje twijfelachtig om eerlijk te zijn. Maar wie weet kun je mij overtuigen.