Linux Command Guide: `ping` - Network Connectivity Tester

1. Introduction

The ping command is a fundamental and widely used command-line utility for testing network connectivity between a host and a specified destination. It operates by sending ICMP (Internet Control Message Protocol) ECHO_REQUEST packets to the target host and waiting for ICMP ECHO_RESPONSE replies. The command’s output provides valuable information, including whether the destination is reachable, the round-trip time (RTT) for packets, and any packet loss.

ping is an indispensable tool for network administrators and users alike for diagnosing network issues, verifying host reachability, and getting a basic measure of network latency. Its simplicity and effectiveness make it a go-to tool for initial network troubleshooting. This guide provides an in-depth exploration of the ping command, its options, and practical applications. ping6 is the equivalent command for IPv6 networks. For simplicity, this guide will primarily refer to ping, but most options apply to ping6 as well, with specific IPv6-related notes included where relevant.

This tool is available on virtually all operating systems with a command-line interface, though this guide focuses on its usage in Linux environments, where it is typically provided by the iputils package. Its cross-platform nature and consistent core functionality make it a universal starting point for network diagnostics.

2. Basic Syntax

The basic syntax for the ping command is:


# Basic syntax of the ping command
$ ping [OPTION]... DESTINATION

[OPTION]...: These are optional flags that modify the behavior of the ping command. Options can control various aspects such as the number of packets to send, the interval between packets, the size of the packets, and more. Multiple options can be combined to tailor the command to specific needs. Options are typically prefixed with a single hyphen (e.g., -c), and some have arguments that follow immediately or after a space.
DESTINATION: This is the target you want to test connectivity with. It can be specified as a hostname (e.g., google.com) or an IP address (e.g., 8.8.8.8). If a hostname is used, ping will resolve it to an IP address using DNS before sending the packets. For IPv6, an IPv6 address (e.g., 2001:4860:4860::8888) can be used with ping or ping6, depending on the system.

When executed without options that limit the number of packets (e.g., -c), ping will continuously send ECHO_REQUEST packets to the DESTINATION at approximately one-second intervals until manually interrupted, typically by pressing Ctrl+C. This default behavior is useful for ongoing monitoring but can be adjusted with options for more specific tasks.

3. Core Use Cases with Examples

The primary use of ping is to check if a remote host is reachable and responsive. Below are several core use cases with examples, each demonstrating a common scenario for using ping. These examples assume a working network connection and do not require specific file or directory setups.

3.1. Pinging a Host by Name

This use case tests connectivity to a remote host by its hostname, relying on DNS to resolve the name to an IP address.


# Ping google.com to test connectivity using its hostname
$ ping google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=3 ttl=116 time=15.5 ms
^C  # User presses Ctrl+C to stop
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 14.800/15.166/15.500/0.300 ms

Explanation of Output:

PING google.com (142.250.196.142) 56(84) bytes of data.: Indicates the target hostname (google.com), its resolved IP address (142.250.196.142), and the size of the data being sent. Here, 56 bytes is the ICMP payload, and 84 bytes is the total IP packet size (56 data + 8 ICMP header + 20 IP header).
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms: This line appears for each successful reply. It shows:
- 64 bytes: The size of the received packet (typically 56 data + 8 ICMP header).
- lhr48s26-in-f14.1e100.net (142.250.196.142): The hostname and IP of the replying host (via reverse DNS).
- icmp_seq=1: Sequence number of the packet, useful for tracking order and loss.
- ttl=116: Time To Live, indicating the number of hops remaining in the packet’s journey.
- time=15.2 ms: Round-trip time in milliseconds.
--- google.com ping statistics ---: Summary of the session after interruption.
3 packets transmitted, 3 received, 0% packet loss, time 2003ms: Shows packets sent, received, loss percentage, and total duration.
rtt min/avg/max/mdev = 14.800/15.166/15.500/0.300 ms: Round-trip time statistics (minimum, average, maximum, and mean deviation).

3.2. Pinging a Host by IP Address

This bypasses DNS resolution, directly targeting an IP address, which can be faster and useful when DNS is unreliable.


# Ping 8.8.8.8 (Google Public DNS server) directly by IP
$ ping 8.8.8.8


PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=15.1 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 14.900/15.000/15.100/0.100 ms

Explanation: Similar to pinging by hostname, but no DNS resolution occurs, so the output directly references the IP (8.8.8.8). This is useful for isolating network issues from DNS problems.

3.3. Pinging the Localhost

This tests the local machine’s network stack by pinging the loopback address.


# Ping the loopback address to verify local network functionality
$ ping localhost
# Alternative command using the loopback IP
$ ping 127.0.0.1


PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.060 ms
^C
--- localhost ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.050/0.055/0.060/0.005 ms

Explanation: The very low RTT (e.g., 0.050 ms) is expected since packets don’t leave the local machine. This confirms the network stack and ICMP handling are functional.

3.4. Pinging an IPv6 Address

This tests connectivity to an IPv6 host, using ping6 or ping -6 depending on the system.


# Ping Google’s IPv6 DNS server
$ ping6 2001:4860:4860::8888
# Alternative syntax on some systems
$ ping -6 2001:4860:4860::8888


PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=118 time=10.2 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=118 time=10.5 ms
^C
--- 2001:4860:4860::8888 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.200/10.350/10.500/0.150 ms

Explanation: This confirms IPv6 connectivity. Note that ping6 may be required on older systems, while modern ping often supports IPv6 with the -6 flag.

3.5. Pinging an IPv6 Link-Local Address

Link-local addresses (starting with fe80::) require specifying the interface due to their link-specific scope.


# Ping an IPv6 link-local address on interface eth0
$ ping6 -I eth0 fe80::1234:5678:9abc:def0


PING fe80::1234:5678:9abc:def0(fe80::1234:5678:9abc:def0) from fe80::1%eth0 eth0: 56 data bytes
64 bytes from fe80::1234:5678:9abc:def0: icmp_seq=1 ttl=64 time=0.120 ms
64 bytes from fe80::1234:5678:9abc:def0: icmp_seq=2 ttl=64 time=0.130 ms
^C
--- fe80::1234:5678:9abc:def0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.120/0.125/0.130/0.005 ms

Explanation: Replace fe80::1234:5678:9abc:def0 with an actual link-local address on your network. The -I eth0 specifies the interface, as link-local addresses are only valid within a specific network segment.

4. Key Options Explained (with Examples)

ping offers numerous options to customize its behavior. Below are detailed explanations and examples for key options, ensuring no overlap with core use cases.

4.1. -c count (Packet Count)

Purpose: Stops after sending (and receiving replies for, if -w or -W is used with a deadline) a specified number of ECHO_REQUEST packets.

Syntax:


$ ping -c COUNT DESTINATION

Use Case: Ideal for sending a fixed number of pings instead of continuously pinging, useful for quick checks or automation in scripts.


# Send exactly 4 ping packets to google.com
$ ping -c 4 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=3 ttl=116 time=15.5 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=4 ttl=116 time=15.0 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 14.800/15.125/15.500/0.294 ms

Explanation: The command sends 4 packets and stops automatically, displaying replies and statistics.

4.2. -i interval (Interval Between Packets)

Purpose: Sets the interval in seconds between sending each packet (default is 1 second).

Syntax:


$ ping -i SECONDS DESTINATION

Use Case:

Increase interval (e.g., -i 5) to reduce network load.
Decrease interval (e.g., -i 0.2) for rapid testing (requires root for intervals < 0.2s).


# Ping every 3 seconds, send 2 packets
$ ping -i 3 -c 2 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 14.800/15.000/15.200/0.200 ms


# Ping 5 times per second (0.2s interval), requires sudo, send 3 packets
$ sudo ping -i 0.2 -c 3 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=3 ttl=116 time=15.5 ms
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 402ms
rtt min/avg/max/mdev = 14.800/15.166/15.500/0.300 ms

Explanation: The first example spaces pings 3 seconds apart; the second sends them every 0.2 seconds, requiring elevated privileges for such a short interval.

4.3. -s packetsize (Packet Data Size)

Purpose: Specifies the number of data bytes in the ICMP payload (default 56 bytes, resulting in 64 bytes including the 8-byte ICMP header).

Syntax:


$ ping -s BYTES DESTINATION

