Linux ping Command: Test Network Connectivity and Diagnose Problems

Learn how to use Linux ping to test IP reachability, measure latency and packet loss, distinguish DNS problems, and troubleshoot local and remote network failures.

The Linux ping command is a standard network troubleshooting utility. It tests whether a destination responds over an IP network and reports basic timing and packet-loss information.

Ping is useful for checking a local device, a default gateway, or a remote host. However, a successful ping does not prove that an application is working. A host can reply to ICMP messages while refusing SSH, HTTP, DNS, or another application connection. Conversely, a host may be reachable while its firewall blocks ping.

How ping works

ICMP means Internet Control Message Protocol. It carries network control and diagnostic messages rather than ordinary application data.

When you run ping, Linux sends an ICMP Echo Request to an IP address. If the destination is reachable and permits these messages, it sends an ICMP Echo Reply back. Ping measures the time between sending the request and receiving its matching reply.

This elapsed time is called round-trip time (RTT). It is commonly used as a practical measure of network latency, or delay. No reply does not always mean that the host is powered off. The request or reply may be blocked by a firewall, filtered by a router, rate-limited, or disabled by the destination.

Basic ping syntax

ping [options] destination

The destination can be an IPv4 address, an IPv6 address where supported by the installed ping implementation, or a hostname. A hostname must first be translated into an IP address by DNS or another local name-resolution mechanism.

ping 192.168.198.130

This example tests a private IPv4 address. On most Linux systems, ping sends approximately one request per second and continues until you interrupt it.

Reading ping output

A successful result commonly looks similar to this:

PING 192.168.198.130 (192.168.198.130) 56(84) bytes of data.
64 bytes from 192.168.198.130: icmp_seq=1 ttl=64 time=0.742 ms
64 bytes from 192.168.198.130: icmp_seq=2 ttl=64 time=0.689 ms
64 bytes from 192.168.198.130: icmp_seq=3 ttl=64 time=0.711 ms

--- 192.168.198.130 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 0.689/0.714/0.742/0.022 ms

Field	Meaning	Diagnostic value
`bytes`	The size of the returned ICMP message, including the payload and protocol overhead as displayed by the implementation.	Shows that a reply containing data was received. It is not the same as the payload size selected with `-s`.
`icmp_seq`	The sequence number of the Echo Request.	Helps match replies to requests and can reveal missing sequence numbers.
`ttl`	Time To Live, an IP header value received in the reply.	It limits packet forwarding, but it is not a complete route analysis. Use a route-tracing tool for path details.
`time`	The round-trip time, normally shown in milliseconds.	Helps assess latency and changes in delay.
Packet-loss summary	The number of transmitted probes, received replies, and the percentage without replies.	Shows whether probes were lost during the test.
Minimum, average, maximum, and variation	Summary latency statistics. Linux commonly labels variation as `mdev`.	Helps compare normal delay with spikes or inconsistent performance.

In the example, the destination is shown in the opening line. Each reply has a sequence number, a byte count, a received TTL, and a time value. The final summary reports three transmitted packets, three received packets, no packet loss, and very low latency.

Stopping a continuous ping with Ctrl+C

Press Ctrl+C in the terminal to interrupt a normally continuous ping. Linux then prints the final packet-loss and latency summary.

ping 192.168.198.130
# Press Ctrl+C after collecting enough replies

Use several replies rather than judging the network from a single response. A nearby, healthy LAN commonly has very low latency, often close to 1 ms, while distant networks usually have higher delay.

Limit requests with -c

The -c option sets the number of Echo Requests to send. The command exits after the requested number of probes, making it useful for quick checks and scripts.

ping -c 4 192.168.198.130

This command sends four requests and then prints the final summary without requiring manual interruption.

Option	Purpose	Example
`-c count`	Stop after a specified number of requests.	`ping -c 4 192.168.198.130`
`-s size`	Set the ICMP data payload size in bytes.	`ping -s 1000 192.168.198.130`

Change the ICMP payload size with -s

The -s option selects the size of the ICMP data payload in bytes. For example:

ping -s 1000 192.168.198.130

Larger requests can help investigate packet-size or MTU-related behavior. MTU, or Maximum Transmission Unit, is the largest packet size a network link can carry without fragmentation constraints. Use larger payloads carefully on production networks because they create more traffic and may interact with filtering, fragmentation, or path-MTU behavior.

