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