Hierbij een verzoek aan de experts van KPN om een oplossing te bieden voor een helaas teruggekeerd probleem. Dit is voor zover ik mij kan herinneren een probleem wat zo’n twee jaar geleden ook is opgetreden en na een telefoontje met de klantenservice van KPN, wat overigens niet heel zinvol bleek omdat dit volgens de medewerker KPN buiten haar kennisnivo lag, maar gelukkig uiteindelijk weer net zo opgelost was als dat het startte. Uit het niets.Eerst maar enige speciale informatie.Ik heb internet via glas met een FritZbox 7590 waarbij ik 1000 Mbps zou moeten hebben maar dat is destijds blijven hangen op 500 Mbps. Mijn internet en netwerk functioneert verder prima. Binnen mijn netwerk heb ik, behoudens diverse IPads en IPhones ook diverse Enigma2 satellietontvangers die leen voorzien zijn van de bij insiders bekende OpenPLi firmware. Ik ben overigens bestuurslid van deze vereniging maar dat speelt verder geen rol. Aangezien ik, mede uit hoofde van mijn functie binnen de vereniging, veel test en mijn hardware dan ook vrijwel dagelijks voorzie van nieuwe firmware en / of test met meerdere plug-ins is het prettig als mijn verbinding gewoon goed functioneert. Sinds een mij onbekend moment kwam het mij voor dat updates of installeren van applicaties geregeld erg lang duurde. Rechtstreeks contact met meerdere leden van OpenPLi w.o. onze systeembeheerder leerde ons dat er tussen mijn aansluiting en de downloadserver(s) van OpenPLi (downloads.OpenPLi.org) een fors data loss optreedt en wel tussen KPN en een van de volgende ISP’s, in dit geval Orange. Dit is vanmorgen in een eerste telefonisch contact met de tweede medewerker van de klantenservice, voor de eerste bleek het probleem al te lastig, duidelijk doorgenomen. Het enige wat hij voor mij kon doen wat mij verwijzen naar https://internet.nl om daar een test uit te voeren. Hij ging volledig voorbij aan het door ons al uitgevoerde onderzoek wat duidelijk geregistreerd had dat het probleem in de koppeling met Orange ontstond. Ik heb vanaf mijn hardware meerdere tests uitgevoerd met de bekende Linux tool MTR. De resultaten gaven onmiskenbaar aan dat het probleem zat in de koppeling tussen KPN en Orange S.A in Frankrijk. Daarna blijft er helemaal niets meer over van de data. Helaas zei de medewerker van KPN dat hij hier niets aan kon doen wat mij vreemd leek.Ik vestig mijn hoop dan ook op KPN medewerkers die mogelijk wél iets voor mij kunnen betekenen want op deze manier kan IK niet meer testen voor onze vereniging. Hieronder de regel die ik altijd gebruik om de tracé uit te voeren.root@vuuno4kse:~# mtr -twn -4 downloads.openpli.orgStart: 2023-09-13T23:42:03+0200HOST: vuuno4kse Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.188.1 0.0% 10 0.8 1.1 0.8 3.0 0.8 2.|-- 195.190.228.52 0.0% 10 4.8 3.7 2.6 6.8 1.3KPN Eindhoven of elders 3.|-- 193.251.152.108 90.0% 10 3.3 3.3 3.3 3.3 0.0 Orange Parijs 4.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.0 5.|-- 193.251.132.225 0.0% 10 6.8 6.9 6.7 7.3 0.2 6.|-- 91.121.131.254 0.0% 10 8.9 8.8 7.7 10.3 0.7OVH SAS Brussel 7.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.0 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.010.|-- 91.121.131.27 0.0% 10 14.8 15.1 14.8 16.1 0.411.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.012.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.013.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.014.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.015.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.016.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.017.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.018.|-- 51.178.16.136 0.0% 10 14.1 14.1 13.8 15.0 0.4 Flexcoders (downloads.openpli.org)

Beantwoord

Probleem met routing tussen KPN en Orange

7 maanden geleden
14 September 2023
55 reacties
1499 keer bekeken

Reputatie 1

Frenzelke
Helper
40 reacties