Use ping to isolate network faults

A layered test sequence narrows the problem by checking nearby dependencies before testing a distant destination:

Test the local host or a suitable local interface where appropriate.
Ping the default gateway, which is the router used to reach networks outside the local subnet.
Ping another host on the same local network.
Ping a remote IP address.
If the IP test works but a hostname test fails, investigate DNS name resolution separately.

ping <default-gateway-address>
ping <another-local-host>
ping <remote-ip-address>

If the gateway test fails, examine the local interface, cable or Wi-Fi connection, IP address, subnet configuration, and default route. If local hosts respond but remote IP addresses do not, the likely problem is the default gateway, a router, a missing route, an upstream network, or external filtering.

If an IP address responds but its hostname cannot be resolved or ping cannot start because name resolution fails, the network path may be healthy and DNS may be the problem. DNS, the Domain Name System, translates hostnames into IP addresses.

ping example-host
ping 192.0.2.25

The address 192.0.2.25 belongs to a documentation-reserved IPv4 range and is shown only as an instructional example, not as a guaranteed live target. In a real test, replace it with the known IP address you are investigating. If the IP test succeeds while the hostname test fails, check DNS servers, resolver configuration, hostname records, and local hosts-file mappings. If both fail, continue investigating connectivity and routing.

Observed result	Likely meaning	Next check
Replies from a local host	The local path and that host are responding to ICMP.	Test the default gateway and another local host before testing remotely.
Local hosts respond but remote IPs do not	A gateway, router, route, upstream, or external-connectivity issue is possible.	Verify the local IP, subnet, default route, and gateway; then trace the route if needed.
An IP address responds but a hostname does not	DNS or another name-resolution configuration is likely involved.	Check resolver settings, DNS availability, records, and local hostname mappings.
No replies are received	The destination may be unreachable, the local network may be disconnected, or ICMP may be filtered.	Test the local interface and gateway, confirm the address and route, and check firewall policy.
Replies show high latency or packet loss	Congestion, Wi-Fi interference, an overloaded device, an unstable path, or ICMP rate limiting may be involved.	Run multiple finite tests against local and remote targets and compare results over time.

Practical limitations and safe interpretation

Ping measures ICMP reachability and RTT; it does not test whether a TCP or UDP service is listening.
A successful ping does not confirm that SSH, HTTP, DNS, or another application port is available.
A failed ping does not prove that the host or application is unavailable because ICMP may be blocked or ignored.
Evaluate packet loss and high latency across multiple probes and in context. A single lost reply may not indicate a persistent fault.
Compare nearby and remote targets. A healthy nearby LAN generally has very low latency, whereas distant networks commonly have higher delay.
Some devices prioritize application traffic over ICMP or rate-limit diagnostic replies, so ping results may not represent every type of traffic.

Common troubleshooting patterns

A local host responds, but an external IP does not

Possible causes include an incorrect or unreachable default gateway, a router or upstream outage, a missing route, or external filtering. Ping the gateway, verify local addressing and the default route, and use a route-tracing tool to identify where the path stops.

An IP address responds, but its hostname does not

Check DNS resolver configuration, DNS-server availability, the hostname record, and local hosts-file entries. Continuing to test the known IP helps separate name resolution from network transport.

Ping receives no replies

Check the local interface and gateway, confirm the destination address, and verify routing. Then consider whether a firewall or network policy blocks ICMP. Do not conclude solely from failed ping that an application service is unavailable.

Replies have high delay or packet loss

Run a finite series such as ping -c 4 more than once and compare local and remote results. Wi-Fi interference, congestion, overloaded equipment, an unstable upstream path, and ICMP rate limiting can all produce these symptoms. Continue with route and service-specific tests when necessary.

Exam-relevant notes

Ping sends ICMP Echo Requests and expects ICMP Echo Replies.
RTT is the time for a request to reach the destination and its reply to return.
Packet loss is the proportion of sent probes that receive no reply.
Ctrl+C stops a continuous ping and displays its summary.
-c limits the number of requests; -s changes the ICMP payload size.
TTL is a received IP value that limits forwarding, not a full route report.
Successful IP reachability with failed hostname resolution commonly points to DNS.
Successful ping does not prove that a particular application or port is available.