Jump to content
Welcome to our new Citrix community!

GSLB Active/Active RTT LB method fails

Recommended Posts



I have a setup of Active / Active GSLB vservers. While static proximity works well, RTT fails constantly. I can see that LDNS table gets populated with results on both sides. I ve set site persistance "connectionproxy" on all services and source IP persistance on both Vservers.


Does anyone have any clue how to debug this further in order to find out why RTT LB fails?


Thanks in advance

Link to comment
Share on other sites

Why do you have both source ip persistence on the gslb vserver AND connectionproxy on the gslb services.

Its usually one or the other, because they approach data center persistence differently.

My guess is the connectionproxy at the service level is overriding or changing what you expect the RTT lookup to do (or because both vserver and service persistence for gslb is in effect extra weird things are happening.)


So what is your expected result and what do you think you are seeing.

As I think we'll need to explain the gslb service persistence and whether you should be doing connection proxy or http redirect Or whether the gslb vserver source ip should be good enough.

GSLB server persistence affects decisions during the dns lookup; gslb service persistence affects web traffic (http/https only) and is a deferred decision that happens after the initial gslb decision is made and then overrides at the time the user connects to the destination entity ip:port represented by the gslb service persistence.  At that point, depending on whether it is http redirect or connection proxy will change how the traffic is directed to the final destination.

See:  https://docs.citrix.com/en-us/citrix-adc/current-release/global-server-load-balancing/how-to/configure-persistent-connections.html#:~:text=Citrix recommends persistence in GSLB,Site persistence on GSLB services


Also for the gslb is this for users on network vs remote form your environment?

Link to comment
Share on other sites

Hi Rhonda,


thanks for a comprehensive answer. The setup I have is 2 citrix gateways in 2 different sites, all accessing from the internet (no internal).


I tried all possible combinations: no persistence at all, site persistence only, gslb vserver persistence only, site + vserver. None of this worked. I still keep getting LB method failed and the IP I get back from the netscaler does not match the entry in the LDNS table. I mean, I am not getting the IP with the lowest RTT. Attaching screenshot of the stats (Primary LB Method Failures).


Is there any way to debug the reason for LB method failure?


Link to comment
Share on other sites

1) you have to make sure persistence is enabled in the gslb site-to-site mep exchange.

2) So RTT method is based on rtt from adc to the client's LDNS doing the lookup based on either a ping/tcp/udp probe type under GSLB parameters.

Very possible the LDNS are not responding to any probe and therefore the backup lb method (roundrobin or other) is in use.


How are you confirming that persistence isn't occurring by the clients?

What is the RTT from the client/ldns to adc?  (What is the typical difference in latencies?)


With Gateway doing GSLB there is a complication of after the login phase, the storefront should then switch them to a site specific name.


There may be something else going on there so a different lb method may be better. But I would also start with gslb vserver persistence as sourceip first with no service level peristence.

If you decide to use serivce level persistence; httpredirect is probably what you want over connectionproxy.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...