CSS 11506 ver 8.10 - sticky sessions not being followed

Unanswered Question
Apr 6th, 2009

We have an issue where users are being load-balanced by the string value in the URL but sometimes they get sent to the incorrect service.

See attached content rule configuration and example service configuration.

This works the majority of the time but every so often a user will be sent to the incorrect service even though the session ID (string value) is correct. This causes the application session to break. The services are up when this happens and the same problem occurs on the same CSS with another sticky rule which uses sticky-src-ip.

Any ideas?

Cheers

David

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
JamesLuther Mon, 04/06/2009 - 06:29

Hi,

I've seen a similar issue with passive cookies on the CSS. The persistence works most of the time but for about 1 in 100 attempts it fails. Again this breaks our customers application. Using the arrowpoint cookie appears to work fine, however we're not able to use it in this particular application.

We currently have a case open with Cisco about this.

Using ACE and Big-IP works fine.

Regards

degearing Wed, 04/08/2009 - 02:41

Is it possible this is related to having a full sticky table?

Our sticky stats are attached. My concern is that entries in the sticky-table are being re-used before the remote client has finished there sticky session.

Can anybody shed anymore light on what occurs when the sticky-table is full?

Gilles Dufour Wed, 04/08/2009 - 06:02

When sticky table is full we kick old entries to add new ones.

This can only be a problems if the interval between 2 requests is long enough to have so many new entries that the entry for this src got lost.

What is most probably the issue is that if a persistent connection times out, we stop looking for a sticky match.

So, if the next request should be sent to a different server, we won't see it.

Try to increase the idle timeout with the command "flow-timeout-multiplier 30".

If that helps, but do not solve completely the issue, increase the value from 30 to 50.

Gilles.

chris.williamsEP Tue, 04/14/2009 - 09:06

Sorry to hijack the thread here, but we are experiencing the same issue. TAC has escalated to the development team, but I'm not very optimistic about a fix.

We currently have a L5 sticky rule configured with two services bound. Our developers have inserted "hid=101" and "hid=102" into the URI for each server by way of a REGEX. The Content Rule is configured as follows (only the pertinent config below):

string prefix "hid="

sticky-no-cookie-found-action loadbalance

string eos-char "&"

url "/*"

The services are obviously configured with the "string 101" and "string 102" commands. We are seeing the same behavior where some flows to not trigger the sticky entry and the client session is load-balanced to another server. I also noticed that our sticky tables are depleted with SSL sticky entries for another application. It was always my understanding that L5 CSS Rule stickiness IS NOT maintanied in the same table as L3, L4, SSL...etc. Is this an accurate statement?

Also...Arrowpoint cookie works brilliantly for this application; the caveat being we aren't able to force customers to accept cookies. Has anyone seen this behavior with 8.20? We'd be willing to upgrade to resolve this. Hearing that this doesn't affect the ACE platform is nice as well...we may be moving to that platform shortly.

Thanks,

Chris

Actions

This Discussion