Ik ervaar routeringsproblemen vanwege mijn IP adres

New MTR:

New MTR:

 

Ja, maar laat nu eens de volledige MTR zien. Zoals ik al zei, tussenhops mogen gewoon packetloss laten zien. Ook 100%.

Heeft je eindpunt ook packetloss?? Dan heb je een probleem. Anders niet.

Leg in dat geval dan eerst het probleem eens uit… zonder gebruik te maken van die traceroute en packetloss op tussenhops.

Dat is de volledige MTR.

Naar welk doel is dat?

En dit is toch niet vanaf een KPN lijn? Of wel?

Dit kan helpen om het probleem verder toe te lichten voor de technische dienst van KPN en de forumleden die geïnteresseerd zijn in de situatie.

Van de technici van de AMS-provider:

We hebben de door u verstrekte informatie bekeken en willen graag wat meer duidelijkheid verschaffen over de punten die u vóór uw geplande gesprek hebt aangekaart.

Wat betreft de PTR- en Chello-theorie, raden we ten zeerste af om dit als de belangrijkste oorzaak aan te halen. Bij controle bleek uit een reverse lookup van uw vorige 77.170.x.x IP-adres dat vanuit meerdere invalshoeken een positief resultaat opleverde. De hostnaam die u bij hop 11 zag, behoort tot een transitrouter van Liberty Global waar uw verkeer doorheen loopt. Dit is volkomen normaal in Nederland, aangezien KPN en Liberty Global regelmatig peering en verkeer uitwisselen. Dit duidt niet op een verkeerd geconfigureerde PTR of een routingloop, en het aankaarten ervan tijdens het gesprek kan de aandacht afleiden van het eigenlijke probleem.

Wat betreft de CGNAT-wijziging: het verplaatsen van uw verbinding van uw oorspronkelijke openbare IP-adres in het bereik 77.170.x.x naar het CGNAT-bereik 100.107.0.0/16 was niet de juiste oplossing en heeft de situatie waarschijnlijk verergerd. Met CGNAT bent u de inkomende verbindingen volledig kwijt, wat betekent dat port forwarding en inkomende verbindingen niet langer betrouwbaar zijn. Belangrijker nog, CGNAT lost geen peering- of routingproblemen met hostingproviders in Amsterdam op, aangezien het upstream-pad hetzelfde blijft. Het feit dat u nog steeds last heeft van doorvoerverlies en pakketverlies op het nieuwe IP-adres bevestigt dat het onderliggende probleem niet is opgelost. We raden u aan de engineer te vragen uw verbinding terug te zetten naar een standaard openbaar IPv4-adres uit een KPN-pool zonder CGNAT.

Het kernprobleem dat u aan de engineer moet voorleggen, moet worden geformuleerd rond de volgende belangrijke punten:

De end-to-end doorvoer is aanzienlijk gedaald van ongeveer 70 MB/s naar minder dan 10 MB/s bij SSH-overdrachten naar hostingproviders in Amsterdam, en dit is reproduceerbaar en meetbaar.
Er is sprake van aanhoudend pakketverlies naar specifieke bestemmingen in Amsterdam, zelfs na de IP-wijziging.
Het patroon wijst naar het pad via be6083.ccr21.ams04.atlas, de Core Router 21 van KPN op het AMS04-punt.
De mogelijke oorzaken die u met de engineer moet bespreken, zijn onder andere congestie of instabiliteit bij de AMS-IX-peering of private interconnect, een mogelijke storing op de ccr21.ams04-router, of een probleem met de MTU- en pad-MTU-detectie op de XGS-PON-lijn. Dit laatste komt vaak voor bij nieuwere glasvezelnetwerken en zou verklaren waarom pings lijken te werken terwijl de doorvoer instort.

Daarom vroeg ik naar het doel van die MTR. Je moet tussenhops niet beoordelen. Als je een MTR doet naar een echte correcte server die ook op ICMP moet reageren (game servers reageren daar ook nooit op) dan kun je pas zien of je verbinding een probleem heeft.

Ik blijf het ook raar vinden dat hier jouw oude IP een unifi systeem geeft. Die zou voor het laatst door censys platform gedetecteerd zijn op 20 mei en is nu nog gewoon bereikbaar. Dus dan vraag ik me sterk af waar dat CGNAT adres vandaan komt. Want dan zou je dus 2 IP adressen hebben (1 CGNAT en die oude 77.170.x.x).

Heb jij een unifi router? Zo niet, dan moet dit wel een ander systeem zijn.

Zoals aangegeven… als je je oorsponkelijke probleem op wilt lossen, was CGNAT dus niet de oplossing. Maar als je nu nog steed snelheidsproblemen hebt… geef dan eens aan naar welke IP.

Ja, UDM Pro Max.

Interessant genoeg geeft een ping via SSH vanaf AMS de volgende resultaten:

Uiteraard. Waarom zou jij een CGNAT adres willen pingen. Dat is een shared IP server die niet reageert op een ICMP. Dat is ook helemaal nergens voor nodig. Je moet CGNAT als een soort VPN eindpunt zien waar vele mensen gebruik van maken.

Interessante dag... de KPN-technicus heeft mijn IP-adres geforceerd vernieuwd en ik kreeg het CGNAT-adres. Nu lijkt het erop dat ik weer terug ben bij het 77.170.x.x-adres. Ik heb nog steeds last van pakketverlies en mijn doorvoer is ingestort.

Ik heb teruggebeld en werd beschuldigd van liegen. De nieuwe medewerker vertelde me dat ze nooit IP-adressen vernieuwen en dat ik verkeerd geïnformeerd moest zijn. Maar het staat vast vast dat mijn router het nieuwe IP-adres heeft doorgegeven. Dat is te zien in de screenshots.

Ik weet echt niet wat er aan de hand is, maar ik verlies alle vertrouwen in KPN. Ik had een werkende verbinding, maar wat ik dacht dat een upgrade naar 4 Gbps was, is een nachtmerrie geworden.

Ik smeek om een ​​ECHTE KPN-netwerktechnicus die de informatie van mijn Amsterdamse pro-ider wil bekijken en een oplossing wil vinden.

Hey ​@swanksteak, welkom hier! Ik had je topic al gespot en heb dit ondertussen voorgelegd aan onze peering office. Daar heb ik nu reactie van ontvangen. Zij geven aan dat er aan onze kant niets aan de hand is. 

Jouw stelling dat die IP-rang ooit aan Ziggo heeft toebehoord is niet het geval. Ook is reverse DNS niet relevant voor routering. Dit gaat puur op het IP-nummer. 

Het is dan wel zo dat die reverse DNS die naar Chello verwijst een fout is. Dat is al jaren zo. Hebben we ook gemeld, maar het is nog nooit aangepast. Het levert verder ook geen technische nadelen op voor onze routering. Dus het is ook niet iets waar we prio op zetten.

Wat rvk ook al even benoemde. Packet loss op een hop van een route is over het algemeen geen echte packet loss. Het is meestal alleen een signaal dat die router in het netwerk met lage prioriteit op pingverzoeken reageert. Wil zeggen dat ze de pakketjes wel doorzetten naar de volgende hop, maar niet op alle pakketjes ook terugrapporteren naar jouw computer dat dit gedaan is. 

Als het echte packet loss zou zijn, zou jouw trace bij een hop met 100% packet loss ook gelijk moeten stoppen. Maar in plaats daarvan gaat de trace gewoon door. En zie je ook dat het aantal verzonden pakketjes (de kolom Snt) niet terugloopt. En dat er dus niet daadwerkelijk pakketjes verloren gaan.

Maar ik begrijp uit je berichten dat jij tragere doorvoer ervaart naar een eindpunt. En daar kunnen we zeker met je naar kijken. Maar dan moet we duidelijk wat nu precies het probleem is. Wat probeer je te bereiken, met welk doel? Wat ervaar je in je gebruik van die site, server, dienst, spel, etc.

​@Erik van KPN Hallo Erik. Ik weet niet wat ik moet zeggen. Mijn provider in Amsterdam, waarmee ik via SSH verbinding maak, zegt dat dit binnen het KPN-netwerk valt. Ik had een doorvoer van ongeveer 80 MBps via de tunnel, maar toen ik overstapte naar 4 Mbps Glaswezel stortte de doorvoer in.

Hier is hun meest recente informatie:

______
Bevindingen van je MTR- en pingtests

TCP MTR — sterk bewijs dat het probleem in het KPN-netwerk zit

Omdat dit TCP-probes gebruikt, en geen ICMP, is het verlies dat het laat zien reëel — geen rate-limiting.

