<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic CSS 11500 SSL Stickiness in Application Networking</title>
    <link>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562266#M32003</link>
    <description>&lt;P&gt;Does anyone know what the "Layer 4 hash value" is mentioned in the documentation under ssl-l4-fallback?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Our standard SSL content rules look like:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: #008080; font-family: courier new,courier;"&gt;&amp;nbsp; content layer5rule &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; vip address 123.45.67.89 &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; port 443 &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; protocol tcp &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; application ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; advanced-balance ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; add service server1.dmz_ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; add service server2.dmz_ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; active &lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;</description>
    <pubDate>Wed, 29 Sep 2010 19:22:01 GMT</pubDate>
    <dc:creator>ryankogel1</dc:creator>
    <dc:date>2010-09-29T19:22:01Z</dc:date>
    <item>
      <title>CSS 11500 SSL Stickiness</title>
      <link>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562266#M32003</link>
      <description>&lt;P&gt;Does anyone know what the "Layer 4 hash value" is mentioned in the documentation under ssl-l4-fallback?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Our standard SSL content rules look like:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: #008080; font-family: courier new,courier;"&gt;&amp;nbsp; content layer5rule &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; vip address 123.45.67.89 &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; port 443 &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; protocol tcp &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; application ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; advanced-balance ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; add service server1.dmz_ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; add service server2.dmz_ssl &lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; active &lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;</description>
      <pubDate>Wed, 29 Sep 2010 19:22:01 GMT</pubDate>
      <guid>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562266#M32003</guid>
      <dc:creator>ryankogel1</dc:creator>
      <dc:date>2010-09-29T19:22:01Z</dc:date>
    </item>
    <item>
      <title>Re: CSS 11500 SSL Stickiness</title>
      <link>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562267#M32004</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="http://httpd.apache.org/docs/1.3/mod/core.html"&gt;http://httpd.apache.org/docs/1.3/mod/core.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;The MaxKeepAliveRequests directive limits the number of&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; requests allowed &lt;SPAN style="color: #ff0000;"&gt;&lt;STRONG&gt;per connection&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;this is per connection....so not related to the ssl sessionid which is only sent at the beginning of the connection.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="http://httpd.apache.org/docs/2.2/mod/mod_ssl.html"&gt;http://httpd.apache.org/docs/2.2/mod/mod_ssl.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Check the SSLSessionCacheTimeout if you want to play with session id timeout.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Personnally, I would suggest you don't touch anything.&lt;/P&gt;&lt;P&gt;This method has been working for many people for a long time.&lt;/P&gt;&lt;P&gt;If you have a sticky issue, open a TAC case and we can assist you.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Also be aware that old SSL version do not have the session id, so you can't stick those clients.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Gilles.&lt;/P&gt;&lt;H2&gt;&lt;A id="SSLSessionCacheTimeout" name="SSLSessionCacheTimeout"&gt;&lt;/A&gt;&lt;/H2&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 30 Sep 2010 12:56:20 GMT</pubDate>
      <guid>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562267#M32004</guid>
      <dc:creator>Gilles Dufour</dc:creator>
      <dc:date>2010-09-30T12:56:20Z</dc:date>
    </item>
    <item>
      <title>Re: CSS 11500 SSL Stickiness</title>
      <link>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562268#M32005</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;generally &lt;SPAN style="color: #008080; font-family: courier new,courier;"&gt;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&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE style="margin: 0em;"&gt;This command is to insert&amp;nbsp; 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.&lt;BR /&gt;&lt;BR /&gt;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&lt;BR /&gt;in which case you may wan tto consider terminating ssl on the css (would need an ssl card) and using cookie sticky.&lt;/PRE&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 30 Sep 2010 13:28:19 GMT</pubDate>
      <guid>https://community.cisco.com/t5/application-networking/css-11500-ssl-stickiness/m-p/1562268#M32005</guid>
      <dc:creator>litrenta</dc:creator>
      <dc:date>2010-09-30T13:28:19Z</dc:date>
    </item>
  </channel>
</rss>

