How to read a traceroute, and what the asterisks really mean

Traceroute is the tool people run when something is wrong and then misread almost every time. A row of asterisks appears, or one hop shows 40 percent loss, and the conclusion is "found it." Usually nothing has been found at all.

The confusion comes from a mismatch between what traceroute looks like it does and what it actually does. Once you understand the trick it uses, the output stops being a list of suspects and becomes something you can read properly in about fifteen seconds.

The trick traceroute uses

There is no "trace this route" message in the internet protocol. Nobody designed a way to ask the network what path a packet takes. Traceroute gets the answer by exploiting a safety feature instead.

Every IP packet carries a Time To Live counter. Each router that forwards the packet subtracts one. When the counter hits zero, the router throws the packet away and sends back an error saying "this expired here." The mechanism exists so packets caught in a routing loop eventually die instead of circling forever.

Traceroute abuses it deliberately. It sends a packet with a TTL of 1, which dies at the first router, and that router identifies itself in the error. Then TTL 2, which dies at the second. Then 3. By walking the counter upward, it collects one identity per hop until a packet finally reaches the destination.

Two consequences fall directly out of this, and they explain most of the confusion:

• Every hop is answered by a different machine. You are not measuring one connection, you are collecting replies from a dozen unrelated routers, each with its own load, its own configuration and its own opinion about whether to answer you at all.
• Replying is optional and unrelated to forwarding. Generating an error message is extra work for a router's control processor, which is far weaker than the hardware that actually moves traffic. Under load, routers deprioritise or drop these replies while forwarding your real traffic at full speed.

Hold onto that second point. It is the single most important fact for reading the output correctly.

Anatomy of a single line

 7  ae-3.edge2.lhr.example-isp.net (198.51.100.22)  14.2 ms  13.8 ms  38.1 ms

Left to right: the hop number (seventh router along the path), the reverse DNS name for the address that replied, that address, and then one round trip time per probe. Most implementations send three probes per hop, which is why you get three numbers.

The round trip time is the full journey: your device to that router and the reply back. It is not the time to get from hop 6 to hop 7. That is why the numbers climb as you go outward, and why comparing two adjacent hops does not give you the cost of the link between them.

A single high value among three (like the 38.1 above) is almost always the router being slow to generate one reply, not a delay in the path. Watch the pattern across hops, not the outlier within one.

Five things that look broken and are not

1. Asterisks in the middle

A hop showing * * * means no reply came back within the timeout. It does not mean the packet stopped there. Plenty of routers are configured never to answer, particularly inside large provider networks and behind firewalls that filter ICMP. If the hops after it answer normally, traffic is passing through fine and that router simply declined to introduce itself.

2. One hop with high latency, later hops fast

Hop 6 answers in 280ms, hops 7 through 14 answer in 30ms. This looks alarming and means nothing. Your packets cannot travel backward in time, so if everything past hop 6 is fast, hop 6 did not delay them. It was just slow at replying.

3. Packet loss at a middle hop only

Same explanation, same rule. Rate limited replies show as loss. If the destination shows zero loss, there is no loss on the path. Only loss that continues through to the end is real, which is worth internalising before you test for packet loss properly.

4. Private addresses at the start

Seeing 192.168.1.1, then something in 10.x.x.x, is normal. The first is your router and the second is usually infrastructure inside your ISP's access network. An address in the 100.64.0.0/10 range is more interesting: that is carrier grade NAT, and it means you are sharing a public IP with other customers, which matters a lot if you ever want to forward a port.

5. Latency that goes down

Hop 9 answers in 90ms and hop 10 answers in 70ms. Nothing is wrong. The two replies came from different routers under different loads, and hop 9 happened to be busier. Measurement noise, not a time machine.

What a real problem looks like

There are only four patterns worth acting on.

A step change that persists

 4  20.1 ms   19.8 ms   20.4 ms
 5  21.3 ms   21.0 ms   21.9 ms
 6  118.7 ms  119.2 ms  118.4 ms   <- jumps here
 7  119.1 ms  118.8 ms  120.3 ms   <- and stays
 8  121.4 ms  120.9 ms  122.1 ms

That is real. Roughly 100ms was added between hop 5 and hop 6 and every hop after it carries the penalty. Either the path crosses an ocean there (check the hostnames, it is often simply geography) or something is genuinely congested.

