Skip to main content

Hallo,

Ik heb sinds 2 dagen T-mobile glasvezel (1gbit), dit ipv. KPN glasvezel.
Nu ervaar ik gestotter en packet loss op jullie netwerk, dit is sporadisch wat duid of op een capaciteit probleem of een slechte verbinding tussen jullie eigen routers (of glasoperator).

 

Zie deze MTR, gemaakt van een linux server op bekabeld netwerk:

                                                  Packets               Pings
 Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. router                                                0.0%    13    0.3   0.3   0.3   0.4   0.0
 2. 1-0-208-87.ftth.glasoperator.nl         0.0%    13    3.0   2.7   2.4   3.1   0.2
 3. 10.10.13.77                                      0.0%    13    3.7   3.8   3.3   4.1   0.2
 4. 10.10.12.61                                      25%    13    3.8   4.0   3.7   4.2   0.1
 5. 172.71.92.4                                      0.0%    12   94.5  60.9   5.9 115.6  49.0
 6. 80.249.210.118                                0.0%    12    5.6   9.0   5.5  27.9   7.3
 7. 172.71.92.4                                      0.0%    12    5.3   6.7   5.0  17.4   3.4
 8. 104.18.19.222                                  0.0%    12    5.3   5.3   5.1   5.5   0.1

 

Zoals u ziet is er 1 router die problemen geeft, dat is 10.10.12.61, speelt zich af tussen 10.10.13.77 en 10.10.12.61 en het is sporadisch. Packet loss is al het verkeer dus niet naar specifieke IP adressen of ranges.

Het probleem is zowel niet op mijn router, de ONT, mijn glasvezel lijn is -13 dB en de centrale, het ligt tussen de 3e en 4e hop in jullie netwerk.

Zouden jullie hiervoor een case kunnen aanmaken bij jullie netwerk afdeling?

 

 

Hi @suus_1, welkom op onze Community!

Bedankt voor het delen van je tracert. Ik heb ook direct een lijnmeting gedaan en daar ziet alles er goed uit, het enige wat mij is opgevallen is dat je een eigen router hebt aangesloten. Ik wil je daarom doorverwijzen naar dit topic: 

 

 

Hier legt @louisL precies uit waar je naar moet kijken. Onder anderen: Heb je pings waarbij je trage response ziet op de target host? 

Zou je dit nog kunnen nakijken en een tracert van kunnen delen? Als dat er niet goed uitziet kan ik een onderzoek voor je starten. Ook wil ik je vragen om een tracert te doen als het Zyxel modem is aangesloten. Die kan ik namelijk ook van een afstandje uitlezen, eigen apparatuur jammer genoeg niet. Alvast bedankt!


Hi @suus_1, welkom op onze Community!

Bedankt voor het delen van je tracert. Ik heb ook direct een lijnmeting gedaan en daar ziet alles er goed uit, het enige wat mij is opgevallen is dat je een eigen router hebt aangesloten. Ik wil je daarom doorverwijzen naar dit topic: 

 

 

Hier legt @louisL precies uit waar je naar moet kijken. Onder anderen: Heb je pings waarbij je trage response ziet op de target host? 

Zou je dit nog kunnen nakijken en een tracert van kunnen delen? Als dat er niet goed uitziet kan ik een onderzoek voor je starten. Ook wil ik je vragen om een tracert te doen als het Zyxel modem is aangesloten. Die kan ik namelijk ook van een afstandje uitlezen, eigen apparatuur jammer genoeg niet. Alvast bedankt!

 

Het topic dat je naar mij doorstuurde gaat niet over dezelfde IP range. 10.10.13* is of van jullie of van glasoperator, daarbij is de 10.0.0.0/8 een prive IP range, en niet die ergens op het internet gebruikt mag worden.

Zie deze pagina: https://en.wikipedia.org/wiki/Reserved_IP_addresses


De print hierboven is van het commando MTR, deze doet traceroute, ping, packetloss dus als je het goed leest zie je ook wat de ping is. Ik sta zelf niet 24 uur per dag te pingen dus kan jou niet vertellen naar welke hosts ik wat ervaar, maar wat ik eerder al schreef deze random packet loss is niet naar specifieke IP ranges of adressen, het geldt voor al het verkeer.