Use Case: Test network behavior with varying packet sizes, such as checking for MTU issues or fragmentation.


# Ping with minimal payload (0 data bytes)
$ ping -s 0 -c 2 google.com


PING google.com (142.250.196.142) 0(28) bytes of data.
8 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
8 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 14.800/15.000/15.200/0.200 ms


# Ping with 1000 data bytes
$ ping -s 1000 -c 2 google.com


PING google.com (142.250.196.142) 1000(1028) bytes of data.
1008 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.5 ms
1008 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=15.8 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 15.500/15.650/15.800/0.150 ms

Explanation: Total packet size is packetsize + 8 (ICMP header) + 20 (IP header). The first example sends minimal data (28 bytes total), while the second sends a larger payload (1028 bytes total).

4.4. -W timeout (Response Timeout for Individual Packets)

Purpose: Sets the time (in seconds) to wait for a response per packet. If no reply is received, the packet is marked as lost.

Syntax:


$ ping -W SECONDS DESTINATION

Use Case: Useful on high-latency networks to adjust how long ping waits before reporting loss.


# Wait 0.5 seconds per reply, send 3 packets
$ ping -W 0.5 -c 3 192.168.1.100


PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.200 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.210 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.190 ms
--- 192.168.1.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.190/0.200/0.210/0.010 ms

Explanation: If the target (e.g., 192.168.1.100) takes longer than 0.5 seconds to respond, packets would be reported as lost, even if the host is reachable.

4.5. -w deadline (Overall Deadline)

Purpose: Sets a total timeout (in seconds) for the ping command to run, regardless of packets sent or received.

Syntax:


$ ping -w SECONDS DESTINATION

Use Case: Limits the total duration, useful in scripts or time-sensitive checks.


# Ping for a maximum of 5 seconds
$ ping -w 5 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=3 ttl=116 time=15.5 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=4 ttl=116 time=15.0 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=5 ttl=116 time=15.3 ms
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 5005ms
rtt min/avg/max/mdev = 14.800/15.160/15.500/0.259 ms

Explanation: ping stops after 5 seconds, even if not interrupted manually, showing all packets sent within that time.

4.6. -I interface (Specify Source Interface or Address)

Purpose: Specifies the source interface or IP address for outgoing packets.

Syntax:


$ ping -I INTERFACE_NAME_OR_IP DESTINATION

Use Case: Test from a specific interface on a multi-homed host or required for IPv6 link-local addresses.


# Ping using eth1 as the source interface
$ sudo ping -I eth1 -c 2 8.8.8.8


PING 8.8.8.8 (8.8.8.8) from 10.0.0.5 eth1: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=15.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=15.2 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 15.000/15.100/15.200/0.100 ms

Explanation: Assumes eth1 has IP 10.0.0.5. sudo may be required for binding to specific interfaces.

4.7. -n (Numeric Output Only)

Purpose: Disables reverse DNS lookups, showing only IP addresses.

Syntax:


$ ping -n DESTINATION

Use Case: Speeds up output when DNS resolution is slow or unnecessary.


# Ping with numeric output only
$ ping -n -c 2 8.8.8.8


PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=15.1 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 14.900/15.000/15.100/0.100 ms

Explanation: No hostname (e.g., dns.google) appears, only the IP, reducing DNS lookup overhead.

4.8. -q (Quiet Output)

Purpose: Suppresses per-packet output, showing only summary statistics.

Syntax:


$ ping -q DESTINATION

Use Case: Useful in scripts for concise results.


# Quietly ping, sending 3 packets
$ ping -q -c 3 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 14.900/15.200/15.800/0.400 ms

Explanation: Only the initial line and summary are shown, omitting individual replies.

4.9. -f (Flood Ping)

Purpose: Sends packets as fast as replies are received or 100 times per second, whichever is greater.

Syntax:


$ sudo ping -f DESTINATION

Use Case: Stress testing networks (requires root).


# Flood ping localhost for 100 packets
$ sudo ping -f -c 100 localhost


PING localhost (127.0.0.1) 56(84) bytes of data.
............ # Rapid dots and backspaces
--- localhost ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99ms
rtt min/avg/max/mdev = 0.030/0.045/0.060/0.010 ms

