Getting Started Guide vA5(1.0), Cisco ACE 4700 Series Application Control Engine Appliance - Configuring Server Persistence Using Stickiness [Cisco ACE 4700 Series Application Control Engine Appliances]

Table Of Contents

Configuring Server Persistence Using Stickiness

Information About Configuring Stickiness

Configuring HTTP Cookie Stickiness

Configuring HTTP Cookie Stickiness Using the Device Manager GUI

Configuring HTTP Cookie Stickiness Using the CLI

Configuration Example for the Hash Header Predictor

Where to Go Next

Configuring Server Persistence Using Stickiness

This chapter describes how to configure server persistence using stickiness on the Cisco 4700 Series Application Control Engine (ACE) appliance. It describes how to configure stickiness using the HTTP cookie sticky method.

This chapter contains the following sections:

•Information About Configuring Stickiness

•Configuring HTTP Cookie Stickiness

•Configuration Example for the Hash Header Predictor

•Where to Go Next

Information About Configuring Stickiness

After reading this chapter, you should have a basic understanding of how the ACE appliance provides server persistence using stickiness, and how to configure HTTP cookie 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

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

To configure sticky, you can use either the ACE Device Manager user interface (GUI) or the CLI.

•Configuring HTTP Cookie Stickiness Using the Device Manager GUI

•Configuring HTTP Cookie Stickiness Using the CLI

Configuring HTTP Cookie Stickiness Using the Device Manager GUI

You can configure HTTP cookie stickiness using the GUI by following these steps:

Step 1 Make sure that the context in which you are configuring the sticky group is associated with a resource class that allocates resources to stickiness. See the "Creating a Resource Class" section in Chapter 3.

Step 2 Choose Load Balancing > Stickiness. The Stickiness pane appears.

Step 3 Choose the VC_web context.

Step 4 Add a new sticky group by clicking Add. The Stickiness configuration window appears.

Step 5 Enter the following attributes for the new sticky group. Leave the remaining attributes blank or with their default values.

•Group Name: StickyGroup1

•Type: HTTP Cookie

•Cookie Name: Cookie1

•Sticky Server Farm: SF_web

Step 6 Add the new sticky group to the Stickiness pane by clicking Deploy Now.

Configuring HTTP Cookie Stickiness Using the CLI

You can configure HTTP cookie stickiness using the CLI by following these steps:

Step 1 Verify that you are operating in the desired context by checking the CLI prompt. If necessary, change to the correct context.
host1/Admin# changeto VC_web
host1/VC_web#
Step 2 Enter configuration mode.
host1/VC_web# config
host1/VC_web(config)#
Step 3 Create an HTTP-cookie-type sticky group and enter the cookie configuration mode.
host1/VC_web(config)# sticky http-cookie Cookie1 StickyGroup1
host1/VC_web(config-sticky-cookie)#
Step 4 Configure a timeout for HTTP cookie stickiness.
host1/VC_web(config-sticky-cookie)# timeout 1440
Step 5 Associate a server farm with the sticky group and exit configuration mode.
host1/VC_web(config-sticky-cookie)# serverfarm SF_web
host1/VC_web(config-sticky-cookie)# exit
host1/VC_web(config)# exit
host1/VC_web#
Step 6 Display the HTTP cookie configuration.
host1/VC_web# show running-config sticky
Configuration Example for the Hash Header Predictor

The following example shows how to configure the hash header predictor. 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 roundrobin
  rserver RS_WEB1 80
    inservice
  rserver RS_WEB2 80
    inservice
  rserver RS_WEB3 80
    inservice
  rserver RS_WEB4 80
    inservice
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
    serverfarm SF_WEB
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.2 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 a sticky group using the HTTP-cookie method. In the next chapter, you will configure SSL security.

	Getting Started Guide vA5(1.0), Cisco ACE 4700 Series Application Control Engine Appliance
	Configuring Server Persistence Using Stickiness
