Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP Install/Upgrade, TMOS, vCMP
Known Affected Versions:
10.0.0, 10.0.1, 10.1.0, 10.2.0, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 11.0.0, 11.1.0, 11.2.0, 11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 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, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4
Fixed In:
12.1.0
Opened: May 22, 2015 Severity: 2-Critical Related Article:
K16749
When a primary cluster member is disabled, it relinquishes primary-ship to an enabled cluster member. If none exists, it remains as a 'disabled primary,' and the next enabled member to join the cluster will immediately become the primary. In this scenario, the newly joined cluster member will overwrite the cluster's current configuration with its loaded configuration, which may be old, blank, or otherwise invalid. Furthermore, the newly joined cluster member will force the other members to run the same software version as it, which may cause a software upgrade or downgrade on the other members, if they are running a different version.
The configuration will be overwritten by the one present on the newly joined cluster member. Unless the original configuration was backed up, it will be irretrievably lost. The pre-existing cluster members may also upgrade or downgrade their running software version to match that of the newly joined member.
This issue is only triggered when a new enabled member joins a cluster whose primary member is disabled, which in turn can only happen if all present members in the cluster are disabled when the new member joins.
To prevent this issue, do not cause a new enabled cluster member to join a cluster whose primary member is disabled. To do so, simply make sure there exists at least one enabled cluster member that is primary before adding a new cluster member. This will prevent a newly joined cluster member from becoming the new primary and overwriting the configuration.
This release correctly shows the prompt status in the case where no primary has been elected by adding '(NO PRIMARY) ' rather than 'P' for primary or 'S' for secondary. Previously, all blades would show 'S' for secondary, which is misleading. Also, the prompt does not show a status of 'PRIMARY DISABLED' if no primary has been elected.