Loss that carries to the destination

If hop 9 drops 20 percent and hops 10, 11 and 12 also drop roughly 20 percent, and the destination does too, that is real loss starting at hop 9. Note that hop 9 might not be the faulty device: it is the first place you can observe the damage, and the fault could be on the link feeding into it.

The trace never arrives

Hops answer normally and then everything past hop 12 is asterisks all the way to the maximum. Two possibilities. Either the destination and its final hops filter ICMP, which is extremely common for web servers, or the route genuinely does not get there. Distinguish them by connecting to the actual service: an HTTP(S) Check or a TCP connect on port 443. If the connection succeeds, the path works and the silence is a firewall policy.

The same addresses repeat

Hop 8, 9 and 10 all show the same two or three addresses alternating. That is a routing loop, and it is a genuine misconfiguration somewhere upstream. Rare, but unambiguous when you see it.

Reading the hostnames

The reverse DNS names carry more information than people realise, and they turn an abstract list into a map.

Most large networks embed airport codes: lhr for London, fra for Frankfurt, ams for Amsterdam, sjc for San Jose, nrt for Tokyo, bom for Mumbai, syd for Sydney. Watching those change across hops tells you exactly where your traffic goes, and it frequently explains a latency jump all by itself. If your packets visit Frankfurt on the way to a server two cities away, that is a routing decision, not a fault.

Interface names are conventional too. ae-3 is an aggregated link bundle, xe-0-1-2 is a 10 gigabit port, be-12 is a bundle ethernet. You rarely need these, but they confirm you are looking at real carrier infrastructure rather than a consumer device.

Words like core, edge, border, peer and transit tell you where in a network's hierarchy you are. A jump from an edge router in one provider to a border router in another is a handoff between networks, and handoffs are where congestion problems usually live.

To find out who actually operates a hop, look up its address. A public IP and ASN lookup names the organisation and its autonomous system number, and a Whois query on the address returns the registered owner of the block. That is how you work out whether a problem sits with your ISP, with a transit provider in the middle, or with the destination's own network.

The half of the path you cannot see

Here is the limitation that invalidates a lot of confident conclusions: a traceroute only shows the outbound path.

Return traffic can and often does take a completely different route. Internet routing is asymmetric by default, because each network independently decides how to reach each destination, and the policies are not symmetrical. So the round trip time on every line includes a return journey you have no visibility into.

This means a clean trace does not prove the path is clean, and a jump at a particular hop does not prove the problem is there rather than on the way back. To get the other half you need a trace run from the far end toward you, which is why network operators ask for one when you report a problem. Many hosting providers publish a looking glass page that runs exactly that on request.

It is also why you should be cautious about blaming a specific company based on one trace. You are seeing half the evidence.

Sending it to your ISP

Support teams receive a lot of traceroutes and most of them prove nothing. A few details make yours useful:

1. Include a trace to a well known target and to the thing that is broken

   Use 1.1.1.1 or 8.8.8.8 as a control, plus the actual destination. The comparison shows whether the problem is general or specific to one route.

2. Run it while the problem is happening

   A trace taken afterwards, when everything is fine, is evidence of nothing. If the problem is intermittent, run the same trace on a schedule and keep the results.

3. Pair it with a sustained ping

   Traceroute shows the shape of the path. A ping running for five minutes shows whether it is actually losing traffic. Together they are convincing, separately they are anecdotes.

4. Say which hop and why

   "Latency jumps from 21ms to 119ms at hop 6 and every subsequent hop carries it" is a report an engineer can act on. "Traceroute shows packet loss" gets a router reboot suggestion.

5. Include timestamps and both directions if you can

   Saved runs with timestamps let someone correlate against their own monitoring. A trace from the far end back to you completes the picture.

Because every run is stored in Run History, running the same trace daily for a week produces a record rather than a memory, and a pattern is much harder to dismiss than a single bad afternoon.

The short version

Traceroute works by letting packets expire on purpose, so each line comes from a different router that had no obligation to answer you. Asterisks, one slow hop and mid path loss are almost always the router being busy, not your traffic being harmed. The only patterns worth acting on are a latency step that persists to the end, loss that carries through to the destination, a trace that stops while the service still works, and repeating addresses. And remember you are only ever looking at one direction.