traceroute

核心 · Key Idea

In one line: traceroute progressively increments the TTL so each router on the path returns "TTL exceeded" — yielding the entire path your packets take to a destination, plus per-hop latency.

What it is#

$ traceroute -n 8.8.8.8
 1  192.168.1.1   1.2 ms   1.0 ms   1.1 ms
 2  100.64.0.1    8.5 ms   8.2 ms   8.4 ms
 3  202.97.x.x   12.0 ms  11.8 ms  12.1 ms
 ...
 9  8.8.8.8      11.9 ms  12.0 ms  11.8 ms

Each line = one router hop; the three RTT samples are three retries.

How it works#

Each hop reports its delay; combined, they reveal where it's slow / lossy.

Key concepts#

TTLTime To Live

IP-header field decremented per hop; dropped at 0 with an ICMP report.

TTL ExceededICMP Type 11

The 'I dropped it' message — what traceroute relies on to discover hops.

UDP / ICMP / TCP traceroutethree modes

Linux defaults UDP high-port; macOS/Windows default ICMP; `-T` uses TCP — best at crossing firewalls.

* * *starred hops

Hop didn't reply (filtered by firewall) — doesn't necessarily mean broken.

MPLS hiddenMPLS Hop

Carrier backbones often hide MPLS hops from traceroute.

Practical notes#

traceroute -n host: skip DNS — faster.
traceroute -T -p 443 host: TCP 443 — best chance to bypass ICMP filters.
tcptraceroute is another TCP-based implementation.
mtr host: traceroute + ping in one, continuously refreshed with per-hop loss / jitter. Production triage's first choice.
Stars mid-path are normal. Many core routers don't reply to TTL-exceeded; if the destination still answers and overall latency is sane, don't worry.
Don't trust one run. Network jitter is constant — run multiple times / use mtr for long observation.

Easy confusions#

traceroute

Snapshot path from one run.
Single-run results have noise.

mtr

Continuous probing; per-hop live loss / jitter.
Best for spotting **flaky** links.