Forum Discussion

Cirrostratus

Sep 21, 2021

DNS/iQuery Question - Design Consideration

Hello devs!

All the manuals and K articles I came across regarding iQuery/DNS only states that you must have a full-mesh between all the DNS/LTMs for the iQuery to properly work. I get that.

But should that mesh be just one communication channel? At least two? Or the more the better?

To illustrate: Suppose I have two DCs. Each DC have three internet connections.

Should my mesh use just one internet link? Meaning, every server under DNS would have just one IP designated to it. That IP is the one iQuery will try to connect.

Or should I add at least two IPs for each server?

Thanks!

application delivery

BIG-IP DNS

JRahm
Sep 30, 2021
UPDATE to my incorrect original response:

big3d listens on port 4353 on all self IPs and the management IP, and from an internal doc that was pointed out to me by a fellow F5er:

"The gtmd on each GTM will attempt to establish an iQuery connection with all the servers listed in the /config/bigip_gtm.conf file that are of type BIG-IP. Furthermore, it will do this on all of the self IP addresses that are listed for each server. Those IP addresses will be the ones that the user has assigned."

That said, it's my preference to use single IPs, and that's seconded by my peer as well. If you don't manage all aspects well, you might end up with a situation where a route fails and so service is impaired, but monitors through private paths because of additional connectivity might make it appear to be just fine. As long as you manage that, you're fine, but more IPs, more paths == more complexity.

JRahm
Admin
Sep 30, 2021
UPDATE to my incorrect original response:

big3d listens on port 4353 on all self IPs and the management IP, and from an internal doc that was pointed out to me by a fellow F5er:

"The gtmd on each GTM will attempt to establish an iQuery connection with all the servers listed in the /config/bigip_gtm.conf file that are of type BIG-IP. Furthermore, it will do this on all of the self IP addresses that are listed for each server. Those IP addresses will be the ones that the user has assigned."

That said, it's my preference to use single IPs, and that's seconded by my peer as well. If you don't manage all aspects well, you might end up with a situation where a route fails and so service is impaired, but monitors through private paths because of additional connectivity might make it appear to be just fine. As long as you manage that, you're fine, but more IPs, more paths == more complexity.
- rafaelbn
  Cirrostratus
  Sep 30, 2021
  That's what I thought!
  
  So this kind of thing doesn't make much sense right?
  
  I'm better of having one IP for each device and making sure my backbone have secondary ways of reaching my iQuery mesh IPs, correct?
  
  Thanks Jason! You legend! =D
  - JRahm
    Admin
    Oct 01, 2021
    This will work, but as stated in updated answer above, probably not advisable.
tdtlee
Nimbostratus
Mar 16, 2023
i have a question in regards to iquery mesh. For the LTM mesh with the GTM. For our deployments, we have a decicated interface for iQuery connectivity to the GTM via a routed network. My question is, should the iQuery interface/connection be on an out-of-band management network? or should it go thorugh a VLAN on the Data switch. our out-of band connections are usually quite reliable and we're concern about having a false negative if we have the iquery interface on a out-of-band management switch. We're thinking if there's an odd issue with the data switch, but the LTM health monitors are still ok, but the layer 7 is acting flaky, the GTM will continue directing traffic to the VIPs on the LTM, resulting in what I call a false negative. If the iQuery path went though the data switch and there's aprobelm with the data switch, we should see issues with not only the LTM health monitors but also with the iQuery mesh.