Last Modified: Oct 17, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6
Opened: Oct 09, 2017 Severity: 3-Major
When a transaction attempts multiple commands (delete, create, modify) for the same object in the same transaction, the results can be unexpected or undefined. A common example is: 'transaction { delete key create_if key }' where the transaction will attempt to 'delete key', and then 'create_if key', which unmarks the delete operation on the key (so in this case the key remains unmodified). In other cases it is possible that monitoring stops for the associated object, such as for: pool, pool_member, node_address, monitor.
The monitor-related object may be unchanged; or monitoring may stop for that object.
A user-initiated transaction attempts multiple commands for the same monitor-related object, such as (delete, create, modify).
Transactions modifying a monitor-related object (pool, pool_member, node_address, monitor) should perform a single command upon that object (such as one of: 'delete', 'create', 'modify').
None