Skip to main content

Even wat achtergrondinformatie voor de meelezers die niet volledig op de hoogte zijn. Internetverkeer wordt doorgaans op twee manieren verdeeld: peering en transit. Peering is ‘gratis’ verkeer, bijvoorbeeld direct met een andere provider of via een knooppunt als NL-IX. Transit is al het overige verkeer, naar netwerken waar je geen directe verbinding mee hebt. De provider betaalt hiervoor aan een transitprovider.

KPN was tot vorig jaar eigenaar van zo’n transitprovider: KPN International, ook wel bekend als Eurorings. Vorig jaar is dit verkocht aan de grote internationale netwerkprovider GTT. Sinds deze zomer zegt GTT alle overeenkomsten met andere internationale netwerken op. Waar het verkeer dus eerst KPN-Eurorings-Netwerkprovider was, wordt dat nu KPN-Eurorings-GTT-Netwerkprovider.

En daar gaat iets goed mis. Want hoewel GTT in Amsterdam directe verbindingen heeft met alle andere grote netwerkproviders, maakt het verkeer vanaf KPN nu allerlei wereldreizen. Niet zo goed voor de kwaliteit.

Bekijk bijvoorbeeld deze route, die voorheen van Amsterdam naar Berlijn ging, maar nu van Amsterdam via Saint Denis (Parijs), Londen, Hamburg en dan naar Berlijn.

--- Nice Trace to xxx ---

1) 10.11.12.13 (10.11.12.13) 4.436 ms, 21/21 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 5.192 ms, 21/21 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 7.640 ms, 21/21 ps, 0.0% loss
4) 139.156.98.101 (139.156.98.101) 5.690 ms, 4/21 ps, 76.2% loss
5) * * *
6) sdns-s1-rou-1101.fr.eurorings.net (134.222.48.203) 17.471 ms, 20/20 ps, 0.0% loss 0AS 286]
7) ae17-100-cr0-par9.ipv4.gtt.net (194.122.122.26) 40.869 ms, 20/20 ps, 0.0% loss 0AS 286]
8) ae18.cr11-lon2.ip4.gtt.net (89.149.141.213) 43.025 ms, 20/20 ps, 0.0% loss 0AS 3257] 
9) ldn-b4-link.telia.net (62.115.47.218) 67.076 ms, 20/20 ps, 0.0% loss 0AS 1299]
10) ldn-bb3-link.telia.net (62.115.122.188) 61.165 ms, 20/20 ps, 0.0% loss 0AS 1299]
11) hbg-bb3-link.telia.net (80.91.249.11) 59.728 ms, 20/20 ps, 0.0% loss 0AS 1299] 
12) bei-b1-link.telia.net (62.115.139.9) 59.837 ms, 20/20 ps, 0.0% loss 0AS 1299]
13) bei-b3-link.telia.net (62.115.121.137) 61.258 ms, 20/20 ps, 0.0% loss 0AS 1299]
14) neuemedien-ic-357244-bei-b2.c.telia.net (80.239.167.118) 64.877 ms, 20/20 ps, 0.0% loss 0AS 1299]
15) dd-.kasserver.com (85.13.164.xxx) 63.480 ms, 20/20 ps, 0.0% loss 0AS 34788] Duitsland

Je snapt dat dit niet goed is voor de verbinding. De RTT (Ping) is verdrievoudigd, de downloadsnelheid is gehalveerd.

Eén voorbeeld is geen voorbeeld, dus hier nog twee. Beiden zouden in Nederland moeten blijven maar gaan via België, respectievelijk Duitsland.

--- Nice Trace to 213.19.128.97 ---

1) 10.11.12.13 (10.11.12.13) 5.008 ms, 10/10 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 5.261 ms, 10/10 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 6.981 ms, 10/10 ps, 0.0% loss
4) nl-asd2-pice-ir01.kpn.net (134.222.129.237) 8.017 ms, 2/10 ps, 70.0% loss 0AS 286]
5) * * *
6) ant-s1-rou-1043.be.eurorings.net (134.222.48.197) 11.939 ms, 10/10 ps, 0.0% loss 0AS 286]
7) zvtm-s4-rou-1102.be.eurorings.net (134.222.48.191) 10.980 ms, 10/10 ps, 0.0% loss 0AS 286]
8) ae16-100-cr2-bru2.ipv4.gtt.net (194.122.122.78) 12.229 ms, 10/10 ps, 0.0% loss 0AS 286]
9) ae-10.edge1.brussels1.level3.net (4.68.62.109) 13.015 ms, 10/10 ps, 0.0% loss 0AS 3356]
10) 5-2-3-3994.ear1.amsterdam1.level3.net (213.19.128.97) 12.081 ms, 10/10 ps, 0.0% loss 0AS 3356]
--- Nice Trace to adm-b1.telia.net ---

