cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
545
Views
5
Helpful
4
Replies

SSL sticky entry behaviour

trobbins5
Level 1
Level 1

What is the default behaviour of ssl sticky tables if no sticky-inact timeout is configured on any rule (i.e. value = 0) and our sticky table is consistently at the max entries of 32K in our case.

Checking the table stats, we have 0 free entries and new entries incrementing every second. Watching the oldest entries over the course of a few mins, which are about 22 hours old, I see they disappear eventually.

Does the timer on an ssl sticky entry reset to 0 every time a hit occurs? Therefore when a new entry is needed, only the oldest entries (with no recent hits) are removed ? So relatively active connections in our case may remain in the table forever assuming there is a connection every day. Is this correct ?

4 Replies 4

Diego Vargas
Cisco Employee
Cisco Employee

Hi,

I assume you are talking about a CSS. So the beahvior you are seeing is expected.

When you have no sticky-inact-timeout configured, the CSS does FIFO so if the table is full the oldest entries would get removed and new entries would be added.

Since the table can handle 32K entries it is very unlikely that you would have issues by removing the oldest entries which were probably added for sessions that were already finish.

So yes, you assumption is right.

Here is what the docs says:

Configuring Sticky Inactive Timeout

By default, new sticky connection uses the oldest used sticky entry. A sticky association could exist for a time depending on the sticky traffic load on the CSS. Use the sticky-inact-timeout command to specify the inactivity timeout period on a sticky connection for a content rule before the CSS removes the sticky entry from the sticky table. When you configure this period, the CSS keeps the sticky entry in the sticky table for the specified amount of time. The CSS does not reuse this entry until the time expires. If the sticky table is full and none of the entries has expired, the CSS rejects the new sticky request. If the sticky-inact-timeout command is specified for a Layer 5 content rule using SSL sticky, the SSL sessions continue even if the sticky table is full; however, the CSS does not maintain stickiness on the new sessions.

When the sticky connection expires, the CSS uses the configured load-balancing method to choose an available server for the request.

When this feature is disabled, the new sticky connection uses the oldest used sticky entry. A sticky association could exist for a time depending on the sticky traffic load on the CSS.

Find it here:

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v8.10/configuration/content_lb/guide/Sticky.html#wp1044284

Hope it Helps!!

Diego M

Thanks, yes a CSS.

The reason I ask is we are seeing an interesting issue where two VIPs (same IP, one http, one ssl) with the same 5 servers behind them don't seem to be load-balancing properly. About 10 clients are all hitting the same VIPs on either 80 or SSL. Port 80 requests from one client are getting LB'd to a particular server 90% of the time and the other 4 only 10%. Another port 80 client always gets LB'd to only 3 of the 5 servers, never the other 2. Finally, a few other clients are LB'd evenly to all. We see above results via IIS logs on all 5 servers over the course of a single day.

One of the clients using SSL are seeing similar results. I was thinking the SSL sticky we defined would cause the behaviour I described in the opening note. But this doesn't really explain the port 80 phenomenon of a client hitting only 1, or only 3 of 5 servers. We have only the default round-robin specified for those port 80 VIPs. The stats we have are over the course of one day, but are reproducible day by day.

Any ideas ?

Hi,

Could you please tell me based on what you measure this? when you say 10 % of the time, are you talking about connections or requests?

I mean are you measuring this with new connections (new handshake) or with amount of requests (many GETs can exist on a single HTTP persistent connection).

Keep in mind that the CSS balance connections not requests, so it would be nice to know if your IIS stats are based on the amount on connections or hits per-se.

With regards to a client hitting only 3 of 5 servers, well is hard to say, it means is getting balanced, it would be expected on the port 80 rule that has no stickiness to see new connections getting balanced.

I would like you to double-check if all your clients are using SSLv3 or TLSv1, keep in mind that on SSLv2 the SSLID is encrypted so the CSS cannot read it to to stickiness.

Also if your clients are using a Web Browser, such as IE, well I remember there are a few versions of IE that change the SSL ID every 2 minutes, thus causing the CSS to loose stickiness.

These are a few things to consider, but honestly many things would need to be checked in order to fully understand your issue and provide a resolution.

You might want to open a TAC case for us to check.

Excellent point, I shouldn't take for granted what the server guys are saying. I'm in contact with them now re: the IIS logs, let's see what they say. I ran sniffer on the local segment and see http1.1 in use, with multiple operations over the same http stream (keep-alive is set by default in http1.1)

Another point, if multiple client IPs are hidden behind a proxy or FW, I assume the proxy/fw should open a new connection for each host behind it ?

Getting Started

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: