What ping Actually Tells You
Everyone knows ping google.com. It sends an ICMP echo request and waits for a reply. But ping is a diagnostic instrument, not a yes/no switch. The default output hides most of what the tool can do. A single ping -c 4 8.8.8.8 tells you round-trip time and packet loss. That is about 10% of what you can extract.
The ICMP protocol gives you: latency (min/avg/max/mdev), packet loss percentage, Time-To-Live (TTL) at each hop, fragmentation behavior, and path MTU clues. You just need the right flags.
Flag 1: Packet Size (-s) — Finding MTU Problems
The default ping payload is 56 bytes (64 with headers). That tells you nothing about fragmentation. A common production issue: VPN tunnels or GRE encapsulation adds overhead, and suddenly 1500-byte packets get dropped while small pings work fine.
# Default small packet — works fine
ping -c 4 192.168.1.1
# 1500 byte payload — fails if MTU is wrong
ping -c 4 -s 1472 -M do 192.168.1.1The -M do flag sets the DF (Don't Fragment) bit. If the path can't handle that packet size, you get ping: local error: message too long, mtu=XXXX. This is how you find the real path MTU without guesswork. Start at 1500 and binary-search down.
When you see Frag needed and DF set (mtu = 1400), that is the network telling you exactly where the bottleneck is. Write that number down. It is usually VPN overhead, a misconfigured switch port, or a PPPoE link with 8 bytes of overhead you forgot about.
Flag 2: Flood Mode (-f) — Stress Testing
Flood mode sends packets as fast as the network and CPU allow. This is not a latency test — it is a packet loss test under load.
# WARNING: requires root. Sends hundreds of packets per second.
sudo ping -f -c 1000 10.0.0.1Each dot is a sent packet, each backspace is a received reply. If you see long runs of dots without backspaces, your link is dropping under load. Compare flood loss to normal loss. If normal ping shows 0% loss and flood shows 5%, you have a throughput problem — likely a saturated link, bufferbloat, or a switch dropping frames under backpressure.
Do not flood production servers without warning. A thousand packets per second of ICMP is not a lot of bandwidth, but some IDS systems will flag it as a flood attack and auto-block your IP.
Flag 3: TTL Analysis (-t) — Counting Hops
Every IP packet has a TTL field. Each router decrements it. The initial TTL varies by OS: Linux uses 64, Windows uses 128, many network devices use 255. The TTL in a ping reply tells you how many hops away the target is, and sometimes what OS it is running.
ping -c 1 8.8.8.8 | grep ttl
# 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 msTTL 118 means the reply passed through 10 routers (128 - 118 = 10) if the target is Windows, or 137 hops if the target is a router (255 - 118 = 137). Google's 8.8.8.8 starts at 128 (or sometimes 64 depending on which anycast node you hit), so 10 hops is reasonable. If you suddenly see TTL=60 when it was 118 yesterday, your route changed significantly.
Flag 4: Timestamp Option (-T) — Per-Hop Timing
Most people do not know ping has a timestamp mode that records wall-clock time at each hop. This is like traceroute with microsecond precision:
ping -c 1 -T tsonly 8.8.8.8Output shows TS: router1=12345678 router2=12345700. The delta between timestamps is hop latency. This is far more precise than traceroute because it uses the ICMP timestamp request, not UDP probes. Only some routers respond to it, but when they do, you get real per-hop latency without the noise of probe generation.
Flag 5: Adaptive Interval (-i) and Deadline (-w)
Slow pings with controlled intervals reveal periodic issues:
# One ping every 5 seconds for 10 minutes
ping -i 5 -w 600 10.0.0.1Plot the latency over time. If you see spikes every 60 seconds, that is a cron job saturating the server. Every 300 seconds — that is a monitoring check or garbage collection pause. Correlating ping patterns with time is how you find root cause without logging into the target machine.
For continuous monitoring, use ping -i 1 8.8.8.8 | while read line; do echo "$(date +%s) $line"; done > ping-log.txt and feed the log into your analysis tool. The OpsCheck Ping Test gives you this data from multiple geographic locations, which is more useful than a single-vantage-point test. After identifying a problematic host with ping, use the OpsCheck Port Scanner to check which services are actually reachable — ICMP replies do not guarantee TCP connectivity.
Real Scenario: Intermittent VoIP Call Drops
A client reported VoIP calls dropping every 10-15 minutes with no pattern. Standard ping showed 0% loss. The network team had already replaced the switch and the PBX.
The fix was a targeted ping diagnosis:
# Large packets, flood, over a long duration
ping -s 200 -i 0.2 -c 5000 10.0.1.50 > voip-ping.txt
awk '/time=/ {print $7}' voip-ping.txt | sed 's/time=//' | sort -n99.9% of replies were under 2ms. But exactly every 900 seconds, a single packet took 350ms. That matched the ISP's BGP convergence timer. The upstream router was flapping a route every 15 minutes, and the 350ms gap was enough to drop the RTP stream. Standard ping with default settings (56 bytes, 1-second interval) never caught it because the gap was shorter than the interval.
Moral: default ping answers "can I reach it?" — what you usually need to know is "what happens when I push it?"
Quick Reference Card
# Basic reachability
ping -c 4 target
# Path MTU discovery
ping -c 4 -s 1472 -M do target
# Flood stress test (root)
sudo ping -f -c 1000 target
# Long-duration sampling
ping -i 5 -w 600 target > log.txt
# Timestamp per-hop
ping -c 1 -T tsonly target
# Audible ping (hear the link)
ping -a target
# Record route (up to 9 hops)
ping -c 1 -R targetNext time you open a terminal to "just ping it," use at least -s and -c. The four extra keystrokes turn a yes/no check into a real measurement. For latency testing from multiple geographic vantage points, try the OpsCheck Ping Test which runs ICMP probes from globally distributed check nodes.