1) 10.11.12.13 (10.11.12.13) 5.884 ms, 4/4 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 5.036 ms, 4/4 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 8.172 ms, 4/4 ps, 0.0% loss
4) nl-asd2-pice-ir01.kpn.net (134.222.129.237) 8.203 ms, 1/3 ps, 33.3% loss 3AS 286]
5) * * *
6) dssd-s2-rou-1102.de.eurorings.net (134.222.48.179) 10.879 ms, 3/3 ps, 0.0% loss 0AS 286]
7) ae21-100-cr3-dus1.ipv4.gtt.net (194.122.122.46) 11.599 ms, 3/3 ps, 0.0% loss 0AS 286]
8) ddf-b2-link.telia.net (62.115.169.80) 13.242 ms, 3/3 ps, 0.0% loss 0AS 1299]
9) adm-bb4-link.telia.net (62.115.143.162) 12.662 ms, 3/3 ps, 0.0% loss 0AS 1299]
10) adm-b1.telia.net (62.115.128.170) 13.001 ms, 3/3 ps, 0.0% loss 0AS 1299]

En als klap op de vuurpijl nog eentje die binnen het GTT netwerk van Amsterdam moet blijven, maar een omweg maakt via Frankfurt.

--- Nice Trace to Xxx ---

1) 10.11.12.13 (10.11.12.13) 4.261 ms, 14/14 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 5.438 ms, 14/14 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 6.362 ms, 14/14 ps, 0.0% loss
4) nl-asd2-pice-ir01.kpn.net (134.222.129.237) 8.416 ms, 3/14 ps, 71.4% loss 1AS 286] 
5) * * *
6) ffm-s1-rou-1101.de.eurorings.net (134.222.49.65) 14.949 ms, 14/14 ps, 0.0% loss 0AS 286]
7) ae16-100-cr2-fra6.ipv4.gtt.net (194.122.122.114) 17.200 ms, 14/14 ps, 0.0% loss 0AS 286]
8) ae13.cr4-ams2.ip4.gtt.net (89.149.184.222) 15.209 ms, 14/14 ps, 0.0% loss 0AS 3257] 
9) ip4.gtt.net (154.14.30.82) 14.703 ms, 13/13 ps, 0.0% loss 0AS 3257]
10) 194.127.172.5 (194.127.172.5) 30.753 ms, 13/13 ps, 0.0% loss 0AS 62240]
11) * * *
12) * * *
13) 185.185.40.xxx (185.185.40.xxx) 14.327 ms, 13/13 ps, 0.0% loss 0AS 62240]

Best bijzonder allemaal. Gaat je transitprovider over naar een van de grootste netwerken ter wereld, maar gaat de verbinding achteruit. Ik dacht eerst dat het kinderziektes waren, maar het wordt steeds erger met het eerste voorbeeld als dieptepunt. De laatste traceroute is een server van mezelf en deze gaat al twee maanden zo.

Je merkt dit soort verkeerde routing vooral bij gaming en grote downloads. Het valt mij dan ook erg tegen dat het niet verbetert. KPN kan hier direct niet iets aan doen, maar aangezien ze nu een grote klant van GTT zijn, kunnen ze op zijn minst druk uitoefenen op GTT om dit te wijzigen. Of met de voeten stemmen en overstappen naar een andere provider.

Dit lijkt me niet helemaal de service die KPN aan moet willen bieden. Hopelijk lezen er netwerkengineers mee of kan een van de medewerkers hen hier op wijzen. Het is de enige ingang die ik heb ;-)

Klopt helemaal, verbinding is verschrikkelijk met gamen

Zou mijn probleem hier ook mee te maken kunnen hebben?

Ik heb op al het verkeer die over 2 specifieke hops wordt gerouteerd veel packet loss.


Topic packet loss


Het valt mij sowieso op hoeveel extra hops er inderdaad gepasseerd worden als ik bijvoorbeeld naar tweakers.net ga via een KPN lijn een T-Mobile lijn (deze heeft in het verleden de DTAG drama’s gehad, maar dat is gelukkig nu weer helemaal in orde)

Zou mijn probleem hier ook mee te maken kunnen hebben?

Ik heb op al het verkeer die over 2 specifieke hops wordt gerouteerd veel packet loss.

 

Dat zou kunnen, maar met je voorbeeld lijkt niets echt heel erg mis te zijn. Kan zijn dat dit in andere gevallen wel zo is natuurlijk en dan kan het prima hierdoor veroorzaakt worden. Als jouw pakketjes half Europa doorreizen hebben ze ook meer kans om kwijt te raken.


