Document ID: 25746
Cisco has announced the end of sale for the Cisco LocalDirector. For more information, refer to the LocalDirector 400 Series End-of-Life and End-of-Sale Notices and Product Bulletins.
Sticky or session persistence is a commonly used method that ensures that a client session remains connected or stuck to the same server for the duration of their session. This is necessary for commercial or secure applications that require the preservation of session information, or require a user login and authentication and authorization. Normally in a load balancing scenario, each successive request from the client is again evaluated and can be sent to a different server in the load balancing rotation. When all the servers have the same content and if the user only looks at information, this is the preferred method for load balancing. When session persistence is required, one of three methods for sticky can be used on the LocalDirector (LD)—generic sticky, Secure Socket Layer (SSL) sticky, and cookies.
For more information on document conventions, see the Cisco Technical Tips Conventions.
There are no specific prerequisites for this document.
This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are in a live network, ensure that you understand the potential impact of any command before you use it.
Generic sticky is based on the source IP address of the incoming connection. The requests from the same IP address are always sent to the same server as the one that was selected on its initial connection. The LD maintains an internal table that tracks this information. To configure generic sticky, issue the sticky virtual_id minutes generic command.
The Virtual ID (VID) is defined in the LD configuration bind command, and the minutes parameter is how long after a client disconnects to wait until their sticky association information (which server they were on last time) is purged. The user can be stuck to a different server the next time they connect. The default is zero minutes (sticky disabled).
This method works well unless the incoming clients work through a proxy, firewall, or a router that performs address translation. In this situation, the LD sees all user's requests that come from the same IP address, and sends all requests to the same server.
SSL sticky is based on the SSL Session ID (SID) of the client to server connection. The SID gets negotiated when the client connects. The SID is sent in the HTTP header, and is not encrypted. The SID be read by the LD. The command syntax is sticky virtual_id minutes ssl.
The VID is defined in the LD configuration bind command, and the minutes parameter is how long after a client disconnects to wait until their sticky association information (which server they were on last time) is purged. The user can be stuck to a different server the next time they connect. The default is zero minutes (sticky disabled).
Internet Explorer 5.x and above now renegotiates the SSL ID every two minutes. For more information on this, refer to Internet Explorer Renegotiates Secure Sockets Layer Connection Every Two Minutes .
A sticky scenario based on a value that constantly changes does not work well. As a workaround, configure the LD so that the client comes in on HTTP, and is load balanced among a set of redirect URLs rather than Web servers. Each of these URLs point back to a Direct IP (DIP) address on the LD that maps to a single real server. Now that the client communicates to a single server, there cannot be load balanced to another real and can avoid this issue. For more information on this configuration, refer to Configuring HTTP to HTTPS Redirection on the Cisco LocalDirector.
This configuration requires using extra public IP addresses, one for each real server, registration of all real servers in DNS, and that the client initiate the connection on HTTP (port 80) rather than HTTPS (port 443).
There are two types of cookies that the LD can work with, cookie passive (cookies that are inserted by the back end Web servers), and cookie inserts (cookies inserted by the LD itself).
The command syntax is sticky virtual_id minutes cookie-passive name.
This command enables sticky connection based on a cookie created by the sticky real server. LD learns the cookie and stores it in memory. When two identical cookies (two cookies with the same NAME and VALUE) exist on two different servers, cookie-passive mode in LD Version 3.3.x cannot work properly. LD makes decisions on the sticky relationship based on the cookie received from the Web server. The second identical cookie breaks the first sticky relationship on LD.
LD ( which acts as a proxy server) receives new client connections and scans the HTTP GET request for a cookie that matches one in memory. If there is a match and the time has not expired, LD forwards packets to the previously selected sticky real server. LD then scans packets from the sticky real server until the first HTTP response is detected. If there is a match, but the time has expired, LD assigns the connection to a new real server. If there is no set-cookie token in the HTTP response, LD stops acting as the proxy server and forwards all packets directly to the sticky real server. If there is a set-cookie in the HTTP response, LD stores the new cookie in memory and stops acting as proxy server for the connection. If the sticky real server does not answer or returns a TCP RST, LD assigns the connection to a new real server.
If the real server returns multiple cookies in the HTTP header, LD scans for the first set-cookie directive and then sets the sticky relationship (persistence) for subsequent connections on the first cookie found in the HTTP header.
The command syntax for cookie insert is sticky virtual_id minutes cookie-insert name domain .
This is an optional command. This command enables sticky connection based on a cookie created by LD. LD (acting as a proxy server) receives new client connections and scans the HTTP header of the GET request for a cookie. If one is not detected, LD assigns the connection to a real server and creates the cookie. If a cookie is detected, LD extracts it to determine the sticky real server ID and the expiration time. If time has not expired, LD forwards the connection to the sticky real server. If time has expired, LD assigns the connection to a new sticky real server and creates a new cookie.
Once a sticky association is established, LD stops acting as the proxy server, and forwards all packets directly to the sticky real server. The cookie-insert option is based on time. It is unusual for client and server clocks to be accurately synchronized. It is recommend that you specify a large enough value in the minutes argument to cover possible clock differences between clients and servers. The name is very important, as it is the string that the LD looks for and decides which server the packets should be sent to. The clock time on the LD is also very important, and should be set to Greenwich Meridian Time (GMT) in the military or Coordinated Universal Time (UTC) format.
- LocalDirector 400 Series End-of-Life and End-of-Sale Notices
- LocalDirector 400 Series Product Bulletins
- Command Reference
- LocalDirector 400 Series Content Switches Hardware Support
- Technical Support - Cisco Systems
|Updated: Jan 31, 2006||Document ID: 25746|