Explanation: Dots represent sent packets; backspaces indicate replies. Use cautiously on owned networks only.

4.10. -b (Allow Pinging Broadcast Address)

Purpose: Permits pinging a broadcast address to elicit responses from local hosts.

Syntax:


$ ping -b BROADCAST_ADDRESS

Use Case: Basic network discovery (less effective than nmap).


# Ping broadcast address 192.168.1.255
$ ping -b -c 3 192.168.1.255


PING 192.168.1.255 (192.168.1.255) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.300 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=0.310 ms
--- 192.168.1.255 ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.300/0.305/0.310/0.005 ms

Explanation: Responses depend on network configuration; many hosts ignore broadcast pings.

4.11. -R (Record Route)

Purpose: Attempts to record the route taken by packets.

Syntax:


$ ping -R DESTINATION

Use Case: Basic path tracing (limited and often unreliable).


# Attempt to record route
$ ping -R -c 1 google.com


PING google.com (142.250.196.142) 56(124) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.0 ms
RR: 192.168.1.100
    192.168.1.1
    (incomplete route)
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.000/15.000/15.000/0.000 ms

Explanation: Limited to 9 hops; many routers disable this feature.

4.12. -t ttl (Set IP Time To Live)

Purpose: Sets the TTL for outgoing packets.

Syntax:


$ ping -t TTL_VALUE DESTINATION

Use Case: Test reachability within a hop limit.


# Ping with TTL of 5
$ ping -t 5 -c 2 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Time to live exceeded
From 192.168.1.1 icmp_seq=2 Time to live exceeded
--- google.com ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms

Explanation: If the target is beyond 5 hops, intermediate routers report TTL exceeded.

4.13. -v (Verbose Output)

Purpose: Shows additional ICMP packet types received.

Syntax:


$ ping -v DESTINATION

Use Case: Detailed troubleshooting of ICMP responses.


# Ping with verbose output
$ ping -v -c 2 192.168.1.100


PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.200 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.210 ms
--- 192.168.1.100 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.200/0.205/0.210/0.005 ms

Explanation: Additional ICMP messages (e.g., “Destination Unreachable”) would be detailed if received.

4.14. -L (Suppress Loopback of Multicast Packets)

Purpose: Prevents loopback of multicast packets to the sender.

Syntax:


$ ping -L MULTICAST_ADDRESS

Use Case: Multicast testing without local echo.

4.15. -B (Do Not Allow ping to Change Source Address)

Purpose: Locks the source address, preventing kernel changes.

Syntax:


$ ping -B DESTINATION

Use Case: Ensures consistent source IP on dynamic networks.

4.16. -l preload (Send Preload Packets)

Purpose: Sends an initial burst of packets without waiting for replies.

Syntax:


$ sudo ping -l PRELOAD_COUNT DESTINATION

Use Case: Quick burst for testing (root required for > 3).


# Send 5 packets immediately
$ sudo ping -l 5 -c 10 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
...
--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9008ms

Explanation: Sends 5 packets at once, then proceeds normally.

4.17. -p pattern (Specify Padding Pattern)

Purpose: Fills the packet payload with a hex pattern.

Syntax:


$ ping -p HEX_PATTERN DESTINATION

Use Case: Diagnose data-specific network issues.


# Use pattern ff
$ ping -p ff -c 2 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Explanation: Payload is filled with 0xFF bytes for testing.

4.18. -Q tos (Set Quality of Service)

Purpose: Sets QoS/DSCP bits in the IP header.

Syntax:


$ ping -Q TOS_VALUE DESTINATION

Use Case: Test QoS policy enforcement.


# Set ToS to 0x10 (low delay)
$ sudo ping -Q 0x10 -c 2 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Explanation: Requires root for some values; tests network QoS handling.

4.19. -A (Adaptive Ping)

Purpose: Adapts interval to RTT, keeping one unanswered probe at most.

Syntax:


$ ping -A DESTINATION

Use Case: Dynamic monitoring.


# Adaptive ping
$ ping -A -c 10 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
...
--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 152ms

Explanation: Interval adjusts to RTT, minimum 200ms for non-root.

4.20. -M hint (Path MTU Discovery Hint)

Purpose: Configures Path MTU Discovery (do, want, dont).

Syntax:


$ ping -M HINT -s BYTES DESTINATION

Use Case: Test MTU limits.


# Test with DF bit and 1472 bytes
$ ping -M do -s 1472 -c 2 google.com


PING google.com (142.250.196.142) 1472(1500) bytes of data.
1480 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.5 ms
1480 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=15.8 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Explanation: do sets DF bit; packet loss occurs if MTU is lower.

4.21. -U (Print Full User-to-User Latency)

Purpose: Shows user-to-user latency (older behavior, less used).

Syntax:


$ ping -U DESTINATION

Use Case: Historical latency measurement including DNS.

4.22. -V (Show Version and Exit)

Purpose: Displays ping version.

Syntax:


$ ping -V

Use Case: Check utility version.


$ ping -V


ping from iputils 20211215

Explanation: Outputs version info and exits.

4.23. -S sndbuf (Set Socket Send Buffer)

Purpose: Sets socket send buffer size.

Syntax:


$ ping -S BUFFER_SIZE DESTINATION

Use Case: Advanced tuning for high-speed pings.

4.24. -T timestamp option (Set IP Timestamp Options)

Purpose: Adds timestamp options to IP header (tsonly, tsandaddr, tsprespec).

Syntax:


$ ping -T TIMESTAMP_OPTION DESTINATION

Use Case: Advanced diagnostics (rarely supported).


# Get timestamps only
$ ping -T tsonly -c 1 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.0 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Explanation: Timestamps are rarely returned by modern routers.

5. Combining Options

Options can be combined for tailored behavior. Below are practical examples.

5.1. Custom Packet Count, Interval, and Size


# Send 5 packets, 0.5s interval, 100-byte payload
$ ping -c 5 -i 0.5 -s 100 google.com


PING google.com (142.250.196.142) 100(128) bytes of data.
108 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
108 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=14.8 ms
108 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=3 ttl=116 time=15.5 ms
108 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=4 ttl=116 time=15.0 ms
108 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=5 ttl=116 time=15.3 ms
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 14.800/15.160/15.500/0.259 ms

Explanation: Combines a fixed count, custom interval, and larger payload.

5.2. Flood with Preload


# Flood ping with 10 preload packets, stop after 500
$ sudo ping -f -l 10 -c 500 example.com


PING example.com (93.184.216.34) 56(84) bytes of data.
.......... # Rapid dots and backspaces
--- example.com ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 499ms

Explanation: Initial burst followed by flood, requires root.

5.3. Quiet with Timeout


# Quiet ping, 10 packets, 2s timeout per packet
$ ping -q -c 10 -W 2 192.168.1.1


PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9008ms
rtt min/avg/max/mdev = 0.190/0.205/0.220/0.015 ms

Explanation: Minimal output with specific reply wait time.

6. Handling Special Cases

Special cases for ping involve network-specific scenarios rather than file-related issues.

6.1. Firewalls Blocking ICMP

Firewalls can block ICMP packets, causing ping to fail even if the host is reachable via other protocols.


# Attempt to ping a firewalled host
$ ping -c 4 10.0.0.1


PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Explanation: Check firewall rules if no replies are received.

6.2. Permissions for Advanced Options

Options like -f or low -i values require root privileges.


# Attempt flood ping without sudo
$ ping -f -c 10 localhost


ping: -f flag requires superuser privileges


# Successful flood ping with sudo
$ sudo ping -f -c 10 localhost


PING localhost (127.0.0.1) 56(84) bytes of data.
.......... # Rapid dots and backspaces
--- localhost ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9ms

Explanation: Use sudo for restricted options.

6.3. Network Address Translation (NAT)

Pinging hosts behind NAT involves targeting the public IP, not private IPs externally.


# Ping NAT public IP
$ ping -c 2 203.0.113.1


PING 203.0.113.1 (203.0.113.1) 56(84) bytes of data.
64 bytes from 203.0.113.1: icmp_seq=1 ttl=58 time=20.0 ms
64 bytes from 203.0.113.1: icmp_seq=2 ttl=58 time=20.2 ms
--- 203.0.113.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Explanation: Internal IPs require VPN or port forwarding.

