http/https stickiness for proxied clients

aquilinux · ‎05-06-2010

hello. i am going nuts trying to configure http client session stickness but maybe i'm missing something.

my scenario is:

client IP ---> WWW ---> (public ip) apache reverse proxy HTTP/HTTPS (ace vip)---> ACE module (IIS rservers) |---> IIS srv1/srv2

first, i tried to configure http-cookie stickness like:

policy-map type loadbalance first-match BL-PP
class class-default
sticky-serverfarm COOKIE-STICKY-PP

sticky http-cookie ACE-ID COOKIE-STICKY-PP
cookie insert browser-expire

timeout 720
timeout activeconns
replicate sticky
serverfarm FARM-PP

sooner or later (and randomly) i get switched to the second IIS server, ACE-ID cookie is lost and replaced with other ID.
it happens almost always when switching fron HTTP to HTTPS but sometimes it happens in plain HTTP.

i think i do not need ssl termination, since HTTPS is only spoken between client and apache RP.

i tried bypassing apache reverse proxy and pointing clients to the ACE VIP ip but it happens too.
i tried configuring http-header too, but with same results.

am i missing something?
maybe "parameter-map type http" configuration?
i'm stuck on a dead point. can anyone help me?

thanks

Sean Merrow · ‎05-06-2010

Hello,

Sounds like what is happening is that the browser is eventually initiating a new session without the cookie, and therefore being load balanced and sent a new cookie. You might want to remove the browser-expire option, which will have that line only have cookie insert. Now, the timeout you have configured will take affect (720 minutes). Currently, the browser will expire the cookie it is using at the end of its current session.

Let me know if that works,

Sean

aquilinux · ‎05-07-2010

hi sean, thanks for your quick reply.

i did extensive tests but sessions sometimes still get lost.

whenever the session breaks, ACE sends a Set-Cookie as if he does when starting a new sticky session.

if you are "lucky", then you are given the same ACE-ID and it seems to you nothing has broken down, but then you realize you have a different ASP-Session-ID and sooner or later you know your browsing will exit with session errors.

i think it doesn't depend on cookie lenght, since cookies size is below ACE default length.

so, in conclusion, there's no apparent difference between using a browser-expire directive or not.

i suspect that the when the connection is switched from HTTP to HTTPS the ACE switch to the other rserver.

i'll try to stick to HTTPS from the beginning to see what is the behaviour.

cheers.

Sean Merrow · ‎05-07-2010

The only time the ACE will do a new set-cookie is when the client comes in without a cookie. Then, the ACE will perform load balancing according to the predictor, then set the cookie again. By default, the cookie will expire in 24 hours. When you set the browswer-expire, the ACE will not include any expiration datetime in the cookie and therefore, the browser will expire the cookie at the end of the current session. This means that if the browser launches a new session, then the new session will not stick to the same server. Sometimes it will be load balanced to the same server and sometimes it won't.

At this point, you should upload your config. Also, get a capture of the tengig port between the Sup and the ACE of your connections so we can see where it breaks.

I'll be out for the next week, so responses may take a while.

Sean