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


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

Dan heb ik een gemiddelde van 76 ms!!!

Deze server staat in Dresden en zou normaliter een RTT hebben van ~30ms.

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...

Klantenservice van KPN vind ik best oké, ik heb ze ook niet heel vaak nodig gehad. Verbinding is bovendien heel stabiel.

Het punt is, bij de budgetproviders is de routing vaak magertjes. Die kopen transit in bij budgetpartijen als Cogent. Ik denk dan aan een Online.nl. De verbindingen naar het buitenland zijn dan ook om te janken. Maar inderdaad, van KPN verwacht ik dit niet.



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

Dan heb ik een gemiddelde van 76 ms!!!

Deze server staat in Dresden en zou normaliter een RTT hebben van ~30ms.

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...

Klantenservice van KPN vind ik best oké, ik heb ze ook niet heel vaak nodig gehad. Verbinding is bovendien heel stabiel.

Het punt is, bij de budgetproviders is de routing vaak magertjes. Die kopen transit in bij budgetpartijen als Cogent. Ik denk dan aan een Online.nl. De verbindingen naar het buitenland zijn dan ook om te janken. Maar inderdaad, van KPN verwacht ik dit niet.


En wat ik mij dan afvraag, bij XS4ALL (al langere tijd KPN) hebben die hun eigen transitverbindingen?

Want daar betaal je nog meer dan bij KPN voor een glasvezel abonnement…..



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

Dan heb ik een gemiddelde van 76 ms!!!

Deze server staat in Dresden en zou normaliter een RTT hebben van ~30ms.

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...

Klantenservice van KPN vind ik best oké, ik heb ze ook niet heel vaak nodig gehad. Verbinding is bovendien heel stabiel.

Het punt is, bij de budgetproviders is de routing vaak magertjes. Die kopen transit in bij budgetpartijen als Cogent. Ik denk dan aan een Online.nl. De verbindingen naar het buitenland zijn dan ook om te janken. Maar inderdaad, van KPN verwacht ik dit niet.


En wat ik mij dan afvraag, bij XS4ALL (al langere tijd KPN) hebben die hun eigen transitverbindingen?

Want daar betaal je nog meer dan bij KPN voor een glasvezel abonnement…..

XS4ALL heeft een eigen netwerk en gebruikt GTT en NTT als transitproviders.

Het gekke is dat het sinds maandag eigenlijk weet goed ging, maar dat het sinds de switch naar LGI weer pet is. Dát is terug te draaien.


Het wordt steeds gekker, hoe later het wordt. Nu latency tot 80ms binnen Nederland en naar België.

--- Nice Trace to adm-b1.telia.net ---

1) 10.11.12.13 (10.11.12.13) 3.689 ms, 5/5 ps, 0.0% loss
2) 192.168.178.1 (192.168.178.1) 4.429 ms, 5/5 ps, 0.0% loss
3) 195-190-228-64.fixed.kpn.net (195.190.228.64) 9.717 ms, 5/5 ps, 0.0% loss
4) * * *
5) * * *
6) nl-ams02a-rc2-lag-137-0.aorta.net (84.116.141.65) 79.975 ms, 1/4 ps, 50.0% loss AS 6830]
7) nl-ams04a-ri3-ae-8-0.aorta.net (84.116.130.97) 78.188 ms, 4/4 ps, 0.0% loss AS 6830]
8) adm-b1.telia.net (62.115.128.170) 79.085 ms, 4/4 ps, 0.0% loss AS 1299]

En naar die server in Duitsland, ik knip het eerste stuk even af. Nu al meer dan 100ms.


6) nl-ams17b-rc1-lag-12-0.aorta.net (84.116.139.129) 76.879 ms, 1/7 ps, 85.7% loss AS 6830]
7) nl-ams14a-ri1-ae-8-0.aorta.net (84.116.135.38) 7.516 ms, 7/7 ps, 0.0% loss AS 6830]
8) * * *
9) be2815.ccr41.ham01.atlas.cogentco.com (154.54.38.206) 89.345 ms, 7/7 ps, 0.0% loss AS 174]
10) be3027.ccr21.prg01.atlas.cogentco.com (130.117.1.206) 101.912 ms, 7/7 ps, 0.0% loss AS 174]
11) be2695.rcr21.drs01.atlas.cogentco.com (154.54.57.125) 106.252 ms, 6/6 ps, 0.0% loss AS 174]
12) neue-medien.demarc.cogentco.com (149.6.40.10) 104.463 ms, 6/6 ps, 0.0% loss AS 174]
13) x.kasserver.com (85.13.164.x) 103.485 ms, 6/6 ps, 0.0% loss AS 34788]