Hops 1–2 (jouw kant): schoon, 0% verlies
Hops 3–4 (intern KPN, 10.252.216.x): enorme jitter — StDev 257 ms en 741 ms, worst-case latenties van 3 en 7 seconden. Klassieke bufferbloat / congestie.

Hop 5 (be6083.ccr21.ams04.atlas.cogentco.com): 97,5% verlies bij de KPN ↔ Cogent interconnect.

Het probleem begint binnen de KPN-aggregatie vóór de Cogent-overdracht. Het ligt absoluut niet aan uw apparatuur.

Let op: u hebt dit uitgevoerd naar uw eigen CGNAT IP-adres. Voer het opnieuw uit naar een daadwerkelijk Amsterdams doel dat u gebruikt, zodat de technicus het werkelijke pad kan zien.

Voor de technicus:

Twee specifieke zaken die u hem/haar moet vragen te controleren:

Gebruik en wachtrijen op het aggregatiesegment 10.252.216.128/29 — jitter-signalen wijzen op congestie op dit punt.

De status van de KPN ↔ Cogent peering op ccr21.ams04, en of Amsterdams verkeer via Cogent transit wordt geleid in plaats van via AMS-IX.

Om dit probleem op te lossen, moet u rechtstreeks contact opnemen met uw internetprovider en een omleiding van het verkeer aanvragen. Geef ze gewoon je IP-adres, dat je in je controlepaneel kunt vinden, en vraag ze om de routering aan hun kant toe te passen. Dit zou het probleem moeten oplossen.

______

Behalve de test die ik al heb gedaan, weet ik niet wat ik je nog kan vertellen. Volgens mijn provider is het een routeringsprobleem. Volgens jou niet. Het kan ook een soort MTU-paddetectie op de lijn zijn.

Wat het ook is, mijn doorvoer via een SSH-tunnel is ingestort en niets werkt meer. Ik heb vandaag gebeld en iemand heeft mijn IP-adres vernieuwd. Ik kreeg een CGNAT-adres. Dat heeft het probleem uiteraard niet opgelost. En nu heb ik weer hetzelfde oude IP-adres en blijft het probleem bestaan.

Geen enkele herstart, stroomonderbreking, reset, stekker eruit, erin, discussie, overleg of geschreeuw heeft geholpen.

Zou je bereid zijn om met me samen te werken, gezien de bovenstaande informatie, om dit op te lossen? Zo niet, dan heb ik geen andere oplossing dan van provider te wisselen. Ik ben al 8 jaar klant bij KPN, dus ik hoop dat het niet zover komt.

Alstublieft, help me.

Zou terugkeren naar de standaard 1 Gbps-optie een haalbare optie zijn? Want de huidige verstoring is het gewoon niet waard.

Er worden hier zoveel aannames gedaan… dat je door de bomen het bos niet meer ziet. Zeker moet je in eerste instantie echt stoppen met het kijken naar die tussenhops. Ik geloof echt wel dat je een probleem hebt maar er worden dingen gezegd (of aangenomen) waardoor je alleen maar in de war raakt.

Ten eerste dit…. heeft KPN je echt in een CGNAT gezet? Kan ​@Erik van KPN dat bekijken? Want ik dacht dat dat nooit op een vaste aansluiting gebeurd. Alleen op mobiel.

​@swanksteak kun je eens naar https://myip.nl gaan en kijken wat je echte externe IP is. Dus niet kijken in je router maar op die pagina. Dan kunnen we verder kijken (want je hoort niet in CGNAT te zitten).

Ik begrijp dat je er zelf wanhopig van wordt en dat is niet jouw schuld, maar ik denk dat er even vanuit 0 begonnen en naar gekeken moet worden.

Ik heb bevestigd dat mijn IP-adres is teruggezet naar het oude adres (77.170.x.x). Ik heb ook gecontroleerd of de wijziging wel degelijk heeft plaatsgevonden toen KPN aangaf dat het adres was vernieuwd; het was inderdaad een CGNAT-adres. Misschien was dat onbedoeld en is dat de reden waarom het adres is teruggezet.

Hoe dan ook, met het IP-adres 77.170.x.x verlies ik nog steeds pakketten en is mijn doorvoersnelheid sterk gedaald.

Ok. Dan kan daar nu beter naar gekeken worden. Hoe weet je dat je pakketten verliest (en niet dat alleen de doorvoersnelheid lager ligt)?

