What is ARP?

A number of times in the last few weeks I have been asked by a number of people:

What is ARP?

There is the simple answer – which is simply a definition:

Address Resolution Protocol (ARP) is a mechanism to resolve IP addresses into MAC addresses.

However…that doesn’t really explain a lot. It probably doesn’t explain anything you didn’t already know. To really understand ARP, you probably need to understand the following:

  • Why do we need to ARP? Why do we care what MAC address is associated with what IP?
  • When do we ARP, and what do we ARP for?
  • How does ARP work? What does the conversation look like?
  • How often do we perform ARP?

In this post I’ll aim to go over some low level basic network stuff, to try and explain all of this. I’m going to generalise quite a lot – I’m specifically talking about ARP and IPv4. There are other protocols at the various layers, but I’m sticking to simple and relevant.

Why do we need ARP?

Right back at basics, we have the OSI 7 layer model (or the TCP/IP model – whichever you prefer)

It is important to understand these layers, and where things fit. In particular (and quite generically):

  • Transport: Layer 4. This is where TCP or UDP fit. Addressing at this layer is port numbers. A block of data at this layer is referred to as a segment.
  • Network: Layer 3. This is where IP fits. Addressing at this layer is IP addresses. A block of data at this layer is referred to as a packet.
  • Data Link: Layer 2. This is where Ethernet fits. Addressing at this layer is MAC addresses. A block of data at this layer is referred to as a frame.

So as you pass data down from an application through either model, to the physical cable, each upper layer gets encapsulated into the layer below.

An important thing to take from this, is that when a frame is sent onto the wire, it is always (within the Ethernet protocol anyway) addressed to a MAC address. Packets are addressed to IP’s, but a packet is never sent in it’s native form. It is always encapsulated. So that answers the question around why we ARP. We ARP, because we know the IP of the thing we need to communicate with (Layer 3), but we don’t know it’s MAC address (Layer 2).

When do we ARP?

We ARP when we need to know the Layer 2 address which we need to send a segment to. However – that does not necessarily mean that we always ARP for every IP which we send packets to.

Remember when you configure an end device, you generally give three pieces of information:

  • IP Address
  • Subnet Mask
  • Default Gateway

This allows the device to work out the usable host range for the subnet that it is on. So if the device is,, it knows that all IP’s in the range to are on it’s own subnet. Here is the key…end devices are lazy. They will only try and speak directly to devices which they determine to be on their own subnets. If they decide that who they are trying to talk to is not on their subnet…well that’s what a default gateway is for. It doesn’t care. Not on my subnet? Send it to the gateway. So, we only need to ARP if we are trying to reach a host which is on our subnet. If you read between the lines here, this means that our default gateway has to be on our subnet (maybe with an exception here or there).

So what do we ARP for? If it’s in our subnet – we ARP for the IP we want to send traffic to. If it’s in our subnet, we consider it reachable directly, so we’ll ARP for it to send stuff to it. If it’s not? Then we ARP for the default gateway. As far as we are concerned, as the end host, it’s not our problem. So if we are reaching a host that is off our subnet, the packet will be addressed to the far end, but the frame will be addressed to the default gateway. It’s the default gateway’s problem to get it there. Note that the inverse of this is also true, and that is an important distinction. A default gateway is not a fail safe – if we consider an IP to be in our subnet, then it is considered reachable. We will ARP for it, and we won’t send traffic to the gateway to reach it.

Each hop we go, we change the MAC. The IP stays the same end to end, but the MAC is only significant in the local LAN. When a router receives a frame, it goes through something like this:

  1. Layer 2 – is the frame destined to me? Yes. Strip the Layer 2 header.
  2. Layer 3 – is the packet destined to me? No. Do a routing lookup – find the outgoing interface and use the MAC of that as the source MAC. From the routing lookup, find the next hop IP. Run ARP for it, find the MAC. Create a new layer 2 header destined to that MAC and sourced from my interface, and send the frame.

How does ARP work?

To send an ARP for an IP, we send a frame on to the network destined to ffff.ffff.ffff. This is the MAC address for broadcast. It means send to every host. So every host receives a copy of the ARP request. The frame contents list the sender IP, and the sender MAC. It also lists a target IP and a target MAC. The target IP is the address we want to ARP for. The target MAC is 0000.0000.0000. Note that the target information is not the destination information contained in the Ethernet header. The Ethernet destination is ffff.ffff.ffff.

The ARP reply (hopefully!) comes back from the other side. It comes back as unicast Ethernet, addressed to the local MAC address, with a source of the far end. The details within the ARP reply are filled in – i.e. the 0000.0000.0000 is replaced with the details of the far end.

At this point I would usually include a packet capture. But there are already plenty on Google. Just search “ARP Packet Capture” in a Google image search.

How often do we ARP?

So, do we ARP every time we need to send a frame? That would be really inefficient. We have an ARP cache. Any ARP responses we receive are cached into a table and assigned an ageing timer. When the ageing timer expires, if we need to still communicate, then we re-ARP. The ageing timer is OS specific – in some Linux OS’s is is 60 seconds, in some Cisco routers it is 4 hours. The idea here is to reduce overhead – we don’t want to be ARP’ing for something we probably should already know. This can raise an issue whereby you can end up with stale caches when things change though – if you have information in a cache, be it right or wrong, it is generally trusted. When you are changing IP’s of things in the network, it is usually worth bearing in mind that it might be necessary to clear or refresh the ARP cache.

There is a lot of info in this post, and I hope it makes sense. There are also a lot of generalisations and simplifications – hopefully it’s a decent overview, and prompts you to read more detail into anything you need to know more about.

Leave a Comment

Your email address will not be published.

Scroll to Top