ACE cookie-based slb

Question

Hi,
I'm trying to configure a cookie-based slb method which corresponds to my current CSS11503-configuration. Basicly, my CSS performs slb purely based on the content of the arrowpoint-cookie, using the following config:
advanced-balance arrowpoint-cookie
arrowpoint-cookie name WPS6
The cookie contains the real ip of the underlying webserver and the CSS fowards traffic based on that particular content of the cookie. Whenever we need to do an unscheduled shutdown of a webserver, we gracefully take the webserver out of service by setting the weight to 0, but also, my webdepartment have implemented a feature in Websphere, that somehow sends a cookie-expire to both the SESSIONID-cookie and the WPS6 cookie. So once the subsequent http-req hits the CSS, the cookie is gone and the CSS lb'es the req to a diffent server. We've intentionally left out the sticky-option, as it didn't work well with the before mentioned Websphere-feature.
Now I'm trying to configure something similar on the ACE, but so far without luck. I did start by configuring sticky-group with the cookie-insert option and a http-parametermap with persistence-rebalance. But all attempts to recreate the above mentioned scenario, have failed. It's seems, that even with persistence-rebalance, the client-session is still stuck to the webserver and a display of the sticky-database shows, that the sticky-entry persists. Even when I manually delete the cookie-container on the client and verify with the Live-HTTP-plugin, that the subsequent http-req does not contain the WPS6 cookie, the req is still forwarded to the realserver. Even when the real-server is placed in 'inservice standby'.
Is it possible to staticly define a cookie-value for, say, 4 webservers, each with their own unique cookie? And when the initial part of the tcp is completed and the ACE decides which realserver is to be used, it sets a cookie containing that particular value and includes it in the http-response. So if any subsequent http-req's are not containing that cookie, the ACE re-balancences that req and sends it to a different webserver.
/Ulrich
PS! Merry X-mas

Answer 1

Ulrich,
what you're asking for is what ACE does currently.
The static cookies are created at configuration time.
You can see the values with "show sticky cookie-insert"
ie:
switch/Admin# show sticky cookie-insert group portalap
     Cookie   |        HashKey       |           rserver-instance
  ------------+----------------------+----------------------------------------+
  R4181073320 | 11105909834649097754 | vmware-http/vmware-27:80
  R4181109257 | 10017312105356339124 | vmware-http/vmware-28:80
  R4183409225 | 15537882249682767338 | vmware-http/vmware-46:80
  R4183517036 | 1787657754489574767  | vmware-http/vmware-49:80
Whenever we see the cookie "R...." we check if the associated server is alive and forward the connection to that server.
Otherwise we loadbalance to a new server and include the new cookie in the response.
For established connections, persistence rebalance is indeed required to inspect every request and rebalance the connection to a new server if a new cookie is detected.  However ACE will try not to rebalance when not needed.
If you need a new loadbalancing decision each time, you need 'persistence rebalance strict'.
An alternative could be the configuration of 'failaction purge' to force the connection to be terminated when the server goes down.
'inservice standby' is described @ http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/rsfarms.html#wp1000333
•Tears down existing non-TCP connections to the server
•Allows current TCP connections to complete
•Allows new sticky connections for existing server connections that match entries in the sticky database
•Load balances all new connections (other than the matching sticky connections mentioned above) to the other servers in the server farm
•Eventually takes the server out of service
As you can see, this option still allows connection to the server if it matches a sticky entry.
Gilles.