ACE - Problem with sticky and sorry serverfarm

Darren Sasso · ‎01-18-2008

I have a sticky serverfarm configured with a sorry serverfarm for when the site is out of service. All works well when i

take "rserver host "TEST.MICROCHIPDIRECT.COM_01". The requested then hit the "TESTBOX" which is the out of service page. The

problem is when i refresh the out of service page it never switches back to "TEST.MICROCHIPDIRECT.COM_01" until i open a new

window or clear the connections. I'm running the most recent version of code Version 3.0(0)A1(6.3).

I read that the following needs to be configured but i dont even have an option for that in the config.

http://www.cisco.com/en/US/customer/docs/interfaces_modules/services_modules/ace/v3.00_A1/configuration/slb/guide/classlb.html#wp1049254

"predictor hash source-ip"

I can only configure the below hash and i'm not sure if that is the same.

"predictor hash address source"

***Just to not I read through the previous posting about the same problem but wasn't able to pull up the bug related to this***

rserver host TEST.MICROCHIPDIRECT.COM_01

ip address 10.10.204.200

inservice

rserver host TEST.MICROCHIPDIRECT.COM_02

ip address 10.10.204.201

inservice

rserver host TESTBOX

ip address 10.10.204.245

inservice

probe http HTTP_TEST

interval 5

faildetect 1

passdetect interval 5

passdetect count 1

request method get url /aceprobe/

expect status 200 200

expect regex PROBE_UP

serverfarm host TEST.MICROCHIPDIRECT.COM_SF

predictor hash address source

probe HTTP_TEST

rserver TEST.MICROCHIPDIRECT.COM_01

inservice

serverfarm host TESTBOX_SF

predictor hash address source

rserver TESTBOX

inservice

sticky http-cookie TEST_MICROCHIPDIRECT TEST_MICROCHIPDIRECT

cookie insert browser-expire

timeout 20

replicate sticky

serverfarm TEST.MICROCHIPDIRECT.COM_SF backup TESTBOX_SF

class-map match-all TEST.MICROCHIPDIRECT.COM_VS_443

2 match virtual-address 10.10.215.41 tcp eq https

class-map match-all TEST.MICROCHIPDIRECT.COM_VS_80

2 match virtual-address 10.10.215.41 tcp eq www

class-map match-any TESTBOX_VS

2 match virtual-address 10.10.215.30 tcp eq www

3 match virtual-address 10.10.215.30 tcp eq https

4 match virtual-address 10.10.215.30 tcp eq ftp

5 match virtual-address 10.10.215.30 tcp eq ftp-data

class-map type http loadbalance match-any HTTP_443_L7

2 match http url .*

policy-map type loadbalance first-match TEST.MICROCHIPDIRECT.COM_443_L7SLB

class TEST.MICROCHIPDIRECT.COM/PROG

sticky-serverfarm TEST_MICROCHIPDIRECT_PROG

class class-default

sticky-serverfarm TEST_MICROCHIPDIRECT

ssl-proxy client test.microchipdirect.comSSL

policy-map type loadbalance first-match TEST.MICROCHIPDIRECT.COM_80_L7SLB

class class-default

serverfarm REDIRECT_TO_HTTPS

policy-map type loadbalance first-match TESTBOX

class HTTP_443_L7

serverfarm TESTBOX_SF

class class-default

serverfarm TESTBOX_SF

ssl-proxy client test.microchip.comSSL

policy-map multi-match VIPS

class TESTBOX_VS

loadbalance vip inservice

loadbalance policy TESTBOX

loadbalance vip icmp-reply

ssl-proxy server test.microchip.comSSL

class TEST.MICROCHIPDIRECT.COM_VS_80

loadbalance vip inservice

loadbalance policy TEST.MICROCHIPDIRECT.COM_80_L7SLB

loadbalance vip icmp-reply

class TEST.MICROCHIPDIRECT.COM_VS_443

loadbalance vip inservice

loadbalance policy TEST.MICROCHIPDIRECT.COM_443_L7SLB

loadbalance vip icmp-reply

appl-parameter http advanced-options HTTP-PARAM

ssl-proxy server test.microchipdirect.comSSL

interface vlan 204

interface vlan 215

service-policy input VIPS

Roble Mumin · ‎01-18-2008

I have the same problem. The reason is your static cookie.

When the client hits the sorry server he gets a new static cookie but this time the cookie for the sorry server with a default TTL of 24 hrs.

So when your productive server comes back up and your client hits the ACE again he will show a still valid cookie to the ACE and therefore get redirected to the sorry server.

AFAIK Cisco calls this "works as designed".

You can either switch to dynamic cookies and remove the "cookie insert" which unfortunately doesn't work well for me. Or as a second choice you can take the sorry server out of service until "all" clients have received a new cookie. But that is a quite bad solution because you can never know if all clients have the "good" cookie.

I planned on opening a TAC-Call for the dynamic cookie. But as long as this is the designed behavior with "insert cookies(static)" there is nothing you can do about it.

Roble

Darren Sasso · ‎01-18-2008

I thought it had something to do with the cookie so i changed the timeout to 1 min but that still doesn't work.

Roble Mumin · ‎01-19-2008

If you change the cookie to 1 min TTL "after" the client already received the cookie it will AFAIK not be applied until the cookie is issued again.

Have a look at the following link.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsi61812

It marks the stickyness issue as "expected behavior".

Should you find a solution i would be very happy to hear about it. :)

Roble

sebastianvandijk · ‎01-21-2008

I had the same problem : http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Data%20Center&topic=Application%20Networking&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cbee9b6

Solved it by using the predictor hash address source.

The sticky thing is a bug and will be solved in V2

Darren Sasso · ‎01-22-2008

I read through your posting and that is how i have it configured utilizing the 'predictor hash address source'. I also changed the timeout to 1 minute but that didn't help either. Look at my config above and what is V2? I'm assuming version 2 or something but is that a new release coming out soon?

sebastianvandijk · ‎01-23-2008

Hi Darren,

I mean version 2 indeed. I received the roadmap from a TAC engineer. There is mentioned version 2 to be released somewhere around march. But it doesn't guarantee that.

But it guess, since you still use sticky for the cookies your problem won't be solved by the way i managed to work arround.

gr

Sebastian

Roble Mumin · ‎01-23-2008

Version 2 seems to be the holy grail feature wise. The sticky thing is really annoying but i would rate it as cosmetical issue currently.

If your Application is working properly you won't see that issue to often.

Roble