Ik ervaar routeringsproblemen vanwege mijn IP adres

MTR:

Is er een KPN-technicus of -specialist die mij hierbij kan helpen?

Het is even wachten tot een moderator hier op zal reageren. Die kan dan de nodige lijntjes met de netwerktechnische afdeling leggen. 

Dankjewel, ​@AriënC!

Zou een moderator dit alstublieft willen doorverwijzen naar de technische afdeling van KPN, zodat zij 1) mijn DHCP-lease aan de BNG-kant bij de lokale centrale kunnen verlengen; of 2) de oude Chello/UPC PTR-records in de KPN DNS-zones handmatig kunnen verwijderen?

Mijn IP-adres is 77.170.xxx.xxx.

Het IP-blok 77.170.x.x was voorheen toegewezen aan VodafoneZiggo. De centrale Reverse DNS/PTR-records in de RIPE-database zijn nooit opgeschoond. De hostnaam van hop 11 (zie mijn eerdere bericht) wordt opgelost naar d192194.upc-d.chello.nl (Chello/Ziggo-backbone). Dit resulteert in een routing-loop en enorm pakketverlies.

Mijn verbinding werkt niet goed en het pakketverlies zorgt voor extreem lage snelheden. Ik heb tevergeefs geprobeerd een nieuw IP-adres te verkrijgen. Dit moet aan de KPN-kant worden opgelost.

Kan iemand dit alstublieft doorgeven aan een netwerkbeheerder of technicus van KPN, zodat zij de oude Chello/UPC PTR-records kunnen opschonen of een schoon IP-adres uit een native KPN-adrespool voor mijn verbinding kunnen afdwingen?

Alvast bedankt voor de hulp.

Hartelijk dank!

Laatste MTR:

Het is onacceptabel dat mij wordt verteld dat ik hierover niet eens een serviceaanvraag kan indienen.

Bij gebrek aan een spoedige oplossing zal ik deze kwestie escaleren door een formele klacht in te dienen bij de ACM inzake de ernstige en langdurige dienstverstoring op mijn glasvezelabonnement.

Beste KPN Community team,

Ik wil even benadrukken dat het IP-blok 77.170.0.0/16 (waaronder mijn huidige IP-adres valt) volledig eigendom is van KPN B.V. en geregistreerd staat op ASN AS1136 (KPN) in de RIPE-database.

KPN routeert dit blok inmiddels native via de nieuwe XGS-PON glasvezelinfrastructuur. Het probleem is echter dat dit blok vroeger toebehoorde aan VodafoneZiggo (UPC/Chello) en de oude reverse DNS/PTR-records (die verwijzen naar *.upc-d.chello.nl) nooit zijn opgeschoond. Dit veroorzaakt serieuze routingproblemen bij upstream providers.

Kunnen jullie dit alstublieft escaleren naar het netwerkteam zodat de oude PTR-records worden verwijderd of ik een nieuw IP-adres uit een schoon KPN-blok krijg?

Alvast bedankt!

Ik heb zojuist het telefoongesprek met de klantenservice van KPN beëindigd. Hij weigerde een supportticket aan te maken voor dit probleem en probeerde in plaats daarvan een betaald servicebezoek in te plannen.

Het probleem ligt niet bij de hardware of mijn thuisinstallatie. Ik heb al uitgebreid getest met herstarts van de ONT en mijn UDM Pro Max. MTR en traceroute laten duidelijk zien dat het probleem begint bij hop 11 met oude Chello/UPC reverse DNS-records (PTR) op het KPN-IP-blok 77.170.0.0/16 (AS1136).

Upstream-providers routeren het verkeer verkeerd vanwege deze verouderde configuratie.

Ik heb het gesprek opgenomen en zal een schriftelijke klacht indienen bij KPN, de geschillencommissie en de ACM als het probleem niet snel wordt opgelost.

De klantenservicemedewerker heeft mij laten weten dat dit forum wordt beheerd door KPN-netwerkpersoneel. Ik verzoek om dit onmiddellijk door te geven aan het Network Engineering/Core/BNG-team. Kunt u mij hierbij helpen?

Kun je aangeven welk IP die verkeerde reversed PTR heeft naar d192194.upc-d.chello.nl?
(misschien even met een traceroute -I -n op een Linux machine om de IP’s te zien)

Want d192194.upc-d.chello.nl resolved wel forward naar 213.46.192.194 (welke uiteraard van Ziggo is).

Vanuit welke internet provider gebeurd dit? Want met beide Ziggo en Middenbrabant-glas kom ik niet op die route uit.

(Kan even duren voordat een moderator dit topic opmerkt)

Ik heb al een trace-route uitgevoerd. Zie de MTR-berichten hierboven. Zie hop 10-11.

