21-Sep-2021 05:53
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!
Solved! Go to Solution.
30-Sep-2021 08:44
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.
30-Sep-2021 08:44
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.
30-Sep-2021 09:40
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
01-Oct-2021 06:12
This will work, but as stated in updated answer above, probably not advisable.
01-Oct-2021 06:45
Thanks for taking the time to help Jason. Really appreciate. 😀
11-Oct-2021 16:27
Hello Jason!
I read even more and labbed a ton the past few days. And I agree with you. Adding a bunch of IPs to the iQuery mesh is doable but injects some not so pretty secondary issues.
For starters, if one of your BIG-IP DNS looses one of the interfaces it uses to communicate with the other DNS in the sync-group, you have to make sure it can route through the secondary interface. This becames an issue if you use non-bigip monitors (gateway-icmp, http and so on). For example. DNS1 is on DC1 and DNS2 is on DC2. They both have two device IPs. Usually, one of these interfaces is going to be the default route and the other will not.
If you loose the main one, let's say on DNS2 on DC2, since DNS1 still sees DNS2 as UP it expects the probe results from it. And if you use non-bigip probes, DNS2 will report lot's of stuff down since it no longer have the default route.
This is just one case. This can get out of hand very quickly I think.
Just added this as a note for future reference for anyone looking at this.
16-Mar-2023 11:42
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.