@Rutger_ Kijk je hier ook mee en stuur je dit ook door? Dank je.


@UP @soundwork @mmc @B100NL @wjb Er is nog een ander topic over hetzelfde onderwerp. Onze specialisten lezen hier mee en zijn druk bezig. Bij de activatie van Liberty Global zijn er wat dingen mis gegaan, ondanks zorgvuldig testen. Het probleem is ondertussen gevonden en we werken hard om het probleem volledig op te lossen. Onze specialisten lezen graag wat de situatie is, dus als jullie hier feedback zouden kunnen achterlaten zou dat super zijn! 


@Rutger_ om maar meteen met de deur in huis te vallen hier de route die ik dagelijks bewandel om op de VOIP server van mijn werkgever bij provider Infopact uit te komen en waar ik nog altijd flinke packet loss heb….

 

Mijn werkgever heeft 2 datacenters in Amsterdam (via de AMS-IX). Waarom ga ik via Ierland en Frankrijk naar Vught om via Vught de lijn van InfoPact binnen te wandelen?

De rood gemarkeerde adressen staan in Ierland (89.149.x.x) en Frankrijk (46.33.x.x)

Is totaal onnodig en kan via direct peering naar NL-IX of AMS-IX.

Kunnen jullie dit oplossen net zoals T-Mobile dit ook opgelost heeft?

 

 


@UP @soundwork @mmc @B100NL @wjb Er is nog een ander topic over hetzelfde onderwerp. Onze specialisten lezen hier mee en zijn druk bezig. Bij de activatie van Liberty Global zijn er wat dingen mis gegaan, ondanks zorgvuldig testen. Het probleem is ondertussen gevonden en we werken hard om het probleem volledig op te lossen. Onze specialisten lezen graag wat de situatie is, dus als jullie hier feedback zouden kunnen achterlaten zou dat super zijn! 

Dank voor de update, Rutger. Ik heb straks weer een online meeting via het platform waarmee ik gisteren ernstige problemen had. Hopelijk werkt het nu wel!

@soundwork Ik zie jouw traceroute nu gewoon in Nederland blijven, Rotterdam (rt), Amsterdam (asd en ams) en de laatste is gezien de latency ook Nederland. Dat een tooltje een andere locatie aangeeft, klopt niet. De app die ik op de iPad gebruik zet er bijvoorbeeld een Duits vlaggetje naast.  In je voorbeeld is er ook geen packet loss te zien op de eindbestemming.


@UP @soundwork @mmc @B100NL @wjb Er is nog een ander topic over hetzelfde onderwerp. Onze specialisten lezen hier mee en zijn druk bezig. Bij de activatie van Liberty Global zijn er wat dingen mis gegaan, ondanks zorgvuldig testen. Het probleem is ondertussen gevonden en we werken hard om het probleem volledig op te lossen. Onze specialisten lezen graag wat de situatie is, dus als jullie hier feedback zouden kunnen achterlaten zou dat super zijn! 

Dank voor de update, Rutger. Ik heb straks weer een online meeting via het platform waarmee ik gisteren ernstige problemen had. Hopelijk werkt het nu wel!

@soundwork Ik zie jouw traceroute nu gewoon in Nederland blijven, Rotterdam (rt), Amsterdam (asd en ams) en de laatste is gezien de latency ook Nederland. In je voorbeeld is er ook geen packet loss te zien op de eindbestemming.


Bij mij niet hoor, nog steeds via Ierland en Frankrijk.

Het zijn 2 hops van GTT in Ierland en Frankrijk.

46.33.84.186 GTT in Parijs

89.149.128.117 GTT in Dublin

De ASN is wel dezelfde…. maar dat zal binnen GTT.

Dit verkeer hoort niet via GTT te lopen, dit kan met direct peering.

 

 


