Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

SSL sticky (persistence) options with ACE Module

Hello Everyone,

Quick background:

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

serverfarm stage

response sticky

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.

Best Regards,

raman

2 ACCEPTED SOLUTIONS

Accepted Solutions
Bronze

Re: SSL sticky (persistence) options with ACE Module

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

Bronze

Re: SSL sticky (persistence) options with ACE Module

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

8 REPLIES
New Member

Re: SSL sticky (persistence) options with ACE Module

Hello,

Could some of the Network /Engineer/Architects share some config/design models in regards to SSL Sticky design requirements/suggestions?

Sorry to make it sound so urgent, but as I'm trying to provide some recommendation to our customer about the type of features that the ACE module can support fo SSL Sticky application.

So Far this is what I have or feel comfortable with:

1) Session ID tracking [(Pro: It's ok, with parsing added) ** (CON) Not browser follows the rules or it is consistent)]

2) Source IP address [Pro: if no mega Proxy]

3) Cookie Insert: I Don't have a good understanding

Is it better to have the Server to insert cookies or ACE? Does ACE support Passive Cookie insert from Server?

If ACE inserts cookies toward clients, how does it terminate the SSL session towards the Servers? Can you have termination in one direction using Cookie insert, and session ID in other direction?

As always thank you for taking the time to provide any feedbacks!!!

Raman

Bronze

Re: SSL sticky (persistence) options with ACE Module

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

New Member

Re: SSL sticky (persistence) options with ACE Module

HI Ulrich,

Thanks for taking the time to provide the information. Everything was explained well, and I have a much better understanding.

I know you were talking about the ACE terminating the SSL session facing the Client, and sending data un-crypted toward the sever, but my customer will need end to end encryption.

Will this mode of operation be supported with cookie insert, using ACE?

If it does support this mode, will that place tremendous amount of CPU cycle, since the ACE will now have to insert cookies, terminate SSL (Client and Server), and track Stickiness from client to servers?

Very respectly,

Raman

Bronze

Re: SSL sticky (persistence) options with ACE Module

Hi Raman,

Glad you found it useful.

As far as end-to-end encryption goes, the ACE does support this, using a combination of SSL-termination (client-side) and SSL-initiation (serverside). I've never used this method though, so you might want to take a closer look at http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/ssl/guide/endtoend.html, although this document may not be sufficient. You should probably familiarize yourself with both SSL-termination and SSL-initiation, since end-to-end makes use of theese two mechanisms.

In terms of CPU-usage, I wouldn't expect a significant increase of this, since all SSL-handling, both termination and initiation is processed in hardware. The cookie-insertion in the clientside-traffic remains the same, and to the best of my knowledge, this cookie can be used as a L7-classmap value, when initiating serverside ssl-connections.

I'm not so much worried about the ACE-resources, as I am with the serverresources. In my experience, most webservers, while excellent in handling large amount of http-traffic, ssl-processing puts a lot of pressure on the CPU, unless you've installed a dedicated SSL-acceleration card. But if this is not an issue in your case and, as you mentioned, it's a customer requirement, the SSL end-to-end is the way for you to go.

hth

/Ulrich

New Member

Re: SSL sticky (persistence) options with ACE Module

Hi Raman,

SSL SessionID stickiness is not a good idea, because SSL SessionID is not constant:

https://supportforums.cisco.com/message/459511#459511

If there is no other way, don't forget:

parameter-map type generic SESSID-PARAM

set max-parse-length 76

sticky layer4-payload SESSID-STICKY

serverfarm SF1

response sticky

layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST)"

Achim

New Member

Re: SSL sticky (persistence) options with ACE Module

Achim,  thank's for the input and sample config, That helped even more..  Do you mind sharing with us in regard to the method you are using for SLB SSL application requiring sticky tracking?   My hands are full with this bad boy..  Have a great week! Raman

New Member

Re: SSL sticky (persistence) options with ACE Module

Ulrich,

Once again thank you for that excellent information you have provided. I know if you ever get tired of working as a "Network Engineer", then writing books or teaching will be your calling (if not already!).

As I have been reading more tips and documents on the SSL offload, the only benefit that I see is the sharing of server resources (server farm with multile real servers) for SSL transaction application.

Initially I was under the impression that once we purchased the ACE modules, we would remove the SSL from the Servers to the ACE to offload the CPU processing. But, with End-to-End SSL termination (ACE terminating each side) the servers will still have to perform SSL communication, but there will be more servers availabe based on the type of Load-balancing Algorithms (leastcon, roundrobin, etc..) configured on the ACE.

Now, I just have to determine which method will be the most efficient for stickiness (Cookie insert or Source/Destination). I am going to move away from session id tracking, simply because of the incosistency of various browser ( "perception" ) SSL handshaking routine/Process.

You have been a tremendous help in explaning the operation of SSL with sticky.

Best Regards,

Raman

Bronze

Re: SSL sticky (persistence) options with ACE Module

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

5114
Views
0
Helpful
8
Replies
CreatePlease to create content