Getting Started Guide, Cisco ACE Application Control Engine Module
Configuring Server Persistence Using Stickiness
Downloads: This chapterpdf (PDF - 169.0KB) The complete bookPDF (PDF - 3.17MB) | Feedback

Configuring Server Persistence Using Stickiness

Table Of Contents

Configuring Server Persistence Using Stickiness

Information About Configuring Stickiness

Configuring HTTP Cookie Stickiness

Configuration Example for HTTP Cookie Stickiness

Where to Go Next


Configuring Server Persistence Using Stickiness


This chapter describes how to configure server persistence using stickiness on the Cisco Application Control Engine (ACE) module.

This chapter contains the following sections:

Information About Configuring Stickiness

Configuring HTTP Cookie Stickiness

Configuration Example for HTTP Cookie Stickiness

Where to Go Next

Information About Configuring Stickiness

After reading this chapter, you should have a basic understanding of how the ACE provides server persistence using stickiness, and how to configure HTTP cookie stickiness.

When customers visit an e-commerce site, they usually start by browsing the site. Depending on the application, the site may require that the client remain connected (stuck) to one server as soon as the initial connection is established, or the application may require this action only when the client starts to create a transaction, such as building a shopping cart.

For example, after the client adds items to a shopping cart, it is important that all subsequent client requests are directed to the same real server so that all the items are contained in one shopping cart on one server. An instance of a customer's shopping cart is typically local to a particular server rather than duplicated across multiple servers.

E-commerce applications are not the only types of applications that require a sequence of client requests to be directed to the same real server. Any web applications that maintain client information may require this behavior, such as banking and online trading applications, or FTP and HTTP file transfers.

You can configure the ACE so that the same client can maintain multiple, simultaneous, or subsequent TCP or IP connections with the same real server for the duration of a session. This session persistence capability of the ACE is called stickiness. A session is defined as a series of transactions between a client and a server over some finite period of time (from several minutes to several hours).

Depending on the configured server load-balancing policy, the ACE sticks a client to an appropriate server after the ACE determines which load-balancing method to use. If the ACE determines that a client is already stuck to a particular server, then the ACE sends that client request to that server, regardless of the load-balancing criteria. If the ACE determines that the client is not stuck to a particular server, it applies the normal load-balancing rules to the request.

To determine how a particular client is stuck to a specific web server and how an application distinguishes each client or a group of clients, the ACE supports the following sticky methods:

Source and/or destination IP address—For stickiness, you can use the source IP address, the destination IP address, or both to uniquely identify individual clients and their requests based on their IP net masks. However, if an enterprise or service provider uses a mega-proxy (a free, anonymous web proxy service that can represent hundreds or thousands of different clients with a single source IP address) to establish client connections to the Internet, the source IP address is not a reliable indicator of the true source of the request. In this case, you can use another sticky method to ensure session persistence.

Cookie—Client cookies uniquely identify clients to the ACE and to the servers that provide content. A cookie is a small data structure within the HTTP header that a server uses to deliver data to a web client, with the request that the client store the information. The cookie may be inserted into a response packet from the server or the ACE can insert the cookie. This information may include items that users have added to their shopping carts or travel dates that they have chosen. When the ACE examines a request for content and determines that the content is sticky, it examines any cookie or URL present in the content request. The ACE uses the information in the cookie or URL to direct the content request to the appropriate server.

Hypertext Transfer Protocol (HTTP) header—You can specify a header offset to provide stickiness based on a unique portion of the HTTP header.

Layer 4 Payload Stickiness—Layer 4 payload stickiness allows you to stick a client to a server based on the data in Layer 4 frames. You can specify a beginning pattern and ending pattern, the number of bytes to parse, and an offset that specifies how many bytes to ignore from the beginning of the data.

HTTP Content Stickiness—HTTP content stickiness allows you to stick a client to a server based on the content of an HTTP packet. You can specify a beginning pattern and ending pattern, the number of bytes to parse, and an offset that specifies how many bytes to ignore from the beginning of the data.

RADIUS Attribute Stickiness—The ACE supports stickiness based on RADIUS attributes. The following attributes are supported for RADIUS sticky groups:

Framed IP

Framed IP and calling station ID

Framed IP and username

RTSP Session Header Stickiness—The ACE supports stickiness based on the RTSP session header field. With RTSP header stickiness, you can specify a header offset to provide stickiness based on a unique portion of the RTSP header.

SIP Call-ID Header Stickiness—The ACE supports stickiness based on the SIP Call-ID header field. SIP header stickiness requires the entire SIP header, so you cannot specify an offset.

SSL Session-ID Stickiness—This feature allows the ACE to stick the same client to the same SSL server based on the SSL Session ID. This feature supports SSLv3 only. Because the SSL Session ID is unique across multiple connections from the same client, you can use this feature to stick clients to a particular SSL server when the ACE is configured to load balance SSL traffic, but not terminate it. To use this feature, you must configure a generic protocol-parsing policy for sticky learning. The ACE learns the SSL Session ID from the SSL server or other SSL-termination device.

Because an SSL server can reuse the same SSL Session ID for new connections from a known client, the SSL handshake time is reduced. This reduction in the handshake time translates directly into lower computational requirements for the server and reduced CPU utilization, and, therefore, increased SSL transactions per second (TPS).

The e-commerce application often dictates which of these methods is appropriate for a particular e-commerce application.

The ACE uses sticky groups for stickiness attributes. These attributes include the sticky method, timeout, replication, and attributes related to a particular sticky method.

To track sticky connections, the ACE uses a sticky table with information about sticky groups, sticky methods, sticky connections, and real servers. The ACE uses a configurable timeout mechanism to age out sticky table entries. When an entry times out, it becomes eligible for reuse. High connection rates may cause the premature aging out of sticky entries. In this case, the ACE reuses the entries that are closest to expiration first.

