Traceroute Explained: Diagnose Network Path Issues

The Problem Traceroute Solves

You are debugging a slow database connection from your application server to an RDS instance in another availability zone. Ping works. The connection eventually succeeds, but with 800ms of latency that appears randomly. Where is the delay happening - in your VPC, the AWS backbone, or on the application side?

Traceroute answers this question by mapping every router between you and the destination, measuring the round-trip time to each one. Instead of a binary "works/doesn't work," you get a path diagram of the network with latency at every hop. This is the information you need to identify whether the bottleneck is in your local network, your ISP, a transit provider, or the target network.

How Traceroute Works: TTL Manipulation

Traceroute exploits a fundamental property of IP networking: the Time To Live (TTL) field in every IP packet. TTL is a hop counter. Each router that forwards a packet decrements its TTL by 1. When TTL reaches 0, the router discards the packet and sends back an ICMP "Time Exceeded" message to the sender, including its own IP address.

Traceroute uses this mechanism deliberately:

1. Send a packet with TTL=1. The first router decrements to 0, discards the packet, and replies. You now know the IP and RTT of hop 1.
2. Send a packet with TTL=2. It passes the first router (TTL becomes 1), then the second router decrements to 0 and replies. Hop 2 identified.
3. Repeat with increasing TTL until the destination itself replies, or you reach the maximum hop count (usually 30).

By default, traceroute sends 3 probes per TTL value, which is why you see three latency measurements per hop. The variation between those three measurements shows packet-level jitter at that router.

Running Traceroute: Commands by Platform

# Linux (UDP probes by default)
traceroute google.com

# macOS (UDP probes)
traceroute google.com

# Windows (ICMP probes)
tracert google.com

# Linux with ICMP (bypasses some firewalls)
traceroute -I google.com

# Linux with TCP on port 80 (bypasses most firewalls)
traceroute -T -p 80 google.com

# Specify max hops (default 30)
traceroute -m 20 google.com

# Disable hostname resolution (faster output)
traceroute -n google.com

Reading Traceroute Output

Here is example output from traceroute -n google.com:

traceroute to google.com (142.250.80.46), 30 hops max, 60 byte packets
 1  192.168.1.1      1.234 ms  1.089 ms  1.156 ms
 2  10.0.0.1         5.678 ms  5.432 ms  5.891 ms
 3  72.14.215.165   12.345 ms  12.201 ms  12.567 ms
 4  * * *
 5  142.250.234.2   14.123 ms  13.987 ms  14.234 ms
 6  142.250.80.46   14.567 ms  14.432 ms  14.678 ms

Each line represents one hop. Reading left to right:

• Hop number (1, 2, 3...): the position in the network path
• IP address or hostname: the router at that hop
• Three RTT measurements: round-trip time in milliseconds for each of the three probes

In this example, the connection reaches Google's servers in about 14ms with very consistent latency - a healthy result. The * * * at hop 4 is a firewall or router that silently drops ICMP/UDP probes but still forwards traffic.

What Does * * * Mean?

The * * * output is the most misunderstood part of traceroute. It means the router at that hop did not reply within the timeout period. There are two very different reasons this can happen:

• The router filters probes (normal): Many routers, especially ISP backbone routers and cloud provider infrastructure, are configured to rate-limit or drop ICMP/UDP probes. The router is functioning normally and forwarding traffic, but it does not bother responding to traceroute packets. This is by far the most common reason for * * *.
• The router is actually unreachable or broken: If * * * appears at a hop and all subsequent hops also show * * *, and you cannot reach the destination, then there is a real network problem at or after that hop.

A single * * * hop surrounded by responding hops is almost always a router that filters probes - not a problem. Only worry about * * * when it appears at the point where the trace stops progressing entirely.

Diagnosing Common Network Problems

High latency spike at a specific hop

 1  192.168.1.1       1.2 ms   1.1 ms   1.3 ms
 2  10.0.0.1          5.4 ms   5.2 ms   5.6 ms
 3  203.0.113.1     320.4 ms 318.7 ms 321.2 ms   ← spike here
 4  198.51.100.5    322.1 ms 319.8 ms 320.9 ms
 5  198.51.100.1    323.4 ms 321.2 ms 322.7 ms

The 320ms spike appears at hop 3 and carries through to all subsequent hops. This indicates the bottleneck is at or just before hop 3 - likely a congested link or a long-distance undersea cable. Hops after the problem inherit the latency.

Latency spike that disappears at the next hop

 3  203.0.113.1     320.4 ms 318.7 ms 321.2 ms
 4  198.51.100.5      5.1 ms   4.9 ms   5.3 ms

When hop 3 shows high latency but hop 4 returns to normal, it means hop 3 is rate-limiting ICMP responses (deprioritizing probe replies) but forwarding actual traffic normally. This is not a real problem - it is a router configuration artifact.

Trace stops before destination

 8  203.0.113.10     14.2 ms  14.1 ms  14.3 ms
 9  * * *
10  * * *
11  * * *

