How to Read and Interpret Traceroute Results

What Traceroute Actually Does

Traceroute works by sending packets with increasing TTL (Time to Live) values. The first packet has TTL=1, so the first router decrements it to 0 and returns an ICMP "Time Exceeded" message — revealing the first hop's IP. The second packet has TTL=2, reaching the second hop before expiring. This continues until the destination responds with a "Port Unreachable" (UDP mode) or "Echo Reply" (ICMP mode), completing the path.

# Linux (UDP mode, default)
traceroute google.com

# Linux (ICMP mode — often works through firewalls that block UDP)
traceroute -I google.com
sudo traceroute -I google.com

# Linux (TCP mode — most firewall-friendly)
sudo traceroute -T -p 80 google.com

# macOS (ICMP by default)
traceroute google.com

# Windows
tracert google.com

Understanding Each Hop

A traceroute result shows each router along the path:

traceroute to google.com (142.250.80.46), 30 hops max
 1  192.168.1.1         1.2 ms   1.1 ms   1.0 ms    <- Home router
 2  10.100.0.1          8.4 ms   8.2 ms   8.5 ms    <- ISP DSLAM/CMTS
 3  203.0.113.1         9.1 ms   9.3 ms   9.0 ms    <- ISP core router
 4  72.14.215.165      12.3 ms  12.1 ms  12.4 ms    <- Google peering
 5  142.251.49.58      12.8 ms  12.9 ms  12.7 ms    <- Google backbone
 6  142.250.80.46      13.2 ms  13.1 ms  13.2 ms    <- Destination

Reading the columns: - Column 1: Hop number (TTL value) - Column 2: IP address or reverse DNS hostname of the router - Columns 3-5: Three round-trip times in milliseconds (three probes are sent per hop)

Healthy patterns: - Latency increases monotonically (each hop adds a small increment) - The three RTT values for each hop are consistent (within 5-10ms of each other) - Total latency to destination is reasonable for geographic distance (~1ms per 100km in fiber)

Asterisks and Timeouts

 4  * * *
 5  72.14.215.165  12.3 ms  12.1 ms  12.4 ms

Three asterisks mean the probe packets at that hop timed out. This does NOT necessarily mean the hop is unreachable or causing problems. The router may simply be configured not to respond to ICMP Time Exceeded messages.

Key insight: If the NEXT hop responds, the intermediate hop with asterisks is working fine — it just does not send ICMP TTL exceeded messages. The asterisks show a router that silently forwards traffic without responding to probes.

Concerning patterns:

# Pattern 1: Packet loss at a specific hop AND all subsequent hops
 4  * * *
 5  * * *
 6  * * *
# True loss at hop 4 — problem is AT or before hop 4

# Pattern 2: Latency spike that persists to destination
 4   8.0 ms   7.9 ms   8.1 ms
 5  250.3 ms  249.8 ms  250.1 ms   <- sudden increase
 6  251.2 ms  251.0 ms  251.3 ms
# Problem introduced at hop 5 (congestion, bad route, or distance)

ICMP Rate Limiting

Many routers rate-limit ICMP responses to prevent DoS attacks. This causes intermittent asterisks that do not indicate real packet loss.

# ICMP rate limiting shows as occasional * in otherwise healthy rows:
 3  203.0.113.1   9.1 ms   * 9.3 ms   <- middle probe timed out, others OK

# Use mtr to send more probes and see true packet loss percentage
mtr --report --report-cycles 100 google.com

mtr distinguishes between ICMP rate limiting (occasional loss at intermediate hops but 0% loss at destination) and actual packet loss (loss persists at destination).

# mtr report mode (100 cycles, then exit)
mtr --report --report-cycles 100 --no-dns google.com

# Live mode
mtr google.com

# mtr with TCP (avoids ICMP blocking)
mtr -T -P 443 google.com

# Example mtr output:
# HOST: myhost          Loss%  Snt  Last   Avg  Best  Wrst StDev
#   1. 192.168.1.1        0.0%  100  1.2   1.2   1.0   2.1   0.3
#   2. 10.100.0.1         0.0%  100  8.3   8.4   7.9  12.1   0.6
#   3. 203.0.113.1       12.0%  100  9.5  10.1   8.8  45.3   4.2  <- rate limiting
#   4. 72.14.215.165      0.0%  100 12.2  12.3  11.8  14.1   0.5
# Loss at hop 3 but 0% at hop 4 = rate limiting, not real loss

Asymmetric Routing

Return packets often take a completely different path than outgoing packets. Traceroute only shows one direction. This explains why a hop might show high latency even though the application feels fast — the latency you see is the sum of forward AND return path.

# Traceroute from source to destination
traceroute destination.com

# Run traceroute FROM the destination back to you (requires access to destination)
ssh [email protected] "traceroute YOUR_IP"

# Or use online traceroute tools to probe from multiple locations:
# https://ping.canopy.tools/
# https://bgp.he.net  (BGP + traceroute)
# https://traceroute.online

Asymmetric routing is normal and expected. It only becomes a problem when: - One direction has significantly higher latency than the other - One direction experiences packet loss (creates one-way audio in VoIP) - Stateful firewalls block return traffic from unexpected sources

Geographic Hop Analysis

Reverse DNS hostnames often encode location information in the format city-state-country.isp.com.

# Enable DNS resolution in traceroute
traceroute google.com   # DNS on by default

# Disable DNS (faster)
traceroute -n google.com

# Analyze hostnames for location clues
traceroute 8.8.8.8 | grep -oP '\S+\.net\b|\S+\.com\b'

# Common ISP hostname patterns:
# ae-x.cr2.nyc3.us.nlayer.net -> New York
# so-5-0-0.edge3.Chicago1.Level3.net -> Chicago
# 72.14.215.165 -> Google (check AS via bgp.he.net)

Unexpected geographic hops (traffic going from New York to London then back to New York) indicate suboptimal routing, possibly due to traffic engineering or peering agreements. BGP routing sometimes produces inefficient paths due to commercial relationships between ISPs.

Identifying ISP Boundaries

The point where your traffic crosses from your ISP to another ISP (or to a major backbone) is often visible in traceroute output.

# For each hop IP, look up the ASN (Autonomous System Number)
# This reveals which company operates each router

# Using whois
whois 72.14.215.165 | grep -E "ASN|AutNum|OrgName"

# Using dig
dig +short AS72.14.215.165.origin.asn.cymru.com TXT

# Batch lookup with bgp community strings
# https://bgp.he.net/ip/72.14.215.165

# When ASN changes between hops, you have crossed ISP boundaries
# Example:
#  Hop 3: AS7922  (Comcast - your ISP)
#  Hop 4: AS15169 (Google - destination's network)
# This is the peering point between Comcast and Google

Latency spikes at AS boundaries often indicate inadequate peering capacity (congested interconnect) rather than a routing problem. The fix is either ISP-side (improved peering) or using a CDN that has direct peering with your ISP.

mtr vs traceroute vs pathping

# Install mtr
sudo apt install mtr          # Debian/Ubuntu
sudo brew install mtr         # macOS
sudo yum install mtr          # RHEL/CentOS

# Best practice: start with traceroute for path, then mtr for statistics
traceroute -n destination.com
mtr --report-cycles 100 -n destination.com

# Save mtr output for comparison over time
mtr --report --report-cycles 100 -n destination.com > /tmp/mtr-$(date +%Y%m%d-%H%M%S).txt

Use traceroute when you want a quick snapshot of the network path. Switch to mtr when troubleshooting packet loss, jitter, or intermittent latency spikes — its continuous probing and statistical output reveal patterns that single-pass traceroute cannot.