Ping, ICMP and what "unreachable" really means

What ping measures

Each probe is an ICMP Echo Request (type 8 in IPv4, type 128 in IPv6). The target answers with an Echo Reply (type 0, or 129 in IPv6). For each reply you get:

Our Ping Check sends four echo requests from each of several locations worldwide, using the Globalping probe network, and reports every reply. Testing from several continents at once tells you whether a problem is global or affects only some paths.

Reading TTL

Each router decrements the TTL by one. Senders start from a fixed value, commonly 64 (Linux, macOS, many network devices), 128 (Windows) or 255 (some routers). A reply arriving with TTL 116 most likely started at 128, so it crossed about 12 hops. That's a useful hint about the remote operating system or a sudden routing change. It isn't proof, because the starting value is configurable.

Reading round-trip time

RTT is bounded by physics: light in fibre covers roughly 200 km per millisecond, so a round trip across the continental US can't be much under 50–60 ms. Sustained RTT far above the distance-based minimum points to congestion, a long detour in routing, or a busy host. Note that routers handle ping at low priority, so a slow reply from a router isn't necessarily slow traffic through it.

Reading packet loss

• 0% loss: healthy.
• Occasional single losses: common, and often caused by ICMP rate limiting on a router or host rather than real loss. Repeat the test before acting.
• Consistent partial loss (25–50%): points to congestion or a flapping link somewhere on the path, or deliberate ICMP rate limiting at the destination. Compare with a TCP test.
• 100% loss: the host is down, the path is broken, or ICMP is filtered. See the next section.

When ICMP is blocked

Many environments drop ping by default:

• Cloud platforms often block inbound ICMP unless a security rule allows it.
• Corporate firewalls and some hosting providers drop ICMP at the edge.
• Windows Defender Firewall blocks inbound echo requests on many profiles.

That's why, when no location gets an ICMP reply, our tool also tries an HTTPS connection to port 443 from our own server. If the host answers, it's up and reachable, even though it ignores ping. If the probe network is unavailable, the tool runs only that HTTPS check and labels it clearly. HTTPS checks don't include bytes or TTL, so those columns show a dash.

If neither ICMP nor TCP gets a reply, the host may still be up behind a firewall that only allows specific sources. Test from inside the network, or check the service directly.

Don't block all ICMP on your own network

Dropping every ICMP message is a common hardening step that causes subtle breakage:

• Path MTU discovery relies on ICMP "fragmentation needed" (IPv4) and "packet too big" (IPv6) messages. Block them, and large packets silently vanish. Typical symptoms are sites that hang mid-load, and VPNs or email with attachments that fail.
• IPv6 depends on ICMPv6 for neighbour discovery and more. RFC 4890 lists which ICMPv6 types must be allowed.

It's reasonable to rate-limit echo requests, or block them from the internet if policy requires it. Allow the error messages the network needs.

Beyond ping

• traceroute / tracert shows each hop and where latency or loss begins.
• mtr combines ping and traceroute over time, which is better for intermittent loss.
• A TCP connect test to the real service port tells you what users experience.

From the field: ICMP Echo Requests, or pings, are essential tools in your network troubleshooting toolkit. One caveat is if you have a device that does not respond to ping checks and mistaking them as being down. Cross check any ping failures to rule out false negatives.

Sources

• RFC 792: Internet Control Message Protocol
• RFC 4443: ICMPv6
• RFC 4890: Recommendations for filtering ICMPv6 messages in firewalls
• RFC 1191: Path MTU discovery