Voor de volledigheid heb ik ook even een traceroute andersom gedaan, hierbij de laatste hops:

8 nl-ams02a-rd1-tge-0-4-0-2.aorta.net (84.116.130.41) 15.614 ms 15.613 ms 5.516 ms
9 84.116.244.42 (84.116.244.42) 15.698 ms 16.037 ms 16.158 ms
10 84.116.245.154 (84.116.245.154) 15.896 ms 16.134 ms 16.224 ms
11 212.142.0.33 (212.142.0.33) 15.437 ms 15.723 ms 15.457 ms
12 212.142.61.98 (212.142.61.98) 15.413 ms 15.377 ms 15.394 ms
13 f79xxx.upc-f.chello.nl (80.56.xx.xxx) 62.129 ms !X 68.489 ms !X 61.894 m !X

Hier zie ik dus niet het 10.15.81.1 adres terugkomen.

Er zijn wel meer ISPs, meestal telcos of andere gecertificeerde prutsbendes als UPC, die intern-maar-voor-de-klant-zichtbaar met RFC1918-adressen werken, ja. Netjes is het niet, nee.

Nee dit is nieuw, dit was voorheen niet zo. Dit is sinds de komst van de Horizon flut producten. En als het zo zou zijn dat UPC interne reeksen gebruikt voor routering zou je dit beide kanten op moeten zien (dus ook vanaf extern naar mij toe). Dat is niet het geval.

Iets klopt hier dus niet.

Dit kan verder wel kloppen.
Het antwoord (ttl expired) dat op een traceroute gestuurd wordt door een device, wordt normaal gesproken verstuurd vanaf het uitgaande interface richting de bestemming (dwz: richting de bron van de traceroute ).

Bij de traceroute vanaf de thuis PC is het interface tussen PC en UPC router blijkbaar 10.15.81.1 .
De next hop in het UPC netwerk, die kijkt in de richting van de thuis PC is 212.142.61.97

Bij de traceroute de andere kant op , is de voorlaatste hop (die kijkt in de richting van de plek waar de traceroute gedaan werd) 212.142.61.98 . Dat zal vast dezelfde router zijn, maar een ander interface
En de laatste hop van het modem, maar nu uitgaand richting de traceroute source 80.56.xx.xxx

Bij de ene traceroute stuurt het modem antwoord vanaf het LAN-facing interface naar de thuis PC, bij de traceroute van buiten wordt het antwoord vanaf het WAN-facing interface verstuurd.

Works as designed.

Dat op de eerste hop was me op d'ene of d'andere manier even ontschoten. Niet alles is even zorgvuldig met het juiste ipadres aan de juiste interface te koppelen. En op de eerste hop is dat je modem, dus wellicht dat dat rare bokkesprongen uithaalt. Als niet (dus als je vanaf het modem die traceroute gedaan hebt) dan zal het een headend of dslam van upc zijn.

En die doen ook wel eens vreemde dingen. Soms reageren ze ineens niet meer op ping of traceroute. Ik heb ook wel eens twee keer hetzelfde ipadres op de tweede (en derde) of derde (en vierde, ofzo) hop gezien.

Van buitenaf zien zal je het niet. Wellicht dat ze filteren op de egress (is wel zo netjes om te doen), maar als niet dan nog komt het niet door de default-free zone heen. Je kan nog even het aantal hops tellen, beide kanten op. Best kans dat er iets asymmetrisch tussenzit. Hoewel als het op je modem is (wat NAT doet) het niet achter de NAT uitkomt. Wat er precies gebeurt weet ik ook niet, daar niet van.

Overigens is het "flutproducten", in het Nederlands althans.

Nee, dit is niet nieuw en het is zeker niet zo sinds te komst van Horizon. Ieder modem krijgt gewoon binnen het UPC netwerk een eigen intern IP toegewezen en dan krijg je met dhcp een normaal IP-adres toegewezen.

Ook bij Ziggo zie ik dat sinds een jaar bij traceroute. Voor die tijd was die 10.x.x.x niet zichtbaar aanwezig.

ziggo is de is sinds kortetijd weer lekker bezig ja.

ze hebben schijt aan iedereen, zo kwam ik er een paar dagen geleden achter dat je de dns servers kan wijzigen na wat na je favoriete voorkeur, ma dat ze daar helemaal geen gehoor aan word gegevens.

elke ip/dns test zegt de verzoeken nog van dynamic.ziggo afkomen, daar ben ik niet blij mee.


ik ga mooi weg bij die corrupte bende, en hun handel in wijkkastjes (die in bijna elke straat een staat) aan justiie, zodat hun ze kunnen inzetten om ons nog massaler te kunnen afluisteren.


iemand nog suggesties wat betreft "fatsoenlijke" internet service providers?
die privacy wel een hoge prio heeft, en dan bedoel ik die ook doen wat ze zeggen

Als je dat bijzonder vindt dan mis je de benodigde diepgaande kennis van hoe traceroute werkt en hoe routers omgaan
met de TTL bijvoorbeeld in geval van ARP cache misses.

Dat is verder niet erg, maar ga dan niet een ander beschuldigen.

Ik heb eigenlijk nog niet gezien/gehoord dat de afluister wijkkast door Ziggo geleverd was. Gezien dat die bal ging rollen toen Ziggo monteurs een 'onbekende' kast zagen zou je denken van niet.

Voor wat betreft providers die wel veel doen aan privacy is dat sinds jaar en dag XS4ALL.

(Waar wettelijk verplicht met de juiste machtiging werkt ook xs4all mee met justitie, overigens)

ARP cache misses op het pad van de klant naar buiten? Ook direct nadat ik de continue lopende traceroute (mtr) herstart en daarmee het wel-betreden pad nog eens opniew natraceer? Lijkt me, zacht gezegd, onwaarschijnlijk.