Het valt mij sowieso op hoeveel extra hops er inderdaad gepasseerd worden als ik bijvoorbeeld naar tweakers.net ga via een KPN lijn een T-Mobile lijn (deze heeft in het verleden de DTAG drama’s gehad, maar dat is gelukkig nu weer helemaal in orde)


Extra hops an sich zijn niet zo erg. KPN peert van oudsher met veel minder providers en doet dit bovendien alleen op NL-IX en niet op AMS-IX. Dat betekent dat meer verkeer via transitproviders gaat en dit leidt tot meer hops. Het hoeft geen verslechtering van je verbinding te betekenen.

Het feit dat heel veel verkeer minder direct gaat, maakt wel dat je zoals in dit geval veel meer risico loopt dat routes suboptimaal zijn. En dat is killing voor je verbinding, zoals hier wel blijkt.

Ergens vergelijkbaar met het DTAG-verhaal, maar daar ging het verkeer in ieder geval niet standaard heel Europa door. Misschien nog iets erger dus. Het verschil is wel dat de switch naar DTAG een commerciële keuze was en dit een technisch probleem is. Hopelijk kan KPN er daarom iets aan doen.

Fun fact: als je deze eindbestemmingen in de looking glass van GTT invoert, zie je dat alles wél direct gaat.

Dat zou kunnen, maar met je voorbeeld lijkt niets echt heel erg mis te zijn. Kan zijn dat dit in andere gevallen wel zo is natuurlijk en dan kan het prima hierdoor veroorzaakt worden. Als jouw pakketjes half Europa doorreizen hebben ze ook meer kans om kwijt te raken.

 

Hoe bedoel je “niet heel veel mis te zijn”?

De eerste hops waarbij ik het KPN netwerk opga, vertonen tussen de 60 en 90 procent packet loss.

Dat lijkt me niet helemaal normaal, of wordt dit percentage ICMP packets geblokkeerd bij KPN?

Je hebt ook hops die 100% ICMP blokkeren, maar die geeft Pingplotter ook aan als 100% loss met een streepje en verschijnt geen rode balk bij.

Dat zou kunnen, maar met je voorbeeld lijkt niets echt heel erg mis te zijn. Kan zijn dat dit in andere gevallen wel zo is natuurlijk en dan kan het prima hierdoor veroorzaakt worden. Als jouw pakketjes half Europa doorreizen hebben ze ook meer kans om kwijt te raken.

 

Hoe bedoel je “niet heel veel mis te zijn”?

 

Ik heb in je eigen topic uitgelegd wat er aan de hand is. Aangezien je de packet loss alleen ervaart op routers van KPN zelf, maar niet verder in het traject, is er niet zoveel mis.

Dat laat natuurlijk niet onverlet dat het toevoegen van zo’n omweg uiteindelijk wél tot packet loss kan leiden. Los daarvan leidt het altijd tot een mindere verbinding als je verkeer tussen allerlei interconnects, routers en switches danst.

Dus wat jij nu schetst is geen probleem, maar ik hou mijn hart vast als ook verkeer naar populaire sites als Tweakers straks ook half Europa door moet.

Los daarvan kun je wel last hebben van dit probleem bij gaming. Een Ping die 3-4 keer hoger is, dat merk je wel. 
 

Dus hopelijk kan KPN dit oplossen. Het is niet in hun belang om dit te laten liggen, lijkt me. 

 

De eerste hops waarbij ik het KPN netwerk opga, vertonen tussen de 60 en 90 procent packet loss.

Dat lijkt me niet helemaal normaal, of wordt dit percentage ICMP packets geblokkeerd bij KPN?

Dat een gedeelte van de ICMP packets geblokkeerd worden hoeft geen enkel probleem te zijn. Die hops kunnen ingericht zijn om bij een bepaalde workload ICMP packets te negeren.

Taak van die hops is om verkeer te routeren, niet om op ping verzoeken te reageren. Zolang je geen packet loss ervaart op de eindbestemming is er niets aan de hand.

De eerste hops waarbij ik het KPN netwerk opga, vertonen tussen de 60 en 90 procent packet loss.

Dat lijkt me niet helemaal normaal, of wordt dit percentage ICMP packets geblokkeerd bij KPN?

Dat een gedeelte van de ICMP packets geblokkeerd worden hoeft geen enkel probleem te zijn. Die hops kunnen ingericht zijn om bij een bepaalde workload ICMP packets te negeren.

Taak van die hops is om verkeer te routeren, niet om op ping verzoeken te reageren. Zolang je geen packet loss ervaart op de eindbestemming is er niets aan de hand.


Toch wil ik het wel uitgezocht hebben door KPN, want ik ervaar wel degelijk packet loss op realtime streams zoals internet radio of VOIP gesprekken.

De eerste hops waarbij ik het KPN netwerk opga, vertonen tussen de 60 en 90 procent packet loss.

Dat lijkt me niet helemaal normaal, of wordt dit percentage ICMP packets geblokkeerd bij KPN?

Dat een gedeelte van de ICMP packets geblokkeerd worden hoeft geen enkel probleem te zijn. Die hops kunnen ingericht zijn om bij een bepaalde workload ICMP packets te negeren.

Taak van die hops is om verkeer te routeren, niet om op ping verzoeken te reageren. Zolang je geen packet loss ervaart op de eindbestemming is er niets aan de hand.


Toch wil ik het wel uitgezocht hebben door KPN, want ik ervaar wel degelijk packet loss op realtime streams zoals internet radio of VOIP gesprekken.

Dat zal dan eerder met dit routeringsprobleem te maken hebben. Het viel me zojuist op dat ook verkeer naar Zoom via België en Frankrijk terug naar Nederland komt. Niet echt handig als je een vlekkeloze videomeeting wilt hebben.

Toevallig kwam ik er vanochtend nog eentje tegen. Deze gaat naar Londen en weer terug.

--- Nice Trace to 103.119.112.1 ---

1) 10.11.12.13 (10.11.12.13) 5.573 ms, 4/4 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 3.958 ms, 4/4 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 6.302 ms, 4/4 ps, 0.0% loss
4) 139.156.98.101 (139.156.98.101) 219.842 ms, 1/3 ps, 66.7% loss
5) * * *
6) ldn-s2-rou-1101.uk.eurorings.net (134.222.48.200) 13.162 ms, 4/4 ps, 0.0% loss sAS 286]
7) ae6-100-cr0-lon1.ipv4.gtt.net (194.122.122.70) 13.328 ms, 4/4 ps, 0.0% loss sAS 286] 
8) ae1.cr12-lon1.ip4.gtt.net (141.136.107.6) 15.503 ms, 4/4 ps, 0.0% loss sAS 3257]
9) * * *
10) be2869.ccr42.lon13.atlas.cogentco.com (154.54.57.161) 13.496 ms, 3/3 ps, 0.0% loss sAS 174]
11) be12488.ccr42.ams03.atlas.cogentco.com (130.117.51.42) 18.925 ms, 3/3 ps, 0.0% loss sAS 174]
12) be2796.rcr21.b047839-0.ams03.atlas.cogentco.com (154.54.58.126) 15.178 ms, 3/3 ps, 0.0% loss sAS 174]
13) 103.119.112.1 (103.119.112.1) 15.505 ms, 3/3 ps, 0.0% loss sAS 174]

Ik gooi het ook maar hier weg, aangezien het forum mijn beste kans is. Bij de klantenservice gaat men niet zo ver. Als iemand een betere ingang heeft, dan hoor ik het graag. Het nadeel met routing is dat je het onmogelijk allemaal kunt controleren. Al lijken de voorbeelden wijdverbreid.

Toch wil ik het wel uitgezocht hebben door KPN, want ik ervaar wel degelijk packet loss op realtime streams zoals internet radio of VOIP gesprekken.

Dan ervaar je dus packet loss van verkeer vanaf de eindbestemming. Die zou je in zo'n trace dus op de eindbestemming geteld zien maar het werkelijke verloren gaan kan ergens op route plaatsvinden. Het enige waar ik iets over zeg is dat ICMP packet loss op een node op de route naar de eindbestemming helemaal niets zegt over de werking en betrouwbaarheid van het netwerk.

Toch wil ik het wel uitgezocht hebben door KPN, want ik ervaar wel degelijk packet loss op realtime streams zoals internet radio of VOIP gesprekken.

Dan ervaar je dus packet loss van verkeer vanaf de eindbestemming. Die zou je in zo'n trace dus op de eindbestemming geteld zien maar het werkelijke verloren gaan kan ergens op route plaatsvinden. Het enige waar ik iets over zeg is dat ICMP packet loss op een node op de route naar de eindbestemming helemaal niets zegt over de werking en betrouwbaarheid van het netwerk.


Hoe ben je daar zo zeker van?

Als je via 8 hops naar je bestemming gerouteerd wordt, en op hop 4 zit veel packet loss dan wil jij dus zeggen dat je daar als internetgebruiker geen van last kan hebben?

Toch wil ik het wel uitgezocht hebben door KPN, want ik ervaar wel degelijk packet loss op realtime streams zoals internet radio of VOIP gesprekken.

Dan ervaar je dus packet loss van verkeer vanaf de eindbestemming. Die zou je in zo'n trace dus op de eindbestemming geteld zien maar het werkelijke verloren gaan kan ergens op route plaatsvinden. Het enige waar ik iets over zeg is dat ICMP packet loss op een node op de route naar de eindbestemming helemaal niets zegt over de werking en betrouwbaarheid van het netwerk.


Hoe ben je daar zo zeker van?

Als je via 8 hops naar je bestemming gerouteerd wordt, en op hop 4 zit veel packet loss dan wil jij dus zeggen dat je daar als internetgebruiker geen van last kan hebben?

Daar heeft hij gelijk in. Het is geen packet loss maar gewoon een router die geen tijd heeft voor jouw verzoekjes.

Zie het maar als een rij mensen die allemaal een letterlijk pakketje doorgeven aan elkaar. Degene die vooraan staat neemt alle pakketjes aan én moet bepalen naar welke volgende persoon ze gaan. Die heeft geen tijd om bij ieder pakketje dat je aan hem geeft te zeggen “ja hoor, ik heb hem”. Als je pakketje maar aan komt.

Toch wil ik het wel uitgezocht hebben door KPN, want ik ervaar wel degelijk packet loss op realtime streams zoals internet radio of VOIP gesprekken.

Dan ervaar je dus packet loss van verkeer vanaf de eindbestemming. Die zou je in zo'n trace dus op de eindbestemming geteld zien maar het werkelijke verloren gaan kan ergens op route plaatsvinden. Het enige waar ik iets over zeg is dat ICMP packet loss op een node op de route naar de eindbestemming helemaal niets zegt over de werking en betrouwbaarheid van het netwerk.


Hoe ben je daar zo zeker van?

Als je via 8 hops naar je bestemming gerouteerd wordt, en op hop 4 zit veel packet loss dan wil jij dus zeggen dat je daar als internetgebruiker geen van last kan hebben?

Daar heeft hij gelijk in. Het is geen packet loss maar gewoon een router die geen tijd heeft voor jouw verzoekjes.

Zie het maar als een rij mensen die allemaal een letterlijk pakketje doorgeven aan elkaar. Degene die vooraan staat neemt alle pakketjes aan én moet bepalen naar welke volgende persoon ze gaan. Die heeft geen tijd om bij ieder pakketje dat je aan hem geeft te zeggen “ja hoor, ik heb hem”. Als je pakketje maar aan komt.


Maar als ik een RTP stream heb met de eindbestemming (Zoom, Teams, VoIP, gaming) dan gaat dat toch door die hop heen? Dan is hoge latency en packet loss uit den boze…..

Maar als ik een RTP stream heb met de eindbestemming (Zoom, Teams, VoIP, gaming) dan gaat dat toch door die hop heen? Dan is hoge latency en packet loss uit den boze…..

Klopt, maar dat is dus geen ICMP ping verzoek wat zo'n hop dan te verwerken maar een opdracht voor het routeren van een datapakketje en dat is nu waarom die traces niets maar dan ook helemaal niets zeggen over de werking en betrouwbaarheid van het netwerk.

Dat er packet loss is bij een hop voor ICMP ping requests is prima, daar is helemaal niets mis mee en kan je het beste dan ook maar volledig negeren.

Pas als je vanaf een bepaalde hop t/m de eindbestemming packet losses ziet zou het zo kunnen zijn dat die hop een probleem veroorzaakt. Geven achterliggende hops echter geen packet losses meer dan is er met die eerdere hop ook niets mis immers die routeert succesvol 100% van de datapakketjes die door die achterliggende hops teruggestuurd worden. Het enige wat ze dus niet doen is zelf altijd op ICMP ping verzoeken reageren en nogmaals, dat is prima.

Een hoge latency is een ander verhaal. Uit zo'n trace kan je heel goed herleiden welk gedeelte van de route een grote rol speelt in de latency. Zo zie je soms in zo'n trace sprongen in responsetijden en dat duidt er op dat (de lijn naar) die hop een bottleneck vormt.

Maar als ik een RTP stream heb met de eindbestemming (Zoom, Teams, VoIP, gaming) dan gaat dat toch door die hop heen? Dan is hoge latency en packet loss uit den boze…..

Een hoge latency is een ander verhaal. Uit zo'n trace kan je heel goed herleiden welk gedeelte van de route een grote rol speelt in de latency. Zo zie je soms in zo'n trace sprongen in responsetijden en dat duidt er op dat (de lijn naar) die hop een bottleneck vormt.


En dat is precies waar dit wel aansluit op de vraag van @soundwork, het kan best zijn dat wat jij denkt dat packet loss is eigenlijk veroorzaakt wordt door hoge latency omdat het voormalige Euroringsnetwerk naar de vaantjes is. Immers: als je met een realtime dienst als gaming of videocalls ineens 70 ipv 10ms latency hebt, tja.

Maar als ik een RTP stream heb met de eindbestemming (Zoom, Teams, VoIP, gaming) dan gaat dat toch door die hop heen? Dan is hoge latency en packet loss uit den boze…..

Een hoge latency is een ander verhaal. Uit zo'n trace kan je heel goed herleiden welk gedeelte van de route een grote rol speelt in de latency. Zo zie je soms in zo'n trace sprongen in responsetijden en dat duidt er op dat (de lijn naar) die hop een bottleneck vormt.


En dat is precies waar dit wel aansluit op de vraag van @soundwork, het kan best zijn dat wat jij denkt dat packet loss is eigenlijk veroorzaakt wordt door hoge latency omdat het voormalige Euroringsnetwerk naar de vaantjes is. Immers: als je met een realtime dienst als gaming of videocalls ineens 70 ipv 10ms latency hebt, tja.


Het enige waar we op kunnen hopen is dat de juiste mensen binnen KPN deze topics opmerken en er iets aan kunnen (en willen) doen. De grote roze concurrent draaide DTAG terug eind oktober vorig jaar omdat er zeer veel klachten kwamen van internetgebruikers uit Nederland maar ook Duitsland. Bij KPN zal de situatie “iets minder urgent” zijn maar er zijn toch veel internetters die er last van hebben.

Maar als ik een RTP stream heb met de eindbestemming (Zoom, Teams, VoIP, gaming) dan gaat dat toch door die hop heen? Dan is hoge latency en packet loss uit den boze…..

Een hoge latency is een ander verhaal. Uit zo'n trace kan je heel goed herleiden welk gedeelte van de route een grote rol speelt in de latency. Zo zie je soms in zo'n trace sprongen in responsetijden en dat duidt er op dat (de lijn naar) die hop een bottleneck vormt.


En dat is precies waar dit wel aansluit op de vraag van @soundwork, het kan best zijn dat wat jij denkt dat packet loss is eigenlijk veroorzaakt wordt door hoge latency omdat het voormalige Euroringsnetwerk naar de vaantjes is. Immers: als je met een realtime dienst als gaming of videocalls ineens 70 ipv 10ms latency hebt, tja.


Het enige waar we op kunnen hopen is dat de juiste mensen binnen KPN deze topics opmerken en er iets aan kunnen (en willen) doen. De grote roze concurrent draaide DTAG terug eind oktober vorig jaar omdat er zeer veel klachten kwamen van internetgebruikers uit Nederland maar ook Duitsland. Bij KPN zal de situatie “iets minder urgent” zijn maar er zijn toch veel internetters die er last van hebben.

Het verwdhmis dat het overschakelen naar DTAG een commerciële keuze was van T-Mobile. Dit is het netwerk van hun moedermaatschappij en dus goedkoper. Bovendien hoopten ze zo betaald verkeer te verkopen aan hostingbedrijven. Dat is eenvoudig terug te draaien.

Dit is een technisch issue dat ontstaan is na het samenvoegen van Eurorings en GTT. Hier is niets terug te draaien, maar moet KPN in de slag met haar leverancier.

Maar als ik een RTP stream heb met de eindbestemming (Zoom, Teams, VoIP, gaming) dan gaat dat toch door die hop heen? Dan is hoge latency en packet loss uit den boze…..

Een hoge latency is een ander verhaal. Uit zo'n trace kan je heel goed herleiden welk gedeelte van de route een grote rol speelt in de latency. Zo zie je soms in zo'n trace sprongen in responsetijden en dat duidt er op dat (de lijn naar) die hop een bottleneck vormt.


En dat is precies waar dit wel aansluit op de vraag van @soundwork, het kan best zijn dat wat jij denkt dat packet loss is eigenlijk veroorzaakt wordt door hoge latency omdat het voormalige Euroringsnetwerk naar de vaantjes is. Immers: als je met een realtime dienst als gaming of videocalls ineens 70 ipv 10ms latency hebt, tja.


Het enige waar we op kunnen hopen is dat de juiste mensen binnen KPN deze topics opmerken en er iets aan kunnen (en willen) doen. De grote roze concurrent draaide DTAG terug eind oktober vorig jaar omdat er zeer veel klachten kwamen van internetgebruikers uit Nederland maar ook Duitsland. Bij KPN zal de situatie “iets minder urgent” zijn maar er zijn toch veel internetters die er last van hebben.

Het verwdhmis dat het overschakelen naar DTAG een commerciële keuze was van T-Mobile. Dit is het netwerk van hun moedermaatschappij en dus goedkoper. Bovendien hoopten ze zo betaald verkeer te verkopen aan hostingbedrijven. Dat is eenvoudig terug te draaien.

Dit is een technisch issue dat ontstaan is na het samenvoegen van Eurorings en GTT. Hier is niets terug te draaien, maar moet KPN in de slag met haar leverancier.


Het baart mij zorgen, straks heb je niets meer aan die glasvezelaansluitingen.

Alsof een kleine Fiat over een luxe 10 baans snelweg kan rijden.

Ook al is het een keuze van T-Mobile geweest om DTAG terug te draaien, ook KPN maakt de keuze zaken te doen met Eurorings/GTT, zij kunnen best wel zaken doen met goede transit providers maar ja…. dat kost weer veel geld en dat willen ze niet betalen. Dus meer betalen als klant en minder kwaliteit krijgen…. of je nu bij de geel/groen/blauwe, de oranje of de roze telecomreus zit……. En dan heb ik het nog niet eens over de kleinere webhosting bedrijfjes gehad….

Nog een prachtige rondreis door Europa hier. RTT lijkt mee te vallen, vermoedelijk omdat de terugweg niet via de toeristische route gaat.

Ik hoop wel heel erg dat KPN hier snel iets aan doet.

--- Nice Trace to tilaa.com ---

1) 10.11.12.13 (10.11.12.13) 3.988 ms, 25/25 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 4.398 ms, 25/25 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 6.893 ms, 24/24 ps, 0.0% loss
4) 139.156.98.101 (139.156.98.101) 5.639 ms, 4/23 ps, 82.6% loss
5) * * *
6) sdns-s1-rou-1101.fr.eurorings.net (134.222.48.203) 17.054 ms, 24/24 ps, 0.0% loss [AS 286]
7) ae7-100-cr1-par9.ipv4.gtt.net (194.122.122.22) 20.161 ms, 24/24 ps, 0.0% loss [AS 286]
8) ae18.cr11-lon2.ip4.gtt.net (89.149.141.213) 22.584 ms, 24/24 ps, 0.0% loss [AS 3257] 
9) ldn-b4-link.telia.net (62.115.47.218) 56.552 ms, 8/23 ps, 65.2% loss [AS 1299]
10) ldn-bb3-link.telia.net (62.115.122.188) 21.077 ms, 24/24 ps, 0.0% loss [AS 1299]
11) adm-bb3-link.telia.net (213.155.136.99) 20.461 ms, 24/24 ps, 0.0% loss [AS 1299] 
12) adm-b3-link.telia.net (62.115.122.179) 20.862 ms, 24/24 ps, 0.0% loss [AS 1299]
13) hlm1-bfr1-as1299.tilaa.net (62.115.42.158) 21.386 ms, 24/24 ps, 0.0% loss [AS 1299] 
14) hlm1-cr1-v1032.tilaa.net (164.138.24.33) 20.963 ms, 24/24 ps, 0.0% loss [AS 196752] 
15) hlm1-pod8-vc8-v1076.tilaa.net (164.138.24.77) 56.008 ms, 24/24 ps, 0.0% loss [AS 196752]
16) my.tilaa.com (84.22.115.3) 20.358 ms, 24/24 ps, 0.0% loss [AS 196752] Nederland

 

Pfff, ik was juist bij de grote roze telecomboer opgestapt om van deze “goedkope omweg-routeringen” af te zijn. Zelfs op Tweakers waren ze lovend over hoe KPN het peering en transitverkeer geregeld had, wat ik heb ik daar nu spijt van. Nu moet ik mijn jaarcontract maar uitzitten, want KPN is dus EN duurder en je bent net zo slecht af met de "toeristische digitale routes".

Hier ook hetzelfde verhaal. Bij mij was het eerst wel erg extreem met de packet loss. Dat is nu weg, maar ook ik zie nog steeds vreemde routering naar veel eindbestemmingen.

Het is de afgelopen dagen echt wel verbeterd allemaal. GTT heeft de problemen in haar netwerk opgelost en KPN heeft Liberty Global (50% eigenaar van Ziggo, maar zal een goeie deal zijn geweest) toegevoegd als transitprovider.

Al mijn routes gaan nu weer goed. Geen onverklaarbaar hoge RTT en packet loss meer. Ook geen toeristische routes meer. Hopelijk blijft dit zo.

Edit: Naar de VS toch nog onverklaarbaar hoge RTT, zonder gekke routing.

Bij het opbouwen van een cisco anyconnect VPN client verbinding via een laptop vanuit Lelystad en omgeving over het netwerk van Cogent gaat niet goed. De IPSec tunnel wordt niet goed opgebouwd en is zeer instabiel. Routerings probleem. Ongeveer 80 klanten binnen lelystad, en alleen op het KPN netwerk, hebben hier de hele dag al last van. Graag oplossen.

@M.Y. : admin: vraag naar centraal topic verplaatst

De tracert van de route naar ons VPN cluster in het netwerk van Cogent:
 

 

