Echo Request

In short: The outgoing ICMP message in a ping — asks the target device whether it’s reachable and can answer.

In more detail: An echo request contains an ID and sequence number, which the target device sends back unchanged in its echo reply — this allows the reply to be matched unambiguously to the original request, even if several pings run at the same time.

In Depth

The basis of the ping command

An echo request is ICMP type 8 and the basis of the ping command, which exists in practically identical form on every operating system — one of the oldest and most widely used network diagnostic tools of all:

$ ping -c 4 8.8.8.8
PING 8.8.8.8: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=13.9 ms

The name “ping” is a deliberate allusion to sonar technology used to locate submarines — a signal is sent out, and the distance (here: the network latency) can be deduced from the echo.

Payload and MTU diagnosis

Besides ID and sequence number, an echo request can also carry any payload, which the target device has to reflect back unchanged. Larger pings (via a flag, e.g. ping -s 1472) thus also test at the same time whether larger packets get through along the entire path without fragmentation problems — relevant for so-called MTU diagnosis (maximum transmission unit), in which the largest packet size that can cross a route without being split into smaller fragments is determined iteratively. Combined with the “Don’t Fragment” flag, this lets you find out specifically at which point in the transmission path an intermediate device’s too-small MTU value is causing problems.

What ping does NOT test

Important for troubleshooting: an echo request only tests pure network reachability at the ICMP level, not whether a particular service is actually running on the target device. A server can answer pings without problems and still not have a working web server (because the corresponding service has crashed), or the other way round: some well-secured servers block ICMP completely but run perfectly normally and answer HTTP requests without a hitch. “The server doesn’t respond to ping” is therefore not reliable proof of a real outage on its own — it only shows that ICMP replies aren’t coming, for whatever reason.

In practice: why many servers don’t answer

Many public servers now deliberately block echo requests with a firewall rule in order to hide from automated network scans and make the first, simplest reconnaissance method (“is anything reachable there at all?”) harder for attackers. This is one of the reasons why some more modern monitoring and uptime tools don’t rely primarily on ping but perform checks directly at the application level (e.g. a real HTTP request with an expected status code).

See also: Echo Reply, Ping, ICMP, Troubleshooting