Ja, maar daar zie ik dus niet wat de IP is voor d192194.upc-d.chello.nl.

Als ik een forward nslookup doe op d192194.upc-d.chello.nl dan kom ik op 213.46.192.194 uit.
Dat is toch gewoon een adres bij Ziggo?

Je geeft aan dat de reverse DNS / PTR-records in de RIPE-database nooit opgeschoond zijn. Kun je wijzen naar die records?

Dank voor je reactie en het meelezen.

Je ziet bij de forward lookup inderdaad 213.46.192.194 (oud Ziggo-adres) — dat klopt helemaal.

Het echte probleem zit in de reverse lookup (PTR-record):

Op mijn huidige KPN-IP (77.170.x.x) retourneert een reverse DNS query nog steeds d192194.upc-d.chello.nl.

Het gaat om reverse DNS (PTR-records), niet om forward DNS.

Als ik een reverse lookup doe op mijn huidige IP-adres (77.170.x.x), dan krijg ik nog steeds d192194.upc-d.chello.nl terug.
Forward lookup van d192194.upc-d.chello.nl geeft inderdaad 213.46.192.194 (oud Ziggo-adres), dat klopt.

Dit is precies het probleem:
Mijn IP-adres ligt nu in een KPN-blok (77.170.0.0/16 – AS1136 KPN) en wordt gerouteerd via KPN’s XGS-PON netwerk, maar de PTR-record is nooit opgeschoond en verwijst nog naar een oud UPC/Chello-hostnaam. Daardoor raken upstream providers in de war en sturen ze verkeer deels naar het oude Ziggo-netwerk, met routing-loops en extreem pakketverlies (60-100%) als gevolg.

Als ik een reverse lookup doe op jouw ip dan kom ik gewoon op 77-170-x-x.fixed.kpn.net uit. (Op Ziggo, KPN en middenbrabant-glas lijnen en ook bij mxtoolbox).

Dank voor het checken.
Interessant verschil inderdaad.
Als jij een reverse lookup doet, zie je 77-170-x-x.fixed.kpn.net (de "nieuwe" KPN-naam).
Bij mij retourneert een reverse lookup op hetzelfde IP nog steeds d192194.upc-d.chello.nl. Dit zie ik ook duidelijk in mijn MTR-traceroutes bij hop 11 (de hostname van die hop lost op naar de oude Chello/UPC-naam).
Dit wijst precies op het probleem: er bestaan inconsistente / verouderde PTR-records voor dit IP-blok. Sommige resolvers/DNS-servers hebben de oude Chello-records gecached of krijgen die nog steeds terug, terwijl andere al de nieuwe KPN-records zien. Dat is typisch bij migraties van IP-blokken?
Voor upstream providers (GTT, Liberty Global etc.) zorgt dit voor verwarring, waardoor ze verkeer soms nog naar het oude Ziggo-netwerk sturen → routing-loops en pakketverlies.
To Moderators/netwerkteam: Dit bevestigt dat de oude PTR-records niet volledig zijn opgeschoond.
Alvast bedankt!

In jouw laatste plaatje krijg je met mtr toch wel de juiste reverse ptr voor jouw eigen ip? (Hop 14, de laatste staat gewoon het juiste reverse ptr)

Dat ie over een Ziggo hop routert wil niet zeggen dat de reverse ptr verkeerd is.

Vanaf welk netwerk doe je deze mtr?

Het is dus niet de 77.170.x.x die een verkeerde reverse ip heeft maar dat de route over een Ziggo hop gaat.

Beste KPN-team/moderators,

Bedankt voor het vernieuwen van de verbinding. Ik heb nu een nieuw IP-adres: 100.107.x.x.

Helaas is het probleem nog niet opgelost. Bijgevoegd vindt u een nieuwe MTR.

Er is nog steeds sprake van extreem pakketverlies (tot 100%) vanaf hop 5/6 binnen het KPN-netwerk (10.252.216.x → be6083.ccr21.ams04.atlas...). Dit is duidelijk geen probleem aan de klantzijde.

Kunt u dit alstublieft doorgeven aan het Network Engineering/Core-team?

Alvast bedankt!

Het is niet handig om je ip-adres hier te delen. 🙂

Dankjewel, ik had haast ;)

Dat is toch niet je complete MTR???

Dat een tussenhop 100% packetloss heeft is heel normaal. Een tussenhop reageert vaak niet op ICMP. Of ze hebben rate limiting waardoor er packetjes gedropt worden. Dat wil niet betekenen dat jouw echte pakketjes niet op het eindpunt terecht komen. Het is alleen de direct ICMP naar die tussenhop die gedropt wordt.

Lees punt #2 op deze pagina eens:
https://www.cloudflare.com/learning/network-layer/what-is-mtr/#mtr-2-packet-loss-or-is-there

Overigens is het door jouw genoemde IP adres niet van KPN volgens mij (het lijkt mij meer een VPN of CGNAT adres). Dus dit is niet jouw nieuwe IP op het KPN netwerk. Volgens mij is dat nog steeds dat andere IP. Die reageert overigens nog steeds op mijn pings.

Ja, het is een volledige MTR. Ik weet dat een paar tussenhop met 100% verlies vaak onschuldig is. Maar hier begint het verlies bij hop 3 en 4 op interne KPN-adressen (10.252.216.x), en daarna is het 99-100% vanaf hop 5/6 (be6083.ccr21.ams04.atlas...). Dit is geen normaal tariefbeperkend meer - het is echt end-to-end pakketverlies voor Amsterdamse hostingproviders.
Bovendien is de doorvoer via SSH teruggebracht van ~70MBps naar minder dan 10MBps.

Via het IP-adres (100.107.242.153):
Dit is mijn nieuwe IP na het vernieuwen. Het ligt in het 100.107.0.0/16 bereik, wat een KPN CGNAT-pool is (RFC 6598). Reverse DNS is nu een schone KPN-naam (*.fixed.kpn.net). Het oude 77.170-IP is vervangen.
Het probleem is het verschoven van “oude PTR-records” naar een ander probleem binnen het KPN-netwerk (misschien routing/peering van CGNAT-gerelateerd?).
Ik spreek zo direct de ingenieur en zal dit doorgeven.

Het gaat erom of je laatste eindpunt packetloss heeft. Als dat gewoon 0% is, dan heeft het geen zin om naar de tussenhops te kijken. Zelfde als de latency. Je beoordeelt de tussenhops dan alleen als de latency op het laatste punt een probleem heeft.

Die begrijp ik even niet. 100.107.242.153 heeft geen reversed PTR omdat het een CGNAT pool betreft. Dus die kan nooit direct naar jouw computer verwijzen. Je kunt hier dus ook geen port-forward e.d. op doen. Dat IP adres is niet van buitenaf bereikbaar (reageert ook niet op een ping vanaf hier).

$ nslookup 100.107.242.153
** server can't find 153.242.107.100.in-addr.arpa: NXDOMAIN

Je kunt nu dus wel in de CGNAT pool opgenomen zijn, maar dan heb je nu dus geen eigen publieke IP meer.

Ik ben ook maar een klant (met wat kennis 😉). Dit is een klant helpt klant community waar de moderators af en toe meekijken en zonodig inspringen.

PS. Ik kan op jouw oude IP adres nog steeds een Unify systeem bereiken.

Je hebt gelijk dat dit een CGNAT-adres (100.64.0.0/10) is.

Er is inderdaad geen individuele PTR-record (NXDOMAIN).
Het is niet direct vanaf internet bereikbaar (geen inbound port-forwarding mogelijk).

Dat is precies waarom ik het probleem blijf melden. Ik had voorheen een normaal publiek IP (77.170.x.x) en nu ben ik na de "refresh" in een CGNAT-pool terechtgekomen. Dit kan routing/peering problemen veroorzaken, zeker als er iets mis is met de manier waarop KPN dit CGNAT-verkeer naar Amsterdamse netwerken routeert.
Ik spreek zo meteen een KPN-engineer en zal dit allemaal aangeven (inclusief jouw opmerkingen). Hopelijk kunnen zij het onderzoeken.
Bedankt voor het meedenken!

Raar dat ik op jouw oude IP adres nog steeds een Unify router kan bereiken. Of het IP adres moet alweer uitgegeven zijn aan een nieuwe klant (wat natuurlijk mogelijk is 😁).

Maar wat is nu je probleem met de CGNAT? Je computer is dan niet direct bereikbaar dus een route naar jouw IP is ook niet meer van belang. Heb je slecht internet?

Hoi ​@swanksteak ,

Er wordt hier achter de schermen zeker meegekeken naar dit issue, alleen de traceroutes die je laat zien laten soms ook merkwaardige dingen zien. zou het kunnen zijn dat je ondertussen ook nog van een VPN gebruik maakt?

​@rvk01 Ja, mijn doorvoer via SSH vanaf de upstream-server in Amsterdam is gedaald van 70 MBps naar minder dan 10 MBps. Technici hebben me geadviseerd een traceroute uit te voeren en hebben het pakketverlies vastgesteld. Ik heb nu een nieuw IP-adres met minder hops, maar het pakketverlies blijft aanhouden. Bijgevoegd is een nieuw MTR-rapport.

​@Raymondt Er wordt geen VPN gebruikt.