Catalyst 6500 Series Switch Content Switching Module (CSM) Installation and Configuration Note, Software Release 4.2(x)
Product Overiew
Downloads: This chapterpdf (PDF - 427.0KB) The complete bookPDF (PDF - 3.59MB) | Feedback

Product Overview

Table Of Contents

Product Overview

Terminology

CSM Operation

Configuration Mode

Session Persistence

Address Translation

Health Checking

Redundancy

CSM Traffic Flow

New Features

Front Panel Description

Status LED

RJ-45 Connector


Product Overview


The Content Switching Module (CSM) is a single slot service module for the Catalyst 6500 Series Switch. The CSM provides high-performance server load balancing (SLB) for clusters of network devices, such as web servers, fire walls, and caches.

A server load balancing device provides a public IP address for clients to reach the service and executes a server-selection algorithm to distribute client requests among the servers.

The CSM provides intelligent load balancing by offering a wide variety of configurable server-selection algorithms. Also, the CSM provides content switching by inspecting incoming messages (to a configurable depth) as part of the distribution decision.

The CSM performs server health checks, so that requests are only sent to operational servers. The CSM supports a variety of configurations (including redundant configurations) to maximize the performance and availability of the network servers.

The CSM supports session persistence, which ensures that all related requests from one client are handled by the same server. This capability is required in applications such as e-commerce and stateful firewall.

The following sections provide additional detail about the operation and features of the CSM:

Terminology

CSM Operation

CSM Traffic Flow

New Features

Front Panel Description

Terminology

CSM configuration commands use the following terminology:

Real server

A physical server resource, identified by an IP address. One physical server may implement more than one real server (each real server needs a unique IP address).

Server farm

A logical group of real servers that provide a service. The CSM balances the workload among the real servers, using the load balancing algorithm configured for this server farm.

Virtual server

A public Virtual IP address (VIP), which the clients use to request the network service. In Layer 4 switching, the virtual server has only one associated server farm. In Layer 7 switching, the virtual server chooses the server farm based on rules (policies) that it applies to incoming packets.

Layer 4 switching

The CSM selects the virtual server based on Layer 3 and Layer 4 information in the incoming packet (such as source IP address, destination IP address, protocol, and port number). The CSM selects the server farm associated with this virtual server.

Layer 7 switching

Server selection is based on Layer 5-7 information. The CSM selects the virtual server based on Layer 3 and Layer 4 information. The CSM selects the server farm by matching upper layer information in the incoming packet (such as the HTTP header) with policies associated with this virtual server.

Policy

In Layer 7 switching, a policy defines the conditions that the incoming packet must match for the CSM to select the associated server farm.

Predictor

Load balancing algorithm. The CSM supports a variety of predictors. Each server farm can have only one predictor.

Flow or connection

Group of packets that fulfill one transaction (for example, a TCP connection). The CSM identifies a specific flow by inspecting the source and destination IP addresses, and the protocol id (and the port number, if relevant). Flows are bidirectional.

Session

A set of related connections. For example, an online shopping session (browse items, fill a shopping cart, check out) requires many connections (simultaneous and sequential).

Session persistence (stickiness)

This capability ensures that all connections from one client session are all handled by one server, so that session information is not lost. For example, shopping cart information is retained at the server. If the CSM sent subsequent requests to a different server, the contents of the cart would disappear.


Figure 1-1 shows the relationships among virtual servers, policies and server farms.

Figure 1-1 Relationships between CSM configuration concepts

CSM Operation

In a Server Load Balancing (SLB) deployment, clients connect to a client-side VLAN and servers connect to a server-side VLAN (see Figure 1-2). A client sends a request through the network to the virtual server VIP address. The CSM performs server selection, and bridges the traffic between the client VLAN and the server VLAN.

Figure 1-2 CSM Location in the Network

The following sections describe CSM operation in more detail:

Configuration Mode

Session Persistence

Address Translation

Health Checking

Redundancy

Configuration Mode

The CSM can operate in bridge mode, router mode, or one-arm mode.

In bridge mode, the client-side and server-side VLANs exist on the same subnet. Bridge mode is also known as transparent mode, because CSM traffic handling is not visible at Layer 3. This mode is very convenient when deploying transparent load balanced devices like fire walls and cache servers.

In router mode, the client-side and server-side VLANs exist on different subnets. This mode is also known as secure mode, as clients cannot access the servers directly. This mode is preferable when you need efficient server-to-server communication, as the real servers are on the same subnet. Router mode is more flexible than bridge mode because real servers can be located anywhere in the Layer 3 network.

In bridge mode and router mode, the CSM is configured inline, which means that all traffic between the client and server flows through the CSM. In One-arm mode, the CSM is not configured inline. Traffic that requires load-balancing needs to flow through the CSM. Other traffic can bypass the CSM.

Session Persistence

This capability ensures that all connections from one client session are handled by one real server, so that session information is not lost. For example, shopping cart information is retained at the server. If the CSM sent subsequent requests to a different server, the contents of the cart would disappear.

You can configure the message fields that the CSM will inspect to identify the session.

Address Translation

You can configure each server farm to operate in directed mode or dispatch mode. In directed mode, the destination address in the message is replaced (using the NAT function) to be the address of the selected real server.

In dispatch mode, the destination address is not replaced. This mode is applicable to transparent applications like fire walls, in which the original destination address needs to be preserved.

Health Checking

The CSM supports health probes, which monitor the real servers. If a probe detects a problem, the selection algorithm ignores the server until it becomes operational again. The CSM supports several types of health probes, which you can configure on a server farm or on a real server. Active probes can run TCP, HTTP, or configurable scripts. In-band health monitoring looks for catastrophic errors (server reset, or no response from server). In-band response parsing checks for HTTP return codes like "service unavailable".

Redundancy

The MSFC and the CSM both provide high availability configuration options. The available options depend on your configured CSM deployment mode. The MSFC uses HSRP to provide redundancy for Layer 3 interfaces that often serve as default gateways for the CSM client-side VLAN and real servers. The CSM uses a fault tolerant (FT) VLAN configuration to provide redundancy between each pair of CSM modules residing in either in the same or a separate chassis. The two CSMs exchange connection information, so that stateful connections are maintained after a switchover.

CSM Traffic Flow

This section describes how the traffic flows between the client and server in a CSM environment. (See Figure 1-3.)

Figure 1-3 Traffic Flow Between Client and Server


Note The numbers in Figure 1-3 correspond to the steps in the following procedure.


When you enter a request to display a web page, the traffic flows as follows:

1. The user enters a URL. (The user enters "www.example.com" in the example shown in Figure 1-3).

2. The client contacts a DNS server to locate the IP address associated with the URL.

3. The DNS server sends the IP address of the virtual IP (VIP) to the client.

4. The client uses the VIP address to send the HTTP request to the CSM.

5. The CSM receives the request, makes a load-balancing decision, and selects a server.

For example, in Figure 1-3, the CSM selects server X from the www.example.com server pool

6. The CSM performs Network Address Translation (NAT), replacing the destination address (originally the VIP address) with the address of server X, and forwards the request to the server.

7. The server processes the request and sends a response, which is directed to the CSM. The CSM performs NAT on the response, and sends it to the client.

New Features

This software release contains new feature sets in addition to supporting CSM functionality from previous releases. The tables in this section list these feature sets.

Table 1-1 lists the new CSM features in this release.

Table 1-1 New CSM Feature Set Description 

Features New in this Release
Description

HTTP header sticky

Allows you to configure the CSM to perform stickiness based on the contents of the HTTP header (for example, the MSISDN1 number, service key, and session ID).

Configuration synchronization

Supports the synchronization of the configuration between the active and the standby CSM over the fault-tolerance VLAN.

Fail over tracking for interfaces and critical devices

Allows you to track the state of HSRP groups, physical interfaces, and gateways.

Private VLANs

Enables the use of private VLANs (PVLANs) with the CSM.

Partial server farm fail over

When you configure a backup server farm, you can define threshold values so that the CSM fails over to the backup server farm if the primary server farm partially fails.

Server probe fail state improvements

Allows you to specify a number of successful retries needed to put a failed server back in service.

Real name option

Allows you to specify details about an entity. This option is applicable for probe, vserver, VLAN, and server farm modes.

NAT configuration enhancements

Provides source NAT (nat client) configuration rules to the policy level.

Infinite idle time-out

Allows you to keep a connection open for an indefinite time period.

VIP dependencies

Provides the ability to link VIPs together to automatically take a dependent VIP out of service if the specified VIP goes out of service.

Ordering of policies

Provides the ability to assign a priority value to a particular policy.

Maximum parse length reached behavior change

CSM load balances maximum parse length connection requests to the default policies.

Slow start improvements

Allows real servers to be in slow-start mode until the slow-start timer value expires or the conn_count is equal to that of the other real servers.

Non-secure router mode

Extends the environment variable to route a SYN packet, in addition to a non-SYN packet, that does not hit a VIP.

Increase vserver limit

Increases the number of virtual servers configurable with a particular VIP from 128 to 1000.

Remote desktop protocol

Adds an environment variable to configure MSTS-RDP2 .

1 MSISDN = mobile station ISDN

2 MSTS-RDP = Microsoft Terminal Services Remote Desktop Protocol


Table 1-2 lists the full set of CSM features available in this release.

Table 1-2 CSM Feature Set Description 

Features
Supported Hardware

Supervisor 1A with MSFC and PFC

Supervisor 2 with MSFC and PFC

Supervisor 720—requires CSM software release 3.1(4) or later

Supported Protocols

TCP load balancing

UDP generic IP protocol load balancing

Special application-layer support for FTP and the Real Time Streaming Protocol (RTSP)

Server Application State Protocol (SASP)

Layer 7 Functionality

Full regular expression matching

URL, cookie switching, Generic HTTP header parsing, HTTP method parsing

Miscellaneous Functionality

VIP connection watermarks

Backup (sorry server) and server farm

Optional port for health probes

IP reassembly

TCL (Toolkit Command Language) scripting

XML configuration interface

SNMP

GSLB (Global Server Load Balancing)-requires a license

Resource usage display

Configurable idle and pending connection timeout

Idle timeout for unidirectional flows

STE integration for SSL load balancing

Real server names

TCP connection redundancy for all types of flows (TCP, UDP, and IP)

Fault-tolerant show command enhancements

IOS SLB FWLB interoperation (IP reverse-sticky)

Multiple CSMs in a chassis

CSM and IOS-SLB functioning simultaneously in a chassis

Configurable HTTP 1.1 persistence (either all GETs are made to the same server or are balanced to multiple servers)

Fully configurable NAT

Server-initiated connections

Route health injection

Load-balancing Algorithms

Round-robin

Weighted round-robin (WRR)

Least connections with slow-start enable for real servers

Weighted least connections

URL hashing

Source IP hashing (configurable mask)

Destination IP hashing (configurable mask)

Source and destination IP hashing (configurable mask)

Load Balancing Supported

Server load balancing (TCP, UDP, or generic IP protocols)

Firewall load balancing

DNS load balancing

Stealth firewall load balancing

Transparent cache redirection

Reverse proxy cache

SSL off-loading

VPN-IPSec load balancing

Generic IP devices and protocols

Stickiness

Cookie sticky with configurable offset and length

SSL ID

Source IP (configurable mask)

HTTP redirection

Redundancy

Sticky state

Full stateful failover (connection redundancy)

Health Checking

HTTP

ICMP

Telnet

TCP

FTP

SMTP

DNS

Return error-code checking

Inband health checking

User-defined TCL scripts

Management

SNMP traps

Full SNMP and MIB support

XML interface for remote CSM configuration

Back-end encryption support

Workgroup Manager Support

Server Application State Protocol (SASP)


Front Panel Description

Figure 1-4 shows the CSM front panel.

Figure 1-4 Content Switching Module Front Panel


Note The RJ-45 connector is covered by a removable plate.


Status LED

When the CSM powers up, it initializes various hardware components and communicates with the supervisor engine. The Status LED indicates the supervisor engine operations and the initialization results. During the normal initialization sequence, the status LED changes from off to red to orange to green.


Note For more information on the supervisor engine LEDs, refer to the Catalyst 6500 Series Switch Module Installation Guide.


Table 1-3 describes the Status LED operation.

Table 1-3 Content Switching Module Status LED 

Color
Description

Off

The module is waiting for the supervisor engine to provide power.

The module is not online.

The module is not receiving power, which could be caused by the following:

Power is not available to the CSM.

Module temperature is over the limit1 .

Red

The module is released from reset by the supervisor engine and is booting.

If the boot code fails to run, the LED stays red after power up.

Orange

The module is initializing hardware or communicating with the supervisor engine.

A fault occurred during the initialization sequence.

The module has failed to download its FPGAs2 on power up but continues with the remainder of the initialization sequence and provides the module online status from the supervisor engine.

The module has not received module online status from the supervisor engine. This problem could be caused by the supervisor engine detecting a failure in an external loopback test that it issued to the CSM.

Green

The module is operational; the supervisor engine has provided module online status.

Green to orange

The module is disabled through the supervisor engine CLI 3 using the set module disable mod command.

1 Enter the show environment temperature mod command to display the temperature of each of four sensors on the CSM.

2 FPGA = Field Programmable Gate Arrays

3 CLI = command-line interface.


RJ-45 Connector

The RJ-45 connector, which is covered by a removable plate, is used to connect a management station device or a test device. This connector is used by field engineers to perform testing and to obtain dump information