Last Modified: Nov 25, 2025
Affected Product(s):
BIG-IP DNS
Known Affected Versions:
15.1.10.8, 16.1.6.1, 17.1.3, 17.5.1.3
Opened: Nov 10, 2025 Severity: 3-Major
Gtmd may display incorrectly associated the name of a virtual server, as known to the LTM device, with more than one virtual-server defined in the GTM configuration This can lead to inconsistent probe results and misleading service availability information in GTM, where a gtm virtual server may reflect the status of a different LTM virtual server.
Incorrect virtual server state from gtmd's point of view, which may show services up that are actually down or down which are actually up.
This issue occurs when multiple gtm server ... virtual-servers { ... } objects are configured with the same external address but distinct internal (translation) addresses. For this configuration to be effective, there must be logic in the network's NAT function that performs address translation based on the content of the incoming request, for example by using the SNI value of a TLS handshake, so that multiple internal virtual servers can share the same external IP address. In such cases, the ltm_name learned from a big3d probe reply for one virtual server may be incorrectly associated with all virtual servers sharing that external IP. As a result, subsequent <vip> probes may use the wrong ltm_name and reflect the status of an incorrect LTM virtual server.
Specify the ltm-name on each virtual server, so that the learned ltm_name from the big3d reply is never used: tmsh modify gtm server gtmserver1 virtual-servers modify { gtm_name_vs1 { ltm-name ltm_name_vs1 } gtm_name_vs2 { ltm-name ltm_name_vs2 } gtm_name_vs3 { ltm-name ltm_name_vs3 } } Note that the "ltm name" field can only be set using tmsh or API calls - it is not exposed in the BIG-IP GUI configuration utility.
None