Test van Zyxel modem naar nu.nl:

 Host                                                                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ZyxelT65                                                                     0.0%     33    0.4   0.4   0.3   0.4   0.0
 2. 1-0-208-87.ftth.glasoperator.nl                                    0.0%     33    2.8   2.8   2.6   2.9   0.1
 3. 10.10.13.77                                                                 0.0%     33    6.1   6.2   6.1   6.3   0.1
 4. 10.10.12.61                                                                 50.0%   33    6.3   6.3   6.3   6.3   0.0
 5. 10.226.4.6                                                                   0.0%     33    6.4   6.3   6.1   6.4   0.2
 6. 192.168.237.135                                                         0.0%     33    6.4   6.4   6.3   6.5   0.1
 7. (waiting for reply)
 8. 192.168.224.17                                                           0.0%     33    6.0   6.1   6.0   6.1   0.1
 9. 192.168.237.135                                                         0.0%     33    5.9   6.0   5.9   6.2   0.1
10. 192.168.241.21                                                          0.0%     33    6.1   6.0   5.8   6.1   0.2
11. a104-110-191-12.deploy.static.akamaitechnologies.com                               0.0%     2    5.8   6.0   5.8   6.2   0.2

50% packet loss or absurd hoog en niet acceptabel.

Ik kan helaas niet permament jullie T-56 aansluiten want dan kan ik niet thuiswerken.

 

 

 


Het kan heel goed zijn dat routers onderweg naar je bestemming geen tijd hebben om te antwoorden op ping requests. Ik zie trouwens hetzelfde ”probleem” met 10.10.12.61. Die heeft zo te zien een throttle op pings waarbij maar 50% wordt beantwoordt. Routers na  die 10.10.12.61 doen het gewoon met 0% packet loss dus die router levert geen problemen op. Wat je hier laat zien lijkt dus een red herring. Routers kunnen soms perfect alle traffic routeren, maar problemen hebben met de control plane: packets worden direct op hardware niveau doorgestuurd. Pings moeten naar de CPU en die kan te druk zijn of zelfs een filter hebben op ICMP.

Zo lang de ping naar een bestemming die ping toestaat (doen ze ook niet allemaal!) een loss van 0% laat zien is er niets aan de hand.

Blijft de vraag wat er wel aan de hand is waardoor je gestotter en packet loss ervaart….

 


Het kan heel goed zijn dat routers onderweg naar je bestemming geen tijd hebben om te antwoorden op ping requests. Ik zie trouwens hetzelfde ”probleem” met 10.10.12.61. Die heeft zo te zien een throttle op pings waarbij maar 50% wordt beantwoordt. Routers na  die 10.10.12.61 doen het gewoon met 0% packet loss dus die router levert geen problemen op. Wat je hier laat zien lijkt dus een red herring. Routers kunnen soms perfect alle traffic routeren, maar problemen hebben met de control plane: packets worden direct op hardware niveau doorgestuurd. Pings moeten naar de CPU en die kan te druk zijn of zelfs een filter hebben op ICMP.

Zo lang de ping naar een bestemming die ping toestaat (doen ze ook niet allemaal!) een loss van 0% laat zien is er niets aan de hand.

Blijft de vraag wat er wel aan de hand is waardoor je gestotter en packet loss ervaart….

 

Hoi!

Het kan idd een router zijn die ICMP niet prioriteert. Maar ik denk dat we het wel eens zijn dat dit intern bij T-mobile is sinds de IP range prive is.
Het gestotter en missed packets is vooral op UDP, ik kan je niet zo snel vertellen welke hosts het zijn, ik weet wel dat ze in Amsterdam te vinden zijn. Het zijn vooral games van EA waar het soms niet te spelen is. Op mijn vorige lijn met KPN was er nooit, maar dan ook nooit gestotter. Binnenshuis is er niks verandert, enigste is T-mobile en de ONT. Ik heb geen wifi dus alles is op 1G lijnen.

 

