This document provides a sample configuration for the CSS 11xxx Products and Web Applications in order to keep a client stuck to the same server, whether you use HTTP or SSL.
Ensure that you meet these requirements before you attempt this configuration:
Understand the basics of HTTP and SSL.
Have knowledge about CSS 11xxx Products and Web Applications.
The information in this document is based on these software and hardware versions:
Cisco WebNS Software Release 5.00 and later
All Cisco CSS 11xxx series Content Services Switches
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Many web sites have clients enter their site with the help of Hypertext Transfer Protocol (HTTP) port 80, but want the clients to transition to Secure Socket Layer (SSL) protocol during the session for secure transactions. Here is a way to keep a client stuck to the same server, whether you use HTTP or SSL.
The client requests HTTP traffic destined to the Virtual IP (VIP). The switch makes a load balance decision. In this document, traffic goes to server s1. The client is then stuck to server s1 based on one of the advance-balance methods, such as sticky-srip, sticky-srcip-dstport, and cookies. Refer to Configuring Sticky Parameters for Content Rules for more information.
During the session of the client, the transition is made to SSL port 443 when the client selects a link on the page that redirects to https. This causes a new content rule to be hit and the client may be load-balanced to another server. As the traffic is now encrypted https (SSL/TLS), the CSS is not able to check above layer 4 (the TCP port number) for cookies, URLs etc., because the requests are encrypted when the information passes the CSS. In order to prevent the occurrence of this issue, configure the redirecting HREF on each server to point back to https at the same servers public address, not the VIP address, as shown here:
<A HREF="https://servers_own_ip_address/path"> secure site </A>
If your servers are in a private address space, configure SSL content rules for each server with a HREF on each server that points to the SSL Content rules VIP.
You may also need to make some modifications to configurations of web applications on secured servers s1 and s2.
Also a content rule with a sticky configuration set to advanced-balance cookies requires all clients to enable cookies on their browser.
In this section, you are presented with the information to configure the features described in this document.
This document uses this configuration:
CSS11XXX with WebNS 5.00 and later - Running Configuration
|CSS11XXX with WebNS 5.00 and later - Running Configuration|
!Generated on 10/10/2001 18:12:17 !Active version: ap0500015s configure !************************** SERVICE************************** service s1 ip address 10.10.1.101 active service s2 ip address 10.10.1.102 active !*************************** OWNER*************************** owner cookie-ssl content layer5cookie vip address 10.10.1.66 protocol tcp port 80 url "/*" advanced-balance arrowpoint-cookie !--- Specify a port in the content rule to use this option. !--- Port 80 traffic is used here. !--- All clients must enable cookies on their browser. add service s1 add service s2 active content s1-ssl vip address 10.10.1.88 protocol tcp port 443 application ssl add service s1 active content s2-ssl vip address 10.10.1.99 protocol tcp port 443 application ssl add service s2 active !--- Use this HREF on server S1 where switching from http to https: <A HREF="https://10.10.1.101/applicationpath1/"> secure site s1 </A> !--- Use this HREF on server S2 where switching from http to https: <A HREF="https://10.10.1.102/applicationpath2"> secure site s2 </A> !--- In the example, the addresses for servers s1 and s2 must be !--- reachable from the client. If this is not the case, you must add a !--- content rule for each server with a unique publicly routable VIP !--- address and one service for each SSL server, as shown here: content s1-ssl vip address 10.10.1.88 protocol tcp port 443 application ssl add service s1 active content s2-ssl vip address 10.10.1.99 protocol tcp port 443 application ssl add service s2 active !--- Use this HREF on server s1 where the switch from http to https occurs: <A HREF=https://10.10.1.88/applicationpath1/> secure site s1 </A> !--- Use this HREF on server s2 where the switch from http to https occurs: <A HREF=https://10.10.1.99/applicationpath2> secure site s2 </A>
There is currently no verification procedure available for this configuration.
There is currently no specific troubleshooting information available for this configuration.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.