ICMP
Internet Control Message Protocol · Network layer
IP has no way of telling a sender that a packet was dropped. ICMP is the companion protocol that does: time exceeded, destination unreachable, fragmentation needed. It also carries echo request and reply, which is what ping uses. Traceroute is built entirely out of deliberately provoked ICMP errors.
Understand these first
- Why does this protocol exist?
- IP silently drops packets it cannot deliver. Without some way to say so, every failure would look identical to every other from the sender's point of view.
- Which problem does it solve?
- Tell a sender that something went wrong with a packet, and give enough of the original back that the sender can work out which one.
- Who participates?
- Any router or host that cannot process a packet, reporting back to whoever sent it. Also any two hosts, for echo request and reply.
- Which layer uses it?
- Network layer, alongside IP rather than above it. Carried in IP with protocol number 1, but it is not a transport — it has no ports.
- What does it depend on?
- IPv4 to carry it, and a routing path back to the original sender.
- What depends on it?
- ping and traceroute entirely. Path MTU discovery depends on fragmentation-needed messages arriving, which is why filtering ICMP breaks connections in ways nobody expects.
- What state does each participant maintain?
- Almost none. Echo uses an identifier and a sequence number so a sender can match replies to requests, and that matching is the sender's own state. Error messages are fire-and-forget.
- Which fields matter?
- type / code — Together they say what happened: 8/0 echo request, 0/0 reply, 11/0 time exceeded, 3/3 port unreachable, 3/4 fragmentation needed.
- identifier / sequence — Only in echo. They let one host run several pings at once and still match every reply to its request.
- quoted original — An error carries the IP header and first 8 bytes of the packet that caused it — enough for the sender to identify the connection, which is what makes the error actionable.
- What does normal behaviour look like?
- Echo request out, echo reply back, one per sequence number. Or an error arriving from a router in the middle of the path, quoting the packet that triggered it.
- What does failure look like?
- Silence. A filtered network drops both the original and the ICMP, so the sender sees nothing at all — which is a different diagnosis from an explicit rejection and looks the same to the application.
- How can I prove the diagnosis from packets?
- Read the type and code, then open the quoted original inside the error. It names the exact packet that failed, and where it failed is the router that sent the error.
- How does it interact with the rest of the stack?
- ICMP is IP's feedback channel and TCP's most useful bystander: a port-unreachable or fragmentation-needed message changes what TCP does next. Filtering ICMP wholesale is a common and damaging mistake for exactly that reason.
Guided course — 4 lessons
Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.
- 1ICMP-01Ping, and the Difference Between Silence and RefusalWhy an explicit error is worth more than a timeout≈10 min · 7 steps · 4 questions · guidedNot started
- 2ICMP-02Traceroute: Making Routers Identify ThemselvesA tool built entirely out of deliberate failures≈10 min · 7 steps · 3 questions · guided · after icmp-ping-and-errorsNot started
- 3ICMP-03Errors, Information, and the Quoted PacketReading an ICMP message as evidence rather than as noise≈10 min · 7 steps · 3 questions · guided · diagnosis lab · after icmp-ping-and-errorsNot started
- 4ICMP-04Path MTU Discovery, and the Black HoleA process built entirely on an error message arriving≈10 min · 7 steps · 3 questions · guided · diagnosis lab · after icmp-errors-and-informationNot started
Troubleshooting labs — 2
A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.
Packet explorer — 7 scenarios, no coaching
Three echo requests and three replies. Watch the identifier stay constant while the sequence number counts up — together they are the only way a host can match a reply to its request.
ICMP silently filteredThe same ping, but the server's policy discards ICMP without answering. Requests arrive and nothing comes back — which looks exactly like the host being switched off.
Port unreachable — an explicit 'nothing is listening'A datagram arrives for a UDP port with no socket bound. The host answers with an error quoting the datagram that caused it. Compare this with the silence of the filtered scenario.
Time exceededA probe with TTL 1 dies at the first router, which reports it and thereby names itself. One packet, one error, and you have learned the identity of a device you never addressed.
Traceroute across two routersProbes with increasing TTL. Each router in turn discards one and reports the expiry, revealing its own address. The destination answers with a different error, which is how the trace knows to stop.
Path MTU discoveryA large datagram with Don't Fragment set meets a narrow link. The router reports the MTU it could have used — the message a sender needs to size its packets correctly.
Troubleshooting: the path-MTU black holeIdentical to the PMTUD scenario, except a firewall drops the router's error on the way back. Small packets work, large ones vanish, and nothing explains why. This is the classic argument against blanket ICMP filtering.
Reference material
The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.
That you can read an ICMP message as evidence rather than as noise.