Bug ID 701609: Static member of pool with FQDN members may revert to user-disabled after being re-enabled

Last Modified: May 29, 2024

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

Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3,,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1

Fixed In:

Opened: Jan 11, 2018

Severity: 3-Major


Within an LTM pool containing both FQDN members and members configured with static IP addresses; a statically-configured member that had been disabled (session = user-disabled) and then re-enabled (session = user-enabled) may become disabled again after making other changes affecting the state of other FQDN members of the pool.


A pool member may be unexpectedly disabled after being re-enabled, and thus would not receive traffic.


This may occur under the following conditions: - An LTM pool containing a mix of FQDN and statically-configured members. - A statically-configured pool member is disabled (session = user-disabled) and then re-enabled (session = user-enabled). - Other changes occur which affect the availability of FQDN pool members. For example, if a route to an FQDN pool member is deleted and recreated, a previously-disabled statically-configured member may revert to a disabled state. Depending on circumstances, the issue may only occur once after BIG-IP, TMM, bigd, or a related daemon restarts.


It may be possible to work around this issue by disabling and re-enabling the statically-configured pool member again.

Fix Information

Statically-configured pool members of a pool that also contains FQDN members remain enabled after being manually disabled then re-enabled. This issue is resolved by the FQDNv2 feature re-implementation in this version of the software.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips