topic Re: ACE with sticky http-cookies across two server farms issue in Application Networking

ACE with sticky http-cookies across two server farms issue

Paul Cummings — Wed, 06 Apr 2011 11:43:53 GMT

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

Virtual server name: www.somedomain.com
Virtual IP: 2.2.2.2
TCP/443 (https)
SSL Termination - Proxy service name: www.somedomain.com (all keys and certs loaded and correct)
L7 Load Balancing - **inline** rule match HTTP URL:(/AuthenticateMe/).* Action : Sticky, Group: StickyGroup2, SSL Initiation enabled (www.somedomain.com)
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

Re: ACE with sticky http-cookies across two server farms issue

Surya ARBY — Wed, 06 Apr 2011 12:46:16 GMT

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.

Re: ACE with sticky http-cookies across two server farms issue

Paul Cummings — Wed, 06 Apr 2011 13:01:20 GMT

Surya,

Thanks for your response.

Could you clarify what you mean by 'clear text' in the backend for farm2?

Cheers

Paul

Re: ACE with sticky http-cookies across two server farms issue

Surya ARBY — Wed, 06 Apr 2011 13:18:46 GMT

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 ?

Re: ACE with sticky http-cookies across two server farms issue

psinghmandla — Wed, 06 Apr 2011 13:33:06 GMT

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

Re: ACE with sticky http-cookies across two server farms issue

Surya ARBY — Wed, 06 Apr 2011 13:35:33 GMT

Open a case, maybe cisco can build a special release for you. Otherwise what you want to do is not supported.

Re: ACE with sticky http-cookies across two server farms issue

Surya ARBY — Fri, 08 Apr 2011 05:36:54 GMT

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.