Skip to content

traceroute

ping answers one question: did this destination respond? traceroute answers a different one entirely — which routers did the packet pass through on the way, and how long did each hop take? It gets that answer with a genuinely clever abuse of a field that has nothing to do with diagnostics in its original design: the IP header's Time To Live.

TTL was built to prevent infinite loops, not to map a path

Every IP packet carries a TTL, decremented by exactly one at every router it crosses. TTL exists to stop a misrouted packet from circulating forever if a routing loop ever forms — once TTL hits zero, the router holding it at that moment discards the packet immediately rather than forwarding it, and sends an ICMP Time Exceeded message (Type 11, Code 0) back to the original sender, identifying itself as the router where the packet died.

traceroute turns that failure-reporting mechanism into a deliberate discovery tool. It sends a packet with TTL set to 1, and the very first router along the path decrements it to zero and reports back — which means that first router has, unavoidably, revealed itself. Send a second packet with TTL 2, and the second router is the one that hits zero and reports. Increment the TTL by one for each subsequent probe, and each router along the entire path takes its turn being exposed, one hop at a time, purely as a side effect of doing exactly what TTL always requires it to do.

A real run, hop by hop

traceroute example.com

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.412 ms  0.389 ms  0.375 ms
 2  10.20.0.1 (10.20.0.1)  4.213 ms  4.109 ms  4.087 ms
 3  203.0.113.5 (203.0.113.5)  9.876 ms  9.654 ms  9.601 ms
 4  * * *
 5  93.184.216.34 (93.184.216.34)  12.301 ms  12.290 ms  12.104 ms

Each numbered line is one hop, and each hop sends three probes by default — the three timing columns are three separate round-trip times, not one measurement repeated for display. Hop 1 is the local gateway, answering almost instantly; the RTT climbing steadily at each subsequent hop is expected, since each additional router is genuinely one more real network segment away.

Hop 4's * * * means all three probes at that TTL got no reply at all before their timeout expired. That's frequently not a broken router — plenty of routers rate-limit or deliberately suppress ICMP Time Exceeded generation without dropping the actual forwarded traffic, so a silent hop in the middle of an otherwise complete trace is common and, on its own, not evidence of a problem. What matters is whether hops after it keep responding, hop 5 here included — if the trace successfully continues past the silent hop and reaches the destination, that hop simply chose not to identify itself, and the path is otherwise working exactly as expected.

How the destination itself gets detected

Every intermediate hop replies with Time Exceeded because its TTL hit zero mid-journey. The final destination is different: once a probe's TTL is high enough to actually survive the full path, it arrives intact. On Linux, the default traceroute sends UDP datagrams to a high, deliberately unused destination port (33434 and upward, incrementing per probe) — nothing is listening there, so the destination host replies with an ICMP Destination Unreachable, Code 3 (Port Unreachable) rather than Time Exceeded. traceroute recognizes that specific message as "you've arrived," not as an error, and stops incrementing TTL further.

Linux and Windows send genuinely different probes by default

Linux's traceroute defaults to UDP probes, as described above, and can be told to use ICMP Echo Requests instead with traceroute -I. Windows' tracert does the opposite — it defaults to ICMP Echo Requests for every probe, at every hop, and the destination confirms arrival with an ordinary Echo Reply rather than a Destination Unreachable. Both approaches expose the same intermediate routers via Time Exceeded; they differ only in what final message tells the tool it has reached the actual destination. A firewall that blocks UDP in that specific ephemeral-port range but permits ICMP Echo can make a Linux trace stall right at the last hop while a Windows trace against the same destination completes cleanly — worth checking before assuming one operating system's result reveals a fault the other one doesn't.

Practical scenario: the trace stops exactly at the network's edge

A trace to an external site completes every internal hop cleanly, then goes silent for every remaining hop all the way past where the destination should be — not one intermittent gap, but a hard stop:

 1  192.168.1.1 (192.168.1.1)  0.401 ms  0.388 ms  0.379 ms
 2  10.20.0.1 (10.20.0.1)  3.982 ms  3.877 ms  3.901 ms
 3  * * *
 4  * * *
 5  * * *
...
30  * * *

A single silent hop mid-trace, as in the earlier example, is unremarkable. Every remaining hop going silent, with no recovery at any later TTL and no final arrival, points somewhere different: an egress firewall at hop 3's boundary blocking the UDP port range traceroute uses outbound, for every packet from that point on — not one uncooperative router choosing not to reply, but a wall nothing gets through. Confirming this means trying traceroute -I to force ICMP Echo Requests instead of UDP; a trace that completes successfully under -I but not under the UDP default confirms the block is specific to UDP on those ports, not a real path or routing failure at all.

Where beginners misread the output

  • Treating one silent * * * hop as a broken path. Many routers suppress Time Exceeded replies deliberately without dropping the traffic they're actually forwarding; check whether later hops still respond before concluding anything is wrong.
  • Reading traceroute timings as a precise router-by-router benchmark. Rate-limiting on ICMP generation (routers deprioritize generating Time Exceeded messages compared to forwarding real traffic) can inflate a specific hop's reported time without that hop actually being slow to forward packets through it.

Practice exercises

  1. Run traceroute (or traceroute -I) against a distant destination and identify which hop shows the largest jump in RTT compared to the hop before it — that jump is often a real geographic or undersea-cable transition.
  2. A colleague sees * * * at hop 6 out of 12 and declares the network broken at that point. Using the distinction above, explain what you'd check before agreeing with that conclusion.

ICMP's job in this module has been diagnosing the network itself — is a host up, and where does a path break down. The next module turns from the protocols themselves to the physical and virtual devices that actually forward, filter, and inspect this traffic, and the command-line tools — including deeper looks at ping and traceroute themselves — used to work with them directly.

Sources