Last Modified: Jul 13, 2024
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
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, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 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
Opened: Nov 13, 2015 Severity: 2-Critical
On configuration reload, runtime objects such as FQDN ephemeral nodes are removed. The ephemeral node refresh process (performed by bigd) continues to run on the existing interval. If the interval is large, such as the default 3600 seconds (1 hour), this can lead to pool members taking an unexpectedly long time to repopulate. For example, if the interval is 1 hour, and an ephemeral node is created, then half an hour later, the config is reloaded, and the ephemeral node does not refresh for another 30 minutes.
FQDN ephemeral nodes do not repopulate their pool until the configured TTL interval expires.
This always occurs, but with large intervals, the delay before the node is repopulated is more noticeable, and might impact normal operation.
Although this is as-designed behavior, it might produce unexpected results. To work around the behavior, you can restart the bigd process to cause the TTL timer to be reset, and force the ephemeral nodes to be immediately repopulated. As a mitigation, you can set a lower TTL interval so that the refresh occurs more often: -- Restart the bigd process by running the following command: tmsh restart sys service bigd. Note: Restarting this service should not have any impact on traffic. -- Configure a lower TTL interval by running the following command: tmsh modify ltm node example.org fqdn { interval 60 } Note: There is still a delay, but it is shorter.
None