Skip to content

ping

ping is probably the first networking command most people ever type, and also one of the most commonly misread. It's worth seeing exactly what it does at the ICMP level, because half of what makes ping results confusing in practice comes from treating it as a simple yes/no reachability check when it's actually reporting something more specific.

Echo Request and Echo Reply

ping sends an ICMP Echo Request (Type 8, Code 0) to a target address and waits for an ICMP Echo Reply (Type 0, Code 0) sent back. That's the entire mechanism — there's no connection, no handshake, nothing beyond one message out and, if everything works, one message back.

ping -c 4 example.com

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=12.4 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=11.9 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=12.7 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=56 time=12.1 ms

--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 11.900/12.275/12.700/0.298 ms

-c 4 limits ping to four requests and then stops; without it, ping on Linux keeps sending once per second until interrupted with Ctrl+C. icmp_seq is a sequence number, incrementing by one on every request, and ttl is the destination's reported Time To Live at the moment its reply left — both fields come from an identifier-and-sequence pair the Echo Request/Reply messages carry specifically so a sender with several requests in flight at once can match each reply back to the request that triggered it, the same matching problem ARP and TCP each solve differently at their own layers.

What time actually measures

The time field is a round-trip time (RTT) — the interval from when the Echo Request left this machine to when its matching Echo Reply arrived back, measuring the full there-and-back journey in one number. This is worth being precise about, because latency properly refers to one-way delay — the time for a packet to travel in a single direction — and RTT is roughly double that, not the same measurement under a different name. ping's summary line calls it rtt for exactly this reason; nothing about the tool measures one-way delay at all, since that would require a synchronized clock on both ends to timestamp departure and arrival separately, which plain ICMP has no mechanism for.

Reading the summary line: avg gives a typical RTT, min and max bound how much it varied across the four requests, and mdev (mean deviation) is a quick measure of that variation's spread — a small mdev means consistent timing; a large one, relative to avg, points at an unstable path worth investigating further rather than a single average number that quietly hides a lot of jitter.

TTL on the reply is a distance clue, not just a diagnostic field

The ttl value in each reply line is worth a second look. IP's Time To Live field starts at a value the sending host's operating system sets by default — commonly 64 on Linux, 128 on Windows, 255 on many network devices — and every router the packet crosses decrements it by exactly one. The value ping reports is what's left by the time the packet reaches you, so working backward from a commonly used starting value gives a rough hop count: a reply with ttl=56, if the remote host started at 64, crossed roughly eight routers along the way. This won't be exact — it depends on the remote host's specific starting value, which you generally can't confirm directly — but a used-up TTL that's dropped much further than expected for a supposedly nearby destination is a real clue that traffic is taking a longer path than assumed.

When ping fails, it usually isn't the network

A common instinct on seeing ping fail is to conclude the target is down. That's often true, but far from always — plenty of servers, especially anything behind a firewall configured with any real intent, deliberately drop ICMP Echo Requests while every other service on that same machine works perfectly normally:

ping -c 2 a-web-server-with-icmp-blocked.example

PING a-web-server-with-icmp-blocked.example (203.0.113.10) 56(84) bytes of data.

--- a-web-server-with-icmp-blocked.example ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1023ms

curl -sI https://a-web-server-with-icmp-blocked.example

HTTP/1.1 200 OK

100% packet loss on ping, followed immediately by a perfectly healthy HTTP response from the same host, is the single clearest sign this is a firewall rule specifically targeting ICMP rather than any real outage — the web server is plainly up and answering. Blocking ICMP Echo is a deliberate, common security posture (it denies a trivially easy way to enumerate which hosts on a network are alive), and treating a blocked ping as proof of downtime, without checking the actual service the host is meant to provide, is one of the most common mistakes made when diagnosing a "server down" report.

Common mistakes

  • Concluding a host is down purely from ping failing. ICMP Echo is very often filtered deliberately; check the actual service the host provides (HTTP, SSH, whatever's relevant) before assuming an outage.
  • Calling RTT "latency." They're related by roughly a factor of two, not interchangeable — this matters anywhere a round trip gets counted, including reasoning about handshake or request timing elsewhere in this course.
  • Reading one ping result as conclusive. A single request can be affected by a transient blip that four or five in a row would immediately reveal as an outlier rather than a trend — mdev exists precisely to make that spread visible.

Practice exercises

  1. Run ping -c 5 against a nearby server and a distant one (a different continent, if you can pick one), and compare both the average RTT and the ttl values reported.
  2. A monitoring alert fires because a server stopped responding to ping. Using the scenario above, describe the next single command you'd run before declaring an outage, and why.
  3. Explain, in one sentence, why "RTT" and "latency" aren't the same measurement — and what additional capability a tool would need to measure latency directly instead of inferring it from a round trip.

ping tells you whether a destination answers, and roughly how long the round trip took. It says nothing about where along the path things go wrong when they do — that's a different tool, built on a completely different ICMP message type: traceroute.

Sources