When an active/standby pair moves a virtual IPv4 address to the standby, how does the standby's gratuitous ARP redirect LAN hosts and Ethernet switches?
answer
- two tables can be stale
- IP-to-MAC versus MAC-to-port
- own MAC or shared virtual MAC
- the frame's source teaches switches
- repeat it; broadcast is lossy
basics
~20 sThe new holder broadcasts an ARP Announcement for the virtual IP. Hosts that cached the address overwrite its MAC, and every switch relearns the frame's source MAC on the new port, so traffic shifts without waiting for timeouts.
solid answer
~50 sTwo different tables can be stale after the move. Hosts' **ARP caches** map the virtual IP to a MAC; switches' **MAC address tables** map a MAC to a port. The standby broadcasts gratuitous ARPs with sender IP = target IP = the virtual address. If the address moves with the standby's **own MAC**, the payload is what matters: RFC 826's merge rule makes every host with an entry overwrite it. If a **shared virtual MAC** moves with the address, host caches were already right, and the frame is what matters: its Ethernet source is the virtual MAC, so each switch relearns it on the standby's port instead of sending traffic to the dead node. Either way it is unacknowledged broadcast, so it is sent several times. Deciding which node holds the address is the redundancy protocol's job, not ARP's.
go deeper
Remember that after a failover the new holder announces the address with a gratuitous ARP, so neighbours stop sending to the node that failed.
Separate the two tables: host ARP caches (IP to MAC) from the ARP payload, switch MAC tables (MAC to port) from the frame's source address. Say which one is stale with an own MAC versus a virtual MAC.
Cover what makes it work in practice: repeats because broadcast is lossy, timing against port readiness, the router as the host that matters to remote clients, hardened receivers, and a surviving old holder.
Weigh own-MAC against virtual-MAC designs: one depends on every host accepting unsolicited ARP, the other only on switches learning a source address, and both rest on a link where any sender is believed.
## The situation Two nodes share one **virtual IP** (VIP): an IPv4 address that clients use, held by whichever node is currently active. A redundancy protocol, a cluster manager or an operator decides when the standby takes over; that decision is outside ARP. What ARP has to solve is the aftermath: every device on the LAN that remembers where the address used to be must learn where it is now, and it must learn quickly, because traffic sent to the old location is lost. ## Two tables, two kinds of staleness There are two separate pieces of state on the link, held by different devices: - **ARP caches** on hosts and routers map *IPv4 address to MAC*. They are filled by ARP (RFC 826) and aged out by the implementation's own mechanism (RFC 1122 requires one, without fixing a value). - **MAC address tables** on Ethernet switches map *MAC to port*. A switch fills them by reading the **source** MAC of every frame it receives, and forwards by **destination** MAC. Which of the two is wrong after a failover depends on what moves with the address: | Design | Host ARP caches after the move | Switch MAC tables after the move | What the announcement fixes | |---|---|---|---| | VIP moves with the standby's **own MAC** | wrong: still map the VIP to the failed node's MAC | already right for the standby's MAC | the ARP payload: sender hardware address = standby MAC | | VIP moves with a **shared virtual MAC** | already right: the MAC did not change | wrong: the virtual MAC still points at the old port | the Ethernet frame: source MAC = virtual MAC | VRRP, for example, uses a virtual MAC from the IANA block `00-00-5E-00-01-00` to `00-00-5E-00-01-FF` that RFC 9542 records; other designs keep each node's own MAC. ## What happens on the wire 1. The standby takes ownership of the VIP. 2. It broadcasts an ARP Request to `ff:ff:ff:ff:ff:ff` with sender IP = target IP = the VIP and sender hardware address = the MAC that should now receive the traffic (its own, or the virtual one). 3. Every switch floods the broadcast and, on the way, learns the frame's source MAC on the port it arrived from. A virtual MAC that used to sit behind the failed node's port now sits behind the standby's. 4. Every host and router on the link runs RFC 826's receive algorithm: if it already has an entry for the VIP, it overwrites the MAC with the sender hardware address. Hosts with no entry add nothing and will resolve the address when they need it. 5. The standby repeats the announcement a few times, because an Ethernet broadcast is never acknowledged and one lost copy leaves some devices stale. ## Details that decide whether it works - **The router on the segment is a host too.** Clients on other subnets never see the announcement; they reach the VIP through a router, and it is that router's ARP cache that must change. If the router misses or ignores the announcement, every remote client fails at once. - **Send it when the port forwards.** An announcement sent before the standby's link is up, or while its switch port is not yet forwarding, is lost; implementations commonly send a burst and repeat it after a short delay. - **Request form, not reply.** RFC 5227 notes that some receivers drop unsolicited or broadcast ARP Replies, while broadcast Requests are universally expected. - **Hardened receivers.** Some implementations ignore unsolicited ARP, or refuse to change an entry updated very recently, to resist poisoning. Those hosts stay stale until their own cache entry expires, which is the main reason designs choose a shared virtual MAC. - **A surviving old holder.** If the "failed" node is still alive and still answering for the VIP, both nodes' ARP packets merge into caches in turn and hosts flip between them; a node implementing RFC 5227 also detects the other's packets as an address conflict. The fix is in the election, not in ARP. ## The trade in one sentence Gratuitous ARP gives coordination-free failover because RFC 826 believes any sender, and that same belief is what lets a forged announcement steal the address; how attackers exploit it and how switches filter it belong to ARP spoofing defence.
- If the virtual IP keeps a shared virtual MAC, why send a gratuitous ARP at all?Because the switches are stale even though the hosts are not. Each switch's MAC table still maps the virtual MAC to the failed node's port, so frames for it go there and are lost until the entry ages out. The announcement's Ethernet source is the virtual MAC, so every switch on the path relearns it on the standby's port the moment the broadcast passes through.
- Why can remote clients break after a failover even though every LAN host updated?Remote clients never see the announcement: ARP is link-local. They reach the virtual IP through the segment's router, so only the router's ARP entry for the VIP matters to them. If the router missed the broadcast, or ignores unsolicited ARP by policy, it keeps forwarding to the old MAC until its own entry expires, and every off-subnet client fails together.
- What goes wrong if the old active node is still up and still answering for the address?Both nodes send ARP packets claiming the virtual IP with different MACs. RFC 826's merge rule makes each host overwrite its entry with whichever arrived last, so traffic flips between nodes and connections reset. A node implementing RFC 5227 also detects the conflict. ARP cannot settle it; the redundancy mechanism must ensure only one holder.
A change-of-address notice pinned on the building's noticeboard: everyone who had your old flat written down crosses it out and writes the new one, people who never knew you ignore it, and the mailroom notes which door the notice came from.
saying these in an interview costs you the question
- With a shared virtual MAC no gratuitous ARP is needed, since nothing changed.
- Switches learn where a MAC lives from the ARP payload's sender field.
- One gratuitous ARP is enough because Ethernet delivers broadcasts reliably.
- Clients on other subnets update their own ARP caches from the announcement.
- The gratuitous ARP is what decides which node becomes active.