Linux Ping Options Every Network Engineer Should Know

The iputils ping that ships with every modern Linux distribution has dozens of flags, and most engineers use exactly two of them (-c and nothing else). Hidden in the rest are a jitter meter, an MTU prober, a flood tester, and an interface selector that solves one of the most confusing IPv6 failures you will hit. This article walks the flags that earn their place in a network engineer's muscle memory, each demonstrated live against a three-router Cisco lab. It is part of the PingLabz ping guide.

The Everyday Set: -c, -i, -q, -w

-c (count) stops after N probes instead of running forever. -i (interval) sets seconds between probes (default 1). -q (quiet) suppresses the per-probe lines and prints only the summary. Combine all three and you get a dense link-quality sample in under a second:

j@lab:~$ sudo ping -c 100 -i 0.01 -q 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.

--- 3.3.3.3 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 990ms
rtt min/avg/max/mdev = 2.992/3.581/6.581/0.402 ms

One hundred packets, one second, and the two numbers that matter: loss (0%) and mdev (0.4 ms of jitter). Note the sudo: unprivileged users cannot set intervals below 0.2 seconds (a rate-limiting guardrail, since fast pings are effectively load generators).

-w (deadline) is subtly different from -c: it bounds the total runtime in seconds, regardless of how many replies arrive. ping -w 3 host is the right shape for scripts and health checks, because it can never hang:

j@lab:~$ ping -w 3 3.3.3.3
--- 3.3.3.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Its sibling -W (timeout) sets how long to wait for each individual reply. -W 1 is the difference between a subnet sweep that takes 4 minutes and one that takes seconds (more on that in the ping sweep article).

Size and MTU: -s and -M

-s sets the ICMP payload size (default 56; add 28 bytes of headers for the wire size), and -M do sets the DF bit so nothing on the path may fragment the packet. Together they turn ping into an MTU probe. Against a lab path with a 1400-byte link two hops out:

j@lab:~$ ping -c 3 -s 1400 -M do 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 1400(1428) bytes of data.
From 10.0.12.2 icmp_seq=1 Frag needed and DF set (mtu = 1400)

The router names the limiting MTU in its error. The complete method, including the payload math and the Cisco-side equivalent, has its own article: testing MTU with ping and the DF bit.

Hop Probing: -t

-t caps the outgoing TTL. The probe dies at hop N and that router introduces itself with a Time Exceeded message:

j@lab:~$ ping -c 3 -t 1 3.3.3.3
From 192.168.99.1 icmp_seq=1 Time to live exceeded

j@lab:~$ ping -c 3 -t 2 3.3.3.3
From 10.0.12.2 icmp_seq=1 Time to live exceeded

TTL 1 finds the first hop, TTL 2 the second. This is traceroute's core mechanism exposed as a single flag (background in how ping works).

Timestamps for Correlation: -D

-D prefixes each reply with a Unix epoch timestamp:

j@lab:~$ ping -c 3 -D 3.3.3.3
[1783543025.242112] 64 bytes from 3.3.3.3: icmp_seq=1 ttl=253 time=4.34 ms
[1783543026.243890] 64 bytes from 3.3.3.3: icmp_seq=2 ttl=253 time=4.45 ms
[1783543027.245589] 64 bytes from 3.3.3.3: icmp_seq=3 ttl=253 time=4.34 ms

Indispensable when you leave a ping running overnight into a log file and need to line up the moment of loss against syslog, interface counters, or a change window. Pair it with -O, which prints a line for each missed reply instead of staying silent, and you have a poor man's availability monitor.

Load Testing: -f (Handle With Care)

-f (flood) sends as fast as replies return (or 100 pps minimum), printing a dot for each unanswered probe. Watching the dots pile up during a flood is a live packet-loss visualization:

j@lab:~$ sudo ping -f -c 500 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 504ms
rtt min/avg/max/mdev = 0.807/0.923/2.714/0.140 ms, ipg/ewma 1.009/0.918 ms

500 packets in half a second, zero loss, and a bonus metric: ipg (inter-packet gap). Flood requires root, and it is a lab and maintenance-window tool. Pointing it at production infrastructure you do not own is somewhere between rude and a security incident (that address is a lab router's loopback, not the public resolver).

IPv6 and the Interface Trap: -6 and -I

-6 forces IPv6. Here is the failure mode that confuses everyone the first time. The lab host has two NICs, and R1's IPv6 address lives off the second one:

j@lab:~$ ping -6 -c 3 2001:db8:99::1
From fd64:f725:df42:4f01:b1ba:d16b:bd2e:dde9 icmp_seq=1 Destination unreachable: Address unreachable

Address unreachable, even though the router is right there and configured correctly. The giveaway is the From address: the kernel sourced the probe from the wrong interface (the management NIC), where no route to 2001:db8:99::/64 exists. Bind the ping to the correct interface with -I and it works instantly:

j@lab:~$ ping -6 -c 3 -I ens224 2001:db8:99::1
PING 2001:db8:99::1 (2001:db8:99::1) from 2001:db8:99::100 ens224: 56 data bytes
64 bytes from 2001:db8:99::1: icmp_seq=1 ttl=64 time=4.81 ms

--- 2001:db8:99::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

On multi-homed hosts, and especially with IPv6 link-local addresses (which always need %interface or -I), source and interface selection is half the battle. More IPv6 fundamentals live in the IPv6 guide.

The Field Reference

Key Takeaways

• -c 100 -i 0.01 -q gives you loss and jitter (mdev) in one second; sub-0.2s intervals need root.
• -w is the script-safe flag: it bounds runtime no matter what the network does.
• -s plus -M do turns ping into a path MTU prober.
• -D timestamps make overnight captures correlatable with logs.
• When IPv6 ping says "Address unreachable" from an address you didn't expect, check the source interface and reach for -I.
• Flood ping is a lab tool. Own the target or don't send it.

Continue with ping sweeps for host discovery, or head back to the complete ping guide.