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

Last Modified: Nov 07, 2022

Bug Tracker

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

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

Fixed In:
11.5.4 HF2

Opened: Jan 22, 2014
Severity: 2-Critical
Related Article:
K16852

Symptoms

If APM is provisioned, after uploading a new SecurID config file via the GUI, mcpd restarts and fails to sync on device group peers.

Impact

The peer receiving the sync restarts mcpd, which in turn restarts several other daemons. The peer never receives the config file properly.

Conditions

This happens on a device group peer with APM provisioned, only after using the GUI to update the SecurID configuration. This can also happen on chassis secondary blades.

Workaround

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

Fix Information

The fix changes the behavior of transactions. Previously, if a single transaction contained a delete operation and a modify of the object just deleted, the outcome was that the object was deleted and the modify was silently ignored. This was different behavior from a delete followed by a create, which ignored the delete and internally modified the object. Since that modify is sent to the peer as a modify, the object must have the same behavior as a delete-plus-create operation. So the new behavior is that, when a single transaction contains a delete followed by a modify of the same object, then the delete is ignored and the modify is applied.

Behavior Change

With this release, there is a change to the behavior of transactions. Previously, if a single transaction contained a delete operation and a modify of the object just deleted, the outcome was that the object was deleted and the modify was silently ignored. This was different behavior from a delete followed by a create, which ignored the delete and internally modified the object. Since that modify is sent to the peer as a modify, the object must have the same behavior as a delete-plus-create operation. So the new behavior is that, when a single transaction contains a delete followed by a modify of the same object, then the delete is ignored and the modify is applied.