# # arp
APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

2003/10/23 arp

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.



Some material is very old and may be incorrect today

© October 2003 Tony Lawrence

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.


If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> arp


Inexpensive and informative Apple related e-books:

Take Control of iCloud

Photos for Mac: A Take Control Crash Course

Photos: A Take Control Crash Course

iOS 8: A Take Control Crash Course

Take Control of iCloud, Fifth Edition





More Articles by © Tony Lawrence



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






Printer Friendly Version

Have you tried Searching this site?

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.

Contact us


Printer Friendly Version





A man can be destroyed but not defeated. (Ernest Hemingway)




Linux posts

Troubleshooting posts


This post tagged:

Networking

UnixWords



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode