01-18-2008 08:23 AM
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.
"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
01-18-2008 12:10 PM
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
01-18-2008 12:47 PM
I thought it had something to do with the cookie so i changed the timeout to 1 min but that still doesn't work.
01-19-2008 12:30 AM
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.
It marks the stickyness issue as "expected behavior".
Should you find a solution i would be very happy to hear about it. :)
Roble
01-21-2008 05:10 AM
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
01-22-2008 08:03 AM
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?
01-23-2008 12:34 AM
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
01-23-2008 01:06 AM
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
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