Skip to main content
Vraag

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

  • April 1, 2026
  • 2 reacties
  • 13 keer bekeken

Hallo,

Ik ondervind verbindingsproblemen vanaf mijn KPN-verbinding naar een cloudserver.

Meerdere TCP MTR-tests (poort 443) naar deze server tonen consistent packet loss en hoge latencypieken, beginnend kort na het KPN-netwerk:

# mtr -T -P 443 -nrc 100 62.84.183.X (weggelaten om privacyredenen)
Start: 2026-04-01T17:32:03+0200

HOST: vm51.home                  Loss%   Snt   Last   Avg  Best  Wrst StDev

  1.|-- 192.168.2.254              0.0%   100    2.3   2.1   1.5   5.8   0.7

  2.|-- 195.190.228.126            0.0%   100    3.8   4.2   3.2   8.4   0.8

  3.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

  4.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

  5.|-- 84.116.136.178            57.0%   100  7098. 955.8   7.0 7137. 2317.4

        4.68.37.173

        84.116.136.62

  6.|-- 84.116.136.61             85.0%   100  7123. 2658.   9.9 7123. 3011.5

        84.116.134.54

  7.|-- 213.248.67.11             30.0%   100   16.4  21.1  15.5 176.1  22.6

        62.115.45.149

  8.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

  9.|-- 62.115.45.149             66.0%   100   16.8  16.9  15.9  21.0   0.8

        213.248.67.11

 10.|-- 62.84.183.X              37.0%   100   17.3  20.7  16.9  29.6   3.1

De eindbestemming blijft bereikbaar, maar met verminderde kwaliteit (~20–40% packet loss).

Reverse tests en metingen vanaf andere netwerken richting de VPS zijn grotendeels stabiel. Dit wijst erop dat het probleem specifiek verkeer vanaf KPN betreft. Het probleem heeft ook impact op daadwerkelijk TCP-verkeer (niet alleen ICMP).

Vraag:
Kunnen jullie mogelijke congestie- of routingproblemen onderzoeken op upstream/transitverbindingen (bijvoorbeeld via Telia of Lumen)?

Alvast bedankt voor de ondersteuning.

2 reacties

rvk01
Slimmerik
  • April 1, 2026

Meerdere TCP MTR-tests (poort 443) naar deze server tonen consistent packet loss en hoge latencypieken, beginnend kort na het KPN-netwerk:

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 😂)

 


rvk01
Slimmerik
  • April 1, 2026

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).