GSLB Services and Port numbers

[Chris Craddock]

Community,

 

I may have already asked this question but cannot find where I did. I am a little confused about what role the Port plays when creating a GSLB Service. All the documentation defines it as is "Port on which the load balancing entity represented by this GSLB service listens" but I don't know what that means exactly. Does this mean that the GSLB Service Port has to match that of the port the load balancing VS you are tying to it is listening on? So for instance if you made a GSLB Service on port 443, you couldn't tie a LB VS listening on port 80 to it?

 

I thought GSLB was just DNS and the actual destination port the packets are destined to should be handled by the Load Balancing potion of the Netscaler and not the GSLB. I'm a little confused about this one. If I may I would like to posit a scenario:

 

LB VS: 172.16.1.1:443 (has Redirect From Port 80 enabled)

LBVS: 192.168.1.1:443 (has Redirect From Port 80 enabled)

GSLB Service: Bound to 172.16.1.1:443 and 192.1681.1:443

 

Would incoming traffic on port 80 be successfully handled by GSLB even though the GSLB Service and LB VS's are on 443?

 

Thank you very much for any insight you can provide. 

 

[Rhonda Rowland1709152125]

Fundamentally, a  GSLB decision dynamically determines which IP to return in response to a DNS resolution for a managed FQDN.  The GSLB service represents the potential IP for the GSLB-based FQDN to resolve to.  And from that context, the port doesn't matter in the dns resolution.

 

However, determining the service up/down state is related to how regular load balancing works and monitor types must match the service type being monitored. So a http-monitor for an http service (ip:port combo); tcp monitor  for tcp service, ldap monitor for ldap-based etc...  In some ways, its a holdover from the parts of load balancing that were borrowed for GSLB. The port doesn't affect the GSLB decision perse, but it affects the monitoring up/down decision making for what potential IPs are up/down.

 

If that helps.

 

So for your question (I'm going to restate differently initially) if you have a GSLB decision for a given FQDN (demo.company.com) that could resolve to either IP1 or IP2.  It doesn't matter during the dns query itself whether the client is doing an http://demo.company.com resolution or an https://demo.company.com resolution. The DNS resolution isn't based on the port; just the name to ip resolution.  From your perspective as the ADC admin, the HTTP entity is based on monitoring a service availability (gslb service) on HTTP:80 vs SSL:443...but technically you would really only be doing one or the other from a gslb name to ip standpoint.  You can make the DNS resolution decision based on one of these (not both at the same time) for a single FQDN.

 

Your LB VSERVER can easily be SSL to HTTP services.

For GSLB, usually you make your gslb vserver protocol the match for your gslb service to affect your monitor options.  But the DNS query is neither HTTP or HTTPS based.

For your GSLB:SSL example with LB vservers of type HTTP (behind the gslb services), you could just as easily have made it GSLB:HTTP.

 

If you want the client-side connection SSL, then GSLB isn't solving that. LB vservers of type SSL or CS vservers of type SSL would.

 

So for this part specifically:

 

2 hours ago, Chris Craddock said:

Would incoming traffic on port 80 be successfully handled by GSLB even though the GSLB Service and LB VS's are on 443?

 

The GSLB decision aka the dns resolution is neither http:80 or ssl:443.  What happens during the user connection of http:80 after the name resolution should then be governed by the lb vserver on 80 redirect to 443.

 

[Chris Craddock]

Rhonda,

 

Thank you so very much for taking the time to respond in such detail. Your answer makes complete sense and definitely confirms my suspicion that the GSLB Port has more to do with monitoring the actual service its bound to (the Load Balancing Virtual Server). In my case, I only care about the SSL LB Virtual Server because the HTTP Virtual Server has an "always up" service applied to it. The HTTP VS is only there to redirect traffic using a responder policy to the 443 service, which is the actual production service. So in my case, I should only have to create a GSLB service and VS based on the SSL/443 Load Balancing Virtual Server. If the SSL/443 LB VS goes down, I don't want GSLB responding for it. Since the HTTP/80 LB VS is going to be "always up" I shouldn't create the GSLB services based off of that one. 

 

Thanks again!