Moet toch terugkomen op mijn eerdere post, want dit lijkt me toch echt niet de bedoeling te zijn. Normale latency naar deze locatie zou zo'n ~30ms moeten zijn. Wat het de afgelopen dag ook was.

Tracing route to xxx
over a maximum of 30 hops:

  1     4 ms     3 ms     2 ms  10.11.12.13
  2     3 ms     2 ms     2 ms  192.168.178.1
  3     5 ms     3 ms     3 ms  195-190-228-64.fixed.kpn.net [195.190.228.64]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     7 ms     6 ms     6 ms  nl-ams14a-ri1-ae-8-0.aorta.net [84.116.135.38]
  8     *        *        *     Request timed out.
  9    48 ms    47 ms    47 ms  be2815.ccr41.ham01.atlas.cogentco.com [154.54.38.206]
 10    62 ms    61 ms    61 ms  be3027.ccr21.prg01.atlas.cogentco.com [130.117.1.206]
 11    65 ms    63 ms    62 ms  be2695.rcr21.drs01.atlas.cogentco.com [154.54.57.125]
 12    70 ms    67 ms    63 ms  neue-medien.demarc.cogentco.com [149.6.40.10]
 13    65 ms    62 ms    63 ms  -.kasserver.com [85.13.164.xxx]

En wat hiervan te denken, binnen Nederland. Normaal <10ms.

Tracing route to adm-b1.telia.net [62.115.128.170]
over a maximum of 30 hops:

  1     3 ms     5 ms     3 ms  10.11.12.13
  2     5 ms     3 ms     3 ms  192.168.178.1
  3     6 ms    19 ms     4 ms  195-190-228-64.fixed.kpn.net [195.190.228.64]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7    48 ms    44 ms    45 ms  nl-ams04a-ri3-ae-8-0.aorta.net [84.116.130.97]
  8    44 ms    41 ms    44 ms  adm-b1.telia.net [62.115.128.170]

Terwijl ik dit aan het typen ben, werkt videoconferencing software ook niet meer goed bij alle deelnemers die KPN gebruiken.

Moet toch terugkomen op mijn eerdere post, want dit lijkt me toch echt niet de bedoeling te zijn. Normale latency naar deze locatie zou zo'n ~30ms moeten zijn. Wat het de afgelopen dag ook was.

Tracing route to xxx
over a maximum of 30 hops:

  1     4 ms     3 ms     2 ms  10.11.12.13
  2     3 ms     2 ms     2 ms  192.168.178.1
  3     5 ms     3 ms     3 ms  195-190-228-64.fixed.kpn.net [195.190.228.64]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     7 ms     6 ms     6 ms  nl-ams14a-ri1-ae-8-0.aorta.net [84.116.135.38]
  8     *        *        *     Request timed out.
  9    48 ms    47 ms    47 ms  be2815.ccr41.ham01.atlas.cogentco.com [154.54.38.206]
 10    62 ms    61 ms    61 ms  be3027.ccr21.prg01.atlas.cogentco.com [130.117.1.206]
 11    65 ms    63 ms    62 ms  be2695.rcr21.drs01.atlas.cogentco.com [154.54.57.125]
 12    70 ms    67 ms    63 ms  neue-medien.demarc.cogentco.com [149.6.40.10]
 13    65 ms    62 ms    63 ms  -.kasserver.com [85.13.164.xxx]

En wat hiervan te denken, binnen Nederland. Normaal <10ms.

Tracing route to adm-b1.telia.net [62.115.128.170]
over a maximum of 30 hops:

  1     3 ms     5 ms     3 ms  10.11.12.13
  2     5 ms     3 ms     3 ms  192.168.178.1
  3     6 ms    19 ms     4 ms  195-190-228-64.fixed.kpn.net [195.190.228.64]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7    48 ms    44 ms    45 ms  nl-ams04a-ri3-ae-8-0.aorta.net [84.116.130.97]
  8    44 ms    41 ms    44 ms  adm-b1.telia.net [62.115.128.170]

Terwijl ik dit aan het typen ben, werkt videoconferencing software ook niet meer goed bij alle deelnemers die KPN gebruiken.


Als ik de PingPlotter naar www.kasserver.com laat lopen (draait deze in NL?)

Dan heb ik een gemiddelde van 76 ms!!!

Al met al, niet zoals KPN dat hoort te doen….

Waarom is KPN eigenlijk duurder met zijn glasvezelabonnementen? Als ik een waardeloze transit route bewandel? Als je hogere kosten vraagt voor je dienstverlening, dan moet dit “ergens” terugkomen toch?? De klantenservice is al niet om over naar huis te schrijven...

De Kennisbank

Heb je vragen over diensten, producten of wil je weten hoe je modeminstellingen verandert? Vind het antwoord op de meest gestelde vragen in onze Kennisbank

...

Community voorwaarden