Reading a Traceroute

Questions people actually ask

One hop shows 100% loss but the trace completes. Is that a problem?

No, and this is the single most misread thing in traceroute output. Routers generate ICMP TTL-exceeded replies at low priority, so a busy core router will drop your probes while forwarding real traffic perfectly. Loss only counts when it continues to every hop after it, all the way to the destination. Loss at one hop that clears at the next is the router being too busy to answer a probe. How it forwards real traffic is a different question, and usually a fine one.

Latency jumps at one hop and stays high. What does that mean?

That is a real leg of the path — usually a long haul between cities or a peering handoff — and it is the length of that leg, and every hop after it carries the same figure. A jump that carries through to the destination is geography. A spike at one hop that comes back down at the next is that router being slow to answer, which is invisible to your actual traffic.

The trace stops before reaching the destination. Is the host down?

Probably not. Most edge firewalls drop ICMP and UDP probes while happily accepting TCP to the service port. A trace that dies at the last few hops usually means something along the way is filtering probes. The path itself may be perfectly healthy. Confirm with a TCP probe to the real port before concluding anything.

How do I tell whose network the fault is in?

Find where sustained loss begins and look at whose address space that hop sits in. Private RFC 1918 addresses are your own infrastructure. Anything in 100.64.0.0/10 is carrier-grade NAT — your ISP's internal addressing, not yours, which is worth knowing before you go looking for a switch you do not own. Everything past that belongs to a carrier.

Why do the three times on each line differ so much?

They are three separate probes, and each may take a different path where equal-cost routing exists. Wide variation across the three at one hop, with steady times after it, usually means that router is inconsistent about answering rather than that the path is unstable. mtr's larger sample makes this much easier to see than a single traceroute run.

Is mtr better than traceroute?

For diagnosis, yes. It runs continuously and gives you loss percentages over many probes rather than three samples, which is what separates a hop that genuinely drops traffic from one that happened to miss a packet. Use traceroute to see the path; use mtr to judge it.