How Traceroute Works: TTL, ICMP and Reading the Stars

Traceroute answers a deceptively simple question: which routers does a packet cross on its way to the destination? It exploits a field every IP packet carries — the Time To Live (TTL). Each router along the path decrements the TTL by one; when it hits zero, the router drops the packet and sends an ICMP "Time Exceeded" message back to the sender. That safety mechanism, designed to kill routing loops, doubles as a map of the path.

The TTL trick, step by step

1. Send a packet with TTL = 1. The first router decrements it to zero, drops it, and returns ICMP Time Exceeded — revealing its address.
2. Send with TTL = 2. The first router forwards; the second router kills it and identifies itself.
3. Keep incrementing until a packet reaches the destination. The final reply is different — an ICMP Echo Reply (for UDP variants, an ICMP Port Unreachable) — which marks the end of the path.

Each line of output therefore shows one router, usually with three probe round-trip times, since most implementations send three probes per TTL. Typical output looks like:

 1  gateway.local        0.4 ms  0.3 ms  0.3 ms
 2  isp-core.example     8.1 ms  8.0 ms  8.2 ms
 3  intl-gw.example     42.7 ms 43.1 ms 44.0 ms
 4  * * *
 5  target.example.com  45.2 ms 45.0 ms 45.3 ms

Reading the output

• Gradually rising latency: normal. Each hop adds distance; international links add tens of milliseconds at once.
• A sudden jump at one hop: a congestion point or a congested international segment. The hop where the jump first appears is the suspect segment.
• Asterisks (* * *): the router did not answer the probes. This is not automatically an error — many routers rate-limit or simply refuse to answer ICMP Time Exceeded for security. It only matters if every hop from that point onward also fails; then the path genuinely breaks there.
• Different addresses across the three probes: load balancing across parallel paths. Harmless, but it makes per-hop numbers noisy.

Two caveats that trip people up

• High latency on the last hops can be an illusion. Some routers deprioritise ICMP replies, answering probes only after forwarding real traffic. Latency that appears at hop 6 but does not persist at hops 7 and 8 is measurement overhead, not a real bottleneck — judge latency by where it persists to the destination.
• Paths change between runs. Load balancing means a second traceroute can cross different routers entirely. For a stable picture, tools like mtr run continuously and aggregate statistics per hop, separating real loss from cosmetic noise.
• Firewalls can block the whole protocol. Some networks drop outbound UDP or ICMP Time Exceeded, and traceroute returns nothing but stars. TCP-based traceroute (on port 443) usually gets through and is the right fallback.

For the classic "is it me or is it the server?" dispute, traceroute is the fastest instrument: if latency spikes from hop 3 onward, the problem sits in that network segment, not on your server. Use it when a site is slow but reachable, when a route change broke connectivity, or before and after switching providers to compare paths. The WhoDNS traceroute tool runs the trace from our server, so you get a second, independent vantage point to compare with your own output — two views of the same path usually isolate the faulty segment in minutes.

🔗 Related tool: Run a traceroute to any host