Last Modified: Dec 10, 2018
See more info
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
12.0.0, 11.6.1 HF2
Opened: Feb 26, 2015
Related AskF5 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.
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.