Skip to content

Gratuitous ARP

    Gratuitous ARP

    This article is a part of a series on Address Resolution Protocol (ARP). Use the navigation boxes to view the rest of the articles.


    Address Resolution Protocol

    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

    Gratuitous ARP - Ethernet Header

    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.

    Gratuitous ARP - ARP Packet

    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.

    This use case is often confused with an attempt to detect possible duplicate IP addresses, but a Gratuitous ARP is not used for this process. To detect an IP address conflict, hosts will use ARP Probes and Announcements, which is the topic for the next article in the Address Resolution Protocol Series.


    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 The hosts in our example will be using this shared IP address as their default gateway.

    Gratuitous ARP - Shared IP Address

    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 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 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 will always map to the shared MAC address 0053.ffff.1111.

    Gratuitous ARP - Shared IP and MAC

    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.

    You can download a packet capture of a Gratuitous ARP here. Or, you can download a packet capture of HSRP’s Gratuitous ARPs enacting the last animation of IP and MAC redundancy. Both can be studied using Wireshark.

    Series Navigation

    Proxy ARP >>ARP Probe and ARP Announcement >>

    5 20 votes
    Article Rating
    Notify of

    Newest Most Voted
    Inline Feedbacks
    View all comments

    Well said,

    I would like to add that hosts use gratuitous to check for an ip assigned by the DHCP

    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?

    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 ?

    How does the router know that the other router has stopped working?

    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.



    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.

    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) ?

    Thanks for the response.


    Great series about ARP. Thank you for explanation!
    Btw there is a typo “ffff.fff.ffff” should be “ffff.ffff.ffff”


    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.


    Vignesh R P

    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.

    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?

    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!!

    Great job Eddie!

    This article is incorrect, gratuitous ARP is performed using opcode REQUEST (1) not REPLY (2).


    @John_Smith is not talking about the ARP Announcement.
    RFC says:
    … Gratuitous ARP is documented in Stevens Networking [Ste94] as using
    ARP Request packets …

    I have a printer that sends our gratuitous ARPs. That doesn’t seem to find any of your use cases.

    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.~

    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: xx:xx:xx:xx:xx:xx xx:xx:xx:xx:xx:xx

    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?

    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)

    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.

    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.

    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.

    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.

    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.

    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

    Nice job!