ICMP and diagnostics

Why it matters

When something is unreachable, the first two tools anyone reaches for are ping and traceroute, and both are built on ICMP. Reading their output correctly separates "the network is broken" from "that router just does not answer pings", which saves hours. ICMP is also load-bearing in ways people forget: firewalls that block all of it cause large transfers to hang mysteriously, as the encapsulation lesson showed.

The idea

ICMP (Internet Control Message Protocol) carries errors and diagnostics for IP. It rides inside IP packets but has no ports; each message has a type and code. Routers and hosts send ICMP to report problems with packets they could not deliver, and tools send it deliberately to probe the network.

ping

ping sends echo requests and times the replies, reporting round-trip time and loss. It answers "is layer 3 working between here and there, and how far away is it?" Its limits matter as much as its answers: many hosts and cloud security groups block echo by default, so no reply does not mean down; ICMP may be deprioritised by busy routers, so ping latency is not exactly application latency; and a successful ping says nothing about whether port 443 is open or the application healthy.

traceroute

traceroute maps the path by exploiting TTL. It sends packets with TTL 1, 2, 3 and so on; each router where the TTL hits zero drops the packet and returns "time exceeded", revealing its address and the round-trip time to that hop. The final destination answers with a reply (or "port unreachable" for UDP probes), ending the trace.

Reading traceroute output honestly

1. 1

   Asterisks on one hop, later hops fine

   That router does not answer or rate-limits ICMP. It is forwarding your traffic; ignore it.
2. 2

   Latency jumps at one hop and stays high

   A long link (an ocean crossing) or a congested link at that point. If later hops return to normal, the jump was the router's slow ICMP reply, not real delay.
3. 3

   Loss at one hop only

   Usually ICMP rate limiting on that router. Loss that starts at a hop and continues to the destination is real.
4. 4

   Trace stops and never resumes

   Traffic is being dropped beyond the last answering hop: a firewall, a routing black hole, or the destination filtering probes.
5. 5

   Use mtr

   mtr combines ping and traceroute over many rounds, showing loss and latency per hop over time, which makes these patterns obvious.

Don't block it all

Blanket ICMP blocking is a common security reflex that causes real breakage. Dropping "fragmentation needed" or "packet too big" breaks path MTU discovery and causes black holes for large packets; dropping "unreachable" turns fast failures into long timeouts. Reasonable policy allows the error types needed for correct operation, rate-limits echo, and blocks nothing it does not understand. IPv6 depends on ICMPv6 even more, for neighbour discovery and address configuration, so blocking it breaks IPv6 entirely.

Trade-offs

ICMP gives the network a way to report problems and gives operators cheap probes, at the cost of a channel that attackers can use for reconnaissance and floods. Rate-limiting and selective filtering keep the benefits; blanket blocking trades a small security gain for confusing failures.

In an interview

Use it in debugging narratives: "Ping to the host works, so routing and layer 3 are fine; curl to 443 times out, so it is a security group, a listener or the app. A traceroute from the client side shows where packets stop when ping fails." And as a design note: "We allow ICMP packet-too-big through the firewall so path MTU discovery keeps working over the VPN."