Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP APM
Fixed In:
11.5.4 HF2
Opened: Jan 22, 2014 Severity: 2-Critical Related Article:
K16852
If APM is provisioned, after uploading a new SecurID config file via the GUI, mcpd restarts and fails to sync on device group peers.
The peer receiving the sync restarts mcpd, which in turn restarts several other daemons. The peer never receives the config file properly.
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.
Use tmsh: tmsh modify apm aaa securid <name> config-files modify { sdconf.rec { local-path /path/to/sdconf.rec } }.
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.
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.