Traceroute feels magical the first time you run it: a list of hops appears, each with a latency, tracing a packet’s journey across the internet. But the technique has assumptions and blind spots that make it easy to misinterpret. Understanding them turns traceroute from a party trick into a reliable diagnostic.
The TTL trick
Traceroute works by exploiting the Time-To-Live field in IP packets. It sends a packet with TTL 1; the first router decrements it to 0, drops it, and sends back an ICMP Time Exceeded message — revealing that router’s address. Then it sends TTL 2, and the second router replies. It repeats, incrementing the TTL, until the packet reaches the destination.
Crucially, each hop’s latency is measured for the probe that reached that hop, not for the full path to it. A hop showing 50 ms means the round trip to that router was 50 ms — it does not mean the path to hop 5 took 50 ms and the path to hop 6 took 60 ms, so hop 6 added 10 ms. Latencies are independent measurements and can even decrease as you go further, because return paths can differ.
Why hops show as asterisks
A row of three asterisks does not mean a router is down. It means no ICMP reply came back within the timeout. The most common reason is that the router is configured to rate-limit or silently drop TTL-expired responses — a common hardening practice on core routers. The packets are still passing through; you just cannot see that hop. Traffic continues to subsequent hops, which appear normally.
This is why a traceroute with a gap in the middle but a successful destination is usually healthy. The gap is a visibility limitation, not a connectivity problem.
Asymmetric and load-balanced paths
The internet does not guarantee a single path. Per-flow load balancing can send each probe along a different route, producing a traceroute that appears to visit unrelated routers in sequence. Similarly, the return path for the ICMP replies can differ from the outbound path. The result is a trace that does not reflect any single packet’s actual journey.
When a trace looks bizarre — hops jumping between continents, latencies that make no geographic sense — suspect load balancing before suspecting routing pathology. Running multiple traces and comparing helps; a single trace is one sample of a possibly non-deterministic path.
When traceroute is the wrong tool
Traceroute answers “where does the path break” only when the break is at a visible hop. If the destination itself is dropping traffic, the last visible hop is the router just before it — useful, but not proof that router is the culprit. Pair traceroute with a ping to the destination and a port check on the service you actually care about. The combination tells you reachability, path, and service availability, which is what you really wanted to know.