Bug ID 519004: patching "virtualServers" list, of an ASM policy, with a new LTM virtual, implicitly detaches all other ASM policies from that LTM virtual

Last Modified: Jan 29, 2019

Bug Tracker

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

Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 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, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4

Opened: Apr 20, 2015
Severity: 3-Major

Symptoms

Having: * 'ASM_policy_1' assigned to 'LTM_virtual_1' by the means of an 'LTM_policy_1'. * 'ASM_policy_2' that is not assigned to any LTM virtual. If one would send a PATCH REST request to update 'ASM_policy_2', so that it would be assigned to 'LTM_virtual_1' (the target virtual): -------------------------- "virtualServers": [ "/Common/LTM_virtual_1" ] -------------------------- The result is that: * 'ASM_policy_1' is not assigned to any LTM virtual (unassigned from the target virtual). * 'ASM_policy_2' assigned to 'LTM_virtual_1' by the means of an 'LTM_policy_2' (assigned to the target virtual).

Impact

The ASM policy that was previously assigned to the target virtual gets implicitly unassigned from it.

Conditions

ASM provisioned Two ASM policies, one of which is assigned to an LTM virtual

Workaround

Use LTM REST/GUI to assign multiple ASM policies to a single LTM virtual

Fix Information

None

Behavior Change