Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP vCMP
Known Affected Versions:
11.4.1
Fixed In:
11.5.0, 11.4.1 HF9
Opened: May 07, 2013 Severity: 2-Critical Related Article:
K15136
Under certain conditions, a new or less desired cluster member's configuration might become the active configuration.
The configuration might change or become factory default between instances of a live cluster.
This can occur when the cluster is active, goes dormant, and becomes active again. There are two forms of this: 1. The VIPRION hardware cluster has a new or differently configured blade inserted while all of its members are not available (rebooting, resetting, powered off, etc.). 2. The vCMP guest deployed on VIPRION hardware has multiple slots. The guest was powered off or brought to a configured before being deployed again. The guest has slots added while in a configured state, or at least one guest's vdisk image is created on a new slot at provisioning/deployment time (and therefore not migrated).
When adding additional slots to a vCMP guest, you should leave the vCMP guest in state 'deployed' to keep the extant slots running. Only add slots to a running guest, not configured guests. Similarly, only add new blades to a live cluster.
In this version of software, the cluster synchronized configuration files have version control, so that a new blade or guest slot's configuration cannot overwrite the higher version of any existing configuration on any potential cluster primary member.
An internal revision control system has been introduced for handling configuration deltas on VIPRION blades and VIPRION hosted vCMP guests.