Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 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.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 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
Fixed In:
13.1.0
Opened: Aug 08, 2017 Severity: 4-Minor Related Article:
K19963260
In v11.6.0 through v13.0.0 implementations of the FQDN feature, ephemeral Node Address objects were tagged with a name including the FQDN that created them, for example, 'www.f5.com-10.20.30.40'. The problem lies in the fact that a Node Address object may be referenced by more than one FQDN, if they happen to resolve to the same IP address.
Not only can it be confusing if an ephemeral Node Address object refers to an FQDN other than the one expected (because more than one FQDN may resolve to the same IP), but it may cause operational issues when the ephemeral node needs to be deleted.
This can be observed when viewing pool members for pools that contain FQDN nodes.
None.
Starting in v13.1.0, ephemeral Node Address objects will be given generic names, e.g., '_auto_10.20.30.40'. The linkage to the FQDN template node that created them will be logical, but not encoded in the node name. This is largely a cosmetic change.
In v11.6.0 through v13.0.0 implementations of the FQDN feature, ephemeral Node Address objects were tagged with a name including the FQDN that created them, for example, 'www.f5.com-10.20.30.40'. Starting in v13.1.0, ephemeral Node Address objects will be given generic names, e.g., '_auto_10.20.30.40'. The linkage to the FQDN template node that created them will be logical, but not encoded in the node name.