We have a CSM-S to load balance the web servers. It is configured with very simple round robin config with cookie based sticky. So, when the user access the webpage CSM insert a cookie to provide stickyness for that connection. All work well...but the problem here is.. the Cookie value injected by CSM is kind of combination of numbers. Our developers are requesting to inject some predefined value into that cookie for example if server-1 replies to the request then CSM should insert the cookie data as ONE, if it is Server-2 then CSM should insert the cookie data as TWO etc..
I have been goolging for whole day yesterday but couldn't find any relevant document.
If any of you had faced this kind of challenges by any chance would you please help me to implement it?
Thanks in advance for your help.
Could you please state which version of CSM you are using.
You can accomplish session stickiness using HTTP cookies. There are two types of HTTP cookies are available.
Real servers store persistent cookies in a text file on the hard disk of the client's computer, primarily to provide personalization and customization for the user on subsequent visits to the site.
Real servers and clients store session cookies locally in RAM, and they exist only temporarily for the life of the session.
The browser removes the cookie from RAM when the user closes the browser window(s) for the session, and the real server removes the cookie from RAM after a configurable timeout on your web server.
Content switches use session cookies to provide session stickiness for clients and can be set on the real server or, if the real server is not capable of setting cookies, the content switch can set the cookie on the real server's behalf.
The session cookie is set by the server with the HTTP "Set-Cookie:" header.
The value of the cookie can be set to any attribute/value pair, such as "SESSION_ID=012321."
For subsequent HTTP requests, either within the same TCP connection or across connections, the client uses the cookie as a handle for all communication during the session.
You must configure your content switch to inspect cookies with a value starting with "SESSION_ID=," , and store a mapping of the associated value to the real server originally chosen for the session.
This way, the content switch does not load balance subsequent requests to new real serversthe cookie overrides the normal load-balance decision. The image I have attached illustrates how the CSM sticks a client to the same server.
The CSM selects the real server using the configured load balancing method, and forwards the GET request to that real.
When the CSM receives the "Set-Cookie:" header from the real server, the CSM stores the association between the cookie value and real server in the sticky table. On subsequent requests from the client, the CSM performs a table lookup with the cookie that the client supplies to determine which real the client is stuck to.
To configure your CSM to inspect HTTP cookies, you can use the configuration shown below.
You must give the sticky configuration for "SESSION_ID" a unique identifier (for example, 1 in this case) and apply the sticky configuration to a policy using the stick-group command.
You then apply the policy to the virtual server using the policy command.
Configuring Sticky Cookies on the CSM
mod csm 5
sticky 1 cookie SESSION_ID time-out 100
no nat client
virtual 10.1.10.100 tcp www
To stick to only a portion of a cookie, as opposed to the entire cookie, use the following command:
cookie offset 5 length 8
This command benefits applications, such as Java 2.0 Enterprise Edition (J2EE), which store the real session ID only in certain bytes of the cookie value. If your origin servers do not support cookies, you can configure your CSM to insert a cookie in the server's response to the client, using the following command:
sticky 5 cookie mycookie insert
Instead of setting a sticky string within a "Set-Cookie:" HTTP header of an HTTP 200 OK method, you can configure your real servers to send an HTTP 302 Object Moved method containing a sticky string within the URL of the "Location:" header. You must direct your content switch to inspect URLs from clients for the sticky cookie. For example, you can configure your real server to return the following URL in an HTTP 302 Object Moved method for client logins:
HTTP/1.1 302 Object Moved
Clients use the value in the "Location:" header to request the login page. Your real servers must also embed the sticky string into the hyperlinks within all further HTML pages to which the client will have access during their session. To direct the CSS to inspect the client URLs to find the sticky string within your URL strings (after the "?" in the URL field), use the following content rule configuration command:
To configure your CSM to check the URL for the sticky string, use the sticky configuration command:
cookie secondary session-id
Please remember that the CSM combines URL strings with cookies in that it can search a cookie value in the URL after having learned it dynamically from a "Set-cookie:" message, to account for clients that reject the cookie sent by the server.
Depending on client and server behavior and the sequence of frames, the same cookie value may appear in the standard HTTP cookies appearing in the HTTP cookie, set-cookie headers, or cookies embedded in URLs. The name of a cookie may be different from the URL depending on whether the cookie is embedded in a URL or appears in an HTTP cookie header. The use of a different name for the cookie and the URL occurs because these two parameters are configurable on the server and are very often set differently. For example, the set-cookie name might be as follows:
Set-Cookie: session_cookie = 123
The URL might be as follows:
The name field in the sticky command specifies the cookie name that appears in the cookie headers. The secondary session_id clause added to this command specifies the corresponding cookie name that appears in the URL.
This example shows how to configure the URL learning feature:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# module csm 4
Router(config-module-csm)# sticky 30 cookie session_cookie
Router(config-slb-sticky-cookie)# cookie secondary session-id
Thanks for your reply.
The explantion you have given is all talks about setting up the cookie in URL. Is there any way to change the
r12345678 value to some other value which ever I want? These detail should be downloaded into client machine as part of cookies rather inserting in URL.
I have question regarding cookies in http header. We configured CSM to insert cookie in Server response. In request from server is java script that generates additional cookie name and values when client request addition information. It seems that additional values are not RFC compliant and that forces CSM to drop packets.
There is documented Bug CSCeg04864 that states | pipe sign should not be used between cookie values. We are using release 4.2(7).
Is it possible to have cookie insert and cookie offset concurrently. If the | value is causes CSM to drop packets, can we limit the parsing of Headers to only few bytes of Cookie header that CSM inserts.
Example: We have cookie that CSM inserts in response to client Cookie_CSM=r1234567; on client request java script on web page adds anothoer cookie Cookie_new=zrueiwrziw|zetiurtzier;
Now, from client we have Cookie_CSM=r1234567; Cookie_new=zrueiwrziw|zetiurtzier;
Will it work if we configure cookie offset to parse only 8 bytes of Cookie Cookie_CSM.