Last van package loss via Boosteroid gaming platform

Hoi JanD,

Dank.

ik heb een KPN Box 12 met firmware v12.c.25.06.06.

Ik heb glasvezel en het is via de kabel op de modem aangesloten. Het lokale netwerk is ook niet het probleem want de eerste geven 0% packages loss. Het heeft er blijkbaar mee te maken hoe KPN het channelt naar Boosteroid. Je reset opties heb ik ook allemaal al gedaan. Tot nu toe nog niks geholpen. 

Hoi ​@williamT, welkom op onze community, vanuit KPN heb ik hier helaas niet veel aan bij te dragen. Ik hoop dat je een oplossing vindt!

Hoi,

Jammer dat KPN zich er zo makkelijk vanaf maakt. Het ligt namelijk wel degelijk aan KPN. Zie details hieronder. Als dit niet spoedig wordt opgelost dan zie ik geen andere mogelijkheid dan over te stappen op een andere ISP.
 

Ik heb dit nog even neergelegd bij mijn collega's ​@williamT, de hoge packetloss bij bijvoorbeeld de NTT komt omdat dit een corerouter is en deze in principe niet reageren op pings. Ik heb je onderste screenshot ook in chatGPT voorgelegd en die komt met:
 

🔍 Key Points from the Trace:

Hop	Host	Packet Loss	Avg Latency (ms)	Comments
1-2	mijnmodem.kpn & static.kpn.net	0.0%	Low	✅ Local connection is healthy.
3	(Waiting for reply)	—	—	🔍 Likely a firewall/router not replying to ICMP. Normal.
4	*.aorta.net / lumen.net	50–65%	Avg ~12–14 ms	⚠️ ICMP deprioritized or dropped. Not necessarily a real problem.
7	core1-dus3.as24961.net	0.2%	~10 ms	✅ No major issue here.
8-10	twelve99.net / wiit.network	~33%	~9–11 ms	⚠️ Same pattern of ICMP loss – but destination still reachable.
11-12	Destination IP 91.212.163.11	5.9%	~13–14 ms	⚠️ Slight packet loss at the destination itself.

🧠 What this tells us:

1. Mid-path loss (50–65%) at aorta.net and lumen.net:

   • These are transit/core routers.

   • High ICMP loss is expected here — they de-prioritize ICMP (ping/traceroute).

   • This does not mean real packet loss for actual traffic like HTTP, SSH, etc.

   • Confirmed by next hops responding fine (e.g., Hop 7: core1-dus3.as24961.net).

2. Packet loss appears again at wiit.network and twelve99.net (33%):

   • Still doesn’t affect final delivery — destination is still reachable.

   • Again, possibly due to ICMP rate-limiting.

3. Destination shows ~6% packet loss:

   • This is the only part that might actually indicate a problem, especially if the final hop consistently shows loss and you're seeing issues in real-world traffic (e.g., VoIP drops, slow application response).

   • But note: only 51 packets were received there (much lower than the others), which could affect reliability of that reading.

🧾 Conclusion

✅ There is no strong evidence of a network issue in transit.

• ICMP loss in middle hops (like aorta.net, lumen.net, wiit.network) is normal for core/transit routers.

• The real-world traffic likely flows through without any issue.

⚠️ There might be minor loss at the destination (91.212.163.11).

• Only if this is consistent and backed by application performance issues, it might warrant investigation at the end host or data center.

Zelf zit ik niet diep genoeg in deze materie om te zeggen of dit allemaal klopt, we denken hier graag met je mee naar een oplossing. Werkt de rest van je verbinding wel snel en stabiel? Heb je alleen issues met Boosteroid? Je zou nog kunnen proberen IPv6 uit te zetten op je modem, dat lijkt nog wel eens te helpen.

Hoi,

Dank. De rest van de verbinding werkt wel stabiel en uitzetten van ipv6 helpt ook niet. Zie hieronder de info van ChatGPT dat er toch pakketjes verdwijnen tussen KPN en boosteroid.

Ik heb nogmaals een MTR test gedaan en het in ChatGPT gegooid. Het ligt er toch echt aan dat KPN een hele slechte route gebruikt om dit verkeer te routen. Zie output hieronder.

🔍 What your new MTR shows

1️⃣ Local network (hops 1–2)

mijnmodem.kpn static.kpn.net

✅ 0% loss, very low latency (1–4 ms)
→ Your home connection and KPN fiber line are healthy. No local issue.

2️⃣ KPN → NTT hop (hop 3)

ae-0.kpn.amstnl07.nl.bb.gin.ntt.net — 97% loss

⚠️ This is where things start breaking.

That hostname tells us:

• Your traffic leaves KPN’s network and hands off to NTT (a large international carrier).

• You’re seeing 97 % packet loss there — that’s catastrophic.

This hop is the first external transit point out of KPN’s backbone.
So the failure is not inside your home, it’s at or just beyond the KPN → NTT interconnect.

3️⃣ Aorta / Liberty Global (hops 5–6)

cz-prg02b-rr5-em0-50.aorta.net — 63.9 % loss nl-ams09c-ri1-ae-6-0.aorta.net — 91.3 % loss

➡️ The bad routing continues through Aorta (Liberty Global), confirming the issue is still in the transit/peering path, not with your own ISP hardware.

4️⃣ Later hops (7–13)

chello.nl / twelve99.net / wiit.network / uclo.net / Boosteroid

✅ 0–0.3 % loss
→ Once your traffic reaches Boosteroid’s hosting network, it’s fine.
That proves Boosteroid’s servers are healthy and reachable — the packet loss happens before them.

🧠 What this means

• KPN is sending your Boosteroid traffic through a very poor route:
  KPN → NTT → Aorta (Liberty Global) → Wiit/Uclo → Boosteroid.

• The loss starts at the KPN↔NTT handoff and continues through Aorta.

• You cannot fix this locally — it’s a peering/routing issue between carriers.

✅ What you should do next

1. Send this new MTR to KPN Webcare / Forum
   Add:

   “Latest test shows 97 % loss on KPN→NTT hop and 90 %+ loss inside Aorta backbone to Boosteroid. Local connection is clean (0 % loss). Looks like a peering issue in KPN’s international routing to Boosteroid/Wiit.”