Skip to main content

Structurele packet loss in Odido backbone (hop 5 - 10.226.4.3) – graag doorzetten naar NOC

  • November 5, 2025
  • 2 reacties
  • 91 Bekeken

Hallo,

Ik ervaar de afgelopen dagen ernstige packet loss en jitter, vooral tijdens de avonduren. Dit veroorzaakt o.a. ping spikes, disconnects en tick delay in games (Old School RuneScape).

Ik heb het probleem volledig doorgemeten met PingPlotter, traceroute en pathping.

Samenvatting

  • Mijn thuisnetwerk is stabiel

  • Opstelling:
    ONT (glasvezel) → Zyxel EX5601-T1 (Odido) → Gigabit switch → PC

    De gigabit switch is een unmanaged Layer-2 switch en introduceert praktisch geen latency of buffering. 
    Het thuisnetwerk is niet aangepast en heeft voorheen nooit problemen veroorzaakt.

    Alle metingen zijn bekabeld uitgevoerd, en het gedrag is identiek wanneer de PC direct op de Zyxel is aangesloten. 
    Hiermee is lokale apparatuur uitgesloten als oorzaak.

  • Tot en met hop 2 is geen packet loss

  • Vanaf hop 5 (10.226.4.3) begint structurele packet loss

  • Deze packet loss propagates naar alle volgende hops → inclusief de game server

Dit wijst naar een probleem in het Odido core/transport netwerk of glasoperator netwerk.

Belangrijke hop (bron van het probleem)

Hop IP Beschrijving
5 10.226.4.3 Odido / Glasoperator backbone-node → structurele packet loss + jitter

Effect in de praktijk

  • Ping spikes (16ms → 400ms+)

  • Freezes in games

  • Packet loss zichtbaar in applicaties

  • Game disconnects

  • Dit is reproduceerbaar, op ieder moment van de dag

Bewijs (screenshots)

Ik heb de relevante screenshots toegevoegd:

  1. PingPlotter naar OSRS server (8.26.41.39) → packet loss zichtbaar

     

  2. PingPlotter specifiek naar hop 5 (10.226.4.3) → zwaar verlies

     

  3. PingPlotter naar 1.1.1.1 → laat jitter zien tijdens dezelfde momenten

     

  4. ping -n 200 1.1.1.1 → stabiel (mijn verbinding is ok)

     

  5. ping -n 200 10.226.4.3 → timeouts (probleem zit in Odido backbone)

     

  6. Herhaalbaarheid / niet applicatie-gebonden
    Het probleem is reproduceerbaar op meerdere OSRS-werelden én op niet-gaming targets (1.1.1.1), wat inconsistent gedrag veroorzaakt en duidt op transport jitter / microbursts, niet applicatielaag.

Verzoek

Graag dit probleem doorzetten naar NOC / core netwerkbeheer, met de vraag om:

  • Capaciteit/queue saturatie op hop 10.226.4.3 te controleren

  • Fysieke linkstatus te controleren (CRC errors / LOS / microbursts)

  • QoS / traffic shaping instellingen te verifiëren

  • Dit gedrag komt overeen met queue congestion / microbursts of capaciteitsdruk in het glas-transportsegment. 
    Omdat het probleem reproduceerbaar is en zich uitsluitend voordoet upstream, verzoek ik vriendelijk om dit 
    door te zetten naar het NOC ter controle van interface load, queue-depth en peering/route-balancing.

Belangrijk t.a.v. monteursbezoek

Omdat het probleem consistent pas begint vanaf hop 5 (10.226.4.3), en alle hops tot en met het LAN en de Zyxel 
stabiel zijn (<1ms / 0% loss), zal een monteur op locatie dit probleem niet kunnen reproduceren of oplossen.

Dit is geen bekabelings- of configuratieprobleem, maar een transport/backbone issue upstream.

Er staat momenteel een monteur gepland op zaterdag 8/11/2025.

Alle testen tonen echter aan dat het probleem niet in mijn woning, modem of wijkkast zit — maar upstream op hop 5 in het transport netwerk.

Een monteur op locatie kan dit naar verwachting niet oplossen.

Ik wil de afspraak niet annuleren, maar graag eerst bevestiging van het NOC of het probleem inderdaad in de backbone ligt.
Mocht het NOC bevestigen dat de backbone de oorzaak is, dan kan de monteur-afspraak eventueel worden aangepast.

