The ICMP protocol is fundamentally a control plane for IP networks, not a data plane.
Let’s see this in action. Imagine you’re on your laptop and you want to check if a server at 192.168.1.100 is reachable. You’d typically type ping 192.168.1.100.
$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.543 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.498 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.512 ms
^C
--- 192.168.1.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.498/0.517/0.543/0.018 ms
What’s happening here? Your ping command isn’t sending IP packets that carry your application data. Instead, it’s crafting a very specific type of IP packet: an Internet Control Message Protocol (ICMP) packet. Specifically, it’s sending an ICMP "Echo Request." The 192.168.1.100 server, if it’s up and configured to respond to pings (most are by default), will receive this request and send back an ICMP "Echo Reply." The ping utility then measures the round-trip time (RTT) for these messages. The ttl (Time To Live) field in the IP header of the reply packet tells you how many router hops the packet took to get back to you.
Now, let’s look at traceroute (or tracert on Windows). If you run traceroute 192.168.1.100:
$ traceroute 192.168.1.100
traceroute to 192.168.1.100 (192.168.1.100), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.450 ms 0.320 ms 0.270 ms
2 10.0.0.1 (10.0.0.1) 15.123 ms 14.987 ms 15.050 ms
3 some.isp.router (203.0.113.1) 25.678 ms 25.710 ms 25.800 ms
4 192.168.1.100 (192.168.1.100) 26.000 ms 26.150 ms 26.050 ms
traceroute uses ICMP too, but in a clever way. It sends out UDP packets (by default on Linux/macOS) with an ever-increasing Time To Live (TTL) value, starting with 1.
- When the TTL is 1, the first router on the path receives the UDP packet, decrements the TTL to 0, and discards it. Crucially, before discarding it, it sends back an ICMP "Time Exceeded" message to your source IP address. This tells
traceroutethe IP address of that first router. traceroutethen sends another UDP packet, this time with TTL set to 2. This packet reaches the second router, where the TTL becomes 1. The second router decrements it to 0, discards the packet, and sends back an ICMP "Time Exceeded" message. This reveals the second router’s IP.- This process repeats, incrementing the TTL by one each time, until the UDP packet finally reaches the destination. The destination, not expecting a UDP packet on that port, will typically send back an ICMP "Destination Unreachable" message (specifically, "Port Unreachable"). This ICMP message indicates that
traceroutehas successfully mapped the entire path.
The core problem ICMP solves is network diagnostics and error reporting without interfering with the actual data flow. Imagine if every dropped packet or routing error had to be handled by your web browser or FTP client. The internet would be chaos. ICMP provides a standardized, low-level mechanism for network devices to communicate operational status and problems.
The most surprising thing about ICMP is that it often gets blocked by firewalls, which can lead to confusion because some diagnostics that rely on ICMP will then fail, making it seem like the network is broken when it’s just the diagnostic tool that’s being thwarted. For example, many stateless firewalls will happily let your application data packets (TCP/UDP) through but will drop ICMP "Time Exceeded" or "Destination Unreachable" packets. This means traceroute might show a path with asterisks (* * *) for certain hops, not because the router is down, but because it’s not allowed to send the ICMP error message back to you.
The key levers you control with ICMP-based tools like ping and traceroute are the destination IP address or hostname, the source interface (if you have multiple network cards), and the packet size. For traceroute, you can also specify the protocol (UDP, ICMP, or TCP) and the destination port for the probes, which can be useful for troubleshooting around firewalls that filter specific protocols or ports.
The next concept you’ll likely run into is understanding how TCP and UDP operate on top of IP, and how their own error reporting mechanisms (like TCP retransmissions) differ from ICMP’s network-level notifications.