Release Notes for Catalyst 6500 Series Switch Content Switching Module with SSL (CSM-S) Software Release 1.1(3)
Available Languages
Table Of Contents
Software Release 1.1(3) Features
Open Caveats in Software Release 1.1(3) for CSM
Resolved Caveats in Software Release 1.1(3) for CSM
Open Caveats in Software Release 1.1(2) for CSM
Resolved Caveats in Software Release 1.1(2) for CSM
Open Caveats in Software Release 1.1(2) for SSL
Resolved Caveats in Software Release 1.1(2) for SSL
Open Caveats in Software Release 1.1(1)
Resolved Caveats in Software Release 1.1(1)
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 Switch Content Switching Module with SSL Software Release 1.1(3)
Current Release—January 28, 2005
This publication describes the features, modifications, and caveats for the Catalyst 6500 series Content Switching Module with SSL (CSM-S) software release 1.1(3) operating on a Catalyst 6500 series switch with a Supervisor Engine 2 with MSFC2 and Cisco IOS Release 12.2(18)SXD or higher or with a Supervisor Engine 720 and Cisco IOS Release 12.2(18)SXE 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-S software release 1.1(3).
Memory Requirements
Hardware Supported
Before you can use the Catalyst 6500 series CSM-S, you must have a Supervisor Engine 2 with an MSFC2 or a Supervisor Engine 720 and any module that has ports to connect server and client networks.
Caution
Software Requirements
Caution
Table 1 lists the software releases for the CSM-S:
Software Compatibility
The minimum version that is listed is required to support the CSM-S hardware with a given Supervisor engine to perform basic CSM-S configuration.
The recommended version is the base version to support new commands for a given CSM release.
Table 2 and Table 3 lists the CSM-S software release compatibility.
Software Release 1.1(3) Features
This software release contains feature sets supporting SSL (CSM-S) and functionality from previous CSM releases. The tables in this section list these feature sets.
Table 4 lists the CSM features available in this release and previous releases.
Table 5 lists the CSM-S features in this release.
1 NAT = Network Address Translation
2 PAT = Port Address Translation
Limitations and Restrictions
•
•
•
•
•
Note
Caveats
These sections describe the open and resolved caveats in CSM-S software:
•
•
•
•
•
•
•
•
Open Caveats in Software Release 1.1(3) for CSM
Note
This section describes known limitations that exist in CSM-S software release 1.1(3).
•
When you configure more than one virtual server with an IP address that is being used by a DNS serverfarm (GSLB feature), the health probe for the real server within this serverfarm might show as failed. This situation is caused by the probe checking the status of one virtual server instead of checking the status of all virtual servers with this IP address.
Workaround: Remove those virtual servers which are out-of-service.
•
Resetting the CSM-S can cause these messages to appear on the supervisor console:
%EARL-SP-STDBY-4-BUS_CONNECTION:Interrupt FM_CRC16_ERR occurring in EARL bus connection.%EARL-SP-STDBY-4-BUS_CONNECTION:Interrupt HD_CRC_ERR occurring in EARL bus connection.%EARL-SP-STDBY-4-BUS_CONNECTION: Interrupt ENCAP_ERR occurring in EARL bus connection.This situation happens only when there is a non-fabric enabled module in the chassis. The CSM-S is a non-fabric enabled module.
Workaround: None.
•
During a supervisor engine switch over, the standby CSM-S fails to initialize and the new standby supervisor engine prints the following message for all CSM-S ports:
%PM-STDBY-4-INT_FAILUP:GigabitEthernet7/2 failed to come up.No internal VLAN availableWorkaround: None.
•
If more than one CSM-S in a chassis is reset through the hw-reset command, one of the modules may fail to reboot the first time. This failure may be caused by the supervisor engine timeout value for a module to reset itself. In these cases, the module must be either power-cycled or reset a second time.
Workaround: If the module does not boot after a reset, use the hw-reset command to restart the module or power cycle the switch.
•
In a CSM-S fault tolerant configuration, it is possible for a failover to occur between the CSM-S fault-tolerant pair. However, failover may not occur if the SSL daughter card fails. When the SSL daughter card failure is detected, the SSL daughter card is restarted causing all SSL flows to fail, and they will need to be re-established.
Workaround: None.
•
The CSM-S module may stop responding to the supervisor engine keep-alive polling. When this situation occurs, the supervisor power cycles the module to restart it. After restarting, the module operates correctly.
Workaround: None.
•
As of software Release 12.2(18)SXD the CSM-S needed identifiers assigned in the MIBs, for example:
CISCO-ENTITY-VENDORTYPE-OID-MIB.my & OLD-CISCO-CHASSIS-MIB.myThis situation causes incorrect values to show up through SNMP. New identifier assignments have been made in the MIBs and are available in the 12.2(18)SXD release as follows:
CISCO-ENTITY-VENDORTYPE-OID-MIB.my:csm-ssl(442) -- CSM-S is a content switching module with integrated SSL accelerationOLD-CISCO-CHASSIS-MIB.my:cevChassisCSMSsl OBJECT IDENTIFIER ::= { cevChassis 479 }-- CSM-S is a content switching module with integrated SSL accelerationWorkaround: None.
•
When the module boots, you may see messages on the CSM-S console, as follows:
SCP:Rcvd an Unknown Opcode 0x3e...SCP:Rcvd an Unknown Opcode 0x3e...SCP:Subcommand: COMMAND_MODULE_ONLINEModule has become online.SCP: SCP_SET_GET_LTL Subcmd 0x9 UnsupportedSCP: SCP_SET_GET_LTL Subcmd 0x9 UnsupportedWorkaround: None. There is no operational impact to these messages. They can be safely ignored.
•
CSM-S does not allow static ARP for the SSL daughter card interface.
Workaround: None.
•
Thrashing syslog messages may appear under heavy certificate authenticated SSL traffic and the SSL Cisco IOS console may become unresponsive. The heavy traffic is for an SSL proxy-service that has certificate authentication turned on. For example:
ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only | all }The more traffic, the more unresponsive the console becomes. At very high traffic loads the following syslog may appear:
*Apr 1 22:39:13.071: %SCHED-3-THRASHING: Process thrashing onwatched boolean 'CSM IOS Watch Bool'.-Process= "CSM IOS I/O Process", ipl= 5, pid= 27-Traceback= 5233E8 5234CC 5C6044Workaround: None.
•
The static nat command is normally used for server-initiated connections. In release 3.2(1), you can configure the NAT client static into a server farm to take advantage of the static NAT feature for traffic matching a virtual server. If you configured the NAT client static into a sever farm for FTP or RSTP services, this traffic would not be able to pass through the CSM.
Workaround: Configure a client NAT pool with the server farm IP address instead of using the static nat command.
•
The possible number of VLANs has increased to 511 in CSM software release 3.2(1). This limit is the total number of IP interfaces and alias IP interfaces that can be configured on the CSM. If you need to configure alias IP addresses, you need to reduce the number of VLAN IP interfaces.
Workaround: Reduce the number of configured VLANs to accommodate the total number of alias IP addresses.
•
The UDP probe configured for a server farm can only detect a failure of a UDP service when the connectivity to the server IP address is opened. The CSM relies on the ICMP port unreachable message from the server so that it can detect whether the UDP service is available. If the interface on the server is down, the UDP probe cannot detect this failure condition.
Workaround: Configure an ICMP probe to the same server farm where the UDP probe is configured.
•
When the Layer 7 virtual servers have many connections that are in the process of load-balancing, the new and existing connections experience slow response from the CSM. The connections, which are still waiting for more data from the client or which are waiting for the response from the server, are considered to be in the process of load-balancing.
Workaround: Configure the max-conns option on the servers for slow response servers, or lower the number for the max-parselen option to reduce the unnecessary wait for invalid HTTP connections.
Resolved Caveats in Software Release 1.1(3) for CSM
Note
This section describes the caveats resolved in CSM-S software release 1.1(3).
•
The show ssl-proxy version command incorrectly displays the SSL version number as 2.1(2) as shown in this example:
show ssl-proxy versionCisco Internetwork Operating System SoftwareIOS (tm) SVCSSL Software (SVCSSL-K9Y9-M), Version 12.2(14.6)SH2(0.19) INTERIM TEST SOFTWARECopyright (c) 1986-2005 by cisco Systems, Inc.Compiled Wed 05-Jan-05 10:03 by integImage text-base: 0x00400078, data-base: 0x00B06000ROM: System Bootstrap, Version 12.2(15)YS1 RELEASE SOFTWAREshakira uptime is 14 hours, 47 minutesSystem returned to ROM by power-onSystem image file is "tftp://255.255.255.255/unknown"AP Version 2.1(0.19) 4.2(0.20) 2.1(2)The last value should be "2.1(3)."
Workaround: None.
Open Caveats in Software Release 1.1(2) for CSM
Note
This section describes known limitations that exist in CSM-S software release 1.1(2).
•
When you configure more than one virtual server with an IP address that is being used by a DNS serverfarm (GSLB feature), the health probe for the real server within this serverfarm might show as failed. This situation is caused by the probe checking the status of one virtual server instead of checking the status of all virtual servers with this IP address.
Workaround: Remove those virtual servers which are out-of-service.
•
Resetting the CSM-S can cause these messages to appear on the supervisor console:
%EARL-SP-STDBY-4-BUS_CONNECTION:Interrupt FM_CRC16_ERR occurring in EARL bus connection.%EARL-SP-STDBY-4-BUS_CONNECTION:Interrupt HD_CRC_ERR occurring in EARL bus connection.%EARL-SP-STDBY-4-BUS_CONNECTION: Interrupt ENCAP_ERR occurring in EARL bus connection.This situation happens only when there is a non-fabric enabled module in the chassis. The CSM-S is a non-fabric enabled module.
Workaround: None.
•
During a supervisor engine switch over, the standby CSM-S fails to initialize and the new standby supervisor engine prints the following message for all CSM-S ports:
%PM-STDBY-4-INT_FAILUP:GigabitEthernet7/2 failed to come up.No internal VLAN availableWorkaround: None.
•
If more than one CSM-S in a chassis is reset through the hw-reset command, one of the modules may fail to reboot the first time. This failure may be caused by the supervisor engine timeout value for a module to reset itself. In these cases, the module must be either power-cycled or reset a second time.
Workaround: If the module does not boot after a reset, use the hw-reset command to restart the module or power cycle the switch.
•
In a CSM-S fault tolerant configuration, it is possible for a failover to occur between the CSM-S fault-tolerant pair. However, failover may not occur if the SSL daughter card fails. When the SSL daughter card failure is detected, the SSL daughter card is restarted causing all SSL flows to fail, and they will need to be re-established.
Workaround: None.
•
The CSM-S module may stop responding to the supervisor engine keep-alive polling. When this situation occurs, the supervisor power cycles the module to restart it. After restarting, the module operates correctly.
Workaround: None.
•
As of software Release 12.2(18)SXD the CSM-S needed identifiers assigned in the MIBs, for example:
CISCO-ENTITY-VENDORTYPE-OID-MIB.my & OLD-CISCO-CHASSIS-MIB.myThis situation causes incorrect values to show up through SNMP. New identifier assignments have been made in the MIBs and are available in the 12.2(18)SXD release as follows:
CISCO-ENTITY-VENDORTYPE-OID-MIB.my:csm-ssl(442) -- CSM-S is a content switching module with integrated SSL accelerationOLD-CISCO-CHASSIS-MIB.my:cevChassisCSMSsl OBJECT IDENTIFIER ::= { cevChassis 479 }-- CSM-S is a content switching module with integrated SSL accelerationWorkaround: None.
•
When the module boots, you may see messages on the CSM-S console, as follows:
SCP:Rcvd an Unknown Opcode 0x3e...SCP:Rcvd an Unknown Opcode 0x3e...SCP:Subcommand: COMMAND_MODULE_ONLINEModule has become online.SCP: SCP_SET_GET_LTL Subcmd 0x9 UnsupportedSCP: SCP_SET_GET_LTL Subcmd 0x9 UnsupportedWorkaround: None. There is no operational impact to these messages. They can be safely ignored.
•
CSM-S does not allow static ARP for the SSL daughter card interface.
Workaround: None.
•
Thrashing syslog messages may appear under heavy certificate authenticated SSL traffic and the SSL Cisco IOS console may become unresponsive. The heavy traffic is for an SSL proxy-service that has certificate authentication turned on. For example:
ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only | all }The more traffic, the more unresponsive the console becomes. At very high traffic loads the following syslog may appear:
*Apr 1 22:39:13.071: %SCHED-3-THRASHING: Process thrashing onwatched boolean 'CSM IOS Watch Bool'.-Process= "CSM IOS I/O Process", ipl= 5, pid= 27-Traceback= 5233E8 5234CC 5C6044Workaround: None.
•
The static nat command is normally used for server-initiated connections. In release 3.2(1), you can configure the NAT client static into a server farm to take advantage of the static NAT feature for traffic matching a virtual server. If you configured the NAT client static into a sever farm for FTP or RSTP services, this traffic would not be able to pass through the CSM.
Workaround: Configure a client NAT pool with the server farm IP address instead of using the static nat command.
•
The possible number of VLANs has increased to 511 in CSM software release 3.2(1). This limit is the total number of IP interfaces and alias IP interfaces that can be configured on the CSM. If you need to configure alias IP addresses, you need to reduce the number of VLAN IP interfaces.
Workaround: Reduce the number of configured VLANs to accommodate the total number of alias IP addresses.
•
The UDP probe configured for a server farm can only detect a failure of a UDP service when the connectivity to the server IP address is opened. The CSM relies on the ICMP port unreachable message from the server so that it can detect whether the UDP service is available. If the interface on the server is down, the UDP probe cannot detect this failure condition.
Workaround: Configure an ICMP probe to the same server farm where the UDP probe is configured.
•
When the Layer 7 virtual servers have many connections that are in the process of load-balancing, the new and existing connections experience slow response from the CSM. The connections, which are still waiting for more data from the client or which are waiting for the response from the server, are considered to be in the process of load-balancing.
Workaround: Configure the max-conns option on the servers for slow response servers, or lower the number for the max-parselen option to reduce the unnecessary wait for invalid HTTP connections.
Resolved Caveats in Software Release 1.1(2) for CSM
Note
This section describes the caveats resolved in CSM-S software release 1.1(2).
CSCeg38830
When you configure the Cookie Insert or Header Insert feature and you enable the sticky database replication option, the CSM may crash and reboot. The core-dump information would show "IXP4 Bad Data exception on task 'IXP4 SA-CORE (Ex 5)(00000000h)." This problem exists in CSM releases 4.1(1) and 4.1(2).
Workaround: Disable the sticky replication option or the Cookie Insert feature.
•
The CSM closes the connection when it receives a RST packet that it believed to be the correct sequence number. In some cases, the server would ignore this RST packet because the server had seen data beyond the TCP sequence number in the RST packet. This action causes the situation where the server will still have an opened connection that only can be timed out by the TCP stack on the server. In this 4.1(3) release, there is an additional configurable environment variable "TCP_ACCEPT_RST_EQU_NEXT_GET_SEQ" which forces the CSM to a more strict sequence number check and leaves the connection opened (with a quicker idle timer) on the CSM if the RST packet does not match this condition.
Workaround: Tune the TCP stack on the server to have a quicker timeout value.
•
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 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 configured on the same CSM.
Workaround: None.
•
If an RST packet with an invalid sequence number follows the FIN packet immediately, the CSM accepts this RST and closes the connection. This problem occurs for Layer 4 virtual servers only.
Workaround: None.
•
When performing Layer 7 load-balancing, sometimes the CSM forwards an RST packet with an invalid TCP checksum value to the server. This condition can cause the server to have unclosed connections.
Workaround: None.
•
For a given HTTP request, if the client sends in a valid (not expired) sticky HTTP cookie, the CSM does not learn the new cookie value in the server reply. This action creates a situation in which the real server keeps changing the cookie value that is being used for persistent connections by the CSM. As a result, the subsequence client request with the new cookie value is not sticky.
Workaround: None.
•
When enabling the cookie insert sticky feature on the CSM, the module does not insert the configured cookie into the HTTP header of the server response. This action creates a situation in which the CSM incorrectly inserts the cookie into the HTTP body of the server response. These conditions may trigger this problem:
a.
b.
c.
d.
Workaround: None.
•
When connections are replicated with destination port translation (the virtual server port is different from the port configured for the real server) to the redundant CSM, the data flows may have been incorrectly set up. If the redundant CSM that is in standby mode becomes active, all traffic that matched these flows would be forward by the CSM with an invalid TCP checksum value.
Workaround: Remove the destination port configured on the real server.
•
When configured with a destination port translation for a real server, the CSM is unable to send a RST character to the server when choosing another server for HTTP persistent rebalancing. The connection remains open on the server. This situation prevents the HTTP persistent connection from being re-balanced back to the server.
Workaround: Remove the destination port configured on the real server.
Open Caveats in Software Release 1.1(2) for SSL
Note
This section describes known limitations that exist in CSM-S software release 1.1(2) for SSL.
•
The SSL Services Module does not support client certificate insertion for SSL client proxy service. If you apply an HTTP header policy to a client proxy service, and configure the HTTP header policy with client certificate insertion and other headers, error messages are displayed and the configuration is not accepted.
Output from the show running-config command and the show ssl-proxy service service_name command does not show that the HTTP header policy is attached to the client proxy service; however, the SSL Services Module continues to insert the other configured HTTP headers (other than client certificate headers) in the request.
Workaround: Save the configuration and reset the SSL Services Module.
•
When you configure trust points for manual or TFTP enrollment and enter the crypto ca certificate query command, the router loses certificates after it is reloaded.
Workaround: Do not enter the crypto ca certificate query command if you configure any of the trust points for manual or TFTP enrollment.
•
The SSL Services Module with a virtual TCP policy configured with a low TCP maximum segment size (MSS) value (for example, 256), and with the default SYN timeout on the server side, might experience a software-forced reset due to exhausted resources if the following events occur simultaneously:
–
–
–
–
Workaround: Do one of the following:
–
–
•
If you add a trailing "/" to the url value in the enrollment url url command for a trustpoint, the SSL Services Module sends the following GET request during certificate authority authentication:
GET //pkiclient.exe?operation=GetCACert&message=t1 HTTP/1.0The pkiclient.exe file is usually located in the /cgi-bin/ directory of the certificate authority server.
Workaround: Do not enter a trailing "/" to the url value in the enrollment url url command for a trustpoint.
•
When you import a certificate from a PKCS12 or PEM file or when you manually input a certificate authority certificate to the module, and the certificate contains an invalid extension, the SSL peer might reject the certificate.
Workaround: Make sure that the certificate has the correct extension (for example, basic constraint) before importing it to the module.
•
If multiple certificate authority certificates in the database have the same subject name, the certificate chain might contain the wrong certificate authority certificate. If the SSL Services Module is configured as an SSL server, it will send the wrong certificate authority certificate in the chain to the client, which could result in authentication and handshake failures.
Workaround: When a certificate authority has renewed its certificate, make sure that you renew all the SSL certificates issued by this certificate authority. Delete the old certificate authority certificate from the database to avoid this problem.
•
The SSL Services Module does not rewrite the URL if the HTTP header that specifies the relocation string spans more than one TCP segment.
Workaround: None.
•
If you configure a URL rewrite rule, and a server redirects a client to a website that does not have a trailing "/" in the URL, the SSL Services Module does not rewrite the URL.
Workaround: Configure the server to add a trailing "/" to the relocation string.
•
Automatic enrollment might not work correctly if the router does not have a hardware clock (calendar) or if you have not configured a network time protocol (NTP) server.
Workaround 1: Remove the auto-enroll configuration, and then reconfigure auto-enroll to reset the clock manually.
Workaround 2: Reset the enrollment timer by doing the following:
a.
b.
c.
•
The Cisco IOS PKI system does not validate the issuer when using manual enrollment. As a result, a certificate chain may have a root certificate belonging to one certificate authority and a router certificate issued by another certificate authority.
Workaround: None.
•
Windows 2000 certificate authorities occasionally reject certificate enrollment requests issued by the SSL Services Module. The problem originated with the SCEP DLL, and is fixed on the .net version of the certificate authority, but not on the Windows 2000 version.
Workaround: Restart the certificate authority, and issue the enrollment request again.
•
There is no help string for the test crypto pki self command, and the generated self-signed certificate is not displayed by the show crypto ca certificate command.
Workaround: None.
•
Importing a self-signed certificate with the key pair of the issuer is not supported by the Cisco IOS PKI system.
Workaround: None.
•
For manual certificate enrollment, if the URL string ends with a backslash (/) after the TFTP server name or address (for example, tftp://ipaddress/), the system tries to open a file named ".ca" from the TFTP server.
Workaround: Specify the filename in the URL.
•
Cutting and pasting the hexadecimal values of a certificate into the configuration from the terminal can cause the data entry to fail.
Workaround: Copy the configuration file to the running-configuration, or import the certificate with the key pair using a PKCS#12 file.
•
If you import a key pair and a self-signed certificate from a PKCS#12 file to a trustpoint and assign the certificate to a proxy service, installation of the certificate fails after rebooting the system, and the proxy service remains in the "no cert" state.
Workaround: After rebooting, delete the trustpoint and import the PKCS#12 file again. The proxy service automatically reinstalls the self-signed certificate.
•
When query mode is configured and there are multiple trust points using the same certificate authority URL, only one of these trust points succeeds in obtaining the whole certificate chain after a Cisco IOS reboot.
Workaround: Manually authenticate and enroll these trust points after the failure. Turn off query mode, and save the certificates in the NVRAM.
•
Exporting a PKCS#12 file using FTP can take up to 20 minutes if a file with the same name exists on the remote host.
Workaround: None.
•
If you enter the clear arp command on the SSL Services Module, all the proxy services go into a "down" state and then go into an "up" state.
Workaround: None.
•
Syslog messages indicating that proxy services are in the UP state may not be printed for all the services configured in the system while booting.
Workaround: None.
•
The module might take longer to boot up if there are client NAT pools in the startup-configuration. The delay is proportional to the number of NAT pools in the configuration. With the maximum supported number of NAT pools (64), the delay is up to 4 minutes.
Workaround: None.
•
When query mode is configured, entering the no crypto ca certificate query command on the running configuration does not stop the periodic polling for certificates.
Workaround: None.
•
When certificate query mode is configured, an "invalid input" message may be displayed on the console following a fingerprint. This message is displayed when a certificate is read from NVRAM on Cisco IOS reboot and does not indicate a real error condition.
Workaround: None.
Resolved Caveats in Software Release 1.1(2) for SSL
Note
This section describes the caveats resolved in CSM-S software release 1.1(2) for SSL.
•
An HTTP POST request from a client using a Mozilla-based browser does not contain the end-of-header marker (\r\n\r\n) in the first buffer of the request. The SSL Services Module is unable to insert the header.
Workaround: None.
This problem is resolved in SSL software release 2.1(3).
•
The URL rewrite feature rewrites the protocol and the nondefault port (default ports are port 80 for cleartext and port 443 for SSL). However, if a server sends a location URL that specifies the default cleartext port (for example, http://www.cisco.com:80), the SSL Services Module incorrectly rewrites the protocol as https://www.cisco.com:80. Also, if a server sends a location URL that specifies the default SSL port (for example, https://www.cisco.com:443), the SSL Services Module incorrectly rewrites the protocol as http://www.cisco.com:443. Secure HTTP (https://) cannot use port 80, and HTTP (http://) cannot use port 443.
Workaround: Specify a different (nondefault) port on the server (for example, 81 or 444).
This problem is resolved in SSL software release 2.1(3).
•
When you configure an HTTP header policy, the SSL Services Module might truncate or corrupt HTTP POST variables in the decrypted traffic.
Workaround: Remove the HTTP header policy from the SSL proxy service.
This problem is resolved in SSL software release 2.1(3).
•
When you enter the crypto ca import command to import a certificate and a private key, and the public key in the certificate does not match the private key, the SSL Services Module allows the import process to succeed. When the public key and private key do not match, the SSL Services Module should report an error and the import process should fail.
Workaround: Locate the matching private key and certificate. Remove the mismatched trustpoint and reimport the matching key and certificate.
This problem is resolved in SSL software release 2.1(3).
•
The certificate revocation list (CRL) lookup fails during certificate authentication when a peer certificate is signed by a subordinate certificate authority and when the SSL Services Module receives only a peer certificate or a partial certificate chain. The following debug message displays if you enter the debug crypto pki transactions command:
CRYPTO_PKI: status = 1872: failed to verify CRL signatureWorkaround 1: When declaring the trustpoint, enter the crl optional command option for all relevant subordinate certificate authority and root certificate authority.
Workaround 2: Ensure that the peer application sends the full certificate chain.
Workaround 3: Ensure that the peer certificate is signed by the root certificate authority.
This problem is resolved in SSL software release 2.1(3).
•
The output of the show tech command does not include system crash information or SSL proxy service information.
Workaround: None.
This problem is resolved in SSL software release 2.1(3).
•
After you successfully export a trustpoint in PEM format, no information is displayed regarding the status of the exported PEM file.
This problem is resolved in SSL software release 2.1(3).
Open Caveats in Software Release 1.1(1)
Note
This section describes known limitations that exist in CSM-S software release 1.1(1).
•
After running a sustained traffic load with the client requesting and receiving pages that are 65535 or more bytes, there is reduced performance over time. Performance over time drops approximately 30 percent. This behavior has not been seen with page sizes less than 63353 bytes.
Workaround: None.
•
During a supervisor engine switch over, the standby CSM-S fails to initialize and the new standby supervisor engine prints the following message for all CSM-S ports:
%PM-STDBY-4-INT_FAILUP:GigabitEthernet7/2 failed to come up.No internal VLAN availableWorkaround: None.
•
If more than one CSM-S in a chassis is reset through the hw-reset command, one of the modules may fail to reboot the first time. This failure may be caused by the supervisor engine timeout value for a module to reset itself. In these cases, the module must be either power-cycled or reset a second time.
Workaround: If the module does not boot after a reset, use the hw-reset command to restart the module or power cycle the switch.
•
In a CSM-S fault tolerant configuration, it is possible for a failover to occur between the CSM-S fault-tolerant pair. However, failover may not occur if the SSL daughter card fails. When the SSL daughter card failure is detected, the SSL daughter card is restarted causing all SSL flows to fail, and they will need to be re-established.
Workaround: None.
•
The CSM-S module may stop responding to the supervisor engine keep-alive polling. When this situation occurs, the supervisor power cycles the module to restart it. After restarting, the module operates correctly.
Workaround: None.
•
As of software Release 12.2(18)SXD, identifiers were assigned for the CSM-S in the MIBs. For example:
CISCO-ENTITY-VENDORTYPE-OID-MIB.my & OLD-CISCO-CHASSIS-MIB.myThis situation causes incorrect values to show up through SNMP. New identifier assignments have been made in the MIBs and are available in the 12.2(18)SXD release as follows:
CISCO-ENTITY-VENDORTYPE-OID-MIB.my:csm-ssl(442) -- CSM-S is a content switching module with integrated SSL accelerationOLD-CISCO-CHASSIS-MIB.my:cevChassisCSMSsl OBJECT IDENTIFIER ::= { cevChassis 479 }-- CSM-S is a content switching module with integrated SSL accelerationWorkaround: None.
•
When the module boots, you may see messages on the CSM-S console, as follows:
SCP:Rcvd an Unknown Opcode 0x3e...SCP:Rcvd an Unknown Opcode 0x3e...SCP:Subcommand: COMMAND_MODULE_ONLINEModule has become online.SCP: SCP_SET_GET_LTL Subcmd 0x9 UnsupportedSCP: SCP_SET_GET_LTL Subcmd 0x9 UnsupportedWorkaround: None. There is no operational impact to these messages. They can be safely ignored.
•
CSM-S does not allow static ARP for the SSL daughter card interface.
Workaround: None.
•
Thrashing syslog messages may appear under heavy certificate authenticated SSL traffic and the SSL Cisco IOS console may become unresponsive. The heavy traffic is for an SSL proxy-service that has certificate authentication turned on. For example:
ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only | all }The more traffic, the more unresponsive the console becomes. At very high traffic loads the following syslog may appear:
*Apr 1 22:39:13.071: %SCHED-3-THRASHING: Process thrashing onwatched boolean 'CSM IOS Watch Bool'.-Process= "CSM IOS I/O Process", ipl= 5, pid= 27-Traceback= 5233E8 5234CC 5C6044Workaround: None.
Resolved Caveats in Software Release 1.1(1)
Note
CSM-S software release 1.1(1) is the first release in a new release train.
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/en/US/ordering/index.shtml
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/en/US/ordering/index.shtml
You can order Cisco documentation in these ways:
•
http://www.cisco.com/en/US/ordering/index.shtml
•
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)