My background is more in L1-L4, and recently I have been assigned to the ACE project to provide SLB (I know what were they thinking :-) )
I am now having to really understand the handshaking mechanism the various protocols are using for successful communication (Client and Server)
Majority of my customer applications are secure web apps. Currently Foundry is used for load-balancing. Sticky is used in foundry, and it is based on session ID tracking.
I am trying to determine what options do I have for SSL Sticky configuration, so I can pass that on to the WEB app owners, in order to configure the ACE module.
I know ACE provides the following sticky methods for HTTP:
1) IP address stickiness tracks Source IP, Destination, or both IP address in the request Packets
2) HTTP header stickiness tracks the value of an HTTP hearder field in the HTTP request
3) Cookie stickiness tracks the value of the cookies in the HTTP request and response.
I created some configs using Session ID tracking using the following:
sticky layer4-payload sessid
layer4-payload offset 43 lenght 32 begin-pattern "\x20"
\**** the following class map detects which SSL version, V3 or TLS
class-map type generic match-any SSL-v3-32
match layer4-payload regex "\x16\x03\x00..\x01.*"
match layer4-payload regex "\x16\x03\x01..\x01.*"
What other methods can SSL Stickiness be activated on the ACE?
Thanks in advance for any feedback you can provide.
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.
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.