Use ping to Separate Local, IPv4 and IPv6 Network Faults
You will finish with a short, repeatable ping workflow that tells you whether a host answers, which address family works, and whether packet loss or delay is the visible problem. The examples use ping from iputils-ping version 3:20240117-1ubuntu0.1, reporting iputils 20240117.
The route
Jump straight to the step you need, or tick off Done means at the end.
Allow about ten minutes. You need a shell, the iputils-ping package, and a destination you are authorised to test. Ordinary echo tests do not need sudo. Some specialised modes need extra privileges or capabilities, and a remote host or firewall may refuse ICMP even when its services are healthy.
1. Confirm the installed command
Check the binary and package before comparing output with an example. This is read-only:
$ command -v ping
/usr/bin/ping
$ ping -V
ping from iputils 20240117
$ dpkg-query -W -f='${Package} ${Version}\n' iputils-ping
iputils-ping 3:20240117-1ubuntu0.1
The aliases ping4 and ping6 are also installed here, but the three local manpages contain the same command documentation. Modern iputils has the IPv4 and IPv6 modes in one ping program. Use -4 or -6 when the address family is part of the question.
Checkpoint
If ping -V reports a different release, use ping -h and the local ping(8) page as the authority for your host.
2. Test the local network stack first
Start with loopback. It checks the local kernel and the ping path without depending on a switch, route or remote firewall:
$ ping -c 2 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.0xx ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.0xx ms
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time ...ms
rtt min/avg/max/mdev = .../..../.../... ms
The exact times and final line vary. A successful run exits with status 0. Make the status visible when using the test in a script:
$ ping -c 2 127.0.0.1 >/tmp/ping-local.log 2>&1
$ printf 'exit status: %s\n' "$?"
exit status: 0
Do not treat a remote failure as proof that the local interface is broken. If loopback fails, stop and investigate the local host before moving further away.
3. Test one destination with a bounded run
Replace HOST_OR_IP with a name or address you are allowed to probe. -c 4 sends four requests and then exits, so it is safer for a manual check than leaving an unbounded ping running:
$ ping -c 4 HOST_OR_IP
PING HOST_OR_IP (...address...) 56(84) bytes of data.
64 bytes from ...address...: icmp_seq=1 ttl=... time=... ms
...
--- HOST_OR_IP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time ...ms
rtt min/avg/max/mdev = .../..../.../... ms
Each reply gives a sequence number, the received packet's TTL, and a round-trip time. The summary calculates packet loss and minimum, average, maximum and mdev values. A high mdev means the round-trip times vary; it is a clue for an unstable path, not a diagnosis by itself.
Use -n when you want numeric output and no reverse DNS lookup. This avoids a distracting name-resolution delay:
$ ping -n -c 4 HOST_OR_IP
Checkpoint
Record the destination, address family, loss percentage and average time. Repeat the same bounded command before changing several variables at once.
4. Compare IPv4 and IPv6 deliberately
A hostname can resolve to both families, and the chosen path may hide a family-specific fault. Run both tests separately:
$ ping -4 -c 4 HOSTNAME
$ ping -6 -c 4 HOSTNAME
-4 forces IPv4 and -6 forces IPv6. A successful IPv4 test does not establish that IPv6 routing, filtering or address configuration works. Conversely, a failed IPv6 test does not explain an IPv4 failure.
For a link-local IPv6 address, include the interface scope. Replace eth0 with the interface shown by your own host:
$ ping -6 -c 4 'fe80::1234%eth0'
Without a scope, the same link-local address may be ambiguous when more than one interface can reach it. The -I option can also select an interface, address or VRF, but the percent notation keeps this small test easy to inspect.
5. Bound waiting time when a host may not answer
-W sets the time to wait for a response when there have been no responses; -w sets an overall deadline regardless of how many requests have been sent. Use both when a diagnostic or script must finish promptly:
$ ping -n -c 4 -W 2 -w 6 HOST_OR_IP
The values are seconds, and this iputils build accepts decimal values. With -c and -w together, the command can finish when the count is answered or when the deadline expires. A host that sends no replies produces a non-zero result and a summary showing loss.
The exit status is useful but narrow: 0 means the run met its reply condition, 1 means no replies, or fewer than the requested count arrived before a deadline, and 2 means another error. A status of 1 is not proof that a machine is powered off. Firewalls, ICMP policy, routing and asymmetric paths can all matter.
6. Keep the safety boundary clear
Do not start with flood mode, broadcast probing or an automated loop. The manpage warns that ping can impose load, and flood mode can send at very short intervals. -b permits a broadcast address, while -f changes the rate substantially. Use either only with explicit operational authority, a controlled target and a clear stop condition. There is no configuration to undo for the bounded examples above: stop the command with Ctrl-C if necessary, and no service or network setting is changed.
Most users can use ICMP datagram sockets without elevation. Raw-socket operation, IPv6 Node Information queries with -N, and some identifier settings can require CAP_NET_RAW or a host policy that permits the socket. Adding sudo does not make a remote firewall answer, so only use elevated privileges when your local error identifies a privilege requirement.
Done means
- You confirmed the local iputils version and package.
- Loopback answered with a bounded count and status 0.
- You tested the intended destination without leaving an unbounded process running.
- You compared
-4and-6when address-family behaviour mattered. - You used
-n,-Wand-wto reduce DNS distraction and runaway waits. - You treated packet loss as evidence about ICMP reachability, not a complete host-health verdict.