Bug ID 508797: Clarification regarding differences in GARPs on different versions.

Last Modified: Nov 07, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
10.2.4, 11.0.0, 11.1.0, 11.2.0, 11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 12.1.4,, 12.1.5,,,, 12.1.6

Opened: Feb 24, 2015
Severity: 3-Major


The Gratuitous ARP (GARP) behavior when a virtual is disabled varies quite a lot of between the different versions. This request is for more information about: 1. Explanation of the differences in behavior between 11.2.1 or 11.3.0 and 11.5.0 or 11.0.0, and 10.2.4 2. Is the GARP behavior supposed to be the same for different 'active' scenarios for the VS, such as VS disable/enable, fail-over, unreachable/reachable pool etc.? 3. Are GARPs supposed to be sent for the different kinds of addresses like floating/non-floating IP addresses, VIP whose state changes, other VIPs, etc.? 4. Is there a 'correct' or 'expected' behavior for GARPs under these scenarios and for the different IP addresses? The intent is to provide an authoritative summary of the differences. The current behavior summary is as follows: -- 11.5.0: Same behavior as 11.0.0. -- 11.3.0: Same behavior as 11.2.1. -- 11.2.1: Disabling a VIP sends GARPs for non-floating and floating IP addresses, and for other VIPs, but NOT for the VIP being disabled. -- Enabling a VIP sends a GARP only for the VIP being enabled. -- 11.0.0: Disabling a VIP sends GARPs for non-floating and floating IP addresses, for other VIPs, and for the VIP being disabled. -- Enabling a VIP sends GARPs for non-floating and floating IP addresses, for other VIPs, and for the VIP being enabled. -- 10.2.4: Disabling or enabling a VIP produces no GARPs at all, neither for the VIP being toggled, nor for others.


Extra GARPs are sent on some versions.


Following is a summary of the minimally-correct behavior for GARPs: -- On startup or after failover, send out GARPs for all /32 IP addresses. (The system does not send out GARPs for a listener on a subnet, for example.) -- When a virtual server is disabled, there should not be any GARPs. Although there is no issue with a GARP in this instance, they are not necessary. -- When a VIP is added, a GARP is required only if the IP address is not already being used. -- When a VIP is removed, there should be no GARPs. -- When a pool is unreachable or reachable, there should be no GARPs. -- When a virtual server is disabled/enabled, there should be no GARPs in most cases. The only case in which there should be a GARP is when a system is brought online with a disabled virtual server that is then enabled, but the system has never sent a GARP for that IP address. -- On failover, the new active system should GARP for all virtual addresses. When using mac masquerading, this would not be necessary, except that the system must inform the switch of the new location, and that is done via GARP. In this case there is a need for only one packet for anything; there is no need for GARPs for every IP address: In fact, there is no need for GARPs at all; if there is a packet sent, that should be sufficient for the switch. -- GARPs should only be sent for fully-qualified ID addresses. State changes do not require GARPs. Floating IP addresses are only GARPd in order to inform the switch of the new location to send the packets. The system uses GARP for this, but what the BIG-IP system sends does not have to be the GARP.



Fix Information


Behavior Change