The IP address and the routing table direct a datagram to a specific physical network, but when data travels across a network, it must obey the physical layer protocols used by that network. The physical networks that underlay the TCP/IP network do not understand IP addressing. Physical networks have their own addressing schemes, and there are as many different addressing schemes as there are different types of physical networks. One task of the network access protocols is to map IP addresses to physical network addresses.
The most common example of this network access layer function is the translation of IP addresses to Ethernet addresses. The protocol that performs this function is Address Resolution Protocol (ARP), which is defined in RFC 826.
The ARP software maintains a table of translations between IP addresses and Ethernet addresses. This table is built dynamically. When ARP receives a request to translate an IP address, it checks for the address in its table. If the address is found, it returns the Ethernet address to the requesting software. If the address is not found in the table, ARP broadcasts a packet to every host on the Ethernet. The packet contains the IP address for which an Ethernet address is sought. If a receiving host identifies the IP address as its own, it responds by sending its Ethernet address back to the requesting host. The response is then cached in the ARP table.
The arp command displays the contents of the ARP table. To display the entire ARP table, use the arp -a command. Individual entries can be displayed by specifying a hostname on the arp command line. For example, to check the entry for peanut in the ARP table on almond , enter:
%arp peanut
peanut (172.16.12.2) at 8:0:20:0:e:c8
Checking all entries in the table with the -a option produces the following output:
%arp -a
Net to Media Table Device IP Address Mask Flags Phys Addr ------ ----------------- --------------- ----- --------------- le0 peanut.nuts.com 255.255.255.255 08:00:20:00:0e:c8 le0 acorn.nuts.com 255.255.255.255 08:00:02:05:21:33 le0 almond.nuts.com 255.255.255.255 SP 08:00:20:22:fd:51 le0 pecan.nuts.com 255.255.255.255 00:20:af:1e:7e:5f le0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00
This table tells you that when almond forwards datagrams addressed to peanut , it puts those datagrams into Ethernet frames and sends them to Ethernet address 08:00:20:00:0e:c8.
Three of the entries in the sample table ( peanut , acorn , and pecan ) were added dynamically as a result of queries by almond . Two of the entries ( almond and BASE-ADDRESS.MCAST.NET ) are static entries added as a result of the configuration of almond . We know this because both of these entries have an S, for "static," in the Flags field. The special BASE-ADDRESS.MCAST.NET entry is for all multicast addresses. The M flag means "mapping" and is only used for the multicast entry. On a broadcast medium like Ethernet, the Ethernet broadcast address is used to make final delivery to a multicast group.
The P flag on the almond entry means that this entry will be "published." The "publish" flag indicates that when an ARP query is received for the IP address of almond , this system answers it with the Ethernet address 08:00:20:22:fd:51. This is logical because this is the ARP table on almond . However, it is also possible to publish Ethernet addresses for other hosts, not just for the local host. Answering ARP queries for other computers is called proxy ARP .
For example: assume that acorn is the server for a remote system named hazel connected via a dial-up telephone line. Instead of setting up routing to the remote system, the administrator of acorn could place a static, published entry in the ARP table with the IP address of hazel and the Ethernet address of acorn . Now when acorn hears an ARP query for the IP address of hazel , it answers with its own Ethernet address. The other systems on the network therefore send packets destined for hazel to acorn . acorn then forwards the packets on to hazel over the telephone line. Proxy ARP is used to answer queries for systems that can't answer for themselves.
ARP tables normally don't require any attention because they are built automatically by the ARP protocol, which is very stable. However, if things go wrong, the ARP table can be manually adjusted. See Chapter 11, Troubleshooting TCP/IP , the section called "Troubleshooting with the arp Command."