Chapter 14 — ICMP: what ping and traceroute really do

What ICMP is

IP itself has no way to say "that didn't work". ICMP (Internet Control Message Protocol) fills that gap. It is not a transport protocol — it has no ports and carries no user data. It just reports conditions.

Messages you should recognise:

How ping works

Dead simple: send an Echo Request, the target's operating system replies with an Echo Reply, measure the round trip.

ping -c 5 example.com

64 bytes from 93.184.216.34: icmp_seq=1 ttl=52 time=91.2 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=52 time=90.8 ms
...
--- example.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss
round-trip min/avg/max/stddev = 90.8/91.4/92.1/0.5 ms

What each part tells you:

• time=91.2 ms — round trip. Mostly determined by distance.
• icmp_seq — sequence number. Gaps mean lost packets.
• ttl=52 — how much hop budget was left (Chapter 13).
• stddev / mdev — jitter. Low = stable. High = congested or wireless.
• 0% packet loss — the headline number.

Important caveats (these trip people up constantly):

1. "Ping fails" does not mean "host is down". Many hosts and firewalls block or rate-limit ICMP deliberately. Always confirm with something else.
2. Never judge a router by pinging the router itself. Routers deprioritise traffic addressed to them — a router can show 30% ping loss while forwarding your real traffic perfectly.
3. Ping measures round trip, not one way. They're often not symmetric.

How traceroute works (the clever trick)

traceroute exploits the TTL counter from Chapter 13:

   Send a packet with TTL = 1
      -> the FIRST router decrements it to 0, drops it,
         and sends back "Time Exceeded"
      -> that error reveals router 1's address!

   Send a packet with TTL = 2
      -> router 1 passes it (TTL 2->1), router 2 drops it
      -> reveals router 2

   Send TTL = 3, 4, 5, ... until a packet finally reaches the destination.

Each row of traceroute output is one router that had to drop your packet.

traceroute -n example.com

 1  192.168.1.1        1.2 ms   1.1 ms   1.3 ms      <- your router
 2  10.20.30.1         8.4 ms   8.2 ms   8.9 ms      <- your ISP
 3  * * *                                            <- didn't reply (see below)
 4  62.115.11.22      22.1 ms  21.8 ms  22.4 ms
...
12  93.184.216.34     91.2 ms  90.9 ms  91.5 ms      <- destination

How to read traceroute without being misled

This is one of the most misinterpreted tools in networking. Three rules:

1. * * * usually means nothing is wrong. It means that router chose not to reply. If later hops respond fine, the path is fine.

2. High latency at one hop that doesn't persist is fake. Look at this:

 5   10.0.0.1     150 ms      <- looks terrible!
 6   10.0.0.2      22 ms      <- but the NEXT hop is fast
 7   destination   24 ms

Hop 5 isn't slow — it just deprioritises replies to itself. Only believe a latency or loss figure if it persists on every subsequent hop.

3. You only see the forward path. The return path may be completely different, and a problem there will show up in your numbers without being visible in the list.

mtr — use this instead

mtr combines ping and traceroute, running continuously:

mtr -rwzbc 100 example.com     # 100 packets, report mode

It shows loss% and latency per hop over time, which makes rule 2 above obvious: loss that appears at hop 5 and vanishes at hop 6 is cosmetic; loss that appears at hop 5 and continues to the destination is real.

Do not block all ICMP

A depressingly common "hardening" mistake. If you block ICMP entirely:

• You break Path MTU Discovery (Chapter 15) — connections hang mysteriously.
• On IPv6 you break the network completely (Chapter 16) — ICMPv6 does address resolution.

Block what you must, but always allow type 3 (destination unreachable) and type 11 (time exceeded).

ping -c 10 192.168.1.1              # your router: should be <5 ms, near-zero jitter
ping -c 10 1.1.1.1                  # a big public DNS: typically 5-30 ms
ping -c 10 example.com              # a specific server, maybe far away

traceroute -n www.gov.au        # or any distant site

sudo tcpdump -i any -n icmp
# then, in another terminal:  ping -c 3 1.1.1.1

# ask for a UDP port nothing is listening on
sudo tcpdump -i any -n icmp &
nc -u -w1 127.0.0.1 9   # or any closed UDP port