PING

Ping is not proof that an application is healthy. It is a controlled ICMP probe that answers a narrower and more useful question: can this source send an IP packet to that destination and receive a matching reply on the return path?

Used well, ping establishes the first facts in an investigation:

• local interface and gateway behavior
• Layer 3 reachability
• return-path reachability
• round-trip latency
• visible packet loss
• packet-size and Path MTU behavior
• source-address or interface-specific path differences

Used carelessly, ping creates false confidence. ICMP can be filtered, rate-limited, deprioritized, NAT-translated, routed differently from application traffic, or answered by a different node behind load balancing or anycast.

This guide treats ping as the first instrument in a diagnostic chain, not the whole investigation.

What Ping Proves

A successful ping usually proves all of the following for that specific probe:

It does not prove:

• DNS resolution, unless you intentionally pinged a name and verified the resolved address
• TCP or UDP port reachability
• TLS handshake success
• HTTP, database, SMTP, or DNS application health
• equal behavior for larger packets
• equal behavior from another source address
• equal behavior during load, failover, or congestion

Investigation Order

Start with the smallest fact, then widen the test. Do not jump from "ping failed" to "server down."

Core Ping Commands

Use these as the baseline on Linux. macOS and Windows differ; verify flags before copying commands between platforms.

Privileged or disruptive options require care:

Reading Replies

Example:

64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=12.8 ms

Interpret it precisely:

Common failure messages:

MTU and Fragmentation

MTU problems often look like application failure: SSH works, small HTTP requests work, but TLS, file transfer, database replication, or VPN traffic hangs.

For IPv4 over standard Ethernet, the common test payload is:

ping -M do -s 1472 8.8.8.8

Why 1472? IPv4 header is 20 bytes and ICMP header is 8 bytes. 1472 + 20 + 8 = 1500.

For tunnels, reduce the payload by the tunnel overhead. Do not guess the final value; binary-search it:

ping -M do -s 1472 target
ping -M do -s 1400 target
ping -M do -s 1360 target
ping -M do -s 1320 target

Loss, Latency, and Jitter

Do not treat all packet loss equally.

Ping reports round-trip behavior. It does not show one-way delay or direction-specific loss. For that, you need synchronized telemetry, flow data, packet capture, or active probes from both sides.

Source and Interface Testing

Multi-homed systems make basic ping ambiguous. A host with management, storage, overlay, and production interfaces may succeed from one source and fail from another.

Use source selection when the question depends on policy:

ping -I eth1 10.10.10.10
ping -I 192.0.2.10 10.10.10.10

Investigate source-specific differences with:

• ip route get <target> from <source>
• firewall policy for that source subnet
• NAT rules
• reverse-path filtering
• asymmetric routing
• VRF or network namespace context

IPv6 Ping

IPv6 changes two important behaviors.

First, fragmentation is not handled by routers in the same way as IPv4. Path MTU Discovery matters more, and blocking ICMPv6 breaks real traffic.

Second, link-local addresses require an interface scope:

ping -6 2001:4860:4860::8888
ping fe80::1%eth0

For IPv6 failures, check:

• Router Advertisements
• default route
• neighbor discovery
• ICMPv6 filtering
• source-address selection
• DNS records: A versus AAAA

When Ping Is the Wrong Tool

Move to the next tool when the question is no longer "can this ICMP probe return?"

Traceroute, Tracepath, and MTR

These tools deserve their own focused treatment because they answer different questions.

• traceroute maps a likely hop sequence by increasing TTL or hop limit. It may use UDP, ICMP, or TCP depending on platform and flags.
• tracepath is useful on Linux for path discovery and MTU hints without requiring root privileges.
• mtr combines repeated probing with hop-by-hop visibility, useful for intermittent loss and WAN degradation.

Critical caveat: loss shown at an intermediate hop is not automatically forwarding loss. Routers often rate-limit ICMP responses to themselves while forwarding transit traffic normally. Trust loss only when it begins at a hop and continues to later hops or the final destination.

The detailed page for these tools should cover probe types, ECMP effects, MPLS behavior, private hops, cloud firewalls, false hop loss, and TCP traceroute for application paths.

Field Playbooks

Use these patterns to keep investigations short.

Series Map

This master page links to deeper articles in the series instead of repeating them:

• Network Diagnostic Commands Beyond Ping - traceroute, tracepath, MTR, transport probes, DNS, TLS, packet capture, and combined troubleshooting workflows.
• ICMP and ping internals - ICMP types, codes, TTL, return path, rate limits, and filtering.
• Ping options reference - Linux, macOS, and Windows option differences.
• Path MTU and fragmentation - DF behavior, tunnels, MSS clamping, and black holes.
• Loss, latency, jitter, and microbursts - interpreting patterns without overclaiming.
• Traceroute, tracepath, and MTR - path discovery and false-loss interpretation.
• Advanced network probes - fping, arping, nping, hping3, nc, curl, dig, openssl, and swaks.

The linked diagnostics page now covers the non-ping command chain. The remaining pages can be created as focused articles, one topic at a time, to keep each page technically dense and non-repetitive.

Operating Rule

Ping is the right first command when the first question is reachability. It is the wrong final answer when the real question is application behavior, policy behavior, path selection, MTU, or time-dependent loss.

Use ping to establish facts. Use the next tool to test the next layer.