Reading Traceroute Results

A trace samples replies along a path

Traceroute sends probes with progressively increasing hop limits. When a probe expires along the way, a router can return an ICMP time-exceeded message. The resulting output associates an answering interface with a round-trip measurement. It is a set of observations, not a complete map of every cable and router.

Windows tracert uses ICMP echo probes and displays multiple timing samples per hop. Its Microsoft command reference explains the hop limit, timeout, numeric-output option, and the meaning of asterisks.

This distinction matters immediately: a visible hop is an interface that answered the probe. Devices that forwarded traffic but did not return a reply may remain invisible. A successful trace can therefore contain gaps without contradicting the destination's reachability.

Hop time is not the link's travel time

Each displayed timing includes the outward journey to the answering router and the return of its reply. Subtracting one row's timing from the next does not reliably produce the latency of the link between them. Different replies can take different return paths or receive different scheduling treatment.

The IPv4 router behavior behind these probes, including time-exceeded messages and ICMP rate limiting, is specified in RFC 1812. Rate limiting can make a busy router appear slow or lossy as a responder while it continues forwarding ordinary traffic.

In a hypothetical output, a middle hop at 300 milliseconds followed by a destination near 80 milliseconds should not automatically be described as 220 milliseconds of “recovered latency.” It is a clue that the probe replies are measuring more than simple incremental distance.

Asterisks describe missing evidence

An asterisk means that the expected response was not received within the tool's waiting period. Filtering, rate limiting, an unresponsive destination, or an actual delivery problem can all produce it. The output alone cannot choose among those explanations.

ICMP message types and their relationship to IP errors are described in RFC 792. ICMP is a diagnostic and control mechanism; the treatment of those messages need not match the treatment of the application's data.

If later hops answer normally, packets are clearly progressing beyond the silent location for at least some probes. Keep that fact beside the missing responses. If the trace stops entirely, add an application connection test before concluding that the same path is unusable for the service you care about.

Repeated samples improve the picture

mtr combines repeated probing with route information. Its upstream manual describes report mode, cycle counts, numeric output, and protocol choices.

These read-only examples use a documentation hostname. The TCP example probes the selected service port; it does not measure the throughput of a file transfer.

mtr --report --no-dns --report-cycles 30 example.com
mtr --report --no-dns --report-cycles 30 --tcp --port 443 example.com

Specify the sample count when saving a report. A one-packet loss in a short run and a persistent pattern across hundreds of samples convey different amounts of evidence. Record the time and the client network as well, since changing load and routing can alter the observation.

Protocol comparisons can be useful, but their results should be labeled separately instead of being blended into one unexplained “loss percentage.”

Compare the pattern across later hops

Suppose an illustrative report shows 40 percent missing replies at hop six but no missing replies at the destination. That pattern is consistent with limited responses from hop six; it does not establish that 40 percent of application traffic vanished there.

If increased loss or delay persists at later hops and at the destination, the observation deserves closer attention. Even then, identifying the exact responsible link requires more than choosing the first suspicious row. Shared return paths, changing routes, and probe scheduling can complicate attribution.

RFC 5388 provides a framework for representing traceroute measurements, including probe methods, per-hop responses, and measurement context. Its structure reinforces a useful reporting habit: preserve the conditions that produced the trace, rather than reducing the record to a router name and a verdict.

Trace both directions when possible

Internet routing can be asymmetric. A trace from a laptop to a server does not establish the route taken by a large response from that server back to the laptop. The reply packets used by the trace also have their own return paths.

If you control both endpoints, collect observations from each side. A client behind NAT or a firewall may not answer probes sent toward its public address, so a server-side trace can end before the client without proving that established application traffic fails.

For IPv6, ICMPv6 carries important control functions. RFC 4890 discusses filtering considerations; treating every ICMPv6 message as expendable can break behavior beyond a diagnostic display. Keep security policy and diagnostic expectations consistent rather than opening broad access merely to make a trace look tidy.

Connect the trace to the workload

Finish with the application's question. For video delivery, collect transfer rate, interval variation, transport retransmissions where available, and player behavior. For an API, record connection setup and response timings. A route report explains context for those measurements; it does not replace them.

Save raw output before writing the conclusion. Separate visible facts from interpretation: “the destination answered with a median near this value” is a measurement, while “a transit provider is congested” is an inference requiring corroboration.

A useful incident summary includes the direction, probe protocol, destination, timestamp, sample count, and whether an application test succeeded. That compact record gives another operator enough information to repeat the observation and challenge an explanation constructively.