Last Modified: Dec 15, 2020
See more info
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
Opened: Sep 05, 2013
Related AskF5 Article: K15576
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.
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.