Debugging ARP Problems

Since ARP is such a simple protocol, there aren’t many problems that can crop up
with it. Most of the problems that do arise are exhibited elsewhere. You probably
wouldn’t know that a problem was directly related to ARP unless you knew what
some of the common symptoms were.
In addition, it is important to keep in mind that ARP can fail on its own, yet not
appear to be an ARP-related problem. If the destination host specified in the original
ARP request were down or otherwise unreachable, then it obviously would not
receive (nor respond to) the original request. In such a case, the original sender
would be unable to get a hardware address and would therefore be unable to
send any IP packets to the destination device.
This is a substantially different concept from the host being able to send data to
the recipient, even if that data is being ignored. While it may seem irrelevant (we
can’t send data in either case), it is an important distinction.
If a host wanted to send data to another system, then it would first have to get the
hardware address. If it could not get the hardware address, then no IP data would
get sent at all. Under normal circumstances, it would be able to get the hardware
address although IP delivery might still fail. An application should be able to tell
the difference between these two types of failures, as they may have different ramifications
for the end user.
For example, if you try to use the ping program to test a host that is powered off,
that host will not be able to respond to ARP broadcasts, and as such the local
ICMP software will not be able to send an ICMP Echo Request message to the destination
system. So, the ICMP software may return timeout errors to the user
through the ping application. This is a different failure from the host taking too
much time to respond, from routing errors preventing the ICMP packets from
being sent or returned successfully, or from any other form of errors that may be
keeping ping from working properly. Instead of ICMP failing (as the results might
indicate), the truth would be that the sending system was the one having problems.
This is a subtle but important difference, and one that should be kept in
mind when diagnosing connectivity problems.