Om wat voor programma gaat het? Is het een SSH tunnel die dan traag is (omdat je SSH noemde). Is de SSH server een publieke server waarvan je de IP kunt noemen (of dat KPN daar naar kan kijken)?

Ervaar je ook doorvoersnelheid problemen naar andere server. Dus heb je na de upgrade algemene problemen om de 4Gbps te halen of is dat geen probleem?

PS. Ik zie dat het gaat om een UDM Pro Max. Hangt die direct aan de glasvezel? Het probleem met de UDM Pro Max en een 4Gbps lijn is ook dat ik dacht dat de Pro een probleem heeft die snelheid te halen i.c.m. de PPPOE van de internet lijn. Dat zou ook een behoorlijke bottleneck kunnen zijn.

(Ik dacht dat die Pro bij PPPOE geen hardware offloading kan doen)

Een privé SSH-tunnel die eerst 70-80 MBps haalde, geeft nu nog maar 10-15 MBps. Dat gebeurde na de upgrade naar 4 Mbps. Ik heb nooit de volledige snelheid gehaald. Ik krijg maximaal 2,6 Mbps download en upload.

Ik gebruik MTR vanaf de AMS-server via SSH. Het technische team aan de serverzijde heeft aangegeven dat de MTR laat zien dat het probleem bij het KPN-netwerk ligt. Dit was het geval vóór en tijdens de IP-vernieuwing. En nu is hetzelfde met het oude IP-adres.

Heel vreemd.

Voordat je het vraagt: de snelheid wordt getest op de router via een bekabelde verbinding met de ONT.

Zoals ik in mijn laatste post al aangaf… de UDM Pro Max heeft problemen met de PPPOE bij 4Gbps lijnen. Er zijn hier wel wat topics te vinden daarover.

Het makkelijkste om dat even uit te sluiten is de Box 14 even terug aan te sluiten en te testen.

Maar het is dus bekend dat de snelheid tot ver onder de 1000Mbps kan vallen wanneer er geen 4Gbps hardware offloading (door de PPPOE) gedaan kan worden door de UDM Pro Max.

​@Erik van KPN U zegt dat dit geen KPN-probleem is. Waarom was de doorvoer dan wel goed vóór de upgrade? Het gebeurde tegelijkertijd. Er is niets veranderd aan de server waarmee ik verbinding maak, noch aan mijn configuratie.

Is het niet mogelijk om mijn IP-adres te vernieuwen, zodat ik de route kan testen?

​@rvk01 De upgrade zou acceptabel zijn (nog steeds het dubbele van mijn oude 1 Gbps-verbinding) ALS mijn doorvoer niet zo sterk was gedaald. De algehele snelheid van een upgrade van 1 Gbps naar 4 Gbps zou mijn doorvoer niet mogen verminderen en geen pakketverlies van 60-100% mogen veroorzaken.

Heb je mijn laatste twee posts gelezen? De UDM Pro Max kan geen 4Gbps aan en valt ver terug onder 1000Mbps als hij daarmee te maken krijgt door het niet aan kunnen van de PPPOE en niet niet kunnen doen van hardware offloading. Zie de andere topics daarover. Als je weer terug gaat naar 1Gbps dan heeft de UDM schijnbaar voldoende kracht om wel die 1Gbps aan te kunnen.

(Je kunt het dus ook met de Box 14 uittesten)

Ik heb je berichten gelezen, maar mijn huidige snelheid is 2,6 Gbps. Dat is meer dan ik voorheen had en ik geloof niet dat dat mijn doorvoer via een SSH-tunnel zou laten dalen van 70-80 naar minder dan 10.

Wel als je hele UDM Pro Max hierdoor overbelast raakt.
De packetloss wordt dan dus niet door de lijn veroorzaakt maar door het overbelasten van de UDM Pro Max.

Maar goed… ik kan hier verder ook weinig aan doen.

Ik heb de MjnKPN-app geopend en mijn abonnement weer teruggezet naar 1 Gbps. Ik heb een e-mail ontvangen ter bevestiging van de wijziging en mijn router registreert nu snelheden van 1 Gbps zowel upload als download.

Ik heb nog steeds hetzelfde IP-adres en de verbinding via SSH is volledig verbroken.

​@Erik van KPN Wat kan ik nu proberen? Kunt u mijn IP-adres in ieder geval als test vernieuwen?