The ping command, available on both the Windows and Linux CLI, is an implementation of the Internet Control Message Protocol (ICMP) as specified in RFC 792. Ping is typically used to determine if a remote host/computer is available on a network, but it can also be used to test network latency and perform basic network diagnostics.
Basic Use
The basic use of the ping command is nearly identical in both Windows and Linux, although there are some differences that will be covered later. To execute the ping command open a Windows command prompt or Linux terminal and type ping followed by the domain name or IP address of the remote host you want to ping.
C:\>ping 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Ping statistics for 192.168.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2msHere you can see that the remote computer (192.168.0.1) responded to all four ICMP Echo (ping) packets and they had an average round trip time of 2 milliseconds. This tells you that the remote computer is on the network and is responding.
If the remote computer is not available on the network or is not responding to the ping packets it will look like one of the following examples in Windows:
C:\>ping 10.0.0.5
Ping 10.0.0.5 with 32 bytes of data:
Request timed out.C:\>ping 192.168.0.246
Ping 192.168.0.246 with 32 bytes of data:
Reply from 192.168.0.11: Destination host unreachable.Just because a computer does not respond to a ping does not necessarily mean it is not on the network. For security reasons the computer may be behind a firewall that blocks ICMP traffic, or the computer may be configured to not respond to ping requests.
Network Diagnostics Using Ping
While ping may seem simplistic, it can actually be quite useful for network diagnostics.
Request timed out vs Destination host unreachable
When pinging a remote host you will usually receive one of three results:
The remote host responds
A response is not received and a timeout occurs
The remote host is unreachable
Request timed out
The ping command will eventually timeout if an echo response packet is never received. The Windows version of the ping command will display the message Request timed out to standard out when this occurs. The Linux version of ping displays nothing to standard out if a response is not received.
Since a response was never received and a timeout occurred you can conclude that the remote host is either not on the network or that ICMP traffic is being blocked.
Destination host unreachable
There are two primary reasons the ping command will report Destination host unreachable: either the system did not respond to an Address Resolution Protocol (ARP) request, or there is no route to the remote system.
If you are pinging a computer on your local network (i.e. same subnet) and receive this message that typically means the system did not respond to an ARP request. When you ping a computer on your local network your computer will attempt to resolve the remote computer's MAC address prior to sending the ping packet; it does so by sending out an ARP request. In order to function properly on the network the remote computer must respond with an ARP reply that includes its MAC address. If you do not receive an ARP replay the ping command will display Destination host unreachable to standard out. In this case it is reasonable to assume the remote computer is not connected to your local network.
If you are pinging a computer on a different network (i.e. across the internet) and receive Destination host unreachable or Network is unreachable that typically means that there is no known network route between your computer and the remote host. This could indicate that your computer is not connected to the network, that an issue exists in your computer's local routing table, or there is a routing table problem with your gateway router or higher-level devices.
Using Ping to Verify Your DNS Configuration
You can use the ping command to confirm that the Domain Name System (DNS) configuration on your local computer is functioning properly. To verify your DNS configuration simply give the ping command a domain name instead of an IP address. Here is the Windows version:
C:\>ping commandlinewizardry.com
Pinging commandlinewizardry.com [185.230.63.171] with 32 bytes of data:
Reply from 185.230.63.171: bytes=32 time=13ms TTL=243Note how ping displays the domain name and the corresponding IP address, which means that DNS is likely configured properly on your local system since it resolved the domain name. This same functionality exists in the Linux version of ping, although the output looks slightly different:
$ ping commandlinewizardry.com
PING commandlinewizardry.com (185.230.63.186) 56(84) bytes of data.
64 bytes from 185.230.63.186 (185.230.63.186): icmp_seq=2 ttl=128Using Ping to Check Network Latency
Network latency is the time difference between when a request is sent to a remote computer, and when a response is received back. When pinging a computer on your local network latency of 10ms or less is considered reasonable. Here is an example of pinging a system on a local network, note that the round trip time, or latency, is 2ms:
C:\>ping 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64When pinging a computer across the internet a latency of between 20 and 100ms is considered reasonable. The example below shows the ping response from a computer on the internet, note the increase in latency to 13ms as compared to the system on the local network:
C:\>ping commandlinewizardry.com
Pinging commandlinewizardry.com [185.230.63.171] with 32 bytes of data:
Reply from 185.230.63.171: bytes=32 time=13ms TTL=243Typically the further geographically apart the two computers are the higher the latency. The example below shows a ping request to a system in Europe from a system in the United States, note the significant increase in latency to 107ms.
Pinging europa.eu [2a01:7080:24:100::666:45] with 32 bytes of data:
Reply from 2a01:7080:24:100::666:45: time=107msRealize that the network plays a large role in latency, but the system being pinged also plays a role. If the system being pinged is overwhelmed with traffic its response time may increase, which will cause an increase in perceived latency.
The ping command is very useful for confirming that latency across your internal network and internet systems are at an acceptable level.
Common Ping Options
There are a variety of options available for the ping command, some of the more common ones are outlined in the table below. Note that options vary between the Windows and Linux versions of the ping command.
Famous Vulnerabilities
In the early days of the internet and computer networking it was fairly common to find security vulnerabilities in the implementations of different protocols, and ICMP echo (ping) is no exception. Two of the more famous vulnerabilities are Ping of Death and Smurf.
Ping of Death
When using IPv4 packet sizes are limited to 65,535 bytes. Ping of Death took advantage of this fact to craft overly-large network packets that would cause a remote system to crash. Essentially an attacker would create an overly large ping packet, on the order of 100,000+ bytes. When sent, the malicious ping packet would be fragmented into smaller packets to be sent across the network.
The target computer would receive the fragmented packets and try to reassemble them. Unfortunately, the resulting100,000+ byte ping packet caused an overflow in the 65,535 byte buffer, causing the system to crash or reboot.
This issue has since been resolved by simple size bounds checking and is no longer a threat.
Smurf
The Smurf attack is one of the earliest examples of a distributed denial of service attack that used an amplification technique. During a normal ping session a computer will send an echo request to a remote computer and receive an echo reply back. The remote computer will reply to whatever IP address is specified as the source address in the request packet.
If an attacker were to spoof the source IP address in the echo request packet the remote computer would send the echo response back to the target (spoofed IP address) computer. The Smurf attack extended this thinking by spoofing the source IP address of the target computer, but then sending the echo request packet to a network broadcast address. This would cause every system on the network to receive the echo request and then respond back to the target system (spoofed IP address) with an echo response. Amplification occurs because the attacker sends out a single ping packet, but it results in hundreds or thousands of response packets being sent to the target computer. If this is done enough times the target computer gets overwhelmed and a denial of service occurs.
To mitigate this threat many systems no longer respond to ping packets received on a network broadcast address. Also routers typically will no longer forward packets that are sent to a broadcast address, making this attack infeasible outside of a local network.