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

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?

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.

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.

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

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 

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:

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?

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. 

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.

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! 

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.