Hoe traceroute de weg naar een server zichtbaar maakt
Tussen jouw laptop en een website zit een rij routers die je pakketje doorgeven, al gauw tien of meer. Je ziet ze nooit: je browser praat met een adres, en hoe het daar komt, is niet jouw zaak. Toch is er een commando dat die tussenstations één voor één tevoorschijn haalt. Dat commando heet traceroute, en het is vaak het eerste wat je typt als een server traag of onbereikbaar is.
Het mooie is dat traceroute geen speciale medewerking van routers vraagt. Het maakt slim gebruik van een vangnet dat in elk IP-pakket zit. Hieronder zie je hoe dat werkt, hoe je de uitvoer leest en waarom die uitvoer vaker liegt dan je zou denken. Alle metingen zijn gedaan op 9 oktober 2026 vanaf een Nederlandse verbinding.
Een teller die bij elke router afloopt
Elk IPv4-pakket heeft in de header een veld van 8 bits dat Time to Live heet, de TTL. RFC 791 definieerde het in 1981 nog in seconden, maar schreef ook voor dat elke router het met minstens 1 moet verlagen. RFC 1812 stelt vast wat dat in de praktijk betekent: de TTL is een limiet op het aantal hops.
Komt de TTL op nul, dan moet de router het pakket weggooien. Zo kan een pakket in een routeringslus niet eeuwig rondjes draaien. Linux geeft uitgaande pakketten standaard een TTL van 64 mee; dat staat in net.ipv4.ip_default_ttl.
Expres te vroeg sterven
Het interessante zit in de volgende zin van RFC 1812: een router die een pakket weggooit omdat de TTL op is, moet de afzender een ICMP-bericht sturen, Time Exceeded (type 11, code 0). Dat bericht komt van de router zelf, met zijn eigen IP-adres als afzender.
Traceroute buit dat uit. Het stuurt een pakket met TTL 1. De eerste router verlaagt naar 0, gooit het weg en meldt zich. Dan TTL 2: nu komt de tweede router aan het woord. En zo verder, tot de bestemming zelf antwoordt.
Je kunt dat met gewone ping nadoen door de TTL zelf te kiezen. Met ping -t 1 1.1.1.1 antwoordt de eerste router met Time to live exceeded. Met -t 7 is het een router van Cloudflare op 141.101.65.184, en pas bij -t 9 komt er een echt antwoord van 1.1.1.1.
Hoe weet traceroute welk antwoord bij welke probe hoort? Het ICMP-bericht bevat een kopie van het begin van het weggegooide pakket. RFC 792 eiste de IP-header plus de eerste 64 bits van de data; RFC 1812 vraagt routers zoveel mee te sturen als past binnen 576 bytes. In die kopie zitten de poortnummers van de probe.
Hoe traceroute weet dat het er is
De Linux-versie stuurt standaard UDP-pakketjes van 60 bytes naar "onwaarschijnlijke" poorten: de eerste naar poort 33434, daarna steeds één hoger. Per hop gaan er drie probes uit, tot maximaal 30 hops. Op de bestemming luistert niemand op zo'n poort, dus die antwoordt met Destination Unreachable, code 3: port unreachable. Dat is het teken dat traceroute kan stoppen.
Windows doet het anders. Volgens de documentatie van Microsoft stuurt tracert ICMP Echo Requests, hetzelfde als ping, en is een Echo Reply het eindsignaal. Op Linux kan dat ook met traceroute -I, en met TCP-pakketjes via -T, maar beide vragen rootrechten. Zonder die rechten krijg je You do not have enough privileges to use this traceroute method.
De uitvoer lezen
Dit is een traceroute naar 1.1.1.1. De routers van mijn eigen provider heb ik onherkenbaar gemaakt.
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 gateway lokaal netwerk 1.001 ms 0.910 ms 0.829 ms
2 router provider 12.888 ms 17.837 ms 12.578 ms
3 * * *
4 * * *
5 * * router provider 30.842 ms
6 * * *
7 141.101.65.184 18.181 ms * 141.101.65.185 12.992 ms
8 141.101.65.199 16.413 ms 141.101.65.211 34.591 ms *
9 one.one.one.one (1.1.1.1) 15.530 ms 12.577 ms *
Per regel zie je het hopnummer (de TTL), het adres dat antwoordde en drie round-trip-tijden. Volgens de RIPE-database horen de adressen op hop 7 en 8 bij AS13335, Cloudflare. Vanaf hop 7 zit het pakket dus in hun netwerk.
Kijk naar de tijden. Hop 5 heeft 30,8 ms nodig, de bestemming op hop 9 maar 12,6 ms. De probes die de bestemming haalden, gingen ook door dat stuk netwerk, dus die extra 18 ms zit niet in de afstand. Wat je bij een tussenstation meet, is vooral hoe snel die router zelf een ICMP-bericht maakt en terugstuurt. RFC 1812 noemt het verbruik van CPU en geheugen expliciet als reden om ICMP-foutmeldingen te begrenzen. Bovendien kan het antwoord via een andere weg terugkomen dan de probe ging. Een hoge tijd halverwege, terwijl de bestemming snel is, zegt dus weinig.
Waarom er sterretjes staan
Een * betekent alleen dat er binnen de wachttijd geen antwoord kwam. Op hop 3, 4 en 6 hierboven gebeurt dat, en toch bereikte het pakket de bestemming. Die routers stuurden het netjes door; ze stuurden alleen geen Time Exceeded terug. Sommige netwerken schakelen dat uit, andere begrenzen het aantal ICMP-berichten per seconde, wat RFC 1812 uitdrukkelijk toestaat. Regels waar maar een deel van de probes antwoord krijgt, passen bij zo'n limiet.
Lastiger is een rij sterretjes aan het eind. Een traceroute naar de testserver van Vultr in Sydney eindigde met alleen sterretjes van hop 19 tot en met 30: de server antwoordt niet op UDP naar willekeurige poorten. Traceroute weet dan niet dat het er al is en blijft doortellen tot hop 30. Dat zegt niets over of de server werkt: ping naar dezelfde server kreeg alle vier de pakketjes terug, in minimaal 315,6 ms.
Eén traceroute, meerdere routes
Diezelfde traceroute naar Sydney liet iets vreemds zien:
7 ae11.cr4-syd1.ip4.gtt.net (141.136.110.218) 316.473 ms 317.157 ms 310.711 ms
8 ae-0.r22.londen12.uk.bb.gin.ntt.net (129.250.5.151) 24.264 ms 23.980 ms 24.036 ms
Hop 7 zit volgens de naam in Sydney en volgens de tijd ook, hop 8 in Londen op 24 ms. Dat kan geen opeenvolgende route zijn. De verklaring staat in het onderzoek achter Paris traceroute: routers verdelen verkeer over parallelle paden op basis van de five-tuple, oftewel bron- en doeladres, protocol en de twee poortnummers. Klassieke traceroute verhoogt bij elke probe de doelpoort en verandert daarmee steeds de flow. Opeenvolgende probes kunnen zo over verschillende paden gaan, en de uitvoer plakt die aan elkaar tot een route die niet bestaat.
Met een vaste doelpoort (-U) en een vaste bronpoort (--sport) blijft elke probe in dezelfde flow. Twee runs met verschillende bronpoorten gaven daarna allebei hetzelfde, consistente pad, zonder Londen ertussen.
Sprongen die je niet ziet
In die stabiele run zat hop 5 volgens zijn naam nog in Amsterdam, op 11 ms, en hop 7 meteen in Sydney op 315 ms. Hemelsbreed ligt daar al ruim 16.600 kilometer tussen. Grote backbones sturen verkeer vaak door MPLS-tunnels. RFC 3443 beschrijft het zogeheten Pipe Model, waarin de tunnel voor de buitenwereld één hop is, hoeveel routers er ook in zitten. De routers binnen de tunnel verlagen alleen een eigen TTL in het MPLS-label, niet die van je pakket, dus niemand daarbinnen meldt zich. In Waarom Sydney altijd ver weg is lees je waar die 315 ms naartoe gaat.
Hostnamen als cr4-syd1 of londen12 zijn trouwens gewone reverse-DNS-namen die de beheerder zelf kiest. Meestal kloppen ze, maar ze zijn een hint, geen bewijs. De round-trip-tijd is de betere controle.
Zelf proberen
Op macOS en Linux:
traceroute 1.1.1.1
ping -c 2 -t 1 1.1.1.1 # Linux: TTL 1
ping -c 2 -m 1 1.1.1.1 # macOS en BSD: TTL 1
Op Windows is het tracert 1.1.1.1. Mijn ping met TTL 1 en 9:
$ ping -n -c 2 -t 1 1.1.1.1
From <gateway> icmp_seq=1 Time to live exceeded
From <gateway> icmp_seq=2 Time to live exceeded
$ ping -n -c 2 -t 9 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=19.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=13.2 ms
Zie je vreemde sprongen, probeer dan een vaste flow op Linux:
traceroute -n -U --sport=40000 -q 2 syd-au-ping.vultr.com
Tot slot
Ik had traceroute altijd gezien als een kaart van het pad. Na deze metingen zie ik het eerder als een verzameling losse getuigenverklaringen: elke router vertelt alleen iets over zichzelf, op het moment dat hij er zin in heeft, en misschien over een andere weg dan je dacht. Het mooiste voorbeeld vond ik de route die van Sydney terugsprong naar Londen: een pad dat geen enkel pakket heeft afgelegd. Elke regel in die uitvoer klopte op zich. Het is de optelsom die je moet wantrouwen.