CSS 11500 SSL Stickiness

ryankogel1 · ‎09-29-2010

Does anyone know what the "Layer 4 hash value" is mentioned in the documentation under ssl-l4-fallback?

Our standard SSL content rules look like:

content layer5rule
    vip address 123.45.67.89
    port 443
    protocol tcp
    application ssl
    advanced-balance ssl
    add service server1.dmz_ssl
    add service server2.dmz_ssl
    active

advanced-balance SSL is supposed to use the SSL3 session ID for stickiness. It seems to me that this shouldn't be very sticky. Our Apache servers have MaxKeepAliveRequests 100. I'd expect a new SSL3 session ID after 100 requests. Round-robin load balancing should kick in and the user could possibly end up on a different server.

The comments around the Layer 4 hash value make me suspect that something more complicated is happening though. Why is it that this stickiness works at all?

Gilles Dufour · ‎09-30-2010

http://httpd.apache.org/docs/1.3/mod/core.html

The MaxKeepAliveRequests directive limits the number of requests allowed per connection

this is per connection....so not related to the ssl sessionid which is only sent at the beginning of the connection.

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

Check the SSLSessionCacheTimeout if you want to play with session id timeout.

Personnally, I would suggest you don't touch anything.

This method has been working for many people for a long time.

If you have a sticky issue, open a TAC case and we can assist you.

Also be aware that old SSL version do not have the session id, so you can't stick those clients.

Gilles.

litrenta · ‎09-30-2010

generally advanced-balance ssl is not the best sticky for L4 ssl, since today many server s and clients (IE in particular) will renegotiate session id . ssl l4 fallback comes into play only when ssl is V2 or 3 packets go in either direction in beginning (retransmissions) without session id. here is how it works

This command is to insert  L4 hash value to sticky table when CSS sees
SSL hello or SynACK re-transmittions more than 3 times,which means CSS
will use L4 src-ip sticky from now on, not using SSL session ID for
sticky.

Default is ssl-l4-fallback enable and behaves as explained above.

If you disable, CSS will not fall back to L4 even it sees many
re-transmittions.

In the real world situation, we way only see this problem that CSS
loading more traffic to one server (due to original behavior of L4 fall
back) than another if user has some kind of NAT device or mega-proxy in front which
will make CSS see limited tuple of src-ips and ports.

When that tuple tries many re-transmittions, You will see CSS falling
back to L4 from SSL sticky.

Generally if you are loadbalancing ssl at layer4 you should be using src-ip sticky rather than session id. Again this is problematic in the megaproxy instance
in which case you may wan tto consider terminating ssl on the css (would need an ssl card) and using cookie sticky.