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

Last Modified: Jan 16, 2019

Bug Tracker

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

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, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 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, 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

Symptoms

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.

Impact

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

Conditions

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.

Workaround

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