ICMP Ping

What is ping / ICMP?

Ping is the ubiquitous network-diagnostic tool that answers “is this host reachable, and how long does a round trip take?” It works using ICMP (Internet Control Message Protocol) — a helper protocol of the internet used for diagnostics and error signaling rather than carrying application data. Ping sends an ICMP Echo Request to a target host; if the host is reachable and responds, it returns an ICMP Echo Reply, and ping measures the round-trip time (RTT) and reports any packet loss. It’s the first thing nearly everyone reaches for to check basic connectivity, and understanding what it does (and doesn’t) tell you is fundamental network literacy.

What ICMP is for, and what ping actually measures

ICMP is a control and diagnostic protocol, not a data-transport one — it’s how the network reports conditions and errors. Beyond Echo Request/Reply (ping), ICMP carries messages like “Destination Unreachable” (no route to the host, or the port is closed), “Time Exceeded” (a packet’s TTL hit zero — which is exactly what traceroute exploits, sending packets with increasing TTLs to map each hop along the path), and others. So ICMP underpins two everyday tools: ping (reachability + RTT to a destination) and traceroute/tracert (the path and per-hop latency to a destination). What ping measures is worth being precise about: a successful ping tells you the host is network-reachable at the IP layer and gives you latency and packet-loss figures — useful for spotting whether a host is up, whether the network path is lossy, and how far away (in time) it is. What ping does not tell you is whether the application is working: a server can happily reply to pings while its web service, database, or API is completely down (ping hits the OS network stack, not your application). This is a constant source of confusion — “I can ping it, so why is the site down?” — and the answer is that reachability at the IP layer says nothing about whether the service on top is healthy.

The realities: why ping often “fails” on healthy hosts

The most important practical lesson is that ICMP is frequently blocked, filtered, or rate-limited, so “ping fails” does not reliably mean “host is down.” Many networks, firewalls, and cloud security groups drop ICMP by default or by policy — sometimes for security reasons (ICMP has been used in reconnaissance, and in attacks like ping floods, Smurf amplification, and the historical “ping of death”), sometimes just as default hardening. In cloud environments specifically, you often must explicitly allow ICMP in security groups/firewall rules for ping to work at all, so a freshly-launched instance that’s perfectly healthy may not respond to ping until you permit ICMP. Consequently, a failed ping to a public server (say, a major website that blocks ICMP) tells you nothing about its status. Routers and hosts also rate-limit or deprioritize ICMP (generating replies is low-priority work), so ping RTT can appear worse than actual application latency, and intermittent ICMP loss doesn’t necessarily indicate real traffic loss. The correct mental model: ping/ICMP is a useful first-pass reachability and latency check, but it’s a blunt instrument — for real service health you check the actual application (an HTTP request, a database connection, a proper health-check endpoint), and for diagnosing paths you use traceroute (understanding it too relies on ICMP that may be filtered mid-path, causing the * * * hops you often see). The recurring mistakes: concluding a host is down because ping fails (when ICMP is just blocked), concluding a service is up because ping succeeds (when only the network stack is responding), and forgetting to allow ICMP in cloud firewall rules before testing.

What people get wrong

• “Ping fails so the host is down” — ICMP is widely blocked or rate-limited (especially in clouds, where you must explicitly allow it); a failed ping often means filtering, not an outage.
• “Ping succeeds so the service is up”: ping reaches the OS network stack, not your application — a server can answer pings while its web/database service is completely broken.
• Using ping as a health check — real service health needs an application-level check (HTTP request, DB connection, health endpoint); ICMP only tells you about IP-layer reachability and latency.

Primary source: RFC 792: Internet Control Message Protocol