Last Modified: Sep 13, 2023
BIG-IP LTM, MA-VE
Known Affected Versions:
18.104.22.168, 22.214.171.124, 13.1.3, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 13.1.4, 126.96.36.199, 13.1.5, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 14.1.2, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168
Opened: Apr 27, 2019 Severity: 3-Major
The Address Resolution Protocol is used to allow IP endpoints to advertise their L2 (Ethernet MAC) addresses, and to query their network peers to request needed associations. Typically, TMM will immediately broadcast an ARP announcing its IP-MAC association (sometimes called a "gratuitous" ARP), so that switches can begin directing traffic to the self-ip immediately. When BIGIP-VE starts with interfaces provided by some hypervisors, it may not immediately know the MAC address assigned to the interface until several milliseconds after the interface is created. In these cases, the gratuitous ARP will contain the MAC address 00:98:76:54:32:10, which is a valid but incorrect MAC address. Normally, this is harmless, because the correct MAC address is immediately announced once it is known. However, it may be possible for a L2 switch upstream from multiple BIGIP-VE instances to believe a L2 loop has developed, and block one or both ports through which it saw the gratuitous ARPs.
If an upstream switch sees gratuitous ARPs from multiple downstream BIG-IP instances on the same L2 LAN, it might block connectivity to one or more ports through which the gratuitous ARPs are seen. The self IP may appear to have connectivity for some time after it comes up, before connectivity is blocked at the upstream switch.
BIG-IP VE, version 13.0.0 or later, running with the virtio driver on an OpenStack-compatible hypervisor.
Gratuitous ARPs sent with an incorrect MAC address are no longer broadcast.