Guest

Cisco CSS 11500 Series Content Services Switches

CSS 11000 Layer 5 Content Rules

Cisco - CSS 11000 Layer 5 Content Rules

Document ID: 21301

Updated: Jan 30, 2006

   Print


Contents


Introduction

This tech note describes the specific behavior of Layer 5 content rules, how they apply to HTTP (port 80) requests, and how to use them to determine what the problem might be.

Content rules on the CSS 11000 are used to load balance traffic.  There are essentially three types of content rules that balance traffic - Layer 3, Layer 4, and Layer 5. Although there are many variations of these types, every content rule falls into one of these categories, and the Content Services Switches (CSS) deals with each of these differently.

Hardware and Software Versions

The information in this document is based on the software and hardware versions below.

  • WebNS version 5.0 build 10

  • Hardware version CSS 11150

Layer 5 Content Rule Description

A Layer 5 load balancing configuration enables the CSS to use a Virtual IP (VIP) address to load balance Web traffic to Web servers based on URLs. Because a Layer 5 rule needs to inspect the user's request for a URL, the CSS must proxy, or "spoof," the connection in order to make a load balancing decision.  When a connection is sent to the VIP specified in a Layer 5 content rule the CSS will complete the TCP handshake with the client.  The client will then send an HTTP header that includes a request for content (for example, GET /sample/index.html).  The CSS evaluates the request by the client and makes a load balancing decision.

Basic Layer 5 Content Rule

The following is a sample of a basic Layer 5 content rule:
 
!*************************** OWNER ***************************
owner test

  content layer5
    protocol tcp
    vip address 172.17.63.201
    add service server1
    port 80
    url "/*"
    active

In the above content rule the entry url "/*" makes the rule Layer 5.  Without the url "/*" statement the CSS would consider this a Layer 4 rule. If this were a Layer 4 rule the CSS  would not spoof the connection but would simply perform a network address translation (NAT) on the packet and send it to a service in the content rule.  But because the above content rule has the url "/*" statement, if a connection was made to the VIP address of 172.17.63.201 the CSS would spoof the connection (complete the TCP handshake) and would inspect the HTTP header for the URL requested.  Once the CSS parses the HTTP header and determines the URL, it then makes a load balancing decision.  After it makes it's load balancing decision it completes a TCP handshake to one of the load balanced services (spoofing as the client) and the request for the content is served back to the client.

How To Troubleshoot a Layer 5 Content Rule

Because the CSS has to complete the TCP handshake in order to determine what URL the client is requesting it is very important that the CSS has a route back to the client making the request.  Without a route back to the client the CSS is unable to complete the TCP handshake, and therefore a connection to a Layer 5 rule will fail.  The easiest way to ensure a route back to the client is to either have a route statement for the clients specific network or to have a default route configured on the CSS.

The two most important steps in configuring a Layer 5 content rule are:

  • url "/*" statement in the content rule
  • route back to client

How to Verify the Content Rule

You can verify the configuration of a content rule by issuing the show run owner command.  This command will show you the running configuration starting at the owner section.  The output from this command will look similar to following:
 
!*************************** OWNER ***************************
owner test

  content layer5
    protocol tcp
    vip address 172.17.63.201
    add service server1
    port 80
    url "/*"
    active

To verify the specific parameters of a particular rule issue the show rule or show rule {owner}{content rule} commands. For example, below is the output from a show rule test layer5.
 
Name:                  layer5   Owner:             test
State:               Active   Type:              HTTP
Balance:          Round Robin   Failover:           N/A
Persistence:          Enabled   Param-Bypass:  Disabled
IP Redundancy:  Not Redundant
L3:         172.17.63.201
L4:         TCP/80
Url:     /*
Redirect: ""
Rule Services:
 1: server1-Alive
Notice in the above output the state is Active and Url is /*.  These parameters are important to see if the content rule is active and what URL information we are looking for.  In the above example the content rule is Active and we are matching on any URL.

Below is the output from another useful command, show rule-summary.

VIP Address     Port  Prot Url                CntRuleName    OwnerName  State
--------------- ----- ---- ------------------ -------------- ---------- ------
172.17.63.201   80    TCP  /*                 layer5         test       Active

Determining Why a Content Rule Is Not Working

One common troubleshooting problem is determining why a content rule isn't working.  In the sample content rule above, there is a Layer 5 content rule with a single service called server1. 

Problem

When you try to connect to the VIP specified in the content rule, you get an error message in your browser that says the connection was reset by peer or that the page cannot be displayed.  Knowing that the CSS is spoofing the connection (because of the Layer 5 rule), you believe that there is a problem with the CSS.  When you look at a sniffer capture of the traffic, you see your client complete the TCP handshake, perform an HTTP GET, and immediately get a TCP/RST (reset) from the CSS.  Why does this happen?

Solution

The first step in troubleshooting this type of scenario is to determine whether the content rule and the service are alive.  This can be done by issuing the show rule command.

Name:                  layer5   Owner:             test
State:               Active   Type:              HTTP
Balance:          Round Robin   Failover:           N/A
Persistence:          Enabled   Param-Bypass:  Disabled
IP Redundancy:  Not Redundant
L3:         172.17.63.201
L4:         TCP/80
Url:        /*
Redirect: ""
Rule Services:
 1: server1-Down
As you can see, the state of the rule is Active but the state of the service in the rule is Down.  In this scenario, the problem was that all the services bound to that content rule were in a Down state.

After the CSS completed the TCP handshake, the client issued an HTTP request for content.  The CSS inspected the HTTP header for the URL information determined that the request matched content rule layer5.  Because no services were alive for the content rule, the CSS issued a TCP/RST to close out the connection.


Related Information


Updated: Jan 30, 2006
Document ID: 21301