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.
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.
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.
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.
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.
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.
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.
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.
Misschien zoek ik niet goed, maar ik kom orange niet tegen als amx-ix deelnemer?
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.
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'.
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
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
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.
En het blijkt inderdaad ‘wishful thinking’ te zijn geweest. Het is weer compleet knudde.
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.
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.
@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.
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.
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 ?
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.
@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!!!!
Kijk dat klinkt goed. Fijn dat de wijziging voor verbetering heeft gezorgd. Zal ik doorgeven.
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
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?
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.
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...
Reageer
De Kennisbank
Heb je vragen over diensten, producten of wil je weten hoe je modeminstellingen verandert? Vind het antwoord op de meest gestelde vragen in onze Kennisbank
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Bestand scannen voor virussen
Sorry, we zijn de inhoud van dit bestand nog aan het controleren om er zeker van te zijn dat het veilig is om te downloaden. Probeer het nog een keer over een paar minuten.
