My FAQs > Operating Systems > Unix
Last updated on May 14, 2002
The arp command is used to display and manipulate the address table on a local Unix system. The address resolution table, also known as the ARP cache, contains a complete list of all datalink protocols to IP address mappings for the local network. The ARP protocol is a dynamic facility that maps datalink addresses, such as Ethernet to IP addresses, and whenever the system wants to transmit a message, it must first know the low level (i.e., datalink) address for each node on the network.
This command provides the ability to view and modify the ARP cache. To modify the ARP table, the super-user must invoke the command. Note that the terms ARP table and cache can be used interchangeably and that binding also refers to an ARP entry. With the arp command, the following can be accomplished:
The arp command provides a small number of command line options listed in Table 4.1 and fully described later.
|
|
Option |
Description |
|---|---|
|
-a |
Displays the current ARP cache |
|
-d |
Deletes an ARP entry |
|
-f |
Used to load a file that contains entries to place in the cache |
|
-s |
Creates an ARP entry |
|
To display the contents of the ARP table, use the arp -a command. When the table is displayed, it includes the device, IP address, network mask, flags, and physical address for each entry. A sample is shown below.
# arp -a Net to Media Table Device IP Address Mask Flags Phys Addr ------ -------------------- --------------- ----- --------------- le0 224.0.0.1 255.255.255.255 01:00:5e:00:00:01 le1 224.0.0.1 255.255.255.255 01:00:5e:00:00:01 le1 durer 255.255.255.255 00:60:08:26:be:5e le1 rembrandt 255.255.255.255 08:00:20:82:be:05 le1 rubens 255.255.255.255 U le1 monet-a 255.255.255.255 SP 08:00:20:04:cf:2c le0 monet-b 255.255.255.255 SP 08:00:20:04:cf:2c le1 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00 le0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
The Device field corresponds to the network interface that is attached to the local network, for which the ARP entry was obtained. In the example above, two separate interfaces are shown with their own listings. In practice, most systems only contain a single interface. The le stands for Lance Ethernet, which is the name of hardware device driver under Solaris. Because this particular system contains two network interfaces, they are numbered le0 and le1.
The IP Address field shows either an IP address or hostname that corresponds to the ARP entry. This is the address that is used to search the ARP table to determine if the desired entry exists. When an IP address is displayed, this indicates that the IP address couldn’t be correctly resolved to a hostname.
The Mask field is used to determine which part of the addresses should be examined. The Flags field provides additional details and options regarding the ARP entry. Table 4.2 shows the available flags and their associated meaning.
|
|
ARP Flag |
Meaning |
|---|---|
|
S |
Static ARP entry |
|
P |
Publish this ARP entry |
|
M |
Mapped ARP entry (Multicast Only) |
|
U |
Unresolved |
|
The Phys Addr (physical address) field contains the low-level address for each node on the local network and is expressed in 6 hexadecimal numbers in colon notation.
ARP entries that are marked S are static and have been defined outside the normal ARP protocol (e.g., manually entered with the arp –s command). Each interface on the local system has a static ARP entry because the interface is local to the system and doesn’t need the ARP protocol to obtain this information. Certain special purpose interfaces or addresses are also statically defined. Static entries are also used to support networked systems that don’t support the ARP protocol. Therefore, the address binding must be manually entered in the ARP table. One problem with this approach is that if the IP address of any of these systems is changed as a result of moving it to a new network, the ARP information must be manually updated to effect the change.
Entries that contain the P flag will be transmitted over the network if a node makes an ARP request. Typically, the system interfaces will be published so that other local devices can build their own ARP tables. Only the IP addresses associated with genuine interfaces are advertised with ARP. It is interesting to note that ARP information obtained from other network devices is not normally published by third-party systems. It is usually the responsibility of each device to respond to ARP requests with its own ARP information. There is one special case when a system will respond to ARP requests on behalf of others. This is known as proxy ARP and is described below.
Mapped ARP entries include a timer, which controls how long the entry will remain in the ARP cache. By default, most systems hold the entry for approximately 20 minutes before removing it.
The U flag indicates that an ARP request is still pending and the mapping is presently unresolved. In the ARP example above, the system rubens is lacking a physical address because the ARP request hasn’t obtained a reply. This is known as an incomplete ARP entry.
In the above example, some entries do not have corresponding physical interfaces. For example, the addresses 224.0.0.0 and 224.0.0.1 are pseudo addresses that are defined by the system for its own use. These addresses represent the multicast address facility, which is used to support real-time video/audio applications.
It might become necessary to delete one or more entries from the ARP table. For example, should a hardware failure result in the replacement of a network interface card, the network hardware address of the system will change. In this case, the existing ARP entry doesn’t reflect that the low level address has changed. As a result, messages sent to this host will not be picked up because the hardware address is not recognized.
To address this problem, the -d option is used to delete an ARP entry, as shown below. Because removing ARP bindings can cause network problems, only the super-user is permitted to remove them. The arp command expects the -d option to be used with a valid host or IP address entry. In the example, the host durer is removed from the ARP table and the arp command displays the deleted entry:
# arp -d durer durer (10.0.2.126) deleted
If the ARP table were now displayed, the durer entry would not be listed.
If a non-root user attempts to remove this host from the table, the error message would be displayed as depicted below:
$ arp -d rembrandt SIOCDARP: Not owner error
Several situations may warrant manually adding entries to the ARP table. One such situation occurs when communication with a device is needed but the device, for some reason, doesn’t support ARP or the implementation is non-functional. This might be the case with a very old system that is still in service. Another such situation occurs when a hardware address changes and the table must be manually updated to ensure connectivity. A third occurs when it is necessary to support proxy ARP services.
To add an ARP entry, use the -s option followed by the host name (or address) and the associated physical datalink address. For example, let’s say we would like to add a system called bruegel to the ARP table. The format of the physical datalink is represented as x:x:x:x:x:x, where each x is a hexadecimal number between 0 and FF. To illustrate the example, the following command would be used:
# arp -s bruegel 08:00:20:82:be:05
If no error message is displayed, it can be assumed that the command was successful.
If you want to list a single entry instead of all the entries in the table, just specify the hostname or IP address as the second argument to the arp command. For example, to list the ARP information for bruegel, use the following command:
# arp bruegel bruegel (10.0.2.101) at 8:0:20:82:be:5 permanent
Please note that this ARP binding is labeled as permanent, which indicates that the ARP information was defined statically and will not time-out. If the arp -a command is issued again, we will see the S flag option for the bruegel binding:
# arp -a Net to Media Table Device IP Address Mask Flags Phys Addr ------ -------------------- --------------- ----- --------------- le0 224.0.0.1 255.255.255.255 01:00:5e:00:00:01 le1 224.0.0.1 255.255.255.255 01:00:5e:00:00:01 le0 10.0.2.75 255.255.255.255 00:60:08:26:be:5e le0 bruegel 255.255.255.255 S 08:00:20:82:be:05 le0 monet-b 255.255.255.255 SP 08:00:20:04:cf:2c le1 monet-a 255.255.255.255 SP 08:00:20:04:cf:2c le1 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00 le0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
The ARP entry is set up as permanent unless the temp option is specified on the command line. Permanent indicates that the mapping will not expire the way normal ARP mappings do. Unfortunately, permanent bindings are not saved across reboots.
To understand why modifying the ARP table is restricted to the super-user, consider that when static ARP entries are defined, no direct linkage exists between this information and the actual devices attached to the network. For example, the bruegel entry was added manually, but no mechanism is available to ARP to ensure that the physical address is indeed correct. The arp command assumes the information provided is accurate and that the device is actually attached to the network. Therefore, if normal users had the ability to modify the ARP table, more errors would likely be introduced which would lead to loss of network connectivity. Should the physical address field of a critical network resource (like a server) be incorrectly changed, all communication between the local system and the critical system would stop.
The arp command can be used to support proxy ARP services. Proxy ARP is a way to respond to ARP requests on behalf of another network device. Typically, this configuration is used to support devices behind a router or a specialized configuration, such as those required for remote dial-up access strategies.
The arp command also supports the ability to add bindings that are defined within a regular file instead of specifying the information on the command line. This method is used, for example, to load in a list of ARP entries together. It is not uncommon, for example, for a series of ARP bindings to be loaded during normal system startup procedures— especially if the system doesn’t support distributed database lookup schemes such as NIS. The format of a file used for this purpose includes the following fields:
hostname datalink address [ temp ] [ pub ] [ trail ]
Using a text editor, you can create a list of ARP bindings using the format above and save it to a text file—for example /etc/arp-list. A sample file listing is shown below.
bruegel 08:00:20:82:be:05 temp rubens 08:00:20:81:ce:01 temp rembrandt 08:00:20:86:fe:02 cezanne 08:00:20:81:bb:01 michelangelo 08:00:20:84:ee:02
Notice that both bruegel and rubens contain the temp keyword, which indicates that these entries will be deleted from the ARP table after they expire. In practice, the temp option is not commonly used because it might be undesirable for these bindings to expire and be removed from the cache. The pub keyword is used to publish the ARP binding to the network. The trail option is primarily used to indicate that trailer encapsulation is supported by the host. However, trailers have not been widely implemented and are obsolete on Sun systems; this option, for all practical purposes, can be ignored.
After the file contains the desired entries, use the -f option of the arp command to load the contents of the file into the ARP table as shown below:
# arp -f /etc/arp-list
Should you wish to load this table automatically, edit one of the system startup files (/etc/init.d/inetsvc, for example) and include (see listing 4.1) the following entry:
# # Load custom ARP table # echo -n "Loading local arp table..." if [ -f /etc/arp-list ]; then /usr/sbin/arp -f /etc/arp-list echo "done." else echo "failed" fi