When traceroute lies

Traceroute is the second command everyone learns and the one most often misread. It is genuinely useful, but almost every alarming thing people see in its output is normal.

Asterisks are usually fine

A row of asterisks means that hop did not send a time-exceeded message. Many routers rate-limit ICMP generation or do not generate it at all, by policy. The packet still passed through: if later hops respond, that hop forwarded correctly. Asterisks in the middle with a successful final hop mean nothing is wrong.

High latency at one hop means nothing

Generating an ICMP error is control-plane work, handled by the router’s CPU, which is busy and deprioritises it. Forwarding is done in hardware. So a hop can report 300 ms while forwarding transit traffic in under a millisecond.

What matters is latency that is high and stays high for every subsequent hop. That indicates real delay in the path. A single spike that later hops do not inherit is a busy control plane, not a problem.

It shows one direction only

This is the big one. Traceroute maps the forward path. The return path may be completely different, and the latency you see includes both. A problem visible in traceroute may be on the way back, invisible to the tool you are using. Run it from both ends when you can.

Each probe may take a different path

With equal-cost paths, consecutive probes can traverse different routers, so the output is a blend of several paths rather than one. Tools such as mtr and Paris traceroute handle this better by keeping flow identifiers constant.

mtr -rwzbc 100 destination
traceroute -T -p 443 destination    # follow the real service path

Use TCP mode

If the service is TCP 443, trace with TCP to 443. ICMP and UDP probes can be treated entirely differently by firewalls and load balancers, so tracing with the wrong protocol maps a path your traffic never takes.