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, not too busy to forward.

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 distance, not a fault. 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 the probes are being filtered, not that the path is broken. 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.

Field guide · Networking & wireless

Reading a traceroute

How to read traceroute, tracert and mtr output without drawing the wrong conclusion — which is the usual outcome. Covers why loss at one hop that does not continue is not loss at all, why a latency step that stays is distance rather than a fault, and why the last hop that answers is rarely where the problem is.

Plate 01Questions

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, not too busy to forward.
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 distance, not a fault. 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 the probes are being filtered, not that the path is broken. 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.