Trying to understand SSL sticky with CSS 11506 / ssl-l4-fallback behavior

[batsiolas]

Dear experts

I have a CSS 11506 (v7.50) which is used to load balance several SSL-based sites. We use the following textbook content rule:

content mysite-SSL

vip address 10.0.0.1

add service s01

add service s02

add service s03

port 443

protocol tcp

advanced-balance ssl

application ssl

flow-timeout-multiplier 225

active

If I read the manual correctly, SSL L3 session IDs are going to be used till a flow is set up. Then the ssl-l4-fallback (it is enabled) directive kicks in and load balancing is done based on the source IP, destination port.

However, my stats show:

Sticky Statistics - SFM Slot 1, Subslot 1:

Total number of new sticky entries is 4937735

Total number of sticky table hits is 33476045

Total number of sticky rejects (no entry) is 0

Total number of sticky collision is 0

Total number of available sticky entries is 0

Total number of used sticky entries is 131071

Total L3 sticky entries are 131

Total L4 sticky entries are 0

Total SSL sticky entries are 130940

Total WAP sticky entries are 0

Total number of SIPCID sticky entries is 0

So, why don't I see anything in the L4 sticky entries?

Also, I would expect that once the ssl-l4-fallback kicks in, a client will be always directed to the same server (since the CSS uses now source IP, dest port for load balancing). However, if I close and start again my browser I hit a different server.

Your thoughts and suggestions are highly appreciated.

John.

[Gilles Dufour]

John,

the L4-fallback kicks in if there is no usable SSLID.

If there is an SSLID the CSS is able to make a sticky decision and therefore no backup [fallback] mechanism is required.

Since you have a lot of SSL sticky entries it means the CSS is able to use the SSLID.

Gilles.

[batsiolas]

Hi Gilles

Thank you for your response. If I may ask the group for a final further clarification, so as to put this matter to rest. Since there are a lot of frames transmitted in either direction, I would expect the following to be happening and overriding the use of SSLv3 session IDs. Following is the section of the manual that seems to contradict what you say (and I see on the stats). Am I reading the manual wrong?

"Cisco Content Services Switch

Content Load-Balancing

Configuration Guide

Software Version 8.20

November 2006

page 11-14

Configuring SSL-Layer 4 Fallback

Insertion of the Layer 4 hash value into the sticky table occurs when more than

three frames are transmitted in either direction (client-to-server, server-to-client)

or if SSL version 2 is in use on the network. If either condition occurs, the CSS

inserts the Layer 4 hash value into the sticky table, overriding the further use of

the SSL version 3 session ID."

[Gilles Dufour · Accepted solution]

that's more than 3 packets BEFORE we detect the SSLID. So, in other words, if the SSLID is not within the first 3 packets we fall-back to src-ip stickyness.

Obviously your connection will have more than 3 packets, but the SSL handshake should be done after 3.

Gilles.

[batsiolas]

Many thanks, your reply cleared my misunderstanding.

Cheers,

John.