Hierbij een verzoek aan de experts van KPN om een oplossing te bieden voor een helaas teruggekeerd probleem. Dit is voor zover ik mij kan herinneren een probleem wat zo’n twee jaar geleden ook is opgetreden en na een telefoontje met de klantenservice van KPN, wat overigens niet heel zinvol bleek omdat dit volgens de medewerker KPN buiten haar kennisnivo lag, maar gelukkig uiteindelijk weer net zo opgelost was als dat het startte. Uit het niets.

Eerst maar enige speciale informatie.

Ik heb internet via glas met een FritZbox 7590 waarbij ik 1000 Mbps zou moeten hebben maar dat is destijds blijven hangen op 500 Mbps. Mijn internet en netwerk functioneert verder prima.
Binnen mijn netwerk heb ik, behoudens diverse IPads en IPhones ook diverse Enigma2 satellietontvangers die leen voorzien zijn van de bij insiders bekende OpenPLi firmware. Ik ben overigens bestuurslid van deze vereniging maar dat speelt verder geen rol.
Aangezien ik, mede uit hoofde van mijn functie binnen de vereniging, veel test en mijn hardware dan ook vrijwel dagelijks voorzie van nieuwe firmware en / of test met meerdere plug-ins is het prettig als mijn verbinding gewoon goed functioneert.
Sinds een mij onbekend moment kwam het mij voor dat updates of installeren van applicaties geregeld erg lang duurde. Rechtstreeks contact met meerdere leden van OpenPLi w.o. onze systeembeheerder leerde ons dat er tussen mijn aansluiting en de downloadserver(s) van OpenPLi (downloads.OpenPLi.org) een fors data loss optreedt en wel tussen KPN en een van de volgende ISP’s, in dit geval Orange.
Dit is vanmorgen in een eerste telefonisch contact met de tweede medewerker van de klantenservice, voor de eerste bleek het probleem al te lastig, duidelijk doorgenomen. Het enige wat hij voor mij kon doen wat mij verwijzen naar https://internet.nl om daar een test uit te voeren. Hij ging volledig voorbij aan het door ons al uitgevoerde onderzoek wat duidelijk geregistreerd had dat het probleem in de koppeling met Orange ontstond.

Ik heb vanaf mijn hardware meerdere tests uitgevoerd met de bekende Linux tool MTR. De resultaten gaven onmiskenbaar aan dat het probleem zat in de koppeling tussen KPN en Orange S.A in Frankrijk. Daarna blijft er helemaal niets meer over van de data. Helaas zei de medewerker van KPN dat hij hier niets aan kon doen wat mij vreemd leek.

Ik vestig mijn hoop dan ook op KPN medewerkers die mogelijk wél iets voor mij kunnen betekenen want op deze manier kan IK niet meer testen voor onze vereniging. Hieronder de regel die ik altijd gebruik om de tracé uit te voeren.

root@vuuno4kse:~# mtr -twn -4 downloads.openpli.org

Start: 2023-09-13T23:42:03+0200

HOST: vuuno4kse Loss% Snt Last Avg Best Wrst StDev

1.|-- 192.168.188.1 0.0% 10 0.8 1.1 0.8 3.0 0.8

2.|-- 195.190.228.52 0.0% 10 4.8 3.7 2.6 6.8 1.3KPN Eindhoven of elders

3.|-- 193.251.152.108 90.0% 10 3.3 3.3 3.3 3.3 0.0 Orange Parijs

4.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.0

5.|-- 193.251.132.225 0.0% 10 6.8 6.9 6.7 7.3 0.2

6.|-- 91.121.131.254 0.0% 10 8.9 8.8 7.7 10.3 0.7OVH SAS Brussel

7.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.0

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.131.27 0.0% 10 14.8 15.1 14.8 16.1 0.4

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.|-- ??? 100.0% 10 0.0 0.0 0.0 0.0 0.0

18.|-- 51.178.16.136 0.0% 10 14.1 14.1 13.8 15.0 0.4 Flexcoders (downloads.openpli.org)

icon

Beste antwoord door Bart van KPN 28 September 2023, 16:13

Bekijk origineel

Toon eerste bericht Verberg eerste bericht

55 reacties

Bladzijde 2 / 3

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
25 September 2023

@Bart_Z

Wat is het bezwaar om de door @FlexCoders neergelegde informatie neer te leggen bij de betreffende afdeling die daar wél ‘van de hoed en de rand weten’? Dit probleem is uit het niets ontstaan maar het exacte moment is mij onbekend. Ik hoop dat, zodra de monitoring een feit is, dat wij KPN kunnen overtuigen van het probleem. Mijn internet (browsing en mail etc.) is prima. Het gaat dus puur om de peering die KPN blijkbaar NIET heeft.

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
25 September 2023

De monitoring tussen mijn adres en de OpenPLi server(s) is actief. Ik kan ernaar kijken maar om een conclusie te trekken wat de data oplevert is niet aan mij besteed. Ik zal morgen mogelijk een overzicht kunnen posten.

Reputatie 7

+20

Bart van KPN
Oud Moderator
12863 reacties
7 maanden geleden
26 September 2023

Ook wij hebben dit bij OVH aangekaart. Maar is nog niet veel uitgekomen helaas. Het is dus goed om het zelf ook nog eens aan te kaarten bij OVH.

Bij OVH kan je als klant aan de gang blijven en het issue onder de aandacht blijven brengen, eigenlijk zijn ze er vrij helder met het antwoord… verwijs je provider naar http://peering.ovh.net/ en laat hen (KPN) een peering-request indienen of gebruik maken van de exchanges waar wij zelf op zitten.

(escalation) heeft al eens gepoogd om hun NOC iets met KPN voor elkaar te krijgen, alleen is NOC van mening dat het de ISP is die dit moet aanvragen en niet een OVH-consumer.

Het is best vreemd dat KPN geen directe peering overeenkomst heeft met Europa's grootste hosting/server boer waar toch eigenlijk heel veel gebruik van gemaakt wordt.

Dat KPN gebruik maakt van Orange is inderdaad wel een slordige (goedkope) zet.

De resultaten van onze netwerk probe mogen duidelijk zijn:

Er zijn heel veel momenten dat er gewoon geen pakket door komt (dit is een download van een 100KB file, eens per 60 seconden, waarbij response time en download speed in bps gemeten wordt).

Gewoon onwerkbaar voor jullie klant, en eigenlijk triest dat die zo behandeld wordt.

Reputatie 7

+20

Bart van KPN
Oud Moderator
12863 reacties
7 maanden geleden
26 September 2023

Ik begrijp het punt en de teleurstelling van de slechte werking. Echter kunnen wij hier niets aan doen. Wij hebben dit zoals gezegd ook bij OVH aangekaart. Het ligt buiten onze macht, zij zijn aan zet. Dus wellicht kun je daar meldingen maken. Misschien dat als er nog meer bij komen dat OVH de prioriteit van het issue kan opschalen.

Meer kan ik er simpelweg niet van maken.

Sorry Bart, maar je kletst uit de spreekwoordelijke nek.

Ik heb een achtergrond in datacenters en carrier networks, en weet derhalve uitstekend hoe het werkt.

Het is aan KPN om te zorgen voor voldoende betrouwbare bandbreedte voor zijn klanten, niet aan de aanbieder van diensten, en zeker niet aan de datacenters van waar die diensten aangeleverd worden.

OVH heeft connectiviteit naar de AMS-IX, met 2 x 500Gbps aan geconnecteerde bandbreedte, en een open peering policy. Het is aan KPN om een peering overeenkomst aan te gaan, en dat verdommen ze sinds ze eigenaar zijn van NL-IX en AMS-IX nu een concurrent van ze geworden is. En dus moet alle verkeer nu via een lullig 10Gb lijntje van Orange.

Het is bedrijfspolitiek en daar zijn jullie klanten de dupe van! Met dit antwoord steek je dus gewoon de middelvinger op naar jullie klanten. Meer WIL je er dus niet van maken.

Nog even de feedback van OVH:

If you look at this mtr:

You're trying to reach the IP 86.86.x.x which is part of KPN.

As you can see, the hop 10 has 0.0% of loss - then, once it reaches the 11 hop it keeps increasing the data loss.

Hop 11 is part of '193.251.128.0/19AS5511', as per Hop 12

route:          193.251.128.0/19
descr:          France Telecom / Orange SA
descr:          OPENTRANSIT
origin:         AS5511
mnt-by:         FT-BRX

It doesn't recognise Hop 13 but then it has a 2% loss on the last hop (14) which is part of KPN.

root@vps-942f1fdc:~ $ mtr -o 'J M X LSR NA B W V' -wzbc 50 86.86.120.1
Start: 2023-09-26T12:42:36+0000
HOST: vps-942f1fdc Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
1. AS16276 51.195.116.1 0.1 0.1 0.2 0.0% 50 50 0.2 0.2 0.1 0.3 0.0
2. AS??? 192.168.143.254 0.0 0.0 0.1 0.0% 50 50 0.2 0.2 0.1 0.2 0.0
3. AS??? 10.13.117.190 0.0 0.0 0.2 0.0% 50 50 0.3 0.3 0.2 0.5 0.0
4. AS??? 10.13.96.242 0.1 0.1 0.1 0.0% 50 50 0.3 0.3 0.3 0.5 0.1
5. AS??? 10.13.88.116 0.0 0.0 0.2 0.0% 50 50 0.4 0.3 0.2 0.5 0.0
6. AS??? 10.73.41.12 0.0 0.1 0.2 0.0% 50 50 0.3 0.3 0.2 0.5 0.1
7. AS??? 10.73.249.66 1.0 4.6 12.3 88.0% 50 6 2.9 6.4 2.0 15.0 5.5
8. AS16276 fra-fr5-sbb1-nc5.de.eu (91.121.215.116) 0.3 0.2 0.5 0.0% 50 50 2.1 1.8 1.6 2.2 0.2
9. AS??? 10.200.0.13 33.0 16.3 89.3 0.0% 50 50 34.6 17.9 1.5 90.9 27.0
10. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
11. AS??? 193.251.129.121 0.3 0.1 0.3 50.0% 50 25 8.2 8.2 8.0 8.4 0.1
12. AS??? 193.251.152.102 3.1 4.1 12.1 72.0% 50 14 105.5 104.0 96.4 109.9 4.2
13. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
14. AS1136 86-86-x-x.fixed.kpn.net (86.86.x.x) 0.4 0.1 0.5 2.0% 50 49 15.2 14.9 14.6 15.3 0.1

Reputatie 6

wat wil je hiermee bereiken ? kpn gaat je toch niet helpen

Wij hebben zakelijk hetzelfde probleem. Ook OVH klanten die slechte connectie krijgen naar onze KPN adressen. Via zoekfunctie dit topic gevonden , link gegeven naar dit topic en contact gehad met KPN medewerkers met dezelfde antwoorden als hier.

Hoewel ik begrijp dat KPN niet heel internet kan beheren is het wel erg triest als het zoals hier geopperd wordt de oorzaak is dat er geen peering overeenkomst is met OVH.

Ook ben ik van mening dat KPN dit samen met OVH op zou moeten pakken.

Waarom moeten wij als klant hier mee bezig zijn, uitzoeken EN contact op nemen met andere partijen? Wij zijn klant en willen goed bereikbaar zijn vanuit adressen wereldwijd. Als KPN daar niet voor kan zorgen is het tijd om naar een andere provider? Ik mag hopen dat dat meegenomen wordt bij de beslissing om geen peering overeenkomst af te sluiten

Sorry Bart, maar je kletst uit de spreekwoordelijke nek.

Ik heb een achtergrond in datacenters en carrier networks, en weet derhalve uitstekend hoe het werkt.

Het is aan KPN om te zorgen voor voldoende betrouwbare bandbreedte voor zijn klanten, niet aan de aanbieder van diensten, en zeker niet aan de datacenters van waar die diensten aangeleverd worden.

Het is bedrijfspolitiek en daar zijn jullie klanten de dupe van! Met dit antwoord steek je dus gewoon de middelvinger op naar jullie klanten. Meer WIL je er dus niet van maken.

Misschien zoek ik niet goed, maar ik kom orange niet tegen als amx-ix deelnemer?