Getting Started Guide vA5(1.0), Cisco ACE 4700 Series Application Control Engine Appliance Preface Overview Setting Up an ACE Appliance Creating a Virtual Context Configuring Access Control Lists Configuring Role-Based Access Control Configuring Server Load Balancing Configuring a Load-Balancing Predictor Configuring Server Persistence Using Stickiness Configuring SSL Security Configuring Health Monitoring Using Health Probes Configuring Redundant ACEs Configuring Bridged Mode Configuring One-Arm Mode Index	Download this chapter Configuring Server Persistence Using Stickiness Download the complete book Getting Started Guide v 5.1(0), Cisco ACE 4700 Series Application Control Engine Appliance (Book-Length PDF) (PDF - 1 MB) Feedback Table Of Contents Configuring Server Persistence Using Stickiness Information About Configuring Stickiness Configuring HTTP Cookie Stickiness Configuring HTTP Cookie Stickiness Using the Device Manager GUI Configuring HTTP Cookie Stickiness Using the CLI Configuration Example for the Hash Header Predictor Where to Go Next Configuring Server Persistence Using Stickiness This chapter describes how to configure server persistence using stickiness on the Cisco 4700 Series Application Control Engine (ACE) appliance. It describes how to configure stickiness using the HTTP cookie sticky method. This chapter contains the following sections: •Information About Configuring Stickiness •Configuring HTTP Cookie Stickiness •Configuration Example for the Hash Header Predictor •Where to Go Next Information About Configuring Stickiness After reading this chapter, you should have a basic understanding of how the ACE appliance provides server persistence using stickiness, and how to configure HTTP cookie 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 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 To configure sticky, you can use either the ACE Device Manager user interface (GUI) or the CLI. •Configuring HTTP Cookie Stickiness Using the Device Manager GUI •Configuring HTTP Cookie Stickiness Using the CLI Configuring HTTP Cookie Stickiness Using the Device Manager GUI You can configure HTTP cookie stickiness using the GUI by following these steps: Step 1 Make sure that the context in which you are configuring the sticky group is associated with a resource class that allocates resources to stickiness. See the "Creating a Resource Class" section in Chapter 3. Step 2 Choose Load Balancing > Stickiness. The Stickiness pane appears. Step 3 Choose the VC_web context. Step 4 Add a new sticky group by clicking Add. The Stickiness configuration window appears. Step 5 Enter the following attributes for the new sticky group. Leave the remaining attributes blank or with their default values. •Group Name: StickyGroup1 •Type: HTTP Cookie •Cookie Name: Cookie1 •Sticky Server Farm: SF_web Step 6 Add the new sticky group to the Stickiness pane by clicking Deploy Now. Configuring HTTP Cookie Stickiness Using the CLI You can configure HTTP cookie stickiness using the CLI by following these steps: Step 1 Verify that you are operating in the desired context by checking the CLI prompt. If necessary, change to the correct context. host1/Admin# changeto VC_web host1/VC_web# Step 2 Enter configuration mode. host1/VC_web# config host1/VC_web(config)# Step 3 Create an HTTP-cookie-type sticky group and enter the cookie configuration mode. host1/VC_web(config)# sticky http-cookie Cookie1 StickyGroup1 host1/VC_web(config-sticky-cookie)# Step 4 Configure a timeout for HTTP cookie stickiness. host1/VC_web(config-sticky-cookie)# timeout 1440 Step 5 Associate a server farm with the sticky group and exit configuration mode. host1/VC_web(config-sticky-cookie)# serverfarm SF_web host1/VC_web(config-sticky-cookie)# exit host1/VC_web(config)# exit host1/VC_web# Step 6 Display the HTTP cookie configuration. host1/VC_web# show running-config sticky Configuration Example for the Hash Header Predictor The following example shows how to configure the hash header predictor. 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 roundrobin rserver RS_WEB1 80 inservice rserver RS_WEB2 80 inservice rserver RS_WEB3 80 inservice rserver RS_WEB4 80 inservice 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 serverfarm SF_WEB 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.2 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 a sticky group using the HTTP-cookie method. In the next chapter, you will configure SSL security.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks