Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Monitoring a CSS11503 sticky decision

Hi everybody,

we want to see and log (best would be to syslog) why the CSS takes a loadbalancing decision on stickiness. Is this possible and how should this be configured?

Our current problem is the following. We got a CSS11503 pair in box redundancy. They are loadbalancing https traffic to two SUN iPlanet instances using SSLv3. The rule is the following:

content https

protocol tcp

port 443

application ssl

balance aca

add service service1_https

add service service2_https

vip address

advanced-balance ssl


what we see is that some client gets forwarded to the second server during a session although it was directed to the first one before. And this leads to an 'authorization required' error in the client application. We can trace this in the iPlanet logs.

When using src-sticky, everything works fine, so this leads to the conclusion that it has to do with SSL loadbalancing.

Of course the application guys now blame the CSS for not working correctly, but I think (as a CSS guy) that the application is doing something wrong. So, I need to trace the sticky decision on the CSS.

Any ideas are welcome.


New Member

Re: Monitoring a CSS11503 sticky decision


The sticky decision is based upon the SSL hash at the time of the SSL Session Setup. As long as your Sticky Table Timeout is not set extremely low (and your's isn't) there should be no reason for the sticky association to change servers, unless, the application is renegotiating the SSL Session frequently (an application issue). This would cause a new hash and therefore, a new sticky condition balanced according the the ACA alogorithm.

I do not know a way to monitor the decision process, however, maybe Gilles can show you a debug routine.

Mit Fruendlich Gruss Aus New England


Cisco Employee

Re: Monitoring a CSS11503 sticky decision


internet explorer is well-known for re-negotiating the ssl id frequently.

If you search the web you should find many article about it.

There is no way to debug the CSS loadbalancing decision.

If you want to convince yourself that this is a client issue, capture a sniffer trace from a client showing the problem [ to get a free sniffer].

The solution to this problem is to change the sticky method and use sticky source ip.


New Member

Re: Monitoring a CSS11503 sticky decision

Hi Alex,

(I'm a CSS guy too!)

Have you investigated the actual SSL session ID's being used for that particular client when this error occurs?

We had a problem with very similar symptoms and had to use a Sniffer in order to find the root cause.

Our servers (I think they were IPlanet too, running on Linux) were not handling the SSL session-id "re-use" option properly. They were instead providing a bran new SSL session-id each time the client would send a SSL "re-negotiation handshake" (I'm not sure about terminology here!). In our case, we saw this happenning every 90 seconds, causing the clients to bounce from server to server because the CSS would not find a match in its SSL-sticky table and load-balancing would therefore take effect and cause the client to end up on a different server (similar to what you are reporting).

Unfortunately, in our case (also) we were unable to resolve this server issue and we resorted to src-sticky.

Good luck!