Hi Raman,

Since you already have a good feel on matching against L7-content and src-address as your sticky-parameter, I'll stick with the 'cookie-insert' feature. Personally, this is also the one I'm most experienced with.

The "easy" way to apply cookies as your sticky-parameter, is to use the cookie-insert feature. For each rserver in the serverfarm to which you're loadbalancing, ACE generates a value containing an alphanumerical value (e.g R89245151, can't remember excatly how many digits). This value represents the actual rserver, I think it's a hashed value of the rserver ip-addr and port, but I'm not sure. Furthermore, I think this value is "recalculated" each time the corresponding rserver is taken out-of-rotation, e.g for maintanence purpose. When the ACE sees the first client request, it decides which rserver to forward the traffic to and inserts the corresponding cookie into the http-header. However, only the first clientrequest is processed using the cookie-value. All sub-sequent requests are forwarded to the same rserver without the ACE inspecting the L7-header for the cookie. This is mainly to preserve ressources, as L7-inspecting is somewhat more demanding than simple L4-inspection. You can instruct the ACE to inspect all sub-sequent client requests for the cookie, using a paramter-map with the 'persistence rebalance' feature.

Optionally, you can create static cookie-values, using the 'static cookie-value' feature. This let's you generate your own cookie-values and assign them to a rserver. The benefit of this feature from my point of view is, that it provides better information on the rserver, e.g for trouble-shooting purpose. On the other hand, using a hashed value as described above, means less exposure of your webservers, if indeed this is deemed a security-risk-factor.

Also, when configuring stickyness, make sure to allocate sufficient ressources for the individual context (if you're running multible context-mode). Otherwise, you might face some problems with stickyness. Also, the default-timeout for a sticky-session as I recall, is 24 hrs, so you might consider decreasing the value using the 'timeout' value under sticky-configuration. Finally, if you're running your ACE in a fault-tolerant setup, make sure to apply the 'replicate sticky' under your sticky-configuration. This ensures, that the sticky table is maintained in the event of a module-failover.

As far as SSL-termination goes, you simply install your SSL-certificates on the ACE and configure your ssl-proxy services, chain-groups and parameter-maps. If you're not already familiar with SSL-configuration on the ACE, try taking a look at this http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/ssl/guide/sslgd.html.

The basic operation of SSL-offloading/termination on the ACE, is that the ACE performs the ssl-handshake with the client and forwards the traffic to the rserver unencrypted. So infact, the client never interacts directly with the webserver, but with the ACE acting like a proxy. This makes good sense, since ssl-offloading is quite CPU-intensive for a webserver and the ACE provides hardware-support for ssl-offloading and can, depending on your license, handle up to 15k SSL/TPS pr. second and 200k proxied connections simultaneously. To my knowledge, this exceeds most webservers capabilities. Futhermore, using the ACE to offload ssl, means less administrative overhead handling ssl-certificates, as they only need to be installed on the ACE-modules.

I'm not sure wether the ACE supports passive-cookies, but I can't see why i shouldn't, but maybe someone else can comment on that. As far as your question "Can you have termination in one direction using Cookie insert, and  session ID in other direction?", I'm not sure I understand it. But from my understanding, you can only apply in method of stickyness for each L4-class, so if you need to loadbalance traffic going the opposite way, you need to configure a new policy for that, since the ACE only processes traffic inbound.

hth

/Ulrich

Hi Raman,

Thanks, I appreciate that.

Indeed, one of main benefits of deploying ACE is providing a "single-point-of-entry" to a group of webservers, without being dependent on a more traditional clustering technology. And in terms of ssl-processing, the ACE does quite well, provided that you buy the appropiate license :-). But as long as end-to-end encryption is required, ACE only solves parts of the processing-problem.

Another feature I'm quite fond of, are the probes, as they can be tailor-made to provide you with (almost) any kind of health-check you need. Also, as you mentioned, the load-balancing predictors. There are however a few things you might want to take into consideration, if using for instance 'leastconn' predictor. While leastconn prediction provides for a more intelligent ditribution of connections to your webservers, in my experience, it doesn't really take into account the fact, that the number of active connections are not always indicative of the actual load on the webserver, if for instance, one of theese connections takes up a lot of cpu. Also, if a rserver has been taken out of rotation for maintanence, it will re-enter rotation with zero connections and thus, ACE will throw a lot of traffic its way to even out the overall number of connections. This can however be avoided by applying something called 'slowstart', where the rserver re-enters rotation, but the ACE will gradually send traffic its way based on the timers set for the slowstart feature. Then again, using least-loaded (requires the use of snmp probes) or reponse predictors, will consider e.g cpu-usage and server-response-time as a load-balancing parameter.

/Ulrich