Bug ID 2533557: Virtual server traffic may be reset after removing an ASM policy and performing a full configuration synchronization

Last Modified: Oct 12, 2026

Affected Product(s):
BIG-IP TMOS(all modules)

Known Affected Versions:
17.5.1.6, 17.5.1.8, 17.5.1.9, 21.1.0, 21.1.0.1, 21.1.0.2

Opened: Sep 23, 2026

Severity: 3-Major

Symptoms

On BIG-IP 17.5.1.6, removing an ASM security policy from a virtual server on one member of a Sync-Failover device group and then performing a forced full-load push can leave stale compiled LTM policy data on the receiving device After synchronization: - Both devices report an in-sync and apparently correct configuration - The removed ASM policy is absent from the virtual server configuration - Client connections to the affected virtual server are reset. TMM reports: -- F5RST: policy execution error -- The compiled runtime policy data may still contain the removed policy name -- The receiving device can retain stale compiled policy data after the full synchronization. This creates a difference between the visible configuration and the policy data being used by TMM

Impact

Traffic to the affected virtual server may be interrupted immediately after the full synchronization. Existing and new connections can receive TCP resets until the runtime policy data is regenerated Other virtual servers are not expected to be affected unless they undergo the same policy-removal and full-sync sequence

Conditions

The issue may occur when all these conditions are present: - BIG-IP 17.5.1.6 is used in a Sync-Failover device group - An ASM security policy is removed from a virtual server - The change is propagated to the traffic-active peer through a full-load configuration synchronization, including force-full-load-push - The receiving device previously had compiled policy data for that virtual server - Incremental synchronization has not reproduced the issue. Auto-sync normally uses incremental synchronization, although it can use a full load under certain recovery conditions

Workaround

Avoid forced full-load synchronization after removing an ASM policy. Use incremental synchronization where operationally possible To recover an already affected virtual server: - Reapply the ASM policy to the affected virtual server - Remove the ASM policy again using a normal configuration operation - Perform an incremental configuration synchronization - Confirm traffic passes normally - Removing and reassigning an existing virtual-server profile, such as the HTTP profile, may also regenerate the runtime policy data and restore traffic Auto-sync is the preferred temporary synchronization mode, but it is not an absolute safeguard because it may fall back to a full load when incremental synchronization is unavailable

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips