URL-learn cookie stickiness method

[lukaszkhalil]

Hello

In our network we are trying to configure a SLB with stickiness based on the passive cookie method on the CSM-S module for cat6k.

The server is setting the JSESSIONLIST cookie in the "set-cookie" field in the HTTP header. Unfortunately, each time a client is accessing the server, the server adds more data into the "Refer" field in the HTTP header that it's placed before the cookie field. Finally when the HTTP header is bigger then 4000 bytes, which is the maximum max-parse length value for CSM-S module, the module is unable to correctly stick the session based on the cookie value send by the client.

When a server sets the set-cookie value in the HTTP header, at the same time, it sets the parameter called jsessionid in the URI that has the same value that the cookie JSESSIONLIST. Because of our problem with the long "Referer" field in subsequent client requests we have tried to configure the stickiness based on URL-Learn method.

The virtual server is using a sticky group configured as below

sticky 2 cookie JSESSIONLIST timeout 30

cookie secondary jsessionid

Unfortunately it does not work. We are wondering why. In the configuration-guide there is not much information about this kind of stickiness. We are wondering if it is not a problem for CSM to stick a session based on the "secondary cookie", when, at the same time, the cookie field is also transmitted in the client requests. We are also wondering if it is not a problem for a load balancer that the jsessionid parameter in the URI follows ";" not "?" as in the example in the configuration guide.

I am attaching an example HTTP GET request from the client (some values were hidden). This trace shows the request with a short "Refere" field but the subsequent packets contain this field much more bigger.

Thanks for any help in advance

[Gilles Dufour]

the CSM will look into the url if it can't find the cookie in the header.

However, if the header length is too big, the CSM will consider this an error and it will stop parsing.

A solution for you is to increase the parse length with a variable:

gdufour-cat6k-2#sho mod csm 3 var | i PAR

MAX_PARSE_LEN_MULTIPLIER 1

It will multiply whatever parse length you have configured.

Now, you could also change the server behavior with the referer.

Increasing the size of the header will consume BW and reduce performance of the LB and SSL offloader.

Gilles.

[freost]

Have you tried extending max-parse length with the environmental variable

variable MAX_PARSE_LEN_MULTIPLIER

You should be able to sticky on the cookie GT 4000 bytes value by extending the max parse length.

[lukaszkhalil]

Hello

I have not try this. Could you please provide me a command to do that, or is it in the conf guide or command refference ?

[Gilles Dufour · Accepted solution]

the command is :

variable MAX_PARSE_LEN_MULTIPLIER

where is a value from 1 to ...

Try 2 or 3.

If you seach the keyword "MAX_PARSE_LEN_MULTIPLIER" you should be able to find the documentation for this variable and all the others.

Gilles.

[lukaszkhalil]

Hello

We have changed the defaults and it works now.

Thanks for your help

Lucas