@UP @soundwork @mmc @B100NL @wjb Er is nog een ander topic over hetzelfde onderwerp. Onze specialisten lezen hier mee en zijn druk bezig. Bij de activatie van Liberty Global zijn er wat dingen mis gegaan, ondanks zorgvuldig testen. Het probleem is ondertussen gevonden en we werken hard om het probleem volledig op te lossen. Onze specialisten lezen graag wat de situatie is, dus als jullie hier feedback zouden kunnen achterlaten zou dat super zijn! 

Dank voor de update, Rutger. Ik heb straks weer een online meeting via het platform waarmee ik gisteren ernstige problemen had. Hopelijk werkt het nu wel!

@soundwork Ik zie jouw traceroute nu gewoon in Nederland blijven, Rotterdam (rt), Amsterdam (asd en ams) en de laatste is gezien de latency ook Nederland. In je voorbeeld is er ook geen packet loss te zien op de eindbestemming.


Bij mij niet hoor, nog steeds via Ierland en Frankrijk.

Het zijn 2 hops van GTT in Ierland en Frankrijk.

46.33.84.186 GTT in Parijs

89.149.128.117 GTT in Dublin

 

Dat zijn de routers et-0-0-7-0.cr3-ams2.ip4.gtt.net en ae1.cr3-ams2.ip4.gtt.net. Die AMS maakt vrij duidelijk dat ze in Amsterdam staan :wink: . Waar zie jij Ierland en Frankrijk? 

Ook de RTT van onder de 8ms maakt duidelijk dat dit binnen Nederland blijft. Gezien het feit dat Parijs ongeveer 15ms weg is en Dublin ongeveer 25ms zou je >40ms verwachten.

De ASN is wel dezelfde…. maar dat zal binnen GTT.

Dit verkeer hoort niet via GTT te lopen, dit kan met direct peering.

 

 

Ja, of het hoort is een hele discussie op zich. KPN heeft een selectief peeringbeleid, als die ISP met KPN wil peeren via NL-IX dan kunnen ze daarvoor een verzoek doen. Zelf vind ik het altijd een gemis dat KPN niet meer op de AMS-IX zit, waardoor je een aantal mogelijke peers mist. Maar ja, NL-IX is van KPN dus do the math :wink:


@UP @soundwork @mmc @B100NL @wjb Er is nog een ander topic over hetzelfde onderwerp. Onze specialisten lezen hier mee en zijn druk bezig. Bij de activatie van Liberty Global zijn er wat dingen mis gegaan, ondanks zorgvuldig testen. Het probleem is ondertussen gevonden en we werken hard om het probleem volledig op te lossen. Onze specialisten lezen graag wat de situatie is, dus als jullie hier feedback zouden kunnen achterlaten zou dat super zijn! 

Dank voor de update, Rutger. Ik heb straks weer een online meeting via het platform waarmee ik gisteren ernstige problemen had. Hopelijk werkt het nu wel!

@soundwork Ik zie jouw traceroute nu gewoon in Nederland blijven, Rotterdam (rt), Amsterdam (asd en ams) en de laatste is gezien de latency ook Nederland. In je voorbeeld is er ook geen packet loss te zien op de eindbestemming.


Bij mij niet hoor, nog steeds via Ierland en Frankrijk.

Het zijn 2 hops van GTT in Ierland en Frankrijk.

46.33.84.186 GTT in Parijs

89.149.128.117 GTT in Dublin

 

Dat zijn de routers et-0-0-7-0.cr3-ams2.ip4.gtt.net en ae1.cr3-ams2.ip4.gtt.net. Die AMS maakt vrij duidelijk dat ze in Amsterdam staan :wink: . Waar zie jij Ierland en Frankrijk? 

Ook de RTT van onder de 8ms maakt duidelijk dat dit binnen Nederland blijft. Gezien het feit dat Parijs ongeveer 15ms weg is en Dublin ongeveer 25ms zou je >40ms verwachten.

De ASN is wel dezelfde…. maar dat zal binnen GTT.

Dit verkeer hoort niet via GTT te lopen, dit kan met direct peering.

 

 

