Address Resolution Protocol
This is the protocol that matches IP addressses to MAC (hardware) addresses. Every IP network device has a unique 6 byte hardware address, the first three of which are assigned to specific companies. See Troubleshooting network connections with arp, 'arpwatch' for security and administration.
The arp cache can be displayed with "arp -a":
linux (10.1.36.3) at 0:1:2:26:0:cc ? (10.1.36.238) at 0:c0:f0:6b:b4:18 ? (10.1.36.249) at 0:8:0:c0:8:d ? (10.1.36.255) at ff:ff:ff:ff:ff:ff
If you replace a network device, the MAC address will be different and you need to either wait for the arp cache to clear, or delete the cache so that the new MAC information can be put in. The waiting time could be as little as two minutes (Windows 95) or as much as several hours (servers and routers have longer cache retention settings).
An often overlooked debugging point is this: if the ip address you want to talk to is NOT in the cache (after your attempt to ping, telnet etc.), you are not going to be able to talk to it period. If it IS in the cache, it's worth checking that the MAC address makes sense: if the first three bytes indicate that it is a 3Com device, but you know for a fact that is not true, then some other device is using that ip address, and that may be why yoyr attempts to communicate are failing.
It is possible to have "proxy arp": some machine is helping your arp cache by telling you what it thinks you need to know. In such a case, your cache information might be completely useless: the device in question could be turned off, dead, or unplugged. What you get is the MAC of the proxy. If you see the same MAC assigned to two different IP's, that's probably why.
Gratuitous arp is arp broadcasts made without a request: a server telling its clients "I'm 192.168.2.3 at 00-02-9C-08-03-C3". If the server is regularly changing its address, that can be useful, because any client that has that in its cache already will update it.
Inverse and reverse arp are similar: inverse is exactly the opposite of arp; it's who has the ip matching this MAC. Reverse arp is what lets a device find out what its ip address is supposed to be, and is conceptually similar to DHCP.
Finally, there's "UnArp", which is a way to say "I'm all done and am leaving the network", which helps clear out caches sooner.

Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
It should be noted that on SCO OSR5 arp's behavior can be tuned to some extent with several entries in the /etc/default/inet configuration file. Of particular interest are the arpt-prune and arpt_keep parameters.
arpt_prune and arpt-keep together determine how up-to-date the arp cache is at any given instant. arpt_prune tells the kernel how often is should sweep the arp cache and remove invalid entries (an entry becomes invalid when the machine associated with the MAC address no longer responds to network activity). arpt_keep tells the kernel how long it should assume an entry is valid before refreshing it.
On a network with no DHCP clients, it may be helpful to set both arpt_keep and arpt_prune to high values. Setting arpt_keep high will tend to reduce arp related broadcasts, with a corresponding reduction in network traffic. Setting arpt_prune high will reduce the amount of time the kernel spends managing the arp cache. These high settings can be especially beneficial on large networks with dozens or hundreds of machines.
On the other hand, if your server supports DHCP clients, if the server itself is a DHCP client, or if machines just come and go a lot (e.g., Windows clients that make a habit out of crashing), it would be better to set both of these parameters to low values to keep the arp cache as up-to-date as possible. The price for doing so will be more frequent arp broadcasts and an increase in the processing time spent in maintaining the arp cache.
By the way, you can change the values in /etc/default/inet by using the inconfig utility.
--BigDumbDinosaur
It should be noted that on SCO OSR5 arp's behavior can be tuned to some extent with several entries in the /etc/default/inet configuration file. Of particular interest are the arpt-prune and arpt_keep parameters.
arpt_prune and arpt-keep together determine how up-to-date the arp cache is at any given instant. arpt_prune tells the kernel how often it should sweep the arp cache and remove invalid entries (an entry becomes invalid when the machine associated with the MAC address no longer responds to network activity). arpt_keep tells the kernel how long it should assume an entry is valid before refreshing it.
On a network with no DHCP clients, it may be helpful to set both arpt_keep and arpt_prune to high values. Setting arpt_keep high will tend to reduce arp related broadcasts, with a corresponding reduction in network traffic. Setting arpt_prune high will reduce the amount of time the kernel spends managing the arp cache. These high settings can be especially beneficial on large networks with dozens or hundreds of machines.
On the other hand, if your server supports DHCP clients, if the server itself is a DHCP client, or if machines just come and go a lot (e.g., Windows clients that make a habit out of crashing), it would be better to set both of these parameters to low values to keep the arp cache as up-to-date as possible. The price for doing so will be more frequent arp broadcasts and an increase in the processing time spent in maintaining the arp cache.
By the way, you can change the values in /etc/default/inet by using the inconfig utility.
--BigDumbDinosaur
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar