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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: