The Address Resolution Protocol lives in some of the deeper and darker realms of the networking stack and is never of any concern to the every day user.  Nonetheless, it provides a critical service, without which IP-based networking could not function.  In OSI terms, ARP is a "connecting protocol" that lies between the Networking layer and the Data Link protocol known as Ethernet, and since we have discussed neither IP's network protocol (namely IP itself) nor Ethernet, I'll briefly explain what we need to know of each to understand the role of ARP.

All that we need to know about these two protocols that ARP glues together is how their addressing scheme works.  IP is responsible for assigning a unique (32-bit) address (looks like this: and is simply called an "IP address") to each device on a network.  Ethernet has a similar addressing scheme, with three notable exceptions:  Addresses are 48-bit (looks like this: 00:01:D7:3E:E2:84 and is called a Medium Access Control (MAC) address), are assigned to each Network Interface Card (NIC) rather than to the device itself (one device can have multiple NICs), and only need to be unique among the NICs that are directly connected to one another.  This latter difference is because the Data Link layer can't see past the devices that are directly connected to each other, while IP must consider networks of arbitrary size, where not all devices in the network are necessarily directly attached to one another.

So why do we care about all of these addresses?  Well it just so happens that they are the things ARP glues together.  Remember, each layer on the networking stack knows nothing about any of the other layers (see the first bit on the OSI model if this seems foreign to you).  So when IP has data to send, it will push it down the stack to Ethernet and give it the only piece of information it knows about the destination: its IP address.  Therefore IP says "Ethernet, please send this data to IP address"  Ethernet, naturally, has no clue where is.  The only language it knows is that of MAC addresses.  Thus (get out your spoon for the alphabet soup) Ethernet must find the MAC address of the NIC that is attached to the device with the given IP address.  This is where ARP comes in.  Ethernet will broadcast an "ARP request" to all devices that it is attached to.  This request says "Hello everyone, please tell me which of you is attached to device with IP"  If a NIC on a connected device picks up this plea and confirms that the device it is attached to does indeed have this IP address, it will reply, "Good sir! I do own this IP address, so please send your data to me. My MAC address is 00:01:D7:3E:E2:84."  The original sender now knows where the data it got from the IP layer is supposed to go, and communication can proceed.  This information is then stored in a cache so that future communication with that IP address can happen without needing to send another ARP request.

That's all there is to it, and if you think this sounds very simple, you're right.  ARP was intentionally kept small and simple to minimize overhead introduced in the lower layers.  Now, there are alternate forms of ARP, such as RARP (Reverse ARP) and GARP (Gratuitous ARP), that do complicate things a bit, but I will leave learning about them as exercises for the reader.

Now, finally coming to BIG-IP and its dealings with ARP, it has come to my attention that BIG-IP does some tricky stuff with ARP to enable a feature known as "VLAN groups."  However, rather than doubling the size of this post, I will wait until next week, and thus postpone our next protocol, to divulge the juicy details on this nifty feature.  Until then!

(RFC for ARP) - The official IETF document for the ARP protocol.  I will link to each protocol's RFC as I discuss them.