Bug ID 429810: 2000/4000 platforms can end up in indeterminate ARL/FDB state

Last Modified: Nov 07, 2022

Bug Tracker

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

Known Affected Versions:
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

Fixed In:

Opened: Sep 05, 2013
Severity: 3-Major
Related Article:


2000/4000 platforms can end up in indeterminate ARL/FDB state under certain conditions.


The result is an indeterminate ARL/FDB state.


This occurs when one of these platforms is subjected to a stream of frames arriving from one MAC address on two different ports on a VLAN simultaneously.


There is no workaround.

Fix Information

Changes were made to unify the ARL hash tables which means that at any given point in time, ingress tracking (where needed) is not subject to having conflicting details about ingress ports depending on which tmm thread is providing the answer. It is possible that the presented ingress details will change after the ARL/FDB details are presented to mcpd, but that in itself is not an issue and should be expected to accurately reflect which port is receiving the most recent packets from a given peer "at the time" the ARL/FDB details are presented to mcpd. If the ingress path for a given host is 'floating' across multiple ports repeatedly, the ARL/FDB details should be expected to change from one invocation of 'tmsh show net fdb' to the next.

Behavior Change