The trace stops at hop 9 and never reaches the destination. Combined with a failed connection, this indicates a firewall or routing issue at or after hop 8. Use TCP traceroute (traceroute -T -p 443) to probe through firewalls that block UDP/ICMP.

mtr: The Better Traceroute

mtr (Matt's Traceroute) combines ping and traceroute into a single tool that continuously sends probes and updates statistics in real time. It is the preferred tool for network debugging because it reveals intermittent packet loss that a single traceroute run will miss.

# Install on Ubuntu/Debian
sudo apt install mtr

# Install on macOS
brew install mtr

# Run interactively
mtr google.com

# Run for 100 packets then display report
mtr --report --report-cycles 100 google.com

# TCP mode (bypasses ICMP filters)
mtr --tcp --port 443 google.com

mtr output looks like this after running for a few seconds:

Host                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1            0.0%    50    1.2   1.1   0.9   1.8   0.2
2. 10.0.0.1               0.0%    50    5.3   5.2   4.9   6.1   0.3
3. 72.14.215.165          0.0%    50   12.1  12.0  11.8  12.7   0.2
4. ???                   100.0%    50    0.0   0.0   0.0   0.0   0.0
5. 142.250.80.46          0.0%    50   14.2  14.1  13.9  14.8   0.2

The columns show: packet loss percentage, packets sent, last/average/best/worst RTT in ms, and standard deviation. A ??? hop with 100% loss at a position surrounded by working hops is a filtering router - not a problem. A hop with 5-10% loss that persists over 100 packets is a genuine link issue worth investigating.

Step-by-Step Network Debugging Process

1. Start with mtr: Run mtr --report --report-cycles 100 <destination> to get a statistically meaningful sample.
2. Identify the first hop with elevated loss or latency. Everything after an impaired hop is suspect.
3. Check if the high-latency hop is real or an artifact: If latency spikes at hop N but returns to normal at hop N+1, it is a filtering artifact. If the spike carries through to all subsequent hops, the problem is real.
4. Use reverse DNS on suspicious IPs: host 203.0.113.1 or our DNS Lookup tool can identify which carrier or provider owns the problematic hop.
5. Try TCP traceroute: If UDP/ICMP probes are blocked by a firewall, traceroute -T -p 443 or mtr --tcp --port 443 often gets through.
6. Compare from both ends: If possible, run traceroute from the destination back to your source. Routing is asymmetric - the forward and reverse paths may be completely different, and the problem may only be on one direction.

Traceroute on Windows: tracert

Windows ships with tracert, which uses ICMP echo requests (like ping) rather than UDP probes. The output format is similar but ICMP-based probes are blocked by more firewalls than TCP-based ones:

tracert google.com
tracert -d google.com    # Skip hostname resolution
tracert -h 20 google.com # Maximum 20 hops

For Windows users who need the full mtr experience, WinMTR is a free GUI equivalent that provides the same continuous packet loss and latency statistics.

Frequently Asked Questions

Is traceroute blocked by firewalls?

UDP and ICMP probes (the defaults on Linux and Windows respectively) are frequently blocked by firewalls. When this happens, all hops beyond the firewall show * * *. Using TCP traceroute on a port that the destination actually accepts (80 or 443) bypasses most firewall rules: traceroute -T -p 443 example.com.

Why does traceroute show different paths on repeated runs?

Many backbone routers use ECMP (Equal-Cost Multi-Path routing) to load-balance traffic across multiple parallel links. Traceroute probes may be hashed to different paths based on source port or other headers, resulting in different hop sequences on each run. This is normal and does not indicate a routing problem.

What does it mean when the trace loops (same IP appears multiple times)?

A routing loop means two or more routers are sending packets back and forth to each other, neither knowing the correct next hop. Each packet's TTL decrements through the loop until it hits 0. Routing loops are typically caused by a misconfigured BGP or OSPF route and are a real network problem that the upstream provider needs to fix.

How is traceroute different from ping?

Ping tests reachability to a single destination - it tells you whether a host responds and how long it takes. Traceroute shows the entire path to the destination, with latency at each intermediate hop. Ping answers "can I reach it?" Traceroute answers "where is the delay or failure occurring?"

Why does mtr show higher loss than traceroute?

mtr sends many packets over time and accumulates statistics. A router that rate-limits ICMP responses (sending back only 1 in 10 replies) will show ~90% loss in mtr even though it is forwarding traffic perfectly. Always compare a hop's loss percentage to the next hop - if the next hop shows 0% loss, the apparent loss is a measurement artifact, not real packet loss.

Can I run traceroute from a browser?

Browsers cannot send raw ICMP or UDP packets due to security sandboxing. However, you can look up DNS records, IP geolocation, and ASN information for any IP address you find in a traceroute using our DNS Lookup and IP Lookup tools - useful for identifying which carrier owns a suspicious hop.

Use our free tool here → DNS Lookup to resolve any hostname or IP address you encounter in a traceroute output, including reverse DNS lookups to identify network owners.