6.4. Non-Responding Hosts

Some hosts ignore ICMP for security.


# Ping a host that blocks ICMP
$ ping -c 4 silenthost.example


PING silenthost.example (198.51.100.1) 56(84) bytes of data.
--- silenthost.example ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Explanation: Failure doesn’t confirm the host is down.

7. Frequently Asked Questions (FAQ)

Below are common questions from forums, validated and expanded with examples.

7.1. What Does “Request Timed Out” or 100% Packet Loss Mean?

Answer: No replies were received within the timeout period.


# Example of timeout
$ ping -c 4 10.0.0.1


PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Explanation: Causes include host down, firewall, or network issues.

7.2. Why Does `ping` Fail but Websites Work?

Answer: The host may block ICMP but allow HTTP/HTTPS.


# Ping fails
$ ping -c 4 example.com


PING example.com (93.184.216.34) 56(84) bytes of data.
--- example.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Explanation: Test with curl example.com to confirm.

7.3. Can `ping` Measure Bandwidth?

Answer: No, it measures latency and loss, not bandwidth.


# Ping for latency
$ ping -c 4 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
...
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

Explanation: Use iperf3 for bandwidth tests.

7.4. What’s the Difference Between `ping` and `traceroute`?

Answer: ping tests end-to-end; traceroute shows the path.


# Compare outputs
$ ping -c 2 google.com
$ traceroute google.com

Explanation: traceroute lists hops, unlike ping’s single-target focus.

7.5. Why “Destination Host Unreachable”?

Answer: No route to the host or no ARP response.


# Unreachable host
$ ping -c 2 10.0.0.5


PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
--- 10.0.0.5 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms

Explanation: Router or local host reports no path.

7.6. Is Continuous Pinging Okay?

Answer: Yes for testing, but avoid high-frequency on public servers.


# Continuous ping
$ ping google.com

Explanation: Use responsibly to avoid abuse.

7.7. Why Does RTT Vary?

Answer: Network conditions fluctuate.


# Variable RTT
$ ping -c 5 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=1 ttl=116 time=15.2 ms
64 bytes from lhr48s26-in-f14.1e100.net (142.250.196.142): icmp_seq=2 ttl=116 time=20.0 ms
...
rtt min/avg/max/mdev = 15.200/17.500/20.000/1.800 ms

Explanation: Congestion or routing changes cause variance.

7.8. What Does “Time to Live Exceeded” Mean?

Answer: Packet’s TTL reached zero before destination.


# Low TTL
$ ping -t 2 -c 2 google.com


PING google.com (142.250.196.142) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Time to live exceeded
From 192.168.1.1 icmp_seq=2 Time to live exceeded
--- google.com ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms

Explanation: Indicates hop limit reached.

8. Conclusion

The ping command is a fundamental diagnostic tool for anyone working with networks. Its simplicity in testing basic reachability, combined with options to control packet count, size, interval, and more, makes it invaluable for initial troubleshooting steps. While it doesn’t provide a complete network picture, the information it yields—primarily round-trip time and packet loss—is often the first indicator of network health or problems. For deeper analysis, tools like traceroute, mtr, or iperf3 can complement ping. Always use aggressive features like flood ping responsibly and with appropriate permissions.

9. ping Command: Reference Table of Key Options

