03-16-2007 01:25 PM
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.
Solved! Go to Solution.
03-19-2007 08:40 AM
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.
03-19-2007 02:55 AM
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.
03-19-2007 07:24 AM
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."
03-19-2007 08:40 AM
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.
03-19-2007 09:59 AM
Many thanks, your reply cleared my misunderstanding.
Cheers,
John.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide