Traceroute: Tracing the Network Path

Traceroute (or tracert on Windows) is a network diagnostic tool that shows the path packets take from your computer to a destination. It reveals every router (hop) along the way and measures the time it takes to reach each one, making it invaluable for identifying where network problems occur.

How Traceroute Works

Traceroute exploits the Time To Live (TTL) field in IP packets. The TTL starts at a certain value and decrements by one at each router. When TTL reaches zero, the router discards the packet and sends back an ICMP "Time Exceeded" message.

Traceroute works by sending packets with incrementally increasing TTL values:

1. TTL=1: First router receives packet, decrements TTL to 0, sends back error message revealing its address
2. TTL=2: First router passes it, second router hits TTL=0, responds
3. TTL=3, 4, 5...: Process continues until destination is reached

Basic Usage

The basic syntax is straightforward - just provide the destination:

# Trace route to a domain
traceroute google.com    # macOS/Linux
tracert google.com       # Windows

# Trace route to an IP address
traceroute 8.8.8.8       # macOS/Linux
tracert 8.8.8.8          # Windows

Platform-Specific Commands

Windows (tracert)

# Basic traceroute
tracert google.com

# Don't resolve hostnames (faster)
tracert -d google.com

# Set maximum hops
tracert -h 20 google.com

# Set timeout in milliseconds
tracert -w 2000 google.com

# Force IPv4
tracert -4 google.com

# Force IPv6
tracert -6 google.com

macOS

# Basic traceroute
traceroute google.com

# Don't resolve hostnames
traceroute -n google.com

# Set maximum hops
traceroute -m 20 google.com

# Use ICMP instead of UDP
traceroute -I google.com

# Set wait time (seconds)
traceroute -w 2 google.com

# Set number of probes per hop
traceroute -q 1 google.com

Linux

# Basic traceroute
traceroute google.com

# Don't resolve hostnames
traceroute -n google.com

# Use ICMP (may require root)
sudo traceroute -I google.com

# Use TCP SYN packets (better firewall penetration)
sudo traceroute -T google.com

# Set specific port (useful for testing firewall rules)
traceroute -p 443 google.com

# Use mtr for continuous traceroute
mtr google.com

Interpreting Traceroute Output

Here's a typical traceroute output and what each part means:

$ traceroute google.com
traceroute to google.com (142.250.80.46), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)  1.234 ms  1.123 ms  1.089 ms
 2  10.0.0.1 (10.0.0.1)  8.432 ms  8.567 ms  8.234 ms
 3  isp-router.example.net (203.0.113.1)  12.345 ms  11.987 ms  12.123 ms
 4  * * *
 5  core-router.carrier.net (198.51.100.1)  25.678 ms  24.567 ms  25.123 ms
 6  google-peer.carrier.net (198.51.100.50)  26.789 ms  25.890 ms  26.234 ms
 7  142.250.80.46 (142.250.80.46)  27.123 ms  26.890 ms  27.012 ms

Element	Description
Hop number (1, 2, 3...)	Order of routers in the path
Hostname	Reverse DNS name of the router (if available)
IP address	Router's IP address
Three time values	Round-trip time for each of 3 probes sent
* * *	No response (router hiding or filtering)

Understanding the Times

Each hop shows three time measurements because traceroute sends three probes by default. This helps identify inconsistent latency:

• Similar times: Stable connection to that hop
• Varying times: Network congestion or load balancing
• One asterisk: One probe was lost (minor packet loss)
• All asterisks: Router doesn't respond (not necessarily a problem)

What Asterisks Mean

Seeing * * * doesn't always indicate a problem:

• Router configured to not respond: Many routers ignore traceroute probes for security
• Firewall blocking: Corporate or ISP firewalls may block ICMP/UDP
• Rate limiting: Routers may limit ICMP responses

If the traceroute eventually completes (reaches destination), the hidden hops aren't causing problems.

Common Options Reference

Option	Windows	macOS/Linux	Description
No DNS	-d	-n	Skip hostname resolution (faster)
Max hops	-h 30	-m 30	Maximum number of hops
Timeout	-w 3000	-w 3	Wait time (ms for Win, sec for others)
IPv4	-4	-4	Force IPv4
IPv6	-6	-6	Force IPv6
ICMP	(default)	-I	Use ICMP Echo

Troubleshooting Scenarios

Scenario 1: High Latency at a Specific Hop

 5  router-a.isp.net     15.234 ms   14.567 ms   15.012 ms
 6  congested.isp.net   150.432 ms  145.678 ms  148.234 ms  <-- Sudden spike
 7  router-b.isp.net    152.123 ms  149.890 ms  151.234 ms

Diagnosis: Congestion or a slow link at hop 6. Since subsequent hops maintain similar latency, the problem is between hops 5 and 6.

Solution: Contact your ISP if this hop is in their network. If it's beyond your ISP, you may need to wait for the carrier to resolve it.

Scenario 2: Packet Loss at One Hop

 4  router.carrier.net    25.123 ms  *  25.890 ms
 5  next-router.net       26.234 ms  26.012 ms  26.567 ms

Diagnosis: Minor packet loss at hop 4, but packets are getting through. If subsequent hops show consistent results, this is likely just the router deprioritizing ICMP responses.

Scenario 3: Route Goes Dark

 6  last-responsive.net   30.123 ms  29.890 ms  30.234 ms
 7  * * *
 8  * * *
 9  * * *
...
30  * * *

Diagnosis: Traceroute never reaches destination. Either a firewall is blocking all probes, or there's a routing problem after hop 6.

Solutions:

• Try TCP-based traceroute: sudo traceroute -T -p 80 target.com
• Try different ports: traceroute -p 443 target.com
• Verify the destination is actually reachable with curl or web browser

Scenario 4: Routing Loop

 5  router-a.net  25.123 ms  25.234 ms  25.567 ms
 6  router-b.net  26.890 ms  26.123 ms  26.456 ms
 7  router-a.net  27.234 ms  27.567 ms  27.890 ms
 8  router-b.net  28.123 ms  28.456 ms  28.789 ms

Diagnosis: Packets are bouncing between two routers. This is a serious routing misconfiguration.

Solution: Contact your ISP or the network administrator responsible for those routers.