Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions for ARP. Let’s see what does ARP stand for. ARP is the Address Resolution Protocol and it 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 Shafkat.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.

A simple example will clarify this. If a use has a network composed of several machines. Two of the machines which are on the network are Shafkat with an IP address of 10.0.0.1 and bar with an IP address of 10.0.0.2. If Shafkat wants to ping bar to see that he is alive, but alas, Shafkat has no idea where bar is. So when Shafkat decides to ping bar he will need to send out an ARP request. This ARP request is akin to Shafkat 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 Shafkat shouting, but only bar (10.0.0.2) will respond. Bar will then send an ARP reply directly back to Shafkat which is akin bar saying, “Shafkat (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, Shafkat is able to communicate with bar until he (his arp cache) forgets where bar is (typically after 15 minutes on Unix).

Let’s see how it works. A user can view his machines current arp/neighbor cache/table like so:
[root@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
A users 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@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@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/neighbour cache. So until the entry for espa043 times out, 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@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@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.

If you followed advice and guidance as provided in this tutorial guide then you would have learnt about ARP.