Bug ID 525989: A disabled blade is spontaneously re-enabled

Last Modified: Oct 16, 2023

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

Known Affected Versions:
11.6.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2

Fixed In:
12.0.0, 11.6.1

Opened: Jun 01, 2015

Severity: 3-Major

Related Article: K17165

Symptoms

If a secondary blade in a 'ready' state becomes primary and then quickly is disabled, it does not send a cluster packet for ten seconds. A new primary, therefore, is not elected for ten seconds (the heartbeat timeout), instead of the expected time (immediately). The other blades, including the new primary, never receive the message that the blade was set to disabled, so the blade is be re-enabled without the user requesting it.

Impact

A blade that the user expects to be disabled is spuriously re-enabled. User interfaces to access configuration, such as tmsh and the GUI might hang for the ten-second interval. The system posts an error message similar to the following: load_config_files: '/usr/bin/tmsh -n -g load sys config partitions all base' - failed. -- Unexpected Error: Saving and loading configuration is only allowed on the primary slot.

Conditions

This occurs only if the blade disable operations occur very shortly after the primary blade is moved.

Workaround

Wait ten seconds after disabling a blade before disabling another blade.

Fix Information

A previously disabled blade is no longer spuriously re-enabled if the primary blade is moved around quickly.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips