Skip to main content
Beantwoord

Packet loss naar cloudflare en akimei (calls vallen weg)

R7JQ7CDVQ (192.168.1.156) -> 1.1.1.1 (1.1.1.1)                                                       2025-07-23T10:14:42+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                      Packets               Pings
 Host                                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. setup.ui.com                                                                     0.0%   132    3.6   3.4   2.6  20.4   1.6
 2. 1<REDACTED>.ftth.glasoperator.nl                                                0.0%   132   10.4   8.6   7.0  11.6   1.0
 3. 10.227.169.159                                                                   0.0%   132    8.6   7.8   6.1  21.2   1.6
 4. 10.226.11.40                                                                     0.0%   132    8.0   7.8   5.7  10.9   0.9
 5. 141.101.65.141                                                                  50.0%   131   11.3  26.0  10.0 162.2  32.1
 6. ams-ix.as13335.net                                                               0.0%   131   31.3  12.6   7.6  36.1   6.0
 7. 141.101.65.141                                                                   0.0%   131   10.4  15.8   9.5  77.1  10.6
 8. one.one.one.one                                                                  0.0%   131    9.3   8.5   6.6  13.7   1.2

 

LR7JQ7CDVQ (192.168.1.156) -> nu.nl (2.18.244.76)                                                     2025-07-23T10:10:57+0200

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                                                                      Packets               Pings

 Host                                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. setup.ui.com                                                                     0.0%    87    2.8   3.5   2.5  12.1   1.2

 2. 1<REDACTED>.ftth.glasoperator.nl                                                0.0%    87    7.5   8.7   6.6  14.7   1.3

 3. 10.227.169.159                                                                   0.0%    87    8.0   8.3   6.6  17.1   1.4

 4. 10.226.11.42                                                                     0.0%    87    9.3  10.9   9.2  15.3   1.1

 5. 192.168.224.7                                                                   13.8%    87   11.7  28.1   9.2 225.9  54.3

 6. (waiting for reply)

 7. 192.168.224.7                                                                   79.1%    87   11.5  10.6   9.2  12.0   0.8

 8. 192.168.225.163                                                                  0.0%    87    7.3   8.4   6.6  10.8   0.9

 9. a2-18-244-76.deploy.static.akamaitechnologies.com                                0.0%    87    7.8   8.3   6.8  11.4   0.9



Ik heb vaak dat discord slack en teams calls kort wegvallen 2 seconden nu zie ik dat ik heel veel packages gedropt heb als ik probeer te kijken naar de route naar paar grote cdn is dit normaal of is er iets fout met peering bij de odido kant? ik zit op het delta glasvezel netwerk als dat uitmaakt.

Ik kan ook alle andere tools uitvoeren als het nodig is het duidelijk niet in mijn eigen netwerk want het heeft mijn modem al verlaten

Beste antwoord door yorde

​@Cheyenne van Odido ​@yorde 

Ik kan niet zien met welk commando deze getallen naar voren zijn gehaald (niet het standaard tracert of traceroute commando).

Maar bij een traceroute is het normaal dat er tussenstations zijn die paketten laten vallen. Niet alle tussenstops op een traceroute reageren n.l. op een ping. Een traceroute is dus geen tool om packetloss te bekijken.

​@yorde Je geeft verder weinig aan over je setup. Heb je getest met een bekabelde computer direct op de Zyxel? Of heb je andere apparatuur?

Kun je de standaard ping tests e.d. naar 1.1.1.1 en 8.8.8.8 eens doen (ping 1.1.1.1 -n 100 en ping -n 100 8.8.8.8). Heb je dan ook lost packages? Wat geeft de onderste 4 regels van het resultaat van die commandos?

 

 

Many network operators (including Cloudflare) set arbitrary limits on the amount of ICMP packets that are allowed to reach the control plane of a router. (The control plane is the router's brain.) A packet that exceeds a router's TTL has to be processed by the control plane. To prevent the control plane from being overwhelmed by too many of these packets, a rate limit (or policer) is put in place, which is why we see all that loss on the intermediary hops, but not the final hop: the control plane rate limits for the routers on the intermediary hops were exceeded, so Type 11 packets were not sent back for the traceroute packets past those limits, but the packets were able to get through to the destination safely.

Dat legt het een andere oook direct uit sorry voor verkeerd door geven dank je wel voor je tijd en hulp. Het was duidelijk een fout met hoe ik het resultaat las.

Bekijk origineel

5 reacties

Cheyenne van Odido
Moderator
Forum|alt.badge.img+5

Hi ​@rvk01, zou jij hier misschien naar kunnen kijken? Mega bedankt alvast!

Neem alvast een kijkje in onze Wiki: https://community.odido.nl/knowledge-base
rvk01
  • rvk01
  • July 29, 2025

​@Cheyenne van Odido ​@yorde 

Ik kan niet zien met welk commando deze getallen naar voren zijn gehaald (niet het standaard tracert of traceroute commando).

Maar bij een traceroute is het normaal dat er tussenstations zijn die paketten laten vallen. Niet alle tussenstops op een traceroute reageren n.l. op een ping. Een traceroute is dus geen tool om packetloss te bekijken.

​@yorde Je geeft verder weinig aan over je setup. Heb je getest met een bekabelde computer direct op de Zyxel? Of heb je andere apparatuur?

Kun je de standaard ping tests e.d. naar 1.1.1.1 en 8.8.8.8 eens doen (ping 1.1.1.1 -n 100 en ping -n 100 8.8.8.8). Heb je dan ook lost packages? Wat geeft de onderste 4 regels van het resultaat van die commandos?

 

    • yorde
    • Auteur
    • is een Top Poster
    • July 29, 2025

    het is de mtr comand https://www.cloudflare.com/learning/network-layer/what-is-mtr/ 
    bekablede computer (aangeloten op een unifi firewall) maar het lijkt opgelost te zijn. 

    • yorde
    • Auteur
    • is een Top Poster
    • Antwoord
    • July 29, 2025

    ​@Cheyenne van Odido ​@yorde 

    Ik kan niet zien met welk commando deze getallen naar voren zijn gehaald (niet het standaard tracert of traceroute commando).

    Maar bij een traceroute is het normaal dat er tussenstations zijn die paketten laten vallen. Niet alle tussenstops op een traceroute reageren n.l. op een ping. Een traceroute is dus geen tool om packetloss te bekijken.

    ​@yorde Je geeft verder weinig aan over je setup. Heb je getest met een bekabelde computer direct op de Zyxel? Of heb je andere apparatuur?

    Kun je de standaard ping tests e.d. naar 1.1.1.1 en 8.8.8.8 eens doen (ping 1.1.1.1 -n 100 en ping -n 100 8.8.8.8). Heb je dan ook lost packages? Wat geeft de onderste 4 regels van het resultaat van die commandos?

     

     

    Many network operators (including Cloudflare) set arbitrary limits on the amount of ICMP packets that are allowed to reach the control plane of a router. (The control plane is the router's brain.) A packet that exceeds a router's TTL has to be processed by the control plane. To prevent the control plane from being overwhelmed by too many of these packets, a rate limit (or policer) is put in place, which is why we see all that loss on the intermediary hops, but not the final hop: the control plane rate limits for the routers on the intermediary hops were exceeded, so Type 11 packets were not sent back for the traceroute packets past those limits, but the packets were able to get through to the destination safely.

    Dat legt het een andere oook direct uit sorry voor verkeerd door geven dank je wel voor je tijd en hulp. Het was duidelijk een fout met hoe ik het resultaat las.

      rvk01
      • rvk01
      • July 29, 2025

      Geen probleem. Fijn dat het opgelost is. 

        ForumvoorwaardenAccessibility statement