ACE cookie Sticky DB problem

[cajalat]

I configured cookie sticky and it seems to work by testing from the same machine with different browsers (IE & FF). I also can see the connections using the show conn serverfarm command. But I can't seem to see the sticky database entries. It is always blank when I do a "show sticky database". I have another site setup but with source IP sticky and sticky entries do show for that site. What could I be doing wrong? I attached a copy of the config for reference. Also I do have a resource sticky assigned to this context in the admin context.

Thanks

Casey

How can I see the sticky table?

[Gilles Dufour]

Casey,

you have configured cookie insert.

In this case the cookie is a static value.

So you need the following command to see the database

show sticky da static

Regards,

Gilles.

[cajalat]

Hi Gilles,

I now see entries in the static db but it isn't making much sense to me. Here's an example after I have made a new connection to the VIP from a client who's never accessed the site before:

NDCD23ACERT1/DMZ-NDC# sh serverfarm NDVO_80

serverfarm : NDVO_80, type: HOST

total rservers : 2

---------------------------------

----------connections-----------

real weight state current total

---+---------------------+------+------------+----------+--------------------

rserver: NDVO1

10.20.52.41:80 8 OPERATIONAL 0 10

rserver: NDVO2

10.20.52.42:80 8 OUTOFSERVICE 0 10

NDCD23ACERT1/DMZ-NDC# sh conn serverfarm NDVO_80

conn-id np dir proto vlan source destination state

----------+--+---+-----+----+---------------------+---------------------+------+

12721 1 in TCP 1213 10.1.102.5:2676 134.174.13.246:443 ESTAB

4362 1 out TCP 1262 10.20.52.41:80 10.1.102.5:18356 ESTAB

6461 2 in TCP 1213 10.1.102.5:2677 134.174.13.246:443 ESTAB

5277 2 out TCP 1262 10.20.52.41:80 10.1.102.5:26659 ESTAB

NDCD23ACERT1/DMZ-NDC# sh sticky database static

sticky group : CHIP-DPH

type : HTTP-COOKIE

timeout : 15 timeout-activeconns : FALSE

sticky-entry rserver-instance time-to-expire flags

---------------------+--------------------------------+--------------+-------+

11730688818470955540 CHIP-DPH6:80 never -

sticky group : NDVO_80

type : HTTP-COOKIE

timeout : 60 timeout-activeconns : FALSE

sticky-entry rserver-instance time-to-expire flags

---------------------+--------------------------------+--------------+-------+

11775052997257386192 NDVO2:80 never -

NDCD23ACERT1/DMZ-NDC#

As you can see the sticky references NDVO2 which is out of service. It also seems to never expire and I can't seem to be able to clear it either. I guess what I was expecting was a sticky entry that shows which client is tied to which server.

Casey

[cajalat]

I've attached the output for easier reading.

[Gilles Dufour]

Casey,

the sticky entry is static. So it never expires and never changes.

If you want to see to which server a client is linked, you can use the command like this :

switch/Admin# sho stick da static client ?

Enter client IP address

Gilles.

[cajalat]

Gilles,

So this is more confusing then as I would expect to see one for rserver NDVO1. But I only see one for rserver NDVO2 which is OUTOFSERVICE. So connections are hitting NDVO1 but there doesn't see to be anything listed for them.

Regarding being able to see which server a client is stickied command is good if I know the client but generally I want to know which clients are stickied to which servers. Is there no way to see all the clients without having to know their IP's. Perhaps even a CIDR search?

Casey

[Gilles Dufour]

no, you can't know which client stick to which server because ACE does not keep track of the client when using static cookie.

That's the advantage of the solution. No database is required.

Actually the command I gave you will also not work.

All you can do is list the active connections and you'll now what client ip stick to what servers.

I believe what you mostly want to know is if the load is equally shared between the servers.

So, simply check the serverfarm counters.

Regarding your sticky database it looks corrupted to me. You should see 2 entries if you have 2 servers. Even if 1 is down.

Are you running the latest A1.5 version ?

Gilles.

[cajalat]

Gilles,

Things are starting to make sense now :) Finally.

So I should expect to see a cookie per rserver. The ACE would then do Sticky based on which cookie the client presents and thus no db to maintain. This is indeed clever and I like it.

I am running Version 3.0(0)A1(4l). I plan to upgrade to A1.5a and hopefully that will be seemless as I understand it.

So now if you wouldn't mind clarifying how the timeout for the sticky comes into play...how does the ACE keep track of timer per connection for cookie-based sticky and can I look at it?

Casey

[cajalat]

Gilles,

I upgraded the HOT ACE to A1.5a and changed the ft group priority to shift traffic. the "show sticky da static" now shows an entry for every rserver configured for cookie insert.

So if there is no database for sticky then where does the timeout come into play? How do I know what clients have not attritioned out.

Casey

[Gilles Dufour]

Casey,

this is a cookie.

So the timeout is sent with the cookie.

If you configure a sticky timeout, the ACE module will compute a date that define the expiration time and send it with the cookie to the client.

The browser knows it can only use the cookie until the expiration time.

If you did not configure a timeout, the cookie never expires.

Gilles.

[cajalat]

Hi Gilles,

Thank you. This is starting to make sense. So this "timeout" is not the same as what I was originally assuming "idle timeout". Is there a way to setup sticky based on cookies but with "idle timeout" instead? I asked because I noticed that if I set this value to X minutes that after X+1sec the cookie expires and the browser can get redirected to a different server. I need for the browser to stay with the same server so an "idle timeout" is more appropriate for me. That is why I was originally confused about where to find the db entry for the "timeout". I kept thinking it was an "idle timeout" and thus needing to be maintained in a db.

Casey

[Gilles Dufour]

Casey,

there is no idle timeout for static cookie and no way to achieve the same behavior.

Gilles.