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 ;-)

@Rutger_ wat mij verbaast is dat die betreffende collega's de packet loss totaal niet waarnemen. Het is sowieso zichtbaar bij het eindpunt, zowel in de plot van mijn collega als bij mijzelf. Ik heb het dus niet over het begin. Ook heb ik de test gedaan door rechtstreeks op Box-12 te gaan zitten (met de LAN switch die daarin zit). Dus dan maak ik geen gebruik van mijn eigen thuis netwerk…..

Dat het probleem er niet is via een T-Mobile Thuis verbinding zegt al veel. Ik zou e.v.t. ook nog eens via een mobiele verbinding proberen. En e.v.t. via een OpenVPN over de problematische KPN link. Als het even kan dan kijken of er OpenVPN UDP paketten verloren gaan, hopelijk heb je ergens een derde partij VPS of je T-Mobile Thuis waar je de OpenVPN server kan plaatsen.


Zou jij die pingplot eens met ons willen delen op het forum.

Poets de IP adressen die je niet wilt tonen heirbij (gedeeltelijk) weg.


Hier ook weer last van packet loss (over een route via Aorta en Cogent).

Het is dusdanig veel dat het ook zonder een MTR opvalt (haperingen in de verbinding). Het is nu langer dan een dag gaande.

MTRs toegevoegd van thuisverbinding en thuisverbinding+VPN. Met de VPN heb ik minder packet loss (maar wel hogere jitter door de VPN zelf).

MTR KPN verbinding

 

MTR via VPN

 

Kan KPN dit oplossen of moet ik dit beschouwen als het nieuwe normaal?

 


@mmc Bedankt voor het delen. Ik heb even contact gehad met een collega die het geprobeerd heeft te reproduceren. Hij had geen last van packet loss. 

Heeft dit probleem zich na 20-03 nog voorgedaan? 


@mmc Bedankt voor het delen. Ik heb even contact gehad met een collega die het geprobeerd heeft te reproduceren. Hij had geen last van packet loss. 

Heeft dit probleem zich na 20-03 nog voorgedaan? 


Het probleem was kort daarna verdwenen, maar het komt wel eens in de zoveel tijd terug.
Aan de route kan er verder geen verbetering plaatsvinden neem ik aan?


@mmc Bedankt voor het delen. Ik heb even contact gehad met een collega die het geprobeerd heeft te reproduceren. Hij had geen last van packet loss. 

Heeft dit probleem zich na 20-03 nog voorgedaan? 

Gistermiddag leek het allemaal even goed te gaan, maar eergisteren, gisterochtend en vandaag is het weer hetzelfde verhaal. Ik heb net als @mmc een tracert uitgevoerd en ik krijg een soortgelijk resultaat:

 

Bepaalde websites laden snel, denk aan bijvoorbeeld een Nu.nl. Maar het lijkt alsof websites gehost door AWS (waar, vanuit een thuiswerkende situatie, ik, en onze klanten, veel mee te maken heb) een stuk trager laden. Servermatig zijn ze allemaal in orde en werken ze snel, het is de route daar de servers toe wat problemen veroorzaakt.

Tevens wil ik nog vermelden dat dit allemaal begonnen is na de storing/aanvallen bij TransIP. Of het één met het ander te maken heeft durf ik niet te stellen, eerder een observatie.

Alvast bedankt!


Ik heb net als @mmc een tracert uitgevoerd en ik krijg een soortgelijk resultaat:

De tracert daar is niets mis mee, dat ziet er prima uit.


Ik heb net als @mmc een tracert uitgevoerd en ik krijg een soortgelijk resultaat:

De tracert daar is niets mis mee, dat ziet er prima uit.

Ik heb ondertussen via een andere topic kunnen pinpointen dat er meer mensen die met AWS (thuis)werken problemen hebben, dus ik vermoed dat het een KPN > AWS probleem is. Maar we wachten het af!


@mmc De huidige route kan inderdaad niet beter.

Maar op de komende weken vindt er wederom een migratie plaats en ik kan geen garanties geven, maar dit zou er voor kunnen zorgen dat hierdoor wel een betere route gekozen wordt. 


@mmc De huidige route kan inderdaad niet beter.

Maar op de komende weken vindt er wederom een migratie plaats en ik kan geen garanties geven, maar dit zou er voor kunnen zorgen dat hierdoor wel een betere route gekozen wordt. 

Kan je dit nader verklaren? Wat gaat KPN dan precies aanpassen? Wordt het transit verkeer over andere peers/providers geleid? Ik heb met vlagen echt heel veel last van packet loss naar InfoPact….


@soundwork Heel veel meer nader kan ik dit helaas niet verklaren. 

Dit is echter niet van toepassing in jouw geval. Er zijn problemen bij Amazon. Amazon heeft een aanpassing heeft gedaan waardoor hun verkeer niet meer rechtstreeks bij ons binnenkomt maar nu via een extra netwerk loopt. 

