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

Last Modified: Dec 10, 2018

Bug Tracker

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

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

Fixed In:
12.0.0, 11.6.1 HF2

Opened: Feb 26, 2015
Severity: 3-Major
Related AskF5 Article:
K36089384

Symptoms

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.

Impact

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.

Conditions

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.

Workaround

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