Bug ID 524657: Inserting a blade into a chassis with a disabled primary results in overwritten configuration and software upgrade/downgrade

Last Modified: Apr 10, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP Install/Upgrade, TMOS, vCMP(all modules)

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 HF10, 11.5.1 HF11, 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.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.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.4, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 9.6.1

Fixed In:

Opened: May 22, 2015
Severity: 2-Critical
Related AskF5 Article:


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.

Fix Information

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.

Behavior Change