• It may be routed at a lower priority than other protocols, thus making latency appear worse than it really is.
• Some system administrators insist on dropping it at the firewall.
• Some routers may receive an ICMP ping request for a machine on its local net, and on the assumption that it can reach it, will reply itself, rather than sending the packet out on the wire of the localnet and waiting for the response. Call it lazy evaluation if you will. (Disclaimer: I have never observed this myself, but a tech whose word I have no reason to doubt told me that this can happen).

This means that just because you receive a response doesn't mean that the machine is alive, and if you don't receive a packet, it doesn't mean that the machine is dead.

In spite of that, things are not as bad as they seem. When you want to do this sort of thing, you are usually interested in your own LAN, an environment over which you theoretically have some control. So you should be able to determine whether you will encounter these scenarios.

On the other hand, just because you do get a ping response back, doesn't mean that the service you are really interested in (e.g. http, smtp or ssh to name a few) is actually running. Apache might have eaten all your RAM, sendmail might have eaten all your disk, sshd might have run out of sockets...

Therefore, to really test the health of a machine and the ability to reach it successfully (i.e. did a new firewall rule put it out of bounds?) the best way that I have found is to open up socket on the port the service is advertised on, and if successful, close it immediately. As an added benefit, if the open fails, you get a terse explanation of the problem in $!.

I posted a snippet of code recently at Re: is there script to detect if remote machine is alive/reachable w/o using Net::Ping? that shows how this can be done.