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 .
|
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.
|
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