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?