Jump to content
Welcome to our new Citrix community!

Sticky method for Windows web server with multiple URLs

Recommended Posts

One of the web servers at the new gig is Windows IIS based. As the user clicks on a
link within the site the URL in their browser will change to another subdomain, 

then another. So initially they get to say https://www.bigbear.com. So no problem

for the VPX. We setup SSL_BRIDGE at the VIP and Service and we're good to 

go for load balancing. And at this point I was thinking to use SSL Session 

for the stickly algorithm. 


But today learning more about how the site works - a users first arrives

at https://www.bigbear.com - but then will click a link that could take

them to https://rates.bigbear.com. And then they click something else

and they're on https://trends.bigbear.com and then maybe



Now all during this activity they need to be sticky to the same IIS 

server. That is all those URLs would resolve in DNS to the same 

VIP address. Since that's the case, would it be best to use Source Address

or some other algorithm for stickiness? I'm assuming that each

new URL would instantiate a new SSL session negate the desired

effect of SSL Session sticky. But perhaps that's not the case?


Any other tips for load balancing this kind of dynamic URL web 

site that needs to remain sticky at one server throughout is

greatly appreciated.

Link to comment
Share on other sites

Short answer: since all your FQDNs resolve to the same VIP (assuming this is a single lb vserver and not a cs vserver), then you'd probably just need sourceip persistence as preferred over SSL Session ID. Additional info below just to round the explanation out.


The rest:

First, you're using SSL_BRIDGE, which may not be the best option IF you need more flexibility.  Without doing ssl termination on the ADC, persistence and policy options are limited.  Really, only use SSL_BRIDGE when you don't need or want the ADC to be able to do additional processing on the traffic; SSL vservers to SSL services would be preferred.  (Though for the options I would recommend it applies whether SSL or SSL_BRIDGE)


In general, if these were just SSL vservers (not ssl bridge), the following considerations would apply:

  • If all of your websites <something>.bigbear.com are on the same LB vserver just behind different FQDNs, then sourceip persistence would work or cookie insert as all requests regardless of subsite would be on the lb vserver and governed by the same persistence of the single vserver.  (This is what your scenario above states, just giving you both considerations.)
  • IF they are all on different LB vservers (or behind a single cs vserver going to different lb vservers) then a sourceip hash will mostly work (as the source ip hash should hash the same way but variations are possible).  So instead, you could implement a persistency group to guarantee that all related lb vservers follow the same persistence.  However, persistency groups limit the changes you can make to an lb vserver while its configured (you'd have to remove it from the group to make changes and add it back in when done). But both rule-based or sourceip is supported in a persistency group.  

Persistency groups can be configured under Traffic Management > Load Balancing (usually used to track persistence across lb vservers of different protocols; but it could be used here) if a different method doesn't work.  See here:  https://docs.citrix.com/en-us/netscaler/12/load-balancing/load-balancing-persistence/persistence-groups.html



If you use SSL_BRIDGE, your persistence options are narrowed but sourceip and sslsessionid can still be used.  A persistency group can also apply.  But you won't be able to do CS or other policies like rewrite, if needed.  CookieInsert won't be possible either.   If this is all one lb vserver, then the persistence applies to all regardless.


But there are some considerations when using SSL Session ID:  SSL Session ID isn't usually the best for web traffic as SSL Session IDs will get renegotiated more quickly then your actual web session (meaning multiple times during your actual user-perceived session); so persistence by ssl session id isn't usually long enough for the multiple sustained web transactions and so cookieinsert or sourceip tend to be favored.  AND it won't solve the per FQDN issue, as those would be different ssl handshakes...


We'll see if anyone gives you a different recommendation.



  • Like 1
Link to comment
Share on other sites

Thank  you so much for the thoughtful response! That different SSL handshakes was what I thought would happen as the user went from one URL to another to another (all at the same IP address). Thus it becomes not a useful sticky alg. 


The setup is one VPX LB with two web servers behind it. Any thought on how long the persistence should last? I saw the default is like two minutes. But what I have here are folks getting onto this site in the morning and staying there all day. So I'm thinking to set it to like eight hours - even 10 hours. If the user wanders off in the middle of the day to the other server that would be bad.

Link to comment
Share on other sites

The persistence length is determined by what the application(s) behind it view as a an "idle" session. At what point would that app allow the user to start a "new" transaction again, if the user hasn't interacted with the site for X amount of time.  The app should have been designed with some concept of timing or your always going to have an issue eventually.


Max persistence duration is 24 hours.  If you were using SSL (instead of ssl bridge), you could set persistence via cookie insert with timeout 0 (sessionless cookie) which would last for the browser duration as opposed to a cookie timeout from 2 minutes to 24 hours, but that wouldn't work with ssl bridge.



  • Like 1
Link to comment
Share on other sites

The situation is they want to LB this multi-domain IIS business critical server in a week and the SSL Bridge just seems like highest likelihood to succeed since we know the standalone server with its multiple subdomains works. It's just suspected to be overloaded with traffic at times. If I had more time for packet captures and working with the guy who manages it and running more test scenarios, I'd be more open to off loading the SSL or using content switching or other. 


If I could program permanent source address sticky I would. If you see traffic from this source address - always send it to Server A until the end of time unless Server A fails. Next source IP comes along send it to Server B until the end of time. And so on.


SSL Session with Source IP address backup looked intriguing. But when I looked at the details it said that you can't set the timer of the backup Source IP sticky alg. So it's not clear to me what happens if the user goes to lunch, their SSL session times out and then source IP does... I'm not sure.




For down and dirty SSL Bridging balancing - what would be more reliable: Source IP sticky with a 10 hour time out? or SSL Session with a Source IP backup?

Link to comment
Share on other sites

SourceIP as primary; backup method only used if primary can't be tracked AND you are tracking both persistences at same time (more work).


SSL Session ID isn't going to give you the length of time you need as handshakes get renegotiated.


SourceIP will be from 2 to 24 hours max; a 10 hour is a 10 hour idle period meaning user isn't interacting with site and you still want persistence remembered.


Load balancing doesn't have a permanent persistence option; though the Source IP works as a hash so like IPs should continue going to their original locations if no change in service state.  But "permanent persistence" would result in imbalanced load balancing over time. 


Now, if your app is active/passive instead of active/active distribution you have other things to look at (meaning you would send all traffic to primary service (server1) only until it fails or reaches a spillover threshold and then use the protection method backup vserver to handle traffic to backup service (server2).  You made a claim that maybe you didn't need load balancing at all except when first server is overloaded...so see if this is what you are trying to do instead.



Edited by Rhonda Rowland
add note to active/backup
  • Like 1
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...