Bug ID 759968: Distinct vCMP guests are able to cluster with each other.

Last Modified: Oct 16, 2023

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

Known Affected Versions:
13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.1.2, 15.0.0, 15.0.1

Fixed In:
15.1.0, 15.0.1.1, 14.1.2.1, 13.1.3, 12.1.5

Opened: Feb 28, 2019

Severity: 1-Blocking

Symptoms

-- Distinct vCMP guests are able to cluster with each other. -- Guests end up having duplicate rebroad_mac on one or more slots. This can be checked using below command: clsh tmctl -d blade tmm/vcmp -w 200 -s vcmp_name,tmid,rebroad_mac Check the 'rebroad_mac' field for duplicate mac addresses. vcmp_name tmid rebroad_mac --------- ---- ----------------- default 0 02:01:23:45:01:00 vcmp1 0 00:00:00:00:00:00 vcmp5 0 02:01:23:45:01:04 vcmp6 0 00:00:00:00:00:00 vcmp7 0 02:01:23:45:01:06 vcmp8 0 00:00:00:00:00:00 vcmp9 0 02:01:23:45:01:08 vcmp10 0 02:01:23:45:01:0A <-------------- vcmp11 0 02:01:23:45:01:0A <--------------

Impact

Only the vCMP guest acting as primary will be operative.

Conditions

-- It is not yet clear under what circumstances the issue occurs. -- One of the ways this issue occurs is when guests are moved between blades and they end up having a non-null and duplicate 'rebroad_mac' on one or more slots.

Workaround

-- Disable clusterd from sending packets over tmm_bp by turning off the db variable clusterd.communicateovertmmbp: modify sys db clusterd.communicateovertmmbp value false. To disable the db variable on the affected guest, log in to the TMOS Shell (tmsh) by entering the following command: tmsh Then run the following commands, in sequence: stop sys service clusterd modify sys db clusterd.communicateovertmmbp value false start sys service clusterd save sys config Afterwards, the affected guest might still have the wrong management IP address. To resolve that, log into the vCMP Hypervisor and force a management IP update such as changing the netmask and then changing it back. With the above steps, the duplicated rebroadcaster MAC still shows, but the vguests are in stable states. To fix the duplicated MAC problem, apply the workaround (on all blades) documented in K13030: Forcing the mcpd process to reload the BIG-IP configuration :: https://support.f5.com/csp/article/K13030. Important: Applying procedure described in K13030 interrupts traffic.

Fix Information

The vCMP guests no longer end up having a non-null and duplicate 'rebroad_mac' on one or more slots. Distinct vCMP guests are no longer able to cluster with each other.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips