How to Read and Interpret a Traceroute: A Network Engineer's Guide
You run a traceroute and get fifteen lines of IP addresses, hostnames, and timing data. Reading this output correctly separates productive troubleshooting from guesswork. Here's what those numbers actually tell you.
You run a traceroute and get fifteen lines of IP addresses, hostnames, and timing data. The network is slow, packets are dropping, or routing looks wrong. But what do those numbers actually tell you?
Traceroute shows the path packets take from your machine to a destination. Each line represents a router hop along that path. The timing data reveals where delays occur. The hostnames hint at which ISPs and networks your traffic crosses. Reading this output correctly separates productive troubleshooting from guesswork.
How Traceroute Works
Traceroute exploits the Time To Live (TTL) field in IP packets. It sends packets with incrementally increasing TTL values, starting at 1. When a router receives a packet with TTL=1, it decrements the value to 0 and responds with an ICMP "Time Exceeded" message. This reveals the router's IP address.
The process repeats with TTL=2, TTL=3, and so on until packets reach the destination. Each TTL value uncovers the next hop in the path. Most traceroute implementations send three packets per hop to measure response time variability.
Reading Basic Traceroute Output
Here's a typical traceroute to google.com:
traceroute to google.com (142.250.191.14), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.156 ms 1.089 ms
2 10.0.0.1 (10.0.0.1) 12.345 ms 11.987 ms 12.123 ms
3 203.0.113.1 (isp-gateway.example.com) 15.678 ms 16.234 ms 15.890 ms
4 198.51.100.5 (core-router-chi.isp.net) 28.456 ms 27.890 ms 28.123 ms
5 * * *
6 172.217.164.1 (google-peering.net) 45.123 ms 44.567 ms 45.234 ms
Each line shows:
- Hop number — The router's position in the path
- IP address — The router's interface that responded
- Hostname — Reverse DNS lookup (when available)
- Three timing measurements — Round-trip time for each probe packet
Interpreting Hop Information
Hop 1: Your Gateway
The first hop is typically your local router or gateway. Response times under 5ms are normal for wired connections. WiFi adds 1–3ms. Higher latency here suggests local network issues.
Hops 2–3: ISP Access Network
These represent your ISP's local infrastructure. Cable modems might show 10–20ms. DSL connections often see 20–40ms. Fiber connections typically stay under 10ms.
Middle Hops: Internet Backbone
Core internet routers handle massive traffic volumes. Latency depends on geographic distance and network congestion. Cross-country hops in the US typically add 20–40ms. Transatlantic links add 80–120ms.
Final Hops: Destination Network
The last few hops belong to the destination's network. Content delivery networks (CDNs) like Cloudflare or AWS CloudFront often appear here, reducing final hop latency.
Analyzing Latency Patterns
Normal Latency Progression
Latency should increase gradually with each hop. Geographic distance drives most increases. A traceroute from New York to Los Angeles might show:
1 1ms (local gateway)
2 15ms (ISP local)
3 18ms (ISP regional)
4 45ms (cross-country backbone)
5 48ms (destination ISP)
6 50ms (destination server)
Sudden Latency Spikes
When one hop shows dramatically higher latency than previous hops, investigate:
3 18ms 15ms 17ms
4 156ms 158ms 162ms <- Problem hop
5 160ms 159ms 161ms
The spike at hop 4 indicates congestion, routing issues, or hardware problems at that router. Subsequent hops inherit this delay.
Latency Decreases
Sometimes later hops show lower latency than earlier ones:
4 45ms 46ms 44ms
5 38ms 37ms 39ms <- Lower than hop 4
This happens when routers prioritize ICMP responses differently or when traffic takes a faster path after the slower hop.
Understanding Packet Loss Indicators
Asterisks and Timeouts
Three asterisks (* * *) mean the router didn't respond within the timeout period:
5 * * *
6 45ms 44ms 46ms
Common causes:
- ICMP filtering — Many routers drop ICMP packets for security
- High CPU load — Overloaded routers may not respond to traceroute probes
- Routing loops — Packets get stuck in circular paths
- Actual packet loss — Network congestion or hardware failures
Partial Responses
Sometimes only one or two probes succeed:
4 28ms * 29ms
This suggests intermittent packet loss or selective ICMP filtering.
Hostname Analysis for Network Intelligence
Hostnames reveal network ownership and geographic routing.
ISP Infrastructure
core-router-chi.level3.net
core-router— Router typechi— Chicago location codelevel3.net— Level 3 Communications (now Lumen)
Geographic Indicators
ae-1-3604.edge7.NewYork1.level3.net
Location codes help trace geographic routing. Common abbreviations:
nyc/ny— New Yorklax/la— Los Angeleschi— Chicagodfw— Dallassea— Seattle
Cloud Provider Networks
Modern traceroutes often show cloud infrastructure:
142.251.49.158 (google-public-dns-a.google.com)
52.93.7.1 (amazon-02.amazon.com)
104.16.132.229 (cloudflare.com)
Common Routing Scenarios
Symmetric vs. Asymmetric Routing
Traceroute only shows the outbound path. Return traffic might take different routes. Use bidirectional traceroutes from both endpoints to see complete routing behavior.
Load Balancing
Multiple paths to the same destination can cause varying results:
Run 1: Router A -> Router B -> Destination
Run 2: Router A -> Router C -> Destination
This is normal for networks with redundant paths.
Routing Loops
Circular routing appears as repeated IP addresses:
8 203.0.113.5 45ms 46ms 44ms
9 203.0.113.6 47ms 48ms 46ms
10 203.0.113.5 48ms 49ms 47ms <- Same as hop 8
11 203.0.113.6 49ms 50ms 48ms <- Same as hop 9
Loops indicate routing table errors or network misconfigurations.
Advanced Troubleshooting Techniques
MTU Path Discovery
Large packet sizes can reveal MTU limitations:
traceroute -M do -s 1472 google.com
If traceroute fails at a specific hop with large packets but succeeds with smaller ones, that hop has MTU restrictions.
Protocol-Specific Tracing
Different protocols may take different paths:
traceroute google.com # ICMP
traceroute -T google.com # TCP
traceroute -U google.com # UDP
Some firewalls block specific protocols, revealing alternative routing.
AS Path Analysis
Autonomous System (AS) numbers show which organizations handle your traffic. Tools that combine traceroute with BGP data reveal the business relationships between networks.
What Traceroute Cannot Tell You
Bandwidth limitations — Traceroute measures latency, not throughput. A path with good ping times might still have bandwidth constraints.
Return path issues — Traceroute shows outbound routing only. Problems might exist on the return path.
Application-layer problems — Network routing might work perfectly while application protocols fail due to firewall rules, authentication issues, or server problems.
Practical Troubleshooting Workflow
- Establish baseline — Run traceroute to known-good destinations
- Compare paths — Trace to multiple destinations to isolate problems
- Check timing patterns — Look for sudden latency increases
- Identify problem hops — Note which routers show issues
- Correlate with symptoms — Match traceroute data to reported problems
- Document findings — Record normal vs. problematic routing patterns
Modern Network Diagnostics
Traditional traceroute provides basic path visibility, but modern networks need deeper intelligence. Cloud provider detection, BGP analysis, and security context help engineers understand not just where packets go, but what risks and opportunities exist along the path.
Network diagnostic tools that combine traceroute data with threat intelligence, cloud provider identification, and routing analysis give you the complete picture. Instead of just seeing IP addresses and timing data, you get interpreted results that directly inform troubleshooting decisions.
Conclusion
Reading traceroute output effectively requires understanding both the technical mechanics and the business context of internet routing. Latency patterns reveal network health. Hostnames expose routing decisions. Packet loss indicators highlight problem areas.
The key is moving beyond raw data interpretation to actionable intelligence. When you can quickly identify which cloud provider hosts a service, what ASN owns a problematic router, or whether high latency stems from geographic distance or network congestion, you troubleshoot faster and more accurately.
For comprehensive network intelligence that interprets routing data alongside security context and infrastructure details, explore the diagnostic tools on CyrusX.
Related Articles