ICMP: ping, traceroute, and control messages

What ICMP carries, how ping and traceroute work, and why blocking ICMP entirely is harmful.

Why this matters

"The server doesn't respond to ping" and "traceroute shows stars" come up in every other networking issue. Half of these complaints are false alarms: the host is alive, it's just hidden from ping. The opposite story, where ICMP is blocked entirely, breaks things that at first glance have nothing to do with ICMP: large uploads and git push hang without a single error. In this lesson we'll look at what ICMP reports, and learn to read ping and traceroute without jumping to the wrong conclusion.

A control protocol, not a transport

ICMP (Internet Control Message Protocol) is a control protocol for messages about the fate of IP packets. It doesn't carry application data, and it has no ports. Its messages answer questions like "is the destination unreachable?", "did the time to live expire?", "are you alive?".

The main message types:

• echo request / echo reply: "are you alive?" and the answer; ping is built on these;
• destination unreachable: the packet didn't make it. The message's code gives the reason: no route, UDP port closed, blocked by a firewall, packet doesn't fit without fragmentation;
• time exceeded: the packet's TTL ran out; traceroute is built on this.

An ICMP error message goes back to the sender of the original packet. It carries the start of that packet inside it (the IP header and the first bytes of data), so the sender knows which connection the error belongs to.

ping

ping sends echo request and measures the time until echo reply:

$ ping -c 3 10.0.0.5
64 bytes from 10.0.0.5: icmp_seq=1 ttl=63 time=0.41 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=63 time=0.38 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=63 time=0.40 ms

Ping answers the question "is the host alive, and what's the latency to it." But silence doesn't prove the host is dead: echo request is often blocked by a firewall while the service on a TCP port keeps working. If ping fails, check the port too, for example with curl or wget for a web server.

traceroute

Every IP packet has a TTL (time to live): a counter that each router decrements by one. When it reaches zero, the packet is dropped, and an ICMP time exceeded message goes back to the sender. In IPv6 the same field is called Hop Limit.

traceroute uses this on purpose: it sends packets with TTL=1, then TTL=2, and so on. Each next router along the path kills its own packet and reveals itself with a time exceeded reply. This is how the list of hops to the target is built.

$ traceroute -n example.com
 1  192.168.1.1     0.8 ms
 2  10.20.0.1       3.1 ms
 3  * * *
 4  203.0.113.7    12.4 ms

What traceroute probes with depends on the system. On Linux, traceroute by default sends UDP datagrams to high ports (starting at 33434), and the target responds with ICMP port unreachable: this is how traceroute knows it arrived. traceroute -I sends ICMP echo request, and tracert on Windows only knows how to do that. If the target blocks echo request, that kind of traceroute will end in stars all the way to hop 30, even though the UDP version reaches it.

A * * * line is a hop that sent back no response at all. If there are lines with addresses below it, everything's fine: the hop simply doesn't send time exceeded, and packets do pass through it. A broken path looks different: after some hop, the stars continue to the end.

Why you can't block all of ICMP

The temptation to "block ICMP so no one can ping us" breaks more than it protects. Path MTU Discovery runs over ICMP. MTU (maximum transmission unit) is the largest IP packet that fits through a given link in the network. TCP sends packets with the DF (don't fragment) flag, and if there's a link with a smaller MTU along the path, a router drops the packet and sends the sender an ICMP destination unreachable message with the code fragmentation needed (in IPv6, a separate Packet Too Big message). The sender shrinks its packets and sends them again.

Block that message, and the sender never learns about the problem. It keeps repeating the same large packet until the connection times out.

This looks like black magic: ping works, small requests work, but a large POST, a download, or a git push hangs. If you need to hide from ping, block echo request specifically, not the whole protocol.

Common mistakes

• Treating a host as dead because it doesn't respond to ping. Check the service's port: a firewall might have cut off echo request.
• Treating a * * * in the middle of traceroute as a broken path. If there are responses further along, traffic is passing through that hop.
• Reading traceroute without accounting for the method. UDP traceroute and traceroute -I (or tracert on Windows) can show a different picture on the same path.
• Blocking ICMP entirely in firewall rules. This breaks Path MTU Discovery, and large packets are lost without errors.
• Blocking ICMP only in the incoming direction and assuming that's enough. A router sends fragmentation needed itself, which is outgoing traffic, and a rule on outgoing ICMP breaks PMTUD just the same.

What you'll need for the tasks

• docker exec <container> <command>: the lab's commands run inside the lab environment's containers, no sudo needed;
• ping -c 2 -W 2 <address>: two echo requests, wait up to 2 seconds for a response;
• traceroute -n -w 2 <address>: a route without DNS names, wait 2 seconds for each response;
• wget -T 5 -q -O - http://<address>/<path>: download a page and print it, 5-second timeout;
• ip route: the routing table, the default via line shows the default gateway;
• nft list ruleset: nftables firewall rules. With the -a flag (nft -a list ruleset) each rule shows its handle, used to remove it: nft delete rule <family> <table> <chain> handle <N>;
• tcpdump -n -i any 'tcp or icmp': listen to traffic on all interfaces;
• the sections "traceroute" and "Why you can't block all of ICMP".

The next lesson is NAT: how a private network reaches the internet through one address.