Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
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.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, 13.1.5, 13.1.5.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, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 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, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 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
On rare occasions, when using FQDN nodes/pool members and the FQDN name resolves to a different IP address, it may be possible for the ephemeral pool member for the old IP address to be removed, but a new ephemeral pool member for the new IP address might 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 If this problem were to occur, the 'setFQDNPoolMembersModified' log message would not followed by a 'PoolMember::scan' log message: [D]: setFQDNPoolMembersModified: pool /Common/my_fqdn_pool node /Common/my_fqdn_node fqdn my.fqdn.com
If this issue occurs, pools configured with FQDN-based pool members may become empty, in which case no traffic will be processed by that pool.
It is theoretically possible for this to 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. However, this issue has not been observed on current BIG-IP releases which contain related FQDN fixes, particularly the fix for ID 803233. If you suspect you have encountered this issue, you are encouraged to contact F5 support for further investigation.
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.
None