Option(s)	Description	Example Command	Use Case
(none)	Send ICMP ECHO_REQUESTs continuously	`$ ping google.com`	Basic connectivity test
`-c count`	Stop after sending count packets	`$ ping -c 5 8.8.8.8`	Send a fixed number of pings
`-i interval`	Wait interval seconds between packets (default 1s)	`$ ping -i 0.5 server.example.com`	Adjust ping frequency (sub-second needs root)
`-s packetsize`	Specify data bytes to send (default 56)	`$ ping -s 1024 host.local`	Test with different packet sizes, MTU issues
`-W timeout`	Wait time per packet response, in seconds	`$ ping -W 2 slowhost.com`	Set individual packet reply timeout
`-w deadline`	Total timeout in seconds before exit	`$ ping -w 10 mydevice`	Limit total ping duration
`-I interface`	Set source interface or IP address	`$ ping -I eth1 google.com`	Test from specific interface
`-n`	Numeric output only (no DNS lookups)	`$ ping -n 8.8.4.4`	Speed up output, avoid DNS issues
`-q`	Quiet output (summary only)	`$ ping -q -c 10 server`	Get only final statistics, script-friendly
`-f`	Flood ping (rapid sending)	`$ sudo ping -f localhost`	Stress test (use cautiously, needs root)
`-b`	Allow pinging broadcast address	`$ ping -b 192.168.1.255`	Discover hosts on local network
`-R`	Record route (basic path tracing)	`$ ping -R -c 1 target`	Limited route tracing
`-t ttl`	Set IP Time To Live	`$ ping -t 3 remotehost`	Test reachability within hop count
`-v`	Verbose output (more ICMP details)	`$ ping -v host.example.net`	Detailed ICMP error messages
`-A`	Adaptive ping (interval adapts to RTT)	`$ ping -A -c 20 server`	Dynamic ping flow based on latency
`-M hint`	Path MTU Discovery hint (do, want, dont)	`$ ping -M do -s 1472 target`	Test MTU and fragmentation
`-p pattern`	Fill packet with hex pattern	`$ ping -p aabb -c 3 host`	Diagnose data-dependent issues
`-Q tos`	Set QoS/DSCP bits	`$ sudo ping -Q 0x20 target`	Test QoS policies
`-V`	Show version and exit	`$ ping -V`	Check utility version
`--help`	Display help message and exit	`$ ping --help`	Quick usage information

Linux Command Guide: ping - Network Connectivity Tester

1. Introduction

2. Basic Syntax

3. Core Use Cases with Examples

3.1. Pinging a Host by Name

3.2. Pinging a Host by IP Address

3.3. Pinging the Localhost

3.4. Pinging an IPv6 Address

3.5. Pinging an IPv6 Link-Local Address

4. Key Options Explained (with Examples)

4.1. -c count (Packet Count)

4.2. -i interval (Interval Between Packets)

4.3. -s packetsize (Packet Data Size)

4.4. -W timeout (Response Timeout for Individual Packets)

4.5. -w deadline (Overall Deadline)

4.6. -I interface (Specify Source Interface or Address)

4.7. -n (Numeric Output Only)

4.8. -q (Quiet Output)

4.9. -f (Flood Ping)

4.10. -b (Allow Pinging Broadcast Address)

4.11. -R (Record Route)

4.12. -t ttl (Set IP Time To Live)

4.13. -v (Verbose Output)

4.14. -L (Suppress Loopback of Multicast Packets)

4.15. -B (Do Not Allow ping to Change Source Address)

4.16. -l preload (Send Preload Packets)

4.17. -p pattern (Specify Padding Pattern)

4.18. -Q tos (Set Quality of Service)

4.19. -A (Adaptive Ping)

4.20. -M hint (Path MTU Discovery Hint)

4.21. -U (Print Full User-to-User Latency)

4.22. -V (Show Version and Exit)

4.23. -S sndbuf (Set Socket Send Buffer)

4.24. -T timestamp option (Set IP Timestamp Options)

5. Combining Options

5.1. Custom Packet Count, Interval, and Size

5.2. Flood with Preload

5.3. Quiet with Timeout

6. Handling Special Cases

6.1. Firewalls Blocking ICMP

6.2. Permissions for Advanced Options

6.3. Network Address Translation (NAT)

6.4. Non-Responding Hosts

7. Frequently Asked Questions (FAQ)

7.1. What Does “Request Timed Out” or 100% Packet Loss Mean?

7.2. Why Does ping Fail but Websites Work?

7.3. Can ping Measure Bandwidth?

7.4. What’s the Difference Between ping and traceroute?

7.5. Why “Destination Host Unreachable”?

7.6. Is Continuous Pinging Okay?

7.7. Why Does RTT Vary?

7.8. What Does “Time to Live Exceeded” Mean?

8. Conclusion

9. ping Command: Reference Table of Key Options

Linux Command Guide: `ping` - Network Connectivity Tester

7.2. Why Does `ping` Fail but Websites Work?

7.3. Can `ping` Measure Bandwidth?

7.4. What’s the Difference Between `ping` and `traceroute`?