cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.

DNS/iQuery Question - Design Consideration

rafaelbn
Cirrostratus
Cirrostratus

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!

1 ACCEPTED SOLUTION

JRahm
Community Manager
Community Manager

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.

View solution in original post

5 REPLIES 5

JRahm
Community Manager
Community Manager

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.

That's what I thought!

 

So this kind of thing doesn't make much sense right?

 

0691T00000E0QEPQA3.jpg 

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
Community Manager
Community Manager

This will work, but as stated in updated answer above, probably not advisable.

Thanks for taking the time to help Jason. Really appreciate. 😀

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.