InetDaemon.Com

THE PING PROCESS

1. The source host generates an ICMP protocol data unit.
2. The ICMP PDU is encapsulated in an IP datagram, with the source and destination IP addresses in the IP header. At this point the datagram is most properly referred to as an ICMP ECHO datagram, but we will call it an IP datagram from here on since that's what it looks like to the networks it is sent over.
3. The source host notes the local time on it's clock as it transmits the IP datagram towards the destination. Each host that receives the IP datagram checks the destination address to see if it matches their own address or is the all hosts address (all 1's in the host field of the IP address).
4. If the destination IP address in the IP datagram does not match the local host's address, the IP datagram is forwarded to the network where the IP address resides.
5. The destination host receives the IP datagram, finds a match between itself and the destination address in the IP datagram.
6. The destination host notes the ICMP ECHO information in the IP datagram, performs any necessary work then destroys the original IP/ICMP ECHO datagram.
7. The destination host creates an ICMP ECHO REPLY, encapsulates it in an IP datagram placing it's own IP address in the source IP address field, and the original sender's IP address in the destination field of the IP datagram.
8. The new IP datagram is routed back to the originator of the PING. The host receives it, notes the time on the clock and finally prints PING output information, including the elapsed time.

The process above is repeated until all requested ICMP ECHO packets have been sent and their responses have been received or the default 2-second timeout expired. The default 2-second timout is local to the host initiating the PING and is NOT the Time-To-Live value in the datagram.

NOTES ON 'FAILED' RESPONSES

Note that an ICMP ECHO REPLY might return after the default 2-second timeout. Thus the packet did return, it just did not do so in the 2 seconds alotted. When experiencing so-called packet loss when using ping, it is always a good idea to increase the default 2 second timeout to see if packets are no longer being dropped. If increasing the default timeout value seems to improve performance by reducing packet loss, then your problem is NOT a packet loss issue, it is a congestion issue caused by high load at one of the following locations (in order of frequency):

1. Your own Internet connection to your ISP
2. The remote server
3. The remote host's connection to their ISP
4. A peering point between two ISP's which your traffic transits over

Large companies maintaining websites (eg. Google, Yahoo, Microsoft, CNN, AOL etc.) usually monitor their Internet connections to help them prepare for upgrades to their Internet provider before any serious issues arise. They keep a five minute running average byte-count of the input and output of each Internet pipe and trend the utilization over weeks, months and years. This gives them the ability to predict when they will run out of bandwidth under normal usage.

DENIAL OF SERVICE

However, companies can't always prepare for everything. Today there are scripts available that allow any child with the ability to read and type to initiate what is called a denial of service (DoS) attack, or a distributed denial of service (DDoS) attack. Both attacks are designed to deny functional service to the their target systems by confusing, crashing or outright overloading the remote server or flooding it's Internet connection with useless traffic. These attacks have adverse affects on the performance of ping in ways that are not immediately obvious. An ongoing attack will make the site appear to be down, losing packets or just slow, depending on the severity and level of attack. Since DoS/DDoS attacks use PING, the administrator may take defensive actions that will interfere with or block the ability to PING.

RATE LIMITS, ACCESS LISTS AND FIREWALLS

Any website's administrator may have actually planned ahead for a denial of service attack and added rate limits or access lists that restrict or block PING. Many firewalls block all ICMP directed at protected hosts by default. Denial of service attacks are so common these days that this sort of action is actually quite prudent, so long as there is another means of verifying connectivity. As stated elsewhere in this site, PING is really not the best tool for checking packet loss and latency. There is really no way to know if a remote server's Internet gateway is using rate limits or access lists from the PING results you receive. Thus, you can't always trust PING and especially not for any true indication of packet loss or latency and even what seems to be availability problems can't always be trusted.

If you are getting undesireable or strange ping results, use your brain and use other means of testing the connection such as browsing the website, using a traceroute or sending a piece of e-mail or DNS request. [ If you really know what you're doing, you can emulate a web request or an e-mail connection using the command line and use the output to diagnose the problem --InetD ].

ADDITIONAL NOTES

Note that since ICMP requires responses, a fully functioning duplex communication environment (a downlink and uplink path) must be in place and be functioning for the PING to work. PING fails when there is no return path or the return path is unreachable or unavailable.