Release Notes for Catalyst 6500 Series Content Switching Module Software Release 3.1(10)
Available Languages
Table Of Contents
Release Notes for Catalyst 6500 Series Content Switching Module Software Release 3.1(10)
Open Caveats in Software Release 3.1(10)
Resolved Caveats in Software Release 3.1(10)
Open Caveats in Software Release 3.1(9)
Resolved Caveats in Software Release 3.1(9)
Open Caveats in Software Release 3.1(8)
Resolved Caveats in Software Release 3.1(8)
Open Caveats in Software Release 3.1(7)
Resolved Caveats in Software Release 3.1(7)
Open Caveats in Software Release 3.1(6)
Resolved Caveats in Software Release 3.1(6)
Open Caveats in Software Release 3.1(5)
Resolved Caveats in Software Release 3.1(5)
Open Caveats in Software Release 3.1(4)
Resolved Caveats in Software Release 3.1(4)
Open Caveats in Software Release 3.1(3)
Resolved Caveats in Software Release 3.1(3)
Open Caveats in Software Release 3.1(2)
Resolved Caveats in Software Release 3.1(2)
Open Caveats in Software Release 3.1(1a)
Resolved Caveats in Software Release 3.1(1a)
Server and Gateway Health Monitoring
Cisco IOS Software Documentation Set
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Release Notes for Catalyst 6500 Series Content Switching Module Software Release 3.1(10)
March 18, 2005
Previous Releases—3.1(9), 3.1(8), 3.1(7), 3.1(6), 3.1(5), 3,1(4), 3,1(3), 3,1(2), 3.1(1a), 3.1(1)
This publication describes the features, modifications, and caveats for the Catalyst 6500 series Content Switching Module (CSM) software release 3.1(10) operating on a Catalyst 6500 series switch with Cisco IOS software Release 12.1(13)E3 or Catalyst operating system software 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.
Contents
•
•
•
System Requirements
This section describes the system requirements for the Catalyst 6500 series CSM software release 3.1(10).
Memory Requirements
Hardware Supported
The CSM is now supported with either with a Supervisor Engine 1A (MSFC required), Supervisor Engine 2 (MSFC required), or Supervisor Engine 720 (the MSFC is not optional on the Sup720), and a module with ports to connect server and client networks.
Note
Caution
Software Compatibility
Table 1 and Table 2 list the CSM software release compatibility.
The minimum software release that is listed is required to support the CSM hardware with a given supervisor engine to perform basic CSM configuration. The recommended software release is the base release to support new commands for a given CSM release.
Software Release 3.1 Features
Table 3 lists the features that have been added to the CSM software in release 3.1.
Feature Set
Table 4 describes the CSM features and software descriptions.
New and Changed Information
•
A new environment variable, REAL_SLOW_START_ENABLE, is included in the 3.1(9) software release to control the rate at which a real server becomes operational when it is put into service. This new variable is only available for a server farm that has been configured with the least connection predictor.
The configurable range for this variable is 0 to 10. The setting of 0 disables the slow start feature. The value from 1 to 10 specifies how fast the newly activated server should become operational. The value of 1 is the slowest rate. The value of 10 specifies that the CSM would assign more requests to the newly activated server. The value of 3 is the default value.
If the configuration value is N, the CSM assigns 2 ^ N (2 raised to the N power) new requests to the newly active server at startup (assuming no connections were terminated at that time). As this server finishes or terminates connections; more connections are assigned. Normal connection assignments resume when the newly activated server has the same number of open connections as the other servers in a serverfarm.
•
•
•
•
•
http://www.cisco.com/cgi-bin/tablebuild.pl/cat6000-intellother
The following file contains the sample scripts: c6slb-script.3-1-6.tcl.
Limitations and Restrictions
•
•
•
•
Note
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. With no MINCONNS value set in release 1.2(1), no additional session is balanced until the number of open sessions falls below MAXCONNS.
•
•
•
If a health probe is configured on a real server without a configured TCP or UDP port, the CSM chooses the TCP or UDP port to probe from the virtual servers with which the real server is associated. If neither the real server nor the virtual server has a configured port, the CSM simply ignores any configured probes requiring ports to that real server.
•
Note
Note
Caveats
These sections describe the open and resolved caveats in CSM for all 3.1(x) software releases:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Open Caveats in Software Release 3.1(10)
Note
This section describes known limitations that exist in CSM software release 3.1(10).
•
The value for the Connections Timed-Out counter is not displayed correctly when you use the show module csm slot stats command. This counter is not consistent with the values displayed in the show module csm slot tech-support proc 1 command.
This data shows that the counter is not working properly CSM Code: 3.1.7
Switch# show mod csm 1 tech-support proc 1 | inc TimeTimeouts- Sessions examined 447391863 8308996Timeouts- Sessions timed out 1920012 181Timeouts- Active sessions timed out 297575 18Timeouts- Pending sessions timed out 1622437 163Timeouts- Unidir sessions timed out 0 0Timeouts- FT sessions timed out 0 0Switch# show mod csm 1 stats | inc Timed-OutConnections Timed-Out: 0Switch# show mod csm 1 tech-support proc 1 | inc TimeTimeouts- Sessions examined 454121112 6729249Timeouts- Sessions timed out 1920127 115Timeouts- Active sessions timed out 297594 19Timeouts- Pending sessions timed out 1622533 96Timeouts- Unidir sessions timed out 0 0Timeouts- FT sessions timed out 0 0Switch#Workaround: Use the command *show module csm <slot> tech-support proc 1*.
•
The CSM reserves 141 KB of memory on the PowerPC control processor for each TCL scripted health probe item configured on the CSM. A probe item is an instance of a probe object associated with a single real server.
This memory usage is much higher than anticipated. The PowerPC "Available Memory" counter from the show module csm slot tech-support utilization command should not be less than 40 MB.
Workaround: None.
•
When you configure a CSM in a fault-tolerant configuration and you have a fault-tolerant priority of 254, the CSM may take over the active role from the other CSM at startup. This situation could occur even when the fault-tolerant preempt option is disabled.
Workaround: Use fault-tolerant priority values lower than 254.
•
The CSM does not support pipelines (multiple HTTP requests sharing the packet boundary) with the persistent rebalance feature.
Workaround: None.
•
The CSM might not replicate the sticky entries for sticky group zero when it is configured under the virtual server. Because of the configuration download order, the active and redundant CSM may be assigned different group numbers when a group was not specified in the configuration.
Workaround: Configure a sticky group with a specific number, and assign it to the virtual server.
•
When using Cisco IOS Release 12.1(19)E or later with CSM 3.1(x) software, the sticky timeout is displayed as zero for all sticky entries, and the total entries count (CurrCount) for each sticky is also displayed as zero. These counters are supported only in CSM software release 3.2(1).
Workaround: Use the corresponding Cisco IOS software Release 12.1(13)E, which displays the configured timeout instead of the current timeout.
•
The set port cdp, set port trap, set spantree portpri, and set spantree link-type restricted CSM port commands return the "failure" message instead of the "feature not supported" message.
Workaround: None.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module and the multilayer switch feature card (MSFC) use different MAC addresses. This problem remains in software releases earlier than the Catalyst operating system software release 7.5.1. If any Supervisor Engine 2 in the switch is still operating with a software release earlier than the Catalyst operating system software release 7.5.1, and the traffic is forwarded by that switch, the CSM drops the packet.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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" to a value that is greater than one for all TCL script probes.
•
Established FTP connections are not replicated to the redundant CSM when the redundant CSM becomes operational. To enable an FTP connection for replication from an active CSM to a redundant CSM, the redundant CSM must be operational at the time the FTP connection is opened. If the FTP connection is opened prior to the redundant CSM booting and becoming operational, the FTP connection never replicates to the backup.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
When multiple CSM users perform a do copy xx running-config from a CSM submode in Cisco IOS software, 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 entered, 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 reenter the desired CSM configuration submode.
•
Beginning with Cisco IOS software 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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None.
•
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.
•
Entering the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(10)
Note
This section describes the caveats resolved in CSM software release 3.1(10).
•
The CSM may generate a core dump while processing an ICMP destination-unreachable packet.
Workaround: Block all ICMP dest_unreachable packets by setting the DEST_UNREACHABLE_MASK 0 variable to zero.
•
If you remove the global real object (by entering the no real global-real-name command) while the object is configured inside a serverfarm and has a redirect-vserver association, the CSM might stop responding.
Workaround: Remove the named real mapping configuration from the serverfarm, or remove the association with the redirect-vserver; then remove the global real object.
•
When you remove and then add back a VLAN with a new gateway, the CSM creates new encapsulated MAC address entries; however, the session may still select an old encapsulated ID to set up the return flow from the server to the client. The response from the server to the client is not forwarded properly to the client.
Workaround 1: Reboot the CSM.
Workaround 2: Add a specific route in the new VLAN for the affected client.
•
Under rare conditions, when you configure a CSM module in bridge mode and enable SPAN on the port channel to the CSM or on any of the VLANs that the CSM is bridging, you might notice this behavior: high CPU utilization on the CSM and on the route processor of the Catalyst 6500 series switch, high link utilization on the CSM port channel, and a high rate of MAC address relearning (or MAC address flapping) if MAC move notification is enabled on the switch.
Workaround 1: Disable SPAN on the CSM port channel and the VLANs associated with bridge mode on the CSM.
Workaround 2: Use routed mode on the CSM.
•
In the output of the show mod csm probe detail command, the transitions counter for GSLB statistics do not increment.
Workaround: None.
•
The CSM crashes with this core-dump data:
IXP4 Bad Data exception on task +IXP4 SA-CORE (Ex 5)...+
Cookie map matching type for a virtual server was configured. After a few million connections were established to this vserver, a crash could occur. If you have the sticky replication option enabled on this CSM, then the crash might occur sooner.
This problem exists in all prior CSM releases up to: 3.1(9), 3.2(3), 4.1(4), and 4.2(1).
Workaround: Remove the configuration for cookie map matching.
•
When the active CSM sends a replication sticky message to the standby CSM, the active CSM uses an incorrect source MAC address, which takes the format of a multicast MAC address. A Catalyst 6500 series switch will not drop these packets; however, other Layer 2 switch devices between the Catalyst 6500 switches would drop these packets.
Workaround: Set up a direct link between the two Catalyst 6500 switches for fault-tolerant VLAN traffic.
•
When you enter the show csm tech-support command, the GSLB process shows the real server in a down state, yet the output of the show mod csm slot real command shows the real server in an up (operational) state.
Workaround: None.
•
When the CSM is in the process of redirecting more than 16,000 concurrently opened connections, the CSM might reload and produce the following core-dump message:
*IXP3 Bad Data exception on task 'IXP3 SA-CORE (Ex 5)(00000000h)*Workaround: Set the number of maximum connections allowed (max-conns limit) on the configured redirect vserver objects or on the virtual server object.
•
When you use XML to make configuration modifications to the CSM and configure multiple VLANs and gateways to reach a host, the CSM might not be able to determine which VLAN the host is using to make the XML request.
Workaround: Configure a specific route for the hosts that allows you to perform XML configuration.
•
In systems with a Supervisor Engine 720, if you configure the same IP address for the default gateway and for a specific route (for example, if you enter the gateway ip_addr_x command and also the route ip_addr gateway ip_addr_x command), and then you remove the default gateway, the CSM incorrectly points the servers to another gateway instead of the gateway in the route configuration.
Workaround: Remove the route configuration, and then remove the default gateway configuration. You can then reconfigure the route.
•
If you configure two virtual servers with the same IP address and one of the virtual servers is not in service, a GSLB probe pointing to the local virtual server is not operable until you remove the downed (not in service) virtual server from the configuration.
Workaround: Remove the virtual servers that are out-of-service.
•
When you configure the least-connections (leastconns) prediction algorithm and you define a large number of real servers (20 or more) to a serverfarm, the CSM might experience degraded performance, which could result in dropped connections.
Workaround: Use the round-robin prediction algorithm.
•
In CSM software release 4.1(3), the CSM can support service FTP translation for virtual server ports or real server ports other than port 21. If you have configured the FTP port that is not in the reserved port range, which is 1 through 1023, then an FTP data flow with a particular source port can be mistaken for an RTSP data flow if the FTP data flow was configured on the same CSM.
Workaround: None.
•
When connection redundancy is configured, the connection counters on the standby CSM might incorrectly show that all of the replicated connections were assigned only to one server within a serverfarm. This problem is with the counter only; the connection flows will replicate correctly if a switchover occurs. However, if you enter the maxconns max-conns command to limit the number of active connections to the real server, this problem would not correctly count against these limits on the standby CSM.
Workaround: None.
Open Caveats in Software Release 3.1(9)
Note
This section describes known limitations that exist in CSM software release 3.1(9).
•
The CSM reserves 141 KB of memory on the PowerPC control processor for each TCL scripted health probe item configured on the CSM. A probe item is an instance of a probe object associated with a single real server.
This memory usage is much higher than anticipated. The PowerPC "Available Memory" counter from the show module csm slot tech-support utilization command should not be less than 40 MB.
Workaround: None.
•
When you configure a CSM in a fault-tolerant configuration and you have a fault-tolerant priority of 254, the CSM may take over the active role from the other CSM at startup. This situation could occur even when the fault-tolerant preempt option is disabled.
Workaround: Use fault-tolerant priority values lower than 254.
•
The CSM does not support pipelines (multiple HTTP requests sharing the packet boundary) with the persistent rebalance feature.
Workaround: None.
•
The CSM might not replicate the sticky entries for sticky group zero when it is configured under the virtual server. Because of the configuration download order, the active and redundant CSM may be assigned different group numbers when a group was not specified in the configuration.
Workaround: Configure a sticky group with a specific number, and assign it to the virtual server.
•
When using Cisco IOS Release 12.1(19)E or later with CSM 3.1(x) software, the sticky timeout is displayed as zero for all sticky entries, and the total entries count (CurrCount) for each sticky is also displayed as zero. These counters are supported only in CSM software release 3.2(1).
Workaround: Use the corresponding Cisco IOS software Release 12.1(13)E, which displays the configured timeout instead of the current timeout.
•
The set port cdp, set port trap, set spantree portpri, and set spantree link-type restricted CSM port commands return the "failure" message instead of the "feature not supported" message.
Workaround: None.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module and the multilayer switch feature card (MSFC) use different MAC addresses. This problem remains in software releases earlier than the Catalyst operating system software release 7.5.1. If any Supervisor Engine 2 in the switch is still operating with a software release earlier than the Catalyst operating system software release 7.5.1, and the traffic is forwarded by that switch, the CSM drops the packet.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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" to a value that is greater than one for all TCL script probes.
•
Established FTP connections are not replicated to the redundant CSM when the redundant CSM becomes operational. To enable an FTP connection for replication from an active CSM to a redundant CSM, the redundant CSM must be operational at the time the FTP connection is opened. If the FTP connection is opened prior to the redundant CSM booting and becoming operational, the FTP connection never replicates to the backup.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
When multiple CSM users perform a do copy xx running-config from a CSM submode in Cisco IOS software, 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 entered, 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 reenter the desired CSM configuration submode.
•
Beginning with Cisco IOS software 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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None.
•
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.
•
Entering the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(9)
Note
This section describes the caveats resolved in CSM software release 3.1(9).
•
When you configure the CSM to perform Global Server Load-Balancing (GSLB) for a destination IP that is also a local Virtual IP (VIP) on the module, the CSM does not properly take this local VIP out-of-service. The CSM keeps responding to the DNS request with a VIP address that is out-of-service. The CSM also reports to KAL-AP (keep-alive probe) with the incorrect load value for this local VIP.
Workaround: None.
•
When you perform an SNMP MIB request for the packet counter ifHCOutUcastPkts, the CSM Gigabit interfaces may display incorrect 64-bit values.
Workaround: None.
•
When the CSM load-balances more than one HTTP request of a persistent connection to the same server with destination port translation, the CSM will send incorrect RST (reset) packets to this server when the CSM rebalances the connection to another server. The incorrect RST packet contains the virtual server port instead of the port configured for the real server.
Workaround: None.
•
The CSM sends an invalid RST packet when it rebalances an HTTP persistent connection from a serverfarm with the predictor forward parameter applied to another serverfarm with real servers. This action creates two problems:
a.
b.
This caveat exists in CSM releases 3.1(5), 3.1(6), 3.1(7), 3.1(8), 3.2(2) and 4.1(1).
Workaround: None.
•
The CSM listens on these UDP ports: 5002 used for the CAP protocol and port 53 used for GSLB. The CSM silently discards the packets to port 53 and port 5002 with GSLB features disabled.
Workaround: None.
•
With Global Server Load Balancing (GSLB) configured for HTTP probes, the show module csm x gslb probe command output does not show the HTTP counters incrementing.
Workaround: None.
Open Caveats in Software Release 3.1(8)
Note
This section describes known limitations that exist in CSM software release 3.1(8).
•
The CSM reserves 141 KB of memory on the PowerPC control processor for each TCL scripted health probe item configured on the CSM. A probe item is an instance of a probe object associated with a single real server.
This memory usage is much higher than anticipated. The PowerPC "Available Memory" counter from the show module csm slot tech-support utilization command should not be less than 40 MB.
Workaround: None.
•
When you configure a CSM in a fault-tolerant configuration and you have a fault-tolerant priority of 254, the CSM may take over the active role from the other CSM at startup. This situation could occur even when the fault-tolerant preempt option is disabled.
Workaround: Use fault-tolerant priority values lower than 254.
•
The CSM does not support pipelines (multiple HTTP requests sharing the packet boundary) with the persistent rebalance feature.
Workaround: None.
•
The CSM might not replicate the sticky entries for sticky group zero when it is configured under the virtual server. Because of the configuration download order, the active and standby CSM may be assigned different group numbers when a group was not specified in the configuration.
Workaround: Configure a sticky group with a specific number, and assign it to the virtual server.
•
When using Cisco IOS Release 12.1(19)E or later with CSM 3.1(x) software, the sticky timeout is displayed as zero for all sticky entries, and the total entries count (CurrCount) for each sticky is also displayed as zero. These counters are supported only in the CSM software release 3.2(1).
Workaround: Use the corresponding Cisco IOS Release 12.1(13)E, which displays the configured timeout instead of the current timeout.
•
The set port cdp, set port trap, set spantree portpri, and set spantree link-type restricted CSM port commands return the "failure" message instead of the "feature not supported" message.
Workaround: None.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module and the multilayer switch feature card (MSFC) use different MAC addresses. This problem remains in software releases earlier than the Catalyst 7.5.1 software release. If any Supervisor Engine 2 in the switch is still operating with a software release earlier than the Catalyst 7.5.1 software release, and the traffic is forwarded by that switch, the CSM drops the packet.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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" to a value that is greater than one 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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
When multiple CSM users perform a do copy xx running-config from a CSM submode in Cisco IOS software, 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 entered, 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 reenter 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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None.
•
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.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(8)
Note
This section describes the caveats resolved in CSM software release 3.1(8).
•
CLI commands sent to the CSM may fail when the servers in a server farm reaches the configured maximum connections (max-conns) value. When the maximum connection value has been met, the servers would not be selected, generating system messages to notify users of the change in the server state. In software release 3.1(8), the configurable global variable INBAND_STATE_CHANGED_MSG_RATE is introduced to control the rate at which these messages are generated and written into the system message log. You must configure a value of zero to suppress the messages from being sent.
Workaround: Remove the max-conns configuration from the server. The max-conns value can be configured at the virtual server level.
•
The server configured with "inservice standby" becomes active after it fails and recovers from a health probe check. The server should not start accepting load-balancing traffic after it recovers from health probe failure and should go back to standby mode where it accepts only those connections with the sticky or backup role.
Workaround: None
•
When a TCP request with a multicast destination MAC address reaches the CSM, the CSM sends a reset (RST) back to this host. This is a problem even when the TCP request contains the unicast destination IP address that is not owned by the CSM.
Workaround: None.
•
The CSM may respond with an acknowledgement (ACK) message instead of synchronization-acknowledgement (SYN-ACK) message for the repeated synchronization (SYN) packet from the client to a Layer 7 virtual server.
Workaround: None
•
The CSM may fail to respond if it has to replicate over 256,000 unique sticky entries and replicate over 30,000 new connections per second.
Workaround: Configure the appropriate subnet mask for IP sticky to reduce the number of sticky entries in the CSM database.
•
The clear module csm slot sticky command does not clear the sticky entries on the standby CSM.
Workaround: Enter the clear module csm slot sticky command on the standby CSM.
•
If the first reply packet from the server is an "HTTP 100 Continue" type reply, then the CSM does not learn the HTTP "Set-Cookie" information from the subsequent "HTTP 200 OK" reply from the server. In this case, the cookie sticky option will not work for the subsequent "HTTP 100 Continue" packet.
Workaround: Reconfigure the server so that it sends the Cookie information in the "HTTP 100 Continue" packet as well.
•
The CSM incorrectly replicates the FTP connections to the standby CSM if connection replication is enabled for the FTP server. If the FTP traffic reaches the standby CSM due to bridge flooding, the standby CSM also forwards this traffic. This situation causes the Catalyst switch to recognize that the source MAC address belongs to the standby CSM instead of the active CSM. This situation might cause all other traffic to be incorrectly forwarded to the standby CSM, where the packets will be dropped.
Workaround: Turn off connection replication for the FTP virtual server.
•
When you configure the CSM for persistent rebalancing of each HTTP request for the same TCP data stream, the CSM is unable to process requests that contain extra carriage return-line feed (CR-LF) characters that are beyond the "Content Length" specified in the HTTP header.
Workaround: Change the server to "send HTTP version 1.1" to stop the client from sending these extra characters.
Open Caveats in Software Release 3.1(7)
Note
This section describes known limitations that exist in CSM software release 3.1(7).
•
When configuring a CSM in a fault-tolerant configuration, and you have a fault-tolerant priority of 254, the CSM may take over the active role from the other CSM when it boots up. This situation could occur even when the fault-tolerant preempt option is disabled.
Workaround: Use fault-tolerant priority values lower than 254.
•
The CSM incorrectly replicates the FTP connections to the standby CSM if connection replication is enabled for the FTP server. If the FTP traffic is reaching the standby CSM because of bridge flooding, the standby CSM also forwards this traffic. This situation causes the Catalyst switch to recognize that the source MAC address belongs to the standby CSM instead of the active CSM. This situation might cause all other traffic to be incorrectly forwarded to the standby CSM, where the packets will be dropped.
Workaround: Turn off connection replication for the FTP virtual server.
•
The CSM does not support pipelines (multiple HTTP requests sharing the packet boundary) with the persistent rebalance feature.
•
The CSM might not replicate the sticky entries for sticky group zero when it is configured under the virtual server. Because of the configuration download order, the active and standby CSM may be assigned a different group number when the group was not specified in the configuration.
Workaround: Configure a sticky group with a specific number, and assign it to the virtual server.
•
When using Cisco IOS Release 12.1(19)E or later with CSM 3.1(x) software, the current sticky timeout is displayed as zero for all sticky entries, and the total entries count (CurrCount) for each sticky is also displayed as zero. These counters are supported only in the CSM software release 3.2(1).
Workaround: Use the corresponding Cisco IOS Release 12.1(13)E, which displays the configured timeout instead of the current timeout.
•
The set port cdp, set port trap, set spantree portpri, and set spantree link-type restricted CSM port commands return the "failure" message instead of the "feature not supported" message.
Workaround: None.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module 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 Catalyst 7.5.1 software release, and the traffic is forwarded by that switch, the CSM drops the packet.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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 one 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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
When multiple CSM users perform a do copy xx running-config from a CSM submode in Cisco IOS software, 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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None
•
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.
Workaround: None.
•
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:
–
For example, the following configuration is invalid because it is possible for traffic from a remote source to arrive on both VLAN 10 and VLAN 20:
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(7)
Note
This section describes the caveats resolved in CSM software release 3.1(7).
•
When the configurations between the active and standby CSMs are out-of-synchronization, and the switch performs an RPR+ switchover to its peer, the standby CSM becomes active. Both CSMs remain in this active-active state and cause load-balancing problems and bridging problems in the network.
Workaround: Ensure that the configurations are the same on both the active CSM and the standby CSM.
Open Caveats in Software Release 3.1(6)
Note
This section describes known limitations that exist in CSM software release 3.1(6).
•
When configuring a CSM in a fault tolerant (FT) configuration, and you have an fault-tolerant priority of 254, the CSM may take over the active role from the other CSM when it boots up. This situation could occur even when the fault-tolerant preempt option is disabled.
Workaround: Use fault-tolerant priority values lower than 254.
•
The CSM incorrectly replicates the FTP connections to the standby CSM if connection replication is enabled for the FTP server. If the FTP traffic is reaching the standby CSM because of bridge flooding, the standby CSM also forwards this traffic. This situation causes the Catalyst switch to recognize that the source MAC address belongs to the standby CSM instead of the active CSM. This situation might cause all other traffic to be incorrectly forwarded to the standby CSM where the packets will be dropped.
Workaround: Turn off connection replication for the FTP virtual server.
•
The CSM might not replicate the sticky entries for sticky group zero configured under the virtual server. Because of the configuration download order, the active and standby CSM may be assigned a different group number when the group was not specified in the configuration.
Workaround: Configure a sticky group with a specific number, and assign it to the virtual server.
•
When using Cisco IOS Release 12.1(19)E or later with CSM 3.1(x) software, the current sticky timeout is displayed as zero for all sticky entries, and the total entries count (CurrCount) for each sticky is also displayed as zero. These counters are supported only in the CSM software release 3.2(1).
Workaround: Use the corresponding Cisco IOS Release 12.1(13)E, which displays the configured timeout instead of the current timeout.
•
The set port cdp, set port trap, set spantree portpri, and set spantree link-type restricted CSM port commands return the "failure" message instead of the "feature not supported" message.
Workaround: None.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module 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 Catalyst 7.5.1 software release, and the traffic is forwarded by that switch, the CSM drops the packet.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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 one 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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None
•
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.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(6)
Note
This section describes the caveats resolved in CSM software release 3.1(6).
•
When setting the environment variable HTTP_CASE_SENSITIVE_MATCHING to zero, the CSM converts all configured URL, header, and cookie maps to lowercase when matching them with the incoming requests. The CSM does not convert the cookie sticky name in this case. If you configure the cookie sticky with an uppercase name, it will not match any incoming request, and the cookie sticky will not work.
Workaround: When setting HTTP_CASE_SENSITIVE_MATCHING to zero, you must configure the HTTP cookie sticky name in lowercase letters.
•
In Cisco IOS software Release 12.2(17a)SX or later, the downloading order for the fault-tolerant (FT) configurations to the CSM moved to the beginning of the download. In this setup, the prior CSM software releases were not able to calculate configuration parity between the active and standby CSMs. The result was that the fault-tolerant status of the "configuration is out-of-sync" message is unreliable. Disregard this status, and perform a manual comparison of the configurations on the active and standby CSMs.
Workaround: Use the older releases of Cisco IOS software or update to CSM software release 3.1(6) or later.
•
If you use the XML interface to configure the CSM, the CSM may reboot if the client XML made a modification request to an unknown server farm name.
Workaround: Ensure that the client XML can make a configuration change to a configured server farm only.
•
When the active CSM makes a switchover following the route processor (RP) failover, the route health injection (RHI) static routes in the chassis are not removed until 50 seconds later. This delay prevents the newly active CSM, located in another chassis, from receiving incoming requests. CSM software release 3.1(5) includes the tracking of redundant RP switchover with a configurable variable SWITCHOVER_RP_ACTION.
Workaround: None.
•
A bad IP checksum packet could bypass the Catalyst switch check and enter the CSM. A bad IP packet could put the CSM into a non-functional state, causing it to drop all load-balancing traffic. Health probe and bridging traffic would continue to function properly in this case. CSM software release 3.1(4) includes a fix for this problem. However, this fix resolved only some of the load-balancing requests. The fix in CSM software release 3.1(6) should resolve all load-balancing traffic.
Workaround: None.
Open Caveats in Software Release 3.1(5)
Note
This section describes known limitations that exist in CSM software release 3.1(5).
•
When using Cisco IOS Release 12.1(19)E or later with CSM software release, 3.1(x) the current sticky timeout is displayed as zero for all sticky entries, and the total entries count (CurrCount) for each sticky is also displayed as zero. These counters are supported only in the CSM software release, 3.2(1).
Workaround: Use the corresponding Cisco IOS Release 12.1(13)E, which displays the configured timeout instead of the current timeout.
•
The set port cdp, set port trap, set spantree portpri, and set spantree link-type restricted CSM port commands return the "failure" message instead of the "feature not supported" message.
Workaround: None.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module 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.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
When Internet Group Management Protocol (IGMP) snooping is enabled on the Catalyst 6500 series switch, some CSM connection replication frames might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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 one 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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None
•
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.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(5)
Note
This section describes the caveats resolved in CSM software release 3.1(5).
•
When forwarding traffic to a destination, the CSM does not preserve the ToS field in the packets. The CSM must respect the TRUST_DSCP configuration on the Catalyst 6500 switch.
Workaround: Configure the specific differentiated service code point (DSCP) value on each virtual server.
•
When you configure the CSM as the final destination for another Global Server Load Balancing (GSLB) device, the GSLB device can use keepalive application process (KAL-AP) probe to check for the health of a virtual IP address (VIP) in the CSM. This probe is destined to the CSM through the alias IP address. However, the CSM incorrectly responds to the probe using the VLAN IP address, causing the GSLB to ignore the reply from CSM.
Workaround: None.
•
When a VLAN interface is removed from the CSM, some of the host entries within the subnet are still in the ARP table of the CSM. The CSM must clean up its ARP table when you remove an IP subnet.
Workaround: None.
•
An FTP connection cannot be established if the virtual IP address overlaps with a configured client NAT pool IP address. Even if the FTP virtual server is not using this client NAT, the FTP command cannot pass through the CSM.
Workaround: Remove any NAT pool containing the IP address that is overlapping with the virtual IP address of an FTP service.
•
The CSM fails when it is presented with a fragmented UDP packet with no UDP ports, and the IP addresses and IP identification hash to a specific value.
Workaround: None.
•
When the CSM rebalances the subsequent request of an HTTP persistent connection, it sends the default maximum session server (MSS) value of 1460 to the new server; however, the CSM should send the MSS value sent by the client in the original SYN packet.
Workaround: None.
•
The predictor round-robin feature does recognize all of the different weight values configured for the real server. In CSM software release 3.1(4), the CSM used only the simple round-robin method, with all the real server weights being equal. This feature was broken in CSM software release 3.1(4) only.
Workaround: None.
•
When you enter configuration mode to remove a server farm from service, the event is logged in the system log (syslog). When you place a server farm in service using the inservice command, this event is not logged into the syslog, causing service monitoring alarms to occur and never become reset.
Workaround: None.
•
The tftp core_dump ip-addr command is added to the CSM prompt when you session into the module. This command allows you to copy the full core-dump file to an external TFTP server.
Workaround: To access this command you must enter into CSM debug prompt using the debug module csm command.
•
The standby CSM sometimes sees the ARP responses for a gateway on the opposite VLAN in the bridged mode. This situation causes the standby CSM to repeatedly report that the MAC address of a gateway is changing.
This problem occurs only if the bridge device was stripping the padding bytes from the ARP response when it flooded the packet from the active CSM port to the standby CSM port. When the bridge device correctly learned the destination MAC address, the ARP response was not flooded.
Workaround: None.
•
If you configure the HTTP redirect string with more than 22 characters, the HTTP redirect traffic might cause the CSM to fail.
Workaround: Use a redirect string smaller than 22 characters.
•
When the CSM receives a finished (FIN) packet from either a client or a server, the CSM places the flow in a quick idle timer of 8 seconds. This action can cause a problem if an external device intended to leave this connection in the half termination state because of its association with another connection. The CSM should provide only a quick idle timer when it receives the FIN packet from both directions. The CSM should provide only a quick idle timer when one FIN packet is received for the configured unidirectional virtual servers.
Workaround: None.
•
The CSM incorrectly terminates an FTP connection if the data transfer command for this connection takes longer than 15 minutes.
Workaround: None.
•
The CSM could fail to respond if you remove a real server from a server farm when a scripted probe is configured and running.
Workaround: Configure a real server as out-of-service instead of removing it, or remove the scripted probe for that server farm before removing the real server.
•
The CSM does not forward the ICMP unreachable messages from the router to the intended server when the Maximum Transmission Unit (MTU) is exceeded. This problem exists in CSM software release 3.1(3) and software release 3.1(4) only.
Workaround: None.
•
The CSM generates few random source MAC addresses into VLAN 1 when there is a high volume of traffic forwarded across the configured bridge VLANs. Over time, this situation could cause an overflow of the MAC address table in the Catalyst switch chassis.
Workaround: Configure a faster timeout for bridge entries, or configure the virtual server to load-balance this traffic.
•
In previous releases, the CSM was unable to forward jumbo frames. In CSM software release 3.1(5), a jumbo frame up to 9,216 bytes can be forwarded by the CSM to the peer bridge VLAN. A jumbo frame can also be forwarded to it destination if it matched an existing Layer 4 connection. In a switch running both Cisco IOS software and the Catalyst operating system, you must enable jumbo frame for the CSM internal ports.
Workaround: None.
•
The CSM incorrectly stamped the differentiated-services-code-point (DSCP) bits in the least significant bits of the TCP type of service (ToS) byte. The DSCP configuration value of 0 to 63 should be placed in the highest bits.
Workaround: None.
•
In previous releases, the CSM counted all traffic received from a route VLAN that did not match any configured virtual server. This traffic was counted as "server-initiated" connections. In CSM software release 3.1(5), the CSM counts only those connections coming from the configured real servers as server-initiated connections. Other connections are rejected and are counted as "no policy configured" connections.
Workaround: None.
•
When you remove the route for a routed keepalive application process (KAL-AP) probe on a DNS-VIP, the probe always considers the DNS-VIP to be out of service. The probe stays in the failed state even if this route is returned to service.
Workaround: Take the DNS-VIP (the real server of a DNS-VIP server farm) out of the server farm, and then replace it to the server farm.
•
The CSM sends out health checks for the server that was configured to out of service when you configure a keepalive probe into a server farm. This situation causes unnecessary traffic on the network and the CSM.
Workaround: Remove the real server from the server farm.
Open Caveats in Software Release 3.1(4)
Note
This section describes known limitations that exist in CSM software release 3.1(4).
•
The following 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.
Workaround: None.
•
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.
Workaround: In release 3.1(2) or later, you can set the CSM variable "ARP_LEARN_MODE" to zero (0) to prevent the CSM from learning the ARP that is not destined for the CSM.
•
Token Ring and FDDI VLANs should not be configured on CSM trunk ports.
Workaround: None.
•
The CSM drops packets because the multilayer switch (MLS) module 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.
Workaround: None.
•
During a CSM reset, the show module command displays that the module is faulty when it should be displayed as "Other."
Workaround: None.
•
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 might be dropped.
Workaround: Disable IGMP snooping on both the active and standby CSM modules. 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 one 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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
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 user is configuring probe "FOO," the configuration will be corrupted.
Workaround: Ensure that multiple users do not simultaneously modify the CSM configuration with different object types.
•
Some FTP connections may not replicate. For example, an FTP connection through an active CSM is not replicated if no data channel has been set up 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.
Workaround: None.
•
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.
Workaround: None
•
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.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(4)
Note
This section describes the caveats resolved in CSM software release 3.1(4).
•
The CSM may crash if it received a bad format ICMP "destination unreachable" type 3/4 message (fragmentation required with the do not fragment bit set) from the router.
Workaround: None.
•
The CSM was incorrectly timing out the FTP connection after 15 minutes without a new FTP command. This behavior is a problem for a file transfer command that lasted more than 15 minutes.
Workaround: None.
•
If you configured the "port" number for an HTTP probe object, the operational state of the "real" server in the Global Server Load Balanced (GSLB) serverfarm does not change, even if the probe has failed. This problem occurs only with GSLB policy.
Workaround: Do not configure the port number in the HTTP probe for GSLB service.
•
The CSM responds to the ARP request for a virtual IP address (VIP) whether or not the virtual server was configured as "inservice." This behavior is changed in release 3.1(4) and later releases. Previously you had to configure "variable ARP_REPLY_FOR_NO_INSERVICE_VIP 1" to maintain this behavior.
Workaround: None.
•
When processing connections to a layer 7 virtual server, by default the CSM replies with a SYN-ACK and Maximum Segment Size (MSS) value of 1460. You can change this setting by configuring the environment variable "TCP_MSS_OPTION" to another value. When the CSM does not have to parse any HTTP or SSL information, the MSS value is correctly passed between the client and the server.
Workaround: None.
•
The show module csm slot connection command always displays the state of an FTP data connection as "CLOSING." This connection is set up by the CSM. The state of these connections should be "ESTAB."
Workaround: None.
•
The CSM marks the HTTP probe as failed if the server does not send the FIN reply after the CSM completes the HTTP keepalive request. The problem occurred because the CSM set the request to HTTP 1.1 and expected a close request from the server.
Workaround: None.
•
In hybrid systems (running Cisco IOS and the Catalyst operating system software) in a fault tolerant configuration with a CSM in separate switch chassis, reloading the MSFC in one chassis may cause the active CSM to show that the configuration is out of synchronization with the standby CSM on the other chassis.
Workaround: None.
•
The keepalive probes on the standby CSM fail if connections are replicating from the active to the standby module. This problem occurs because the CSM was incorrectly set up with ARP entries for IP addresses in replicated connections that were not directly connected to the CSM VLAN.
Workaround: None.
•
In hybrid systems (running Cisco IOS and the Catalyst operating system software) with redundant CSMs, the standby CSM on the same chassis may incorrectly clear the ARP entries when only the MSFC failed or rebooted. This condition prevents the connections destined for certain servers from replicating correctly to the standby CSM.
Workaround: Reboot the standby CSM if the MSFC in the same chassis was rebooted.
•
In hybrid systems (running Cisco IOS and the Catalyst operating system software) with redundant CSMs, the MSFC could independently fail with the Catalyst operating system continuing to run. When only the MSFC failed or rebooted, the active CSM on the same chassis incorrectly reset (RST) all the existing connections before entering the standby state. The standby CSM lost all of the replicated connections before it become the active CSM.
Workaround: None.
•
When a high volume of RTSP connections pass through the virtual servers with the "service rtsp" option configured, the CSM may fail and reboot.
Workaround: Remove the "service rtsp" option from the virtual server.
•
When a packet with an invalid IP header enters the CSM, the module state may change so that the module no longer forwards load-balanced traffic. When the CSM enters such a state, the keepalive traffic and packets that are forwarded to other VLANs are not affected. Only the traffic destined for load balancing fails. The IP checksum value for this type of packet will not be correct. In most cases, the routers drop and do not forward this type of packet to the CSM.
Workaround: Reboot the CSM module to reset the state.
•
The clear module csm slot counters command does not clear the counters for the fault tolerance (FT) statistics.
Workaround: None.
•
The clear module csm slot conns vserver name does not work for a virtual server configured as out-of-service.
Workaround: Configure the virtual server to "inservice" before using the clear command.
•
By default, the operational state of the backup serverfarm is not used by the virtual server associated with the primary and backup serverfarms. If all the servers in the primary serverfarm are disabled, then the virtual server is recognized as out-of-service.
You can change this behavior by setting the environment variable "AGGREGATE_BACKUP_SF_STATE_TO_VS" which causes the operational state of a virtual server to depend on both the primary and backup serverfarms.
Workaround: None.
•
Statistics on the standby CSM show the connections counter per real server as zero because the CSM does not count any connection replicated from the active CSM to the real server.
Workaround: None.
•
Software release 3.1(4) supports the "failaction reassign" option for firewall load balancing (FWLB). The CSM reassigns existing connections from a failed firewall to another operating firewall. To be reassigned, the firewalls must have the connection state replication feature. The configuration for this option requires the Cisco IOS Release 12.1(19)E or higher.
Workaround: None.
•
When the fault tolerance (FT) heartbeat traffic between the active and standby CSMs stops, the CSM pair goes into an active-active condition. When the fault-tolerant traffic is restored, the CSM pair cannot determine which CSM was previously active before the interruption.
The standby module configured previously with a higher fault-tolerant priority takes over as the active CSM which is undesirable. CSM software release 3.1(4) allows the previously active CSM to become active again, regardless of the priority setting.
Workaround: Set the current active CSM to a higher priority setting.
Open Caveats in Software Release 3.1(3)
Note
This section describes known limitations that exist in CSM software release 3.1(3).
•
When a packet with an invalid IP header enters the CSM, the module state may change so that the module no longer forwards load-balanced traffic. When the CSM enters such a state, the keep-alive traffic and packets that are forwarded to other VLANs are not affected. Only the traffic destined for load balancing stops working. The IP checksum value for this type of packet will not be correct. In most cases, the routers drop and do not forward this type of packet to the CSM.
Workaround: Reboot the CSM module to reset the state.
•
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.
Workaround: None.
•
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.
Workaround: In release 3.1(2) or later, you can set the CSM variable "ARP_LEARN_MODE" to zero (0) to prevent the CSM from learning the ARP that is not destined for the CSM.
•
Token Ring and FDDI VLANs should not be allowed on CSM trunk ports.
Workaround: None.
•
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.
Workaround: None.
•
During a CSM reset, the show module command displays the module as faulty when it should be displayed as "Other."
Workaround: None.
•
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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
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.
•
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.
Workaround: None.
•
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.
Workaround: None
•
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.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(3)
Note
This section describes the caveats resolved in CSM software release 3.1(3).
•
The CSM mishandles an HTTP response from the server, which causes the module to fail and reboot. The following conditions cause this problem to occur:
a.
b.
Workaround: None.
•
The CSM does not set up the real time streaming protocol (RTSP) data channels correctly when the client and server negotiated to have more than one channel open. In this case, the CSM incorrectly swapped the client and server ports. As a result, all RTSP data traffic is either dropped by the CSM or forwarded without the proper NAT information.
Workaround: Set the RTSP protocol in the server to allow only one data channel port per RTSP connection.
•
When the traffic from the FTP control channel (port 21) exceeds the limit of 500 packets per second, the CSM may leave additional connections open indefinitely. In this case, the session resources should be recovered. There is a total of one million possible sessions allowed per CSM module.
Workaround: Reboot the CSM when the number of opened connections is close to one million.
•
When processing the FTP service, the CSM may fail. This problem occurs when the client or server used a corrupt packet ID in the IP header within the control traffic of an FTP session.
Workaround: None.
•
When configured with bridging VLANs and fault tolerance, the CSM might not send gratuitous ARP requests for the real servers after the standby CSM becomes active. As a result, the connection requests from the client to the real server IP and MAC address do not go through immediately. The traffic resumes when the bridge table times out on the client or the ARP table times out on the client or the server side of the transaction.
Workaround: None.
•
The CSM might not send out the reset (RST) packets when it closes connections when a server goes down. The CSM clears the connections when a "failaction purge" option is configured into the serverfarm.
Workaround: Close and reopen the browser to establish a new connection.
•
The CSM checks the operational status of a virtual IP (VIP) address before it responds to an ICMP request to the VIP. When there are multiple virtual servers with the same VIP address, the CSM does not check the status of all of the virtual servers. If one of the virtual servers is not functioning, the CSM will incorrectly ignore the ICMP request.
Workaround: Set the global variable in the CSM release 3.1(1a) or later to always respond to the ICMP request.
•
The CSM might begin inserting and removing route health injection (RHI) routes multiple times for the same VIP when the virtual server first becomes operational, affecting operation on the distance routers for approximately two minutes.
Workaround: Use software releases with a stable RHI feature: Cisco IOS Release 12.1(13)E and CSM software release 3.1(3).
•
The CLI for the CSM in Cisco IOS Release 12.1(13)E does not allow you to configure the max-parse-len section of an HTTP request longer than 4000 bytes. In CSM software release 3.1(3), the CSM supports a global variable "MAX_PARSE_LEN_MULTIPLER," which increases the configured max-parse-len value by the value of this variable.
Workaround: None.
•
In CSM software release 2.2(x), there were resource leaks when the number of opened FTP connections went above 47,000. This high connection rate caused the CSM to run out of resources to process further FTP traffic. Rebooting the CSM was required to reclaim the resources.
Workaround: None.
•
The CSM incorrectly processes the IP sticky configuration option when only the Return Code map is configured for that virtual server. This problem does not occur if other matching rules (ACL, URL, Cookie, etc.) are configured for that virtual server.
Workaround: Configure the client access list with the value of catch all "client 0.0.0.0/0" for the virtual server.
•
The CSM drops part of an HTTP POST request when the request spans multiple packets. The CSM drops the subsequent packet when it receives the synchronize-acknowledge (SYN-ACK) packet from the server at that same time.
Workaround: None.
•
The CSM processes any TCP connection requests on its interfaces, even those with a destination MAC that are not for the CSM. If the switch floods the synchronize (SYN) packet to all bridged ports, this flooding causes the CSM to incorrectly reset or load balance the connections that were not destined for it.
Workaround: The bridge device should only send the packets to the port where the corresponding destination MAC address exists.
•
While parsing the HTTP response from the server, the CSM may crash if the response packet from the server is padded with additional bytes at the MAC layer. The problem only occurs when the CSM has to parse the server response for Cookie Sticky or Return Code requests.
Workaround: None.
•
When you configure a virtual server with a wildcard 0.0.0.0 address and you use the clear module csm slot conn vserver vs-name command, the command clears all open connections in the CSM.
Workaround: Enter the clear command with a specific real server IP address.
•
The CSM might leave the FTP connections in the closed state because the module did not receive the finished (FIN) packet for the FTP connections. The clear module csm slot conn command might be unable to clear these connections.
Workaround: These FTP connections will be closed by the idle timer in the CSM.
•
Under certain conditions, the CSM is unable to process and count the HTTP Return Code from the server as configured. When the server (or client) sends a finished (FIN) packet immediately after the server sends the HTTP response, the CSM does not process the Return Code for this connection.
Workaround: The timing is much longer in a production network because of heavier traffic, so the above condition is unlikely to occur.
•
In CSM releases 3.1(1a) and 3.1(2), the CSM sometimes will not reboot the system when the CSM fails due to a server error.
Workaround: Manually reset the CSM module.
•
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. This caveat applies only to Cisco IOS releases previous to 12.1(13)E3.
Open Caveats in Software Release 3.1(2)
Note
This section describes known limitations that exist in CSM software release 3.1(2).
•
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.
Workaround: None.
•
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.
Workaround: None.
•
Token Ring and FDDI VLANs should not be allowed on CSM trunk ports.
Workaround: None.
•
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.
Workaround: None.
•
During a CSM reset, the show module command displays the module as faulty when it should be displayed as "Other."
Workaround: None.
•
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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
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.
Workaround: None.
•
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.
Workaround: None
•
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.
Workaround: None.
•
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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For 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.
Resolved Caveats in Software Release 3.1(2)
Note
•
When enabling "persistent rebalancing" for a particular virtual server, the CSM examines every GET of the HTTP 1.1 persistent connection so that it can redirect the request to the correct serverfarm. If the subsequent GET request spans multiple packets and is intended for the same server as the previous GET request, then the CSM is not able to forward the reply back to the client.
Workaround: Remove the "persistent rebalancing" option from the virtual server.
•
The "slot0:" option in the upgrade command for the CSM is referencing the MSFC on the active supervisor slot. In CSM release 3.1(2), this option is referencing the active MSFC.
Workaround: Use the MSFC on the same module as the active supervisor. Use the option "127.0.0.12" (for MSFC on slot 1) or "127.0.0.22" (for MSFC on slot 2) instead of using the "slot0:" option.
•
CSM release 3.1(1a) has the problem handling IP fragmented packets. While processing many out-of-order UDP fragments, the CSM can lock up and stop processing all traffic.
Workaround: None.
•
The CSM does not support the non-standard extension in the RTSP message. When the user enables the "service rtsp" for a virtual server, the CSM has to process the RTSP message to set up the peer flows. Any RTSP message with a non-standard extension option sent through this VIP causes the CSM to fail.
Workaround: Remove the option "service rtsp" for the virtual server.
•
In CSM release 3.1(2), the CSM optimizes the use of client NAT pools with multiple IP addresses. The CSM uses the client source port number in determining the corresponding client NAT IP address. This enhancement minimizes the TCP "timewait" port reused condition, causing the server to reject the connection.
Workaround: None.
•
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 the CSM.
Workaround: None.
•
In CSM release 3.1(2), the CSM supports non-standard HTTP requests from the Wireless Application Protocol (WAP) devices.
Workaround: None.
•
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.
•
When one of the firewalls fails the ARP request, the ICMP health probe to other servers or firewalls may drop the ICMP reply. If the number of probe "retries" is small, 60 or less, 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 CSM 2.2(7) release, the maximum ICMP health probe rate is at 600 probes per second.
Workaround: None.
•
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.
Workaround: None.
•
The CSM drops the HSRP advertising traffic when the CSM should have been repeating them through the peer bridging VLAN.
Workaround: None
•
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.
•
The CSM drops the ICMP error message "Destination Unreachable with Type=3 and Code=3."
Workaround: None
•
Using the CSM 3.1(2) release with Cisco IOS Release 12.1(13)E3 causes the CSM to generate SNMP traps when you remove a virtual server from service.
Workaround: None.
•
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.
Workaround: None.
Open Caveats in Software Release 3.1(1a)
Note
This section describes known limitations that exist in CSM software release 3.1(1a).
•
FTP virtual server IP addresses cannot be client NAT IP addresses as well. If there is overlap between the IP address range for a virtual server on which `service ftp' is configured and there is a configured client NAT IP address range, connections through that virtual server will not be handled properly.
Workaround: Configure the FTP virtual server IP address and client NAT addresses such that there is no overlap.
•
When 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 CSMs.
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 to be replicated 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.
Workaround: None.
•
For optimal performance of CSM TCL script probes and TCL standalone scripts, we recommend the following:
a.
b.
c.
•
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 only occurs 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. This caveat applies only to Cisco IOS releases previous to 12.1(13)E3.
•
Some FTP connections may not be replicated. An FTP connection through an active CSM will not be replicated if no data channel has ever 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.
Workaround: None.
•
CSM software release 3.1(1a) 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 to interleaved mode (inline TCP). This mode will work in the application software, although the connection is sent to fastpath.
Workaround: None
•
Issuing the clear interface gigabit slot/port command for a CSM gigabit port may not clear the counters.
Workaround: None.
•
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.
•
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 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:
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# gateway 1.1.1.1Router(config-module-csm)# vlan 20 clientRouter(config-slb-vlan-client)# gateway 2.2.2.2To make this configuration valid, delete the gateway command from either VLAN 10 or VLAN 20.
Note
–
Router(config)# module csm 4Router(config-module-csm)# vlan 10 clientRouter(config-slb-vlan-client)# route 10.0.0.0 255.255.255.0 gateway 1.1.1.1For load balancing to function properly, all traffic arriving from the 10.0.0.0/24 subnet must reach the CSM through VLAN 10.
Resolved Caveats in Software Release 3.1(1a)
Note
Because CSM software release 3.1(1a) is the first release in a new release train. There are no resolved caveats in this release.
Troubleshooting
CSM error messages may be received and reported in the system log (syslog). This section describes these messages.
Message Banners
When syslog messages are received, they are preceded by one of the following banners:
Where # is the slot number of the CSM module.
Error Message CSM_SLB-4-INVALIDID Module # invalid ID
00:00:00: CSM_SLB-4-DUPLICATEID Module # duplicate ID
00:00:00: CSM_SLB-3-OUTOFMEM Module # memory error
00:00:00: CSM_SLB-4-REGEXMEM Module # regular expression memory error
00:00:00: CSM_SLB-4-ERRPARSING Module # configuration warning
00:00:00: CSM_SLB-4-PROBECONFIG Module # probe configuration error
00:00:00: CSM_SLB-4-ARPCONFIG Module # ARP configuration error
00:00:00: CSM_SLB-6-RSERVERSTATE Module # server state changed
00:00:00: CSM_SLB-6-GATEWAYSTATE Module # gateway state changed
00:00:00: CSM_SLB-3-UNEXPECTED Module # unexpected error
00:00:00: CSM_SLB-3-REDUNDANCY Module # FT error
00:00:00: CSM_SLB-4-REDUNDANCY_WARN Module # FT warning
00:00:00: CSM_SLB-6-REDUNDANCY_INFO Module %d FT info
00:00:00: CSM_SLB-3-ERROR Module # error
00:00:00: CSM_SLB-4-WARNING Module # warning
00:00:00: CSM_SLB-6-INFO Module # info
00:00:00: CSM_SLB-4-TOPOLOGY Module # warning
00:00:00: CSM_SLB-3-RELOAD Module # configuration reload failed
00:00:00: CSM_SLB-3-VERMISMATCH Module # image version mismatch
00:00:00: CSM_SLB-4-VERWILDCARD Received CSM-SLB module version wildcard on slot #
00:00:00: CSM_SLB-3-PORTCHANNEL Portchannel allocation failed for module #
00:00:00: CSM_SLB-3-IDB_ERROR Unknown error occurred while configuring IDBServer and Gateway Health Monitoring
Error Message SLB-LCSC: No ARP response from gateway address A.B.C.D.Explanation The configured gateway A.B.C.D. did not respond to ARP requests.
Error Message SLB-LCSC: No ARP response from real server A.B.C.D.Explanation The configured real server A.B.C.D. did not respond to ARP requests.
Error Message SLB-LCSC: Health probe failed for server A.B.C.D on port P.Explanation The configured real server on port P of A.B.C.D. failed health checks.
Error Message SLB-LCSC: DFP agent <x> disabled server <x>, protocol <x>, port <x>Explanation The configured DFP agent has reported a weight of 0 for the specified real server.
Error Message SLB-LCSC: DFP agent <x> re-enabled server <x>, protocol <x>, port <x>Explanation The configured DFP agent has reported a non-zero weight for the specified real server.
Diagnostic Messages
Error Message SLB-DIAG: WatchDog task not responding.Explanation A critical error occurred within the CSM hardware or software.
Error Message SLB-DIAG: Fatal Diagnostic Error %x, Info %x.Explanation A hardware fault was detected. The hardware is unusable and must be repaired or replaced.
Error Message SLB-DIAG: Diagnostic Warning %x, Info %x.Explanation A non-fatal hardware fault was detected.
Fault Tolerance Messages
Error Message SLB-FT: No response from peer. Transitioning from Standby to Active.Explanation The CSM detected a failure in its fault-tolerant peer and has transitioned to the active state.
Error Message SLB-FT: Heartbeat intervals are not identical between ft pair.
SLB-FT: Standby is not monitoring active now.Explanation Proper configuration of the fault-tolerance feature requires that the heartbeat intervals be identical between CSMs within the same fault-tolerance group, and this is currently not the case. The fault-tolerance feature is disabled until the heartbeat intervals have been configured identically.
Error Message SLB-FT: heartbeat interval is identical againExplanation The heartbeat intervals of different CSMs in the same fault-tolerance group have been reconfigured to be identical. The fault-tolerance feature will be re-enabled.
Error Message SLB-FT: The configurations are not identical between the members of the fault tolerant pair.Explanation In order for the fault-tolerance system to preserve the sticky database, the different CSMs in the fault-tolerance group must be identically configured, and this is not currently the case.
Regular Expression Errors
Error Message SLB-LCSC: There was an error downloading the configuration to hardware
SLB-LCSC: due to insufficient memory. Use the 'show ip slb memory'
SLB-LCSC: command to gather information about memory usage.
SLB-LCSC: Error detected while downloading URL configuration for vserver %s.Explanation The hardware does not have sufficient memory to support the desired set of regular expressions. A different set of regular expressions must be configured for the system to function properly.
Error Message SLB-REGEX: Parse error in regular expression <x>.
SLB-REGEX: Syntactic error in regular expression <x>.Explanation The configured regular expression does not conform to the regular expression syntax as described in the user manual.
Error Message SLB-LCSC: Error detected while downloading COOKIE policy map for vserver <x>.
SLB-LCSC: Error detected while downloading COOKIE <x> for vserver <x>.Explanation An error occurred in configuring the cookie regular expressions for the virtual server. This error is likely due to a syntactic error in the regular expression (see below), or there is insufficient memory to support the desired regular expressions.
XML Errors
When an untolerated XML error occurs, the HTTP response contains a 200 code. The portion of the original XML document with the error is returned with an error element that contains the error type and description.
This example shows an error response to a condition where a virtual server name is missing:
<?xml version="1.0"?><config><csm_module slot="4"><vserver><error code="0x20">Missing attribute name in elementvserver</error></vserver></csm_module></config>The error codes returned also correspond to the bits of the error tolerance attribute of the configuration element. Returned XML error codes are:
XML_ERR_INTERNAL = 0x0001,XML_ERR_COMM_FAILURE = 0x0002,XML_ERR_WELLFORMEDNESS = 0x0004,XML_ERR_ATTR_UNRECOGNIZED = 0x0008,XML_ERR_ATTR_INVALID = 0x0010,XML_ERR_ATTR_MISSING = 0x0020,XML_ERR_ELEM_UNRECOGNIZED = 0x0040,XML_ERR_ELEM_INVALID = 0x0080,XML_ERR_ELEM_MISSING = 0x0100,XML_ERR_ELEM_CONTEXT = 0x0200,XML_ERR_IOS_PARSER = 0x0400,XML_ERR_IOS_MODULE_IN_USE = 0x0800,XML_ERR_IOS_WRONG_MODULE = 0x1000,XML_ERR_IOS_CONFIG = 0x2000The default error_tolerance value is 0x48, which corresponds to ignoring unrecognized attributes and elements.
Related Documentation
For more detailed installation and configuration information, refer to the following publications:
•
•
•
•
•
•
•
•
•
•
•
•
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
•
Cisco IOS Software Documentation Set
Cisco IOS Configuration Guides and Command References—Use these publications to help you configure the Cisco IOS software that runs on the MSFC and on the MSM and ATM modules.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/cisco/web/psa/default.html?mode=prod
You can access the Cisco website at this URL:
You can access international Cisco websites at this URL:
http://www.cisco.com/web/siteassets/locator/index.html
Documentation DVD
Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.
Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.
Cisco Ordering tool:
http://www.cisco.com/web/ordering/root/index.html
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/web/ordering/root/index.html
You can order Cisco documentation in these ways:
•
http://www.cisco.com/web/ordering/root/index.html
•
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
•
•
•
A current list of security advisories and notices for Cisco products is available at this URL:
If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:
•
•
Tip
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:
http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on
In an emergency, you can also reach PSIRT by telephone:
•
•
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.
Cisco Technical Support Website
The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:
http://www.cisco.com/cisco/web/support/index.html
Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:
https://tools.cisco.com/RPF/register/register.do
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/en/US/support/tsd_contact_technical_support.html
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•
http://www.cisco.com/go/marketplace/
•
•
http://www.cisco.com/web/about/ac123/ac114/about_cisco_packet_magazine.html
•
•
http://www.cisco.com/web/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html
•
http://www.cisco.com/web/learning/index.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Copyright © 2005, Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)