November 5, 2025

  1. PingPlotter specifiek naar hop 5 (10.226.4.3) → zwaar verlies

     

Even afgezien van de packet loss die je in een applicatie of spel hebt… waarom denk je dat 10.226.4.3 een probleem heeft?? Dit zijn forwarding servers die niet hoeven te reageren op PING/ICMP en dat dus dikwijls ook niet (tijdig) doen (vandaar die loss). Je kunt daar echter niets aan afleiden. Alleen de packet loss en ping naar je eind hop is in deze echt van belang.

Lees b.v. het stukje onder “MTR #2: Packet loss - or is there?” maar eens door:
https://www.cloudflare.com/learning/network-layer/what-is-mtr/

Al het packet loss in de tussenhops bij een traceroute kunnen dus gewoon normaal zijn en hoeven niet op een probleem te wijzen.

Je ziet wel 0,1% packet loss naar 8.26.41.39. (daaraan zie je dus ook dat de packet loss van de tussenhops hier geen invloed op hebben want die tussenhops hoeven niet te reageren). Maar dat is op 900 pakketjes slechts 1 pakketje.

Je ziet echter wel 1,9% verlies bij je 1.1.1.1 voorbeeld. Dat zijn 18 pakketjes. Dat lijkt mij problematischer. Een lijnmeting (e.v. onder stresscondities) lijkt me dan geen overbodige luxe maar het probleem wijst volgens mij niet direct naar een van die tussenhops.

Je kunt ook eens testen met https://packetlosstest.com/ (en dan spelen met de waarden) om de packetloss onder stress condities te bekijken.

2 reacties

rvk01
  • rvk01
  • November 5, 2025

  1. PingPlotter specifiek naar hop 5 (10.226.4.3) → zwaar verlies

     

Even afgezien van de packet loss die je in een applicatie of spel hebt… waarom denk je dat 10.226.4.3 een probleem heeft?? Dit zijn forwarding servers die niet hoeven te reageren op PING/ICMP en dat dus dikwijls ook niet (tijdig) doen (vandaar die loss). Je kunt daar echter niets aan afleiden. Alleen de packet loss en ping naar je eind hop is in deze echt van belang.

Lees b.v. het stukje onder “MTR #2: Packet loss - or is there?” maar eens door:
https://www.cloudflare.com/learning/network-layer/what-is-mtr/

Al het packet loss in de tussenhops bij een traceroute kunnen dus gewoon normaal zijn en hoeven niet op een probleem te wijzen.

Je ziet wel 0,1% packet loss naar 8.26.41.39. (daaraan zie je dus ook dat de packet loss van de tussenhops hier geen invloed op hebben want die tussenhops hoeven niet te reageren). Maar dat is op 900 pakketjes slechts 1 pakketje.

Je ziet echter wel 1,9% verlies bij je 1.1.1.1 voorbeeld. Dat zijn 18 pakketjes. Dat lijkt mij problematischer. Een lijnmeting (e.v. onder stresscondities) lijkt me dan geen overbodige luxe maar het probleem wijst volgens mij niet direct naar een van die tussenhops.

Je kunt ook eens testen met https://packetlosstest.com/ (en dan spelen met de waarden) om de packetloss onder stress condities te bekijken.

  • DevNetLink
  • heeft eerste post geplaatst
  • November 5, 2025

Ik zie op mijn glasvezelverbinding hetzelfde gedrag. Toegenomen latency & jitter in de avonduren (tussen 20u-22:30). Een simpele traceroute lijkt inderdaad ook aan te geven dat het in het odido netwerk zit. Ik zie inderdaad ook tussen de 2-3 procent packet loss op een lange ping richting diverse cloudproviders.

Overdag is de latency naar cloudflare/azure rond de 8 a 9 milliseconden; in de avond uitschieters naar 60-70 milliseconden. Dat is best lastig als je regelmatig een teams-call hebt in de avond :)

Gedrag is begonnen op 3 november, daarvoor was de connectie gewoon stabiel. Ook ik heb de klantenservice gebeld, maar kwam ook niet verder dan “we sturen een monteur”. Die wil ik met alle liefde een kop koffie geven, maar ik ben bang dat de beste man/vrouw voor niets gaat komen.
 

 

    ForumvoorwaardenAccessibility statement