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

Last Modified: Apr 10, 2019

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.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:
11.6.0

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

Symptoms

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

Impact

The result is an indeterminate ARL/FDB state.

Conditions

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.

Workaround

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