Vandaag met meerdere medewerkers van zakelijk internet gesproken, doorverbonden naar de techniekers maar zij kenden dit probleem niet en adviseerden mij om op het KPN forum te posten. Nou, dat helpt geweldig.
In overleg met onze techneuten een nieuwe test uitgevoerd. Het resultaat was, áls ik na tig pogingen contact kreeg dat de snelheid top was. Nu maar opnieuw afwachten of de netwerktechneuten bereid zijn om een onderzoek in te stellen. Opzeggen is geen optie maar als dit de service van KPN zakelijk is, dan is het diepbedroefd.
root@vuuno4kse:~# iperf3 -c 51.195.116.98 port 5201
Connecting to host 51.195.116.98, port 5201
5] local 192.168.188.221 port 49178 connected to 51.195.116.98 port 5201
ID] Interval Transfer Bitrate Retr Cwnd
5] 0.00-1.00 sec 46.9 MBytes 393 Mbits/sec 380 1.10 MBytes
5] 1.00-2.00 sec 58.3 MBytes 489 Mbits/sec 0 1.13 MBytes
5] 2.00-3.00 sec 58.4 MBytes 490 Mbits/sec 0 1.17 MBytes
5] 3.00-4.00 sec 58.2 MBytes 488 Mbits/sec 0 1.20 MBytes
5] 4.00-5.00 sec 58.1 MBytes 487 Mbits/sec 0 1.23 MBytes
5] 5.00-6.00 sec 58.3 MBytes 489 Mbits/sec 0 1.27 MBytes
5] 6.00-7.00 sec 58.5 MBytes 491 Mbits/sec 0 1.30 MBytes
5] 7.00-8.00 sec 58.4 MBytes 490 Mbits/sec 0 1.33 MBytes
5] 8.00-9.00 sec 58.6 MBytes 489 Mbits/sec 0 1.42 MBytes
5] 9.00-10.00 sec 58.0 MBytes 488 Mbits/sec 0 1.51 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
ID] Interval Transfer Bitrate Retr
5] 0.00-10.00 sec 572 MBytes 479 Mbits/sec 380 sender
5] 0.00-10.05 sec 571 MBytes 477 Mbits/sec receiver
iperf Done.
root@vuuno4kse:~# iperf3 -c 51.195.116.98 port 5201
Connecting to host 51.195.116.98, port 5201
iperf3: error - unable to connect stream: Connection timed out
root@vuuno4kse:~#
Ons bedrijf beheert de servers in kwestie, welke gehost worden door OVH, in verschillende datacenters (Strasbourg en Gravelines). Deze servers worden, als onderdeel van ons CDN, door gebruikers over de hele wereld gebruikt om bestanden te downloaden.
We ontvingen klachten van meerdere KPN gebruikers de laatste paar weken, niet of nauwelijks een verbinding kunnen maken, en als er een verbinding gemaakt kan worden, dan is het met horten en storen.
We hebben voor bovenstaande test deze namiddag ipref3 laten draaien, zodat verschillende KPN gebruikers hun connectiviteit en throughput konden testen. Zoals hierboven te zien soms met een bedroevend resultaat. Ter verduidelijking: als de KPN gebruiker “unable to connect” te zien kreeg, zien wij op de server geen enkel pakket binnen komen.
Het mag dus duidelijk zijn dat er onderweg flink packet loss op treed.
We hebben ook nog wat testen gedaan met gebruikers van andere ISPs (bv Priority Telecom) en vanuit andere landen, maar geen van die gebruikers heeft problemen.
Ergo, KPN, ga aan tafel met jullie transit parters (Orange SA in dit geval), en los jullie probleem op !
Nog even ter aanvulling, de output van KPN’s eigen lookingglass service:
Start: Fri Sep 15 22:41:53 2023
HOST: lookingglass Loss% Snt Last Avg Best Wrst StDev
1.|-- 213.197.240.51 0.0% 10 0.5 1.0 0.3 3.3 1.0
2.|-- ae2-0.br1.gs.network.is.nl 0.0% 10 0.7 2.0 0.7 13.1 3.9
3.|-- 145.54.66.162 0.0% 10 1.4 1.4 1.3 1.5 0.0
4.|-- 139.156.156.129 90.0% 10 0.8 0.8 0.8 0.8 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- nl-ams02a-rc2-lag-22-0.aorta.net 90.0% 10 2.9 2.9 2.9 2.9 0.0
7.|-- nl-ams09c-ri1-ae-6-0.aorta.net 0.0% 10 3.6 3.7 3.6 3.9 0.0
8.|-- be106.ams-gsa1-pb1-8k.nl.eu 0.0% 10 14.4 14.1 12.9 15.0 0.6
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- fra1-lim1-g1-8k.de.eu 20.0% 10 13.2 13.8 12.3 15.0 0.8
13.|-- ??? 100.0 9 0.0 0.0 0.0 0.0 0.0
@FlexCoders
Dank voor de uitvoerige reactie. Hopelijk komt er snel een inhoudelijke reactie van KPN.
Zojuist weer een kleine 45 min aan de lijn gehangen met een techneut van KPN om te kijken waar dit probleem mogelijk zou kunnen zitten. Het uiteindelijke resultaat blijft helaas dat ook hij niets voor mij kon doen. Wat hij wel kon doen is mij adviseren om een service plus abonnement te nemen zodat ik nóg betere en hardware gerichte service zou kunnen krijgen. Het feit dat ik een prima functionerende Fritzbox heb maar wat niet ‘zomaar’ door KPN ondersteund wordt is ook voor hem geen reden om te bevestigen dat het probleem elders ligt.
Kortom, weer een dag voorbij waarbij ik én niets kan verkopen omdat ik niets op maat kan inrichten vanwege het niet kunnen downloaden / installeren van software op nieuwe ontvangers maar ook geen enkele plug-in kan downloaden. Ook verlenen van service aan dezelfde hardware kan niet vanwege identieke reden. Het begint steeds vervelender te worden.
Misschien is een optie om een proxy of vpn te gebruiken zodat je misschien gebruik kan maken van een andere peering. Ik ga er vanuit dat je dit probleem dus ook hebt als je het via een hotspot via je mobiel probeert? Als die tenmiste van kpn is.
Bedankt voor je reactie. Dat had ik toevallig vanmorgen al overwogen maar mij ontbreekt de specifieke kennis om (Nord)VPN op mijn Fritzbox te installeren. Als alternatief zou ik NordVPN op een Linux ontvanger kunnen installeren om deze alternatieve route te testen. Dat kán ik in ieder geval proberen. Ik zal eens kijken of ik dit vandaag of morgen kan uitproberen.
Vanmorgen toevallig een nieuwe box ingericht en dat ging (niet meer als) redelijk. Vrijdagavond ging het totaal niet op een willekeurige andere box.
Uiteraard gaat mijn voorkeur uit naar dat KPN het fixt, maar tot op heden geen technisch inhoudelijke respons.
En nog steeds geen publieke reactie van eender welke KPN medewerker. Via PM kreeg ik van een moderator te horen dat reacties op postings worden gedaan op basis van moment van binnenkomst. Dan is de stapel toch wel erg hoog als er na bijna vijf dagen nog steeds geen publieke reactie gegeven kan worden. Het moment van afscheid nemen van KPN komt zo wel naderbij. Triest hoor.
Vanavond ga ik eenzelfde test met MTR uitvoeren bij iemand die ook zo’n ontvanger heeft én ook KPN glasvezel. Ik ben benieuwd.
Hoi @Frenzelke, ik begrijp dat je baalt van de situatie.
Nu wil ik hier graag iets zinvols over zeggen, maar ook ik heb hier te weinig idee van hoe dit allemaal in elkaar steekt. Ik heb dit daarom aan een specialist voorgelegd. Zodra ik een terugkoppeling hebt, dan kom ik weer in de lucht.
Nou, heel apart. Ik was net in de gelegenheid om bij iemand met wél een Experiabox dezelfde test op identieke hardware te doen en halleluja, ook hier vrijwel hetzelfde probleem. Onderweg naar de downloadservers van OpenPLi identiek gedrag dus 100% data loss. Hopelijk lost KPN dit probleem nu eindelijk snel op.
Last login: Tue Sep 19 16:37:08 CEST 2023 on pts/0
root@h5:~# mtr -twn -4 downloads.openpli.org
Start: 2023-09-19T16:38:32+0200
HOST: h5 Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.2.254 0.0% 10 0.6 0.7 0.4 1.5 0.3
2.|-- 195.190.228.52 0.0% 10 4.4 3.3 1.7 10.4 2.7
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 84.116.136.61 0.0% 10 3.7 3.8 3.5 4.8 0.4
7.|-- 91.121.131.85 0.0% 10 15.0 15.5 14.5 17.6 0.9
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- 213.186.32.210 0.0% 10 16.6 15.0 14.4 16.6 0.6
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- 51.178.16.136 0.0% 10 15.8 14.5 14.2 15.8 0.5
root@h5:~#
Hoi FrenZelke,
Voordat je je gaat blind staren op de zogenaamde dataloss die het mtr commando opleverd:
mtr is een simpele traceroute tool die doormiddel van ICMP verkeer alle hosts "Pingt” tussen een source en een destination en op basis van het antwoord een roundtrip aangeeft.
Het feit dat er meerdere servers tussen de source en de destination 100% packetloss hebben is simpel te verklaren door het feit dat het een redelijk standaard gebruik is om servers niet te laten reageren op dat type verkeer. Dit betekend dus niet dat er iets mis is in de route tussen source en destination, maar dat het specifieke tussenpunt niet mag/kan antwoorden op ping opdrachten
Aangezien je destination een roundtrip van rond de 15 ms geeft is er een prima verbinding tussen jou en de host downloads.openpli.org.
Ik heb een aantal test downloads gedaan van de site en trok de verschillende openpli releases in ± 1.5 seconden binnen. wat voor een bestandje van +-80 mb een prima snelheid is.
Dus eerlijk gezegd… ik zie op dit moment geen problemen met de verbinding.
Eerlijkheid gebied wel aan te geven dat ik geen gebruik maak van eenexperiabox dus ik kan niet testen of daarin mogelijk nog een issue zit. maar op de lijn tussen een consumenten aansluiting van KPN en de openpli server zie ik geen problemen
@Vulpen Vermoedelijk heb jij toevallig de mazzel gehad. Als ik een nieuwe enigma2 box ga inrichten, nadat ik een image van de OpenPLi.org downloads heb gehaald, dát gaat overigens gewoon prima, dan gaat het mis zodra ik vanuit de box verbinding maak met de downloadserver http://downloads.OpenPLi.org. Eerst moeten de packages gedownload worden wat meestal al mis gaat of zéér lang duurt. En dan heb ik het nog niet over de picons etc.
Edit: Downloaden van images van OpenPLi.org gaat probleemloos. Die staan niet op http://downloads.OpenPLi.org.
Ter test mocht ik downloaden van de sources en dat liep als de brandweer.
Ik ervaar behoudens dit probleem verder nul issues met mijn internet. Puur deze peer tussen KPN en een andere ISP. Bij mijn dochter, zij gebruikt wél een Experiabox hetzelfde probleem dus trage downloads van die download. Ik gebruik een Fritzbox maar ben ervan overtuigd dat daar het probleem niet zit.
Ik heb jouw reactie aan @FlexCoders gestuurd. Mogelijk dat hij het technisch beter als ik kan uitleggen.
Daarom hadden wij ook geadviseerd om de test met “mtr -t” te doen, en TCP te gebruiken in plaats van ICMP.
En FrenZelke maakt ook geen gebruik vande ExperiaBox.
Bovendien is al meerdere keren aangetoond dat het probleem niet op treed bij servers die niet via de Orange SA peering lopen, dus het lokale netwerk van FrenZelke, zijn uplink naar het KPN netwerk, en het interne KPN netwerk zelf zijn daarmee al uitgesloten.
En vele testen door andere gebruikers, inclusief gebruikers in Nederland met een andere ISP als KPN, hebben uitgewezen dat ook het OVH netwerk en de OVH servers niet het probleem zijn.
Ergo, het probleem zit daar tussen, en daar heeft KPN middels hun peering overeenkomsten wel degelijk controle over.
En ter afsluiting: je bedoelt in je laatste zin ongetwijfeld “zie ik op dit specifieke moment geen”. Want uit een enkele test kan verder niks worden afgeleid, andere dat wat je op dat moment observeert.
Oh, en een laatste opmerking: als je vanaf de website een download initieert, dan loopt dat over https, terwijl software updates (waar FrenZelke het over heeft) via http lopen. Dat hebben wij ook nog niet getest, dus daar gaan we nu naar kijken.
Daarom hadden wij ook geadviseerd om de test met “mtr -t” te doen, en TCP te gebruiken in plaats van ICMP.
Om via TCP SYN te testen moet je de -T en niet -t gebruiken
Dan krijg je meer respons van een aantal servers.
Maar nog steeds niet van alle servers. Het blijft nog steeds staan dat beheerders ook deze pakketten regelmatig droppen. Dit om de server te beschermen tegen een eventuele DDOS die op basis van TCP Syn pakketten uitgevoerd word.
Daarom blijft mijn eerste zin staan, staar je niet blind op de packet loss die de mtr tool aangeeft. De trage responses van verschillende hops en de packet loss bij hops die wel response geven lijken mij sneller een zorg. Daarnaast zitten er een aantal hops tussen die ge-load-balanced lijken te zijn wat het niet makkelijker maakt. als 1 van de nodes in zon cluster niet performed ben je zuur als jij nou net diegene treft in je download.
En ja mijn afsluitende zin interpreteer je correct, op basis van een aantal testen van mijn zijde kan ik geen keiharde conclusies trekken aangezien het maar 1 test is op 1 aansluiting van KPN. Daarnaast zit het lijntje te complex in elkaar (de route lijkt Nederland, België, Duitsland en Frankrijk te beslaan) om en vanaf mijn kant een oplossing/oorzaak aan te kunnen verbinden.
Ik kan me een vraag van begin dit jaar herinneren met verkeer wat over het OVH netwerk ging in combinatie met KPN aansluitingen waarbij er ook issues waren. zo uit mijn hoofd betrof dat ook een configuratie aan "Franse” zijde die niet helemaal klopte. De details zijn mij verder niet bekend.
Maar ik ben wel benieuwd of Bram (en de door hem geraadpleegde specialist) iets zien/vinden
Ik zeg zeker niet dat mtr niet zalig makend is, maar het is een van de weinige middelen die onze gezamelijke klant, met zijn kennis niveau, kan inzetten als onderzoek tool. En mede daarom hebben we ook met ipref3 getest, om een goede end-to-end TCP connectie te hebben.
Feit blijft dat het al weken erg traag is, en er regelmatig helemaal geen connectie tot stand komt, en dat dit beperkt is tot klanten van KPN. Gebruikers met andere ISPs hebben op gelijke momenten de problemen niet, Die connectie problematiek kwam ook naar voren in de ipref3 tests.
En het is niet dat er weinig gebruikers zijn, beide download servers zijn per dag samen goed voor meer dan twee miljoen zip en tar,.gz downloads, bij eventuele problemen aan de server kant zou het forum van onze klant roodgloeiend staan door klagende gebruikers.
Ik heb even de vraag van destijds erbij gehaald, toen was het ook alleen op KPN aansluitingen (voor zover bekend) en andere niet Ik kan Milweb.net niet openen, via T-Mobile wel | KPN Community.
Ik gok dat OVH een toevallige overeenkomst is in deze (hoewel het me wel triggerde)
Maar áls het eventueel aan OVH zou liggen, kan KPN daar dan een rol in spelen om dit issue op te lossen? Ook al heb ik een KPN kleinzakelijk abonnement, dan nog zijn mijn mogelijkheden om daar actief in te participeren nihil. Het zou fijn zijn als KPN hier een actieve rol in zou kunnen maar vooral in WILLEN spelen.
Welke conclusie is dan te verbinden nu ik i.p.v. de t de T heb gebruikt?
HOST: vuuno4kse Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.188.1 0.0% 10 0.7 0.8 0.7 0.9 0.1
2.|-- 195.190.228.52 0.0% 10 3.4 5.2 3.1 9.9 2.6
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- 193.251.132.225 80.0% 10 7.7 7.4 7.1 7.7 0.4
6.|-- 91.121.131.254 0.0% 10 9.8 7.9 4.7 10.5 2.3
84.116.136.61
7.|-- 91.121.131.85 60.0% 10 17.0 16.8 16.5 17.0 0.2
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- 91.121.128.2 20.0% 10 15.6 15.1 14.5 15.6 0.4
178.33.100.200
11.|-- 94.23.122.241 50.0% 10 14.7 1217. 14.7 3020. 1646.2
54.36.50.83
12.|-- 94.23.122.247 50.0% 10 19.7 819.9 18.5 3024. 1306.1
91.121.215.117
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- 51.195.116.98 70.0% 10 14.8 14.4 14.0 14.8 0.4
root@vuuno4kse:~#
Ik heb een reactie ontvangen. Met uitleg op de trace vanuit het startbericht.
In de traceroute zie je een loss van 90% staan bij stap 3 (de koppeling tussen Orange en KPN). Echter, bij stap 5 is het weer 0%. Stap 5 gaat via stap 3, dus als er daardwerkelijk loss is dan hebben alle stappen in het Orange netwerk dezelfde of hogere packetloss. Deze 90% loss is er in werkelijkheid niet, is een beveiligings mechanisme. Een traceroute is niets anders dan een groot aantal pings, en om de routers load te beperken filteren providers zoals KPN en Orange die pings. Bij stap 3 pingt de klant de KPN peta Ice router – en die reageert maar op een klein deel van de pings.
Verder zit OVH zit niet in Brussels maar in Strasbourg. Je ziet daar bij stap 7 en daarna 100% loss. Dat is waarschijnlijk een firewall die de pings blocked.
De trace richting OVH komt goed aan. We zouden graag een trace terug willen zien. Die volgt vaak namelijk een andere route, daar zit waarschijnlijk de kronkel. Maar sinds OVH de publieke tracerouteserver uit de lucht heeft gehaald lukt dat niet meer.
Vraag is nu, heb je dit ook bij OVH gemeld? Zij kunnen je hier verder bij helpen namelijk.
Bart,
Met deze reactie negeer je het feit dat Frenzeike niet netwerk technisch onderlegd is en daardoor zijn initiele observatie mogelijks niet 100% correct is, en alle posts tussen die eerste en deze van jou.
Uiteraard hebben we dit ook met OVH besproken, en die volgen onze mening: Geven het feit dat gebruikers van ALLE ANDERE ISP’s ter wereld geen problemen hebben met het maken van een connectie met de servers in kwestie (nogmaals, wij leveren meer dan 2 miljoen downloads per dag via de servers in kwestie), is het logische conclusie dat het probleem zit bij of de ISP in kwestie (KPN), of bij de peering partners van die ISP.
Aangezien we hierboven hebben aangetoond dat het probleem niet op treed bij testen van 2 KPN klanten naar servers (zowel bij OVH UK als in ons eigen UK datacenter) die niet via Orange gerouteerd worden, is de conclusie dat het probleem niet komt door iets binnen het eigen KPN netwerk, maar bij de peering partner, zeer waarschijnlijk door oversubscription en congestie van de verbinding, waardoor er veel data gedropt wordt op bepaalde tijdstippen.
@Bart_Z
Is er nog enig overleg geweest met hogere afdelingen die dit probleem wél kunnen onderzoeken en bij de juiste organisatie melding hiervan te maken. Na veel hulp van anderen ben ik er in geslaagd om via een VPN verbinding te maken en daarmee komen alle gewenste downloads, weliswaar langzamer a.g.v. de beperking van NordVPN t.o.v. mijn “glas” snelheid, maar 0% data loss. Vanavond kan ik weer een firmware upgrade uitvoeren en deze monitoren via Putty. Daarmee is m.i. onomstotelijk vastgesteld dat een omweg het probleem tackled. Echter is dat geen oplossing maar een slechte workaround. Ik vestig nog even mijn hoop op KPN die het probleem oplost, net als in het hier gelinkte probleem. Dat duurde echter een maand meen ik begrepen te hebben. Inmiddels is er op het OpenPLi forum een topic gestart en lijken meerderen er last van te hebben.
En zojuist nog even een Eperf test uitgevoerd.
Last login: Sun Sep 24 09:22:46 CEST 2023 on pts/1
root@vuuno4kse:~# iperf3 -c 51.195.116.98 -p 5201
Connecting to host 51.195.116.98, port 5201
> 5] local 10.8.1.9 port 37053 connected to 51.195.116.98 port 5201
> ID] Interval Transfer Bitrate Retr Cwnd
> 5] 0.00-1.00 sec 17.3 MBytes 145 Mbits/sec 1 568 KBytes
> 5] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec 0 589 KBytes
> 5] 2.00-3.00 sec 18.5 MBytes 155 Mbits/sec 29 437 KBytes
> 5] 3.00-4.00 sec 18.1 MBytes 152 Mbits/sec 0 500 KBytes
> 5] 4.00-5.00 sec 18.9 MBytes 159 Mbits/sec 0 546 KBytes
> 5] 5.00-6.00 sec 18.6 MBytes 156 Mbits/sec 17 406 KBytes
> 5] 6.00-7.00 sec 15.9 MBytes 133 Mbits/sec 2 436 KBytes
> 5] 7.00-8.00 sec 13.0 MBytes 109 Mbits/sec 0 456 KBytes
> 5] 8.00-9.00 sec 13.5 MBytes 113 Mbits/sec 0 476 KBytes
> 5] 9.00-10.00 sec 13.2 MBytes 111 Mbits/sec 0 495 KBytes
> ID] Interval Transfer Bitrate Retr
> 5] 0.00-10.00 sec 163 MBytes 137 Mbits/sec 49 sender
> 5] 0.00-10.06 sec 162 MBytes 135 Mbits/sec receiver
iperf Done.
root@vuuno4kse:~#
Ook weer via NordVPN. Loopt nu niet via Orange en dus is het stabieler.
Nee helaas niet. En dat komt voor zover ik weet heeft OVH voor elke isp een eigen routing die bepaald hoe het verkeer afgeleverd wordt. Voor ons zit daar een rare knik in de kronkel waar wij niks aan kunnen doen. OVH is hier van op de hoogte.
Het is dan ook goed om dit probleem ook zelf bij OVH aan te kaarten.
Nee helaas niet. En dat komt voor zover ik weet heeft OVH voor elke isp een eigen routing die bepaald hoe het verkeer afgeleverd wordt. Voor ons zit daar een rare knik in de kronkel waar wij niks aan kunnen doen. OVH is hier van op de hoogte.
Het is dan ook goed om dit probleem ook zelf bij OVH aan te kaarten.
Voor zover mij bekend heeft @FlexCoders dit al aangekaart bij OVH. Maar zeker weet ik het niet.
Vanmorgen opnieuw een test uitgevoerd bij een KPN / Enigma2 gebruiker, nu in Nijmegen. De zéér trage update met hiaten in het restoren deden ook bij hem het ergste vermoeden. Het testprogramma geïnstalleerd en dat leverde dezelfde ellende als ik van anderen maar ook bij mijzelf constateer. Het is toch van de zotten dat ik, met mijn zakelijk account, dit probleem zélf bij OVH moet aankaarten. KPN zet je eens in voor je klanten!!!!!!
Hier nog even de uitslag van de test met een Experiabox V10.
En hier opnieuw een test vanaf een ander KPN adres in Nijmegen en opnieuw, wat te verwachten was, KMP.
Configuring libncurses5.
Configuring mtr.
root@vuuno4kse:~# mtr -Twn -4 downloads.openpli.org
Start: 2023-09-25T13:33:35+0200
HOST: vuuno4kse Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.2.254 0.0% 10 0.4 0.3 0.3 0.4 0.0
2.|-- 195.190.228.161 0.0% 10 1.9 3.0 1.6 6.9 2.1
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 84.116.136.61 0.0% 10 4.7 24.4 4.5 152.4 45.3
37.187.232.46
7.|-- 91.121.131.85 60.0% 10 16.8 17.4 16.6 18.2 0.8
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- 91.121.215.117 90.0% 10 7033. 7033. 7033. 7033. 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- 51.195.116.98 60.0% 10 12.3 12.2 12.1 12.3 0.0
root@vuuno4kse:~#
Voor zover mij bekend heeft @FlexCoders dit al aangekaart bij OVH. Maar zeker weet ik het niet.
Zeker hebben wij dat.
Antwoord is dat KPN geen peering overeenkomst met ze heeft, en dat derhalve de directe connectie die OVH op de AMS-IX heeft niet gebruikt wordt. OVH routeert op basis van wat ze binnen krijgen aan BGP prefixes, de KPN prefix loopt dat via AS5511 (OpenTransit, Orange). En dat is een miezerig 10Gb lijntje dat overbelast is.
88.159.0.0/16 via 54.36.50.199 on eth0
gra_g1_nc5 2023-08-28 from 178.33.99.104] * (100/0) 0AS1136i]
via 54.36.50.199 on eth0
gra_g2_nc5 2023-08-28 from 178.33.99.105] (100/0) 0AS1136i]
88.159.0.0/16 via 54.36.50.46 on eth0
fra1_lim1_g1_8k 2023-09-14 from 178.33.99.38] * (100/0) 0AS1136i]
via 54.36.50.46 on eth0
fra1_lim1_g2_8k 2023-09-14 from 178.33.99.39] (100/0) 0AS1136i]
Als het waar zou zijn wat Bart beweert, dan zou de route van KPN naar OVH asymmetrisch zijn, snel op de heenweg (want routing onder controle van KPN) en traag op de terugweg (want OCH zou een geforceerd ander pad gebruiken). Dit is echter niet het geval, sterker nog, er is nog meer packet loss van KPN naar OVH dan er is van OVH naar KPN. Dit laatste hebben we inmiddels ook middels monitoring vast gesteld (er zijn momenten dat er 60-70% packet loss op treed), en we zijn nu met Frenzeike bezig om bij hem thuis een network monitoring probe neer te zetten.
Niet dat ik veel hoop heb dat KPN iets voor zijn klanten gaat doen. KPN staat er om bekend (als de bonte hond) in de netwerk wereld, zeker sinds ze NL-IX hebben over genomen. Dus dat zal ook wel mee spelen, nu AMS-IX een concurrent van ze is, dit soort spelletjes is KPN niet vreemd helaas.