Contents

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.

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).

Caveat

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).

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).

Sticky Cookie-Passive

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.

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.