Last Modified: Mar 17, 2021
See more info
Known Affected Versions:
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, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 11.6.4, 11.6.5, 126.96.36.199, 188.8.131.52, 184.108.40.206, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4
Opened: Mar 25, 2015
Related AskF5 Article: K16997
VXLAN tunnels rely on the TMM for maintaining ARL entries representing MAC address to endpoint mappings. The BIG-IP system may undergo a brief period of inconsistency in VXLAN ARL entries across the TMM instances.
During the period of inconsistency, the TMM instances may forward packets destined to the same remote MAC address to different endpoints. This lasts until the network misconfiguration is corrected and the conflicting ARL entries expire.
Network misconfiguration can lead to a period where the BIG-IP system receives alternating encapsulated frames with the same source MAC address from two different endpoints. This leads to conflicting, alternating ARL updates across the TMM instances. One example of network misconfiguration is the configuration of the same MAC address at two different endpoints/VTEPs. Also if the VXLAN topology contains an L2 forwarding loop, this could lead to the same effect. Currently, VXLAN does not have a standard mechanism for detecting and avoiding loops. Therefore, loops need to be avoided by network configuration. However, network HA failover typically does not lead to a period of conflicting, alternating ARL updates.
In addition to addressing the network misconfiguration, the condition can be mitigated by using a shorter ARL timeout. This can be done by modifying the bigdb variable vlan.fdb.timeout.