De issues die klanten en jij dus ook ervaren zijn problemen die hierdoor ontstaan, dit is een probleem dat bij Amazon opgelost moet worden. Ik zou in dit geval óók adviseren om deze situatie bij InfoPact neer te leggen zodat zij het weer kunnen doorgeven aan Amazon, 


Helaas is het probleem waarmee ik deze thread opende ook weer teruggekeerd.

Verkeer van en naar een server in Amsterdam wordt nu weer via Duitsland gestuurd. Hopelijk is dit niet die migratie van @Rutger_ :wink:

 Host Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 194.127.172.xx. 0.0% 29 0.3 0.5 0.2 2.4 0.6
3. ip4.gtt.net 0.0% 29 0.2 2.9 0.2 33.8 8.5
4. et-0-0-41.cr4-ams2.ip4.gtt.net 0.0% 29 1.0 3.4 0.1 38.5 8.1
5. ae32.cr1-fra6.ip4.gtt.net 0.0% 29 7.0 7.7 7.0 13.7 1.5
6. ffm-s1-rou-1102.DE.as286.net 0.0% 29 7.1 7.2 7.1 8.1 0.2
7. rt2-rou-1022.NL.as286.net 0.0% 29 10.9 10.0 9.4 22.1 2.4
8. nl-rt2-pice-ir01.kpn.net 51.7% 29 9.6 9.6 9.5 9.7 0.0
9. ???
10. xx-xx-xx-xxx.fixed.kpn.net 0.0% 28 12.3 12.2 12.1 12.9 0.2

Geen packet loss, maar wel een RTT die 2-3 keer zo hoog is als ie zou moeten zijn.

Hoewel niet relevant voor deze route ben ik net als de andere posters in deze thread allesbehalve gelukkig met de routing van Aorta/LGI. Meestal is het oké, maar als het dat niet is dan is het gelijk ook slecht. Al was het maar omdat ze een voorkeur hebben voor Cogent.

Aorta heeft nu een bijna-monopolie in Nederland, want na zusterbedrijf Ziggo maakt nu ook KPN er gebruik van. Ook een rare situatie overigens hoor. Dat de op een na grootste provider 90% van het verkeer van de grootste provider stuurt.


Aorta heeft nu een bijna-monopolie in Nederland, want na zusterbedrijf Ziggo maakt nu ook KPN er gebruik van. Ook een rare situatie overigens hoor. Dat de op een na grootste provider 90% van het verkeer van de grootste provider stuurt.

Alles draait om geld, dus als Aorta goedkoper is dan krijg je zoiets.


Aorta heeft nu een bijna-monopolie in Nederland, want na zusterbedrijf Ziggo maakt nu ook KPN er gebruik van. Ook een rare situatie overigens hoor. Dat de op een na grootste provider 90% van het verkeer van de grootste provider stuurt.

Alles draait om geld, dus als Aorta goedkoper is dan krijg je zoiets.

Ik vermoed ook dat Liberty Global hen een offer heeft gegeven “they couldn’t refuse” om de grootste concurrent zo dus afhankelijk te maken van hun netwerk. Wel slim.


Inmiddels loopt nu het verkeer van meerdere van mijn providers via Duitsland. @Rutger_ nog enig nieuws over die ‘migratie’. Wil je dit sowieso delen met je collega’s? Dank.

 

Host Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 31.187.64.x0.0% 27 21.7 28.3 8.5 144.9 27.6
2. 225.56.237.178.hosted-by.hostcircle.com0.0% 27 0.4 7.8 0.3 111.5 25.9
3. ae1-1965.cr4-ams2.ip4.gtt.net0.0% 27 28.0 16.8 14.6 36.2 4.8
4. ae32.cr1-fra6.ip4.gtt.net0.0% 27 6.7 7.4 6.6 21.3 2.8
5. ffm-s1-rou-1102.DE.as286.net0.0% 27 6.7 6.8 6.6 7.8 0.3
6. rt2-rou-1022.NL.as286.net0.0% 27 15.6 16.2 15.5 28.9 2.6
7. nl-rt2-pice-ir01.kpn.net88.5% 27 10.0 10.1 10.0 10.1 0.1
8. ???
9. xx-xx-xxx-xx.fixed.kpn.net0.0% 26 11.9 12.0 11.7 13.4 0.3

 


Ook contact gehad met de provider van bovenstaande server. Zij konden het verkeer switchen naar Cogent, zodat het in Nederland blijft. Helaas zorgt dit voor een heel ander probleem, namelijk 85 procent packet loss. Deze server is nu dus onbruikbaar.

 

De combinatie Cogent → Liberty Global → KPN lijkt toch wel echt erg slecht. Overbelaste links of zo? Wie zal het zeggen. Is er nog nieuws over een migratie of extra carrier @Rutger_? Want dit is niet vol te houden.

--- xxxx.xxxxx.nl ping statistics ---

512 packets transmitted, 77 packets received, 85.0% packet loss

round-trip min/avg/max/stddev = 21.937/54.255/1070.922/165.117 ms

Edit: Ook even een screenshotje vanaf de andere kant erbij.

 

 


