Bug ID 509400: vCMP VIPRION: internal flooded unicast packets with multi-slot trunks impact performance

Last Modified: May 29, 2024

Affected Product(s):
BIG-IP vCMP(all modules)

Known Affected Versions:
11.6.1, 11.6.0

Fixed In:
12.0.0, 11.6.1 HF2

Opened: Feb 26, 2015

Severity: 3-Major

Related Article: K36089384


Occasional duplicated ICMP replies to a guest self-IP by multiple TMMs in a multi-slot guest. Also results in guest unicast traffic showing up in the host VLAN tcpdump because by design, a flooded unicast packet visits the host TMM and is then sent to the appropriate guest.


Packets and connections continue to flow but more broadcast traffic than expected runs through the vCMP host TMM. This can cause extra CPU utilization and switch drops.


When a blade can receive traffic for a vCMP guest that is not deployed on its own blade, L2 learning inconsistencies can result in the FDB entry for the guest VLAN MAC timing out and causing unicast floods (destination-lookup-fail) packets. For example, in a 4-slot trunk and a 3-slot guest topology, the one slot not hosting the guest is subject to FDB entry timeouts due to normal traffic flow.


This situation is corrected any time the guest sends out a broadcast packet on its VLAN MAC. For example, the normal action of TMM emitting an ARP for an external node (for example a monitor whether reachable or not) can correct the situation because the ARP will update all the blades' internal FDB entries for the guest VLAN MAC and halt the flooded unicast situation until the FDB entry times out again.

Fix Information

There is no longer duplicate traffic on vCMP guest when a blade can receive traffic for a vCMP guest that is not deployed on its own blade.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips