Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 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, 12.1.3.1, 12.1.3.2, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1
Fixed In:
12.1.3.3
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.
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.