Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

GTM Listener IP - Best Practice

I'm looking for some clarification on this topic. I've seen it mentioned in various places (ex. http://support.f5.com/kb/en-us/solutions/public/5000/400/sol5427.html) that the best practice is to use one of the BIP-IPs self-IPs as the destination listener.

"F5 recommends to always use a self IP address when defining a listener object for local name resolution. A listener object that is not defined as a self IP address cannot direct name resolution requests to BIND."

I'm using v11.6 and have my listener assigned an IP on the same subnet as my external self-IP, but it's a different IP. Upon defining my listener in this manner, it automatically created an associated Virtual Server with the defined IP and everything works fine. What is the disadvantage in deploying a listener that doesn't use the same IP as one of the self-IPs on the system? I'm trying to understand why this is a best practice. I'd imagine an anycast deployment would also be deployed not using a self-IP of the system, but rather the listener would be assigned a /32 and then advertised by a routing protocol. Similar to using a loopback interface's address for deploying anycast on a router.

Thanks, Dave

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I believe the answer is already in what you typed... e.g.

"A listener object that is not defined as a self IP address cannot direct name resolution requests to BIND"

If you don't require that (and I usually make sure that requests not serviced by GTM are dropped myself), then you have no issues AFAIK.

Possibly it's listed as not best practice because if GTM can't resolve it, you won't get any answer, and whoever wrote it wanted to make sure at least SOMETHING was given back (e.g. for addresses that ARE NOT serviced by GTM - i.e. not WideIP's).

However for most of the installs I've done, that was the DESIRED effect anyway... Because I don't like running GTM's inline with normal DNS services - i.e. I like my GTM's to be serving ONLY WideIP's.

H

0
Comments on this Answer
Comment made 02-Apr-2015 by Dave W. 7
Thanks for the response Hamish. But in v11.6 GTM, DNS express, and local BIND can answer queries directed at a listener IP that's different (but on the same subnet) than the self-IPs configured on the system. I read the quoted statement the same way as you did at first. But then I tested it and it works fine for all three. The link was last updated in 2010, so it may just be dated and no longer apply to current code versions. I'm unclear on this published best practice.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I found this old post while looking for the same information as the OP. Indeed, the behavior has changed since 11.x but some docs that pop on google don't reflect the new behavior. So here's the difference:

  • In BIG-IP 10.x and earlier, if the listener object matches a self IP address, then local BIND resolution is automatically enabled. If the listener object does not match a self IP address, local BIND resolution is disabled and query forwarding is enabled. If you define a listener object for local resolution and the listener does not match a self IP address, wide IP pools configured with the Return to DNS load balancing method will not return the desired results.
  • In BIG-IP 11.x and later, the Use BIND Server on BIG-IP option in the DNS profile dictates local BIND resolution. If the option is enabled on a listener object, it can answer from BIND. If the option is disabled, and the listener does not match a self IP address, then query forwarding is enabled. If the option is disabled and the listener object does match a self IP address, then neither BIND resolution nor forwarding is enabled, so queries that would have otherwise been handled by those methods are dropped.

Source: https://support.f5.com/csp/article/K5427

0