cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1191
Views
0
Helpful
5
Replies

Arrowpoint cookie expiration

tim.metzinger
Level 1
Level 1

On a CSS, if a manual expiration time (say two hours) is set for an arrowpoint-cookie, does the expiration time get reset with every subsequent transaction through the switch? Or is the expiration time set once, at the initial HTTP GET request, and the cookie vanishes at it's expiration time?

If the cookie expiration time isn't constantly updated, then it's possible that a user might lose his cookie after two hours (even though he's only been idle for a minute or two) and lose his server persistence.

5 Replies 5

ciscocsoc
Level 4
Level 4

The CSS command reference manual under arrowpoint-cookie expiration includes the information that:

"If the cookie has expired, the CSS sends a new cookie that includes the server

where the client was stuck. This will allow for the appearance of an uninterrupted

connection."

Reading the manual, the cookie is not continuously updated, but is replaced as it expires. The whole set of arrowpoint commands are worth reviewing to ensure that you get the effects you need.

HTH

Cathy

Gilles Dufour
Cisco Employee
Cisco Employee

The arrowpoint-cookie is static.

It never expires.

It never changes.

But, we can set an expiration time inside the http response when we send the cookie to the client.

This is the client browser that will expire the cookie and stop using it.

Once the browser has expired the cookie it stops using it.

The CSS will see a request with no cookie it will send a new one with a new expiration time.

Gilles.

Well, now we've got two opposite answers:

One says that when the cookie expires it is still sent to the CSS by the browser which will then replace it with a new cookie, so the user will remain stuck to the same server.

Another says that once the cookie expires it is removed from the browser, so that the CSS would see the incoming traffic as an entirely new session, and make a new balancing decision and assign a new cookie. This makes more sense to me as it is how I believe browsers handle cookies.

I guess I'll need to do some testing to find out.

And it turns out that you are both right...

If you set a cookie expiration time, and DON'T set arrowpoint-cookie browser-expire, then the CSS will note the expired cookie and reset a new one. Not sure what this gets you over a non-expiring cookie, except maybe it will allow for recycling of IDs if you've got gazillions of sticky customers.

If you set cookie expiration time AND set arrowpoint-cookie browser-expire, then the cookie vanishes from the browser upon it's expiration time, and the CSS has to make a brand-new decision.

Good night Gilles:

 

We have currently some CSS 11500 in operation. The budget for new equipment looks so far away.

Our user is asking us to implement load balancing for "Munger cookies". After reading the CSS documentation we ran a set of tests and the result is that munger cookies (cookieurl) and all other cookies has ever worked in this platform.

The only option that seems to work is "arrowpoint-cookie".

It seems that you are the only expert alive in CSS 11500, so I want to ask you if our conclusions are correct and the options for stickness based in cookies and munger cookies never worked.

 

Best Regards.

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: