If you're not a networking technician, you probably still know about the ubiquitous ping utility — most likely you use it fairly often. But do you know anything about how it actually works, and what exactly it's telling you?
The original Unix ping program was written by Mike Muuss, who's got a web page with the full story. The name comes from the sound that sonar makes when it generates a loud burst of sound (the "ping" of countless clueless Hollywood productions). Sonar works by listening for the echoes of that burst as it reflects from objects in its path. Similarly, ping works by sending a special network packet (an ICMP Echo Request packet) out, and then listens for the "reflection" (a matching ICMP Echo Reply packet). ICMP stands for Internet Control Message Protocol. ICMP is nearly universally enabled on network devices, though in some cases it can be disabled by configuration and firewalls can block it — but in the real world on enterprise networks, ICMP nearly always works.
The ping utility tells you just two things: whether there is a device at a particular IP address, and how long it takes a network packet to get from the system running ping to the target and back. It tells you nothing whatsoever about what kind of device or system is at that IP address.
Discovery runs ping on the MID server much as if you were sitting at the terminal or console on that computer running it yourself — it actually uses the same utility program that you would use. Every IP address you configure in a Discovery schedule gets pinged individually, just to see if there is any device at all at that address. This is the very first step in every Discovery; only if we get a ping response do we continue on with further exploration of a given IP address.
Discovery ignores the response time from ping, but what does it tell you when you run ping? That response time is simply the time between when the echo request was sent and the echo reply was received by the computer you're running ping on. That delay has many causes. In most enterprise networks, the bulk of the delay is time the packets sat waiting in routers for their turn to be retransmitted. In some cases (when long WAN links are involved), the speed of light may contribute. For instance, when I get on the Internet from my home, I connect over a satellite link (because I live way out in the sticks). When I ping, the echo request travels about 36,000 km up to the satellite, then 36,000 km down to the ground station in Colorado, perhaps 2,000 km over the terrestrial Internet to the target computer, 2,000 km back to the ground station, 36,000 km back up to the satellite, and finally 36,000 km back to my home. Whew! That's a journey of 148,000 km — a distance that takes light about half a second to travel. So when I ping anything out on the Internet from my home, I see typical response times of 600 to 700 ms, and most of that is the time that light (or radio) takes to travel that distance...
