Bug ID 552328: Clone pools - Traffic to a pool member with no fdb entry causes CPU unbalancing

Last Modified: Apr 10, 2019

Bug Tracker

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

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

Opened: Oct 13, 2015
Severity: 4-Minor

Symptoms

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.

Impact

Extra load on tmms attached to port 0 of each HSB.

Conditions

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.

Workaround

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.

Fix Information

None

Behavior Change