Last Modified: Jan 16, 2019
See more info
Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 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, 220.127.116.11, 18.104.22.168, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1
Opened: Jan 11, 2018
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.