Reading a Traceroute: Why Packet Loss at Hop 5 Usually Means Nothing

A site feels slow, someone runs a traceroute, and there it is: 40 percent loss at hop 5. It looks like the answer. It almost never is, and acting on it sends people chasing a router that is working perfectly.

Traceroute is a genuinely useful tool that is built on a trick, and the trick is what makes the output so easy to misread.

What traceroute is actually doing

It sends packets with a deliberately small TTL. The first router decrements it to zero, gives up, and sends back an ICMP Time Exceeded message. That reply is how you learn the router exists. TTL 2 gets you the second one, and so on until the packets reach the destination.

So every line except the last is not a measurement of your traffic. It is a measurement of how quickly a router chose to generate an error message about your traffic. Those are different things, and routers treat them differently.

Why the middle hops lie

Generating ICMP replies is not a router's job. Forwarding packets is done in hardware; replying to an expired TTL is handled by the control plane, which is a much smaller CPU with more important work to do. Most routers rate-limit those replies, and some drop them entirely.

The result is a hop showing 40 percent loss while passing 100 percent of the traffic through it. Two rules follow, and they resolve most of these tickets on the spot:

Loss that does not continue to the end is not loss. If hop 5 shows 40 percent and hops 6 through 12 show zero, nothing was lost. Hop 5 simply did not feel like answering.
Only the last line counts. Loss at the destination, sustained, is real. That is the number worth escalating.

A hop showing high latency behaves the same way. A router that answers its own ICMP slowly is not necessarily forwarding slowly.

The half you cannot see

A traceroute shows the path out. It says nothing about the path back, and the two are frequently different: your packets might leave through one transit provider and the replies return through another. This is normal on the internet and not a fault.

It matters because the problem you are chasing might be entirely on the return path, which your traceroute cannot see at all. That is why a one-directional trace often has support asking for more rather than fixing something: half the evidence is missing.

This is also why the fix sometimes lives with a network that is not yours and not ours. When we run our own AS and BGP sessions, changing which way traffic returns is something that can be adjusted upstream rather than merely explained.

Use mtr instead

mtr is traceroute and ping combined. It keeps sending, so you see loss as a percentage over time rather than three probes' worth of guesswork:

mtr -rwzbc 200 dcxv.com

-r report mode, prints once and exits
-w wide output, so long hostnames are not truncated
-z show the AS number of each hop, which tells you whose network you are in
-b show both hostname and IP
-c 200 send 200 probes, because 10 tells you nothing about intermittent loss

On Windows, WinMTR does the same job. Let it run for a couple of minutes before you read anything into it.

What to send support

The single most useful thing you can attach is mtr in both directions: one from your machine to the server, and one from the server back to your address, taken at the same time. That pair turns a one-sided guess into something that can be traced to a specific network.

Include the destination IP, your own public address, the time and timezone, and whether it is constant or comes and goes. If it comes and goes, say when. Intermittent loss that follows a daily pattern is usually congestion somewhere, and knowing the hour narrows it fast.

What does not help: a screenshot of one traceroute with a red circle around a middle hop. It is the most common attachment and the least actionable one.

Bottom line

Read the last line, not the middle ones. Loss that does not persist to the destination is a router declining to answer, not a network dropping your traffic. When something is genuinely wrong, mtr in both directions is what turns a complaint into a fixable report.

Cloud and dedicated servers in Czechia and Portugal, on our own AS204057 network: dcxv.com/data-center#cloud