Ja, of het hoort is een hele discussie op zich. KPN heeft een selectief peeringbeleid, als die ISP met KPN wil peeren via NL-IX dan kunnen ze daarvoor een verzoek doen. Zelf vind ik het altijd een gemis dat KPN niet meer op de AMS-IX zit, waardoor je een aantal mogelijke peers mist. Maar ja, NL-IX is van KPN dus do the math :wink:


Die FQDN's die aan die hop hangen, klopt dat dan ook echt??

Als ik de 2 IP adressen door geo-loc's haal, dan kom ik bij 1 adres uit in de UK, Ierland en 1 geeft zelfs VS aan. De andere in Parijs. Dus die info klopt dan niet?

En ja, ik snap niet dat dit verkeer niet over de NL-IX gaat… maar dat zal wel komen omdat InfoPact dan weer geen peering overeenkomst heeft met NL-IX en alleen met AMS-IX.

 

Toevoeging 19:48 uur:

Voor de vergelijking even een plaatje via T-Mobile Thuis glasvezel.

Zij peeren nog wel met AMS-IX (maar overigens wel een hogere latency, dat is nog altijd bij TMNL een "zwakte”) maar wel korte route:

 

 


@UP @soundwork @mmc @B100NL @wjb Er is nog een ander topic over hetzelfde onderwerp. Onze specialisten lezen hier mee en zijn druk bezig. Bij de activatie van Liberty Global zijn er wat dingen mis gegaan, ondanks zorgvuldig testen. Het probleem is ondertussen gevonden en we werken hard om het probleem volledig op te lossen. Onze specialisten lezen graag wat de situatie is, dus als jullie hier feedback zouden kunnen achterlaten zou dat super zijn! 

Dank voor de update, Rutger. Ik heb straks weer een online meeting via het platform waarmee ik gisteren ernstige problemen had. Hopelijk werkt het nu wel!

@soundwork Ik zie jouw traceroute nu gewoon in Nederland blijven, Rotterdam (rt), Amsterdam (asd en ams) en de laatste is gezien de latency ook Nederland. In je voorbeeld is er ook geen packet loss te zien op de eindbestemming.


Bij mij niet hoor, nog steeds via Ierland en Frankrijk.

Het zijn 2 hops van GTT in Ierland en Frankrijk.

46.33.84.186 GTT in Parijs

89.149.128.117 GTT in Dublin

 

Dat zijn de routers et-0-0-7-0.cr3-ams2.ip4.gtt.net en ae1.cr3-ams2.ip4.gtt.net. Die AMS maakt vrij duidelijk dat ze in Amsterdam staan :wink: . Waar zie jij Ierland en Frankrijk? 

Ook de RTT van onder de 8ms maakt duidelijk dat dit binnen Nederland blijft. Gezien het feit dat Parijs ongeveer 15ms weg is en Dublin ongeveer 25ms zou je >40ms verwachten.

De ASN is wel dezelfde…. maar dat zal binnen GTT.

Dit verkeer hoort niet via GTT te lopen, dit kan met direct peering.

 

 

Ja, of het hoort is een hele discussie op zich. KPN heeft een selectief peeringbeleid, als die ISP met KPN wil peeren via NL-IX dan kunnen ze daarvoor een verzoek doen. Zelf vind ik het altijd een gemis dat KPN niet meer op de AMS-IX zit, waardoor je een aantal mogelijke peers mist. Maar ja, NL-IX is van KPN dus do the math :wink:


Die FQDN's die aan die hop hangen, klopt dat dan ook echt??

Als ik de 2 IP adressen door geo-loc's haal, dan kom ik bij 1 adres uit in de UK, Ierland en 1 geeft zelfs VS aan. De andere in Parijs. Dus die info klopt dan niet?

 

Nee, Geo IP info bij dit soort adressen is meestal onzin. Dit zijn hele blokken vol routers en die worden niet per adresgroep ingedeeld over het algemeen. De PTR klopt zeker niet altijd, maar in dit geval is het duidelijk dat ‘AMS’ en een RTT van 7ms erop wijzen dat het Nederland is.

 

Voor de vergelijking even een plaatje via T-Mobile Thuis glasvezel.

Zij peeren nog wel met AMS-IX (maar overigens wel een hogere latency, dat is nog altijd bij TMNL een "zwakte”) maar wel korte route:

 

 

Een kortere route zegt niet zo heel veel in dit geval. De verbinding is in theorie beter via KPN, maar dat is onmerkbaar.


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Een hop zegt niet zoveel. Dat is een router of switch die zich kenbaar maakt, maar minder is niet noodzakelijk beter hierin. Zoals je ook kunt zien aan de vergelijking hier, waarbij de KPN-verbinding theoretisch gezien beter is.

Het staat hooguit netter als er minder hops zijn, maar het zegt weinig. Bedenk bijvoorbeeld dat er netwerken zijn waarin iedere tussenliggende router zich kenbaar maakt en dat er netwerken zijn waarin je niets ziet. Bij die tweede lijkt het directer, maar kunnen er bij wijze van spreken nog 10 switches tussenstaan die allemaal een point of failure zijn. Je kunt geen conclusie trekken op basis van een traceroute zonder de architectuur te kennen.

Als ik naar die 3 hops van GTT kijk, dan zie ik een router op hun AMS1 locatie die in verbinding staat met KPN, die zet het door naar een router op de AMS2 locatie en die routeert naar het eindpunt: de router die de verbinding maakt met Infopact.

Uiteindelijk: als je 100 hops nodig hebt en je hebt een prima verbinding, dan is er niets aan de hand. En ik zie in jouw screenshot een latency van 7,5ms en 0% packet loss op de eindbestemming. Dus dat is gewoon een goeie verbinding.

@Rutger_ Vanavond een videomeeting gehad van vijf kwartier, met slechts één enkel hikje. Nog even gecheckt op wat servers die hier de afgelopen dagen naar voren kwamen en geen grote problemen gezien. Af en toe wat hele lichte packet loss, maar het gaat al heel ver de goeie richting uit.


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?

Je hebt een screenshot gepost waarin geen packet loss te zien is op de eindbestemming. Treedt zoiets dan op bepaalde momenten op? En wat zie je dan in het tooltje dat je hiervoor gebruikt? Dat zou erg helpen om te weten of het aan KPN ligt, aan jou of aan de sever.


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?

Je hebt een screenshot gepost waarin geen packet loss te zien is op de eindbestemming. Treedt zoiets dan op bepaalde momenten op? En wat zie je dan in het tooltje dat je hiervoor gebruikt? Dat zou erg helpen om te weten of het aan KPN ligt, aan jou of aan de sever.


Zodra ik bel, hoor ik “gaten” in het gesprek (wat meestal duidt op packet loss), maar ik zie heel soms als ik de PingPlotter langer laat lopen 0,2 procent packet loss op de eindbestemming, duidt dan op een probleem aan de server of aan InfoPact zijde? De gesprekskwaliteit is niet altijd slecht, soms wat beter dan de andere keer maar echt “schoon” is geen enkel gesprek…..


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?

Je hebt een screenshot gepost waarin geen packet loss te zien is op de eindbestemming. Treedt zoiets dan op bepaalde momenten op? En wat zie je dan in het tooltje dat je hiervoor gebruikt? Dat zou erg helpen om te weten of het aan KPN ligt, aan jou of aan de sever.


Zodra ik bel, hoor ik “gaten” in het gesprek (wat meestal duidt op packet loss), maar ik zie heel soms als ik de PingPlotter langer laat lopen 0,2 procent packet loss op de eindbestemming, duidt dan op een probleem aan de server of aan InfoPact zijde? De gesprekskwaliteit is niet altijd slecht, soms wat beter dan de andere keer maar echt “schoon” is geen enkel gesprek…..

Als je het alleen op de eindbestemming ziet, dan ligt het inderdaad bij Infopact. Zie je het ergens op de route ontstaan dan ligt het elders. Begint het al bij je eigen router, dan ligt het daaraan. Overigens is 0,2 procent wel erg weinig om veel last van te hebben. Dat zou af en toe een dipje zijn. Hoe is de pc waarmee je verbonden bent aangesloten op internet? Misschien zijn het wel WiFi issues.

En hoe lang speelt het al? De problemen waarvoor ik dit topic heb gestart, spelen nu twee weken.


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?

Je hebt een screenshot gepost waarin geen packet loss te zien is op de eindbestemming. Treedt zoiets dan op bepaalde momenten op? En wat zie je dan in het tooltje dat je hiervoor gebruikt? Dat zou erg helpen om te weten of het aan KPN ligt, aan jou of aan de sever.


Zodra ik bel, hoor ik “gaten” in het gesprek (wat meestal duidt op packet loss), maar ik zie heel soms als ik de PingPlotter langer laat lopen 0,2 procent packet loss op de eindbestemming, duidt dan op een probleem aan de server of aan InfoPact zijde? De gesprekskwaliteit is niet altijd slecht, soms wat beter dan de andere keer maar echt “schoon” is geen enkel gesprek…..

Als je het alleen op de eindbestemming ziet, dan ligt het inderdaad bij Infopact. Zie je het ergens op de route ontstaan dan ligt het elders. Begint het al bij je eigen router, dan ligt het daaraan. Overigens is 0,2 procent wel erg weinig om veel last van te hebben. Dat zou af en toe een dipje zijn. Hoe is de pc waarmee je verbonden bent aangesloten op internet? Misschien zijn het wel WiFi issues.

En hoe lang speelt het al? De problemen waarvoor ik dit topic heb gestart, spelen nu twee weken.


Nee, al mijn testen zijn gedaan op de vaste netwerkkabel (ook mijn VOIP toestel zit aan een kabeltje vast met PoE). Het speelt vanaf begin van mijn aansluiting, sinds 18 augustus op KPN aangesloten.


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?

Je hebt een screenshot gepost waarin geen packet loss te zien is op de eindbestemming. Treedt zoiets dan op bepaalde momenten op? En wat zie je dan in het tooltje dat je hiervoor gebruikt? Dat zou erg helpen om te weten of het aan KPN ligt, aan jou of aan de sever.


Zodra ik bel, hoor ik “gaten” in het gesprek (wat meestal duidt op packet loss), maar ik zie heel soms als ik de PingPlotter langer laat lopen 0,2 procent packet loss op de eindbestemming, duidt dan op een probleem aan de server of aan InfoPact zijde? De gesprekskwaliteit is niet altijd slecht, soms wat beter dan de andere keer maar echt “schoon” is geen enkel gesprek…..

Als je het alleen op de eindbestemming ziet, dan ligt het inderdaad bij Infopact. Zie je het ergens op de route ontstaan dan ligt het elders. Begint het al bij je eigen router, dan ligt het daaraan. Overigens is 0,2 procent wel erg weinig om veel last van te hebben. Dat zou af en toe een dipje zijn. Hoe is de pc waarmee je verbonden bent aangesloten op internet? Misschien zijn het wel WiFi issues.

En hoe lang speelt het al? De problemen waarvoor ik dit topic heb gestart, spelen nu twee weken.


Nee, al mijn testen zijn gedaan op de vaste netwerkkabel (ook mijn VOIP toestel zit aan een kabeltje vast met PoE). Het speelt vanaf begin van mijn aansluiting, sinds 18 augustus op KPN aangesloten.

Het lijkt me dan niet zozeer met routing te maken te hebben. Gebruik je een Experiabox? Wellicht dat deze wat moeite heeft.

 

Wat betreft het internetverkeer heb ik vanochtend nog last gehad van een kleine verslechtering. Inclusief hoge pings en packet loss, maar verder niets aan de hand.


Of geo IP locatie nu onzin is of niet, het blijft idioot dat GTT 3 hops nodig heeft om bij InfoPact uit te komen, dat ben je hopelijk met mij eens toch?

Volgens jouw grafiek ben je in 2,5ms van de KPN core router bij die ISP. Dat is een prima performance. 3 hops heb je al snel. Met die 2,5ms latency kan je ook never nooit via Dublin gaan. 


Ok, op dat vlak ben ik nu overtuigd.

Toch vind ik het vreemd sinds op KPN aangesloten ben, ik last heb van packet loss. Mijn collega's naar dezelfde server (eindbesteming) rapporteren dit niet. Kan het dan zijn dat het ergens bij GTT stuk gaat want als het bij InfoPact of op de server zelf zou zitten zouden al mijn collega's hetzelfde probleem moeten hebben toch?

Je hebt een screenshot gepost waarin geen packet loss te zien is op de eindbestemming. Treedt zoiets dan op bepaalde momenten op? En wat zie je dan in het tooltje dat je hiervoor gebruikt? Dat zou erg helpen om te weten of het aan KPN ligt, aan jou of aan de sever.


Zodra ik bel, hoor ik “gaten” in het gesprek (wat meestal duidt op packet loss), maar ik zie heel soms als ik de PingPlotter langer laat lopen 0,2 procent packet loss op de eindbestemming, duidt dan op een probleem aan de server of aan InfoPact zijde? De gesprekskwaliteit is niet altijd slecht, soms wat beter dan de andere keer maar echt “schoon” is geen enkel gesprek…..

Als je het alleen op de eindbestemming ziet, dan ligt het inderdaad bij Infopact. Zie je het ergens op de route ontstaan dan ligt het elders. Begint het al bij je eigen router, dan ligt het daaraan. Overigens is 0,2 procent wel erg weinig om veel last van te hebben. Dat zou af en toe een dipje zijn. Hoe is de pc waarmee je verbonden bent aangesloten op internet? Misschien zijn het wel WiFi issues.

En hoe lang speelt het al? De problemen waarvoor ik dit topic heb gestart, spelen nu twee weken.


Nee, al mijn testen zijn gedaan op de vaste netwerkkabel (ook mijn VOIP toestel zit aan een kabeltje vast met PoE). Het speelt vanaf begin van mijn aansluiting, sinds 18 augustus op KPN aangesloten.

Het lijkt me dan niet zozeer met routing te maken te hebben. Gebruik je een Experiabox? Wellicht dat deze wat moeite heeft.

 

Wat betreft het internetverkeer heb ik vanochtend nog last gehad van een kleine verslechtering. Inclusief hoge pings en packet loss, maar verder niets aan de hand.


Nope, geen Experiabox maar eigen router (Ubiquiti ER-4 met eigen SFP).

Het baart mij wel zorgen dat de slechtere routing er nog niet uit is….

V.w.b. de packet loss naar de VOIP server… ik zou eens een dagje bij mij ouders thuis moeten werken, PoE injector en VOIP toestel mee. Zij hebben dezelfde router op een T-Mobile Thuis zitten. Hoor ik daar ook de “gaten” in gesprekken dan lijkt het mij snel duidelijk….


@Rutger_ al meer duidelijkheid hierover?

Graag zou ik mijn packet loss issue toch onderzocht willen hebben of dit bij GTT stuk gaat.

Het is niet te doen…… Echt om te huilen.


Waar ik wel benieuwd naar ben is hoe die routes via Liberty Global lopen bij andere ISPs zoals Ziggo. Ik kan me niet voorstellen dat ze daar ook de boel via Cogent laten lopen terwijl er betere routes beschikbaar zijn.


@soundwork Over deze specifieke situatie is nog niet meer duidelijkheid. Ik hoor veel geluiden dat de routing beter geworden is, in jouw geval gaat het vooral om de VOIP verbinding begrijp ik? Wellicht dat @wjb tijd heeft om hier nog eens naar mee te kijken? Om te kijken of het probleem daadwerkelijk door packet loss ontstaat. Ik zal vandaag mijn collega nogmaals aanspreken om te vragen wat de stand van zaken is, zodra ik meer informatie heb zal ik dit hier delen! 


@soundwork Over deze specifieke situatie is nog niet meer duidelijkheid. Ik hoor veel geluiden dat de routing beter geworden is, in jouw geval gaat het vooral om de VOIP verbinding begrijp ik? Wellicht dat @wjb tijd heeft om hier nog eens naar mee te kijken? Om te kijken of het probleem daadwerkelijk door packet loss ontstaat. Ik zal vandaag mijn collega nogmaals aanspreken om te vragen wat de stand van zaken is, zodra ik meer informatie heb zal ik dit hier delen! 


Hallo @Rutger_ gisteren was er bij ons sprake van een issue op de server wat de packet loss veroorzaakte. Collega's met een Ziggo verbinding hadden ook forse problemen. Dus mijn bericht van gisteren kan je even vergeten.