Bug ID 522024: Config sync of SecurID config file fails on secondary blades

Last Modified: Mar 17, 2021

Bug Tracker

Affected Product:  See more info
BIG-IP APM(all modules)

Known Affected Versions:
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.10, 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, 11.6.5,,,

Opened: May 07, 2015
Severity: 3-Major
Related AskF5 Article:


After uploading a new SecurID config file using the GUI, mcpd restarts and fails to sync the file to the secondary.


The secondary blade restarts mcpd, which in turn restarts several other daemons. The secondary blade never receives the config file, so if it becomes primary, it does not have the correct configuration.


If APM is provisioned, and upload a new SecurID config file via the GUI. This can also happen on device group peers.


Use tmsh: tmsh modify apm aaa securid secureid-name config-files modify { sdconf.rec { local-path /path/to/sdconf.rec } }.

Fix Information


Behavior Change

There is a change in the behavior of transactions. Previously, if a single transaction contained a delete followed by a modify of the object just deleted, the object was deleted and the modify was silently ignored. This is different behavior from a delete followed by a create, which ignores the delete and internally modifies the object. The new behavior is that when a single transaction contains a delete operation followed by a modify operation, the delete is ignored and the modify is applied.