|
|
This publication describes the features, modifications, and caveats for the Catalyst 6500 Series Content Switching Module (CSM) software release 2.2(8) running Cisco IOS Release 12.1(13)E3 or Catalyst operating system 7.5 or higher.
 |
Note Except where specifically differentiated, the term "Catalyst 6500 series switches" includes both Catalyst 6500 series and Catalyst 6000 series switches. |
This section describes the system requirements for the Catalyst 6500 Series CSM software release 2.2(7).
The Catalyst 6500 Series CSM memory is not configurable.
Before you can use the Catalyst 6500 Series CSM, you must have a Supervisor Engine 1A or a Supervisor Engine 2 with a Multilayer Switch Feature Card (MSFC1 or MSFC2), a Policy Feature Card (PFC), and any module with ports to connect server and client networks. The PFC is required for the VLAN access control list (VACL) capture functionality.
 |
Caution The WS-X6066-SLB-APC module is not fabric enabled. |
Software release 1.1(1) requires Cisco IOS Release 12.1(6)E or 12.1(7)E.
Software release 1.2(1) requires Cisco IOS Release 12.1(8a)E.
Software release 2.1(1) requires Cisco IOS Release 12.1(8a)EX or 12.1(11b)E. However, Cisco IOS Release 12.1(11b)E includes some Cisco IOS commands that refer to CSM 2.2 features that are not supported by a CSM 2.1 image.
Software release 2.1(2) and 2.1(2a) requires Cisco IOS Release 12.1(8a)EX.
Software release 2.1(3) and 2.13(a) requires Cisco IOS Release 12.1(8a)EX or 12.1(11b)E. However, Cisco IOS Release 12.1(11b)E includes some Cisco IOS commands that refer to CSM 2.2 features that are not supported by a CSM 2.1 image.
Software release 2.1(4) requires Cisco IOS Release 12.1(8a)EX or 12.1(11b)E. However, Cisco IOS Release 12.1(11b)E includes some Cisco IOS commands that refer to CSM 2.2 features that are not supported by a CSM 2.1 image.
Software release 2.2(1) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(1) are only available with Cisco IOS Release 12.1(11b) E and subsequent releases.
Software release 2.2(2) and 2.2(b) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(2) and 2.2(b) are only available with Cisco IOS Release 12.1(11b) E and subsequent releases
Software release 2.2(3) and 2.2(3a) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(3) are only available with Cisco IOS Release 12.1(11b) E and subsequent releases.
Software release 2.2(4) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(4) are only available with Cisco IOS Release 12.1(11b) E and subsequent releases.
Software release 2.2(5) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(5) are only available with Cisco IOS Release 12.1(11b) E and subsequent releases.
Software release 2.2(6) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(6) are only available with Cisco IOS Release 12.1(11b) E and subsequent releases.
Software release 2.2(7) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(7) are only available with Cisco IOS Release 12.1(13) E3 and Catalyst operating system release 7.5 and subsequent releases.
Software release 2.2(8) requires Cisco IOS Release 12.1(8a)EX or higher. However, the features new to CSM Release 2.2(8) are only available with Cisco IOS Release 12.1(13) E3 and Catalyst operating system release 7.5 and subsequent releases.
|
Caution Only CSM software release 2.27 and higher can be used in a Catalyst 6500 Series switch with the Catalyst operating system release 7.5. |
Table 1 lists the software releases and applicable ordering information for the Catalyst 6500 series CSM module software.
Table 1 Software Release/Orderable Product Number Matrix
|
Table 2 describes the CSM features and software descriptions.
Table 2 CSM Feature Set Description
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In all releases, when the MINCONNS value is set, once a real server has reached the maximum connections (MAXCONNS) state, no additional session is balanced to it until the number of open sessions to that real server falls below MINCONNS. With the no MINCONNS value set in release 1.1(1), no additional session would be balanced until the number of open sessions to that real server falls to 0.
|
Note Configuring stateful redundancy with CSMs in separate chassis requires a gigabit link between the CSMs. |
These sections describe the following release caveats:
This section describes known limitations that exist in CSM software release 2.2(8).
The CSM processes the TCP connection, although the MAC address is not intended for that port. Occasionally, the switch floods a SYN (synchronize) packet to all bridge ports. In this case, the CSM incorrectly resets or load balances the unintended connection.
Workaround: In most cases, the bridge device sends the destination MAC addresses to the correct port.
These restricted CSM port commands return the "failure" message instead of the "feature not supported" message: set port cdp, set port trap, set spantree portpri, and set spantree link-type.
The last module in the chassis may not be shut down gracefully.
The standby CSM incorrectly reports that it learned the address resolution protocol (ARP) address for a server or gateway on both sides of the bridging VLANs. The problem is caused by the external device, which overwrites the padding data in the ARP requests inserted by the CSM.
Token Ring and FDDI VLANs should not be allowed on CSM trunk ports.
The CSM drops packets because the multilayer switch (MLS) card and the multilayer switch feature card (MSFC) use different MAC addresses. This problem remains in software releases prior to the Catalyst 7.5.1 software release. If any Supervisor Engine 2 in the switch is still running a software release prior to the 7.5.1 software release and the traffic is forwarded by that switch, the CSM drops the packet.
During a CSM reset, the show module command displays the module as faulty when it should be displayed as "Other."
FTP virtual server IP addresses cannot also be client NAT IP addresses. If there is an overlap between the IP address range for a virtual server on which `service ftp' is configured and a configured client NAT IP address range, connections through that virtual server are not handled properly.
Workaround: Configure the FTP virtual server IP address and client NAT addresses to ensure that there is no address overlap.
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames may be dropped. When you use the CSM connection replication feature, you must disable IGMP snooping on both the active and standby CSM modules.
Workaround: To disable IGMP snooping, use the no ip igmp snooping command in global configuration submode on the Catalyst 6500 series switch.
TCL script probes are sensitive to network overload, congestion, and delay.
Workaround: To avoid spurious health monitoring results in which real servers are considered unhealthy due to network delay or congestion, we recommend that you set the "retry" value greater than 1 for all TCL script probes.
Established FTP connections are not replicated to the standby CSM when the standby becomes operational. To enable an FTP connection for replication from an active CSM to a standby CSM, the standby CSM must be operational at the time the FTP connection is opened. If the FTP connection is opened prior to the standby CSM booting and becoming operational, the FTP connection never replicates to the backup.
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a. Avoid using asynchronous sockets. For example, avoid calling the socket command with the -async option.
b. Avoid calling the gets command. Use the read command instead.
When multiple CSM users perform a do copy xx running-config from a CSM submode in Cisco IOS, the next command entered will fail with the message "% CSM parser state not found." This problem occurs only if the file copied to running-config contains at least one CSM command. When the CSM command in the file copied to running-config is run, it overwrites the current CSM configuration parser state.
Workaround: Do not perform a do copy xx running-config operation from a CSM configuration submode. You can also exit out to the top level configuration submode and then re-enter the desired CSM configuration submode.
Beginning with Cisco IOS Release 12.1(13)E, it is possible for multiple users to simultaneously issue configuration commands for the same CSM. When you use this capability, it is possible to corrupt the configuration. In particular, if one user changes the "type" of an object while another user is simultaneously configuring that same object, the configuration will be corrupted. For example, if a user changes probe "FOO" from type "script" to type "http" while another is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration in such an inconsistent way.
With Multiple Spanning Tree (MST) or Rapid PVST (RPVST) enabled, CSM failover time is excessive. When MST or RPVST is enabled and the spanning tree protocol is configured on a CSM client or server VLAN, it may take up to one minute for traffic flow through a CSM to resume after a CSM failover. The delay is caused by reconvergence of the Spanning Tree Protocol (STP).
Workaround: Ensure that MST and RPVST are not enabled on the Catalyst 6500 series switch containing the CSM, or ensure that the spanning tree protocol is disabled on the CSM client and server VLANs.
Some FTP connections may not replicate. An FTP connection through an active CSM is not replicated if no data channel has been setup for the connection. Data channels are typically established when the client uses a get or put command on a file or performs a directory listing.
CSM software release 3.1(2) does not support the Real Time Streaming Protocol (RTSP) and User Datagram Protocol (UDP) streaming when a client NAT is enabled. If this configuration is set up, the server attempts to open a UDP connection. Some RTSP clients then fall back to interleaved mode (inline TCP). This mode works in the application software, although the connection is sent to fastpath.
The CSM does not support creating more than 127 virtual servers with the same virtual IP (VIP) address, even though the CLI does allow you to configure more than 127 virtual servers. If you use the CLI to configure more than 127 virtual servers, the 128th and subsequent virtual servers will not function properly.
Workaround: Do not configure more than 127 virtual servers on the same VIP.
In firewall configurations using an HTTP 1.1 redirect virtual server, a connection going through the firewalls may remain open after a redirect virtual server connection is established.
Workaround: None. This connection closes when it times out.
You cannot configure different fault-tolerant pairs to use the same fault-tolerant VLAN.
Workaround: Use a different fault-tolerant VLAN for each fault-tolerant CSM pair.
Issuing the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
In the CSM, it is important that packets transmitted from the CSM toward a client (server) are transmitted on the same VLAN as packets received by the CSM from that same client (server). This constraint may be satisfied as follows:
To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
For load balancing to function properly, all traffic arriving from the 10.0.0.0/24 subnet must reach the CSM through VLAN 10.
The output from the show interface gigabit slot/port command may erroneously indicate that one or more of the CSM gigabit ports are down.
Workaround: Disregard the display.
This section describes caveats that have been resolved in CSM software release 2.2(8).
This section describes known limitations that exist in CSM software release 2.2(7).
Some restricted CSM port commands return "failure" instead of "feature not supported."
The last module in the chassis may not be shut down gracefully.
In certain network setups, the standby CSM incorrectly reports that it learned the ARP address for a server or gateway on both sides of the bridging VLANs. The problem is caused by the external device, which overwrites the padding data in the ARP requests inserted by the CSM.
Token Ring and FDDI VLANs should not be allowed on CSM trunk ports.
In a Hybrid Catalyst system, a switch running both Cisco IOS and the Catalyst operating system, the CSM stays as the active system if the MSFC was shut down and the switch processor is still running.
Workaround: Manually shut down the CSM.
The CSM drops packets because MLS and the MSFC use different MAC addresses. This problem is still in pre Catalyst 7.5.1 software releases. If any Supervisor engine 2 in the switch is still running pre 7.5.1 software and the traffic is forwarded by that switch, the CSM drops the packet.
During reset of the CSM, show module command displays the module as faulty when it should be displayed as "Other."
Release 2.2(x) does not support RTSP UDP streaming when a client NAT is enabled. If this configuration is set up, the server attempts to open a UDP connection. Some RTSP clients then fall back on interleaved mode (inline TCP). This mode will work in the application software, although the connection is sent to fastpath.
The CSM does not support creating more than 127 virtual servers with the same virtual IP (VIP) address, even though the CLI does allow you to configure more than 127 virtual servers. If you use the CLI to configure more than 127 virtual servers, the 128th and subsequent virtual servers will not function properly.
Workaround: Do not configure more than 127 virtual servers on the same VIP.
Issuing the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
You cannot configure different fault-tolerant pairs to use the same fault-tolerant VLAN.
Workaround: Use a different fault-tolerant VLAN for each fault-tolerant CSM pair.
In firewall configurations using an HTTP 1.1 redirect virtual server, a connection going through the firewalls may remain open after a redirect virtual server connection is established.
Workaround: None. This connection closes when it times out.
The output from the show interface gigabit slot/port command may erroneously indicate that one or more of the CSM gigabit ports are down.
Workaround: Disregard the display.
In CSM software release 2.x, it is important that packets transmitted from the CSM toward a client (server) are transmitted on the same VLAN as packets received by the CSM from that same client (server). This constraint may be satisfied as follows:
To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
For load balancing to function properly, all traffic arriving from the 10.0.0.0/24 subnet must reach the CSM through VLAN 10.
This section describes caveats that have been resolved in CSM software release 2.2(7).
When a VLAN interface is removed from the CSM configuration, the learned ARP entries associated with this subnet are still in the ARP table of CSM.
In the 2.2(7) release, the CSM now supports non-standard HTTP requests from the Wireless Application Protocol (WAP) devices.
When one of the firewalls fails ARP request, the ICMP health probe to other servers or firewalls will occasionally drop the ICMP reply. If the number of probe attempts is small, other ICMP health probes could incorrectly be marked as failed.
Workaround: Increase the probe retries count, and increase the probe failed interval for ICMP.
The CSM receive engine was limiting the ICMP probe rate to 60 probes per second. With the fix in the 2.2(7) release, the maximum ICMP health probe rate is at 600 probes per second.
When you configure a virtual server with a wildcard 0.0.0.0 address, and you use the clear module csm id conns vserver vs-name command, the command clears all current opened connections in the CSM.
The clear module csm x arp command does not clear the learned ARP entries.
Workaround: Any old learned ARP entries are removed in the next ARP probing cycle.
Sometimes the CSM cannot get the fault tolerance statistics from the hardware. In this case, the show module csm x ft command always returns an error. However, the fault tolerance function is still working.
This section describes known limitations that exist in CSM software release 2.2(6).
Release 2.2(x) does not support RTSP UDP streaming when a client NAT is enabled. If this configuration is set up, the server attempts to open a UDP connection. Some RTSP clients then fall back on interleaved mode (inline TCP). This mode will work in the application software, although the connection is sent to fastpath.
The CSM does not support creating more than 127 virtual servers with the same virtual IP (VIP) address, even though the CLI does allow you to configure more than 127 virtual servers. If you use the CLI to configure more than 127 virtual servers, the 128th and subsequent virtual servers will not function properly.
Workaround: Do not configure more than 127 virtual servers on the same VIP.
Issuing the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
You cannot configure different fault-tolerant pairs to use the same fault-tolerant VLAN.
Workaround: Use a different fault-tolerant VLAN for each fault-tolerant CSM pair.
In firewall configurations using an HTTP 1.1 redirect virtual server, a connection going through the firewalls may remain open after a redirect virtual server connection is established.
Workaround: None. This connection closes when it times out.
The output from the show interface gigabit slot/port command may erroneously indicate that one or more of the CSM gigabit ports are down.
Workaround: Disregard the display.
In CSM software release 2.x, it is important that packets transmitted from the CSM toward a client (server) are transmitted on the same VLAN as packets received by the CSM from that same client (server). This constraint may be satisfied as follows:
To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
For load balancing to function properly, all traffic arriving from the 10.0.0.0/24 subnet must reach the CSM through VLAN 10.
This section describes caveats that have been resolved in CSM software release 2.2(6).
The CSM drops the HSRP advertising traffic when the CSM should have been repeating them through the peer bridging VLAN.
The CSM drops the ICMP error message "Destination Unreachable with Type=3 and Code=3."
The CSM does not match lowercase cookies in HTTP headers. Normally the Web browsers use the capital C when sending the Cookie HTTP header field. The CSM now supports the lower-case c for the cookie header because there are private applications using the lower-case form.
If you configure the alias IP address for a VLAN first, before you configure the IP address for this VLAN, the VLAN IP address configuration fails. You should configure the IP address for the VLAN first.
Workaround: Remove both the alias and the IP addresses. Then configure the IP address and the alias in the correct order.
The connections configured for cookie sticky sometimes were not replicated to the standby CSM.
CSM TCP health probes are using an incorrect Maximum Segment Size (MSS) value of 1480. The correct default MSS option value should be 1460. Most of the servers ignore the high MSS value from the health probe messages.
Connection replication does not work after removing and adding a fault-tolerant VLAN. After removing the fault-tolerant VLAN between two CSMs, both fault-tolerant modules become active as expected. When you reconfigure the fault-tolerant VLAN, one CSM becomes active and the other becomes the standby module. The active CSM will not replicate the connections to the standby module.
Workaround: Reboot the standby CSM to resolve the problem.
Changing the redirect-vserver protocol through the SSL port command in some cases does not take effect. The redirect protocol (HTTP, HTTPS, FTP, etc.) would stay at the previously configured value.
Workaround: Take the real server out of service, and then return it to in-service to force the CSM to take the new value.
When configuring the NAT client command for a serverfarm with the FTP service, the CSM stops forwarding the FTP traffic after 8000 connections are made. There is a resource leak in the CSM with the client NAT and FTP service.
Under packet processing stress (high packet-per-second load), the NAT module on the CSM sends out a corrupted frame, which crashes the CSM resulting in a core dump and reboot.
The CSM sends multiple GET requests of the same HTTP 1.1 persistent connection to the same server, even though this server has failed in between the GET requests. Thus, the subsequence GET will fail when the server fails.
The CSM is now generating the syslog and SNMP traps when taking the real server out of service. There is no syslog generated when putting the real server in service again.
The CSM now supports client NAT with the FTP service in the "passive" mode.
Workaround: Remove the client NAT option from the serverfarm.
This section describes known limitations that exist in CSM software release 2.2(5).
A virtual server configured with the service FTP option does not work if the client NAT option is enabled for the serverfarm and the FTP mode is passive. The passive mode has the client initiating the data connection (port 20). This caveat has been fixed for the port mode.
Workaround: If FTP passive mode is required, disable the client NAT option, otherwise allow only FTP port mode.
Release 2.2(x) does not support RTSP UDP streaming when a client NAT is enabled. If this configuration is set up, the server attempts to open a UDP connection. Some RTSP clients then fall back on interleaved mode (inline TCP). This mode will work in the application software, although the connection is sent to fastpath.
The CSM does not support creating more than 127 virtual servers with the same virtual IP (VIP) address, even though the CLI does allow you to configure more than 127 virtual servers. If you use the CLI to configure more than 127 virtual servers, the 128th and subsequent virtual servers will not function properly.
Workaround: Do not configure more than 127 virtual servers on the same VIP.
Issuing the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
You cannot configure different fault-tolerant pairs to use the same fault-tolerant VLAN.
Workaround: Use a different fault-tolerant VLAN for each fault-tolerant CSM pair.
In firewall configurations using an HTTP 1.1 redirect virtual server, a connection going through the firewalls may remain open after a redirect virtual server connection is established.
Workaround: None. This connection closes when it times out.
The output from the show interface gigabit slot/port command may erroneously indicate that one or more of the CSM gigabit ports are down.
Workaround: Disregard the display.
In CSM software release 2.x, it is important that packets transmitted from the CSM toward a client (server) are transmitted on the same VLAN as packets received by the CSM from that same client (server). This constraint may be satisfied as follows:
To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
For load balancing to function properly, all traffic arriving from the 10.0.0.0/24 subnet must reach the CSM through VLAN 10.
This section describes caveats that have been resolved in CSM software release 2.2(5).
The web browser will send more data than is specified in the Content Length field of the HTTP request to the email site. If this traffic needs to be load-balanced through the CSM and if the persistent rebalance option is enabled, the CSM will drop these requests.
Workaround: Disable the persistent rebalance option for virtual server.
The CSM leaks resources when an SYN and an RST are close to together in certain traffic patterns. This problem only occurs with Layer 4 load-balancing and only if the CSM receives an RST before it makes the load-balancing decision for that connection.
The service RTSP option for load-balancing streaming media traffic has memory leaks, causing the CSM to slowly run out of resources for the new RTSP flows. When resources are not available, the CSM will not load-balance any additional streaming media connections.
Workaround: Use IP sticky to match the RTSP control and data flows instead of using the service RTSP option.
In CSM release 2.2(4), when you configure the route subnet netmask gateway gateway-address command, the gateway-address cannot be in the specified subnet netmask. You cannot configure a route which overlaps the VLAN subnet interface.
In previous releases, after the real server failed with the inband health check option, the removal of the inband health option would not enable the server. This problem is resolved so that when you remove the inband health option with the no health option the CSM immediately enables the server without waiting for the failed timer duration.
Workaround: Configuring the real server with the no in-service option and then enabling it with the inservice command.
In some cases the CSM permanently disables a real server after that server fa