How Traceroute Works: TTL, ICMP, and Hop Discovery

When a program sends a packet to a remote host, the packet crosses a series of routers, each of which forwards it toward the destination. The sender has no direct way to learn the identities of those routers, because normal IP forwarding does not report back. Traceroute solves this by turning the packet’s time-to-live field into a probe. By sending packets with deliberately small TTL values and listening for the error messages that come back, the sender can map the path one hop at a time. The same mechanism underlies Windows tracert, Unix traceroute, and the per-hop statistics in pathping.

The TTL mechanism

Every IPv4 header contains an 8-bit Time To Live field. Despite the name, TTL is not a timer in modern networks; it is a hop counter. A router that receives a packet decrements the TTL by one before forwarding it. If the TTL reaches zero, the router discards the packet and sends an ICMP Time Exceeded message (type 11, code 0) back to the source address. This design prevents packets from circulating forever if routing tables contain a loop.

Traceroute exploits the discard rule. The sender transmits a packet with TTL set to 1. The first router decrements it to 0, drops it, and returns Time Exceeded. The source address of that ICMP message is the first router’s address on the interface facing the sender. The sender then transmits a packet with TTL 2; the first router forwards it with TTL 1, the second router drops it and replies. The process repeats with increasing TTL until a packet reaches the destination, at which point the destination responds with a different message (ICMP Echo Reply for Windows tracert, or ICMP Port Unreachable for Unix traceroute’s UDP mode). That final response tells the sender the path is complete.

Each probe therefore reveals exactly one router, and the sequence of replies reconstructs the forward path. The mechanism depends only on the TTL field and on routers being willing to generate ICMP errors.

Windows tracert versus Unix traceroute

The two tools use different probe packets, which matters when interpreting results.

Windows tracert sends ICMP Echo Request packets, the same packet type as ping. Each router that drops an expired probe returns ICMP Time Exceeded. The destination, receiving an Echo Request with TTL still above zero, returns ICMP Echo Reply. Some networks filter inbound ICMP Echo Request at the perimeter, so a tracert can show every router on the path and still end in timeouts at the destination.

Unix traceroute defaults to UDP datagrams addressed to high-numbered ports that are unlikely to be open. Intermediate routers still return Time Exceeded when TTL expires. The destination, finding no listener on the port, returns ICMP Port Unreachable, which the tool interprets as arrival. The -I option switches to ICMP Echo, matching Windows behaviour; the -T option uses TCP SYN packets, which is useful when a firewall permits TCP but drops ICMP and UDP.

Both tools send multiple probes per hop, typically three, and print one line per hop with up to three round-trip times.

Reading the output

A typical Windows line looks like this:

  4    12 ms    11 ms    13 ms  10.0.0.1

The hop number, three round-trip times, and the responding address. A Unix line is similar but may include the address in parentheses and a hostname if reverse DNS resolves. The times are measured from probe transmission to receipt of the ICMP error, so they include the router’s own processing time for generating that error, not just forwarding latency.

Asterisks and timeouts

A line such as:

  5     *        *        *     Request timed out.

means no ICMP Time Exceeded arrived for any of the three probes at that hop. This is common and usually harmless when later hops answer. Routers often rate-limit ICMP error generation or deprioritise it below forwarding traffic, because generating errors is optional work. A router that is busy forwarding packets may simply not reply to probes within the timeout. If hop 6, 7, and 8 all answer, the path is intact and hop 5’s silence reflects the router’s ICMP policy, not a broken link. The same applies to a hop that shows one or two times and then asterisks: the router answered some probes and dropped others under rate limiting.

A run of asterisks that continues to the end of the trace is different. If no hop after a certain point ever answers, the path may genuinely stop there, or a firewall may be dropping the probe type entirely. Testing with a different probe type (ICMP versus UDP versus TCP) distinguishes the two cases.

Latency patterns

A single hop with elevated latency that returns to normal at the next hop indicates that the router itself is slow to generate ICMP errors, not that the path is congested. The meaningful pattern is latency that rises at one hop and stays elevated for every subsequent hop through to the destination. That pattern indicates a congested or degraded link between the two hops where the increase appears, because all later packets traverse the same link.

Asymmetric paths

Traceroute maps the forward path only. The return path from destination to source can follow different routers, and often does. The round-trip times printed are for the probe outbound and the ICMP error inbound, so they combine both directions. A path that looks clean outbound can still have a poor return path, which traceroute will not show. Running a trace from the far endpoint back toward the source is the only way to see the return path.

pathping: per-hop loss over time

Windows pathping combines traceroute with a sustained probe phase. It first runs a tracert-like discovery to learn the hop list, then sends packets to each hop over a period (default 25 seconds per hop) and reports loss and latency statistics per hop. The output separates the discovery phase from the statistics phase:

pathping example.com

The statistics table shows, for each hop, the percentage of packets lost and the round-trip times. Because the probes are sustained, transient rate limiting at a router is averaged out, and a hop that shows loss in pathping but not in tracert is more likely to be genuinely dropping traffic. The same caveat applies: routers that deprioritise ICMP will show inflated loss at their own hop without affecting later hops.

What people get wrong

A common misreading is treating an asterisk at a middle hop as evidence of a fault at that hop. The mistake is natural because the line looks like a failure and the tool prints it in the same column as successful hops. But the mechanism explains why it is usually not a fault: the router only has to generate an ICMP error, and many routers are configured to rate-limit or suppress that generation while continuing to forward packets normally. The correct interpretation is that the hop did not answer the probe, not that it failed to forward traffic. Confirmation comes from later hops answering: if the trace reaches the destination, the path is working.

A second misreading is attributing high latency at a single hop to that hop. Because the printed time includes the router’s ICMP generation, a router with a slow control plane can show hundreds of milliseconds while forwarding at line rate. The meaningful signal is sustained elevation from the hop where latency rises through to the end.

A third is assuming the trace shows the return path. It does not. The return path is invisible to a standard traceroute run from one endpoint.

When the mechanism does not apply

Practical commands

Windows:

tracert example.com

Prints the hop list with three round-trip times per hop. Use -d to skip reverse DNS and speed the run, -h to set maximum hops, and -w to change the per-probe timeout.

pathping example.com

Runs discovery then sustained per-hop statistics. The run takes time proportional to the hop count times the per-hop probe period.

Unix and Linux:

traceroute example.com

UDP mode by default. Add -I for ICMP Echo or -T for TCP SYN. Add -n to skip DNS resolution.

traceroute -T -p 443 example.com

TCP mode to port 443, useful when ICMP and UDP are filtered.

The output in each case is a numbered list of hops, each with the responding address and round-trip times. Asterisks indicate no reply at that hop. The final line is the destination, or the last hop that answered before the maximum hop count was reached.