> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Linux Ping Options Every Network Engineer Should Know - URL: https://www.pinglabz.com/linux-ping-options/ - Published: 2026-07-08T20:53:22.000Z - Updated: 2026-08-19T18:26:45.000Z - Description: The iputils ping flags engineers actually use: -c/-i/-q for jitter, -s/-M for MTU, -D for timestamps, and the -I flag that fixes confusing IPv6 failures. - Author: Jaime - Tags: Ping, Linux, Networking, Troubleshooting, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/ping/). ping is the first command in the Linux networking toolkit and rarely the last one you need. This article is part of the [complete guide to Linux networking commands](https://www.pinglabz.com/linux-networking-commands/), which indexes the rest: `ip`, `ss`, `dig`, `tcpdump` and the firewall tools, all with real lab output. ## 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](https://www.pinglabz.com/ping-sweep/)). ## 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](https://www.pinglabz.com/ping-mtu-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](https://www.pinglabz.com/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](https://www.pinglabz.com/ipv6/). ## The Field Reference \-c 100 -i 0.01 -q Fast link-quality sample: loss + jitter in one second (root for i < 0.2). \-s 1372 -M do MTU probe: payload + 28 = wire size, DF set. Router replies with the limiting MTU. \-t 1, -t 2, -t 3... Manual traceroute: each TTL exposes one hop via Time Exceeded. \-w 3 / -W 1 \-w bounds total runtime (script-safe); -W bounds per-reply wait (fast sweeps). \-D (+ -O) Epoch timestamps per reply, and a line per missed reply. Overnight monitoring into a log file. \-6 -I ens224 Force IPv6 and pin the interface. Mandatory for link-local, lifesaving on multi-homed hosts. ## 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](https://www.pinglabz.com/ping-sweep/), or head back to the [complete ping guide](https://www.pinglabz.com/ping/). When ping has told you everything it can, the next command is usually `traceroute`, `ss` or `tcpdump`. All of them are indexed, with real captures, in the [complete guide to Linux networking commands](https://www.pinglabz.com/linux-networking-commands/).