Ik ga denk ik even software installeren waarmee ik de lijn goed in te gaten kan houden. PRTG/smokeping/Solarwinds etc.


Ok, je geeft nu in ieder geval aan wat het probleem is wat je ervaart, dat was in je eerste post niet duidelijk. Dat 10 adres is inderdaad ergens in het T-mobile netwerk. Maar iik denk dat je idee om een monitoring systeem op te zetten je meer gaat helpen, vooral als je dat kunt doen voor de hosts waar je de problemen ervaart. Dat 10.10.12.61 adres zit net voor de cloudflare gateway (waarschijnlijk een BGP gateway) en het lijkt wel logisch dat die niet te veel met ICMP wil doen.

Na 10.10.12.61 zie ik 172.71.100.4, die zit in het cloudflare netwerk:

NetRange:       172.64.0.0 - 172.71.255.255
CIDR:           172.64.0.0/13
NetName:        CLOUDFLARENET
 

Ik ben benieuwd wat je monitoring gaat laten zien.


Het kan heel goed zijn dat routers onderweg naar je bestemming geen tijd hebben om te antwoorden op ping requests. Ik zie trouwens hetzelfde ”probleem” met 10.10.12.61. Die heeft zo te zien een throttle op pings waarbij maar 50% wordt beantwoordt. Routers na  die 10.10.12.61 doen het gewoon met 0% packet loss dus die router levert geen problemen op. Wat je hier laat zien lijkt dus een red herring. Routers kunnen soms perfect alle traffic routeren, maar problemen hebben met de control plane: packets worden direct op hardware niveau doorgestuurd. Pings moeten naar de CPU en die kan te druk zijn of zelfs een filter hebben op ICMP.

Zo lang de ping naar een bestemming die ping toestaat (doen ze ook niet allemaal!) een loss van 0% laat zien is er niets aan de hand.

Blijft de vraag wat er wel aan de hand is waardoor je gestotter en packet loss ervaart….

 

Dit is waar. Maar dan is de vraag natuurlijk of T-Mobile routers gebruikt met een volledig gescheiden control plane, of dat ze resources delen en dat de router het dus zwaar heeft. In dat laatste geval zou het stokken van de control plane doen vermoeden dat packet forwarding ook zwaar te lijden heeft.

Bandbreedteverzadiging lijkt me onwaarschijnlijk want de latency ziet er op het eerste gezicht prima uit.


AA

Het kan heel goed zijn dat routers onderweg naar je bestemming geen tijd hebben om te antwoorden op ping requests. Ik zie trouwens hetzelfde ”probleem” met 10.10.12.61. Die heeft zo te zien een throttle op pings waarbij maar 50% wordt beantwoordt. Routers na  die 10.10.12.61 doen het gewoon met 0% packet loss dus die router levert geen problemen op. Wat je hier laat zien lijkt dus een red herring. Routers kunnen soms perfect alle traffic routeren, maar problemen hebben met de control plane: packets worden direct op hardware niveau doorgestuurd. Pings moeten naar de CPU en die kan te druk zijn of zelfs een filter hebben op ICMP.

Zo lang de ping naar een bestemming die ping toestaat (doen ze ook niet allemaal!) een loss van 0% laat zien is er niets aan de hand.

Blijft de vraag wat er wel aan de hand is waardoor je gestotter en packet loss ervaart….

 

Dit is waar. Maar dan is de vraag natuurlijk of T-Mobile routers gebruikt met een volledig gescheiden control plane, of dat ze resources delen en dat de router het dus zwaar heeft. In dat laatste geval zou het stokken van de control plane doen vermoeden dat packet forwarding ook zwaar te lijden heeft.

Bandbreedteverzadiging lijkt me onwaarschijnlijk want de latency ziet er op het eerste gezicht prima uit.

Zie mijn vorige reactie: dit is de laatste router in het T-mobile netwerk. Ik vermoed dat die BGP doet voor routing. En dan is er echt wel een behoorlijke load op de control plane terwijl de packet forwarding daar niets van merkt


Reageer