Entries in the sticky table can be either dynamic (generated by the ACE as needed) or static (configured). When you create a static sticky entry, the ACE places the entry in the sticky table immediately, and it remains in the sticky database until you remove it from the configuration.

Figure 8-1 illustrates that, in a server load-balancing environment, requests from a client are stuck to real server RS_WEB4 in a session.

Figure 8-1 Client Requests Stuck to a Server

This chapter describes how to configure stickiness using the HTTP cookie sticky method. For information on how to configure stickiness using the IP address and HTTP header methods, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine.

Configuring HTTP Cookie Stickiness

Procedure

 
Command
Purpose

Step 1 

changeto context
 
        

Example:

host1/Admin# changeto VC_WEB
host1/VC_WEB#

Changes to the correct context if necessary. Check the CLI prompt to verify that you are operating in the desired context.

Step 2 

config
 
        

Example:

host1/VC_WEB# config
host1/VC_WEB(config)# 

Enters configuration mode.

Step 3 

sticky http-cookie cookie_name group_name

Example:

host1/VC_WEB(config)# sticky 
http-cookie COOKIE1 STICKYGROUP1
host1/VC_WEB(config-sticky-cookie)#

Creates an HTTP-cookie-type sticky group and enters cookie configuration mode.

Step 4 

cookie insert [browser-expire]

Example:

host1/VC_WEB(config-sticky-cookie)# cookie insert browser-expire

Instructs the ACE to insert a cookie into the response packet from the server. The browser-expire option allows the browser to expire the cookie.

Step 5 

timeout number

Example:

host1/VC_WEB(config-sticky-cookie)# 
timeout 1440

Configures a timeout for HTTP cookie stickiness.

Step 6 

serverfarm name

Example:

host1/VC_WEB(config-sticky-cookie)# serverfarm SF_WEB

Associates a server farm with the sticky group and exits configuration mode.

Step 7 

exit

Example:

host1/VC_WEB(config-sticky-cookie)# 
exit
host1/VC_WEB(config)#

Exits sticky cookie configuration mode.

Step 8 

policy-map type loadbalance first-match policy_name

class class-default

Example:

host1/VC_WEB(config)# policy-map type loadbalance first-match PM_LB

host1/VC_WEB(config-pmap-lb)# class class-default

host1/VC_WEB(config-pmap-lb-c)#

Enters policy map load-balancing class configuration mode for the Layer 7 load-balancing policy.

Step 9 

sticky-serverfarm group_name

Example:

host1/VC_WEB(config-pmap-lb-c)# sticky-serverfarm STICKYGROUP1

Associates the sticky group with the Layer 7 load-balancing policy.

Step 10 

Ctrl-Z

Example:

host1/VC_WEB(config-pmap-lb-c)# Ctrl-Z
host1/VC_WEB#

Returns to Exec mode from any configuration mode.

Step 11 

show running-config sticky

Example:

host1/VC_WEB# show running-config 
sticky

Displays the HTTP cookie configuration.

Step 12 

copy running-config startup-config

Example:

host1/Admin# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuration Example for HTTP Cookie Stickiness

The following example shows how to configure HTTP cookie stickiness. The commands that you have configured in this chapter appear in bold text.

switch/VC_WEB(config)# do show running config
Generating configuration....
 
   
access-list INBOUND line 8 extended permit ip any any
 
   
rserver host RS_WEB1
  description content server web-one
  ip address 10.10.50.10
  inservice
rserver host RS_WEB2
  description content server web-two
  ip address 10.10.50.11
  inservice
rserver host RS_WEB3
  description content server web-three
  ip address 10.10.50.12
  inservice
rserver host RS_WEB4
  description content server web-four
  ip address 10.10.50.13
  inservice
 
   
serverfarm host SF_WEB
  predictor hash header Accept
  rserver RS_WEB1 80
    inservice
  rserver RS_WEB2 80
    inservice
  rserver RS_WEB3 80
    inservice
  rserver RS_WEB4 80
    inservice
sticky http-cookie Cookie1 StickyGroup1
  cookie insert browser-expire
  timeout 3600
  serverfarm SF_WEB
 
   
class-map type management match-any REMOTE_ACCESS
  description Remote access traffic match
  2 match protocol ssh any
  3 match protocol telnet any
  4 match protocol icmp any
class-map match-all VS_WEB
  2 match virtual-address 10.10.40.10 tcp eq www
 
   
policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY
  class REMOTE_ACCESS
    permit
policy-map type loadbalance first-match PM_LB
  class class-default
    sticky-serverfarm STICKYGROUP1
policy-map multi-match PM_MULTI_MATCH
  class VS_WEB
    loadbalance vip inservice
    loadbalance policy PM_LB
 
   
service-policy input REMOTE_MGMT_ALLOW_POLICY
 
   
interface vlan 400
  description Client connectivity on VLAN 400
  ip address 10.10.40.1 255.255.255.0
  access-group input INBOUND
  service-policy input PM_MULTI_MATCH
  no shutdown
interface vlan 500
  description Server connectivity on VLAN 500
  ip address 10.10.50.1 255.255.255.0
  no shutdown
 
   
domain DOMAIN1
add-object all
 
   
ip route 0.0.0.0 0.0.0.0 172.25.91.1
username USER1 password 5 $1$vAN9gQDI$MmbmjQgJPj45lxbtzXPpB1  role SLB-Admin domain 
DOMAIN1

Where to Go Next

In this chapter, you have configured server persistence with a sticky group that uses the HTTP-cookie method. In the next chapter, you will configure secure sockets layer (SSL) security.