ping and traceroute Explained

When something is broken, the first two commands every network engineer reaches for are ping and traceroute. Both use ICMP. Both give you specific kinds of information that nothing else does. Master what each one tells you.

ping — is the host reachable?

ping sends ICMP Echo Request packets and waits for Echo Reply packets. If you get replies back, the destination is reachable AND can talk back to you AND ICMP isn’t blocked anywhere along the way.

ping -c 5 google.com

PING google.com (142.250.190.46) 56(84) bytes of data.
64 bytes from ord37s37-in-f14.1e100.net (142.250.190.46): icmp_seq=1 ttl=115 time=12.3 ms
64 bytes from ord37s37-in-f14.1e100.net (142.250.190.46): icmp_seq=2 ttl=115 time=11.7 ms
...
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 11.701/12.045/12.318/0.234 ms

What ping tells you

• Reachability — packets get there and back
• Latency — round-trip time (the “time=” field)
• Packet loss — % of pings that didn’t get a reply
• Jitter — variance in latency (high stddev = unstable connection)

Useful ping options

ping -c 10 host           # send exactly 10 pings
ping -i 0.2 host          # 5 pings per second (need root for under 1s)
ping -s 1400 host         # send 1400-byte payloads (test MTU)
ping -W 2 host            # wait 2 seconds for each reply
ping -n host              # don't reverse-DNS the IPs
ping -4 host              # force IPv4
ping -6 host              # force IPv6
ping -f host              # flood ping (root only, stress test)

What ping does NOT tell you

• Whether a specific TCP port is open (use nc or nmap)
• Whether the application is running (HTTP server might be down even if host pings)
• Whether DNS is working (you got an IP back, that’s all)

When ping fails but the host IS up

• Firewall blocks ICMP (common on Windows servers, AWS instances by default)
• Host is reachable but routing is asymmetric
• You’re being rate-limited

traceroute — what’s the path?

traceroute shows every router (hop) between you and a destination. It does this by sending packets with deliberately low TTL values and watching where each packet expires.

traceroute google.com

 1  router.local (192.168.1.1)            1.234 ms  1.123 ms  1.345 ms
 2  10.10.5.1 (10.10.5.1)                 5.678 ms  5.234 ms  6.012 ms
 3  72.14.215.62 (72.14.215.62)          14.567 ms 13.234 ms 15.123 ms
 4  108.170.234.193 (108.170.234.193)    18.123 ms 17.890 ms 18.456 ms
 5  142.250.190.46 (lhr25s27-in-f14...)  19.234 ms 18.567 ms 19.012 ms

How it works (the TTL trick)

1. Send a packet with TTL=1. The first router decrements TTL, gets 0, drops the packet, sends back ICMP “Time Exceeded” → you learn router #1’s IP.
2. Send a packet with TTL=2. Reaches router #2 before expiring → you learn #2.
3. Continue until you reach the destination (which sends a normal reply, not Time Exceeded).

What traceroute tells you

• The path your packets take
• Latency at each hop
• Where the path is breaking (last successful hop is just before the problem)

Reading traceroute output

• Asterisks (***) — that hop didn’t reply. Either it’s blocking ICMP or the path stops there.
• Sudden latency jump — the next hop is far away geographically (intercontinental link)
• Latency spike at one hop, then back to normal — that one router just doesn’t prioritize ICMP responses (NORMAL — don’t worry)
• Loop (same hops repeating) — actual routing loop, indicates network bug

traceroute variants

# Use TCP instead of UDP/ICMP (better through firewalls)
sudo traceroute -T -p 443 google.com
tcptraceroute google.com 443

# Use ICMP echo (more reliable through some firewalls)
sudo traceroute -I google.com

# Show AS numbers (which network owns each hop)
traceroute -A google.com

# mtr — combines ping and traceroute, real-time
mtr google.com
mtr -bzw google.com    # report mode with AS numbers

mtr is what most engineers use day-to-day. It runs traceroute continuously, showing per-hop loss percentages and latency stats. Great for diagnosing intermittent issues.

Common debugging patterns

“Internet doesn’t work”

ping 192.168.1.1                # is gateway up?
ping 8.8.8.8                    # internet routing working?
ping google.com                 # DNS working?
traceroute 8.8.8.8              # where does it die?

“This specific site is slow”

mtr -n example.com              # see where latency comes from
ping example.com                # baseline latency
ping -s 1400 example.com        # MTU issues?

“Connection from server X to server Y times out”

# From server X
ping Y                          # network reachable?
traceroute Y                    # path?
nc -zv Y 5432                   # port specifically?

Common mistakes

• Using ping to test “is my service up?” — service might be dead even if ICMP works. Use the actual protocol (curl for HTTP, nc for TCP port).
• Trusting traceroute paths from the destination back — paths are often asymmetric.
• Worrying about asterisks at intermediate hops — many routers deprioritize ICMP, this is normal.
• Not knowing your own MTU — mysterious connectivity issues often turn out to be MTU mismatches found via ping -s.

What to learn next

dig and nslookup — the DNS troubleshooting tools. Up next.