Bug ID 870309: Ephemeral pool member not created when FQDN resolves to new IP address

Last Modified: Aug 02, 2021

Bug Tracker

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

Known Affected Versions:
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, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2

Opened: Jan 17, 2020
Severity: 3-Major

Symptoms

On rare occasions, when using FQDN nodes/pool members and the FQDN name resolves to a different IP address, the ephemeral pool member for the old IP address may be removed, but a new ephemeral pool member for the new IP address may not be created. Under normal operation, the following sequence of messages is logged in /var/log/dynconfd.log when dynconfd logging is set to 'debug' level: [D]: setFQDNPoolMembersModified: pool /Common/my_fqdn_pool node /Common/my_fqdn_node fqdn my.fqdn.com [D]: PoolMember::scan: pool /Common/my_fqdn_pool member /Common/my_fqdn_node fqdn my.fqdn.com But when this problem occurs, the 'setFQDNPoolMembersModified' log message is not followed by a 'PoolMember::scan' log message: [D]: setFQDNPoolMembersModified: pool /Common/my_fqdn_pool node /Common/my_fqdn_node fqdn my.fqdn.com

Impact

Pools configured with FQDN-based pool members may become empty, in which case no traffic will be processed by that pool.

Conditions

This may occur under rare timing conditions while using using FQDN nodes/pool members, when the DNS server resolves the FQDN name to a different IP address.

Workaround

To recover from this condition once it occurs, perform either of the following actions: -- Restart the dynconfd daemon: bigstart restart dynconfd This temporarily interrupts queries for FQDN name resolution and updates (deletion/creation) of ephemeral nodes/pool members in response to FQDN resolution changes. This action is not otherwise expected to affect traffic currently flowing to pools. -- Remove the FQDN pool member, then re-add the FQDN pool member back to the pool: tmsh modify ltm pool my_fqdn_pool { members delete { my_fqdn_node:port } } tmsh modify ltm pool my_fqdn_pool { members add { my_fqdn_node:port <other parameters> } } If the pool already has no ephemeral pool members, this has no effect on traffic (which is already not flowing to this pool). If the pool has some ephemeral pool members but not the complete list of expected ephemeral members, this will interrupt traffic flowing to this pool while there are no pool members present. In that case, temporarily adding at least one pool member with a statically-configured IP address before removing the FQDN pool member, then removing the same temporary pool members after replacing the FQDN pool member, allow straffic to continue flowing to the pool while this action is performed.

Fix Information

None

Behavior Change