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.
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.
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: