Mastering Traceroute: Step-by-Step Guide for Network TroubleshootingTraceroute is a fundamental network diagnostic tool that helps you map the path packets take from your machine to a remote host. Whether you’re a network engineer, system administrator, or an enthusiastic learner, understanding traceroute will greatly improve your ability to diagnose latency, routing, and connectivity issues. This guide explains how traceroute works, how to run it on different platforms, how to interpret results, and advanced tips for real-world troubleshooting.
What traceroute does (and what it doesn’t)
Traceroute determines the sequence of routers (hops) that packets pass through to reach a destination and measures the time each hop takes. It is useful for:
- Identifying routing paths and changes.
- Finding where latency or packet loss occurs.
- Locating unreachable or misconfigured routers.
Traceroute does not:
- Guarantee identical paths for all packets (paths can change).
- Always show every firewall or NAT that inspects traffic.
- Provide full performance metrics like a continuous monitoring system.
How traceroute works (basic mechanics)
Traceroute uses the Time-To-Live (TTL) field in IP packets. TTL starts at 1 and increments with each successive probe. When a router receives a packet with TTL=1, it decrements to 0 and discards the packet, returning an ICMP “Time Exceeded” message to the sender. By sending probes with increasing TTLs, traceroute learns the IP address of each router along the path. The round‑trip time (RTT) for each probe is recorded.
There are two main implementations:
- Traditional traceroute (Linux/Unix): sends UDP packets to high-numbered ports by default and relies on ICMP “Time Exceeded” replies and ICMP “Port Unreachable” when the destination is reached.
- Windows tracert: uses ICMP Echo Request packets for probes.
Modern variations can use TCP probes (e.g., tcptraceroute or traceroute with the -T option) to traverse firewalls that block UDP/ICMP.
Running traceroute on common platforms
Linux/macOS (traceroute):
- Basic: traceroute example.com
- Use ICMP: traceroute -I example.com
- Use TCP SYN (if supported): traceroute -T -p 80 example.com
- Adjust probes per hop: traceroute -q 3 example.com
Windows (tracert):
- Basic: tracert example.com
- Set maximum hops: tracert -h 30 example.com
- Set timeout (ms): tracert -w 1000 example.com
Other useful tools:
- mtr (my traceroute): combines traceroute and ping, showing continuous statistics per hop.
- tcptraceroute: sends TCP SYN probes to a specified port.
- Paris Traceroute: designed to avoid route anomalies caused by per-flow load balancing.
Interpreting traceroute output
A typical traceroute output lists one line per hop with three probe times and the responding router’s IP (and possibly hostname). Example (Linux traceroute):
1 192.168.1.1 1.123 ms 0.984 ms 1.045 ms
2 203.0.113.5 10.234 ms 9.876 ms 10.001 ms
3 * * *
4 198.51.100.9 50.321 ms 51.004 ms 49.888 ms
Key patterns and their meanings:
- Consistent low RTTs: normal local hops.
- Gradual increase in RTTs: expected as packets travel farther.
- Single high RTT at a hop, lower RTTs after: the router may deprioritize ICMP responses—this is not necessarily a real forwarded-path delay.
- Asterisks (*): no reply received within timeout. Could mean ICMP/UDP probes blocked or packet loss at that hop. If subsequent hops respond normally, the asterisked hop may be configured not to reply.
- Last hop unreachable (* * *): destination blocking probes or down.
- Sudden jump in RTT and continuing high latency: likely the point where a congested or distant link is encountered.
- Asymmetric routing: traceroute shows the forward path only; return path (responses) may take a different route. Asymmetry can cause confusing RTT and packet loss interpretations.
Common troubleshooting scenarios
- Slow website access for users in one region
- Run traceroute from affected region to the site.
- Look for the hop where RTT jumps significantly or where packet loss appears.
- If the jump occurs within your ISP or the CDN edge, contact the ISP/CDN with traceroute results.
- Intermittent connectivity or packet loss
- Use mtr for continuous probing to identify persistent loss at specific hops.
- If loss appears at one hop but not beyond, the router may deprioritize ICMP—correlate with application performance.
- Run traceroute at different times to detect time-based congestion.
- Unable to reach a host (timeouts)
- Check for consistent * * * at final hops — destination or intermediate network might be filtering ICMP/UDP.
- Use TCP-based traceroute to test access on service ports (e.g., port 80 or 443).
- Confirm DNS resolution; try traceroute to the destination IP directly.
- Path changes causing performance issues
- Run multiple traceroutes over time; compare to detect changes.
- Use Paris Traceroute if per-flow load balancing may cause inconsistent paths.
Advanced options and techniques
- Increase probes per hop (-q) to collect more samples and reduce variance.
- Increase maximum TTL (-m) to trace longer paths.
- Use reverse DNS lookups (-n to disable) depending on whether you want hostnames.
- Combine with ping, mtr, and BGP looking-glass services to correlate routing with BGP announcements.
- Use packet capture (tcpdump/wireshark) to inspect probe/response types and confirm firewall behavior.
- For IPv6: use traceroute6 or traceroute -6; be aware of different header sizes and potential MTU issues.
- When dealing with firewalls, use TCP SYN probes to a known-open port to see if the path for application traffic is allowed.
Example workflows
Quick local diagnosis:
- traceroute -n example.com
- If you see a clear hop with high latency, ping that hop directly.
- Run mtr to observe ongoing behavior.
Testing through firewalls:
- Attempt tracert/traceroute with default probes.
- If blocked, try traceroute -T -p 443 example.com (or tcptraceroute).
- If still blocked, capture packets to confirm filtering.
Correlating with BGP:
- Identify the AS numbers of suspicious hops via IP-to-AS lookups.
- Use public BGP tools to check prefixes and recent route changes.
Limitations and caveats
- Middleboxes and firewalls often affect traceroute visibility; lack of response isn’t always an actual forwarding problem.
- Per-flow load balancing can cause traceroute probes to traverse different paths, producing confusing results.
- ICMP and UDP responses may be deprioritized, yielding misleading latency at particular hops.
- Traceroute is a snapshot; intermittent problems may require prolonged monitoring.
Quick reference commands
Linux/macOS:
- traceroute example.com
- traceroute -I example.com (ICMP)
- traceroute -T -p 443 example.com (TCP)
Windows:
- tracert example.com
- tracert -d example.com (disable name resolution)
MTR:
- mtr example.com
- mtr -r -c 100 example.com (report mode, 100 pings)
Traceroute is simple in concept but powerful when combined with context and additional tools. With practice you’ll learn to distinguish harmless ICMP quirks from real network faults and use traceroute as a rapid first step in any network troubleshooting workflow.
Leave a Reply