Last Modified: May 05, 2026
Affected Product(s):
F5OS (all modules)
Known Affected Versions:
F5OS-A 1.8.0, F5OS-A 1.8.1, F5OS-A 1.8.2, F5OS-A 1.8.3
Opened: Jul 14, 2025 Severity: 3-Major
If a box experiences hitting Bug ID 1759761, sometimes the workaround for that bug does not always work. The currently published workaround for that bug is: "The [vlan] deletion operation can be retried, or wait a moment after unassigning the VLAN before deleting it." However, in some cases the vlan delete will always fail because the vlan-listener for the tenant is never removed. Which means every attempt to delete the vlan will fail until the vlan-listener is removed, and any lingering fdb entries. You will see one or even a handful of vlan listeners that should not exist anymore.
VLAN-listener does not get deleted, and will show disabled.
Sometimes it will take several iterations for the vlan-listener to not be deleted in time. It's possible enabling network-manager and api-svc-gw debug logging increases the probability of hitting this bug. 1. Create and deploy a tenant 2. Copy the bash script vlan.tenant.tort.bsh to an external client 3. Modify the script to match rseries or partition mgmt ip, username, password and tenant name: ex. PARTITION_MGMT_IP=172.12.12.12 USERNAME=admin PASSWORD=admin TENANT=rdt1 4. run show vlan-listener | repeat 1 on the rSeries 5. run the script: while :;do date;bash vlan.tenant.tort.bsh 1;echo "sleeping for 10";sleep 10;done 6. As soon as the script reports it's sleeping for 10 seconds, check to see if the vlan-listener still exists from the output of #5. If its still there for 2+ seconds; kill the bash script to leave the device in that state.
There are two delays needed, which I know is less then ideal. One for Bug ID 1759761 which is before removing the vlan entirely. and A second one for Bug ID 1983061 before removing the vlan from the tenant. And both bugs are resolved by the change for 1759761 which is fixed in F5OS v2.0.0 and is unfortunately not backportable.
None