Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.5.1 HF1, 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.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.0, 11.5.1, 11.5.2, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.0.0, 11.6.0 HF5, 11.5.3
Opened: Mar 25, 2015 Severity: 3-Major Related Article:
K17096
In a VXLAN tunnel, a remote MAC address movement from one endpoint to another does not trigger ARL updates across all TMMs. As a result, some TMMs may contain stale ARL entries which can impact traffic forwarding. Also, when using 'tmsh show net fdb tunnel', there is a duplicated MAC address associated with different endpoints in the same tunnel.
This issue could impact traffic forwarding in VXLAN tunnels.
When a remote MAC address is moved from one endpoint to another. For example, when a BIG-IP system in an HA setup configured with a masquerading MAC address changes its state from 'standby' to 'active'.
Although there is no complete workaround, you can mitigate the situation by making sure that the network is properly configured so that every device uses a unique MAC address. For example, in a network with an HA setup, try not to use masquerading MAC addresses.
This version of software more consistently handles the condition of a remote MAC address being moved from one endpoint to another.