Last Modified: Nov 07, 2022
See more info
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, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 12.1.4, 13.1.0, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 13.1.1, 18.104.22.168, 22.214.171.124, 14.0.0, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 14.0.1, 14.1.0, 22.214.171.124
15.0.0, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11
Opened: Apr 26, 2018
FQDN ephemeral pool members and corresponding FQDN ephemeral nodes may not be created if multiple FQDN template pool members are created rapidly, without the corresponding FQDN template nodes being created first. The missing FQDN ephemeral pool members may be created an hour after initial operations.
One or more FQDN ephemeral pool members may not be created, which could result in a pool with no members, and any virtual servers using that pool to fail to pass traffic.
This may occur when all of the following conditions are true: -- Multiple FQDN template pool members are created rapidly, such as during config load or multiple FQDN template pool members created in a single tmsh cli transaction, without the corresponding FQDN template nodes being created first. -- The FQDN names in the newly-created FQDN template nodes all resolve to the same IP address.
The following steps, alone or in combination, may help avoid this issue: 1. Avoid rapid creation of multiple FQDN template pool members (such as by creating multiple in a single tmsh CLI transaction). 2. Create the corresponding FQDN template nodes first, before creating the FQDN template pool members. Once this issue occurs (such as, after a config load), you can recover from this condition by deleting and recreating the FQDN template pool members that have no corresponding FQDN ephemeral pool members. In addition, creating the corresponding FQDN template nodes first, with an FQDN 'interval' value set to a shorter timeout than the default (3600 seconds) allows automatic recovery from this condition after the configured FQDN 'interval' period (instead of after the default period of one hour).
Ephemeral pool members are now created for each pool under these conditions.