https://bgp.he.net/AS5511#_ix

Ik zag ze wel met Extended Peering op de NL-IX terug (maar dat staat weer niet op peeringdb), dan is het toch een kwestie dat Orange een nieuwe (of snellere) port moet bestellen?

Nog even de feedback van OVH:

You're trying to reach the IP 86.86.x.x which is part of KPN.

As you can see, the hop 10 has 0.0% of loss - then, once it reaches the 11 hop it keeps increasing the data loss.

Hop 11 is part of '193.251.128.0/19AS5511', as per Hop 12

route:          193.251.128.0/19
descr:          France Telecom / Orange SA
descr:          OPENTRANSIT
origin:         AS5511
mnt-by:         FT-BRX

It doesn't recognise Hop 13 but then it has a 2% loss on the last hop (14) which is part of KPN.

Het leuke is dat diezelfde loss waarover hier gesproken wordt, ook van toepassing is wanneer je vanaf de KPN infrastructuur test, hier dezelfde MTR test van KPN naar KPN 86.86.***.*

Dit ligt dus niet aan OVH noch aan Orange.

Wanneer ik diezelfde MTR vanaf mijn KS (Kimsufi) en Rise (OVHcloud) bakken naar mijn eigen IP Adres doe, dan is er geen sprake van enige loss. Beide servers overigens in Roubaix. Een Rise server van een kennis staat in Gravelines en het enige opvallende daar is de hogere latency maar ook hier is geen loss zichtbaar (kijkende naar Snt/Rcv) dus niet de Loss in percentages aangezien ICMP traffic een lage prioriteit heeft en dus onbetrouwbaar is.

Doe ik eenzelfde test naar een server van een familielid (Roubaix) dan verloopt de routering vanuit KPN over Aorta (Liberty Global) AS6830 waar het merendeel via AS5511 verloopt. Het lijkt erop dat er ergens in de routering iets niet lekker loopt maar in principe is de loss waarover gesproken wordt iets dat niet te wijten lijkt aan OVH noch aan Orange maar daadwerkelijk bij KPN zelf ligt. Ik herken het issue n.l. niet.

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
28 September 2023

Vanavond al gebeld door KPN a.g.v. mijn ingediende klacht. De dame in kwestie gaf ook gelijk aan dat het haar pet te boven ging. Ik heb gedurende het hele gesprek aangedrongen om dit issue bij technisch / commerciële mensen neergelegd moet worden. De gemiddelde techneut mag dit soort commerciële beslissingen toch niet nemen. Deze beslissingen, aan vraag van een peering-overeenkomst met OVH, moet door de hogere heren goedgekeurd worden. Zoveel is mij wel duidelijk.

Los van het feit dat het nog steeds vrijwel onmogelijk is om firmware te flashen op een nieuwe enigma2 ontvanger waardoor ik en geen nieuwe hardware kan verkopen maar ook kan ik geen service verlenen aan klanten om '’even” nieuwe firmware te plaatsen en plug-ins te installeren. De meeste fouten komen namelijk door foutief geconfigureerde software.

Zojuist ter test weer eens een ontvanger geprobeerd om te updaten. Op dat specifieke moment ging dat weer eens, bij wijze van uitzondering, op een redelijk normale snelheid. Het zal wel aan het tijdstip hebben gelegen. Morgen overdag maar weer eens testen. Of zou mijn klacht eindelijk effect hebben opgeleverd zodat er eindelijk beweging bij KPN is ontstaan. Ik ga nog niet juichen. Ik houd het op ‘wishful thinking'.

Reputatie 7

+12

Hoewel ik begrijp dat KPN niet heel internet kan beheren is het wel erg triest als het zoals hier geopperd wordt de oorzaak is dat er geen peering overeenkomst is met OVH.

Ook ben ik van mening dat KPN dit samen met OVH op zou moeten pakken.

Dan zou ik je klacht vooral neer leggen op http://zakelijkforum.kpn.com

KPN Monteur Regio Europoort - Koper, Glas, PSTN, Installatie, Storingen, Bis los van Has, (oud-)XS4ALL & KPN EEN MKB. -Geen medewerker van dit Forum - Reageert standaard niet op privé berichten-

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
28 September 2023

Hoewel ik begrijp dat KPN niet heel internet kan beheren is het wel erg triest als het zoals hier geopperd wordt de oorzaak is dat er geen peering overeenkomst is met OVH.

Ook ben ik van mening dat KPN dit samen met OVH op zou moeten pakken.

Dan zou ik je klacht vooral neer leggen op http://zakelijkforum.kpn.com

Natuurlijk kan ik dat laatste ook nog proberen maar ik heb al meerdere personen van kleinzakelijk gesproken wat tot heden weinig soelaas bood. Overigens kon ik al niet inloggen met mijn KPN ID. Het eerste begin liep al niet lekker. Maar, ik ga het straks ook daar nog melden met een link naar dit topic. Het enige wat ik hoop is dat het onderhand eens opgelost wordt.

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
28 September 2023

En het blijkt inderdaad ‘wishful thinking’ te zijn geweest. Het is weer compleet knudde.

Reputatie 7

+20

Bart van KPN
Oud Moderator
12863 reacties
7 maanden geleden
28 September 2023
Antwoord

De specialisten zijn er nog weer ingedoken. Zij vinden het vervelend dat jullie de problemen ervaren. Daarom laten we het verkeer via een andere weg lopen. Wij zijn nu heel benieuwd hoe het nu gaat met de verbinding.

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
28 September 2023

Ik ga ermee aan de slag en laat de resultaten weten. Goed of slecht. Ik zal meerdere keren een image flashen en doe dit vanuit het menu. Dan kom ik al snel erachter of het verbeterd is. De testen zijn mooi, maar gebruikerservaringen zullen in eerste instantie een beter beeld geven. Daarna eventueel gevolgd door nieuwe testen.

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
28 September 2023

@Bart_Z

Een eerste test met het online flashen van een nieuwe / andere image in zo'n box lijkt nu weer full speed te werken. Als dit nu geen toeval is maar een structurele oplossing dan ben ik heel happy. Ik flash straks nog een paar modellen om te kijken of het geen toevallige positieve momentopname is geweest. Dat laat ik jou dan uiteraard ook gelijk weten. Dat wordt dan na het avondeten. Voorlopig ben ik blij verrast met de eerste resultaten. 😀😀

Het lijkt erop dat het niet om al het verkeer gaat dat via een andere weg loopt, zo verloopt de routering naar 94.23.155.10 via Liberty Global's Aorta om vervolgens bij OVHcloud uit te komen, maar verloopt de routering naar 94.23.150.152 weer via OpenTransit. De routering lijkt hiermee niet plaats te vinden op basis van het ASN van OVH noch op basis van subnet (94.23.0.0/16) in mijn voorbeeld.

Wat wel merkbaar is - even kijkende en testende vanaf mijn 2e server - is dat de latency lager is geworden (~5ms) ondanks dat het path één extra hop erbij gekregen heeft.

Misschien is het een idee de specialisten te vragen of ze het gehele ASN van OVH over Aorta te laten verlopen ?

Reputatie 1

Frenzelke
Auteur
Helper
40 reacties
7 maanden geleden
28 September 2023

@Bart_Z

Inmiddels heb ik een aantal ontvangers voorzien van nieuwe firmware via de online flash methode. Hierbij wordt er eerst vanaf de betreffende server een image gedownload, vervolgens start deze nog niet geconfigureerde image op en worden eerst alle packages ge-update en vervolgens worden de eerder geïnstalleerde plug-ins weer gedownload en geïnstalleerd. Dit ging een aantal keren als de brandweer. Ik hoop dan ook dat wat KPN ook gewijzigd mag hebben dat zij dit niet opnieuw wijzigen naar de oude situatie.
Het huidige resultaat is bemoedigend te noemen. Waar ik eerder nog nauwelijks iets kon (her)installeren of duurde dat minimaal een uur of meer a.g.v de geconstateerde ellende is dat nu, afhankelijk van het aantal geplaatste plug-ins en grootte van de image, nog geen 5 minuten of minder.

Hierbij bedank ik @Bart_Z voor zijn inzet in tegenstelling tot de gesproken medewerkers van de klantenservice. Bart, chappeau!!!!

