Rare routing zorgt voor verminderde connectviteit

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

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? 

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?

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!

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. 

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_ 

 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.

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.

UP schreef:

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.

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.

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. 

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.