networking diagnostics

Traceroute

traceroute diagnostics troubleshooting network-path
Plain English

Traceroute is like tracking a package through the postal system. Instead of just knowing whether it arrived (that is what ping does), traceroute shows you every sorting facility (router) it passed through, how long it spent at each stop, and where it got stuck if it never arrived. It is the go-to tool for figuring out where a network problem is happening between you and a destination.

Technical Definition

Traceroute (Linux/macOS) / tracert (Windows) maps the network path between source and destination by exploiting the IP Time to Live (TTL) field and ICMP Time Exceeded responses.

How it works:

  1. Send a packet with TTL=1. The first router decrements TTL to 0 and returns ICMP Time Exceeded, revealing its IP address.
  2. Send a packet with TTL=2. The second router responds.
  3. Increment TTL and repeat until the destination responds with ICMP Echo Reply (or the max hops limit is reached).
  4. Send three probes per hop to calculate min/avg/max latency.

Implementation differences:

  • Linux/macOS traceroute: sends UDP packets to high ports (33434+) by default. Can also use ICMP (-I) or TCP SYN (-T).
  • Windows tracert: sends ICMP Echo Requests with incrementing TTL.
  • mtr (My Traceroute): combines ping and traceroute into a continuous, real-time display. The best tool for diagnosing intermittent issues.

Reading traceroute output:

  • * * * (asterisks): the router did not respond. May be filtering ICMP, or the probe timed out. Does not necessarily indicate a problem.
  • Sudden latency jump at a specific hop: congestion or geographic distance at that link.
  • Increasing loss starting at a hop: likely a problem at or beyond that router.
  • Asymmetric routing: forward and return paths may differ, making single-direction traceroute incomplete.

Traceroute and mtr usage 

# Basic traceroute
$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8, 30 hops max, 60 byte packets
 1  192.168.1.1     1.234 ms  0.987 ms  1.102 ms
 2  10.0.0.1        5.432 ms  5.678 ms  5.234 ms
 3  72.14.215.85   11.234 ms 10.987 ms 11.456 ms
 4  8.8.8.8        12.345 ms 12.123 ms 12.567 ms

# TCP traceroute (bypasses ICMP filtering)
$ sudo traceroute -T -p 443 example.com

# mtr: continuous traceroute with statistics
$ mtr -n --report -c 100 8.8.8.8
HOST                  Loss%  Snt   Last  Avg   Best  Wrst  StDev
1. 192.168.1.1        0.0%  100    1.2   1.3   0.8   3.2   0.5
2. 10.0.0.1           0.0%  100    5.4   5.6   4.8   8.1   0.7
3. 72.14.215.85       0.2%  100   11.1  11.4  10.5  15.2   1.1
4. 8.8.8.8            0.0%  100   12.3  12.6  11.2  16.8   1.3

# Paris traceroute (more accurate path detection)
$ paris-traceroute 8.8.8.8
In the Wild

Traceroute is essential for isolating where a network problem lives. When a user reports “the website is slow,” traceroute reveals whether the latency is in your local network, your ISP, a transit provider, or the destination’s network. ISP support teams often ask for traceroute output when diagnosing connectivity issues. The mtr tool is preferred for ongoing diagnosis because it shows packet loss and latency statistics over time, revealing intermittent problems that a single traceroute misses. In cloud environments, VPC flow logs and cloud-native traceroute tools (AWS Reachability Analyzer) supplement traditional traceroute for diagnosing routing within virtual networks. A common gotcha: some routers rate-limit ICMP responses, making them appear lossy in traceroute even though they forward traffic perfectly.

← Back to Dictionary