3.5. ARP
ARP is the Address Resolution Protocol as described in
RFC 826.
ARP is used by a networked machine to resolve the hardware location/address of
another machine on the same
local network. Machines on the Internet are generally known by their names
which resolve to IP
addresses. This is how a machine on the foo.com network is able to communicate
with another machine which is on the bar.net network. An IP address, though,
cannot tell you the physical location of a machine. This is where ARP comes
into the picture.
Let's take a very simple example. Suppose I have a network composed of several
machines. Two of the machines which are currently on my network are foo
with an IP address of 10.0.0.1 and bar with an IP address of 10.0.0.2.
Now foo wants to ping bar to see that he is alive, but alas, foo has no idea
where bar is. So when foo decides to ping bar he will need to send
out an ARP request.
This ARP request is akin to foo shouting out on the network "Bar (10.0.0.2)!
Where are you?" As a result of this every machine on the network will hear
foo shouting, but only bar (10.0.0.2) will respond. Bar will then send an
ARP reply directly back to foo which is akin
bar saying,
"Foo (10.0.0.1) I am here at 00:60:94:E9:08:12." After this simple transaction
that's used to locate his friend on the network, foo is able to communicate
with bar until he (his arp cache) forgets where bar is (typically after
15 minutes on Unix).
Now let's see how this works.
You can view your machines current arp/neighbor cache/table like so:
[root at espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable |
As you can see my machine espa041 (9.3.76.41) knows where to find espa042
(9.3.76.42) and
espagate (9.3.76.1). Now let's add another machine to the arp cache.
[root at espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms
--- espa043.austin.ibm.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
[root at espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable |
As a result of espa041 trying to contact espa043, espa043's hardware
address/location has now been added to the arp/neighbor cache.
So until the entry for
espa043 times out (as a result of no communication between the two) espa041
knows where to find espa043 and has no need to send an ARP request.
Now let's delete espa043 from our arp cache:
[root at espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root at espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale |
Now espa041 has again forgotten where to find espa043 and will need to send
another ARP request the next time he needs to communicate with espa043.
You can also see from the above output that espagate (9.3.76.1) has been
changed to the "stale" state. This means that the location shown is still
valid, but it will have to be confirmed at the first transaction to that
machine.
Take our 