Buiten dat had die verbinding een minimum(!) packet loss van 10% gemeten over maanden, met sporadisch meer, veel meer. Ik heb daar wel eens pingtijden van 30 seconden (als in 30000 miliseconden, jawel, ik heb de log nog ergens) gemeten. Of bijvoorbeeld: Binnen een half jaar vier nieuwe router/modems geleverd gekregen omdat ze voortdurend over de nek gingen, factory-defaults die ongevraagd geforceerd over de eigen instellingen geschreven werden, soms meermaals per week, en zo verder. Ergens houdt het op met het voordeel van de twijfel.

Volgens mij lul je uit je nek om interessant te doen. Het minste is toch wel dat je het dan even begrijpelijk uitlegt, meneertje de betwetert.

@Anoniem Ziggo geeft als hostname een xxx.dynamic.ziggo.nl adres. Dat heeft verder weinig met DNS Servers te maken. Wanneer jij in bijvoorbeeld je PC als DNS-server 208.67.222.222 (OpenDNS) opgeeft krijg je bij een onbekend domein toch echt een OpenDNS vangpagina en gaat je request dus gewoon via de niet-Ziggo DNS-server. Wel vanaf een Ziggo IP met een dynamic.ziggo.nl hostname.

"ik ga mooi weg bij die corrupte bende, en hun handel in wijkkastjes (die in bijna elke straat een staat) aan justiie, zodat hun ze kunnen inzetten om ons nog massaler te kunnen afluisteren."

LMFAO wat een onzin. Voldoen aan aftapverzoeken is geen gunst, maar een juridische verplichting.

Een bedrijf heeft geen keuze. Verder heeft jusitie geen wijkkastjes nodig, zij gebruiken gewoon de wettelijk verplichte aftap voorziening die elke provider in het netwerk heeft zitten, daarvoor hoef je de wijk niet in.

"iemand nog suggesties wat betreft "fatsoenlijke" internet service providers?"

Je zoekt naar een provider die zich niet aan de wet houdt ?

Indien je niet afgetapt wil worden, zorg dan dat je geen handelingen verricht op basis waarvan een rechter commissaris toestemming zal geven om jou af te tappen.

Vrij simpel ;)

"elke ip/dns test zegt de verzoeken nog van dynamic.ziggo afkomen, daar ben ik niet blij mee."

Denk je dat -jouw- DNS entry wijzigt wanneer jij een DNS record van een systeem op internet bij een andere DNS server opvraagt ? Jij bent inderdaad nog altijd dynamic.ziggo.

De vraag op welke DNS server jij een domein opvraagt heeft daar helemaal niks mee te maken......

ARP cache misses is niet zo waarschijnlijk inderdaad.

Maar RTT/packet loss op tussenliggende hops zegt erg weinig over de kwaliteit van de end to end verbinding.
Een verstandige operator zal verkeer gericht _aan_ een router fors rate limiten, en het genereren van antwoorden op TTL expired heeft een lage prioriteit voor de router cpu.

Dat je zo af en toe geen antwoorden ziet van tussenliggende hops, of dat die een hogere RTT geven dan de eindbestemming kan prima, en het wil niet zeggen dat er end-to-end een hoge RTT is, of packetloss is.

traceroute is nuttig, en ongeveer het enige wat je hebt als eindklant, maar het zegt niet alles over een verbinding.


Blijkbaar heb je inderdaad geen goede dienst . Opzeggen dan maar.
Het zou nog kunnen dat de ping tijden en packetloss buiten het domein van je provider veroorzaak worden.
(Want, zie boven, je kunt niet altijd op basis van traceroute zeggen waar het begint mis te gaan ).


Ook al was ik niet dezelfde betweter als degene die de ARP cache mis opperde, bij deze.

Als beiden zeer scherp oplopen direct na de router/modem, dan is dat wel een teken aan de wand. De ADSL linkstatistieken vertelden ook zo een eigen verhaal. Dat was ook waar de 30 seconden pings te zien waren.

In dit geval zes seconden interval per uitgezonden pakket op vijf hops, dus 30 seconden interval per host. Continue doorlopend om te kunnen zien wat voor fout er nu weer te zien was. Extra breed venster zodat een backlog van enige tientallen minuten zichtbaar was. Een reboot van het router/modem kostte een minuut of twee. Er waren er regelmatig meerdere op rij te zien.

In context, hield het na maanden dagelijks de trace bijhouden (op een 30 seconden ping interval per hop) plots permanent op voor een hop. Nooit meer een ping vandaan gezien later. Kennelijk uitgezet. Wat gezien de openstaande tickets waar niets mee gebeurde dingen zegt over hun prioriteiten.

Gedeelde verbinding en de contractuele klant was niet voor rede vatbaar. Alternatieven waren om alweer politieke redenen (en fysieke: niet genoeg koperparen, glasvezel niet te krijgen, etc.) niet beschikbaar. Heb nog een tijdje op een wifi van buren meegelift, maar die deed het 50 van de 60 seconden wel, en dan 10 seconden strak niet. Dat is ook niet prettig. Overigens deed de wifi het wel constant als ze het (aparte) modem loskoppelden--maar dan heb je dus geen uplink. Wellicht iets met de electriciteit in dat huis niet geheel in orde. Blij dat ik daar uit de buurt wegverhuisd ben.

Dat is zeker waar. Maar als je kijkt naar adressen die in een adresbereik van je provider zit vanaf een verbinding van die provider en je kijkt maar een paar hopjes diep, en alle tussenliggende adressen zijn ook van die provider, dan, nuja, doe ik die anderszins ongefundeerde aanname toch maar.

Ik denk dat wel duidelijk is wat daarmee aan de hand was.