Release Note For The Cisco Application Control Engine Module
Release Note For The Cisco Application Control Engine Module
Engine Module
Released: December 21, 2009
Revised: March 10, 2010
Note The most current Cisco documentation for released products is available on Cisco.com.
Contents
This release note applies to the following software versions for the Cisco Application Control Engine
Module (ACE), models ACE10 (ACE10-6500-K9) and ACE20 (ACE20-MOD-K9).
• A2(2.3)
• A2(2.2)
• A2(2.1)
• A2(2.0)
It also includes new features and command changes from software version A2(1.1) to A2(2.0). For
information on the ACE module features and configuration details, see the ACE documentation located
at:
http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html
This release note contains the following sections:
• Supervisor Engine and Cisco IOS Support for the ACE Module
• Virtual Switching System Support
• ACE Module Troubleshooting Wiki
• New Software Features in Version A2(2.3)
• New Software Features in Version A2(2.1)
• New Software Features in Version A2(2.0)
• Features in Software Version A2(1.1) through A2(1.3)
• ACE Operating Considerations
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2009 Cisco Systems, Inc. All rights reserved.
Supervisor Engine and Cisco IOS Support for the ACE Module
• Software Version A2(2.3) Resolved Caveats, Open Caveats, and Command Changes
• Software Version A2(2.2) Resolved Caveats and Open Caveats
• Software Version A2(2.1) Resolved Caveats, Open Caveats, Command Changes, and Syslog
Messages
• Software Version A2(2.0) Resolved and Open Caveats
• Command Changes from Software Version A2(1.1) to A2(2.0)
• Available ACE Licenses
• Ordering an Upgrade License and Generating a License Key
• Upgrading Your ACE Software
• Downgrading Your ACE Software from Version A2(1.0) or Higher to 3.0(0)A1(6.x) in a Redundant
Configuration
• ACE Documentation Set
• Obtaining Documentation and Submitting a Service Request
Supervisor Engine and Cisco IOS Support for the ACE Module
Table 1 and Table 2 summarize the supervisor engine model and Cisco IOS version support for the ACE
module in the Catalyst 6500 series switch and the Cisco 7600 series router, respectively.
Table 1 Supervisor Engine and Cisco IOS Support for the ACE Module in a Catalyst 6500
Series Switch with a Multilayer Switch Feature Card (MSFC3)
Supervisor Engine Model Minimum Required IOS Version Other IOS Version Support
WS-SUP720 12.2(18)SXF4 (or later) 12.2(33)SXH (or later),
WS-SUP720-3B 12.2(33)SXI1 (or later)
WS-SUP720-3BXL
VS-S720-10G-3C 12.2(33)SXH (or later)
VS-S720-10G-3CXL
1. Minimum required IOS version for VSS support. See the Virtual Switching System Support section.
Table 2 Supervisor Engine, Route Switch Processor (RSP), and Cisco IOS Support for the ACE
Module in a Cisco 7600 Series Router with an MSFC3
Supervisor Engine or RSP Minimum Required IOS Version Other IOS Version Support
WS-SUP720 12.2(18)SXF4 (or later) 12.2(33) SRB (or later)
WS-SUP720-3B Not supported: 12.2(33)SXH1
WS-SUP720-3BXL
RSP720 12.2(33)SRC (or later) None
1. Cisco IOS release 12.2(33)SXH runs only on the Catalyst 6500 series switch. Therefore, the Supervisor 720-10GE engines
are not supported in the Cisco 7600 series router.
For more information about Cisco IOS releases, see the Release Notes for Cisco IOS Release 12.2SXF
and Rebuilds and the Release Notes for Cisco IOS Release 12.2(33)SXH and Later Releases.
rehandshake enable
Configure this command under an SSL parameter map and associate the parameter map with an SSL
proxy server using the ssl advanced-options command. To display the status of the rehandshake enable
command, enter the show parameter-map command.
cdp-errors ignore
When you configure the SSL parameter map, you associate it with the SSL proxy server service by using
the ssl advanced-options command in SSL proxy configuration mode.
To reset the default behavior where the ACE rejects an SSL connection when CDP errors occur, use the
no form of the cdp-errors ignore command. For example, enter:
host1/Admin(config-parammap-ssl)# no cdp-errors ignore
To display the number of times that the ACE ignored CDP errors in the presented SSL certificate and
allowed the SSL connection, use the show crypto cdp-errors command. This command displays the
output of the Best Effort CDP Errors Ignored field.
By default, persistence rebalance is disabled. To enable the strict persistence rebalance feature, use the
persistence-rebalance strict command in HTTP parameter-map configuration mode. The syntax of this
command is as follows:
persistence-rebalance strict
To revert to the persistence rebalance behavior that load balances successive GETs to the same server if
the request results in load balancing that chooses the same Layer 7 class in the load-balancing policy,
use the persistence-rebalance command.
Overview
The “\xST” (STop) metacharacter is now available in software version A2(2.1) for all regular
expressions (regexes) that are supported by the ACE. This new metacharacter has been provided for
specific use cases that utilize the maximum parse length to terminate parsing. However, the “\xST”
metacharacter is specifically designed for use by applications that involve the generic data parsing of a
Layer 4 payload.
If you intend to use the “\xST” metacharacter for regex matches on packets from protocols, we
recommend that you use this metacharacter only for the following protocols in the generic data parsing
of a Layer 4 payload:
• SSL session-ID stickiness—To perform sticky hashing on the initial packets in an SSL handshake,
allowing the ACE to stick the same client to the same SSL server based on the SSL session ID.
• Financial Information eXchange (FIX) type ‘A’ Logon message—To define load-balancing criteria
while setting up the outbound path of a connection.
In earlier releases of the ACE software, without the ability to include the “\xST” metacharacter in
regexes, there are certain SSL session-id and FIX packets that may get stuck in the ACE HTTP engine
and eventually time out the connection. The inclusion of the “\xST” metacharacter will now aid the ACE
in properly load-balancing SSL session-id and FIX packets.
The “\xST” metacharacter has been added to software version A2(2.1) per CSCsh04655.
Configuration Examples
The following configuration examples show the use of the “\xST” metacharacter in two very specific
regexes:
Displaying the Layer 7 Match HTTP URL Statement Hit Counts Feature
The Layer 7 match HTTP URL statement hit count feature allows you to display the number of times
that a connection is established (hit count) based on match HTTP URL statements for a class map in a
Layer 7 HTTP policy map. The show service-policy url-summary command displays this information.
The syntax of this command is as follows:
Table 3 describes the fields in the show service-policy url-summary command output.
Table 3 Field Descriptions for the show service-policy url-summary Command Output
Field Description
Service Policy Unique identifier of the policy map.
L3-Class Name of the Layer 3 class map associated with the service policy.
L7-Class Identifier of the Layer 7 class map.
Table 3 Field Descriptions for the show service-policy url-summary Command Output
Field Description
match http url The HTTP URL match statement.
hit The number of times that a connection is established based on a specific URL match
statement.
Note The URL hit counter is per match statement per load-balancing Layer 7
policy. If you are using the same combination of Layer 7 policy and class
maps with URL match statements in different VIPs, the count is combined.
If the ACE configuration exceeds 64K URL and load-balancing policy
combinations, this counter displays NA.
Note For the domain load calculation, the ACE considers the Layer 3 class map, server farm, and real server
objects. All other objects under the domain are ignored during the calculation. For the ACE A2(2.0)
release, the calculation of the Layer 3 class-map has changed. Previously, the calculation considered
each VIP address that is configured in the class map. A VIP-based KAL-AP calculation is run on each
address. Now, the calculation consider all Layer 3 rules (a Layer 3 class map within a Layer 3 policy
map) defined by the class map and sums up the total number of servers and the number of servers in the
Up state. After determining these sums, the ACE multiplies them by the number of VIP addresses
configured in the class map.
For detailed information on the keywords and arguments for this command, see the Cisco Application
Control Engine Module Server Load-Balancing Guide.
Note For KAL-AP, the ACE verifies whether the VIP addresses are active in all Layer 3 class maps that are
configured with the addresses. It ignores all other protocol-specific information for the VIP addresses.
For example, to create a class map VIP-20 that matches traffic destined to VIP address 10.10.10.10 with
a wildcard value for the IP protocol value (TCP or UDP), enter the following command:
host1/Admin(config)# class-map VIP-20
host1/Admin(config-cmap)# match virtual-address 10.10.10.10 any
kal-ap-tag tag_name
The tag_name is the name of the KAL-AP tag. Enter the name as an unquoted text string with no spaces
and a maximum of 76 alphanumeric characters.
Note the following restrictions:
• You cannot associate the same tag name to more than one Layer 3 class map.
• You cannot associate the same tag name to a domain and a Layer 3 class map.
• You cannot configure a tag name for a Layer 3 class map that already has a tag configuration as part
of a different Layer 3 policy map configuration, even if it is the same tag name.
For example, to associate the VIP-20 class map with the l3_policy20 policy map by using the class
command in policy map configuration mode and access policy class configuration mode, enter the
following command:
host1/Admin(config)# policy-map multi-match l3_policy20
host1/Admin(config-pmap)# class VIP-20
host1/Admin(config-pmap-c)#
To associate the KAL-AP-TAG2 tag with the class map, enter the following command:
host1/Admin(config-pmap-c)# kal-ap-tag KAL-AP-TAG2
To remove the KAL-AP-TAG2 tag from the class map, enter the following command:
host1/Admin(config-pmap-c)# no kal-ap-tag
Table 4 Field Output Descriptions for the show kalap udp load all Command
Field Description
VIP-Addr VIP address of the KAL-AP request based on a VIP address.
VIP Tag Name Tag name for a KAL-AP request based on a VIP tag and its associated VIP
address.
Domain Name Name of the domain for a KAL-AP request.
VIP VIP address for the VIP tag or domain KAL-AP request.
Port Port number for the KAL-AP request.
Load Value Load number that the ACE calculates. The number is from 0 to 255 and
reports the server availability of the VIP to the KAL-AP device. A load value
of 0 indicates that the VIP address is not available. A load value of 2 indicates
that the VIP is least loaded and a load value of 255 indicates that the VIP is
fully loaded. A load value of 1 is reserved to indicate that the VIP is offline
and not available for use.
Time Last Updated Time when the KAL-AP request occurred.
For example, to display the latest load information for all VIP addresses, domains, and VIP tags, enter
the following command:
host1/Admin# show kalap udp load all
To display the latest load information to the KAL-AP request for the VIP KAL-AP-TAG2 tag, enter the
following command:
host1/Admin# show kalap udp load vip tag KAL-AP-TAG2
Note After the crypto import bulk command initially executes, pressing Ctrl-C may not cancel it.
The ACE does not a execute any crypto commands or the show crypto commands in Table 11 at the
same time. See Table 11 for more information.
For example, to import all files from an SFTP server., enter the following command:
host1/Admin# crypto import bulk sftp 1.1.1.1 JOESMITH /USR/KEYS/*
Initiating bulk import. Please wait, it might take a while...
Connecting to 1.1.1.1...
[email protected]’s Password: password
...
Bulk import complete. Summary:
Network errors: 0
Bad file URL: 0
Specified local files already exists: 0
Invalid file names: 1
Failed reading remote files: 5
Failed reading local files: 0
Failed writing local files: 0
Other errors: 0
Successfully imported: 10
host1/Admin#
For the complete syntax of and more information about the crypto import command, see the Cisco
Application Control Engine Module SSL Configuration Guide for software version A2(1.0).
expired-crl reject
To reset the default behavior of the ACE of not considering a server certificate as revoked after the CRL
in use has expired, enter the following command:
host1/Admin(config-parammap-ssl)# no expired-crl reject
Note By default, the ACE does not reject server certificates when the CRL in use has passed its update date.
To configure the ACE to reject certificates when the CRL is expired, use the expired-crl reject
command. For more information, see the “Rejecting Server Certificates Because of Expired CRL”
section.
You can determine which CRL information to use for server authentication by using the crl command in
SSL proxy configuration mode. The syntax of this command is as follows:
When the ACE accepts a server certificate in the downloaded CRL database, a successful SSL
connection to an SSL real server increments the following show stats crypto client counters:
• Total SSL server authentications
• SSL static CRL lookups
To scan the server certificate for CRL information, enter the following command:
host1/Admin(config-ssl-proxy)# crl best-effort
When the ACE accepts a server certificate on a best-effort-CRL-enabled connection and the certificate
is not found in the downloaded CRL database, a successful SSL connection to an SSL real server
increments the following show stats crypto client counters:
• Total SSL server authentications
• SSL best effort CRL lookups
After the certificate is validated and cached in the ACE, subsequent SSL connections without session
reuse to the same SSL server increments the following show stats crypto client counters:
• Total SSL server authentications
• SSL best effort CRL lookups
To disable the use of server certificates for CRL information during server authentication, enter the
following command:
host1/Admin(config-ssl-proxy)# no crl best-effort
• url—URL where the ACE retrieves the CRL; the CRL distribution point (CDP). Enter the URL full
path including the CRL filename in an unquoted text string with a maximum of 255 alphanumeric
characters. Both HTTP and LDAP URLs are supported. Start the URL with the http:// prefix or the
ldap:// prefix.
The ldap:/// prefix is not considered a valid LDAP CRL link in the CDP portion of the server
certificate. Valid formats for LDAP URLs are as follows:
– ldap://10.10.10.1:389/dc=cisco,dc=com?o=bu?certificateRevocationList
– ldap://10.10.10.1/dc=cisco,dc=com?o=bu?certificateRevocationList
– ldap://ldapsrv.cisco.com/dc=cisco,dc=com?o=bu?certificateRevocationList
– ldap://ldapsrv.cisco.com:389/dc=cisco,dc=com?o=bu?certificateRevocationList
To use a question mark (?) character as part of the URL, press Ctrl-v before entering it. Otherwise
the ACE interprets the question mark as a help command.
When attempting to download a CRL:
• The ACE considers only the first four CDPs. From the CDPs obtained from certificate, the ACE only
considers valid and complete CDPs for the downloading of the CRLs. If a CDP leads to the
successful downloading of the CRL, ACE does not consider the subsequent CDPs for CRL
downloads.
• If none of the first four CDPs present in the certificate are valid to proceed with the downloading of
the CRL, the ACE considers the certificate as revoked unless you configured the
authentication-failure ignore command in parameter map SSL configuration mode.
• If the ACE fails to download a CRL after trying four valid CDPs, the ACE aborts its initiated SSL
connection unless you configured the authentication-failure ignore command in parameter map
SSL configuration mode.
• The ACE skips malformed CDPs and processes subsequent CDPs. To display CDP error statistics
including the number of malformed CDPs, use the show crypto cdp-errors command.
For example, to configure a CRL that you want to name CRL1 from http://crl.verisign.com/class1.crl,
enter the following command:
host1/Admin(config)# crypto crl CRL1 http://crl.verisign.com/class1.crl
243512
Client ACE Web server
50.100.100.1 100.1.1.122
The following example is the configuration of the authentication group with the root certificate that
signed the client certificate:
crypto authgroup root_ca_pool
cert root-cert-2.cer
The following example provides the configuration for the ldap:// based CDP URL:
crypto crl win2003crl1
ldap://windows2003-srv.win2003.cisco.com/CN=root-ca(2),CN=windows2003-srv,CN=CDP,CN=Public
%20Key%20Services,CN=Services,CN=Configuration,DC=win2003,DC=cisco,DC=com?certificateRevoc
ationList?base?objectClass=cRLDistributionPoint
The following example provides the DNS configuration for the ACE to successfully resolve the
hostname in the ldap:// URL during the CRL download:
ip domain-lookup
ip domain-name win2003.cisco.com
ip name-server 100.1.1.147
interface vlan 50
ip address 100.1.1.138 255.255.0.0
no shutdown
Table 5 Field Descriptions for the show crypto crl crl_name detail Command
Field Description
URL URL where the ACE downloads the CRL.
Last Downloaded Last time the ACE downloaded the CRL. If the CRL is configured on an
SSL-proxy service on a policy map that is not active or the service is not
associated with a policy map, the field displays the “not downloaded yet”
message.
Total Number of Number of times the ACE attempted to download the CRL.
Download Attempts
Failed Download Numbers of times that the ACE failed to download the CRL.
Attempts
Successful Loads Number of times that the ACE successfully loaded the CRL.
Failed Loads Number of times that the ACE could not load the CRL because of a failure.
Hours since Last Load Number of hours that elapsed since the ACE last successfully downloaded
the CRL. If no successful download has occurred, this field displays NA,
not applicable.
No IP Addr Resolutions Number of times the DNS resolution for the server host address of CRL the
failed.
Host Timeouts Number of download retries to the CRL that had timed out.
Next Update Invalid Number of times that the next update field of the CRL was invalid.
Next Update Expired Number of times that the next update field of the CRL was expired.
Bad Signature Number of times that the signature mismatch for the CRL was detected,
with respect to the CA certificate configured for signature verification of
the CRL.
CRL Found-Failed to Number of times that the ACE could not load the CRL because of the
load maximum size limitation of 10MB on ACE or the formatting of the CRL
was not recognized. The ACE recognizes only DER and PEM encoded
CRLs.
File Not Found Number of times that the server responded that the CRL file was not found
at the server.
Memory Outage failures Number of times that the ACE failed to download the CRL because it
temporarily could not provide memory to store the CRL data.
Cache Limit failures Number of times that the ACE could not load the CRL because the CRL
cache was exhausted.
Conn Failures Number of times that the ACE failed to download the CRL because it could
not establish a connection with the server or no server entity was listening
on the destination system.
Internal Failures Number of internal failures in the ACE that hampered downloading the
CRL, for example, internal communication failures between components
responsible for the downloading the CRL.
Table 5 Field Descriptions for the show crypto crl crl_name detail Command (continued)
Field Description
Not Eligible for Number of times that the CRL was found ineligible for downloading
download because the following conditions:
• The downloading of the same CRL is in progress.
• The CRL has already been loaded successfully earlier and has not
expired yet.
HTTP Read Failures Number of times that the ACE encountered an error when downloading the
CRL because it could not read data on the connection established with
server.
HTTP Write failures Number of times that the ACE encountered an error when downloading the
CRL because it could not write the CRL download request from the
connection established with the server.
253011
Error Message %ACE-2-253011: Crypto file storage failure: All certificates/keys were
removed. Error: text_string
Explanation A system failure deleted the SSL services internal database of certificates and keys. The
text_string variable is either of the following:
• Corrupted certificates/keys metadata found
• Out of resources while trying to store certificates/keys metadata
Recommended Action Contact Cisco TAC and send them the message output. Reimport the certificates
and keys to maintain the integrity of the SSL services.
305009
Explanation An address translation slot was created. The slot translates the source address from the
local side to the global side. In reverse, the slot translates the destination address from the global
side to the local side.
305010
305011
Explanation A TCP, UDP, or ICMP address translation slot was created. The slot translates the
source socket from the local side to the global side. In reverse, the slot translates the destination
socket from the global side to the local side.
305012
253003
Explanation This message is logged during the SSL handshake when a client attempts to connect with
a certificate that was signed by an unknown CA (the certificate is not part of the authgroup for this
VIP’s SSL proxy). The client_information variable is the subject name of the client certificate.
253004
Explanation This message is logged during the SSL handshake when client or server authentication
is enabled. The ACE determines that the certificate has been revoked by the CA. The
subject_of_certificate variable is the subject field of the certificate. The proxy_name is the name of
the SSL proxy service. The reason is the reason for the revocation of the certificate and has one of
the following messages:
• revoked—The certificate is revoked by the CA.
• no workable cdps in cert—The certificate does not have a workable CRL distribution point
(CDP). A CDP indicates the location of the CRL in the form of a URL.
• crl download failure—The download of the CRL failed.
253006
Explanation This message is logged during the SSL handshake when client authentication is enabled.
The ACE determines a certificate is invalid or nonexistent. The subject_of_peer_certificate variable
is the subject field of the peer certificate. The reason variable is the reason for rejecting the
certificate.
Note The ACE sticky table, which holds a maximum of 4 million entries, is shared across all sticky types,
including reverse IP stickiness.
Symmetric Topology
A typical firewall load-balancing topology (symmetric) includes two dedicated ACEs with the firewalls
positioned between the ACEs. In this scenario, the ACEs are used exclusively for FWLB and simply
forward traffic through their host interfaces in either direction. See Figure 2.
The hosts in either VLAN 31 or VLAN 21 can initiate the first connection and the hosts on both sides
of the connection can “see” each other directly. Therefore, only catch-all VIPs (with an IP address of
0.0.0.0 and a netmask of 0.0.0.0) are configured on the ACE interfaces.
Gateway 10.10.40.1
10.10.40.x 10.10.50.x Host C
Host D
Bridge-Group Virtual Interface 10.10.40.2
Gateway 10.10.40.1
FSW-OUT FSW-IN
Host A IP: 10.10.40.1
Host B VLAN 21
VLAN 31 VLAN 113 VLAN 112 FW1 VLAN 111
242724
10.10.40.0 10.10.50.0 192.168.1.0
For the network diagram shown in Figure 2, the following steps describe a possible connection scenario
with reverse IP stickiness:
Step 1 Host A (a client) initiates an FTP control channel connection to the IP address of Host C (an FTP server).
Step 2 ACE 1 load balances the connection to one of the two firewalls (FW1 or FW2) in the FWS-OUT server
farm. ACE 1 is configured with a source IP sticky group that is associated with a policy map, which is
applied to interface VLAN 113. This configuration ensures that all connections coming from the same
host (or directed to the same host) are load balanced to the same firewall. The ACE creates a sticky entry
that maps the IP address of Host A to one of the firewalls.
Step 3 The firewall that receives the packets from ACE 1 forwards them to ACE 2.
Step 4 Assume that a sticky group that is based on the destination IP address is associated with a policy map
and is applied to interface VLAN 21. The same sticky group is associated as a reverse sticky group with
the policy that is applied to VLAN 111. When it receives the packets, ACE 2 creates a sticky entry in the
sticky database based on the source IP address (because the sticky group is based on the destination IP
address in this case), which maps the Host A IP address to the firewall in the FWS-IN server farm from
which the traffic was received. Then, ACE 2 forwards the packets to the FTP server (Host C) in the server
farm.
Step 5 If you have enabled the mac-sticky command on the VLAN 111 interface, ACE 2 forwards return traffic
from the same connection to the same firewall from which the incoming traffic was received. The
firewall routes the return traffic through ACE 1, which in turn forwards it to the MSFC and from there
to the client.
Step 6 Now suppose that Host C (an FTP server) opens a new connection (for example, the corresponding FTP
data channel of the previously opened FTP control channel) to the IP address of Host A. Because a sticky
group based on destination IP is associated with the policy applied to interface VLAN 21, ACE 2
performs a sticky lookup and finds a valid sticky entry (the one created in Step 4) in the sticky database
that allows ACE 2 to load balance the packets to the same firewall that the control connection traversed.
Step 7 The firewall routes the packets through ACE 1, which in turn forwards them to the MSFC and from there
to the client (Host A).
Follow these guidelines and observations when you configure reverse IP stickiness:
• When reverse IP sticky is enabled, the sticky entry is populated in one direction (for incoming
traffic) and looked up in the opposite direction (for outgoing traffic), allowing traffic to flow through
the same firewall in both directions.
• The example that is described in the steps above is symmetric because it does not matter on which
side of the connections that the clients and servers reside. Everything would work in a similar
manner if Host C was a client opening the FTP control channel and Host A was a server opening the
FTP data channel, assuming that a reverse sticky group was also configured on the ACE 1 VLAN
112 interface. To make reverse IP stickiness work symmetrically, you must apply a reverse sticky
group to the ACE interfaces that are associated with the firewall server farm (in this example, VLAN
112 and VLAN 111) and apply the same sticky group as a regular sticky group to the ACE interfaces
associated with the hosts (in this example, VLAN 113 and VLAN 21).
• In this example, the assumption is to have a regular sticky group based on the source IP associated
with the VLAN 113 interface of the ACE 1 module and another sticky group based on the
destination IP associated with the VLAN 21 interface of the ACE 2 module (the reverse sticky
groups on VLAN 112 and VLAN 111 would be based on the opposite IPs). Everything would work
correctly if the regular sticky groups were reversed, that is, the sticky group on VLAN 113 was based
on the destination IP and the one on VLAN 21 was based on the source IP, or if both regular sticky
groups were based on both the source and the destination IP.
Asymmetric Topology
The following scenario is asymmetric because it cannot work equally in both directions as in the
previous scenario. In this setup, one of the load balancers is unknown (Unknown LB) so that it is
uncertain whether the load balancer supports reverse sticky. The clients must be on one side of the
connection and the servers must be on the other side with the clients opening the first connection to the
servers. See Figure 3. In this scenario, the ACE performs only FWLB and forwards traffic to the real
servers in the server farm.
Server farm
Gateway 10.10.40.1 RS1
10.10.40.x 10.10.50.x RS2
RS3
Bridge-Group Virtual Interface 10.10.40.2 RS4
Gateway 10.10.40.1
FSW-OUT FSW-IN
IP: 10.10.40.1
VLAN 21
VLAN 31 VLAN 113 VLAN 112 FW1 VLAN 111
242725
10.10.40.0 10.10.50.0 192.168.1.0
For the network diagram shown in Figure 3, the following steps describe the sequence of events for
establishing a connection with reverse IP stickiness:
Step 1 A client initiates a connection (for example, an FTP control channel connection) to the IP address of one
of the servers in the server farm.
Step 2 The Unknown LB load balances the connection to one of the two firewalls in the FWS-OUT server farm.
The Unknown LB should, at a minimum, support load balancing based on the source or destination IP
address hash predictor. These predictors ensure that all connections coming from the same client (or
destined to the same server) are load balanced to the same firewall. Assume in this example that a
predictor based on source IP hash is configured in the Unknown LB, so that all traffic coming from the
same client will be directed to the same firewall.
Step 3 The firewall that receives the packet forwards it to the ACE.
Step 4 Assume that a sticky group that is based on the destination IP address is associated with a policy map
that is applied to interface VLAN 21 using a service policy. The same sticky group is associated as a
reverse sticky group with the policy that is applied to VLAN 111. When it receives the packets, the ACE
creates a sticky entry in the sticky database based on the source IP address (because the sticky group is
based on the destination IP in this case), which maps the Host A IP address to the firewall in the FWS-IN
server farm from which the traffic was received. Then, the ACE forwards the packets to the FTP server
(Host C) in the server farm.
Step 5 If you have enabled the mac-sticky command on VLAN 111, the ACE forwards the return traffic for the
same connection to the same firewall from which the incoming traffic was received. The firewall routes
the return traffic through the Unknown-LB, which in turn forwards it to the MSFC and then to the client.
Step 6 Now suppose that the FTP server opens a new connection (for example, the corresponding FTP data
channel of the previously opened FTP control channel) to the IP address of the client. Because a sticky
group based on the destination IP address is associated with the policy applied to interface VLAN 21,
the ACE performs a sticky lookup and finds a valid sticky entry (the one created in Step 4) in the sticky
database that allows the ACE to load balance the packets to the same firewall that the control connection
traversed.
Step 7 The firewall routes the packet through the Unknown LB, which in turn forwards it to the MSFC and then
to the client.
In this scenario, reverse sticky would also work properly under the following conditions:
• The sticky group is associated with the policy map as a regular sticky group based on source the IP
and applied to the VLAN 21 interface.
• The sticky group is associated with the policy map as a reverse sticky group (based on the
destination IP address) and applied to the VLAN 111 interface.
• The Unknown LB has a predictor based on the hash of the destination IP.
For more information about configuring firewall load balancing, see the Cisco Application Control
Engine Module Server Load-Balancing Guide.
reverse-sticky name
The name argument specifies the unique identifier of an existing IP address sticky group. Enter the name
of an existing IP address sticky group as an unquoted text string with no spaces and a maximum of 64
alphanumeric characters.
For example, to configure reverse IP stickiness for a sticky group called DEST_IP_STICKY, enter the
following sequence of commands:
host1/Admin(config)# sticky ip-netmask 255.255.255.255 address destination DEST_IP_STICKY
host1/Admin(config-sticky-ip)# serverfarm FWS-IN
ACE 1 Configuration
access-list acl1 line 8 extended permit ip any any
policy-map multi-match LB
class CATCH-ALL-VIP
loadbalance vip inservice
loadbalance policy LB_PMAP_TO_REALS
policy-map multi-match ROUTE
class CATCH-ALL-VIP
loadbalance vip inservice
loadbalance policy ROUTE_PMAP
interface bvi 15
ip address 10.10.40.2 255.255.255.0
alias 10.10.40.3 255.255.255.0
no shutdown
ACE 2 Configuration
access-list acl1 line 8 extended permit ip any any
interface vlan 21
ip address 21.1.1.1 255.255.255.0
access-group input acl1
service-policy input L4_TO_FWS
no shutdown
interface vlan 111
description inside FW vlan
ip address 10.10.50.1 255.255.255.0
mac-sticky enable
access-group input acl1
service-policy input L4_TO_REALS
no shutdown
switch-mode
For example, to enable the switch mode feature, enter the following command:
host1/Admin(config)# switch-mode
• Per CSCsz87533, the outbound UDP connection may timeout shortly after the ACE receives a
RADIUS request, but before it gets the response for this request from the server. This situation can
cause the ACE to improperly forward subsequent RADIUS traffic. If the server is not expected to
initiate connections through the ACE, we recommend that you apply an inbound ACL on the server
interface to block these connections.
• In software version A2(2.2), the ACE introduces the STANDBY_WARM and
WARM_COMPATIBLE redundancy states to handle any CLI incompatibility issue between peers
during the upgrading and downgrading of the ACE software. When you upgrade or downgrade the
ACE software in a redundant configuration with different software version, the STANDBY_WARM
and WARM_COMPATIBLE states allow the configuration and state synchronization process to
continue on a best-effort basis. This basis allows the active ACE to synchronize configuration and
state information to the standby even though the standby may not recognize or understand the CLI
commands or state information. These states allow the standby ACE to come up with best-effort
support. In the STANDBY_WARM state, as with the STANDBY_HOT state, configuration mode is
disabled on the standby ACE and configuration and state synchronization continues. A failover from
the active to the standby based on priorities and preempt can still occur while the standby is in the
STANDBY_WARM state.
When redundancy peers run on different version images, the SRG compatibility: field of the show
ft peer detail command output displays WARM_COMPATIBLE instead of COMPATIBLE. When
the peer is in the WARM_COMPATIBLE state, the FT groups on standby go to the
STANDBY_WARM state instead of the STANDBY_HOT state. The following software version
combinations indicate whether the SRG compatibility: field displays WARM_COMPATIBLE (WC)
or COMPATIBLE (C):
• With the resolution of CSCtc14439 in software version A2(2.3), if you add or modify an SSL
certificate/key pair in the SSL proxy such that a mismatch is created, the ACE now displays the
following warning message: “Warning: mismatched key/cert pair in this ssl-proxy” and continues to
use the previous matching certificate/key pair.
• CSCsu88684, CSCsq27062—When you configure the ACE with a large number of contexts and
enable redundancy, as traffic flows on the ACE, the ACE becomes unresponsive and displays the
following messages on the console:
mts_acquire_q_space() failing - no space in sap 516
sap=516 rq=102048 lq=0 pq=0 nq=0 sq=0 buf_in_transit=937, bytes_in_transit=82456
sap=1118 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=936, bytes_in_transit=145904
sap=514 rq=937 lq=0 pq=0 nq=0 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1084 rq=935 lq=0 pq=0 nq=1 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1025 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=102052, bytes_in_transit=9388784
• CSCsy29181—If either of the DP processors is at MAXCONN, the ACE should show MAXCONN
in the show commands. However, the ACE waits until both DP processors are at MAXCONN. This
issue occurs when the cde-same-port-hash is configured. Workaround: None.
• CSCsy34814—The syslog message 305010 includes the duration of the Xlate translation. However
this duration is always equal to the Xlate idle timeout. Workaround: Use the timestamps in the
creation and tear down of the Xlate connections to calculate the Xlate duration.
• CSCsy54551—The show service-policy command displays the connection counts from the service
policy but it does not display the Layer 3 rule in the service policy. Workaround: None.
• CSCsy58843—When the ACE has a high rate of management traffic, it may become unresponsive
due to an ARP failure. Workaround: None.
• CSCsy65650—When the ACE reports the termination of TCP flows, it may display incorrect values
for the duration and amount of data transferred. This issue occurs with HTTP and connections that
are terminated with TCP RST. Workaround: None. If accounting is needed and relies on this log, use
another method.
• CSCsy68974—When you configure the SYN cookie and FTP inspection features on the ACE, and
the number of embryonic connections reach the threshold, the first FTP inspection connection may
encounter a problem if the same connection issues more than one FTP GET request, causing the
second FTP GET request to fail. This problem only applies to the first FTP inspection requests that
trigger the SYN cookie feature. Subsequent FTP connections succeed as long as the SYN cookie
feature is not triggered. Workaround: Disable the SYN cookie feature.
• CSCsy88379—The TAC diagnostic script showtech generates large output due to the show xlate
command. Workaround: None.
• CSCsz09362—When pinging the ACE with small packets, the ACE inserts Ethernet padding into
the ICMP data field of a request less than 18 bytes. Workaround: Use larger ICMP packets to stop
the ACE from inserting the padding.
• CSCsz10107—When you configure preempt and the Catalyst 6500 series switch with an active ACE
module is reloaded, the ACE may not correctly replicate connections when it reboots and becomes
active again. Some connections may get dropped. Workaround: None. This issue does not occur
when reloading only the ACE or if preempt is not configured.
• CSCsz14634—The ACE has problems when you copy large configurations from TFTP to the
running-configuration and use the snmp-server community command to add the public group
Network-Monitor to a context when the command was not in the original configuration.
Workaround: None.
• CSCsz18739—The ACE reloads when running software version A2(1.4) and RADIUS AAA is
configured. Workaround: None.
• CSCsz19849—You cannot import an ACE VIP in WAF. Importing works in software version
A2(1.2) and in A2(1.3). Workaround: None.
• CSCsz20325—If you attempt to remove a nonexisting inspection policy map and then attempt to
remove a configured inspection policy map, the ACE displays an error and does not remove the
policy map. Workaround: Reboot the ACE.
• CSCsz21527—When you configure an SNMP V3 user with authentication and privacy options on
the ACE and attempt to perform an snmpwalk with the authNoPriv option for the same user, the
snmpwalk succeeds. Workaround: None.
• CSCsz25000—When the ACE is running front-end SSL traffic, a memory leak occurs on both IXPs.
This leak happens if the tcp-env information is very lossy and many drop packets in the network
occur with duplicate packets and fragmentation. Workaround: None.
• CSCsz27257—When you configure the ACE for SSL termination and a client sends multiple
single-byte SSL records, the ACE advertises a zero TCP window when terminating the front-end
SSL connection and subsequently does not open the window after the underlying data is processed.
In some packet scenarios, the ACE does not open the TCP window after the server acknowledges
the payload. Part of the scenario also involves the server advertising a zero window to the ACE in
conjunction with the ACE advertising a zero window to the client. Workaround: None.
• CSCsz28035—Accessing the qnx shell from the physical console port of either NP on an ACE puts
you in a shell. If you type exit, the NP console hangs and becomes inaccessible. Workaround: None.
• CSCsz29641—With back-end SSL traffic (SSL initiation), some connections may not be closed
properly and may remain in CLSRST state for approximately one hour or until the TCP timeout
interval expires. Front-end SSL (SSL termination) appears to work normally. Workaround: Enter the
clear conn command in the context to clear the connections or wait for the TCP timeout to occur.
• CSCsz31739—When the VIP is out of service and loadbalance icmp-reply is not configured, the
virtual server entry still exists in the ARP cache. The ACE will respond to ARP requests sent for
this VIP. Workaround: None.
• CSCsz34011—After a series of reboots, both ACE modules lose their context configurations. If the
active ACE halts and reboots, after it reboots it reads the first half of the startup-config file,
establishes FT with the standby ACE (the new active), and synchronizes the configuration to obtain
the rest of the configurations from the other ACE. If the other ACE stops functioning, the active ACE
does not obtain the rest of the configurations, including context configurations. Context
configurations may be lost, although they still exist in the startup-config file. Workaround: None.
• CSCsz34933—The ACE may send a reset with the sequence number zero for a probe configured
with the connection term forced command. Workaround: Use the graceful termination no
connection term command.
• CSCsz40699—When you use the SLB-Admin, Server-Appln-Maintenance, or a custom role with a
create feature server farm rule and the real-inservice feature, you cannot bring real servers in or out
of service under the server farm. Workaround: None. There are currently no workarounds using
these specific roles. However, you can complete these tasks using the Admin role.
• CSCsz49088—When you monitor the ACE CPU, you can only monitor it using an Admin role. The
show system resources command is available only in the Admin role. The Network-Monitor role,
which should have access to all show commands is unable to access the show system resources
command. Configuring a new role on the ACE does not allow you to monitor the system feature.
Therefore, only Admin users are able to run this command. Workaround: Run the show system
resources command in an Admin role.
• CSCsz50090—When you quickly remove a NAT pool and add a new one with more IP addresses
and those addresses are not present in the ARP cache, the ACE does not respond to an ARP request
sent for IP addresses in its NAT pool. Workaround: None.
• CSCsz58417—When you configure any inline match statement in a policy map, the ACE becomes
unresponsive for a few minutes and does not apply the configuration. Workaround: None.
• CSCsz63457—When you add inspect RTSP under a Layer 4 policy map that is already configured
with inspect RTSP, the ACE triggers a download configuration to the data plane. Workaround: None.
• CSCsz68435—When the ACE has many concurrent SSL connections and high peak rates, the ACE
becomes unresponsive under the SSL traffic load. Workaround: None.
• CSCsz82740—When you attempt to disable DHCP relay, the ACE fails to delete the ACL and
displays the following error:
Failed to delete acl
Workaround: None.
• CSCsz83033—When traffic on the ACE matches a Layer 7 rule, the DSCP/TOS bits set in the
packets received from the server are not preserved. Workaround: None.
• CSCsz84462—When you configure redundancy on the ACE and then add or delete interface
VLANs in a loop or frequently, the active ACE becomes unresponsive and generates an IFMGR core
file. Workaround: Do not add or delete VLAN or BVI interfaces in a loop or frequently.
• CSCsz86630—DNS inspection may not work after you upgrade from software version A2(1.1) to a
higher release. The problem occurs only for a percentage of responses and it builds over the time.
The following errors appear in the output of the show np me-stats -sfixup command in the higher
release:
– +[Hash miss errors]
– +[NAT app fixup response error]
Workaround: Disable DNS inspection and configure more aggressive timeouts (for example, 4
seconds) for UDP and port 53.
• CSCsz92671—When you configure the ACE in bridged mode with a Layer 3 VIP, the ACE bridges
relayed DHCP packets in bridged mode instead of load balancing these packets if they match a
configured VIP. Workaround: None.
• CSCta01789—When the ACE has a large configuration with multiple contexts, and each context
has a unique route for the same destination with a different next hop, clearing and copying this
configuration can cause the SE flag to be set incorrectly in the routing table. Workaround: None.
• CSCta03202, CSCsz92427—When you remove and readd the inspect protocol command under a
VIP class from a multi-match policy map, the following error occurs:
Error: This class doesn't have tcp protocol and a specific port
You cannot unconfigure inspection other than HTTP inspection from a policy map. Workaround:
Remove the VIP class from the multi-match policy map and reconfigure it.
• CSCta03825—When the UDP booster is configured, the ACE does not forward every first packet
from a new client's DNS request to a real server on each network processor (NP). Two packets (one
for each NP) are dropped for each session. Workaround: Disable the UDP booster.
• CSCta06378—If a control plane process (for example, snmpd, sysmgr, hm, and scripted hm)
encounters memory corruption of the /proc/meminfo data, the ACE may reboot and produce a core
dump file. Memory corruption may occur with other processes or threads, too. Workaround: None.
• CSCta08715—When you configure CSR fields with certain special characters on the ACE, the
following error message occurs:
Error: Organization-unit name cannot be composed of these special characters.
Workaround: Use an external tool to generate a CSR (for example, OpenSSL) or ask the CA to
generate a key pair and certificate for the ACE.
• CSCta09574—When you configure TACACS on the ACE and a TACACS key with a comma (,)
character and you reboot the ACE, you must enter the key again for TACACS to work properly.
Workaround: Configure the TACACS key on the ACE and TACACS server without a comma
character.
• CSCta20756, CSCsx15558—If the Nitrox II (crypto chip) becomes unresponsive when running
SSL traffic, the ACE may become unresponsive and a core dump of the crypto chip occurs.
Workaround: None.
• CSCta25613—When using RADIUS load balancing, the ACE may become unresponsive and
generate a loadBalance_g_ns core file. Workaround: None.
• CSCta28624—When you configure the MTU in an interface to a value other than the default of
1,500, reuse and reproxy fail. When you configure the MTU in the client interface, SYN cookie fails.
Workaround: Remove the MTU configured for the interface.
• CSCta29049—When the UDP booster is enabled, the ACE drops the UDP packets that originate
from the server. Workaround: Disable the UDP booster.
• CSCta30959—When you configure redundancy on the ACE, configuration mode is enabled on the
active ACE when the standby ACE is in the standby-configuration state. During
standby-configuration synchronization, configuration mode is enabled for a short time and any
command that you enter during that time is lost. Workaround: Do not enter or change any command
during a bulk configuration synchronization.
• CSCta41421—The ACE module may become unresponsive due to an internal error, but it does not
reboot and it does not generate complete core files. Workaround: None.
• CSCta43466—When you do not configure a real server in the server farm, the ACE does not
generate the closing XML tag for the server farm detail output. Workaround: Configure a dummy
real server on the server farm.
• CSCta47529—When you configure the ACE for DHCP relay on an interface, the ACE may route
DHCP traffic that uses a nonbroadcast destination address without using the DHCP relay feature.
Workaround: None.
• CSCta53085—When you configure scripted probes on the ACE, if the disk is full and the ACE
retrieves the exit_msg command from the script, occasionally the ACE reboots. Workaround: None.
• CSCta56143—If the ACE reboots, the service-policy input command may be missing in some user
context configurations. If you enable cfgmgr debugging, it is possible to see that this condition is
due to:
(ctx:2)cm_is_dup_ipaddr_in_shrdvlan_priv : vip address x.x.x.x is already in use by
shared interface vlan x
This problem occurs if a VIP address is duplicated in multiple contexts that have shared VLANs.
Normally, when it applies a service policy, the ACE checks to see if the configured VIP (IP and
ports) is already configured in other contexts and, if so, it does not allow you to apply the service
policy:
ACE/context1(config-if)# service-policy input SP Error: Cannot overlap vip or NAT
address configured in a shared interface!
However, if a service policy is already applied and you add a class-map with a VIP to the policy
map, this check is not performed anymore. In this case, you could have multiple contexts with
duplicated VIPs. Workaround: Do not configure an incremental VIP in a class map, add it to a policy
map, and apply it to an interface as a service policy.
• CSCta57280—When you use the capture command to take packet captures on the ACE, some
frames may be truncated. Workaround: None.
• CSCta71906—When expired CRLs are in use and the expired-crl reject command is configured in
an SSL parameter map, the SSL process on the ACE control plane may become unresponsive.
Workaround: Do not reconfigure VIPs while traffic is flowing.
• CSCta76782—If a client or a server certificate contains a multitiered chain, an SSL handshake may
fail when the order of the certificates within the chain is altered. Workaround: Do not use chained
certificates.
• CSCta78220—When the ACE is under heavy load through XML connections to the local interface,
the ACE can reboot without a core file, generate a kernel crash, or lock out management functions.
This condition is due to over consumption of resources by XML of memory and CPU. Workaround:
Disable XML access to the ACE or stop XML polling of the ACE from customer management
stations.
• CSCta83978—If you download an unusually large number of best-effort CRLs from a server, the
SSL process on the control plane may become unresponsive. Workaround: Do not use best-effort
CRLs.
• CSCta89560—When you configure a match statement for a called party with an invalid regex that
has double quotation marks under a SIP inspection policy, the ACE may become unresponsive and
generate a core dump file. Workaround: None.
• CSCta92673—When SSL traffic is flowing and you reconfigure SSL proxies that contain
authgroups, the ACE leaks memory in the control plane. The memory leak is directly proportional
to the number of reconfigurations that you perform. Workaround: Avoid reconfiguring an SSL proxy
when an authgroup is applied to the proxy.
• CSCta93957—If you upgrade a redundant ACE pair to software version A2(2.1), downgrade the
standby to software version A2(1.4), and allow the pair to synchronize configurations, and then
upgrade the standby again to A2(2.1), the standby ACE does not lock configuration mode, allowing
you to make configuration mode changes. Workaround: Enable a bulk synchronization by entering
the no ft auto-sync command followed by the ft auto-sync command on the active ACE.
• CSCtb03844—When you configure failaction reassign on a server farm configured with cyclic
backup and both real servers are in the failed state, the ACE becomes unresponsive. Workaround:
None.
• CSCtb08318—When you configure the snmp-server unmask-community command in a
non-Admin context on the active ACE, incremental synchronization does not synchronize this
command on the standby ACE. Workaround: Perform bulk synchronization to the standby ACE. You
can execute the no ft auto-sync running-config and ft auto-sync running-config commands on the
active ACE whenever you are configuring or unconfiguring the snmp-server unmask-community
command in a non-Admin context.
• CSCtb08836—If the ACE is configured with cookie stickiness and persistence rebalance and a
client switches cookies and then switches back mid-TCP stream, persistence rebalance works, but
the sticky table is never updated when the connection closes. In this case, connections build up in
the sticky database. Workaround: Perform the following steps:
a. Enter the clear sticky database command to clear the sticky database manually.
b. Add the timeout-activeconns command to the cookie sticky configuration.
• CSCtb12976—When UDP fast age is configured and the ACE is running close to capacity, the ACE
may become unresponsive. Workaround: Disable UDP fast age and/or use UDP booster, and set the
UDP timeout to approximately 10 seconds.
• CSCtb13426—After the ACE has run for a long time without a reboot or there is a lot of
communication between the supervisor engine and the ACE, when you enter the show scp stats
command, the TX bytes field displays a negative byte count in its output. Workaround: None.
• CSCtb13438—When you enter the supervisor no power enable module slot_number command for
the slot number of the standby ACE, the standby ACE asserts itself to be the active ACE before the
shutdown and both ACEs become active. Workaround: None.
• CSCtb15183—When you configure the ACE with an access list and then perform multiple dynamic
configurations and the use of the resequence option on it, duplicate access-list line numbers may
occur on the ACE, further resequence commands fail, and you can not add an object. Workaround:
Reboot the ACE to clear this condition.
• CSCtb16605—When you add the cookie secondary command to a sticky group after you assigned
the group to a policy and an interface, this command has no effect. Workaround: Remove the policy
and reconfigure it.
• CSCtb23312—The ACE becomes unresponsive when its uptime reaches approximately 485 days.
Workaround: Gracefully reboot the ACE before its uptime reaches 480 days.
• CSCtb23798—If you configure a BVI interface and a VLAN interface in two different contexts with
the same ID and apply a global policy in the context with the BVI, the configuration may fail with
either of the following errors:
Error: Global Policy applied, conflicts with VIP, NAT or Interface IP in shared
interface!
Workaround: None.
• CSCtb25491—After modifying an access list and then resequencing it in quick succession, the
following error message appears in the syslog file:
WARNING: Unknown error while processing access-group. Incomplete rule is currently
applied on interface vlanXXXX.
Workaround: Manually roll back to a previous access rule configuration on the interface. Do not
issue resequence commands in quick succession. After you execute a command, reenter it with a
different line number.
• CSCtb27018—When you configure the ACE for SIP UDP, the ACE does not accept the SIP UDP
probes requests because the source port of the 200 OK message from the server is different from the
destination port of the OPTIONS method. Workaround: None.
• CSCtb28897—If you repeatedly enter commands related to SNMP traps for the server farm or the
username command on the ACE CLI, an MTS buffer can leak. Overtime, a shortage of MTS buffers
can cause the ACE to be unresponsive to management commands. Workaround: Do not repeatedly
enter commands related to SNMP traps for the server farm or username command from the CLI.
Monitor the MTS buffers through the show system internal mts buffer details command. If you
detect a leak, schedule a reboot of the ACE.
• CSCtb29571—After you repeatedly configure and unconfigure DHCP in Admin and user contexts,
the DHCP relay service may restart. Workaround: None.
• CSCtb35900—When all of the ports for the first IP address in the NAT pool are used up, NAT pool
exhaustion occurs and ACE-wide problems occur. Workaround: Configure a single NAT pool range,
for example, nat-pool 5 10.147.2.11 10.147.2.14 netmask 255.255.255.255 pat.
• CSCtb38297—When you configure the weighted leastconn configuration on the ACE, the ACE
sends a majority of the traffic to a few of the real servers in a server farm and very little traffic to
the other real servers. When the real servers are in a failed state (PROBE_FAILED) and configured
with custom weights, a configuration download occurs.
Workaround: Perform one of the following:
– Change any configuration on the affected server farm when all the real servers are operational.
For example, enter the no inservice and inservice commands of any real server in the server
farm.
– Remove the weight configuration.
– Remove the probe configuration and then make a configuration change when all real servers are
operational. Readd the probe configuration after 30 seconds.
• CSCtb38910—If you force the core of the syslogd process twice by entering the system internal
snapshot service syslogd command two times, the control plane becomes unreachable (similar to
CSCsz78275). Workaround: None.
• CSCtb39287—During the bootup of an ACE that has multiple contexts with large configurations,
some probe commands may time out due to an mts_recv error. The context may be in the
STANDBY_COLD state after the reboot. This behavior occurs because the probe commands time
out while the configuration manager is busy downloading a large configuration. Workaround:
Manually reconfigure the probe commands that failed because of the above error.
• CSCtb40872—With a large configuration that generates many ACL entries, ACL memory usage
can increase and never return to the previous usage level even after you remove the configuration.
Workaround: None.
• CSCtc43641—While the ACE is processing an SRAM parity error in the buffer freelist, an
me_dump process issue occurs, the ACE reboots, and the following files are seen using the dir core:
command:
314320 Oct 4 00:09:33 2009 qnx_2_mecore_log.999.tar.gz
467552 Oct 4 00:09:19 2009 qnx_2_me_dump_g_ns_core_log.<pid>.tar.gz
38662 Oct 4 00:09:36 2009 ixp2_crash.txt
An SRAM parity error must occur to cause this me_dump process problem. Workaround: None. The
ACE reboots and recovers on its own.
• CSCtb48429—When repeatedly logging into and out of the ACE, a memory leak occurs.
Workaround: None.
• CSCtb49907—If the ACE fails and the standby ACE becomes active, a gratuitous ARP on the
standby ACE in bridge mode does not update the ARP table causing a probe failure. After the ARP
entry times out, the standby ACE recovers. Workaround: None.
• CSCtb60118—After you reboot the ACE, the SSH key for management connections is different
from the SSH key prior to the reboot. When the SSH key is generated on an active ACE and
synchronized to the standby ACE, the standby ACE does not properly store the new SSH key in
NVRAM. Workaround: If you remove the SSH key, use the write memory command. After a key
is generated, use the write memory command on the active and standby ACE prior to the reboot.
• CSCtb65921—In a redundant configuration, the show conn count command or the show resource
usage all | inc conc- command may show a disproportionately higher number of current connections
on the standby ACE as compared with the active ACE. The show conn | inc CLS command on the
standby may show many connections in the CLSRST state. This problem appears to be a race
condition when short-lived connections end in RST. In this case, the connection remove directive
from the active to the standby may arrive before the connection create directive. Workaround: None.
However, you can reduce the number of connections waiting to time out by lowering the idle timeout
parameter from the default of 60 minutes. A higher discrepancy rate in the connection count between
the active and the standby may require that you configure a more aggressive idle timeout.
• CSCtb68393—When you configure the ACE for LDAP authentication but incorrectly define an
LDAP server, the ACE CLI becomes unresponsive if there are not enough MTS buffers for intrabox
communication. Workaround: Remove the LDAP authentication configuration. Then, properly
configure the LDAP server.
• CSCtb69990—If a probe is a associated with a tracking host, the clear probe command has no
effect. If a probe is associated with a serverfarm or a real server, the clear probe command works
properly. Workaround: None.
• CSCtb70103—When you apply an action list to a policy, you may receive the following
configuration manager error:
• CSCtc25043—When FTP inspection is enabled in bridged mode with a catch-all VIP (0.0.0.0), the
ACE does not source NAT (SNAT) a passive FTP data connection. Workaround: Disable inspection
or change to routed mode.
• CSCtc25527—When redundancy is configured, the ACE may reboot and generate a core file for the
ha_mgr. Workaround: None.
• CSCtc39615—If you configure a parameter map with the TCP window-scaling (WS) option, the
ACE may use the wrong TCP WS option in the server-side TCP SYN when the client WS is greater
than the configured WS on the ACE. Workaround: None.
• CSCtc46913—For all proxied connections, the ACE may send packets to a client with a maximum
segment size (MSS) of 536 bytes regardless of the maximum transmit unit (MTU) that is configured
on the client interface of the ACE. Such proxied connections including the following:
– Layer 7 SSL
– Layer 7 HTTP traffic with a chunked response
– All Layer 7 connections using a connection parameter map with the set tcp wan-optimization
rtt command set to 0
Note For a Layer 7 connection, the behavior remains as long as the connection is in the
proxied state. When the ACE unproxies the connection, the behavior is not seen.
• CSCtc55162—When the ACE TCP protocol stack is processing a large amount of data, the two
ACE modules in a redundant configuration may become unresponsive, generate a core dump file,
and reboot. Workaround: Configure the TCP options in a connection parameter map to clear (not
allow) window scaling.
• CSCtc58925—With SSL configured, the ACE module may become unresponsive with the
following error message: NP 1 Failed : Nitrox Crash Detected. Workaround: None.
• CSCtc60445—A rare environmental condition may cause the ACE network processor to become
unresponsive due to reason "SRAM Parity Error". The memory address that is the source of the
parity error is in a specific region of memory. This condition is present in releases 3.0(0)A2(1.6) and
A2(2.2). Workaround: Reboot the ACE to clear the state. This reboot is accomplished automatically
when the core dump file is created.
• CSCtc76933—When you configure a policy-map of type generic and this policy is linked to an SSL
proxy server, generic parsing over SSL fails in the middle of the connection. Workaround: Configure
a connection parameter-map and assign it to the policy as follows:
parameter-map type connection StayProxy
set tcp wan-optimization rtt 0
• CSCtc77029—When you configure a scripted probe that sends an XML request to the interface of
the ACE (from another ACE) and executes the show service-policy command, the output of the
show proc cpu command shows that the CPU of the control plane (CP) is almost always at
approximately 90% usage and that the XML CP processes is consuming those cycles.
Workaround: Instead of sending an XML request, send a RAW request and turn XML output on
before executing the show service-policy command as follows:
xml_cmd=<request_raw>xml-show on%0ashow service-policy</request_raw>
The resulting XML output will have an extra exec_command node in the response for the xml-show
on command, but the show service-policy response will be the same as with the XML request.
• CSCtc81556—When you configure SSL sessionID stickiness with generic protocol parsing, SSL
connections may hang after the server sends the HELLO packet. Workaround: None.
• CSCtc82817—When you configure the ACE in a Virtual Switching System (VSS) deployment,
multicast OSPF is not bridged. Workaround: Install the active ACE in the same chassis as the active
supervisor engine.
• CSCtc96770—If RADIUS traffic is being sent or you enter the show conn rserver rserver_name
command, the outstanding messages in the load-balancing queue build up over time, which causes
the ACE to become unresponsive eventually. This issue is not seen with the show conn command.
Workaround: Do not use the sh conn rserver command.
• CSCtd18547—An industry-wide vulnerability exists in the Transport Layer Security (TLS)
protocol that could impact any Cisco product that uses any version of TLS and SSL. The
vulnerability exists in how the protocol handles session renegotiation and exposes users to a
potential man-in-the-middle attack. This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml.
• CSCtd27448—When SSL is configured in version A2(1.6a), RSA_WITH_AES_128_CBC_SHA
and RSA_WITH_AES_256_CBC_SHA are configured and a rehandshake is performed, the ACE
may reboot and generate SSL (Nitrox) core dump files. Workaround: Downgrade to the previous
release.
Workaround: Reconfigure the VLANs and the svclc module number vlan-group number command
on the supervisor module.
• CSCsx55228—When you remove an entry with an object group from an ACL which is associated
as global access group and then readd it, merge errors occur and nonallowed traffic goes through the
ACE. Workaround: Unconfigure and then reconfigure the access group.
• CSCsx62330— When SSL is configured in one or more contexts and a large number of certificates
and keys (approximately 2000 or more) are configured on the ACE, HTTPS probes may fail if you
reload the module. The ACE appears to send the HTTPS probes, but they are not successful. You
will not see this problem if you do not reload the module after the configuration. Workaround: If
possible, reduce the number of certificates and keys to below 2000, and then reload the ACE.
• CSCsx80363—When the ACE uses a single IP source NAT with server connection reuse, PAT, and
a high rate of traffic of approximately 30,000 connections per second in a one-arm topology, it
reboots. Workaround: None.
• CSCsx93137 and CSCsx93995—When you enter one of the following commands in any context
but do not complete entering the remote host password when prompted, the ACE waits for your
input:
– crypto import ftp | sftp | {bulk ftp}
– crypto export ftp | sftp
Then, if you enter one of the following commands, the session may appear to be in an unresponsive
state:
– crypto delete
– crypto export
– crypto generate csr
– crypto generate key
– crypto import
– crypto verify
– show crypto authgroup
– show crypto certificate
– show crypto chaingroup
– show crypto files
– show crypto key
After a while, the command aborts with a “SSL PKI subsystem is busy. Please try again later”
message. Reissuing the command results in the same behavior.
Workaround: Enter the remote host password as requested by the associated crypto import | export
command. If the problem persists, clear the relevant sessions by executing one of the following
commands:
– clear users
– clear telnet session_ID
– clear ssh session_ID
You can execute those commands if you have the appropriate privileges (for example, Admin). For
details about role-based access control (RBAC) and user roles, see the Cisco Application Control
Engine Module Virtualization Configuration Guide.
• CSCsy31553—When traffic traverses the ACE module with the same source and destination port
and dynamic NAT for that traffic is enabled, the ACE performs an implicit PAT. This behavior will
interrupt some sessions. This problem does not happens if NAT is not involved. Workaround: If
possible, disable dynamic NAT.
• CSCsy91540—When the supervisor engine detects that the ACE is not responding to keepalives,
the ACE may silently reboot and not generate core dump files. Workaround: None.
• CSCsy94458—The output of the show resource usage command may show that bandwidth has
been denied in the Admin context of the ACE. The counters indicate that bytes have been dropped
prior to a configuration having completed, but the count does not increment thereafter. There is no
adverse effect of these drops; it is a cosmetic issue only. This behavior occurs in the display for the
Admin context only. Workaround: None.
• CSCsy98701—The standby ACE generates a load-balancing core file when you configure two
ACEs as FT pairs that are replicating sticky entries and you enter certain show commands on the
active/master ACE. Workaround: None.
• CSCsz19782—When you convert the configuration from a non-full proxy to a full proxy
configuration for full proxied new connections and you add new VIPs for load balancing, traffic to
these VIPs do not go through the ACE. Workaround: Reboot the ACE.
• CSCsz22742—When you copy a large configuration to the running-configuration file, an API
timeout error may occur. Workaround: None.
• CSCsz54546—When a probe is successful, the output of the show probe detail command may
display 0 in the Last status code field instead of the actual code. If the probe is failing, the Last status
code field value will be correct. Workaround: None.
• CSCsz62556—When you apply connection limits by entering the conn-limit command at the
real-server level and connection limits are already applied at the server-farm level, some real servers
may become stuck in the stopped list forever and not perform loadbalancing. Workaround: Reload
the ACE.
• CSCsz78275—The ACE control plane becomes unreachable using either Telnet or SSH and
eventually the VIPs become unresponsive. Workaround: Reload the ACE.
• CSCsz85367—When you configure and unconfigure access lists in a loop, the ACE leaks memory.
Workaround: Do not configure and then unconfigure access lists in a loop.
• CSCta13446—When you remove and then reapply the inspect ftp command, the ACE may drop
connections. Workaround: None.
• CSCta49917—When Telnet connections, SSH connections, or a debug session are active for a long
time on the ACE or they do not close properly, then the following behavior is observed:
– The MTS buffers increases after each changeto command as displayed by the show system
internal mts buffers command.
– Or the following error message occurs:
IPC queue full. Clear idle telnet/ssh connections or debug plugin sessions to
recover err
Workarounds: 1. Try to clear each session to the ACE using the clear line command. You can
identify all sessions by entering the show users command. 2. You can either Telnet to each context
to make configuration changes or reboot the ACE.
• CSCta77955—The ACE may unexpectedly reboot and generate a minimal core file on the disk.
Workaround: None.
• CSCta92891—If you change the load-balance predictor from least conns to hash url with a mixed
traffic flow that consists of both TCP and UDP, the ACE may become unresponsive and generate a
loadBalance_g_ns core dump file. Workaround: None.
• CSCta99792—When you are making configuration changes to an ACE that has 30 contexts with
traffic running, the control plane configuration manager process may become unresponsive while it
is processing a configuration download or configuration changes. Workaround: None.
• CSCtb00726—If the VIP address conflicts with the shared interface address across contexts, the
standby ACE goes into the cold state with the show ft config-error command displaying the
following error message:
interface vlan number
Error: Global Policy applied, conflicts with VIP, NAT or Interface IP in shared
interface!
Workaround: Do not configure a VIP address with the same address as the shared interface IP
address on which the service policy is configured.
• CSCtb03138—If you configure SNMP traps on a VLAN that has either the IP address or the peer
IP address missing and redundancy is enabled, then the active ACE does not synchronize the SNMP
traps to the standby ACE. The show ft group detail command displays the following error: Error
“Incremental Sync Failure: snmp config sync to sby.” Workaround: Configure both an IP address
and a peer IP address on the interface VLAN that you are using as the trap source.
• CSCtb03834, CSCtb47541—When you configure the failaction reassign command in a server
farm and all the real servers in the server farm are down, the ACE becomes unresponsive to most
CLI commands and its CPU spikes up to 100 percent by the cfgmgr process. Workaround: Use the
no failaction command to disable failaction reassign in the server farm.
• CSCtb21313—When you configure persistence rebalance in a configuration with two server farms
containing the same real server with different port numbers and attached to two different Layer
7 policy maps, connections are dropped intermittently after a rebalance occurs to a different Layer
7 policy. Workaround: None.
• CSCtb44729—When you configure the ACE for Layer 7 load balancing and a connection is closed
before it is processed by the load balancer, the show conn command displays no connections but the
show serverfarm command displays the current connection for the real server even after all traffic
has stopped. Workaround: Remove the real server and readd it.
• CSCtb55526—With HTTP and SMTP traffic flowing and approximately 140,000 concurrent
connections, the ACE module may exhibit CP slowness and eventually reboot with no core dump
files. Workaround: None.
• CSCtb55845—When a Virtual Switching System is configured on two Catalyst 6500 series
switches, active-active redundancy is configured on the two ACEs in separate chassis, and you run
stateless UDP traffic through the ACEs, some connections may fail. A trace shows that the
successful flows use the ACE virtual MAC as the destination and the unsuccessful flows use the
physical interface MAC of the standby ACE. A display of the default route and the svclc RHI routes
shows two entries for the VIP in question. If you enter the show ip route command, the preferred
route is the standby interface instead of the alias IP address. Workaround: None.
• CSCtb56199—The ACE may become unresponsive while it is applying a configuration to the
network processor engines. The following message appears on the console: ERROR : DRV : PCI
send failed! PCI RIngs in Use. Workaround: None.
• CSCtb72635—When you run a script for the show tech detail command on an ACE that has 4000
BVI and 4000 VLAN interfaces configured, the ACE may become unresponsive. Workaround:
None.
• CSCtb86697—When you modify a NAT pool under an interface configuration, the following error
may be logged and can be displayed using the show logging command: “Sep 4 2009 12:34:03
ace/ace: %ACE-1-106028: WARNING: Unknown error while processing service-policy. Incomplete
rule is currently applied on interface vlan953. Manual roll back to a previous access rule
configuration on this interface is needed.” You may also see Service download failures in the show
interface command output. Workaround: Remove and then reapply the NAT pool configuration.
• CSCtb95136—When a server sends a request to a client in an RTSP configuration, the ACE resets
the RTSP connections. RTSP servers are supported only in an asymmetric client-server mode
(required and recommended methods). Workaround: None.
• CSCtb95153—After you apply configuration changes to a NAT pool, the ACE may become
unresponsive because a network processor (NP) microengine (ME) became unresponsive on
X_TO_ME. Workaround: None.
• CSCtc25285—After performing a supervisor switchover (SSO) in an Active-Active ACE failover
configuration, ACE HSRP tracking fails. The output of the show ft track status command indicates
that the ACE is up on both the chassis. Workaround: None.
• CSCtc76686—When the ACE Module is running as the active member in a redundant
configuration, it may reboot and generate a core dump file for the Load Balance (LB) process
running on the Xscale. Workaround: None.
• CSCtc80207—If ACL merge resources are close to exhaustion and you add a configuration
statement that pushes the ACE over the limit, the ACE may drop traffic on the VLAN interface to
which the configuration statement applies. Workaround: To restore service, reverse the last
configuration change that you made. To determine your current ACL merge resource status, enter
the show np 1 access-list resource command in the Admin context and the show acl-merge
merged-list vlan number in non-redundant command in the context or VLAN to which your
configuration change applies.
• CSCtc83195—Under very specific conditions, HSRP or other multicast control packets may be lost
for up to 10 seconds toward the CPU or may be flooded in the case of a non-supervisor port that is
going up and down repeatedly. This behavior has been observed with an ACE in the chassis under
the following conditions:
– IOS version 12.2(33)SXH3a and 12.2(33)SXI
– Configurations with a port channel spanning multiple modules
– Combination of a Catalyst 6708 and SUP EC or a Catalyst 6708 and 6708 EC
– SUP720 and SUP4 on the Catalyst 6500 series switch
Workaround: None.
• CSCtc87588—When TACACS+ is configured, the ACE does not account for configuration mode
commands that contain sensitive information (for example, keys and passwords). Such commands
do not appear in the local ACE accounting log nor in the TACACS server accounting log. In the ACE
accounting log, there are descriptive entries, (for example, "deleted user"). In the supervisor engine
accounting log, the commands are accounted for, but the sensitive information is masked.
Workaround: None.
• CSCtc88730—A double-free of a buffer may cause the ACE to reboot and generate a core dump
file. Workaround: None.
• CSCtc91087—A configuration change in the limit-resource all minimum command value may
cause the ACE to start rate-limiting traffic at a different throughput level than that indicated by the
show resource usage command. Workaround: None.
Table 7 lists the commands and options that have been changed in software version A2(2.3).
Workaround: None.
• CSCsx68671—With generic protocol parsing, payload sticky and UDP fast-age traffic, Layer 7
UDP connections may cause a memory leak in the ACE module data plane. Workaround: None.
• CSCta20756, CSCsx15558—When the ACE has over 120,000 concurrent SSL connections, it
displays SSL connection rate denies, FastQ transmit back pressure, and SSL RX back pressure.
Eventually, the ACE becomes unresponsive. Workaround: None.
• CSCta97335—When you configure the ACE with multiple contexts, DHCP, and a VLAN shared
with the Admin context, the DHCP is not supported in a user-configured context. Workaround:
None.
• CSCtb05686—When you configure multiple service policies under one interface and then delete a
policy, Layer 7 connections reset in the other service policies. Workaround: None.
• CSCtb15617—The ACE release note should include information about the required supervisor
engine Cisco IOS software and hardware revisions. Workaround: None.
• CSCsv92321, CSCsx25981—The ACE module reboots unexpectedly and writes a core file to the
disk. Workaround: None.
• CSCsx05150—When using 2048-bit certificate and key pairs with block and export ciphers, a
rehandshake may lead to stuck connections. Workaround: Either use nonblock and nonexport
ciphers or use certificate and key pairs that are less than 2048 bits.
• CSCsx19525—When you configure 1,000 SSL VIPs on the ACE and then you change the
configuration on those VIPs, a buffer leak occurs as displayed by the show np 1 me-stats command
“-scommon” output and traffic conditions. Workaround: Reboot the ACE and do not make
configuration changes that affect those VIPs.
• CSCsx37047—When you configure and unconfigure an object group on an ACE, it allows invalid
traffic and the acl-merge list becomes corrupted. Workaround: Remove and readd the access group
to the interface or globally.
• CSCsx80363—When the ACE uses a single IP source NAT with server connection reuse, PAT, and
a high rate of traffic of approximately 30,000 connections per second in a one-arm topology, it
reboots. Workaround: None.
• CSCsx93137 and CSCsx93995—When you enter one of the following commands in any context
but do not complete entering the remote host password when prompted, the ACE waits for your
input:
– crypto import ftp | sftp | {bulk ftp}
– crypto export ftp | sftp
Then, if you enter one of the following commands, the session may appear to be in an unresponsive
state:
– crypto delete
– crypto export
– crypto generate csr
– crypto generate key
– crypto import
– crypto verify
– show crypto authgroup
– show crypto certificate
– show crypto chaingroup
– show crypto files
– show crypto key
After a while, the command aborts with a “SSL PKI subsystem is busy. Please try again later”
message. Reissuing the command results in the same behavior.
Workaround: Enter the remote host password as requested by the associated crypto import | export
command. If the problem persists, clear the relevant sessions by executing one of the following
commands:
– clear users
– clear telnet session_ID
– clear ssh session_ID
You can execute those commands if you have the appropriate privileges (for example, Admin). For
details about role-based access control (RBAC) and user roles, see the Cisco Application Control
Engine Module Virtualization Configuration Guide.
• CSCsy29181—If either of the DP processors is at MAXCONN, the ACE should show MAXCONN
in the show commands. However, the ACE waits until both DP processors are at MAXCONN. This
issue occurs when the cde-same-port-hash is configured. Workaround: None.
• CSCsy65650—When the ACE reports the termination of TCP flows, it may display incorrect values
for the duration and amount of data transferred. This issue occurs with HTTP and connections that
are terminated with TCP RST. Workaround: None. If accounting is needed and relies on this log, use
another method.
• CSCsy88379—The TAC diagnostic script showtech generates large output due to the show xlate
command. Workaround: None.
• CSCsy98701—The standby ACE generates a load-balancing core file when you configure two
ACEs as FT pairs that are replicating sticky entries and you enter certain show commands on the
active/master ACE. Workaround: None.
• CSCsz10107—When you configure preempt and the Catalyst 6500 series switch with an active ACE
module is reloaded, the ACE may not correctly replicate connections when it reboots and becomes
active again. Some connections may get dropped. Workaround: None. This issue does not occur
when reloading only the ACE or if preempt is not configured.
• CSCsz14634—The ACE has problems when you copy large configurations from TFTP to the
running-configuration and use the snmp-server community command to add the public group
Network-Monitor to a context when the command was not in the original configuration.
Workaround: None.
• CSCsz18739—The ACE reloads when running software version A2(1.4) and RADIUS AAA is
configured. Workaround: None.
• CSCsz19849—You cannot import an ACE VIP in WAF. Importing works in software version
A2(1.2) and in A2(1.3). Workaround: None.
• CSCsz28035—Accessing the qnx shell from the physical console port of either NP on an ACE puts
you in a shell. If you type exit, the NP console hangs and becomes inaccessible. Workaround: None.
• CSCsz31739—When the VIP is out of service and loadbalance icmp-reply is not configured, the
virtual server entry still exists in the ARP cache. The ACE will respond to ARP requests sent for
this VIP. Workaround: None.
• CSCsz34933—The ACE may send a reset with the sequence number zero for a probe configured
with the connection term forced command. Workaround: Use the graceful termination no
connection term command.
• CSCsz40699—When you use the SLB-Admin, Server-Appln-Maintenance, or a custom role with a
create feature server farm rule and the real-inservice feature, you cannot bring real servers in or out
of service under the server farm. Workaround: None. There are currently no workarounds using
these specific roles. However, you can complete these tasks using the Admin role.
• CSCsz49088—When you monitor the ACE CPU, you can only monitor it using an Admin role. The
show system resources command is available only in the Admin role. The Network-Monitor role,
which should have access to all show commands is unable to access the show system resources
command. Configuring a new role on the ACE does not allow you to monitor the system feature.
Therefore, only Admin users are able to run this command. Workaround: Run the show system
resources command in an Admin role.
• CSCsz86630—DNS inspection may not work after you upgrade from software version A2(1.1) to a
higher release. The problem occurs only for a percentage of responses and it builds over the time.
The following errors appear in the output of the show np me-stats -sfixup command in the higher
release:
– +[Hash miss errors]
– +[NAT app fixup response error]
Workaround: Disable DNS inspection and configure more aggressive timeouts (for example, 4
seconds) for UDP and port 53.
• CSCta03825—When the UDP booster is configured, the ACE does not forward every first packet
from a new client's DNS request to a real server on each network processor (NP). Two packets (one
for each NP) are dropped for each session. Workaround: Disable the UDP booster.
• CSCta29049—When the UDP booster is enabled, the ACE drops the UDP packets that originate
from the server. Workaround: Disable the UDP booster.
• CSCta83978—If you download an unusually large number of best-effort CRLs from a server, the
SSL process on the control plane may become unresponsive. Workaround: Do not use best-effort
CRLs.
• CSCta92673—When SSL traffic is flowing and you reconfigure SSL proxies that contain
authgroups, the ACE leaks memory in the control plane. The memory leak is directly proportional
to the number of reconfigurations that you perform. Workaround: Avoid reconfiguring an SSL proxy
when an authgroup is applied to the proxy.
• CSCta92891—If you change the load-balance predictor from least conns to hash url with a mixed
traffic flow that consists of both TCP and UDP, the ACE may become unresponsive and generate a
loadBalance_g_ns core dump file. Workaround: None.
• CSCta93957—If you upgrade a redundant ACE pair to software version A2(2.1), downgrade the
standby to software version A2(1.4), and allow the pair to synchronize configurations, and then
upgrade the standby again to A2(2.1), the standby ACE does not lock configuration mode, allowing
you to make configuration mode changes. Workaround: Enable a bulk synchronization by entering
the no ft auto-sync command followed by the ft auto-sync command on the active ACE.
• CSCtb03834, CSCtb47541—When you configure the failaction reassign command in a server
farm and all the real servers in the server farm are down, the ACE becomes unresponsive to most
CLI commands and its CPU spikes up to 100 percent by the cfgmgr process. Workaround: Use the
no failaction command to disable failaction reassign in the server farm.
• CSCtb08318—When you configure the snmp-server unmask-community command in a
non-Admin context on the active ACE, incremental synchronization does not synchronize this
command on the standby ACE. Workaround: Perform bulk synchronization to the standby ACE. You
can execute the no ft auto-sync running-config and ft auto-sync running-config commands on the
active ACE whenever you are configuring or unconfiguring the snmp-server unmask-community
command in a non-Admin context.
• CSCtb13426—After the ACE has run for a long time without a reboot or there is a lot of
communication between the supervisor engine and the ACE, when you enter the show scp stats
command, the TX bytes field displays a negative byte count in its output. Workaround: None.
• CSCtb13438—When you enter the supervisor no power enable module slot_number command for
the slot number of the standby ACE, the standby ACE asserts itself to be the active ACE before the
shutdown and both ACEs become active. Workaround: None.
• CSCtb15183—When you configure the ACE with an access list and then perform multiple dynamic
configurations and the use of the resequence option on it, duplicate access-list line numbers may
occur on the ACE, further resequence commands fail, and you can not add an object. Workaround:
Reboot the ACE to clear this condition.
• CSCtb16605—When you add the cookie secondary command to a sticky group after you assigned
the group to a policy and an interface, this command has no effect. Workaround: Remove the policy
and reconfigure it.
• CSCtb23312—The ACE becomes unresponsive when its uptime reaches approximately 485 days.
Workaround: Gracefully reboot the ACE before its uptime reaches 480 days.
• CSCtb23798—If you configure a BVI interface and a VLAN interface in two different contexts with
the same ID and apply a global policy in the context with the BVI, the configuration may fail with
either of the following errors:
Error: Global Policy applied, conflicts with VIP, NAT or Interface IP in shared
interface!
Workaround: None.
• CSCtb25491—After modifying an access list and then resequencing it in quick succession, the
following error message appears in the syslog file:
WARNING: Unknown error while processing access-group. Incomplete rule is currently
applied on interface vlanXXXX.
Workaround: Manually roll back to a previous access rule configuration on the interface. Do not
issue resequence commands in quick succession. After you execute a command, reenter it with a
different line number.
• CSCtb27018—When you configure the ACE for SIP UDP, the ACE does not accept the SIP UDP
probes requests because the source port of the 200 OK message is different from the destination port
of the OPTIONS method. Workaround: None.
• CSCtb29571—After you repeatedly configure and unconfigure DHCP in Admin and user contexts,
the DHCP relay service may restart. Workaround: None.
• CSCtb30337—In a configuration with two gateways for the same network and asymmetric traffic,
the ACE may not handle the connection properly if the source MAC address changes in the middle
of connection. Workaround: None.
• CSCtb34660—When a client sends large HTTP POST requests, the ACE advertises the incorrect
value for the window size when sending the response page. Workaround: Set the buffer share to
64K bytes unless the ACE starts advertising a window size greater than 64K bytes.
• CSCtb34696—When a large POST request is sent to the ACE VIP address with a default window
size, the ACE does not acknowledge the bytes and retransmits them in another frame as a result of
a misassignment in a previous GET request. Workaround: Set the buffer share to 64K bytes.
• CSCtb35900—When all of the ports for the first IP address in the NAT pool are used up, NAT pool
exhaustion occurs and ACE-wide problems occur. Workaround: Configure a single NAT pool range,
for example, nat-pool 5 10.147.2.11 10.147.2.14 netmask 255.255.255.255 pat.
• CSCtb38297—When you configure the weighted leastconn configuration on the ACE, the ACE
sends a majority of the traffic to a few of the real servers in a server farm and very little traffic to
the other real servers. When the real servers are in a failed state (PROBE_FAILED) and configured
with custom weights, a configuration download occurs. Workaround: Perform one of the following:
– Change any configuration on the affected server farm when all the real servers are operational.
For example, enter the no inservice and inservice commands of any real server in the server
farm.
– Remove the weight configuration.
– Remove the probe configuration and then make a configuration change when all real servers are
operational. Readd the probe configuration after 30 seconds.
• CSCtb39310— When you configure the ACE with leastconn predictors using weight buckets and
the ACE processes load balancing requests, the ACE reboots. Workaround: None.
• CSCtb39697—The NAT Pool Alloc [fail] counters increment on the standby ACE but the counters
on the active ACE do not. Workaround: None.
• CSCtb48429—When repeatedly logging into and out of the ACE, a memory leak occurs.
Workaround: None.
• CSCtb49907—When the ACE fails and the standby ACE becomes active, a gratuitous ARP on the
standby ACE in bridge mode does not update the ARP table causing a probe failure. After the ARP
entry times out, the standby ACE recovers. Workaround: None.
Note This software release includes resolved caveats that were merged from software versions A2(1.4),
A2(1.4a), and A2(1.5). For details about those resolved caveats, see the A2(1.x) release note at the
following URL:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A2/release/note/ra
cea2_x.html.
Workaround: None.
• CSCsl75662—You may observe that ACE health probes remain in the INIT state when you change
a parameter that is associated with the probe; the configuration change takes effect only after the
next time that the probe is sent even though the configuration change is visible in the
running-configuration file. This behavior may be most visible when you change a probe with a high
time interval (for example, 65535 seconds) to a much lower interval (for example, 2 seconds). In
this configuration, it may appear as if the probe was not sent; the initial large time interval has to
expire before the new, smaller interval can take effect.
Workaround: For a probe parameter change to take immediate effect, perform the following
procedure:
1. Remove the probe from the real server and the server farm.
2. Modify the probe parameter that you want to change.
3. Readd the probe to the real server and the server farm.
For details, see the Cisco Application Control Engine Module Server Load-Balancing Configuration
Guide.
• CSCsm72725—The packet capture output of one context may appear in other (different) user
contexts. This behavior may occur when you use a terminal to configure the packet capture function
in a context and then specify the changeto command to switch to a different context using the same
terminal.
Workaround: Perform either of the following actions:
– Stop the packet capture process before you enter the changeto command (the recommended
workaround).
– Log out of the terminal, and then log in again to access a different context than the original
context with the configured packet capture function.
• CSCsm89594, CSCsr14898—XML output for the show serverfarm detail command is not valid
XML. If the server farm does not have a configured probe, the generated XML output still contains
a close tag </sf_probes> and does not have an open tag <sf_probes>. Workaround: Configure a
probe in the server farm. If a probe is configured on the server farm, then there should be both an
open tag and a close tag present in the XML output. If a probe is not configured on the server farm,
then neither tag should be present.
• CSCso60304—When an invalid XML attribute is sent to the ACE, it does not respond as expected.
Instead, the ACE displays a 500 Internal Server Error message. No negative impact to the ACE is
observed. Workaround: None.
• CSCso80478—When you perform multiple parallel SNMP walks that last 30 seconds or longer on
an ACE in a redundant configuration, you may observe response timeouts on both the active and the
standby ACEs. You may also observe this behavior in multiple contexts. This behavior does not
occur with SNMP walks of shorter durations. Workaround: None.
• CSCso81785—If you are using TACACS+ and the Cisco Access Control Server (ACS) with an RSA
authentication manager, you may receive the Login Incorrect message when you try to log in to the
ACE with an account that requires a new PIN even if you use the correct credentials. Workaround:
Log in to another network access server (NAS) to set your PIN.
• CSCso81811—If you are using TACACS+ and the Cisco ACS with an RSA authentication manager
and your account is in next token mode, you may receive the Login Incorrect message when you try
to log in to the ACE with an account that requires a new PIN even if you use the correct credentials.
Workaround: Log in to another NAS to enter the next token code and make your account accessible
again.
• CSCso82971—If you are using a TACACS+ server that is an RSA server with TACACS+ continue
authentication, authentication may fail to the configured server, but you still can log in using local
authentication.
Use one of the following workarounds:
• Use the Cisco ACS instead of the RSA server.
• Do not configure local as the secondary authentication method.
• CSCso85639—If you configure the passdetect interval command value for less than 30 seconds,
the ACE sends overlapping probes that use additional management connections (resources).
Workaround: Increase the passdetect interval command value to 45 seconds.
• CSCso86485—When a client-side VLAN interface is brought up and down an excessive number of
times on the active ACE under a light traffic load, the standby ACE may generate a core dump.
Workaround: None.
• CSCso95457—When you enter the clear conn all command, the ACE sends an RST to close the
connection only to the server and purges both the inbound and outbound connection entries from its
connection database. As a result, the client connection is left open and any further requests arriving
on that connection are not serviced. Workaround: None.
• CSCso95620—With long-lived HTTP, SSL, FTP and UDP traffic on the ACE, you may observe a
memory loss of approximately 333 KB in the ACE during an EtherChannel link (FT port channel)
failure and recovery on the Catalyst 6500 series switch. Workaround: None.
• CSCsq87162—SSL transactions may not complete when the server-conn reuse command is
enabled. Workaround: Disable the server-conn reuse command.
• CSCsq99448—When you upgrade the ACE from version A1(6.3a) to A2(1.1), you might
experience unresponsiveness in the outbound connection manager (OCM) because of the deletion
of an improper internal message. Workaround: None.
• CSCsr09129—When you configure SIP load balancing with inspection enabled, the ACE should
open a pinhole to the address in the Via header for the server response. However, the server
responses remain in the data channel. Workaround: None.
• CSCsr18029—The ACE may reload after an SNMP query. Workaround: None.
• CSCsr62027—When TCP normalization is disabled, the ACE places replicated TCP connections in
the INIT state on the standby ACE. After the normal embryonic connection timeout occurs, the ACE
removes the replicated connections from the standby. Workaround: Do not disable normalization.
• CSCsu49899—When an HTTP virtual server that performs Layer 7 inspection shares the same
virtual IP addresses as other servers, the ACE responds to SYN requests whether or not the Layer 7
virtual server is up or down. The ACE completes the three-way handshake before sending an RST.
Workaround: Make sure that HTTP Layer 7 virtual servers have unique virtual IP addresses or all of
them use the same VIP to ensure the other protocols do not get spoofed unnecessarily.
• CSCsu55180, CSCsv02360—When you configure the ACE with SSL termination and server
connection reuse, and a client makes an HTTPS request to the VIP address, some connections fail
if the client MTU is low (for example, an MTU of 576). Workaround: None.
• CSCsu60137—When the ACE issues a POST request, an SSL bad-record MAC error occurs with
Firefox Version 2 and 3. The same POST request works with Microsoft IE. Workaround: None.
• CSCsu67523 and CSCsu67556—Upgrading the ACE software to version A2(1.1a) causes the ACE
to reboot and generate a core dump. Workaround: None.
• CSCsu67539—When you upgrade the ACE software to version A2(1.1), the ACE reboots and
generates a core dump. Workaround: None.
• CSCsu68314—When the ACE becomes unresponsive and generates a core dump, the core-dump
file contains three different types of files. These files should be separate files. Workaround: Use the
file command to uncompress the core-dump files.
• CSCsu68366—The ACE reboots and generates a qnx_2_mecore_log.999.tar.gz core-dump file.
Workaround: None.
• CSCsu86606—When you reboot the ACE and as it powers up, the Catalyst 6500 series switch
disables the ACE and displays the following log messages:
Oct 1 07:43:25.710 EDT: %C6KPWR-SP-4-DISABLED: power to module in slot 1 set off
(Reset)
Oct 1 07:43:41.611 EDT: %OIR-SP-6-PWRFAILURE: Module 1 is being disabled due to power
convertor failure 0x1
Workaround: None.
• CSCsu95356—When you configure the ACE with the predictor least conn command, the real
server does not get the expected number of connections. Workaround: Remove the real server from
the server farm and readd it.
• CSCsu95887—After the active ACE module completes configuration synchronization, it generates
a core dump. Workaround: None.
• CSCsu96977—When you configure more than 640 action lists and enter the do show action_list
command with the Tab or ? key for help, the ACE becomes unresponsive. Workaround: None.
• CSCsv02224—When you configure and remove an SSL-proxy service after you configure and
remove multiple class maps under a policy map, the following error appears on the console:
Error: Called API encountered error appears console.
The ACE rejects the ssl-proxy command and the command does not appear in the configuration.
Workaround: None.
• CSCsv04319—If you create a TACACS+ server with a numeric key, the ACE sends a warning about
the key; however, it does not create the server. The message should be an error and not a warning.
Workaround: Use a key that is not entirely numeric.
• CSCsv04848—When you configure RADIUS on the ACE and a user logs off, the RADIUS client
sends an accounting stop message to the server for that user but the ACE does not immediately delete
all connections for that user. If the source IP address for the user is immediately reassigned to
another user, the new user could open a new connection before the old connections from the previous
user times out. The result is that the ACE incorrectly forwards the new connections and does not
load balance the packets. Workaround: Set the UDP connection timer to a smaller number (for
example, 10 seconds).
• CSCsv10547—The config-register setting does not synchronize after an ACE module boots. The
config-register setting synchronizes only when you configure it with ACE modules in active or
standby mode. Workaround: None.
• CSCsv31476—When the ACE generates a core-dump file for the kernel or Virtual Shell (VSH)
applications, the file does not contain the code-train version information. Workaround: None.
• CSCsv35373—Failaction reassignment does not work with real servers on different VLANs.
Workaround: None.
• CSCsv40516, CSCsr22703, CSCsu67574—When you upgrade the ACE software to version
A2(1.0a), the ACE reboots and generates a core dump. Workaround: None.
• CSCsv41126, CSCsu80235—When you configure stickiness on a context and the sticky database
lookup is 8,192 over the maximum threshold, the ACE drops connections causing the users to
experience resets or their pages do not load properly. The Drop Max Remote Stky counter displayed
by the show np [1 | 2] me-stats -slb command continues to increase. Workaround: Force a failover
to the backup ACE and reboot the module that had the problem.
• CSCsv47724—The heartbeats on fault-tolerant (FT) ACE modules occasionally miss due to late
TCP timers. The ACEs increment the Heartbeats Missed counter on the standby ACE and the
Unidirectional HB’s Received counter on the active ACE. Workaround: None.
• CSCsv48498—When you enable FTP inspection and disable normalization on the client-side
interface, the ACE inserts the TCP Option Timestamp in packets to the client and the FTP server,
even if both the client and the server are not using this option. Workaround: Enable normalization
or disable FTP inspection.
• CSCsv49606—When you configure stickiness on the ACE, the ACE becomes unresponsive.
Workaround: None.
• CSCsv52331—The ACE becomes unresponsive due to an SRAM parity error. Workaround: None.
• CSCsv52478—When you reboot the Catalyst 6500 series chassis, the ACE may reboot as Active.
Workaround: None.
• CSCsv52942—When the server farm that has no backup, goes to inactive state after all the real
servers go to the MAXCONNS state, the real servers may not accept connections even though they
are out of maximum connections. Workaround: Configure a backup to the server farm.
Workaround: Remove the class from the policy map and then readd it.
• CSCsv65178—When you specify TCP as the protocol in a class map configured for DNS traffic,
the ACE allows the configuration and DNS inspection fails. Workaround: Specify UDP as the
protocol in a class map configured for DNS traffic.
• CSCsv69769—When you configure an expect regex value, the ACE allows a space in the quoted
name of the value. Workaround: Do not use a space. Instead, use a search character (.*) or allow the
variable to be on a long string input.
• CSCsv74527, CSCsw82768—When DNS traffic runs consistently at more than 10000 CPS, proxy
entries are leaked on the standby ACE in a HA environment after approximately two hours. Proxy
entries are leaked and are not cleared on the standby ACE due to connection validation errors.
Workaround: None.
• CSCsv95254, CSCsv53112—When an IP address conflict occurs on a bridged VLAN, the ARP
manager may become unresponsive causing the ACE to generate a core dump. Workaround: Resolve
the IP conflict in your configuration.
• CSCsv98101—Although console and remote login access has failed to the ACE, traffic is still
passing. Workaround: Reboot the ACE to clear this condition.
• CSCsx14648, CSCsx08589—After the ACE takes a long time to boot with some errors on the
console or terminal, the Admin user behaves as a network-monitor user. After another reboot, the
ACE loads and the Admin user has Admin privileges, but the SSL-proxy configuration in the Admin
context has lost certificates. The Admin context includes several VIPs with the SSL-proxy
configuration and the configuration includes several contexts. Workaround: Define the VIPs in a
context other than the Admin context.
• CSCsw28313—If one client sends multiple, consecutive DHCP requests to the ACE, the ACE may
become unresponsive and generate a core dump file. Workaround: Block the DHCP requests by
configuring an access list.
• CSCsw81300—When you configure the ACE with the combination of HTTP inspection and an
HTTP load-balancing policy map with only a class-default class, server-connection reuse does not
allow traffic. Workaround: Change the class map in the HTTP load-balance policy map from a
class-default class map to a type HTTP load-balance class map.
• CSCsw97987—When you configure multiple class maps to a multi-match policy map and you send
traffic to a class map, if you delete and readd all of the other class maps, the traffic destined for the
remaining class map gets a hit when you try to readd it to the same policy map. Workaround: In a
multi-match policy map with more then one class map, do not delete and readd all class maps except
the class map where you are sending the traffic.
• CSCsw98274—When you add and remove the class map along with the SSL proxy from a
multi-match policy map multiple times, if you attempt to add a class map and then try to apply an
SSL proxy, the “Error: Called API encountered error” message occurs and the proxy is not applied
to the class map. Workaround: Do not add and remove the class map from a multi-match policy map
too quickly. If this situation continues, reboot the ACE.
• CSCsx14648—Crypto files may be deleted if high loads are created on the control plane, for
example, by copying and pasting a very large configuration. The control plane must be heavily
loaded for this issue to occur. Workaround: Copy and paste large configurations in small segments,
giving each segment time to load before moving to the next segment.
• CSCsx39224—When you configure a sticky server farm as part of a policy map and the real servers
are brought out of service making the server farm inactive, the backup server farm does not take the
connections after the primary server farm becomes inactive. Workaround: Configure the server farm
as part of the policy-map instead of the sticky server farm.
• CSCsx47594—When an SSL server does not use an RSA certificate and the ACE does not
determine that the certificate is not RSA, the ACE becomes unresponsive when there is SSL
back-end traffic with HTTPS probes. Workaround: Make sure that the SSL server uses an RSA
certificate.
• CSCsx63328, CSCsx13274—When the ACE SSL is at its peak performance, a leaked SSL context
state occurs that cannot be detected with show commands. Workaround: None.
• CSCsx72444—If you configure system logging over TCP to send messages to a server and the
server closes the connection because of a failure or a restart, the ACE close its own socket and
displays the following error message:
Monitor logging: enabled (level - information)
Logging to 192.168.1.11 tcp/5140
(socket created but failed to connect)
After the ACE closes the socket, it never tries to reopen it and no more messages are sent.
Workaround: Remove and readd the syslog host command configuration or use a syslog over UDP.
• CSCsx81954—If an HTTP request spans multiple packets, it is possible that the ACE will discard
the second packet, forcing the client to retransmit. The HTTP request must be large enough that it
is sent in more than one packet and the request is not the first one on a persistent connection. The
discarded packet causes a retransmission by the client and the ACE does not drop packets after the
retransmission. Workaround: None.
• CSCsx97484—When the ACE reboots with the primary server farm out of service, traffic does not
switch to the backup server farm. Workaround: Configure one real server under the primary server
that could trigger the failover again.
• CSCsy29490, CSCsv83236—When you configure the ACE with a sticky cookie and enable
persistence rebalance, the show serverfarm command displays connection entries after traffic has
stopped. Also, the connection entries do not clear correctly. Workaround: Disable persistence
rebalance or use another sticky type (for example, IP sticky).
• CSCsy34814—The syslog message 305010 includes the duration of the xlate translation. However,
this duration is always equal to the xlate idle timeout. Workaround: Use the timestamps in the
creation and the tear down of the xlate connections to calculate the xlate duration.
• CSCsy55274—When the ACE is running software version A2(2.0) with application inspection
configured, both network processors may generate core dump files. This issue may occur when the
inspection configuration is in an error-handling scenario with a missing NULL pointer check.
Workaround: None.
• CSCsz34011—After a series of reboots, both ACE modules lose their context configurations. If the
active ACE halts and reloads, after it reboots, it will read the first half of the startup-config file,
establish FT with the standby ACE (the new active), and synchronize the configuration to obtain the
rest of the configurations from the other ACE. If the other ACE stops functioning, the active ACE
will not have obtained the rest of the configurations, including context configurations. Context
configurations may be lost, although they still exist in the startup-config file. Workaround: None.
• CSCsz32455—When you enter the show tech-support command, it may fail with an error during
the execution of the show acl-merge merge vlan commands. Workaround: Enter the commands in
the show tech-support command manually.
• CSCsz69431—When the ACE is configured for redundancy and Route Health Injection (RHI) and
the FT VLAN goes up and down, the standby ACE may transition to a nonredundant state and
advertise its routes using RHI with the real interface IP address. Workaround: Configure an FT query
VLAN with a management policy and ACL that allow ICMP (pings).
• CSCsz69433—The FT VLAN may transition incorrectly to a nonredundant state if the interface
goes up and down. When the FT interface correctly transitions out of this nonredundant state, any
RHI routes are not withdrawn. Workaround: Configure an FT query VLAN with a management
policy and an ACL that allow ICMP (pings).
• CSCsz73222—After you apply a configuration where the logging server address does not match the
network address of any configured interface, the ACE may become unresponsive and generate a
network processor crash file that indicates an SRAM parity error. Workaround: Disable logging by
entering the no logging enable command or configure a server on a network that is local to the ACE.
• CSCsz77633—When the ACE is receiving Layer 7 traffic, it may discard Layer 4 sticky connection
requests on the same or on a different context because the ACE may incorrectly reset the connection
after traffic is sent for some duration. You should not encounter this issue with only Layer 4 traffic
or only Layer 7 traffic. The issue is seen only with the combination of the two types of traffic.
Workaround: None.
• CSCta01759—When an SSL certificate with a nonconforming serial number length is presented to
the ACE as part of the authentication mechanism, the ACE becomes unresponsive. Typically, CAs
do not issue certificates with a nonconforming serial number length. Workaround: Use only
conforming-length (up to a maximum of 20 bytes per RFC3280) serial numbers in SSL certificates.
• CSCta05557—If you dump verbose queue outputs using either the ucdump command on the
network processor console or at the CLI by using the show np 1 | 2 me-stats -q queue_name -vvv
command, the network processor may become unresponsive and unusable. This issue occurs
randomly depending on the content of the message. Specifically, the problem was seen when the
ACE dumped the verbose queue elements for the lbrx queue. However, it can happen to a few other
queues as well. Workaround: None.
• CSCta14111—The show service-policy command may not display all configured policies. The
command output has a limited size. If you exceed that size because of a large number of class maps
and match statements, the remaining information may not appear in the output. Workaround: None.
• CSCta15251—If you change the load-balancing predictor in a server farm to one of the hash
predictors while traffic is flowing and with two real servers that are configured as backup servers
for each other (cyclic backup servers), the ACE load-balancing queues eventually becomes full and
the ACE becomes unresponsive. Workaround: None.
• CSCta15196—The show service-policy detail command may display invalid port numbers if the
associated VIP has a configured port range. Workaround: None.
• CSCta26489—A user with a custom role that includes the rule number permit modify feature real
server command cannot change the real server configuration even though the real server is defined
as an object in this domain. When you try to configure the real server, you may see the message
“Error: cannot create new object; user has modify permissions only.” This problem has occurred in
A2(2.x) software, but not in A2(1.x) software. Workaround: Add the rule number permit create
feature rserver command to the user role.
• CSCta33566—When the set tcp timeout embryonic command is configured, the ACE may not
send RSTs at the time specified by the command. Retransmitted SYNs from the clients are not
received by the server because the retransmits are causing the embryonic connections to be reset.
Workaround: None.
• CSCta38648—The ACE reports a loss of particle buffers when you reconfigure a large number of
VIPs at the same time. The buffers are lost because they cannot find a place in the same system pool
intended to hold these buffers. Workaround: None.
• CSCta42712—If a real server is down, configuring a passdetect interval that is less than 30 seconds
can cause overlapping probes, which can lead to resource issues. This problem occurs because the
default half-open timeout for the TCP probe traffic is configured to be 30 seconds and cannot be
changed. Workaround: Configure a passdetect interval that is greater than or equal to 30 seconds.
• CSCta45580—When a large number of VIPs (greater than 50) use the same SSL proxy with a
certificate revocation list (CRL) applied and the CRL server is down when the ACE attempts to
download the CRL for the first time, the download fails as expected. When the CRL server comes
back up and the CRL is applied again, the ACE may not attempt to download the CRL again.
Workaround: Unconfigure and reconfigure the CRL.
• CSCta53777—When SSL traffic that requires client authentication enters the ACE, it may begin
leaking memory. If the real servers are brought down at the same time, the rate of the memory leak
increases until the ACE may eventually become unresponsive. Workaround: Reload the ACE to
reclaim the occupied memory and restart the system.
Workaround: Copy the files from debug or from the console after you modify the permissions using
debug.
• CSCso76159—When you dynamically modify a service policy to use an HTTP parameter map with
the header modify per request command, the ACE does not insert a header into every GET request
for existing long-lived persistent flows. However, the ACE does insert a header into every GET
request for new flows. Workaround: None.
• CSCso82657—While moving a VLAN from a Cisco Firewall Services Module (FWSM) to an ACE
or from an ACE to an FWSM, IP routing is not updated on the ACE to reflect the change. This
behavior occurs when you are making a change to the svclc commands and the shut and no shut
commands on the ACE interfaces. Workaround: None.
• CSCsq03035—The ACE was configured with an idle timeout of 0 (never time out), while TCP and
UDP traffic was sent and left in an idle state over an extended period of time. The idle timeout was
then changed from infinite to 60 seconds. The UDP traffic was immediately cleared, while the TCP
traffic was not. After waiting more than 15 minutes, the idle TCP flows still had not been cleared.
Workaround: None.
• CSCsq64401—If you configure the switch-mode command in an ACTIVE user context in a
redundant configuration, the command is not synchronized to the STANDBY_HOT user context on
the other ACE. This problem occurs only in a redundant configuration where an ACE has its Admin
context in the STANDBY_HOT state and a user context in the ACTIVE state.
There are two possible workarounds for this behavior as follows:
• Never allow a user context to be in the ACTIVE state on the standby ACE.
• Reload the ACE that has its user context in the STANDBY_HOT state.
• CSCsr01570, CSCsy90965—The Set-Cookie: length is null. Changing the default class-map from
a sticky-serverfarm to none does not eliminate a cookie insertion. Workaround: Remove and then
enter the class class-default command.
• CSCsu88684, CSCsq27062—When a large number of Layer 2 connected real servers are in the
ARP FAILED state and each real server is associated with probes, the ACE becomes unresponsive,
displays the following messages on the console, and eventually reboots:
mts_acquire_q_space() failing - no space in sap 516
sap=516 rq=102048 lq=0 pq=0 nq=0 sq=0 buf_in_transit=937, bytes_in_transit=82456
sap=1118 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=936, bytes_in_transit=145904
sap=514 rq=937 lq=0 pq=0 nq=0 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1084 rq=935 lq=0 pq=0 nq=1 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1025 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=102052, bytes_in_transit=9388784
The ACE reboots after the messages are displayed. Workaround: None.
• CSCsv09963—When you repeatedly add and remove VLANs on a context, the ACE loses memory.
Workaround: None.
• CSCsv31046—When you configure the least-connections predictor on the ACE, the ACE may not
sustain 160,000 CPS traffic. Workaround: None.
• CSCsv54222—When an HTTP client sends pipelined requests, if the next request comes in the
middle of the server response, the HTTP connection becomes unresponsive and data is missing on
the web page. Workaround: Configure a connection parameter-map with the set tcp
wan-optimization rtt 0 command.
• CSCsv92321, CSCsx25981—The ACE module reboots unexpectedly and writes a core file to disk.
Workaround: None.
• CSCsw40764—When the ACE executes the no access-list command to delete an ACL configured
with 64,000 entries, an API timeout occurs. Workaround: Do not delete all of these entries from an
ACL at one time. Delete the entries from an ACL one at a time or in small chunks.
• CSCsw51821—When you enable RTSP inspection on the ACE and the server sends the next request
without responding to the previous client request, a static parse error occurs and the packet is
dropped. Also if you configure RTSP inspection on the ACE, the ACE resets the connection.
Workaround: Make sure that the server responds to every client request with the proper return code
(for example, 200 OK) before sending the next request.
• CSCsx05150—When using 2048-bit certificate and key pairs with block and export ciphers, a
rehandshake may lead to stuck connections. Workaround: Either use nonblock and nonexport
ciphers or use certificate and key pairs that are less than 2048 bits.
• CSCsx13147—When you import a number of SSL PKI key or certificate files into a context by
using the crypto import command, if you remove the context without first removing the files
through the crypto delete command, the ACE may not import additional SSL PKI key or certificate
files. The failure is due to a lack of resources or during a subsequent file import process, some or all
of the previously imported key or certificate files may be forcibly removed from some or all
contexts. Workaround: Use the crypto delete command to explicitly delete the SSL PKI key or
certificate files from the contexts before removing the context. Try rebooting the ACE if this
problem has already happened.
• CSCsx19525—When you configure 1,000 SSL VIPs on the ACE and then you change the
configuration on those VIPs, a buffer leak occurs as displayed by the show np 1 me-stats command
“-scommon” output and traffic conditions. Workaround: Reboot the ACE and do not make
configuration changes that affects those VIPs.
• CSCsx28656—When you create a large configuration consisting of interfaces and ACLs in a
redundant configuration, if you remove a context from the active ACE, the context is not removed
from the standby and the standby ACE transitions to the Hot state even though configuration
synchronization failed. Workaround: Disable redundancy. Remove the configuration manually from
the standby ACE and then reenable redundancy.
• CSCsx37047—When you configure and unconfigure an object group on an ACE, it allows invalid
traffic and the acl-merge list becomes corrupted. Workaround: Remove and readd the access group
to the interface or globally.
• CSCsx38885—When the ACE contains a large configuration, if you quickly add and remove
multiple class maps under a Layer 7 policy map, API timeout errors occur. Workaround: Do not add
and remove class maps under a Layer 7 policy map in quick succession.
• CSCsx52128—When you copy a large configuration with many ACLs to the running-config file and
perform other configuration changes continuously, the aclmerged process does not get the CPU and
also the configurations result in API errors. Workaround: When you copy a large configuration with
many ACLs to the running-config file, wait approximately 2 minutes for it to complete. Do not
perform any configuration changes at that time.
• CSCsx80363—When the ACE uses a single IP source NAT with server connection reuse, PAT, and
a high rate of traffic of approximately 30,000 connections per second in a one-arm topology, it
reboots. Workaround: None.
• CSCsx80970—When you configure a multi-match policy map with more than one class map, if you
perform an inspect policy change in a class map, the traffic to other class maps may be hit.
Workaround: Do not make any inspect changes on the multi-match policy map when traffic is
running.
• CSCsx93137 and CSCsx93995—When you enter one of the following commands in any context
but do not complete entering the remote host password when prompted, the ACE waits for your
input:
– crypto import ftp | sftp | {bulk ftp}
– crypto export ftp | sftp
Then, if you enter one of the following commands, the session may appear to be in an unresponsive
state:
– crypto delete
– crypto export
– crypto generate csr
– crypto generate key
– crypto import
– crypto verify
– show crypto authgroup
– show crypto certificate
– show crypto chaingroup
– show crypto files
– show crypto key
After a while, the command aborts with a “SSL PKI subsystem is busy. Please try again later”
message. Reissuing the command results in the same behavior.
Workaround: Enter the remote host password as requested by the associated crypto import | export
command. If the problem persists, clear the relevant sessions by executing one of the following
commands:
– clear users
– clear telnet session_ID
– clear ssh session_ID
You can execute those commands if you have the appropriate privileges (for example, Admin). For
details about role-based access control (RBAC) and user roles, see the Cisco Application Control
Engine Module Virtualization Configuration Guide.
• CSCsy04371—When a server farm with no backup transitions to the Inactive state after all the real
servers transition to the MAXCONNS state, if the real servers transition out of the MAXCONNS
state, they may not accept connections. Workaround: Configure a backup to the server farm.
• CSCsy23268—The ACE may send probe traffic with the source IP address of the alias IP address
instead of the local interface IP address. This issue occurs on the active ACE only. Workaround:
None.
• CSCsy29181—If either of the DP processors is at MAXCONN, the ACE should show MAXCONN
in the show commands. However, the ACE waits until both DP processors are at MAXCONN. This
issue occurs when the cde-same-port-hash is configured. Workaround: None.
• CSCsy65650—When the ACE reports the termination of TCP flows, it may display incorrect values
for the duration and amount of data transferred. This issue occurs with HTTP and connections that
are terminated with TCP RST. Workaround: None. If accounting is needed and relies on this log, use
another method.
• CSCsy88379—The TAC diagnostic script showtech generates large output due to the show xlate
command. Workaround: None.
• CSCsy98701—The standby ACE generates a load-balancing core file when you configure two
ACEs as FT pairs that are replicating sticky entries and you enter certain show commands on the
active/master ACE. Workaround: None.
• CSCsz10107—When you configure preempt and the Catalyst 6500 with an active ACE module is
reloaded, the ACE may not correctly replicate connections when it reboots and becomes active
again. Some connections may get dropped. Workaround: None. This issue does not occur when
reloading only the ACE or if preempt is not configured.
• CSCsz14634—The ACE has issues when you copy large configurations from TFTP to the
running-configuration and use the snmp-server community command to add the public group
Network-Monitor to a context when the command was not in the original configuration.
Workaround: None.
• CSCsz18739—The ACE reloads when running software version A2(1.4) and RADIUS AAA is
configured. Workaround: None.
• CSCsz19849—You cannot import an ACE VIP in WAF. Importing works in software version
A2(1.2) and in A2(1.3). Workaround: None.
• CSCsz28035—Accessing the qnx shell from the physical console port of either NP on an ACE puts
you in a shell. If you type exit, the NP console hangs and becomes inaccessible. Workaround: None.
• CSCsz31739—When the VIP is out of service and loadbalance icmp-reply is not configured, the
virtual server entry still exists in the ARP cache. The ACE will respond to ARP requests sent for
this VIP. Workaround: None.
• CSCsz34933—The ACE may send a reset with the sequence number zero for a probe configured
with the connection term forced command. Workaround: Use the graceful termination no
connection term command.
• CSCsz40699—When you use the SLB-Admin, Server-Appln-Maintenance, or a custom role with a
create feature server farm rule and the real-inservice feature, you cannot bring real servers in or out
of service under the server farm. Workaround: None. There are currently no workarounds using
these specific roles. However, you can complete these tasks using the Admin role.
• CSCsz49088—When you monitor the ACE CPU, you can only monitor it using an Admin role. The
show system resources command is available only in the Admin role. The Network-Monitor role,
which should have access to all show commands is unable to access the show system resources
command. Configuring a new role on the ACE does not allow you to monitor the system feature.
Therefore, only Admin users are able to run this command. Workaround: Run the show system
resources command in an Admin role.
• CSCta20756, CSCsx15558—When the ACE has over 120,000 concurrent SSL connections, it
displays SSL connection rate denies, FastQ transmit back pressure, and SSL RX back pressure.
Eventually, the ACE becomes unresponsive. Workaround: None.
• CSCta83978—If you download an unusually large number of best-effort CRLs from a server, the
SSL process on the control plane may become unresponsive. Workaround: Do not use best-effort
CRLs.
• CSCta92673—When SSL traffic is flowing and you reconfigure SSL proxies that contain
authgroups, the ACE leaks memory in the control plane. The memory leak is directly proportional
to the number of reconfigurations that you perform. Workaround: Avoiding reconfiguring an SSL
proxy when an authgroup is applied to the proxy.
• CSCta92891—If you change the load-balance predictor from least conns to hash url with a mixed
traffic flow that consists of both TCP and UDP, the ACE may become unresponsive and generate a
loadBalance_g_ns core dump file. Workaround: None.
• CSCta93957—If you upgrade a redundant ACE pair to software version A2(2.1), downgrade the
standby to software version A2(1.4) and allow the pair to synchronize configurations, and then
upgrade the standby again to A2(2.1), the standby ACE does not lock configuration mode, allowing
you to make configuration mode changes. Workaround: Enable a bulk synchronization by entering
the no ft auto-sync command followed by the ft auto-sync command on the active ACE.
• CSCtb02056—When you configure the ACE with SSL certificates and keys in multiple contexts,
the output of the show crypto certificate all command may become corrupted. Workaround: Use
the show crypto certificate cert_name command instead of the show crypto certificate all
command.
Table 10 Field Descriptions for the show crypto crl crl_name detail Command
Field Description
URL URL where the ACE downloads the CRL.
Last Downloaded Last time the ACE downloaded the CRL. If the CRL is configured on an
SSL-proxy service on a policy map that is not active or the service is not
associated with a policy map, the field displays the “not downloaded yet”
message.
Total Number of Number of times the ACE attempted to download the CRL.
Download Attempts
Failed Download Numbers of times that the ACE failed to download the CRL.
Attempts
Successful Loads Number of times that the ACE successfully loaded the CRL.
Table 10 Field Descriptions for the show crypto crl crl_name detail Command (continued)
Field Description
Failed Loads Number of times that the ACE could not load the CRL because of a failure.
Hours since Last Load Number of hours that elapsed since the ACE last successfully downloaded
the CRL. If no successful download has occurred, this field displays NA,
not applicable.
No IP Addr Resolutions Number of times the DNS resolution for the server host address of CRL the
failed.
Host Timeouts Number of download retries to the CRL that had timed out.
Next Update Invalid Number of times that the next update field of the CRL was invalid.
Next Update Expired Number of times that the next update field of the CRL was expired.
Bad Signature Number of times that the signature mismatch for the CRL was detected,
with respect to the CA certificate configured for signature verification of
the CRL.
CRL Found-Failed to Number of times that the ACE could not load the CRL because of the
load maximum size limitation of 10MB on ACE or the formatting of the CRL
was not recognized. The ACE recognizes only DER and PEM encoded
CRLs.
File Not Found Number of times that the server responded that the CRL file was not found
at the server.
Memory Outage failures Number of times that the ACE failed to download the CRL because it
temporarily could not provide memory to store the CRL data.
Cache Limit failures Number of times that the ACE could not load the CRL because the CRL
cache was exhausted.
Conn Failures Number of times that the ACE failed to download the CRL because it could
not establish a connection with the server or no server entity was listening
on the destination system.
Internal Failures Number of internal failures in the ACE that hampered downloading the
CRL, for example, internal communication failures between components
responsible for the downloading the CRL.
Not Eligible for Number of times that the CRL was found ineligible for downloading
download because the following conditions:
• The downloading of the same CRL is in progress.
• The CRL has already been loaded successfully earlier and has not
expired yet.
HTTP Read Failures Number of times that the ACE encountered an error when downloading the
CRL because it could not read data on the connection established with
server.
HTTP Write failures Number of times that the ACE encountered an error when downloading the
CRL because it could not write the CRL download request from the
connection established with the server.
253011
Error Message %ACE-6-253011: The CRL crl_Name may not be from a trusted source.
Signature mismatch detected for CRL.
Explanation When the ACE performs signature verification on a CRL with a CA certificate
configured with the crypto crlparams command, it detects a signature mismatch. Either the CRL
(crl_name) download failed or the CRL has been removed from the ACE.
Recommended Action Verify the CRL configuration for the crypto crlparams command.
253004
Explanation This message is logged during the SSL handshake when client authentication is enabled.
The ACE determines that the client certificate has been revoked by the CA. The
subject_of_certificate variable is the subject field of the certificate. The proxy_name is the name of
the SSL proxy service. The reason is the reason for the revocation of the certificate and has one of
the following messages:
• revoked—The certificate is revoked by the CA.
• no workable cdps in cert—The certificate does not have a workable CRL distribution point
(CDP). A CDP indicates the location of the CRL in the form of a URL.
• crl download failure—The download of the CRL failed.
253008
Error Message %ACE-6-253008: CRL crl_name could not be retrieved, reason: reason
Explanation This message is logged when the ACE failed to retrieve a CRL. If you define CRL
checking for SSL client authentication, the ACE periodically retrieves a CRL. Due to a variety of
reasons, these attempts can occasionally fail. The crl_name variable is the name of the CRL as
defined by the crypto crl command. The reason variable is the reason for the CRL download failure.
and can be one of the following messages:
– DNS error
– host conn timeout
– memory outage
– crl max size limit violation
– crl cache full
– crl data/file not found
– invalid format of data
– crl signature mismatch
– next update field erroneous
– next update field expired
– internal error
– not okay to download
– http connection error
– http file read error
– http request writing error
– ldap bind error
– ldap search error
Recommended Action Check to see if there is a network connectivity problem or if the server location
of the CRL has changed.
Error Message %ACE-2-253012: Crypto file storage failure: All certificates/keys were
removed. Error: text_string
Explanation A system failure deleted the SSL services internal database of certificates and keys. The
text_string variable is either of the following:
• Corrupted certificates/keys metadata found
• Out of resources while trying to store certificates/keys metadata
Recommended Action Contact Cisco TAC and send them the message output. Reimport the certificates
and keys to maintain the integrity of the SSL services.
305010
305012
441001
Explanation A serverfarm failover event has occurred. The name variable is the name of the
serverfarm. The backup_name is the name of the backup serverfarm. The lb_Policy_Map is the name
of the load-balancing policy map. The count1 variable is the number of times that the primary
serverfarm failed over to the backup serverfarm. The count2 variable is the number of times that the
primary serverfarm returned to service.
441002
Explanation A serverfarm in service event has occurred. The name variable is the name of the
serverfarm. The lb_Policy_Map is the name of the load-balancing policy map. The count1 variable
is the number of times that the primary serverfarm failed over to the backup serverfarm. The count2
variable is the number of times that the primary serverfarm returned to service.
• CSCsq14440—The aclmerged process in the ACE may not complete or may exceed the available
system resources. With very large configurations where there are many ACLs, NAT statements, and
class maps, the processing of these elements can require a significant amount of time and internal
resources. In some cases, the processing (as displayed by the show proc cpu | include aclmerged
command) may become unresponsive and never complete. In other cases, the processing may
complete, but the output could exceed the resources available on the ACE, which may cause the ACE
to not function properly.
Workaround and recovery: Currently, there is no method to predict the aclmerged response.
However, in most cases, the commands eventually complete and the ACE continues to function
properly. The suggested workaround is to allow aclmerged to complete without any intervention,
assuming that there is no external impact to traffic. If the process does not complete or if there is a
significant disruption to traffic flow, then reboot your ACE. If you enter the write memory
command prior to the reboot, then the ACE attempts to come up in the post-change configuration.
This may allow the desired configuration to be applied properly after the reboot. If you do not enter
the write memory command before rebooting the ACE, then the ACE should reload and continue
to operate in the same manner as before the change.
• CSCsr22521—When you enter the show service command on the active ACE and enter the show
running-config interface | be command on the standby ACE, an “Error: API call timed out” error
message occurs. Workaround: None.
• CSCsr72591—When you need to import many SSL keys and certificates, it may take a long time
(approximately 30 minutes to import 1000 keys and certificates). You must import them one at a
time; there is no bulk import feature available. Workaround: None. See the “Bulk Importing of SSL
Certificates and Key Pair Files” section.
• CSCsu42225—When you configure the ACE with a Layer 4 load-balancing policy map and it
receives a series of UDP requests with a payload of 3,200 bytes that spans three nonfragmented
packets, the ACE drops two packets from the first request. For subsequent requests, the ACE load
balances all packets successfully. Workaround: None.
• CSCsv31394, CSCsm46044—When you modify the policy-map configuration on an interface, the
ACE occasionally records a service-policy download error. Workaround: None.
• CSCsv32122—When you configure approximately 8,000 match source-address statements, you can
see traffic drop for 10 to 20 seconds with a lockup of the console or terminal. Workaround: None.
• CSCsv33051—When you configure RADIUS load balancing and create a RADIUS-attribute sticky
group with the sticky radius framed-ip command, if the Framed-IP-Address is reused and load
balanced to a different rserver, the ACE may not update the sticky entry. Workaround: Configure the
RADIUS client to issue Framed-IP-Addresses and include them in the RADIUS access request
messages or configure separate Framed-IP-Address pools for each RADIUS real server.
• CSCsv52288—This enhancement allows the ACE to support 16,384 match source-address
statements entries. The previous limit was 8,192.
• CSCsv52887—The ACE may experience a short lockup period of the console or terminal when you
modify match source-address entries in a configuration with a large number of match source-address
statements under a high traffic load. Workaround: None.
• CSCsv56901—When you enable client authentication and a CRL on the ACE, the CRL applied to
the SSL proxy under traffic could cause a memory leak. Workaround: None.
• CSCsv56991—After removing the real server configuration on a server farm and reconfiguring a
real server with the same configuration, the connections may not get replicated. After one failover,
both active and standby ACEs are synchronized. But after another failover, the standby ACE is not
synchronized with the active ACE.
• CSCsv59066—When using KAL-AP to report the VIP address status, all VIPs with the same
addresses report a load of 255 if one is out of service. Workaround: Do not use KAL-AP to monitor
multiple VIPs with the same IP addresses.
• CSCsv61295—When you configure the ACE with SIP inspection, when the SIP message contains
the letters “tel” before the sip: information, packet drops occur. Workaround: None.
• CSCsv89746— In the ACE 2(1.2) release, the logging rate-limit command adds an extra “1” in the
running configuration which causes the command to function incorrectly. Workaround: Do not use
the logging rate-limit command.
• CSCsv94341— When you configure a class-default class map in a RADIUS policy map, RADIUS
accounting on or off packets are dropped. This behavior occurs due to an incorrect check on the
empty rule list. Workaround: Configure a class map other than the default traffic class in the
RADIUS policy map.
• CSCsw14149—Applying an ACL to an interface and then expanding it to 24,000 access control
elements takes over 9 hours. Workaround: None.
• CSCsw14181— When you apply an ACL with 24,000 access control elements to an interface and
then remove it, an “Error: Called API timed out” message occurs. Workaround: Remove the ACL
from the interface and then remove the ACL.
• CSCsw18441—When you enable the access-list debug errors, the ACL Hit count statistics are
displayed. Workaround: None.
• CSCsw18450—In a large configuration, deleting a class map from a policy that is applied on an
interface takes 10 minutes for one class map. The show commands return with failures and the
aclmerge process takes more than 90 percent of the CPU for more than 10 minutes. Workaround:
None.
• CSCsw18452—Adding a service policy under an interface takes more than 12 hours. The show
commands return with an “API call timed out” error and the aclmerge process takes more than
90 percent of the CPU for a long time. Workaround: None.
• CSCsw20096—Configuring the logging level does not work for some syslogs. The running-config
shows the updated value, but the actual syslog generation is based on the default level. Workaround:
Set the logging levels for the console and buffering based on the default levels of these syslogs.
• CSCsw28726—When the ACE is configured to insert the client source IP address into the back-end
HTTP header, it may intermittently insert an incorrect source IP address in the HTTP header.
Workaround: None.
• CSCsw29087—On rare occasions, the ACE drops RADIUS load-balanced traffic due to buffer
exhaustion. Layer-4 load-balanced traffic is unaffected. The ACE will be out of buffers on at least
one network processor, as indicated when the following counter increments:
show np [1|2] me-stats -socm
Drop [out of connections]: 96023 0
Workaround: Avoid importing files other than valid SSL key pairs and certificates. Avoid importing
large numbers of excessively large key pairs and certificates. Avoid exceeding the maximum
supported number of key pairs and certificates.
• CSCsw35954—If the ACE runs out of space on the secure storage area of the flash memory during
the execution of the crypto import command before it is rebooted, it may keep repeatedly rebooting
until you power it off or replace its flash storage card. Workaround: Reboot the ACE with a software
version that contains the A2(2.0) fix for this issue. If necessary, reboot the ACE again and boot it
back with the original image. If booting the ACE with a newer image is not an option, perform the
following steps:
a. Reboot the ACE with different software versions until you find one that successfully boots and
allows you to log in to the ACE.
b. Delete all crypto files using the crypto delete command.
c. Reboot ACE again and boot it back with the original image.
• CSCsw41402—Applying a packet capture may render the context unusable as the merged list on
the incoming interface is deleted. Workaround: None.
• CSCsw49482—When you or users enter a long-running SSL PKI command (for example, the
crypto generate or show crypto command) in the same or in a different context, if you press Ctrl-c
to abort it, the session may become unresponsive and various SSL PKI commands may fail
sporadically with surprising error messages or with an “Error: API timed out” message.
Previously-imported key or certificate files may disappear without any indication. Workaround: Do
not abort long-running SSL PKI commands by pressing Ctrl-c, or wait at least three minutes after
aborting one of these commands using Ctrl-c before entering another SSL PKI command.
• CSCsw52831 —If a RADIUS packet is the second packet on a UDP connection and it is received
shortly after the first RADIUS packet on the connection, it may be dropped. Workaround: None.
• CSCsw63921—When you configure the ACE with a Layer 7 rule and persistence rebalance, it does
not load balance a large Post packet correctly. The ACE sends half of the data to one server and the
second half to another server within the default class. The show http stats command displays static
parse errors. Workaround: Remove the persistent rebalance configuration.
• CSCsw69707—In earlier ACE releases, the set tcp buffer-share command was configurable only
for TCP connections. This command now applies to UDP connections. However, the CLI remains
unchanged.
• CSCsw71243—When you enter one of the following commands while another one from this list is
executing in the same or different context, the commands may spontaneously fail and may report an
unrelated error or no error at all:
– crypto delete
– crypto export
– crypto generate csr
– crypto generate key
– crypto import
– crypto verify
– show crypto authgroup
– show crypto certificate
– show crypto chaingroup
– show crypto files
– show crypto key
This problem may cause all of the key pair or certificate files that were previously imported or user
generated to disappear from the ACE either immediately or after the first reboot. Workaround: Do
not enter more than one command from the above list simultaneously on the ACE, not just
context-wide.
• CSCsw75536—The ACE may stop splicing TCP sequence numbers between the front-end and
back-end connections of a load-balanced connection. Initially the connection may operate with
several successful HTTP transactions. However, the connection may eventually fail due to the ACE
sending the TCP sequence numbers from the front-end connection to the back-end real server.
Workaround: None.
• CSCsw77807—SIP probes with random Call-IDs and From-Tags in the SIP options may fail with
the Cisco Session Border Controller (SBC). The SBC responds with a SIP “482 Loop Detected”
message because the same Call-Id and From-Tag are used in all requests. Workaround: Do not use
SIP probes with Cisco SBC.
• CSCsw83500—The show conn protocol tcp | inc CLSRST command displays a large number of
connections. Workaround: Enter the clear flow command for all flows in the CLSRST state to free
the buffers.
• CSCsw99769—Under some conditions with the A2(1.2) and A2(1.3) releases, when some QNX
processes (such as ssl_Hs) receive an abort signal, the ACE may not create a set of core files and
does not reboot. Instead, the ACE may become unresponsive and the core files may be incomplete
or nonexistent. The behavior is different between NP1 and NP2. Workaround: Manually reboot the
ACE.
• CSCsx01630—If the ACE is configured with multiple service policies for an interface, deleting a
service policy can cause Layer 7 connections to reset in other service policies. Workaround: None.
• CSCsx03110—When a service policy id applied globally on several interfaces and the ssl-proxy
command is applied to the policy, the traffic is not SSL offloaded and is forwarded as if there is no
SSL proxy configured. Workaround: Apply the service policy locally on the relevant interfaces.
• CSCsx11078— Whenever you import PKI key or certificate files and then delete them, a memory
leak occurs on the ACE. Workaround: None.
• CSCsx11478—When a large number of certificates and keys are imported to the ACE, SSL-related
configurations are lost after the ACE reboots. The ACE displays the following error messages:
`crypto crl test1 http://10.7.107.68/crl1` *** Context 0: cmd exec error ***
Workaround: None.
• CSCsx19410—When a service policy is applied globally and SSL traffic is load balanced through
an interface, if you remove another interface, the active interface drops the SSL traffic and no load
balancing is performed. Workaround: Apply the service policy locally on the relevant interface.
Then, reconfigure the interface that was removed.
• CSCsx25224—During a large VIP test, ipcp stall messages occur continuously with traffic. These
messages cause the IPCP Q to stall for the cfgmgr. The cfgmgr enters the Suspend state and all of
the tasks related to cfgmgr will become unresponsive.Workaround: None.
• CSCsx26856—The ACE becomes unresponsive when reconfigurations are performed on a large
number of VIPs (up to 1,500). Workaround: Avoid frequent reconfigurations of a large number of
VIPs. Do not use CRLs with VIPs.
• CSCsx33084—When you configure the ACE with a front-end SSL termination proxy that includes
client authentication and session reuse, refreshing a page in a Firefox, Netscape, or Opera browser
does not work and the page fails to load in the browser.
• CSCsx33515—The ACE becomes unresponsive when you apply a chain group to a large number of
VIPs (up to 1,500) and then change the chain group. Workaround: None.
• CSCsx61234—When the ACE imports a certificate or key pair with a filename of 40 characters and
a passphrase of any valid length, it is not displayed through the show crypto files command and is
not usable. Workaround: Reduce the filename to 39 characters and the problem does not occur.
• CSCsy03713—When the ACE reboots and the primary server farm is out of service, traffic does not
switch to the backup server farm. Workaround: Configure a real server under the primary server farm
that could trigger the failover again.
This behavior rarely occurs, but once it does, the behavior will continue every time that you enter
the show module command. The ACE continues to forward traffic normally. This is a display
problem only. Workaround: Reboot the ACE.
• CSCsl46334—When a high rate of Layer 7 load-balanced traffic is flowing in multiple contexts or
a high rate of Layer 7 traffic with server connection reuse is configured, the ACE may start dropping
traffic after a few hours. Workaround: None.
• CSCsl64911—The behavior of HTTPS probes in nonrouted mode is the same as that of the probes
in routed mode (the inclusion of the routed option with the ip address command). For example:
probe https https1
ip address 10.76.248.141
interval 10
passdetect interval 10
Workaround: None.
• CSCsl68531—In bridge mode, a real server in a transparent server farm may stop accepting
connections after another real server in the same server farm fails probe health checks. Workaround:
None.
• CSCsl75662—You may observe that ACE health probes remain in the INIT state when you change
a parameter that is associated with the probe; the configuration change takes effect only after the
next time that the probe is sent even though the configuration change is visible in the
running-configuration file. This behavior may be most visible when you change a probe with a high
time interval (for example, 65535 seconds) to a much lower interval (for example, 2 seconds). In
this configuration, it may appear as if the probe fails to fire; the initial large time interval has to
expire before the new, smaller interval can take effect.
Workaround: For a probe parameter change to take immediate effect, perform the following
procedure:
1. Remove the probe from the real server and the server farm.
2. Modify the probe parameter that you want to change.
3. Readd the probe to the real server and the server farm.
For details, see the Cisco Application Control Engine Module Server Load-Balancing Configuration
Guide.
• CSCsm72725—The packet capture output of one context may appear in other (different) user
contexts. This behavior may occur when you use a terminal to configure the packet capture function
in a context and then specify the changeto command to switch to a different context using the same
terminal.
Workaround: Perform either of the following actions:
– Stop the packet capture process before you enter the changeto command (the recommended
workaround).
– Log out of the terminal, and then log in again to access a different context than the original
context with the configured packet capture function.
• CSCsm93110—When you configure Microsoft Internet Information Services (IIS) version 5.0 to
accept client certificates, SSL initiation through the ACE may fail. Workaround: Upgrade to IIS
version 6.0.
• CSCso33506—In a redundant configuration with the FT pair running mismatched code (A1(x) and
A2(x)) and mismatched licenses, if the active ACE is rebooted, the Admin context comes up, but, in
user contexts, the running-config file is blank. This behavior occurs only when there is both a license
and a code mismatch. Workaround: Resolve one of the mismatches and reload the ACEs or enter the
copy start run command in each user context.
• CSCso38853—After four consecutive Route Processor Redundancy (RPR) failovers in the Catalyst
6500 series switch, the primary and standby ACEs may enter the Active-Active state. This state is
not resolved until you reload the primary ACE. Workaround: None.
• CSCso55790—While trying to copy core dump files from the core: directory to an FTP server, the
copy operation failed with the following permission denied error message:
local: /TN-COREFILE/core.618: Permission denied
Workaround: Copy the files from debug or from the console after you modify the permissions using
debug.
• CSCso60304—When an invalid XML attribute is sent to the ACE, it does not respond as expected.
Instead, the ACE displays a 500 Internal Server Error message. No negative impact to the ACE is
observed. Workaround: None.
• CSCso76159—When you dynamically modify a service policy to use an HTTP parameter map with
the header modify per request command, the ACE does not insert a header into every GET request
for existing long-lived persistent flows. However, the ACE does insert a header into every GET
request for new flows. Workaround: None.
• CSCso80478—When you perform multiple parallel SNMP walks that last 30 seconds or longer on
an ACE in a redundant configuration, you may observe response timeouts on both the active and the
standby ACEs. You may also observe this behavior in multiple contexts. This behavior does not
occur with SNMP walks of shorter durations. Workaround: None.
• CSCso81785—If you are using TACACS+ and the Cisco Access Control Server (ACS) with an RSA
authentication manager, you may receive the Login Incorrect message when you try to log in to the
ACE with an account that requires a new PIN even if you use the correct credentials. Workaround:
Log in to another network access server (NAS) to set your PIN.
• CSCso81811—If you are using TACACS+ and the Cisco ACS with an RSA authentication manager
and your account is in next token mode, you may receive the Login Incorrect message when you try
to log in to the ACE with an account that requires a new PIN even if you use the correct credentials.
Workaround: Log in to another NAS to enter the next token code and make your account accessible
again.
• CSCso82657—While moving a VLAN from a Cisco Firewall Services Module (FWSM) to an ACE
or from an ACE to an FWSM, IP routing is not updated on the ACE to reflect the change. You can
observe this behavior when making a change to the svclc commands and the shut and no shut
commands on interfaces on the ACE. Workaround: None.
• CSCso82971—If you are using a TACACS+ server that is an RSA server with TACACS+ continue
authentication, authentication may fail to the configured server, but you still can log in using local
authentication.
Use one of the following workarounds:
• Use the Cisco ACS instead of the RSA server.
• Do not configure local as the secondary authentication method.
• CSCso85639—If you configure the passdetect interval command value for less than 30 seconds,
the ACE sends overlapping probes that use additional management connections (resources).
Workaround: Increase the passdetect interval command value to 45 seconds.
• CSCso86485—When a client-side VLAN interface is brought up and down an excessive number of
times on the active ACE under a light traffic load, the standby ACE may generate a core dump.
Workaround: None.
• CSCso95457—When you enter the clear conn all command, the ACE sends an RST to close the
connection only to the server and purges both the inbound and outbound connection entries from its
connection database. As a result, the client connection is left open and any further requests arriving
on that connection are not serviced. Workaround: None.
• CSCso95620—With long-lived HTTP, SSL, FTP and UDP traffic on the ACE, you may observe a
memory loss of approximately 333 KB in the ACE during an EtherChannel link (FT port channel)
failure and recovery on the Catalyst 6500 series switch. Workaround: None.
• CSCsq03035—The ACE was configured with an idle timeout of 0 (never time out), while TCP and
UDP traffic was sent and left in an idle state over an extended period of time. The idle timeout was
then changed from infinite to 60 seconds. The UDP traffic was immediately cleared, while the TCP
traffic was not. After waiting more than 15 minutes, the idle TCP flows still had not been cleared.
Workaround: None.
• CSCsq23701—After an FT VLAN failure, which resulted in an Active/Active FT state, has been
resolved, the ACE with the higher priority should take over as the active ACE (even though the
preempt command is disabled) through the election process, but did not. Workaround: Enter the
preempt command.
• CSCsq27062—After toggling the state of the FT port channel in the Catalyst 6500 series switch
110 times, the primary ACE module generated a core dump and reloaded. Workaround: None.
• CSCsu80235—When you configure stickiness on a context and the sticky database lookup is 8,192
over the maximum threshold, the ACE drops connections causing the users to experience resets or
their pages do not load properly. The Drop Max Remote Stky counter displayed by the show np [1
| 2] me-stats -slb command continues to increase. Workaround: Force a failover to the backup ACE
and reboot the module that had the problem.
• CSCsu86606—When you reboot the ACE and as it powers up, the Catalyst 6500 series switch
disables the ACE and displays the following log messages:
Oct 1 07:43:25.710 EDT: %C6KPWR-SP-4-DISABLED: power to module in slot 1 set off
(Reset)
Oct 1 07:43:41.611 EDT: %OIR-SP-6-PWRFAILURE: Module 1 is being disabled due to power
convertor failure 0x1
Workaround: None.
• CSCsu88684—When a large number of Layer 2 connected real servers are in the ARP FAILED state
and each real server is associated with probes, the ACE becomes unresponsive, displays the
following messages on the console, and eventually reboots:
mts_acquire_q_space() failing - no space in sap 516
sap=516 rq=102048 lq=0 pq=0 nq=0 sq=0 buf_in_transit=937, bytes_in_transit=82456
sap=1118 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=936, bytes_in_transit=145904
sap=514 rq=937 lq=0 pq=0 nq=0 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1084 rq=935 lq=0 pq=0 nq=1 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1025 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=102052, bytes_in_transit=9388784
The ACE rejects the ssl-proxy command and the command does not appear in the configuration.
Workaround: None.
• CSCsv02360—When you configure the ACE with SSL termination and server connection reuse,
and a client makes an HTTPS request to the VIP address, some connections fail if the client MTU
is low (for example, an MTU of 576). Workaround: None.
• CSCsv04319—If you create a TACACS+ server with a numeric key, the ACE sends a warning about
the key; however, it does not create the server. The message should be an error and not a warning.
Workaround: Use a key that is not entirely numeric.
• CSCsv04848—When you configure RADIUS on the ACE and a user logs off, the RADIUS client
sends an accounting stop message to the server for that user but the ACE does not immediately delete
all connections for that user. If the source IP address for the user is immediately reassigned to
another user, the new user could open a new connection before the old connections from previous
user times out. The result is that the ACE incorrectly forwards the new connections and does not
load balance the packets. Workaround: Set the UDP connection timer to a smaller number (for
example, 10 seconds).
• CSCsv09963—When you repeatedly add and remove VLANs on a context, the ACE loses memory.
Workaround: None.
• CSCsv10547—The config-register setting does not synchronize after an ACE module boots. The
config-register setting synchronizes only when you configure it with ACE modules in active or
standby mode. Workaround: None.
• CSCsv31046—When you configure the least-connections predictor on the ACE, the ACE may not
sustain 160,000 CPS traffic. Workaround: None.
• CSCsv31476—When the ACE generates a core-dump file for the kernel or Virtual Shell (VSH)
applications, the file does not contain the code-train version information. Workaround: None.
• CSCsv47724—The heartbeats on fault-tolerant (FT) ACE modules occasionally miss due to late
TCP timers. The FT ACEs increment the Heartbeats Missed counter on the standby ACE and the
Unidirectional HB’s Received counter on the active ACE. Workaround: None.
• CSCsv48498—When you enable FTP inspection and disable normalization on the client-side
interface, the ACE inserts the TCP Option Timestamp in packets to the client and the FTP server,
even if both the client and the server are not using this option. Workaround: Enable normalization
or disable FTP inspection.
• CSCsv49518—The ACE becomes unresponsive due to the ICM being stuck at 100 percent in the
proxy_connection_stack_lock state. Workaround: None.
• CSCsv49606—When you configure stickiness on the ACE, the ACE becomes unresponsive.
Workaround: None.
• CSCsv52331—The ACE becomes unresponsive due to an SRAM parity error. Workaround: None.
• CSCsv52478—When you reboot the Catalyst 6500 series chassis, the ACE may reboot as Active.
Workaround: None.
• CSCsv53112—When you enter the show xlate command, the ACE may generate a core dump.
Workaround: None.
• CSCsv53187—The ACE generates an NP ha_hb_g_ns core dump during a standard operation.
Workaround: None.
• CSCsv53620—When you add an SSL proxy class to a policy map, the following error occurs:
Error: Called API encountered error
Workaround: Remove the class from the policy map and then readd it.
• CSCsv65178—When you specify TCP as the protocol in a class map configured for DNS traffic,
the ACE allows the configuration and DNS inspection fails. Workaround: Specify UDP as the
protocol in a class map configured for DNS traffic.
• CSCsv69769—When you configure an expect regex value, the ACE allows a space in the quoted
name of the value. Workaround: Do not use a space. Instead, use a search character (.*) or allow the
variable to be on a long string input.
• CSCsv95254—When an IP address conflict occurs on a bridged VLAN, the ARP manager may
become unresponsive causing the ACE to generate a core dump. Workaround: None.
• CSCsw40764—When the ACE executes the no access-list command to delete an ACL configured
with 64,000 entries, API timeout occurs. Workaround: Do not delete all of these entries from an ACL
at one time. Delete the entries from an ACL one at a time or in small chunks.
• CSCsw81300—When you configure the ACE with the combination of HTTP inspection, HTTP
load-balance policy map with only a class-default class, server-connection reuse does not allow
traffic. Workaround: Change the class map in the HTTP load-balance policy map from a
class-default class map to a type HTTP load-balance class map.
• CSCsw82768—When the ACE runs end-to-end SSL traffic at a rate of 1,000 to 2,000 TPS, proxy
entries may leak on the standby ACE. Workaround: None.
• CSCsw97987—When you configure multiple class maps to a multi-match policy map and you send
traffic to a class map, if you delete and readd all of the other class maps, the traffic destined for the
remaining class map gets a hit when you try to readd it to the same policy map. Workaround: In a
multi-match policy map with more then one class map, do not delete and readd all class maps except
the one where you are sending the traffic.
• CSCsw98274—When you add and remove the class map along with the SSL proxy from a
multi-match policy map multiple times, if you attempt to add a class map and then try to apply an
SSL proxy, the “Error: Called API encountered error” message occurs and the proxy is not applied
to the class map. Workaround: Do not add and remove the class map from a multi-match policy map
too quickly. If this situation continues, reboot the ACE.
• CSCsx05150—When using 2048-bit certificate and key pairs with block and export ciphers, a
rehandshake may lead to stuck connections. Workaround: Either use nonblock and nonexport
ciphers or use certificate and key pairs that are less than 2048 bits.
• CSCsx08589—After the ACE takes a long time to boot with some errors on the console or terminal,
the Admin user behaves as a network-monitor user. After another reboot, the ACE loads and the
Admin user has Admin privileges but the SSL-proxy configuration in the Admin context has lost
certificates. The Admin context includes several VIPs with the SSL-proxy configuration and the
configuration includes several contexts. Workaround: Define the VIPs in a context other than the
Admin context.
• CSCsx11453—When you remove and apply a service policy several times on the client VLAN
while traffic is running on the ACE, the ACE becomes unresponsive. Workaround: Do not change
the service policy while traffic is running on the ACE.
• CSCsx13061—When you perform a checkpoint rollback in a specific order or execute a match and
no match statement under a class map, ACL memory is leaked and some entries configured in the
ACL are not removed from the interface. Workaround: Remove the interface and readd it.
• CSCsx13147—When you import a number of SSL PKI key or certificate files into a context by
using the crypto import command, if you remove the context without first removing the files
through the crypto delete command, the ACE may not import additional SSL PKI key or certificate
files stating that the failure is due to a lack of resources or, during a subsequent files import process,
some or all of the previously-imported key or certificate files may be forcibly removed from some
or all contexts. These symptoms disappear after you reboot the ACE. Workaround: Use the crypto
delete command to explicitly delete the SSL PKI key or certificate files from contexts before
removing the context. Rebooting the ACE also alleviates this problem if it has already happened.
• CSCsx13274—When the ACE SSL is at peak performance, a leaked SSL context state occurs that
cannot be detected with show commands. Workaround: None.
• CSCsx19525—When you configure 1,000 SSL VIPs on the ACE and then you change the
configuration on those VIPs, a buffer leak occurs as displayed by the show np 1 me-stats command
“-scommon” output and traffic conditions. Workaround: Reboot the ACE and do not make
configuration changes that affects those VIPs.
• CSCsx24893—When you update a 1,500 VIPs, a change in one context affects traffic in another
context. Workaround: None.
• CSCsx27063—When you apply rules with more than 100,000 elements on an interface, the show
acl-merge and show np 1 commands show that the rules are still applied after crossing the
100,000 limit per interface. Workaround: None.
• CSCsx28587—When the maximum aclmerge instance limit of 8191 is reached and then freed, ACL
merge will not occur. Also, after reaching the maximum limit of instances, if you remove the
outbound ACL from the interface, the policy action nodes are not released. Workaround: None.
• CSCsx28656—When you create a large configuration consisting of interfaces and ACLs in a
redundant configuration, if you remove a context from the active ACE, the context is not removed
from the standby and the standby ACE transitions to the Hot state even though config-sync failed.
Workaround: Place redundancy out of service. Remove the configuration manually from the standby
ACE and place redundancy in service.
• CSCsx37047—When you configure and unconfigure an object group on an ACE, it allows invalid
traffic and the acl-merge list becomes corrupted. Workaround: Remove and readd the access group
to the interface or globally.
• CSCsx38885—When the ACE contains a large configuration, if you quickly add and remove
multiple class maps under a Layer 7 policy map, API timeout errors occur. Workaround: Do not add
and remove class maps under a Layer 7 policy map in quick succession.
• CSCsx41858—When you configure redundancy on the ACE and it reboots, IP connectivity to and
from the ACE fails. For example, if you Telnet or ping to or from the ACE, it fails. All the interfaces
are down for the following reason:
VLAN not assigned from the supervisor
Workaround: Reconfigure the VLANs and the svclc module number vlan-group number command
on the supervisor engine.
• CSCsx47594—When an SSL server does not use an RSA certificate and the ACE does not
determine that the certificate is not RSA, the ACE becomes unresponsive under SSL backend traffic
including the HTTPS probes. Workaround: Make sure that the SSL server uses an RSA certificate.
• CSCsx52128—When you copy a large configuration with a lot of ACLs to the running-config file
and perform other configuration changes continuously, the aclmerged process does not get the CPU
and also the configurations result in API errors. Workaround: When you copy a large configuration
with a lot of ACLs to the running-config file, wait approximately 2 minutes for it to complete. Do
not perform any configuration changes at that time.
• CSCsx55228—When you remove an entry with an object group from an ACL which is associated
as global access group and then readd it, merge errors occur and nonallowed traffic goes through the
ACE. Workaround: Unconfigure and then reconfigure the access group.
• CSCsx62330—When you configure one or more contexts with an SSL configuration and HTTPS
probes, if you import 2,000 or more certificates and keys and then reboot the ACE, the probes fail.
The problem does not occur if you do not reboot the ACE after the configuration. Workaround: If
possible, reduce the number of certificates and keys to below 2,000 and then reboot the ACE.
• CSCsx80363—When the ACE uses a single IP source NAT with server connection reuse, PAT, and
a high rate of traffic of approximately 30,000 connections per second in a one-arm topology, it
reboots. Workaround: None.
• CSCsx80970—When you configure a multi-match policy map with more than one class map, if you
perform an inspect policy change in a class map, the traffic to other class maps may be hit.
Workaround: Do not make any inspect changes on the multi-match policy map when traffic is
running.
• CSCsx93137 and CSCsx93995—When you enter one of the following commands in any context
but do not complete entering the remote host password when prompted, the ACE waits for your
input:
– crypto import ftp | sftp | {bulk ftp}
– crypto export ftp | sftp
Then, if you enter one of the following commands, the session may appear to be in an unresponsive
state:
– crypto delete
– crypto export
– crypto generate csr
– crypto generate key
– crypto import
– crypto verify
– show crypto authgroup
– show crypto certificate
– show crypto chaingroup
– show crypto files
– show crypto key
After a while, the command aborts with a “SSL PKI subsystem is busy. Please try again later”
message. Reissuing the command results in the same behavior.
Workaround: Enter the remote host password as requested by the associated crypto import | export
command. If the problem persists, clear the relevant sessions by executing one of the following
commands:
– clear users
– clear telnet session_ID
– clear ssh session_ID
You can execute those command if you have the appropriate privileges (for example, Admin). For
details about role-based access control (RBAC) and user roles, see the Cisco Application Control
Engine Module Virtualization Configuration Guide.
• CSCsy04371—When a server farm with no backup transitions to the Inactive state after all the real
servers transition to the MAXCONNS state, if the real servers transitions out of the MAXCONNS
state, they may not accept connections. Workaround: Configure a backup to the server farm.
• CSCsz87249—The following log messages may appear sporadically in the ACE log:
– “can_wait_specific_msg: Aborting call (SAP 27, pid 959). Another thread is also waiting for a
specific msg”
– “can_wait_specific_msg: Aborting call (SAP 27, pid 905). Another thread is also waiting for a
specific msg”
These messages do not impact the operation of the ACE. The messages may be caused by more than
one device that is accessing the ACE context through XML. Workaround: None.
Exec show kalap udp load {all | vip tag name} The new vip tag keyword displays the latest load information
for the specified VIP tag name.
The all keyword now displays information for all VIP tags. For
more information on this command, see the “Displaying the
Load Information for a VIP KAL-AP Tag” section.
Note You can access the license and show license commands only in the Admin context. You must have the
Admin role in the Admin context to perform the tasks of installing, removing, and updating the license.
Step 1 Order one of the licenses from the list in the “Available ACE Licenses” section using any of the available
Cisco ordering tools on Cisco.com.
Step 2 When you receive the Software License Claim Certificate from Cisco, follow the instructions that direct
you to the cisco.com website. As a registered user of cisco.com, go to this URL:
http://www.cisco.com/go/license
Step 3 Enter the Product Authorization Key (PAK) number found on the license certificate as your proof of
purchase.
Step 4 Provide all the requested information to generate a license key.
Step 5 After the system generates the license key, you will receive a license key e-mail with an attached license
file and installation instructions. Save the license key e-mail in a safe place in case you need it in the
future (for example, to transfer the license to another ACE).
For information about installing and managing ACE licenses, refer to Chapter 3, Managing ACE
Software Licenses, in the Cisco Application Control Engine Module Administration Guide.
Note To upgrade your ACE software to version A2(1.0) or higher, your ACE must be running software version
3.0(0)A1(5a) or higher.
An incompatibility exists between certain ACE software versions in the 3.0(0)A1.6.3x and A2.1x release
trains. In a redundant configuration, the FT ACE pairs will not recognize each other and will report the
following status as part of the show ft peer detail command output:
SRG Compatibility: INCOMPATIBLE
The following software version combinations that are indicated with an “x” are incompatible:
Before you upgrade your ACE software, be sure that your ACE configurations meet the upgrade
prerequisites in the following sections:
• Changing the Admin Password
• Changing the www User Password
Creating a Checkpoint
We strongly recommend that you create a checkpoint in the running-configuration file of each context
in your ACE. A checkpoint creates a snapshot of your configuration that you can later roll back to in
case a problem occurs with an upgrade and you want to downgrade the software to a previous release.
Use the checkpoint create command in Exec mode in each context for which you want to create a
configuration checkpoint and name the checkpoint. For details about creating a checkpoint and rolling
back a configuration, see Cisco Application Control Engine Module Administration Guide. For
information about downgrading your ACE, see the “Downgrading Your ACE Software from Version
A2(1.0) or Higher to 3.0(0)A1(6.x) in a Redundant Configuration” section.
The following examples show some of the generic class-map match statements and an ACL that are not
allowed in A2(1.0) or higher inspection configurations:
• match port tcp any
• match port udp any
• match port tcp range 0 65535
• match port udp range 0 65535
• match virtual-address 192.168.12.15 255.255.255.0 any
• match virtual-address 192.168.12.15 255.255.255.0 tcp any
• access-list acl1 line 10 extended permit ip any any
For application protocol inspection, the class map must have a specific protocol (related to the inspection
type) configured and a specific port or range of port numbers.
For HTTP, FTP, RTSP, Skinny, and ILS protocol inspection, the class map must have TCP as the
configured protocol and a specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port tcp eq www
For SIP protocol inspection, the class map must have TCP or UDP as the configured protocol and a
specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port tcp eq 124
or
host1/Admin(config-cmap)# match port udp eq 135
For DNS inspection, the class map must have UDP as the configured protocol and a specific port or range
of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port udp eq domain
For ICMP protocol inspection, the class map must have ICMP as the configured protocol. For example,
enter the following commands:
host1/Admin(config)# access-list ACL1 extended permit icmp 192.168.12.15 255.255.255.0
192.168.16.25 255.255.255.0 echo
Downgrade Procedure
To downgrade your A2(1.0) or higher software in a redundant configuration, perform the following
steps:
Step 1 If you have created checkpoints in your 3.0(0)A1(6.x) running-configuration files (highly
recommended), roll back the configuration in each context on each ACE to the check-pointed
configuration. For example:
host1/Admin# checkpoint rollback CHECKPOINT_ADMIN
host1/Admin# changeto C1
host1/C1# checkpoint rollback CHECKPOINT_C1
Do the same on the other ACE. For information about creating checkpoints and rolling back
configurations, see Chapter 4, Managing the ACE Software.
Step 2 Configure ACE-1 to automatically boot from the 3.0(0)A1(6.x) image. To set the boot variable and
configuration register to 1, use the boot system image: and config-register commands in configuration
mode. For example, enter the following command:
host1/Admin# config
host1/Admin(config)# boot system image:c6ace-t1k9-mzg.3.0.0_A1_6_3.bin
host1/Admin(config)# config-register 1
host1/Admin(config)# exit
host1/Admin#
You can set up to two images through the boot system command. If the first image fails, the ACE tries
to boot from the second image.
Note Use the no boot system image: command to remove the configured A2(1.x) or higher boot
variable.
Step 3 Verify that the boot variable was synchronized to ACE-2 by entering the following command on ACE-2:
host1/Admin# show bootvar
BOOT variable = “disk0:c6ace-t1k9-mzg.3.0.0_A1_6_3.bin”
Configuration register is 0x1
host1/Admin#
Step 4 Use the show ft group detail command to verify the state of each module. Upgrade the ACE that has its
Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command.When
ACE-2 loads the startup-configuration file, you may observe a few errors if you did not roll back the
configuration to a checkpoint. These errors are harmless and occur because the 3.0(0)A1(6.x) software
does not recognize the A2(1.x) or higher commands in the startup-configuration file. After ACE-2 boots
up, it may take a few minutes to reach the STANDBY_HOT state again. At this time, configuration
synchronization is disabled, but the connections through ACE-1 are still being replicated to ACE-2.
host1/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 5 Perform a graceful failover of all contexts from ACE-1 to ACE-2 by entering the ft switchover all
command in Exec mode on ACE-1. ACE-2 becomes the new active ACE and assumes mastership of all
active connections with no interruption to existing connections.
host1/Admin# ft switchover all
Step 6 Reload ACE-1 with the same 3.0(0)A1(6.x) software version as ACE-2. Again, you may observe a few
errors as ACE-1 loads the startup-configuration file.
host1/Admin# reload
After ACE-1 boots up, it assumes the role of standby and enters the STANDBY_HOT state (this may
take several minutes). You can verify the states of both ACEs by entering the show ft group detail
command in Exec mode. Because both ACE-1 and ACE-2 are running the same version of software now,
configuration mode is enabled. The configuration is synchronized from ACE 2 (currently active) to
ACE-1. If ACE-1 is configured with a higher priority and preempt is configured on the FT group, ACE-1
reasserts mastership after it has received all configuration and state information from ACE-2, making
ACE-2 the new standby. ACE-1 becomes the active ACE once again.
Step 7 Perform manual cleanup in the running-configuration files of both ACEs to remove unnecessary version
A2(1.0) or higher configuration elements. For example, you may need to remove a service policy from
an interface that was part of the version A2(1.x) or higher configuration that is no longer needed in
version 3.0(0)A1(6.x).
Step 8 Enter the write memory all command in both ACEs to save the running-configuration files in all
configured contexts to their respective startup-configuration files. This action will eliminate future errors
when the ACEs reload their startup-configuration files.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase,
Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good,
Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks;
Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card,
and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA,
CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus,
Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast,
EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream,
Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV,
PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0910R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and
figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and
coincidental.