Reputatie 7

+20

Bart van KPN
Oud Moderator
12863 reacties
7 maanden geleden
29 September 2023

Kijk dat klinkt goed. Fijn dat de wijziging voor verbetering heeft gezorgd. Zal ik doorgeven.

Alleen jammer dat niet iedereen hier iets van merkt, het ene IP adres verloopt n.l. nog wel via Opentransit waar de andere via Aorta.net verloopt. Of te wel, de uitkomst is wisselend @Bart_Z

Voorbeeldjes

root@n100:~# mtr -o 'J M X LSR NA V' -twz4n xxxxxxxxxxxxxxxx
Start: 2023-09-29T12:20:26+0200
HOST: n100                     Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg  StDev
  1. AS???    192.168.1.1       0.0   0.0   0.1   0.0%    10    10    0.6   0.5    0.0
  2. AS???    195.190.228.xx    0.4   0.3   1.0   0.0%    10    10    2.6   2.3    0.4
  3. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  4. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  5. AS???    193.251.129.120   2.8   2.1   6.7   0.0%    10    10    9.2  10.4    2.1
  6. AS16276  37.187.232.46     0.4  27.3  97.1   0.0%    10    10   18.0  47.7   44.0
  7. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  8. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  9. AS16276  54.36.50.242      0.0   0.2   0.3  10.0%    10     9   17.5  17.5    0.2
 10. AS16276  54.36.50.243      0.1   7.7  37.9   0.0%    10    10   15.6  21.0   12.3
 11. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 12. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 13. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 14. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 15. AS16276  94.23.150.1xx     0.1   0.1   0.4   0.0%    10    10   15.8  15.7    0.1

root@n100:~# mtr -o 'J M X LSR NA V' -twz4n xxxxxxxxxxx
Start: 2023-09-29T12:26:15+0200
HOST: n100                     Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg  StDev
  1. AS???    192.168.1.1       0.1   0.0   0.1   0.0%    10    10    0.6   0.5    0.1
  2. AS???    195.190.228.xx    2.6   1.1   7.2   0.0%    10    10    5.0   3.3    2.3
  3. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  4. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  5. AS???    193.251.129.120   7.2   2.6   7.2   0.0%    10    10   18.0  14.0    2.8
  6. AS16276  37.187.232.46     0.1  26.6  130.   0.0%    10    10   17.2  48.1   44.7
  7. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  8. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  9. AS16276  54.36.50.242      0.3   0.2   0.5   0.0%    10    10   17.4  17.5    0.2
 10. AS16276  54.36.50.243      0.2   0.1   0.2   0.0%    10    10   16.0  15.8    0.1
 11. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 12. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 13. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 14. AS16276  94.23.145.1xx     0.1   0.1   0.4   0.0%    10    10   15.7  15.7    0.1

Zoals te zien, het ASN is AS16276 en dus OVH/OVHcloud waar ook deze IP adressen zich bevinden bij dezelfde partij als waar die van de TS zich bevinden. Op de één of andere manier lijkt de oplossing die KPN geïmplementeerd heeft dus niet op alle IP Adressen te zijn toegepast.

Het probleem van @Frenzelke lijkt hiermee ook maar deels opgelost, why?

root@n100:~# dig A downloads.openpli.org

; <<>> DiG 9.16.44-Debian <<>> A downloads.openpli.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57453
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;downloads.openpli.org.         IN      A

;; ANSWER SECTION:
downloads.openpli.org.  120     IN      A       51.178.16.136
downloads.openpli.org.  120     IN      A       51.195.116.98

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 29 12:33:56 CEST 2023
;; MSG SIZE  rcvd: 82

De routering verloopt via de oude weg als een MTR wordt uitgevoerd naar 51.178.16.136 zoals de 4e hop laat zien (n.l. OpenTransit).