Ook contact gehad met de provider van bovenstaande server. Zij konden het verkeer switchen naar Cogent, zodat het in Nederland blijft. Helaas zorgt dit voor een heel ander probleem, namelijk 85 procent packet loss. Deze server is nu dus onbruikbaar.

 

De combinatie Cogent → Liberty Global → KPN lijkt toch wel echt erg slecht. Overbelaste links of zo? Wie zal het zeggen. Is er nog nieuws over een migratie of extra carrier @Rutger_? Want dit is niet vol te houden.

--- xxxx.xxxxx.nl ping statistics ---

512 packets transmitted, 77 packets received, 85.0% packet loss

round-trip min/avg/max/stddev = 21.937/54.255/1070.922/165.117 ms

Edit: Ook even een screenshotje vanaf de andere kant erbij.

 

 

Bij mij ook alleen maar ellende als de route van mijn server via Cogent loopt.

Volgens mij is dat de oorzaak van de packet loss hier.

 

server
thuis

 

 


Dus je benadert een server die bij HostHatch is ondergebracht.

Overigens is het niet zo dat het niet reageren op een ping request direct een probleem met de communicatie impliceert. Hops op de route naar de eindbestemming kunnen prima ingericht zijn om ping requests te negeren als de workload boven een bepaalde drempel komt en dat uit zich dan in packetlosses. Dat wil echter nog niet zeggen dat het "echte" verkeer dan ook verloren gaat.


 Dus je benadert een server die bij HostHatch is ondergebracht.

In bovenstaand voorbeeld wel ja, dit is mijn hobby dev servertje. De andere server waarover ik 17 dagen geleden een opmerking maakte is overigens een dedi een andere provider. Bij beide providers heb ik een case lopen vanwege verkeer via Duitsland, maar in beiden gevallen is het alternatief (Cogent → Liberty Global of Telia → Liberty Global) veel packet loss.

Overigens is het niet zo dat het niet reageren op een ping request direct een probleem met de communicatie impliceert.
 

Dit hoef je mij niet uit te leggen hoor. Ik snap je goede bedoelingen, maar op het moment dat de packet loss tot het einde aanwezig is (zoals in mijn voorbeeld van vandaag) is dit dus wel een probleem met de communicatie. 
 

Dat heb ik wel gemerkt door de totaal unresponsive SSH verbinding. Het gaat niet om 1 routertje dat meer prio geeft aan routeren dan aan reageren, maar dat kun je ook zien aan de ping resultaten en de mtr.

Feit blijft dat het sinds een halfjaar behoorlijk hit and miss is wat betreft transit verkeer. Meestal is het voor mij redelijk in orde, maar op een verkeerd moment kun je zo een tijd lang vertragingen of loss ondervinden. Lijkt bijna wel op capaciteitsgebrek bij Liberty Global. GTT is dan weer heel goed in verkeer een tripje door Europa geven, gelukkig zonder packet loss.

Ik begrijp dat KPN niet de hoofdprijs wil betalen, maar goedkoop lijkt toch een beetje duurkoop op deze manier. Ook zie je nu het gebrek aan peering wel duidelijk terug zo. De gemiddelde klant zal dit niet altijd ondervinden, maar als je iets meer doet dan Googelen en Netflixen dus wel. Ik neem aan dat KPN iedereen een goede verbinding wil geven.

Toen KPN nog een eigen tier 1 netwerk had was het prima, nu is het te wisselend. Het had ook logischer geweest dat KPN bij meerdere tier 1 netwerken verkeer in zou kopen (zoals dochter Solcon doet) in plaats van alles aan de concurrent te geven.

Wel benieuwd naar die migratie die @Rutger_ aan heeft gekondigd. Wie weet verbetert het dan wel en wordt het weer wat consistenter.


Het had ook logischer geweest dat KPN bij meerdere tier 1 netwerken verkeer in zou kopen (zoals dochter Solcon doet) in plaats van alles aan de concurrent te geven.

 

Om even mezelf aan te halen (kan niet meer bewerken blijkbaar): ook XS4ALL kiest voor die optie en gebruikt nu GTT (direct) en NTT. Hoewel het direct onder KPN hangt tegenwoordig is Liberty Global daar dus niet de norm.


Ik meen dat ik eenzelfde soort probleem heb als in dit topic omschreven. Wellicht zijn hier medewerkers van KPN die meer van de hoed en de rand weten. Ik neem de vrijheid om de link naar mijn probleem hier te posten zodat er wellicht meer mensen met kennis van zaken daarop willen / kunnen reageren. 

 


Ik meen dat ik eenzelfde soort probleem heb als in dit topic omschreven. Wellicht zijn hier medewerkers van KPN die meer van de hoed en de rand weten. Ik neem de vrijheid om de link naar mijn probleem hier te posten zodat er wellicht meer mensen met kennis van zaken daarop willen / kunnen reageren. 

 

je post dit nog steeds op het consumenten deel


@robinjoo1 

Klopt helemaal en ik heb ook op het kleinzakelijke deel gepost. 
Maar mij komt / kwam het voor dat met name in dit topic meer mensen met inhoudelijke kennis zitten.