CSM with active cookie stickiness

[lukaszkhalil]

Hello

I notice a strange behavior of my CSM-S when I am trying to use the active cookie sticky method.

I have a server farm with 2 servers. When I tried to open a session to the VIP ip address, everything works fine until I try to open one of the links in the java menu for the second time. In the sniffer trace I can see that after the HTTP request is being sent the load-balancer answer with RST packet.

Even if I take out of service one of the real server in this farm I have the same problem.

Does anybody know why I might receive this RST packet, especially if I am doing test with one real server?

PS

When I change the sticky method to e.g. source IP everything works fine.

Thank you in advance for any help.

Regards

Lukas

[Gilles Dufour]

Lukas,

with sticky cookie, the CSM needs to spoof the connection.

While with sticky src ip the CSM just passes the traffic without looking into the data.

So, if you get a RESET, the CSM might not like the content of the data.

Could we get a sniffer trace of a transaction from start up to the failure.

Thanks,

Gilles.

[lukaszkhalil]

Hi

It might be difficult because we do test on the production traffic, but I will check. Could you please tell me if it is possible to get from the CSM why is he sending reset? Is there any command that will show some counters describing the reason?

If there is sticky cookie configured on the CSM what HTTP header fields are required by the CSM to process packets correctly?

Thank you in advance

Lukas

[Gilles Dufour]

unfortunately this is not that easy.

That's why the sniffer trace is required.

Gilles.

[lukaszkhalil]

Hello

Could you please send me you e-mail address. I will send you the sniffer capture directly.

Thanks

[Gilles Dufour]

gdufour@cisco.com

[Gilles Dufour · Accepted solution]

ok, from the trace it seems like the request is so long the CSM can't find the cookie and reset the connection.

Do the following command to verify this :

sho mod csm 3 tech proc 4 | i arse

LB Rjct: L7 max parse len 0

LB Rjct: L7 parser 0

See if any of this counter is increasing.

If yes, under the vserver configure

parse-length 4000

This should fix the problem.

A trace is always helpuf :-)

Gilles.

[lukaszkhalil]

It works !! :)

Thank you

You are brilliant.

Regards