Forum Discussion
rafaelbn
Cirrostratus
CirrostratusDNS/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. ...
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
AdminUPDATE 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.
rafaelbnThat'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
This will work, but as stated in updated answer above, probably not advisable.
- rafaelbn
Thanks for taking the time to help Jason. Really appreciate. 😀
- rafaelbn
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.