Start: 2023-09-29T12:35:36+0200
HOST: n100                     Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg  StDev
  1. AS???    192.168.1.1       0.0   0.0   0.2   0.0%    10    10    0.6   0.6    0.1
  2. AS???    195.190.228.xx    2.2   1.2   5.3   0.0%    10    10    2.4   3.4    1.7
  3. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  4. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  5. AS???    193.251.132.225   0.2   0.2   0.6   0.0%    10    10    7.9   8.1    0.2
  6. AS16276  91.121.131.254    0.8   1.0   3.8   0.0%    10    10   13.2  14.8    1.6
  7. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  8. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  9. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 10. AS16276  91.121.131.27     0.0   2.8  26.3   0.0%    10    10   13.4  15.8    8.4
 11. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 12. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 13. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 14. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 15. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 16. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 17. AS???    ???               0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 18. AS16276  51.178.16.136     0.1   0.1   0.3   0.0%    10    10   12.9  12.9    0.1

Wordt het andere IP adres getest 51.195.116.98, dan verloopt deze inderdaad via het nieuwe path (Aorta / Liberty Global), dit zien we bij de 6e hop:

root@n100:~# mtr -o 'J M X LSR NA V' -twz4n 51.195.116.98
Start: 2023-09-29T12:37:49+0200
HOST: n100                    Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg  StDev
  1. AS???    192.168.1.1      0.0   0.0   0.1   0.0%    10    10    0.5   0.5    0.1
  2. AS???    195.190.228.xx   0.2   0.1   0.2   0.0%    10    10    2.3   2.2    0.1
  3. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  4. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  5. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  6. AS6830   84.116.136.61    0.0   1.8   6.5   0.0%    10    10    5.2   6.1    2.1
  7. AS16276  91.121.131.85    1.8   0.5   1.8   0.0%    10    10    6.1   7.9    0.7
  8. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
  9. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 10. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 11. AS16276  54.36.50.81      0.6   0.3   0.6  80.0%    10     2   21.9  22.2    0.5
 12. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 13. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 14. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 15. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 16. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 17. AS???    ???              0.0   0.0   0.0  100.0    10     0    0.0   0.0    0.0
 18. AS16276  51.195.116.98    0.1   0.1   0.2   0.0%    10    10   20.9  20.9    0.1

Ik vraag me dat ook af, als je een MTR draait met “-c 50”, dan zie je duidelijk dat zowel OpenTransit als LiberyGlobal gebruikt worden om OVH te bereiken.

De eerste 7 hops gemeten vanuit het KPN netwerk zijn nog steeds dezelfde 7, en aangezien de data dan al lang het KPN netwerk verlaten heeft vraag ik me ernstig af wie wat waar aan “routing” heeft aangepast.

Start: 2023-09-29T12:50:43+0200
HOST: raspberrypi                                            Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg   Best   Wrst  StDev
  1. AS???    fritz.box (192.168.188.1)                       0.3   0.2   0.7   0.0%    50    50    2.3   1.7    1.3    2.3    0.2
  2. AS???    195-190-228-52.fixed.kpn.net (195.190.228.52)   0.2   1.8   7.6   0.0%    50    50    4.2   5.3    3.5   11.2    1.8
  3. AS???    ???                                             0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0
  4. AS???    ???                                             0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0
  5. AS???    193.251.132.225                                 0.1  232.  1007  48.0%    50    26    9.0 124.2    6.2  1013.  327.1
     AS6830   nl-ams02a-rc2-lag-22-0.aorta.net (84.116.136.146)
  6. AS16276  bru-bru1-pb2-8k.be.eu (91.121.131.254)         10.5   5.2  12.1   0.0%    50    50   16.7  11.0    5.2   17.3    4.9
     AS6830   nl-ams09c-ri1-ae-6-0.aorta.net (84.116.136.61)
  7. AS16276  be106.ams-gsa1-pb1-8k.nl.eu (91.121.131.85)     1.5   1.2   7.5  48.0%    50    26    9.8   9.5    8.1   16.8    1.6

p.s. wellicht kan KPN ook een web developer inzetten zodat dit forum meer dan een kwart van mijn scherm breedte gebruikt, en bovenstaande code blocks wat beter leesbaar zijn?

Of de overflow aan past en het block scrollable maakt? Want dit is beroerd leesbaar...

Bladzijde 2 / 3

Reageer

De Kennisbank

Meld je aan

Welkom

Bestand scannen voor virussen

Dit bestand kan niet worden gedownload