Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
11.5.0, 11.5.1, 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, 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.5.10, 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, 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
Opened: Oct 13, 2015 Severity: 4-Minor
The use of a clone-pool with a pool member which mac-address doesn't have an entry in the BIG-IP fdb causes a big unbalancing in CPU usage by tmm threads. This is caused by outgoing clone pool traffic from one HSB being DLF(Destination Look Up Failure)ed back to another HSB.
Extra load on tmms attached to port 0 of each HSB.
On dual HSB platforms (10000 series, 10300 series, 12000 series and B4300 blades), a virtual server with a clone pool configured. The clone pool member has a static arp entry but no fdb entry for the destination mac address due to misconfiguration of static arp entry.
Try to avoid the situation of configuring static arp entries for the clone pool member only. So either: 1. Do not configure static arp or fdb entry for the clone pool member, and let BIG-IP resolve both dynamically 2. or correctly configure both static arp and fdb entries for the clone pool member.
None