04-06-2011 04:43 AM
Hi,
We need the same sticky http cookie to applied to two server farms (which are actually the same servers but listening on different ports in each farm) to persist sessions to the same real backend server.
e.g.
Farm1 (front end HTTP service) - StickyGroup1
rserver1 - 192.168.0.1:80
rserver2 - 192.168.0.2:80
rserver3 - 192.168.0.3:80
Farm2 (SSL front end authentication service) - StickyGroup2
rserver1 - 192.168.0.1:443
rserver2 - 192.168.0.2:443
rserver3 - 192.168.0.3:443
We have setup two Sticky Groups (one for each of the farms above) both using the same cookie name e.g. cookieXYZ
Our service is behind a single virtual server configured as follows (example URL and addresses):
Virtual Server Configuration
Default L7 Load Balancing action : Sticky, Group: StickyGroup1
So normally we would expect users to first hit www.somedomain.com first and therefore Farm1, get cookieXYZ from the ACE (cookie insert is only enabled on StickyGroup1) and then be redirected to www.somedomain.com/AuthenticateMe which matches the inline URL L7 rule which directs the request at Farm2 - at this point we expected the ACE to use cookieXYZ to persist the user to the same real server hit in Farm1 but instead the stickiness doesn't seem to work.
We suspect that the ACE uses IP:port as the unique value in the Cookie ID and therefore the ACE fails to match the same real host in a different farm because we are using a mix of port numbers across farms. Is this correct? Is there another way of accomplishing what we are after with a different configuration but still the same setup with single VIP and multiple services on the backend servers?
Any suggestions or solutions appreciated.
Thanks
Paul
04-06-2011 05:46 AM
You're correct.
using the same cookie can work only if you use clear text in the back end for farm2. Otherwise try by using source IP stickyness.
04-06-2011 06:01 AM
Surya,
Thanks for your response.
Could you clarify what you mean by 'clear text' in the backend for farm2?
Cheers
Paul
04-06-2011 06:18 AM
Can you use the same service on port 80 on the servers while keeping a dual virtual servers topology (HTTP/80 HTTPS/443 with SSL offload) for the front end VIP ?
04-06-2011 06:33 AM
Hi Surya
I am working with Paul on this one.
Unfortunately, the limitation of webservice application is that :(/AuthenticateMe/).* needs to be SSL terminated on the webserver and not the ACE. I also need the SSL offload for the rest of the application virtual server performed on the ACE. Any other ideas of how we could achieve this. I'm not keen on sticky src ip due to the "megaproxy" effect we'd have for a bunch of our customers.
Regards
Pali
04-06-2011 06:35 AM
Open a case, maybe cisco can build a special release for you. Otherwise what you want to do is not supported.
04-07-2011 10:36 PM
The issue is related to the fact that it's not about persistence because there are only "new" services in the backend in SSL, you want to keep the IP address.
With a little bit of dev, the only way to acheive this is to redirect the user when he has been sent to http and adding a "tag" (cookie / token in the URL), then on the SSL virtual server, when performing SSL offload matching this tag to send to user to the right server. But it will be a 1-to-1 mapping.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide