Last Modified: Jul 18, 2026
Affected Product(s):
BIG-IP ASM
Known Affected Versions:
11.5.1, 11.5.1 hf1, 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.1 hf10, 11.5.1 hf11, 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.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.3.1
Fixed In:
12.0.0, 11.6.3.2, 11.5.6
Opened: Feb 05, 2015 Severity: 3-Major
An inactive ASM policy on a sync target is suddenly re-activated.
If the user deactivates or deletes a policy on one device and then pushes the ASM config to the other device, the policies will end up being reactivated (or recreated as a default policy) on the other device.
This occurs when ASM manual sync is configured, and a policy is de-activated or deleted. The time stamp of the policy does not get updated, so the active policy will take precedence and re-activate it.
The workaround is to make a change to Policy one of the machines before de-activating it, to update its timestamp to newer than the other machine.
When loading the ASM side of a UCS, ensure that the MCP data is updated correctly for policies that have become inactive or have been deleted.