This article is a part of a series on Address Resolution Protocol (ARP). Use the navigation boxes to view the rest of the articles.
- Traditional ARP
- Proxy ARP
- Gratuitous ARP
- ARP Probe and ARP Announcement
We’ve talked about Traditional ARP, where a node is requesting another node’s MAC address. We’ve also talked about Proxy ARP, where a node is answering an ARP request on behalf of another node. Which brings us to another iteration of ARP known as Gratuitous ARP.
A Gratuitous ARP is an ARP Response that was not prompted by an ARP Request. The Gratuitous ARP is sent as a broadcast, as a way for a node to announce or update its IP to MAC mapping to the entire network.
There are three typical use cases for Gratuitous ARP, and we will look at each of them after looking at the packet structure.
Gratuitous ARP Packet Structure
The main item to point out in the Ethernet header is the Destination MAC. Notice this frame is addressed to ffff.ffff.ffff, making it a Broadcast frame.
The Source MAC, Type, and Padding work exactly as they did in the traditional ARP.
Similarly, in the ARP payload, the Hardware and Protocol type and the Hardware and Protocol Size also serve the same purpose as they did in traditional ARP.
The Opcode is set to 2, indicating a response. Despite the fact that this packet did not actually follow a request.
This is why it is said that a Gratuitous ARP is broadcast ARP Response, that was not prompted by an ARP Request.
The Sender MAC and Sender IP contain the ARP mapping the initiator is advertising. These two are the important part of the ARP Packet. They are the reason the ARP packet exists.
The Target MAC address is ffff.ffff.ffff – a reflection of the Destination MAC address. But in reality, the contents of this field are irrelevant – they are ignored in a Gratuitous ARP. Some implementations of ARP will use 0000.0000.0000 in this field.
Lastly, the Target IP address once again confirms the IP address that this particular ARP mapping is being created for.
Gratuitous ARP Use Cases
Now that we’ve understood the packet contents of a Gratuitous ARP, we can look at their specific use cases. There are three primary cases we will illustrate for Gratuitous ARP: updating ARP mappings, announcing a node’s existence, and redundancy.
Updating ARP Mapping
The first use case is pretty straight forward, a node can use a Gratuitous ARP to update the ARP mapping of the other hosts on the network should the node’s IP to MAC mapping change.
This might happen if a user manually modifies their MAC address – they retain the same IP address, but now have a new MAC address. Therefore, the ARP mapping for all the nodes which are communicating with this user must be updated.
That being said, manually changing the MAC address is pretty rare. However, you do sometimes see this in redundant Cloud or Virtual environments, where a particular Virtual Machine (VM) ‘jumps’ to a new physical box – the same VM’s IP address is now being served by a different physical machine.
Announcing a Node’s Existence
The second use case for Gratuitous ARP is when a host newly joins a network — it can use Gratuitous ARP to announce it’s existence to the network.
The intent motivating this action is useful — it is an attempt to preemptively populate ARP caches of neighboring hosts without requiring them to initiate the Traditional ARP process.
However, there is no mandate for hosts to cache ARP mappings in every Gratuitous ARP they receive. As a result, this use case provides little benefit. It causes no significant harm though, so this behavior is not discouraged.
Redundancy
Much more substantial is Gratuitous ARP’s use case in situations where redundancy or failover between two devices are used.
With redundancy, you typically have two scenarios: two devices sharing an IP address, but each having their own MAC address. Or, two devices sharing both an IP address and a MAC address.
In both of these cases, Gratuitous ARP is critically important to ensure the continued ability to communicate with the IP address as it shifts between the two redundant devices. Below are examples of each scenario and how Gratuitous ARP is employed.
Redundant IP Addresses
In this scenario, only the IP address is redundant. Two devices will share a single IP address, but each device has their own unique MAC addresses.
Our example will use two Routers sharing the IP address 10.0.0.1. The hosts in our example will be using this shared IP address as their default gateway.
When one of the routers experiences a failure, the other router sends a Gratuitous ARP.
The specific contents of the Gratuitous ARP match the packet structure described above, but the essential purpose of the packet is to let everyone on the network know that the IP 10.0.0.1 is now being served by the other router’s MAC address.
Upon receiving the Gratuitous ARP, all the hosts update their ARP tables with the new mapping so they can continue to send traffic to their default gateway IP address through the non-failed Router.
The process continues indefinitely in the case of the opposite router failing. Note, that this particular animation uses routers as the example, but nearly any type of device that shares an IP address with another device will use Gratuitous ARP in this manner.
Redundant IP and MAC Addresses
In this scenario, both the IP address and the MAC address are redundant. Two devices will share both an IP address and a MAC address.
Our example will again use two Routers, but this time they will be sharing the IP address 10.0.0.1 and the MAC address 0053.ffff.1111.
The hosts will still use the shared IP address as their default gateway, but in this example their ARP mapping will never need to change – the shared IP address 10.0.0.1 will always map to the shared MAC address 0053.ffff.1111.
Despite the hosts’ ARP mapping never needing to be updated, Gratuitous ARP is still crucial. But not for the sake of updating the hosts’ ARP mapping, but for the sake of updating the switch’s MAC address table so the shared MAC address is associated with the correct port. Recall, switches learn MAC address mappings from the Source MAC address of any received frame.
Notice, as a router fails, the other router sends a Gratuitous ARP. The switch then updates its MAC address table with the new location of the device that owns the shared MAC address.
Again, the specific contents of the Gratuitous ARP match the packet structure described above. But the purpose is for the Switch to learn the new location of the shared MAC address.
In this way, frames sent by the hosts addressed to 0053.ffff.1111 will always egress the correct switch port.
First Hop Redundancy Protocols (FHRPs) like HSRP or VRRP use this exact strategy to enable both routers to share the same IP address and MAC address. Gratuitous ARP is instrumental to enable this type of functionality.
Well said,
I would like to add that hosts use gratuitous to check for an ip assigned by the DHCP
Hi Abdo. Thanks for the read.
Technically, however, hosts use an ARP Probe to check for IP Address conflicts. The next article in the series discusses it =).
If that is the case, then why, when I issue the “show ip dhcp conflict” command, does Gratuitous ARP show up in the Detection Method column?
A lot of sources use the term “Gratuitous ARP” to describe what is actually an ARP Probe. The majority of the time, the difference is insignificant. But as this (and the next) article are speaking specifically to the distinction between them, I am intentionally being very explicit with the terms.
If you do a packet capture, you will see a difference in the packet format’s for a host doing duplicate address detection and a host sending a gratuitous ARP. You can download sample packet captures in each article as well.
and if in case configuration parameters recieved from DHCP server is not acceptable to client ( may be due to duplicate ip address assigned to other router in same broadcast domain) , client will issue dhcpdecline to dhcp server
You’ve explained so clearly exactly what I was looking for! Thank you. I’ll check your other pages for MVRP and whether it uses GARP for redundancy purposes.
This is so well explained. The visuals really help too. I’m a tech consultant, but I’m trying to become more familiar with our network, and server infrastructure. I’ll definitely be referencing your site in the future. I really appreciate this. Thanks!
How switches update mac table?
Is it referring source mac address on Gratuitous ARP payload or referring source mac address on Ethernet header of Gratuitous ARP ?
Hi Tony. Great Question.
Switches will use the Source MAC address of the Ethernet Header to update their MAC address. Switches “look no further” than the L2 header to make all their decisions. They do not know that the payload is an ARP frame, or any other type of frame — nor do they need to.
Hope this helps.
How does the router know that the other router has stopped working?
Hi Ankit, that is a function of the specific FHRP itself — HSRP does it slightly different than VRRP which does it slightly different than GLBP. I didn’t want to go into the details since this article was mostly about Gratuitous ARP and not the intricacies of FHRPs.
Cool. Thanks
Hi Ed,
Do u have any another reference for the above question??
I was under the impression that track port senses the fail and reduces the priority by its track priority cumulatively.
Thanks
Afnaan
That is also a function of the First Hop Redundancy Protocol itself (FHRP). Port tracking will bring router Interfaces or Routes in and out of service. But simply bringing an interface down or removing a route will not update neighboring switches MAC address tables or neighboring hosts’ ARP tables.
Gratuitous ARP is a tool that instructs hosts to update their ARP mapping — many different services make use of such a tool, to include many different FHRPs. Separating the tool (Gratuitous ARP) from it’s many use cases (Redundancy, FHRP, load balancing, etc) will aid your understanding of both.
Hello,
I was doing a search over how to decide over the timeout value for the ARP cache entry. I still can’t find any exact solution. I need to know is there any specific formula or parameters which we need to consider while deciding the timeout value.
Typically the timeout value is set by each operating system. The trend is client based OS’s (Win7/8/10, OSx, mobile phones, etc) use shorter time outs (30s or less) while infrastructure devices (servers, routers, etc) use longer timeouts.
The shorter the timeout the more ‘agile’ or ‘responsive’ the device will be when connecting to different networks or experiencing changes in typologies, but the more often it will have to use ARP to resolve addresses.
The longer the timeout the less CPU/cycles it would have to spend on refreshing ARP tables. This would be more useful in very stable/consistent environments where the devices attached to the network do not change frequently.
Consider a coffee shop wifi, devices come and go constantly. Compared to a network hosting servers, new server addition/removals happen much less often.
Is there a possibilty where a router receives its own ARP request ( which was sent previously), If yes what should be done ? I know that the protocol says that if TPA does not match , the packet should be dropped, so here the drop happens in L3. Can L2 drop it saying the SHA had matched its own HA ( hardware Address) ?
Hi Sandeep,
No, typically a router will not receive its own ARP Request that it initially sent out. The receiving switch would never send the ARP request back out the port it was received on due to a Switch’s filtering action.
Unless a switching loop exists I suppose, (but Spanning Tree should protect against that).
Even if, for some strange reason, the Router DID receive its own ARP request, it would drop it because the TPA doesn’t match one of its interface addresses (as you correctly pointed out).
Thanks for the response.
Regards,
Sandeep.
Great series about ARP. Thank you for explanation!
Btw there is a typo “ffff.fff.ffff” should be “ffff.ffff.ffff”
Good catch. Fixed it. Thanks!
Glad you enjoyed the series ^_^.
Hi,
In a server cluster using Virtual IP, after fail over, what if the new active server sends a GARP Request packet instead of GARP Reply to the Switch it is connected ? Will the Switch still be able to update its ARP table with the new MAC for the virtual IP ? Or do we need a GARP Reply packet from the server ?
Kindly clarify.
Thanks,
Vignesh R P
Hi Vignesh,
Remember, switches are L2 only — they do not care about IP addresses, and therefore do not maintain an ARP table.
A switch will, however, update its MAC address table regardless of what frame is sent. In fact, the switch doesn’t “look into” the ARP Payload to determine whether it is a Reply or Request — it just looks at the Source MAC address field of the L2 header of any frame.
If however, you are specifically asking about ARP tables of other devices on the network, than either an GARP Reply (as pictured above) or a GARP Response (as pictured in the ARP Announcement) has the ability to update ARP tables.
Switches still need ARP tables just like any host with an IP address. Unless you plan to only administer your L2 switches via a console cable. Any device with an IPv4 address must maintain an ARP table, including a switch. However, the only device to maintain a MAC-Address table is a switch. Before you say… what about bridges!!! Yes… a bridge would have a MAC-Address table too. However, a switch is really just a bridge with a new name, the devices operate in an identical fashion. The reason for the name change to “switch” was the introduction of ASIC chips that did the bridge functionality in hardware.
Hi Stephen,
A switch’s ARP table is only used when packets are being sent to or from the switch — i.e. when the switch is acting as a host on a network receiving and sending packets.
A switch’s ARP table is not used for transient traffic. To that end, you may as well consider a L2 switch funneling frames around to simply not have an ARP table.
A very informative and extremely well done tutorial. I like the way you break this down – it’s enlightening for someone like me who felt he had a “working knowledge” of ARP. After reading this, I realized there were quite a few holes in my understanding! Thank you for this.
I found your site doing research on an idea. I’d like to run this idea by you, and get your thoughts. The idea would seem to be a third use case for GARP: a means for a new host on a network to announce its DHCP-assigned IP address. Let me explain: I work with Raspberry Pi devices. I deploy them as “headless” devices to perform a variety of small-ish tasks, mostly to do with home automation. Deployment is most conveniently done (in my case) by configuring them to use DHCP, but this presents a small problem: To connect to the device (via SSH typically), I must know its IP address. There are a number of ways to get this information, but they all strike me as awkward, time-consuming and in some cases impractical.
So the idea is really quite simple: I’ll add a small bit of code to the Raspberry Pi that will run at boot time, and check for presence of a flag designating the device’s IP address is known to its controller host. If that flag is not present, the device will simply repeat GARPs every minute or so until he is acknowledged by its controller.
From a network persepctive, do you see any flaws in this approach?
Hi Seamus,
Does the Rasberry Pi know the Controller Host’s IP address? If so, I feel simply sending a packet directly to the controller is more efficient.
Remember, theoretically (and of course, I don’t know what else you have on your network), GARP’s will be sent sporadically by all devices for various reasons. You don’t want every single GARP to trigger a process on the controller to determine if each GARP is something the controller needs to concern itself with.
Multicast might also be a better use for what you are trying to do. Either way, the further discussion of it probably isn’t relevant to the main topic of this article. So feel free to reach out to me directly if you want to talk more.
This is so far the best article I have seen on GARP. The differences between ARP Probe, announcements and GARP was something I never knew of. Really great content!!
Thanks for the kind words, Shipra! So glad you enjoyed the articles!
Great job Eddie!
Luke! Hey friend! Thank you =)
This article is incorrect, gratuitous ARP is performed using opcode REQUEST (1) not REPLY (2).
See: https://tools.ietf.org/html/rfc5227#section-3
Hi John,
I think you are thinking of the ARP Announcement, not the Gratuitous ARP — they are different, but very similar. The next article in the series discusses them in more detail, and explains how and why they are different from Gratuitous ARPs.
@John_Smith is not talking about the ARP Announcement.
RFC says:
… Gratuitous ARP is documented in Stevens Networking [Ste94] as using
ARP Request packets …
So, after seeing your comment I did more research. And it took a while to track down, but I think I’ve gotten to the bottom of it.
First, later on in the same RFC you quote (5227) is this note:
Confirming that an Opcode of 1 (Request) is indeed an ARP Announcement.
But digging further into it it doesn’t seem very explicit. I also found this in RFC 5944 Section 4.6:
o A Gratuitous ARP [45] is an ARP packet sent by a node in order to spontaneously cause other nodes to update an entry in their ARP cache. A gratuitous ARP MAY use either an ARP Request or an ARP Reply packet.So it seems in the end a Gratuitous ARP could be either Opcode 1 or Opcode 2 — the vendor is free to implement it as they choose. But an ARP Announcement must be Opcode 1. Section 3 of RFC 5227 has more information on this.
In the end, Gratuitous ARP and ARP Announcements serve the same purpose — trigger an ARP cache update from everyone on the local network.
(I may update the post with a note mentioning this and pointing to this comment for more details. I’m going to hold off a bit and do a bit more research before doing so though)
I have a printer that sends our gratuitous ARPs. That doesn’t seem to find any of your use cases.
Hi Jon, good point. I’ve added a section to account for what your Printer is doing. Hope it helps.
Your blogs are helpful. You make things easy to understand. Thank you.
Your explanations are very clear and helpful.
But I have a question about the whether the gratuitous ARP is sent out as ARP request or ARP response since the result of google shows that it is sent out as gratuitous ARP.
Thank you.~
If the
opcodefield is a2then technically the ARP payload is a Response. You can always validate it against the packet capture of Gratuitous ARP provided at the bottom of the article.Glad you enjoyed the article =)
This is one and one article clearly explained about GARP.
Thanks a lot!
In theory what if you have 2 active/standby devices that are going to share a mac but the IP address between the two are different. Lets say when the active device (Device A) fails, the standby (Device B) sends a Gratuitous ARP with his own address but the same mac, would the ARP table take Device A’s ARP entry out of the table? or would there be 2 ARP entries with the same mac address for two different IP’s in the table?
EX:
1.1.1.1 xx:xx:xx:xx:xx:xx
1.1.1.2 xx:xx:xx:xx:xx:xx
The ARP mapping wouldn’t be a problem. It is possible and entirely within specifications to have multiple IP addresses map to the same MAC address.
The problem would be the underlying switch. Hosts may send packets to 1.1.1.1 or 1.1.1.2, but the L2 frame in both cases contains only the shared MAC address. The switch will not distinguish the frames by their IP header, and instead will deliver all frames to only one of the devices at a time.
For that reason, shared MAC addresses while not also sharing IP addresses (and complete redundancy) is not recommended.
When a computer is joined to the network and sends a Gratuitous ARP, all devices on the network receive and add IP ADDRESS AND MAC ADDRESS to their tables. The asking is whether afterwards everyone who received the Free ARP also sends the same Free ARP to the computer that had just joined the network and sent the Free ARP or is it another type of package that is sent?
Client’s are free to do what they please in response to a new hosts’s Gratuitous ARP. Although typically, they avoid caching the information learned in the Gratuitous ARP until they actually need to speak directly with the new host. Consider, there might be 100 hosts on a network, but generally they only need to speak with the default gateway and not each other. It could be a waste of resources to keep track of all the ARP mappings of a bunch of neighbors on your network which you never need to send traffic to.
After a fresh boot-up of a machine, does a host/machine perform G-ARP with opcode2 or is it a ARP-Probe(to check ip conflict first)?
assuming arp probe will always be followed by arp announcement(if no conflict detected)
Typically an ARP Probe, so that it doesn’t inadvertently cause an ARP mapping to update to a conflicting IP address. I talk about this in this section of the ARP Probe article:
https://www.practicalnetworking.net/series/arp/arp-probe-arp-announcement/#probe-packet
And yes, as far as I know, if there is no conflict, an ARP Probe is always followed with an ARP Announcement.
Wireshark does not capture free arp packets (opcode2). Only arp announcement packages (opcode1). While running wireshark on the windows 10 computer, I turned on the other computers, but wireshark does not capture free arp (opcode2) packages from the machines that are being connected.
Not sure what to tell you, Odairmar. Gratuitous ARP’s are certainly sent. It might be that you didn’t capture packets for long enough? Or that your Wireshark settings was preventing the capture of L2 broadcast frames? Try setting your capture to Promiscuous mode to see if that helps. You can also download the Gratuitous ARP packet capture above to study them in wireshark, if you want.
Maybe it’s the switch I use. I’ve already configured the switch to mirror all traffic and and same like this didn’t work. I used wireshark on Windows and also tried Ubuntu 18.04. The promiscuous mode option is already enabled. It may be that the driver is not letting the network interface go into mode promiscuous mode. I really don’t know what the problem is. I did these tests using the TL-SG108E switch. I may not have configured his port mirroring correctly.
Thank you so much! You are best.
You’re welcome!
Thanks a lot, I wasted my time searching for this in Google.
You have explained everything in a detailed manner. And the diagrams are really great.
Happy to help.
Gratuitous ARP is also a great ARP poisoning tool, highly recommended if you’re mischievous.
I just read the comment in your article and from what I understand then a “Gratuitous ARP” (Opcode 1) is the same “ARP Announcement” – Opcode1 – but with different names. And “Gratuitous ARP” with – Opcode2 – also serves the same purpose as “Gratuitous ARP” – Opcode1 – and “ARP Announcement”. Unless the computer that just joined the network sends a “Gratuitous ARP” – Opcode1 – in order to receive the MAC from hosts that were already connected and the “Gratuitous ARP” – Opcode2 – in order to send its own MAC to the computers that were already connected. I didn’t really understand.
Gratuitous ARP and ARP Announcement serve the same purpose — update the ARP cache of neighbors with the ARP entry of the sendor. Gratuitous ARP can be Opcode 1 or 2. ARP Announcements must be opcode 1. Details here: https://datatracker.ietf.org/doc/html/rfc5227#section-3
The explicit different between ARP announcements and Gratuitous ARP is most likely splitting hairs, given they serve the same purpose.
The main one to keep separate from these is ARP Probe, which by design must not update the ARP cache of it’s neighbors.
I just read the rfc and there’s a note that says: What Stevens describes as ‘Gratuitous ARP’ is exactly the same package that this document refers to by the more descriptive term ‘ARP Announcement’. Gratuitous ARP “opcode1”
Hi Ethan,
We have a interesting problem at our company and it can be related to GARP.
Scenario
Host A is connected to a switch but must be replaced with Host B. Host B must reuse IP from Host A. It’s not possible to use DHCP or another IP.
Often we see that Host B will not be correctly connected to the network – but clearing ARP-table in router solves the problem.
The affected hosts are pretty dumb hosts, like PLCs and similar. We never see this problem when using modern windows computer.
Can a possible solution be to enable GARP in Host B, to make sure Host B will broadcast it’s existence for router to update ARP with new mac-adress but the same IP?
(This is causing a lot of problem in our operations and as usual, the network is the problem..)
Best regards
Jones
Yes. That sounds like an ARP issue. It seems the other devices on the network are still using the old ARP mapping. Windows Clients typically have very low ARP timeouts (30s or less), so changes in ARP mappings on the local network are detected much quicker.