Table Of Contents
Release Note for the Cisco 4700 Series Application Control Engine Appliance
Contents
New Software Features and Enhancements in A3(2.7)
Probing a Redirect Server
Accounting Logs Containing Sensitive Information
Enabling SSL Rehandshake on All Contexts
New Software Features and Enhancements in A3(2.6)
Configuring Persistence with Load Balancing on Each HTTP Request
Enabling Maximum Load Notification When the Backup Server Farm is in Use
Enabling Caching for Regex Parsing by HTTP or HTTPS Probes
New Software Features in A3(2.5)
New Software Features in A3(2.4)
New Software Features in A3(2.3)
Using the"\xST" Metacharacter in Regular Expressions for Layer 4 Generic Data Parsing
Overview
"\xST" Metacharacter Regex Usage Considerations
Configuration Examples
New Software Features in A3(2.2)
New Software Features in A3(2.0)
New Software Features in A3(1.0)
Available ACE Licenses
Ordering an Upgrade License and Generating a Key
Upgrading Your ACE Software in a Redundant Configuration
Before You Begin
Changing the Admin Password
Changing the www User Password
Removing the duplex Command from the ACE Configuration
Removing the Underscore Character from a Hostname
Creating a Checkpoint
Copying the Startup Configuration of Each Context
Checking Your Configuration for FT Priority and Preempt
Updating Your Application Protocol Inspection Configurations
Upgrade Procedure
Downgrading Your ACE Software in a Redundant Configuration
Before You Begin
Downgrade Procedure
Supported Browsers for ACE Appliance Device Manager
ACE Operating Considerations
ACE Ages Out Sticky Entries When Sticky Resource Usage Reaches the Minimum Value
Verifying the ACE Appliance Hardware Revision
Redundancy States between Peers Running with Different Software Versions
RADIUS Load-Balanced Sticky Entry
Port Number Inheritance for Probes
SSL Filenames
Application Acceleration Functionality
Using SSL (HTTPS) Probes
Using Dynamic ETag and HTTP Compression
Using Application Acceleration FlashForward With IP Address Stickiness
Reestablishing Redundant Connection and Using the show ft Command
Standby ACE Responding to the GSS
Allowable Public Key Size Increased on the ACE
Naming ACE Objects for Use with ANM or DM
ACE Documentation Set
Software Version A3(2.7) Resolved Caveats, Open Caveats, and Command Change
Software Version A3(2.7) Resolved Caveats
Software Version A3(2.7) Open Caveats
Software Version A3(2.7) Command Changes
Software Version A3(2.7) System Log Messages
901001
Software Version A3(2.6) Resolved Caveats, Open Caveats, and Command Change
Software Version A3(2.6) Resolved Caveats
Software Version A3(2.6) Open Caveats
Software Version A3(2.6) Command Changes
Software Version A3(2.6) System Log Messages
441003
442007
Software Version A3(2.5) Resolved Caveats, Open Caveats, and Command Change
Software Version A3(2.5) Resolved Caveats
Software Version A3(2.5) Open Caveats
Software Version A3(2.5) Command Changes
Software Version A3(2.5) Revised System Log Messages
106028
305010
305012
Software Version A3(2.4) Resolved Caveats, Open Caveats, and Command Change
Software Version A3(2.4) Resolved Caveats
Software Version A3(2.4) Open Caveats
Software Version A3(2.4) Command Changes
MIB and Notification Changes for A3(2.4)
Software Version A3(2.3) Resolved Caveats, Open Caveats, and Command Changes
Software Version A3(2.3) Resolved Caveats
Software Version A3(2.3) Open Caveats
Software Version A3(2.3) Command Changes
Revised System Log Messages
253004
441001
441002
Software Version A3(2.2) Resolved Caveats, Open Caveats, and Command Changes
Software Version A3(2.2) Resolved Caveats
Software Version A3(2.2) Open Caveats
Software Version A3(2.2) Command Changes
Displaying Detailed CRL-Downloading Statistics
Software Version A3(2.1) Resolved Caveats, Open Caveats, and Command Changes
Software Version A3(2.1) Resolved Caveats
Software Version A3(2.1) Open Caveats
Software Version A3(2.1) Command Changes
Software Version A3(2.0) Open Caveats
Software Version A3(1.0) Resolved and Open Caveats
Software Version A3(1.0) Resolved Caveats
Software Version A3(1.0) Open Caveats
Obtaining Documentation and Submitting a Service Request
Release Note for the Cisco 4700 Series Application Control Engine Appliance
December 21, 2010
Revised: June 29, 2011
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 4700 Series Application Control Engine (ACE) appliance.
•A3(2.7)
•A3(2.6)
•A3(2.5)
•A3(2.4)
•A3(2.3)
•A3(2.2)
•A3(2.1)
•A3(2.0)
•A3(1.0)
For information on the ACE appliance features and configuration details, see the ACE documentation located on www.cisco.com at:
http://www.cisco.com/en/US/products/ps7027/tsd_products_support_series_home.html
This release note contains the following sections:
•New Software Features and Enhancements in A3(2.7)
•New Software Features and Enhancements in A3(2.6)
•New Software Features in A3(2.5)
•New Software Features in A3(2.4)
•New Software Features in A3(2.3)
•New Software Features in A3(2.2)
•New Software Features in A3(2.0)
•New Software Features in A3(1.0)
•Available ACE Licenses
•Ordering an Upgrade License and Generating a Key
•Upgrading Your ACE Software in a Redundant Configuration
•Downgrading Your ACE Software in a Redundant Configuration
•Supported Browsers for ACE Appliance Device Manager
•ACE Operating Considerations
•ACE Documentation Set
•Software Version A3(2.7) Resolved Caveats, Open Caveats, and Command Change
•Software Version A3(2.6) Resolved Caveats, Open Caveats, and Command Change
•Software Version A3(2.5) Resolved Caveats, Open Caveats, and Command Change
•Software Version A3(2.4) Resolved Caveats, Open Caveats, and Command Change
•Software Version A3(2.3) Resolved Caveats, Open Caveats, and Command Changes
•Software Version A3(2.2) Resolved Caveats, Open Caveats, and Command Changes
•Software Version A3(2.1) Resolved Caveats, Open Caveats, and Command Changes
•Software Version A3(2.0) Open Caveats
•Software Version A3(1.0) Resolved and Open Caveats
•Obtaining Documentation and Submitting a Service Request
New Software Features and Enhancements in A3(2.7)
The ACE software version A3(2.7) release contains the following features and enhancements:
•Per CSCsq87212, you can now add a probe to a redirect server. For more information, see the "Probing a Redirect Server" section.
•By default, when the ACE finds a malformed cookie in a flow, it stops parsing the remaining packets. Per CSCtj42966, the cookie-error-ignore command allows you to configure the ACE to ignore malformed cookies in a request and continue parsing the remaining cookies. This command is in parameter map HTTP configuration mode and the syntax is as follows:
[no] cookie-error-ignore
Use the no form of this command to reset the default behavior.
•Per CSCtg87843, to avoid compiling the Layer 7 match statements when changes do not need Layer 7 compilation, you can optionally enable regex download optimization through the debug cfgmgr limit-regex-dnld command. Use the no form of the command to reset the default behavior and disable regex download optimization. The show download information command displays the regex download optimization status, enabled or disabled.
•Per CSCtj71776, whenever a CP Kernel crash occurs, the crashinfo file generated in the core directory now contains the following information:
–Per process memory information, kmem, memtrack, slabinfo, MTS memory, and buffer information.
–Build type, date, time, image version, and hardware details. The reload reason is also stored inside the crashinfo header.
–The dmesg output and the stack trace.
•Per CSCtj72783, this enhancement is used to convert the printk of level KERN_CRIT and less to syslogs with ID 901001, for example:
%ACE-2-901001 kernel: Clear buffer stats
•Per CSCth72012, the ACE now includes the configuration mode commands that contain sensitive information in the accounting logs. For more information, see the "Accounting Logs Containing Sensitive Information" section.
•Per CSCti76025, the ACE now allows you to enable SSL rehandshake for all contexts on the ACE. For more information, see the "Enabling SSL Rehandshake on All Contexts" section.
•Per CSCth59240, the new regex compilation-timeout command in configuration mode allows you to configure the timeout for regular expression (regex) compilation. When you configure a regex and its compilation is longer than the configured timeout, the ACE stops the regex compilation. The syntax for this command is as follows:
[no] regex compilation-timeout minutes
The minutes argument is the time period in minutes. Enter an integer from 1 to 500. The default timeout has been set to 60 minutes. This command is available only in the Admin context for an admin role and is applicable across all contexts.
For example, to configure a compilation timeout of 80 minutes, enter:
host/Admin(config)# regex compilation-timeout 80
Use the no form of the command to reset the default timeout of 60.
Probing a Redirect Server
Per CSCsq87212, you can now add a probe to a redirect server. When you configure a probe under a redirect server, the ACE uses the state of the real server based on the probe result for load-balancing decisions.
You can configure only probes with an IP address in routed mode under a redirect server, real and server farm. You cannot associate a scripted probe to a redirect server.
The following configuration is an example of this command:
ip address 10.25.25.18 routed
ip address 10.5.55.5 routed
webhost-redirection http://3.111.1.100/index.html 302
Note When the ACE incrementally synchronizes a probe configuration under a redirect server to an older release that does not have the ability to probe a redirect server, the configuration is synchronized but the probe remains inactive on the older version.
If you attempt to add a probe without an IP address in routed mode to a redirect server, the ACE displays the following error message:
Error: Only Probe in routed mode can be configured under a redirect server
If you try to remove the ip address ip_address routed option from a probe that is associated with a redirect server, the ACE displays the following error message:
Error: Cannot remove ip address option from a probe associated with redirect server
Caution
We strongly recommend that you do not make any CLI changes when the ACEs in a redundant configuration are running different software versions. Unexpected results may occur. Remove any new feature commands before performing a downgrade on the ACE.
Accounting Logs Containing Sensitive Information
Per CSCth72012, the ACE now includes the following configuration mode commands in the accounting logs:
•[no] ldap-server host ip_address [port port_number] [timeout seconds] [rootDN "DN_string" [password bind_password]]
•[no] radius-server key [0 | 7] shared_secret
•[no] radius-server host ip_address key [0 | 7] shared_secret
•[no] snmp-server community community_name
•[no] snmp-server host ip_address [inform | traps] [version {1 | 2c} | {3 {auth | noauth | priv}}] community_ string_or_username
•[no] snmp-server user user_name [group_name] [auth {md5 | sha} password1 [priv {password2 | aes-128 password2}] [localizedkey]]
•[no] tacacs-server host ip_address key [0 | 7] shared_secret
•[no] tacacs-server key [0 | 7] shared_secret
•[no] username name1 [password [0 | 5] {password}]
Previously, the ACE omitted these commands from the logs because they contain sensitive information, such as a community name, shared secret, username, or password.
With this behavior change, when the ACE includes any of these commands in the log, it masks the sensitive information with five stars. For example, when you enter the snmp-server community community_name command, the ACE logs the following:
snmp-server community *****
Note The ACE logs the sensitive information for the following commands in plain text and does not mask it:
•The backup pass-phrase command in Exec mode
•The ip address command in KAL-AP UDP configuration mode
•The credentials command in probe configuration mode
Enabling SSL Rehandshake on All Contexts
By default, SSL rehandshake is disabled on the ACE. Previously, you could enable only SSL rehandshake at the SSL-proxy level by configuring the rehandshake enable command in the SSL parameter map and associate the parameter map with an SSL proxy server using the ssl advanced-options command.
Per CSCti76025, the ACE now allows you to enable SSL rehandshake for all contexts on the ACE by using the crypto rehandshake enabled command in configuration mode. This command is available in the Admin context. The syntax of this command is as follows:
[no] crypto rehandshake enabled
Use the no form of this command to reset the default behavior of disabling SSL rehandshake for all contexts on the ACE.
New Software Features and Enhancements in A3(2.6)
The ACE software version A3(2.6) release contains the following features and enhancements:
•Per CSCtf11816, you can now create a maximum of 64 FT groups. Previously, you could create a maximum of 21 FT groups.
•Per CSCtd13725, the show service-policy [policy_name] [detail] command now displays the status of a regex download through the new Regex dnld status field. This field displays the QUEUED, SUCCESSFUL, or FAILED states.
•Per CSCtd68223, an SRG update is not required with every release. By default, releases are considered compatible unless they are explicitly declared as incompatible.
•Per CSCsr19346, the static arp command in configuration mode now allows the configuration of the multicast MAC address for a host. The ACE uses this multicast MAC address while sending packets to the host. This enhancement allows the support of deployments that involve clustering (for example Checkpoint clustering). A host can be assigned an multicast MAC address with the arp command. The ACE does not learn the multicast MAC addresses for a host.
•Per CSCte19502, BPDU packets are not subjected to bandwidth policing in a bridge-mode configuration.
•Per CSCtf35290, the new strict option for the persistence-rebalance command allows you to configure the ACE to load balance each subsequent GET request on the same TCP connection independently. For more information, see the "Configuring Persistence with Load Balancing on Each HTTP Request" section.
•Per CSCte57166, the new kal-ap primary-oos command in policy map class configuration mode enables the ACE to report the maximum load value of 255 to the GSS when the primary server farm is down and the backup server farm is in use. For more information, see the "Enabling Maximum Load Notification When the Backup Server Farm is in Use" section.
•Per CSCte54655, the ACE now generates syslog messages when the following server farm changes occur:
–A server farm fails without a backup server farm.
–A server farm transitions from the inactive and out-of-service states and the VIP state changes.
For more information, see the "Software Version A3(2.6) System Log Messages" section.
•Per CSCtg13892, the new cache option for the HTTP and HTTPS probe expect regex command in probe configuration mode enables regex parsing in cached mode for long web pages. For more information, see the "Enabling Caching for Regex Parsing by HTTP or HTTPS Probes" section.
Configuring Persistence with Load Balancing on Each HTTP Request
By default, the persistence-rebalance feature is enabled on the ACE. It load balances successive GET requests on the same TCP connection if the request results in load balancing that chooses the same Layer 7 class in the load-balancing policy. Per CSCtf35290, the new persistence-rebalance strict command in HTTP parameter-map configuration mode allows you to configure the ACE to load balance each subsequent GET request on the same TCP connection independently.
The syntax of this command is as follows:
persistence-rebalance strict
This command allows the ACE to load balance each HTTP request to a potentially different Layer 7 class or real server.
For example, to enable the strict persistence rebalance feature, enter:
host1/Admin(config)# parameter-map type http http_parameter_map
host1/Admin(config-parammap-http)# persistence-rebalance strict
To disable persistence rebalance, enter:
host1/Admin(config-parammap-http)# no persistence-rebalance
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.
Enabling Maximum Load Notification When the Backup Server Farm is in Use
When you configure a server farm as a backup server farm on the ACE and the primary server farm fails, the backup server farm redirects the client requests to another data center. However, the VIP remains in the INSERVICE state.
When you configure the ACE to communicate with a GSS, the ACE reports the availability of the server to a GSS by sending a load number. To inform the GSS that the primary server farm is down and a backup server farm is in use, the ACE needs to send a load value that the server is unavailable. When the GSS receives the load value of 255, it recognizes that the primary server farm is down and sends future DNS requests with the IP address of the other data center.
Per CSCte57166, the new kal-ap primary-oos command in policy map class configuration mode enables the ACE to report the maximum load value of 255 when the primary server farm is down and the backup server farm is in use.
The syntax for this command is as follows:
kal-ap primary-oos
For example, enable the reporting of a load value of 255 when the primary server is down and the backup server is in use, enter:
host1/Admin(config-pmap-c)# kal-ap primary-oos
To disable the reporting of a load value of 255 when the primary server is down and the backup server is in use:
host1/Admin(config-pmap-c)# no kal-ap primary-oos
Enabling Caching for Regex Parsing by HTTP or HTTPS Probes
By default, when you configure the expect regex command for HTTP or HTTPS probes in probe configuration mode, the ACE does not cache the web page parsed by the probes. If the web page is longer than 4kBytes and the regex matching string exceeds this length, the probe fails.
Per CSCtg13892, you can enable caching when regex parsing long web pages by using the new cache option for the expect regex command. The syntax for this command is as follows:
expect regex string [offset number] [cache [length]]
The arguments and options are as follows:
•string—Regular expression expected response string from the probe destination. Enter an unquoted text string with no spaces. If the string includes spaces, enclose the string in quotes. The string can be a maximum of 255 alphanumeric characters.
•offset number—(Optional) Sets the number of characters into the received message or buffer where the ACE starts searching for the defined expression. If you do not include the cache keyword when entering this command, the number argument is from 1 to 4000. However, if you include the cache keyword, the offset maximum number is 163840.
•cache—(Optional) Enables caching. By default, caching is not enabled. If you do not enable caching and the regex string is spanned across buffers, the probes fail.
•length—(Optional) Cache length. Enter a number from 1 to 1000. The default cache length is 1000.
Note The HTML file configured with the request method command cannot exceed the length of the offset plus the length of the cache. If the file exceeds this length, the probes fail.
Note For HTTP and HTTPS probes with active and standby ACEs that are running different software versions, any incremental changes made for the expect regex command are not synchronized. Any synchronization changes to the other ACE occur through bulk synchronization. Bulk synchronization takes place as expected.
For example, to configure the expected response string without caching, enter:
host1/Admin(config-probe-http)# expect regex test
To configure the expected response string with caching with the default cache length of 1000, enter:
host1/Admin(config-probe-http)# expect regex test cache
Per CSCtg13892, the regex cache-len field has been added to the output for show probe detail command. This field displays the configured cache length.
New Software Features in A3(2.5)
The ACE software version A3(2.5) release contains the following feature:
•Configuring the ACE to perform an SSL rehandshake—In prior releases, the ACE automatically performed an SSL rehandshake when necessary because rehandshake was enabled by default. Starting with this release, SSL rehandshake is disabled by default and a new CLI command has been added to explicitly enable this functionality. The syntax of this command is:
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.
•Compression enhancements, as follows:
–Per CSCsu06258, when you attempt to remove a default Multipurpose Internet Mail Extension (MIME) type and no other MIME type is configured, the following error message is displayed:
Error: At least one user mimetype needs to be configured before removing the
default mimetype
When you remove the only configured MIME type and the default MIME type was previously removed, the default MIME type is restored and the following information message is displayed:
The only user mimetype available is deleted so the default mimetype is configured
–The show service-policy command has additional compression counters. For more information, see Table 5.
New Software Features in A3(2.4)
The ACE software version A3(2.4) release contains the following features:
•Support for the new serverfarm option in the snmp-server enable traps slb command to send a trap when all servers are down in the server farm or the server farm has changed state. To address this change in the ACE, the CISCO-ENHANCED -SLB-MIB has been modified as well as the CISCO-ENHANCED-CAPABILITY-MIB. See Table 6 and the "MIB and Notification Changes for A3(2.4)" section for details.
•Addition of the description command to the serverfarm host real server configuration mode (see Table 6 for details).
•Implementation of ACL merge optimization to properly calculate and configure ACL resource allocation in the ACE.
New Software Features in A3(2.3)
The ACE software version A3(2.3) release contains the following features:
•Support for the "\xST" (STop) metacharacter for regular expressions (regexes) specifically designed for use by applications that involve the generic data parsing of a Layer 4 payload. See the "Using the"\xST" Metacharacter in Regular Expressions for Layer 4 Generic Data Parsing" section for details.
•Ability to unmask the snmpCommunityName and snmpCommunitySecurityName OIDs of the SNMP-COMMUNITY-MIB.
•Addition of the description command to the following configuration mode:
–Individual parameter map configuration modes
–Action list modify configuration mode
–Action list optimization configuration mode
•Configure the SNMP engine ID for an ACE context (Admin or user).
•Ability to enable an internal length check and remove any trailer bytes (appended to the end of an Ethernet IP frame) coming into the ACE.
•Ability to define the ASCII-character string at the start of a secondary cookie in a URL or ignore any start string of a secondary cookie in the URL and considers the secondary cookie part of the URL.
For details on the CLI commands that have been modified for software version A3(2.3) to address the features outlined above, see the "Software Version A3(2.3) Command Changes" section.
Using the"\xST" Metacharacter in Regular Expressions for Layer 4 Generic Data Parsing
This section describes the use of the new "\xST" metacharacter added in software version A3(2.3) for regular expressions that are used as part of Layer 4 generic data parsing.
It includes the following topics:
•Overview
•"\xST" Metacharacter Regex Usage Considerations
•Configuration Examples
Overview
The "\xST" (STop) metacharacter is now available in software version A3(2.3) 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 only use this metacharacter 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 appliance 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 timeout 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 A3(2.3) per CSCsx30496.
"\xST" Metacharacter Regex Usage Considerations
The new "\xST" metacharacter has the following usage guidelines related to its inclusion in regex matching:
•If the input matches a regex pattern that includes the "\xST" metacharacter, the regex engine will halt upon finding the character directly next to the '\xST' in the regex string (2nd '\x01' in the match statement).
•No additional input data will be considered by the ACE once the matching pattern is seen which may affect other regexes that are configured elsewhere in the policy. In this case, the "\xST" metacharacter should be used only once in the policy.
•The "\xST" metacharacter should only be used at the end of a regex pattern and not at the beginning. In this case, the ACE will display the "Error: Invalid regular expression" error message.
•The "\xST" metacharacter should not be added directly after a * wildcard match. For example, "abc.*\xST" would not be a recommended regex.
Configuration Examples
Included below are two configuration examples that show the use of the "\xST" metacharacter in regexes.
SSL session-ID Stickiness Configuration Example
parameter-map type generic SESSID-PARAM
sticky layer4-payload SESSID-STICKY
layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST)"
FIX Protocol Configuration Example
sticky layer4-payload FIX-STICKY
layer4-payload begin-pattern "\x0149=" end-pattern "\x01"
class-map type generic match-all FIX-CM
2 match layer4-payload regex ".*\x0110=...\x01\xST"
New Software Features in A3(2.2)
The ACE software version A3(2.2) release contains the following features:
•Ability to enter a cookie string value of the real server for HTTP cookie insertion when establishing a sticky connection. With this feature enabled, the ACE inserts the cookie in the Set-Cookie header of the response from the server to the client. See the "Software Version A3(2.2) Command Changes" section for details.
•Ability to modify a child class map in the ACE without having to first disassociate it from the parent class map.
•Supports the cyclic backup of real servers in a server farm.
•ACE appliance Device Manager enhancements, including:
–SSL provisioning workflow that allows you to set up keys, certificates, proxies, and generate certificate signing requests (CSRs).
–ACL enhancements:
- Enhanced user-friendly view to manage ACLs or individual entries within ACL tables.
- ACL/interface association view.
–Operations enhancements (Config >Operations >Real Servers screen) such as the following:
- Addition of Virtual Servers column.
- Addition of Graceful suspend option (triggers the Inservice Standby real server state).
–Miscellaneous usability enhancements
New Software Features in A3(2.0)
The ACE software version A3(2.0) release contains the following features:
•0.5-Gbps bundle (ACE-4710-0.5F-K9), which includes the ACE 4710 appliance and the following performance licenses:
–0.5-Gbps throughput license
–100 SSL transactions per second (TPS) license
–100-Mbps compression license
–5 virtual contexts license
–Application acceleration license (50 connections)
•Upgrade from 0.5 to 1-Gbps bundle (ACE-4710-BUN-UP1), which includes the ACE 4710 appliance and the following performance licenses (same as in ACE-4710-1F-K9):
–1-Gbps throughput license
–5000 SSL TPS
–500-Mbps compression license
–5 virtual contexts license
–Application acceleration license (50 connections)
•ACE 4710 appliance two-pack bundle (ACE-4710-BAS-2PAK), which includes two ACE 4710 appliances and the following performance licenses (same as contained individually in ACE-4710-BAS-SK-K9):
–1-Gbps throughput license
–1000 SSL TPS license
–100-Mbps compression license
–5 virtual contexts license
–Application acceleration license (50 connections)
See the "Available ACE Licenses" section for details.
New Software Features in A3(1.0)
The ACE software version A3(1.0) release contains the following expanded features and functions:
•Enhanced load-balancing support:
–SIP
–Extended RTSP
–RADIUS
–RDP
–Generic protocol parsing
•Enhanced predictors:
– Adaptive algorithms
– Least loaded
– Least bandwidth
–Predictor response
•General SLB enhancements:
–HTTP header rewrite
– Partial server farm failover
– Application-based probes
– SNMP-based probes
– UDP fast age
–SSL cipher suite-based load balancing
•SSL enhancements:
–Hardware-assisted probes
–Session ID reuse
– SSL queue delay timer
– Client authentication
– URL rewrites for SSL
•GigabitEthernet port enhancements:
–Quality of Service (QoS) for a configured physical Ethernet port that is based on VLAN Class of Service (CoS) bits
–Assignment of higher priority to traffic on QoS-enabled port (a trusted port) for the configured FT VLAN port
•Fast DNS load balancing—UDP booster
•Dynamic inheritance of the port number specified from the following:
–The real server specified in a server farm
–The VIP specified in a Layer 3 and Layer 4 class map
•XML-tagged configuration
•Management traffic protection
•Redundancy (high availability) sync improvements
•Source NAT changes
•Protocol inspection enhancements:
– SIP
– ILS/LDAP
– Skinny
•ACL improvements—object grouping
•Denial-of-service protection—SYN cookie per interface
•Rate-limiting enhancements:
– Connection-rate
– Bandwidth-rate
•HTTP firewall features:
– Inspect HTTP POST body
– Inspect HTTP secondary cookies
Available ACE Licenses
By default, the ACE supports the following features and capabilities:
•Performance: 1 gigabit per second (Gbps) appliance throughput
•Virtualization: 1 admin context and 5 user contexts
•Secure Sockets Layer (SSL): 100 transactions per second (TPS)
•Hypertext Transfer Protocol (HTTP) compression: 100 megabits per second (Mbps)
•Application Acceleration: 50 connections
You can increase the performance and operating capabilities of your ACE product by purchasing one of the licensing options.
Note Starting with the A3(2.1) software release, the ACE will enforce licenses and their associated limits. License limits were not enforced in the A3(2.0) software release. To ensure proper operation of your ACE when using the A3(2.1) software release, ensure that you activate all of your feature licenses as described in Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
The ACE performance and operational defaults outlined in this section will be enforced starting with the next software release. This phase-in of system defaults is to allow graceful and nondisruptive software upgrades for your ACE appliance.
You can order your ACE product by either of these methods:
•Ordering a license bundle. Each license bundles includes the ACE appliance and a series of software licenses.
•Ordering separate license options.
You must have the Admin role in the Admin context to perform the tasks of installing, removing, and updating the license. You can access the license and show license commands only in the Admin context.
Note Table 1 and Table 2 contain the software license models that are supported for the A3(x.x) software. Any license that you may receive that is not listed in these tables cannot be used on the A3(x.x) software.
Table 1 ACE Licensing Bundles
|
License Model
|
Description
|
Upgrade Path
|
ACE-4710-0.5F-K9 |
This license bundle includes the following items: •ACE 4710 appliance •0.5-Gbps throughput license (ACE-AP-500M-LIC) •100-Mbps compression license (ACE-AP-C-100-LIC) •100 SSL transactions per second (TPS) license (ACE-AP-SSL-100-K9) •5 virtual contexts license (ACE-AP-VIRT-5) •Application acceleration license (50 connections) (ACE-AP-OPT-50-K9) |
You have the option to upgrade to the 1-Gbps, 2-Gbps, or 4-Gbps bundle. Start the upgrade with ACE-4710-BUN-UP1=. |
ACE-4710-1F-K9 |
This license bundle includes the following items: •ACE 4710 appliance •1-Gbps throughput license (ACE-AP-01-LIC) •500-Mbps compression license (ACE-AP-C-500-LIC) •5000 SSL TPS license (ACE-AP-SSL-05K-K9) •5 virtual contexts license (ACE-AP-VIRT-5) •Application acceleration license (50 connections) (ACE-AP-OPT-50-K9) |
You have the option to upgrade to the 2-Gbps or 4-Gbps bundle. Start the upgrade with ACE-4710-BUN-UP2=. |
ACE-4710-BAS-2PAK |
This license bundle includes the following items: •Two ACE 4710 appliances •1-Gbps throughput license (ACE-AP-01-LIC) ACE-4710-BAS-2PAK also includes the following default options: •1000 SSL TPS •100-Mbps compression •5 virtual contexts •Application acceleration (50 connections) |
You have the option to upgrade to the 2-Gbps or 4-Gbps bundle. Start the upgrade with ACE-4710-BUN-UP2=. Two upgrade licenses are required for upgrading two units of the ACE-4710-BAS-2PAK bundle. |
ACE-4710-2F-K9 |
This license bundle includes the following items: •ACE 4710 appliance •2-Gbps throughput license (ACE-AP-02-LIC) •1-Gbps compression license (ACE-AP-C-1000-LIC) •7500 SSL TPS license (ACE-AP-SSL-07K-K9) •5 virtual contexts license (ACE-AP-VIRT-5) •Application acceleration license (50 connections) (ACE-AP-OPT-50-K9) |
You have the option to upgrade to the 4-Gbps bundle. Start the upgrade with ACE-4710-BUN-UP3=. |
ACE-4710-4F-K9 |
This license bundle includes the following items: •ACE 4710 appliance •4-Gbps throughput license (ACE-AP-04-LIC) •2-Gbps compression license (ACE-AP-C-2000-LIC) •7500 SSL TPS license (ACE-AP-SSL-07K-K9) •5 virtual contexts license (ACE-AP-VIRT-5) •Application acceleration license (50 connections) (ACE-AP-OPT-50-K9) |
This is the highest value bundle. |
ACE-4710-BUN-UP1 |
0.5 to 1-Gbps throughput bundle upgrade license |
See the Upgrade Path outlined above. |
ACE-4710-BUN-UP2 |
1 to 2-Gbps throughput bundle upgrade license |
See the Upgrade Path outlined above. |
ACE-4710-BUN-UP3 |
2 to 4-Gbps throughput bundle upgrade license |
See the Upgrade Path outlined above. |
Table 2 ACE Licensing Options
|
Feature
|
License Model
|
Description
|
Performance Throughput |
Default |
1-Gbps throughput. |
ACE-AP-500M-LIC |
0.5-Gbps throughput. |
ACE-AP-01-LIC |
1-Gbps throughput. |
ACE-AP-02-LIC |
2-Gbps throughput. |
ACE-AP-04-LIC |
4-Gbps throughput. |
ACE-AP-02-UP1 |
Upgrade from 1-Gbps to 2-Gbps throughput. |
ACE-AP-04-UP1 |
Upgrade from 1-Gbps to 4-Gbps throughput. |
ACE-AP-04-UP2 |
Upgrade from 2-Gbps to 4-Gbps throughput. |
Virtualization |
Default |
1 admin/5 user contexts. |
ACE-AP-VIRT-020 |
1 admin/20 user contexts. |
SSL |
Default |
100 TPS. |
ACE-AP-SSL-05K-K9 |
5000 TPS. |
ACE-AP-SSL-07K-K9 |
7500 TPS. |
ACE-AP-SSL-UP1-K9 |
Upgrade from 5000 TPS to 7500 TPS. |
HTTP Compression |
Default |
100-Mbps. |
ACE-AP-C-500-LIC |
500-Mbps. |
ACE-AP-C-1000-LIC |
1-Gbps. |
ACE-AP-C-2000-LIC |
2-Gbps. |
ACE-AP-C-UP1 |
Upgrade from 500-Mbps to 1 Gbps. |
ACE-AP-C-UP2 |
Upgrade from 500-Mbps to 2 Gbps. |
ACE-AP-C-UP3 |
Upgrade from 1 Gbps to 2 Gbps. |
Application Acceleration Feature Pack License |
ACE-AP-OPT-LIC-K9 |
Application acceleration and optimization. By default, the ACE performs up to 50 concurrent connections. With the application acceleration and optimization software feature pack installed, the ACE can provide greater than 50 concurrent connections. This license increases the operating capabilities of the following features: •Delta optimization •Adaptive dynamic caching •FlashForward •Dynamic Etag |
|
ACE demo licenses are available through your Cisco account representative. A demo license is valid for only 60 days. At the end of this period, you must update the demo license with a permanent license to continue to use the ACE software. To view the expiration of a demo license, from the CLI, use the show license usage command in Exec mode. If you need to replace the ACE appliance, you can copy and install the licenses onto the replacement appliance.
Ordering an Upgrade License and Generating a Key
This section describes the process that you use to order an upgrade license and to generate a license key for your ACE. To order an upgrade license, follow these steps:
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 following Cisco.com website:
•If you are a registered user of cisco.com, go to the following location:
http://www.cisco.com/go/license
•If you are not a registered user of cisco.com, go to the following location:
http://www.cisco.com/go/license/public
Step 3 Enter the Product Authorization Key (PAK) number found on the Software License Claim Certificate as your proof of purchase.
Step 4 Provide all the requested information to generate a license key. Once the system generates the license key, you will receive a license key e-mail with an attached license file and installation instructions.
Step 5 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 on installing and managing ACE licenses:
•From the ACE appliance CLI, see Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
•From ACE appliance Device Manager, see Chapter 2, Configuring Virtual Contexts, in the Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Configuration Guide.
Upgrading Your ACE Software in a Redundant Configuration
This procedure assumes that your ACE appliances are configured as redundant peers to ensure that there is no disruption to existing connections during the upgrade process. In the following procedure, the active ACE is referred to as ACE-1 and the standby ACE is referred to as ACE-2.
For complete instructions on how to upgrade your ACE software, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
This section includes the following topics:
•Before You Begin
•Upgrade Procedure
Before You Begin
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
•Removing the duplex Command from the ACE Configuration
•Removing the Underscore Character from a Hostname
•Creating a Checkpoint
•Copying the Startup Configuration of Each Context
•Checking Your Configuration for FT Priority and Preempt
•Updating Your Application Protocol Inspection Configurations
Note As part of CSCte73151 in software version A3(2.7), the default least-loaded predictor behavior of autoadjust maxload is now autoadjust average. This change occurs automatically when you upgrade from software version A3(2.6) to A3(2.7). Consider the following:
•If you had configured the autoadjust off command under the least-loaded predictor, the ACE retains the configuration after the upgrade.
•If you had configured the autoadjust average command under the least-loaded predictor, the ACE retains the behavior after upgrade. However, the ACE does not display the configuration in the running config.
If you perform any configuration change related to the autoadjust command during the upgrade or downgrade process, in which either the active or standby ACE is running software version A3(2.7) or A3(2.6), when incremental sync occurs on the standby ACE, a configuration mismatch can occur pertaining to the enabling of the autoadjust feature on the standby ACE. Perform any configuration changes related to autoadjust commands only after both ACEs have the same software versions.
Changing the Admin Password
Before you upgrade to ACE software version A3(1.0) or higher, you must change the default Admin password if you have not already done so. Otherwise, after you upgrade the ACE software, you will only be able to log in to the ACE through the console port.
Caution
If you do not change the Admin password prior to upgrading to ACE software version A3(1.0) or higher, configuration synchronization may fail and the context may not be in the STANDBY_HOT state.
For details on changing the default Admin password, do one of the following:
•From the CLI, see Chapter 1, Setting Up the ACE, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
•From the Device Manager GUI, see Chapter 1, Overview, in the Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Configuration Guide.
Note If your ACE is managed by the Cisco Application Networking Manager (ANM) software, you must change the Admin password on the ANM in the Primary Attributes page instead of the ACE CLI. From the ANM, click the Change Password button on Primary Attributes page (Config > Devices > System > Primary Attributes).
Changing the www User Password
Before you upgrade to ACE software version A3(1.0) or higher, you must change the default www user password if you have not already done so. Otherwise, after you upgrade the ACE software, the www user will be disabled and you will not be able to use Extensible Markup Language (XML) to remotely configure an ACE until you change the default www user password.
For details on changing a user account password, see Chapter 2, Configuring Virtualization, in the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide. In this case, the user would be www.
Caution
If you do not change the www user password prior to upgrading to ACE software version A3(1.0) or higher, configuration synchronization may fail and the context may not be in the STANDBY_HOT state.
Removing the duplex Command from the ACE Configuration
As a result of a duplex command syntax change between A3(2.1) and A3(2.2) (per CSCta56623), if your ACE configuration includes one or more Gigabit Ethernet ports that are configured for full or half duplex operation, before you upgrade from A3(2.1) to A3(2.2), or A3(2.2) to either A3(2.4) or A3(2.3) you must first remove the duplex configuration from the startup-configuration file on both the active ACE and standby (peer) ACE.
Perform the following configuration change on both the active ACE and standby (peer) ACE before you begin the upgrade procedure:
a. Use the no form of the duplex command in interface configuration mode to remove the duplex configuration from all configured Gigabit Ethernet ports.
b. Save changes from the running-configuration file to the startup-configuration file.
After you complete the upgrade procedure, you can update the duplex settings for the configured Gigabit Ethernet ports using A3(2.4) (or A3(2.3). See Chapter 1, Configuring Ethernet Interfaces, in the Cisco 4700 Series Application Control Engine Appliance Routing and Bridging Configuration Guide.
Removing the Underscore Character from a Hostname
Before you upgrade the ACE appliance software from A3(2.0) to A3(2.x) as a result of addressing CSCsr90184, the underscore character (_) is no longer allowed in the hostname. As a result of this change, if you do not modify a hostname by removing the underscore character (_), after you perform an upgrade the standby ACE will remain in the STANDBY_COLD state because the configuration cannot synchronize with the illegal character.
Creating a Checkpoint
We strongly recommend that you create a checkpoint of the running-configuration 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 the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Copying the Startup Configuration of Each Context
In addition to creating a checkpoint of the running-configuration of each context in your ACE, we also strongly recommend that you copy the startup configuration of each context to either:
•The disk0: file system on your ACE.
•An TFTP, FTP, or SFTP server.
Having a backup of the startup configuration of each context ensures that you can recover your ACE should an issue arise during the upgrade procedure. In that case, you can then downgrade and restore the existing startup configuration to your ACE.
Checking Your Configuration for FT Priority and Preempt
If you want the currently active ACE to remain active after the software upgrade, be sure that the active ACE has a higher priority than the standby (peer) ACE and that the preempt command is configured. To check the redundant configuration of your ACEs, use the show running-config ft command. The preempt command is enabled by default and does not appear in the running-config.
Updating Your Application Protocol Inspection Configurations
Because ACE software version A3(x.x) has stricter error checks for application protocol inspection configurations than the previous A1(x.x) ACE software versions, be sure that your inspection configurations meet the guidelines that follow. The error checking process in the A3(x.x) software denies misconfigurations in inspection classifications (class maps) and displays error messages. If such misconfigurations exist in your startup- or running-configuration file before you load the A3(x.x) software, the standby ACE in a redundant configuration may boot up to the STANDBY_COLD state. For information about redundancy states, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
If the class map for the inspection traffic is generic (match . . . any or class-default is configured) so that noninspection traffic is also matched, the ACE displays an error message and does not accept the inspection configuration. For example:
switch/Admin(config)# class-map match-all TCP_ANY
switch/Admin(config-cmap)# match port tcp any
switch/Admin(config)# policy-map multi-match FTP_POLICY
switch/Admin(config-pmap)# class TCP_ANY
switch/Admin(config-pmap-c)# inspect ftp
Error: This class doesn't have tcp protocol and a specific port
The following examples show some of the generic class-map match statements and an ACL that are not allowed in ACE 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
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match access-list ACL1
Upgrade Procedure
To upgrade your ACE software in a redundant configuration, follow these steps:
Step 1 Log in to both the active and standby ACEs. The Exec mode prompt appears at the CLI. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the Admin context. If necessary, log directly in to, or change to the Admin context.
Step 2 Save the running configurations of every context by entering the write memory all command in Exec mode in the Admin context of each ACE.
ACE-1/Admin# write memory all
Step 3 Create a checkpoint in each context of both ACEs by entering the checkpoint create command in Exec mode.
ACE-1/Admin# checkpoint create ADMIN_CHECKPOINT
ACE-1/C1# checkpoint create C1_CHECKPOINT
Step 4 Copy the new software image to the image directory of each ACE (active and standby) by entering the copy ftp, copy sftp, or the copy tftp command in Exec mode. For example, to copy the image with the name c4710ace-mz.A3_2_4.bin through FTP, enter:
ACE-1/Admin# copy ftp://server1/images//c4710ace-mz.A3_2_4.bin image:
Enter source filename[/images/c4710ace-mz.A3_2_4.bin]?
Enter the destination filename[]? [c4710ace-mz.A3_2_4.bin] File already exists, do you
want to overwrite?[y/n]: [y]
Enter hostname for the ftp server[server1]?
Enter the file transfer mode[bin/ascii]: [bin] Enable Passive mode[Yes/No]: [Yes] no
Step 5 Ensure that the new software image is present on both the active and standby ACEs by entering the dir command in Exec mode. For example, enter:
ACE-1/Admin# dir image:c4710ace-mz.A3_2_5.bin
35913728 Jan 05 2010 01:17:01 c4710ace-mz.A3_2_5.bin
Usage for image: filesystem
828182528 bytes total used
Step 6 If you are running software version A1(7a) or A1(7b), on the active ACE, enter the show running-config command and verify if any of the unsupported application acceleration CLI commands are enabled in the action list, parameter map, or optimize sections of the running-configuration file. Include the pipe character (|) to enable an output modifier that filters the command output.
The following list summarizes the application acceleration CLI commands that are no longer supported in the ACE appliance, starting with software release A1(8.0):
–Action list optimization configuration mode commands: cache forward-with-wait, fast-redirect, flashconnect, flashconnect-object, image, meta refresh-to-302, urlmap scope, xslt merge
–Optimize configuration mode commands: prefix flashconnect
–Parameter map optimization configuration mode commands: flashconnect limit, image,
urlmap non-html, xslt merge-debug, xslt pretransformer, xslt stylesheet
For example, enter:
ACE-1/Admin# show running-config action-list | include flashconnect
Generating configuration....
Step 7 If you are running software version A1(7a) or A1(7b), if any of the unsupported application acceleration commands are present, remove them by specifying the no form of the associated command. For example, enter:
ACE-1/Admin# show running-config action-list
Generating configuration....
action-list type optimization http AL-AVS
Enter configuration commands, one per line. End with CNTL/Z.
ACE-1/Admin(config)# action-list type optimization http AL-AVS
ACE-1/Admin(config-actlist-optm)# no flashconnect
ACE-1/Admin(config-actlist-optm)# no flashconnect-object
ACE-1/Admin(config-actlist-optm)# exit
ACE-1/Admin(config)# exit
Step 8 Verify the current BOOT environment variable and configuration register setting by entering the show bootvar command in Exec mode. For example, enter:
ACE-1/Admin# show bootvar
BOOT variable = "image:c4710ace-mz.A3_2_4.bin"
Configuration register is 0x1
Step 9 Remove the existing image from the boot variable on ACE-1 by entering the no boot system image:ACE_image command in configuration mode. For example, to remove the A3(2.1) image, enter:
Enter configuration commands, one per line. End with CNTL/Z.
ACE-1/Admin(config)# no boot system image:c4710ace-mz.A3_2_1.bin
Step 10 Configure ACE-1 to autoboot from the latest ACE appliance image. To set the boot variable and configuration register to 0x1 (perform auto boot and use startup-config file), use the boot system image: and config-register commands in configuration mode. For example, enter:
ACE-1/Admin(config)# boot system image:c4710ace-mz.A3_2_5.bin
ACE-1/Admin(config)# config-register 0x1
ACE-1/Admin(config)# exit
ACE-1/Admin# show bootvar
BOOT variable = "image:c4710ace-mz.A3_2_5.bin"
Configuration register is 0x1
Step 11 On the standby ACE appliance (ACE-2), perform the following:
–Enter the show running-config command and ensure that all the changes made in the active ACE (ACE-1) are also reflected on the standby ACE.
–Enter the show bootvar command to verify that the boot variable was synchronized with ACE-1.
Step 12 Verify the state of each ACE by entering the show ft group detail command in Exec mode. Upgrade the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command in Exec mode.
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Note If you upgrade from software version A1(7a) or A1(7b) to software version A3(x.x), you will see that the ACE enters the STANDBY-HOT state. However, if you upgrade from software version A1(8.0) or A1(8.0a) to software version A3(x.x), you will see that the ACE enters the STANDBY_WARM state.
After ACE-2 boots up, it may take a few minutes to reach the STANDBY_WARM state again. Configuration synchronization is still enabled and the connections through ACE-1 are still being replicated to ACE-2.
Note We do not recommend that you make any changes to the ACE-1 configuration. At this point in the upgrade procedure with ACE-2 in the STANDBY_WARM state, any incremental commands that you add to the ACE-1 configuration may not be properly synchronized to the ACE-2 configuration. To make any changes to ACE-1, disable incremental sync on ACE-1 and manually synchronize the changes to ACE-2.
Step 13 After the standby ACE reboots, log in and perform the following actions to verify the state of the standby ACE:
–Enter the show version command in Exec mode to verify that the appliance has properly rebooted with the latest ACE appliance software image.
–Enter the show ft group detail command in Exec mode to verify that the standby ACE has recovered to a STANDBY_HOT state. If the standby ACE is running software release A3(2.2) or later, the state is STANDBY_WARM.
Note If you are upgrading from software version A1(7a) or A1(7b), you may encounter synchronization issues if the active peer, which has not been rebooted at this point in the procedure, still contains the deprecated application acceleration commands in its running-configuration file when you reload the standby ACE (see Step 6). In this case, when the next configuration synchronization occurs between the two peers, the configuration sync will fail and the standby ACE enters the STANDBY_COLD state.
If the deprecated application acceleration commands appear in the startup-config file of either the standby ACE or the active ACE, the console displays exceptions during the reload process. If the running-config file of the active ACE is in the correct state, you can correct the startup-config file mismatch between the two peers by entering the copy running-config startup-config command, followed by the write mem command.
Step 14 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.
ACE-1/Admin# ft switchover all
Step 15 Upgrade ACE-1 by reloading it. Verify that ACE-1 enters the STANDBY_HOT state (this action may take several minutes) by entering the show ft group detail command in Exec mode.
Because the standby ACE has changed its state to either STANDBY_COLD or STANDBY_HOT, the 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.
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 16 Verify that ACE-1 is in the ACTIVE state and ACE-2 is in the STANDBY_HOT state by entering the show ft group detail command in Exec mode.
Downgrading Your ACE Software in a Redundant Configuration
If you need to downgrade your ACE software from version A3(x.x) to an earlier ACE software version, use the procedure that follows. This procedure assumes that your ACEs are configured as redundant peers to ensure that there is no disruption to existing connections during the downgrade process. In the following procedure, the active ACE is referred to as ACE-1 and the standby ACE is referred to as ACE-2.
Before You Begin
Note the following considerations before you begin the downgrade process:
•Before you downgrade your ACE software, ensure that the following conditions exist:
–Identical versions of the previous software image resides in the image: directory of both ACEs.
–The active ACE has a higher priority than the standby ACE and preempt is enabled on the FT group if you want the active ACE to remain active after the downgrade procedure.
•As a result of a duplex command syntax change in A3(2.2) (per CSCta56623), if your ACE configuration includes one or more Gigabit Ethernet ports that are configured for full or half duplex operation, before you downgrade from A3(2.4) or A3(2.3) to A3(2.2) to you must first remove the duplex configuration from the startup-configuration file on both the active ACE and standby (peer) ACE.
–Use the no form of the duplex command in interface configuration mode to remove the duplex configuration from all configured Gigabit Ethernet ports.
–Save changes from the running-configuration file to the startup-configuration file.
After you complete the downgrade procedure back to A3(2.2), you can update the duplex settings for the configured Gigabit Ethernet ports using A3(2.2). See Chapter 1, Configuring Ethernet Interfaces, in the Cisco 4700 Series Application Control Engine Appliance Routing and Bridging Configuration Guide.
•If your ACE includes a 4-Gbps performance throughput license or a 2-Gbps HTTP compression license, ensure that you first uninstall the following prior to downgrading to A1(7a) or A1(7b):
–Uninstall the 4-Gbps performance throughput license and reinstall the 2-Gbps license.
–Uninstall the 2-Gbps HTTP compression license and reinstall the 1-Gbps license.
See Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
•If your ACE includes the 0.5-Gbps bundled license (ACE-4710-0.5F-K9) that is available with software version A3(2.0) or higher, ensure that you first uninstall the 0.5-Gbps bundle prior to downgrading to an earlier ACE software release. The ACE defaults to the 1-Gbps license.
Note If you have installed one of the other available ACE license bundles (see Table 1) or individual upgrade license options (see Table 2) in addition to the 0.5-Gbps bundled license, and you downgrade to an earlier software version without first uninstalling those bundled licenses or individual upgrade licenses, the ACE may not downgrade properly to the original system defaults. In this case, you may observe an inconsistent behavior in the system defaults of the ACE.
•If your ACE includes the 5-to-20 user context upgrade license (ACE-AP-VIRT-020-UP) that is available with software version A3(2.0) or higher, ensure that you first uninstall the 5-to-20 user contexts license prior to downgrading to an earlier ACE software release. The ACE defaults to 1 admin context and 5 user contexts.
Note If your ACE includes more than 5 user contexts configured, when you downgrade to an earlier ACE software release the ACE will default to 1 admin context and 5 user contexts. In this case, the ACE will randomly remove the additional user contexts that have been configured. The ACE will delete the configuration associated with those additional contexts, including SSL certification/keys and scripted probe files.
If this is an issue, we recommend that you copy the start-up configuration file, running-configuration file, and SSL certificate and key pair files of each context prior to uninstalling the 5-to-20 user contexts license.
See the "Copying Files" section of the Cisco 4700 Series Application Control Engine Appliance Administration Guide for details on how to use the copy command to save configuration files or objects.
See the Cisco 4700 Series Application Control Engine Appliance SSL Configuration Guide for details on how to use the crypto export command to export SSL certificate and key pair files to a remote FTP, SFTP, or TFTP server.
•If you intend to downgrade from software version A3(x.x) to software version A1(7a) or A1(7b), before you begin the process, be sure to modify all existing Layer 7 HTTP load-balancing policy maps in A3(x.x) to remove the http keyword from the command. If you do not remove the http keyword, the ACE generates an error and the VIP enters the OUTOFSERVICE state.
•If you have configured carrier delay in software version A3(1.0) to add a configurable transition delay at the physical port level for the FT VLAN, and if you intend to downgrade from software version A3(x.x) to software version A1(8.0) or A1(8.0a), ensure that you save the current running-config file on the active ACE before you perform the software downgrade procedure on the active ACE. See CSCsr23197 in the "Software Version A3(2.1) Resolved Caveats, Open Caveats, and Command Changes" section for details.
•If you are downgrading from A3(2.6) and had configured more that 21 FT groups, remove them from the configuration. Also, remove any new commands as part of this release.
•As part of CSCte73151 in software version A3(2.7), the default least-loaded predictor behavior of autoadjust maxload is now autoadjust average. If you perform any configuration change related to the autoadjust command during the upgrade or downgrade process in which either the active or standby ACE is running software version A3(2.7) or A3(2.6), when incremental sync occurs on the standby ACE, a configuration mismatch can occur pertaining to the enabling of the autoadjust feature on the standby ACE. Perform any configuration changes related to autoadjust commands only after both ACEs have the same software versions.
During the downgrade process in which the active ACE is running software version A3(2.7) and the standby ACE is running software version A3(2.6), the default autoadjust average behavior of the least-loaded predictor on the active ACE changes to autoadjust maxload on the standby ACE. If you configure the autoadjust maxload command under the least-loaded predictor on the active ACE, during the build-sync, an FT-sync issue occurs on standby ACE. The show ft group detail command displays the following FT-sync error:
Error on Standby device when applying configuration file replicated from active on
performing
Downgrade Procedure
To downgrade your A3(x.x) software to an earlier ACE software version in a redundant configuration, follow these steps:
Step 1 If you have previously created checkpoints in your running-configuration files (highly recommended), roll back the configuration in each context on each ACE to the check-pointed configuration. For example:
ACE-1/Admin# checkpoint rollback CHECKPOINT_ADMIN
ACE-1/C1# checkpoint rollback CHECKPOINT_C1
Do the same on the other ACE. For information about creating checkpoints and rolling back configurations, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Step 2 Configure ACE-1 to automatically boot from the earlier ACE software 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:
ACE-1/Admin(config)# boot system image:c4710ace-mz.A3_2_3.bin
ACE-1/Admin(config)# config-register 1
ACE-1/Admin(config)# exit
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:ACE_image command to remove the configured A3(x.x) boot variable.
Step 3 Verify that the boot variable was synchronized to ACE-2 by entering the following command on ACE-2:
ACE-2/Admin# show bootvar
BOOT variable = "disk0:c4710ace-mz.A3_2_3.bin"
Configuration register is 0x1
Step 4 Verify the state of each ACE by entering the show ft group detail command in Exec mode. Downgrade the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command.
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Note If you downgrade from software version A3(x.x) to software version A1(7a) or A1(7b), you will see that the ACE enters the STANDBY-HOT state. However, if you downgrade from software version A3(x.x) to software version A1(8.0) or A1(8.0a), you will see that the ACE enters the STANDBY_WARM state.
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 ACE software does not recognize the A3(x.x) commands in the startup-configuration file.
After ACE-2 boots up, note the following:
–For software version A1(8.0) or A1(8.0a), after ACE-2 boots up, it may take a few minutes to reach the STANDBY_HOT state again.
–For software version A1(7a) or A1(7b), after s-2 boots up, it may take a few minutes to reach the STANDBY_WARM state again.
Configuration synchronization is still enabled and the connections through ACE-1 are still being replicated to ACE-2.
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.
ACE-1/Admin# ft switchover all
Step 6 Reload ACE-1 with the same ACE software version as ACE-2. Again, you may observe a few errors as ACE-1 loads the startup-configuration file.
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 the standby ACE has changed its state to either STANDBY_COLD or STANDBY_HOT, the 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 A3(x.x) configuration elements. For example, you may need to remove a service policy from an interface that was part of the version A3(x.x) configuration that is no longer needed in version A1(8.0a).
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.
Supported Browsers for ACE Appliance Device Manager
The ACE appliance Device Manager is supported on the following browsers:
•Microsoft Internet Explorer 6.0 or 7.0 with Service Pack 2 on Windows XP or Windows Vista
•Firefox 3.5 on Windows XP, Windows Vista, Windows 7, or Red Hat Enterprise Linux
All browsers require cookies and DHTML (JavaScript) to be enabled.
ACE Operating Considerations
This section outlines the following ACE operating considerations:
•ACE Ages Out Sticky Entries When Sticky Resource Usage Reaches the Minimum Value
•Verifying the ACE Appliance Hardware Revision
•Redundancy States between Peers Running with Different Software Versions
•RADIUS Load-Balanced Sticky Entry
•Port Number Inheritance for Probes
•SSL Filenames
•Application Acceleration Functionality
•Using SSL (HTTPS) Probes
•Using Dynamic ETag and HTTP Compression
•Using Application Acceleration FlashForward With IP Address Stickiness
•Reestablishing Redundant Connection and Using the show ft Command
•Standby ACE Responding to the GSS
•Allowable Public Key Size Increased on the ACE
•Naming ACE Objects for Use with ANM or DM
ACE Ages Out Sticky Entries When Sticky Resource Usage Reaches the Minimum Value
By design, if you set the maximum resources for sticky to unlimited using the limit-resource command, the ACE ignores the setting and sets the maximum value to equal-to-min. In addition, the maximum resource value for sticky in the show resource usage command output displays as 0. This behavior occurs because the ACE does not allow sticky resources to become oversubscribed as with other configurable resources. Instead, when the sticky resource usage reaches the minimum value, the ACE ages out older sticky entries in the sticky table and reuses them for new sticky entries.
Verifying the ACE Appliance Hardware Revision
Certain ACE appliances have been programmed with a hardware revision of 65535.65535 in the IDProm instead of the correct hardware revision of 1.1. This is a cosmetic issue only and has no functional impact on the operation of the ACE appliance.
To verify the hardware revision of your ACE appliance, enter the show hardware command as shown in the example below:
switch/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: QCN1208007N
Hardware Rev: 65535.65535
MFG Part Num: 800-29070-02
Redundancy States between Peers Running with Different Software Versions
In version A1(8.0), 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):
Note Per CSCtd68223 for software release A3(2.6), an SRG update is not required with every release. By default, releases are considered compatible unless they are explicitly declared as incompatible.
|
Active ACE Software Version
|
Standby ACE Software Version
|
|
|
A1(7.0) or less
|
A1(8.0)
|
A3(1.0)
|
A3(2.0)
|
A3(2.1)
|
A3(2.2)
|
A3(2.3)
|
A3(2.4)
|
A3(2.5)
|
A3(2.6)
|
A3(2.7)
|
|
A1(7.0) or less
|
C |
C |
C |
C |
C |
C |
C |
C |
C |
C |
C |
|
A1(8.0)
|
C |
C |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
|
A3(1.0)
|
C |
WC |
C |
C |
C |
C |
WC |
WC |
WC |
WC |
WC |
|
A3(2.0)
|
C |
WC |
C |
C |
C |
C |
WC |
WC |
WC |
WC |
WC |
|
A3(2.1)
|
C |
WC |
C |
C |
C |
C |
WC |
WC |
WC |
WC |
WC |
|
A3(2.2)
|
C |
WC |
C |
C |
C |
C |
WC |
WC |
WC |
WC |
WC |
|
A3(2.3)
|
C |
WC |
WC |
WC |
WC |
WC |
C |
WC |
WC |
WC |
WC |
|
A3(2.4)
|
C |
WC |
WC |
WC |
WC |
WC |
WC |
C |
WC |
WC |
WC |
|
A3(2.5)
|
C |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
C |
WC |
WC |
|
A3(2.6)
|
C |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
C |
WC |
|
A3(2.7)
|
C |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
WC |
C |
RADIUS Load-Balanced Sticky Entry
When the ACE times out a RADIUS load-balanced (RLB) sticky entry, it only considers the connections for the end-user traffic as part of the connection count. It does not consider connections for the RADIUS traffic as part of the connection count, whether or not you configure the timeout activeconns command. The only exception is when a connection has an outstanding RADIUS request for that sticky entry.
Port Number Inheritance for Probes
When you explicitly configure a default port through the probe command, the probes will always be sent to the default port. In this case, the probe will not dynamically inherit the port number from the real server specified in a server farm or from the VIP specified in a Layer 3 and Layer 4 class map.
SSL Filenames
In software version A3(2.2), the ACE now supports an SSL filename for a certificate or key pair with a maximum of 39 characters.
Application Acceleration Functionality
Cisco has refined the ACE application acceleration functionality starting in software version A1(8.0) and later releases by removing features that are rarely used. The following list summarizes the application acceleration CLI commands and associated functions that are no longer supported in the ACE appliance:
•Action list optimization configuration mode commands: cache forward-with-wait, fast-redirect, flashconnect, flashconnect-object, image, meta refresh-to-302, urlmap scope, xslt merge
•Optimize configuration mode commands: prefix flashconnect
•Parameter map optimization configuration mode commands: flashconnect limit, image,
urlmap non-html, xslt merge-debug, xslt pretransformer, xslt stylesheet
For information on the use of the application acceleration and configuration features of the ACE, see the updated Device Manager GUI online help system and the Cisco 4700 Series Application Control Engine Appliance Application Acceleration and Optimization Configuration Guide located at:
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/app_acc_and_opt/guide/appaccoptgd.html
Note With the removal of the subset of the application acceleration functionality, an incompatibility has been introduced between release 1.2 of the Cisco Application Networking Manager (ANM) software and release A1(8.0) of the ACE appliance. Specifically, if you attempt to configure the ANM 1.2 to utilize a removed application acceleration command, the deployment will fail and the ANM displays an error message that is related to the removed application acceleration function.
To bypass this configuration issue in the ANM software, we recommend that you use the ACE appliance Device Manager to make the application acceleration and optimization configuration changes for the ACE.
This incompatibility will be addressed in the next release of the ANM software.
Using SSL (HTTPS) Probes
Software version A3(1.0) introduced hardware-assisted SSL (HTTPS) probes. For that reason, the ACE uses the all option for the default SSL version and uses the routing table (which may bypass the real server IP address) to direct HTTPS probes to their destination regardless of whether you specify the routed option in the ip address command. If you are using HTTPS probes in your A1(x.x) configuration with the default SSL version (SSLv3) or without the routed option, you may observe that your HTTPS probes behave differently with software version A3(1.0) and later releases. For more information about HTTPS probes, see the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
Using Dynamic ETag and HTTP Compression
When you operate the ACE with application acceleration, and you define a policy map that includes dynamic ETag (entity tag) and HTTP compression, you may encounter behavioral issues when using a Microsoft Internet Explorer web browser (typically, Internet Explorer 6.0) that prevents the dynamic ETag function from properly leveraging the web browser cache. With HTTP compression and dynamic ETag configured, upon an Internet Explorer web browser refresh of the same page without any content changes, the browser will continue to retrieve the new (unchanged) content along with a new ETag header and the HTTP "200 OK" request succeeded response. Typically, when you use dynamic ETags and the web content has not changed, the browser receives a 304 Not Modified response and no data. This response prevents users from downloading objects on each request.
This operating consideration with the Microsoft Internet Explorer web browser does not result in broken pages or functionality but rather in a failed attempt at application acceleration, which results in the unnecessary download of objects that should be cached.
This behavior does not occur with the Firefox 2.0 or greater web browser, so we recommend that you use the Firefox web browser instead of the Internet Explorer 6.0 web browser if you plan to configure dynamic ETag (entity tag) with HTTP compression.
Using Application Acceleration FlashForward With IP Address Stickiness
When you operate the ACE with application acceleration, if your configuration includes the following elements:
•FlashForward object acceleration to extend the ACE appliance's bandwidth usage reduction and download acceleration benefits to objects that are embedded within HTML pages.
•IP address stickiness to stick a client to the same server for multiple subsequent connections as needed to complete a transaction.
you may find that there will more than one sticky entry created for the same session when a single user (one client IP address) attempts to retrieve one HTML page. The creation of multiple sticky entries is the expected behavior; in addition to the sticky entry created for the user session, a second sticky entry will be created for the application acceleration cache renew requests for the FlashForward embedded objects.
This behavior can be encountered when one of the following conditions occur:
•The client already contains the cached page in the browser cache.
•The application acceleration cache expires maximum setting (the expires-setting command in parameter map optimization configuration mode) is at the default of 300 seconds.
•The IP address sticky timeout setting (timeout command in sticky-IP configuration mode) is set to a lower value (for example, two minutes).
Under these conditions, when the client request an HTML page, the request is then load-balanced to multiple real servers. With IP address stickiness enabled, you may expect that the request would stick with a single real server and serve the HTML page from that server.
For example, in the show serverfarm output illustrated below, both servers increment and form two sticky entries.
switch/Admin# clear serverfarm WWWfarm
switch/Admin# show serverfarm WWWfarm
serverfarm : WWWfarm, type: HOST
num times back inservice : 0
---------------------------------
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
192.168.10.12:0 8 OPERATIONAL 1 1 0
max-conns : - , out-of-rotation count : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
192.168.10.99:0 8 OPERATIONAL 1 1 0
max-conns : - , out-of-rotation count : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
Reestablishing Redundant Connection and Using the show ft Command
When redundant ACEs lose connectivity, for example due to a network interruption, and they attempt to reestablish their connection, if you enter the show ft command during this time, the response for this command may be delayed.
Standby ACE Responding to the GSS
In software version A3(2.6) per CSCte73886, the standby ACE now always responds with a load value of 255 to the GSS.
Allowable Public Key Size Increased on the ACE
In software version A3(2.6) per CSCtf45668, the ACE now allows a maximum public key size of 4096 bits. Previously, the ACE allowed a maximum public key size of 2048 bits. The maximum private key size is still 2048 bits.
Naming ACE Objects for Use with ANM or DM
When you use the ACE CLI to configure named objects (such as a real server, virtual server, parameter map, class map, health probe, and so on), consider that the Cisco Application Networking Manager (ANM) or the Device Manager (DM) supports objects names with an alphanumeric string of 1 to 64 characters including the following special characters: underscore (_), hyphen (-), dot (.), and asterisk (*). Spaces are not allowed.
If you use the ACE CLI to configure a named object with special characters that are not supported by ANM or DM, you may not be able to import or manage the ACE using ANM, or configure the ACE using DM.
ACE Documentation Set
You can access the ACE appliance documentation on www.cisco.com at:
http://www.cisco.com/en/US/products/ps7027/tsd_products_support_series_home.html
For information about installing the Cisco ACE 4710 appliance hardware, see the following documents on Cisco.com:
|
Document Title
|
Description
|
Cisco 4710 Application Control Engine Appliance
Hardware Installation Guide |
Provides hardware information for installing the Cisco ACE 4710 appliance. |
Regulatory Compliance and Safety Information for the Cisco 4710 Application Control Engine Appliance |
Provide regulatory compliance and safety information for the Cisco ACE 4710 appliance. |
To familiarize yourself with the ACE appliance software, see the following documents on Cisco.com:
|
Document Title
|
Description
|
Release Note for the Cisco 4700 Series Application Control Engine Appliance |
Provides information about operating considerations and caveats for the ACE. |
Cisco 4700 Series Application Control Engine Appliance Quick Start Guide |
Describes how to use the ACE appliance Device Manager GUI and CLI to perform the initial setup and VIP load-balancing configuration tasks. |
For detailed configuration information on the ACE appliance Device Manager, see the following software documents on Cisco.com:
|
Document Title
|
Description
|
Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Configuration Guide |
Describes how to use the ACE appliance Device Manager. The Device Manager resides in Flash memory on the ACE appliance to provide a browser-based graphical user interface for configuring and managing the ACE. |
For detailed configuration information on the ACE CLI, see the following software documents on Cisco.com:
|
Document Title
|
Description
|
Cisco 4700 Series Application Control Engine Appliance Administration Guide |
Describes how to perform the following administration tasks on the ACE: •Setting up the ACE •Establishing remote access •Managing software licenses •Configuring class maps and policy maps •Managing the ACE software •Configuring SNMP •Configuring redundancy •Configuring the XML interface •Upgrading the ACE software |
Cisco 4700 Series Application Control Engine Appliance Application Acceleration and Optimization Configuration Guide |
Describes the configuration of the application acceleration and optimization features of the ACE. It also provides an overview and description of the application acceleration features and operation. |
Cisco 4700 Series Application Control Engine Appliance Command Reference |
Provides an alphabetical list and descriptions of all CLI commands by mode, including syntax, options, and related commands. |
Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide |
Describes how to perform the following ACE security configuration tasks: •Security access control lists (ACLs) •User authentication and accounting using a Terminal Access Controller Access Control System Plus (TACACS+), Remote Authentication Dial-In User Service (RADIUS), or Lightweight Directory Access Protocol (LDAP) server •Application protocol and HTTP deep packet inspection •TCP/IP normalization and termination parameters •Network Address Translation (NAT) |
Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide |
Describes how to configure the following server load-balancing tasks on the ACE: •Real servers and server farms •Class maps and policy maps to load balance traffic to real servers in server farms •Server health monitoring (probes) •Stickiness •Firewall load balancing •TCL scripts |
Cisco 4700 Series Application Control Engine Appliance SSL Configuration Guide |
Describes how to configure the following Secure Sockets Layer (SSL) tasks on the ACE: •SSL certificates and keys •SSL initiation •SSL termination •End-to-end SSL |
Cisco 4700 Series Application Control Engine Appliance System Message Guide |
Describes how to configure system message logging on the ACE. This guide also lists and describes the system log (syslog) messages generated by the ACE. |
Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide |
Describes how to operate your ACE in a single context or in multiple contexts. |
Cisco CSS-to-ACE Conversion Tool User Guide |
Describes how to use the CSS-to-ACE conversion tool to migrate Cisco Content Services Switches (CSS) running-configuration or startup-configuration files to the ACE. |
Software Version A3(2.7) Resolved Caveats, Open Caveats, and Command Change
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats, command changes, and revised system messages in software version A3(2.7):
•Software Version A3(2.7) Resolved Caveats
•Software Version A3(2.7) Open Caveats
•Software Version A3(2.7) Command Changes
•Software Version A3(2.7) System Log Messages
Software Version A3(2.7) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.7).
•CSCso16562—When you use the ACE Device Manager to edit the expect status for a probe, the ACE adds the new expect status but does not remove the previous expect status. Workaround: Log in to the ACE, remove the old expect status command, and synchronize the context.
•CSCsy66327—When you enter the show snmp group command from any context other than the Admin context, it does not display any output. Workaround: None.
•CSCsy73919—When you configure more than one probe for use in transparent mode with the same probe address, if transparent probe traffic destined to multiple real servers using the single probe address is interleaved, the ACE incorrectly switches its destination MAC address. Workaround: Use normal probes to the physical IP addresses of the real servers.
•CSCta34241—In a backend SSL configuration, after the ACE and server complete a resumed handshake, the server disables SSL session ID reuse. The ACE continues to sends the client hello containing the session ID previously generated by the server. In a front-end SSL configuration, when the client attempts to perform a resumed handshake with the ACE using the session ID which was overwritten by newer entry on the ACE, the resumed handshake fails and the ACE does not continue with a full handshake with the client. Workaround: For a backend SSL configuration, use the clear crypto session-cache all command after disabling the real server session ID reuse. For the front-end SSL configuration, there is no workaround.
•CSCta79631—The SNMP cslbxServerFarmCurrConns object is not displaying the same connection number as displayed by the show serverfarm command. Workaround: None.
•CSCtb52457—When the ACE has approximately 2000 real servers that are down in the ARP failed state, the CLI is less responsive. Workaround: None.
•CSCtb64408—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 mts_recv error.
•CSCte34658—When you attach a probe to two different real servers and delete one of the servers, the probe instance for the other server remains in the INVALID state. Workaround: Delete probes that remain in the INVALID state for all real servers and readd them.
•CSCte37379—Resetting the admin password fails if the username has the following format, admin@01 or admin-. Workaround: Do not use the formats of this type.
•CSCte52766—After a user account has expired on the ACE, the ACE DM still allows the expired user to log in, view, and edit the ACE configuration. Workaround: ACE appliance administrator must manually remove the expired user from ACE.
•CSCte62078—The ACE may experience a core dump due to snmpd service becoming unresponsive. Workaround: Preventing SNMP polling may avoid the snmpd service from becoming unresponsive.
•CSCte66045—When you change the value for the limit-resource all minimum command, the ACE may rate limit traffic at a different throughput level than indicated by the show resource usage command. Workaround: None.
•CSCte73151—When the ACE is using an SNMP probe for the least-loaded server farm predictor and the probe returns the OID value of 0 from the real server (the server is least loaded), the real server may not receive any connections and the ACE distributes all the connections to the other servers in the server farm. Workaround: Change the predictor autoadjust value from the default of max to average. The ACE autoadjusts the load to the average load of the server farm and the real server receives connections based on its having the average load of the server farm.
•CSCte92966—When you try to remove the limit-resource all command from a resource class, all ACE contexts associated with the resource class are left out of the resources that are not separately defined. Workaround: In A3(2.7), the ACE displays the following warning message when you try to remove the limit-resource all command from a resource class:
Warning: The context(s) associated with this resource-class
will be denied of all the resources that are not explicitly
configured with minimum limit in this resource-class
•CSCtf04751—The show buffer usage command displays incorrect values that are larger than the usage for certain types of internal ACE buffers. Workaround: Reboot the ACE to clear the buffers.
•CSCtf04771—When you enter the show buffer usage command, it now displays an additional Hi watermark field that allows more visibility into the buffer usage to monitor the high watermarks. Workaround: None.
•CSCtf05284—Occasionally, when the ACE control plane experiences high CPU utilization and you use the correct username and password to log in to the ACE, the login attempt fails and the ACE displays a message, such as Login incorrect. Workaround: Logging in to the ACE may result in a successful login.
•CSCtf07836—When you configure a non-TCP or non-UDP protocol after a TCP or UDP range inside an object group, the non-TCP or non-UDP protocols inherits the TCP or UDP port ranges. Workaround: Configure the ACL directly without using the object group.
•CSCtf50924—When you configure 0.0.0.0/0 as the first VIP on the ACE, all subsequent VIPs inside the show cfgmgr internal table vip command matches 0.0.0.0/0. This command table becomes corrupted with 0.0.0.0/0 as the first VIP. Workaround: Do not configure 0.0.0.0/0 as the first VIP.
•CSCtf53921—When you configure the shared-VLAN host ID for the local and peer ACEs, the ACE allows you to configure the same value for the shared-vlan-hostid and peer shared-vlan-hostid commands. However, the ACE should not support this configuration. Workaround: Configure different values for the shared-vlan-hostid and peer shared-vlan-hostid commands.
•CSCtf59011—When you configure the sticky-serverfarm command under a RADIUS policy map, the ACE does not clear the policy map entries on a RADIUS response and does not evenly load balance the RADIUS requests due to false retransmission issues. Workaround: Configure a sticky server farm under the RADIUS Layer 7 policy map.
•CSCtf74878—The output of the show resource usage command may show that the 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.
•CSCtf79878—When numerous SIP PUBLISH requests larger than 2KB are sent over connections inspected by the ACE, the ACE drops them and the SIP: Memory Allocation Failure counter increases. Workaround: You can monitor appInspect memory by using the show system resources and show system kmem command to determine that the memory usage is stable across time.
•CSCtf84257—When you configure several ECMP static routes, the ACE route_manager service unexpectedly becomes unresponsive. Workaround: None.
•CSCtf86402—When you configure the ACE for Role Based Access Control (RBAC) using custom domains and roles, and you log in to the ACE as a user with a user-configured domain and role, some commands do not work. Workaround: Use the specific versions of the show rserver name and show serverfarm name commands.
•CSCtg17350—When you configure the Acceleration and Optimization features on the ACE, the integrated packet capture utility may not capture traffic from all interfaces, even when you configure the capture to capture from all interfaces. Workaround: None.
•CSCtg27611—When you configure the IP relay agent on the ACE VLAN interfaces, due to the fix for CSCtb60599, the ACE DHCP relay agent forwards DHCP unicast packets which is incorrect. Workaround: None.
•CSCtg28579—When you configure the 128th global service policy in the running configuration, the ACE displays an error that is not informative. Workaround: None.
•CSCtg31255—When you change the cookie name of an HTTP-cookie sticky group, the name does not change. Workaround: Remove the cookie group. Then, reapply it to the policy map.
•CSCtg37325—During normal ACE operating conditions, the configuration manager becomes unresponsive and the ACE generates a core file. Workaround: None.
•CSCtg45244—After you add multiple configurations and then remove them by deleting contexts, the ACE becomes unresponsive. The backtrace indicates a loop when removing from the good list. Workaround: None.
•CSCtg52619—When the ACE core directory contains the core.number, core_server_log.number.gz and core_client_log.number.gz files, the ACE repeatedly reports the following message:
03:54:55 : %ACE-2-443001: System experienced fatal failure.Service name:System Manager
(core-server)(8119) has terminated on receiving signal 11,system will not be reloaded
Workaround: Reboot the ACE.
•CSCtg53126—When you attempt to delete a server farm with the no serverfarm host command, the ACE displays the following error message:
Error: serverfarm `serverfarm_name' is in use. Cannot delete!
The configuration manager thinks the server farm is still applied to the load-balance policy. Workaround: None.
•CSCtg62782—When the software and license on the ACE are compatible, ANM does not display their compatibility status. The XML show ft peer 1 detail command on the ACE is not correct. Workaround: None.
•CSCtg70470—After you add multiple ACE configurations and then remove them by deleting contexts, the ACE becomes unresponsive. The backtrace indicates a WeightBucket-related operation. Workaround: None.
•CSCtg79608—When you disable normalization for remote real servers, the ACE may resend a TCP RST for the probe. For a probe TCP SYN, the remote real server responds with a TCP RST. The ACE may respond with a TCP RST in the case where the real servers are reachable through a gateway and you have disabled normalization on the source interface for probe traffic. This issue may occur only if the remote server is another ACE and the VIP is out of service. Workaround: Perform either of the following:
–Enable normalization on the source interface for probe traffic.
–Configure the following ACL command on the ACE for every remote ACE VIP and port for probing from the ACE:
access-list test1_acl line 1 extended deny tcp host RSERVER_VIP_IP eq
RSERVER_VIP_PORT host ACE_INTERFACE_IP
•CSCtg82096—When the ACE has different inbound flows that have a common outbound flow, it sends the RADIUS accounting response from the wrong VIP address. Workaround: Force source NAT upstream to avoid this situation in which inbound flows share a common outbound flow.
•CSCtg84678—When you attempt to log in to the ACE console with a username containing an @ character, the login attempt fails. For example, if you use the user@cisco username, as soon as you type the @ character, the ACE deletes everything before the character. The login attempt also fails when you enter a username with the # character, acting as a backspace and deleting a character before it. Workaround: Perform either of the following:
–Log in to the ACE over SSH.
–Cause a failed login attempt on the console first before attempting to login with a username with an @ character.
•CSCtg87843— After you change the configuration in a large ACE configuration and enter show commands, the CLI becomes unresponsive for a period of time. In this case, the show processes cpu | include cfgmgr command displays one of the configuration manager (cfgmgr) processes consuming CPU resources. After you apply the configuration change, the cfgmgr CPU usage goes to zero, and the CLI becomes unresponsive. Workaround: Wait until the cfgmgr completes its previous operation before entering the show command.
•CSCtg87927, CSCtf42007—When the ACE has a large configuration and a probe changes state, the configuration manager may consume high usage of the CPU and lock out CLI operations for a period of time. Workaround: None.
•CSCtg96913—When traffic is flowing through the ACE and you change the configuration with respect to the real server, probe and clearing statistics, weight bucket for the real server may become corrupted causing the ACE to reboot. This is an one-time occurrence. Workaround: None.
•CSCth06234—When you configure a match statement in a match-all class map, you cannot modify the statement. Workaround: Remove the class map from the associated Layer 3 policy and then modify the match statement.
•CSCth07612—When you apply or modify ACLs or object groups to an ACE that has operated for a long time and undergone many ACL configuration changes, issues in the ACL object group expansion during the configuration download may cause an unexpected traffic drop. The show interface command displays a non-zero download failure counter, similar to the following:
Access-group download failures : 8
Workaround: Remove and readd the object group.
•CSCth10734—When you include any address with the show np [1|2] me-stats "-N 0x....." command, it calls an internal function with an invalid address that may cause the ACE to reboot. CSCtg73822 fixed the rebooting of the ACE. Workaround: None.
•CSCth12446—When the ACE is using a 1-Gbps throughput license, the throughput output displayed through the show resource command is rounded to the nearest thousand. For example, a value of 134217728 is rounded to 134217000. This issue does not occur with other throughput licenses. Workaround: Install a throughput license that is not 1 Gbps and then uninstall the license.
•CSCth13078—When you configure multiple interfaces to share the same multi-match policy, you cannot ping a VIP defined on the ACE. Workaround: Removing and reapplying the class map in the multi-match policy may clear this issue.
•CSCth13221—When TCP probes are sent to specific services which may cause unusual TCP sequences to occur, the ACE may run out of sockets for the probes. The output for the show probe detail command displays the following:
Internal error: Out of sockets
Workaround: Increase the open timer for the probes to increase the time it takes before the ACE runs out of sockets. If you reboot the ACE while the problem is occurring, it temporarily clears this issue.
•CSCth15465—When you use the send-data command in a TCP probe and the server sends a FIN ACK after it receives the data from the ACE, the ACE incorrectly assumes it receives a non-FIN packet containing no data and displays the following error message:
Last disconnect err : Unrecognized or invalid response
Workaround: Do not use the send-data command in a TCP probe.
•CSCth16935—Under normal operating conditions, Linux bash-shell executables occasionally core on the ACE. These cores are either incorrectly packaged as Virtual Shell (VSH) cores or not packaged and compressed and left in the core: directory as core. Workaround: None.
•CSCth24858—After running the Device Manager GUI for more than a few months or a year, it cannot deploy a configuration to the ACE. There is no impact on the ACE load balancing. It continues to work. Workaround: Enter the dm reload command from the ACE CLI to restart the Device Manager.
•CSCth38233—In both FT or non-FT configurations, normally when you add a new entry to the object group, it expands. If you add a new entry after removing and adding the first access list where the object group is associated, it does not expand. Workaround: Remove all of the access list and readd it.
•CSCth39502—The ACE divides the sticky table and cookies between its two IXP network processors (NPs). If a connection on one NP uses a cookie with a hash that resolves to the other NP, the NPs must perform additional inter-IXP messaging to process the cookie. In a default TCP connection configuration, if the server sends 32 K or more of data in less than 10 milliseconds (msec), a zero window may result on the backend. Some server TCP stacks may inadvertently introduce a 5-second delay in this situation. The ACE should advertise a non-zero window to the sending server when the buffers are released. Workaround: You can configure the set tcp wan-optimization rtt 0 command to apply TCP optimizations to packets for the life of a connection. However, this command results in increased resource consumption.
•CSCth42261—When you configure a role with the real-inservice feature and assign this role to a user, this user cannot use the inservice standby command. Workaround: Instead of the real-inservice feature, configure the server farm feature in the role.
•CSCth42803—Under normal operating conditions with logging configured by default, the ACE unexpectedly reboots and generates a core file for the syslogd process. Workaround: None.
•CSCth45415—When you log in to the A3(2.5) ACE Device Manager (DM) as a nonAdmin user and attempt to suspend or activate a server under Operations > Real Servers, the change is applied on the ACE but immediately rolled back. Workaround: Use the ACE CLI or log in to the Device Manager as the Admin user. Or, add the following rules to the custom role for the nonAdmin user:
rule 8 permit create feature config-copy rule 9 permit create feature exec-commands
•CSCth46220—When the ACE is running a software version earlier than software version A3(2.7) and load balancing RADIUS traffic, multiple client-side connections simultaneously associated with a single server-side connection cause a leak in which the connections on the NP are not reclaimed. This event causes the consumption and hitting of 2 million internal maximum connections per real server. After a period of time, traffic is dropped. Workaround: Reboot the ACE when the connections per real server is 1.5 million per NP.
•CSCth50079—When you enter the show logging message all command on the ACE appliance, it displays the following syslog IDs that are used for the debugging purposes only: 5123456, 6101005, 6101006, 6101007, 2888006, and 6101004. Workaround: None.
•CSCth53135—When you add a class map to a configuration with a large number of class maps and the ACE fails to add it to the running configuration, the ACE displays an error message that does not describe the actual issue. Workaround: None.
•CSCth54206—When the ACE has a small number of connections, an SSL negotiation failure occurs. The change cipher spec message is sent after the encrypted finished message. Workaround: None.
•CSCth59240—When you configure or change a command to contain regular expressions that are long and complex, further changes are not possible and the ACE may become unresponsive for a long time. Workaround: Modify the regular expressions to make them shorter.
•CSCth63549—The standby ACE may have a higher number of connections than the active ACE Workaround: Configure a shorter connection inactivity timeout.
•CSCth64330—If you configure TCP probes with small intervals and set the termination mode as forced, the TCP probe stops firing if the server sends an RST after the TCP handshake. Workaround: Remove and readd the faulty probe from real server.
•CSCth64376—When you attempt to log in to the ACE using remote authentication with a username that has special characters that are not supported by the ACE, the securityd process becomes unresponsive and the ACE reboots. Workaround: Do not log in to the ACE with usernames with special characters that are not supported by the ACE.
•CSCth64503—When you register an organization name containing an & with a certificate authority (CA) and attempt to create a certificate signing request (CSR) on the ACE with this organization name, the ACE displays the following error message:
Error: Organization name cannot be composed of these special characters <>~!@#$%^*\&
Workaround: Use an external tool (for example, OpenSSL) to generate a CSR or request the CA to generate the key pair and certificate for the ACE.
•CSCth72012—When you configure TACACS+ on the ACE, the ACE does not account for configuration mode commands that contain sensitive information (for example, keys and passwords). These commands do not appear in the local ACE accounting log or 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 logged but the sensitive information is masked. Workaround: None.
•CSCth76768—When you configure the UDP port equal to 5060 (udp eq 5060) on the active ACE, it appears as the udp eq sip command in the show run command in the active and the standby ACEs. When a bulk synchronization occurs, the standby ACE does not recognize the command and transitions to the Cold state. UDP equal to 5060 is not standard port on the ACE. Workaround: Use the tcp-udp eq 5060 command.
•CSCth85499—When the same SNMP request identifier is used in a previous SNMP GET and GET NEXT requests to the ACE, and an SNMP agent is polling the ACE, the ACE may incorrectly respond to the SNMP request. Workaround: Perform the following:
1. Change the SNMP agent to use unique SNMP Request Identifiers for each SNMP request.
2. Wait at least 10 seconds between SNMP requests that use the same SNMP request identifier.
•CSCth88774—On a rare occasion, when you change an HTTP action list on the ACE, the ACE reboots and creates the cfgmgr_log.1393.tar.gz core file. Workaround: None.
•CSCti02044—When the ACE is using SSL client authentication and is oversubscribed beyond capacity, HTTPS probes continue to fail after traffic has failed over to the standby ACE. The connections become stuck. Workaround: Do not allow the ACE to be oversubscribed. Clear all the connections and allow the connections to continue.
•CSCti11180—If the client or server retransmits a packet and the remote end exceeds the acceptable window size, the ACE incorrectly drops the retransmission packet and increments the [Drops] fp TCP window left edge counter. Workaround: Disable normalization or correct the client or server to honor the window sizes.
•CSCti11892—The ACE treats the deny function inside a management policy or class map as a SKIP. The ACE does not deny the traffic. Instead, it skips the class map and try to match another one. Workaround: None.
•CSCti44311—When you change the default destination port for an HTTP probe, the probe does not append the port to the Host tag in the HTTP request and the ACE receives an HTTP/1.1 404 Not Found error. Workaround: Configure the probe with the header Host header-value command to specify and append the destination port to the host in the HTTP request.
•CSCti49790—When you use the CSS2ACE conversion tool and the input CSS configuration has SSL urlrewrite and associate references for certificates and keys, the converted configuration does not have SSL urlrewrite and SSL-proxy configurations do not have certificate and file names. Workaround: Manually add the required configurations.
•CSCti57248—After you correct a license mismatch on a standby ACE, the show ft group detail command displays the following:
Running cfg sync enabled: Disabled
Workaround: Reboot the standby ACE.
•CSCti63000—When a client sends a SYN on an existing connection in a Layer 7 connection, the ACE responds to a TCP SYN with an ACK, and an incorrect ACK sequence number. Workaround: None.
•CSCti63055—The ACE does not reset a SYN for an existing Layer 7 connection if the sequence number is within the receive window. Workaround: None.
•CSCti68051—When selecting a bridged VLAN as the SNMP server trap source, the ACE uses the BVI internal interface ID for the agent address instead of the BVI interface IP address. Workaround: Use a non-bridged VLAN.
•CSCti74138—When the static host route and ARP entry are for the same host, the ACE reboots due to the itasca_route_mgr service. Workaround: None.
•CSCti77480—When you configure multiple real servers in multiple server farms in multiple contexts and traffic is hitting all the contexts, some real servers in the RETCODE_FAILED state recover more slowly than the time configured for the reset timer. Workaround: None.
•CSCti85584—When you configure the ACE appliance to perform regular expression matching, these regular expression configurations consume more memory than on the ACE module. Workaround: None.
•CSCti88459—When you enter an SSL crypto show command, the ACE generates a VSH core file. The VSH core file does not cause the ACE to reboot. Workaround: None.
•CSCti90236—When ANM or a script at bootup time issues the show resource usage all command, the standby ACE console displays command parse errors and the context transitions to the STANDBY_COLD state. Workaround: After an ACE boot has completed, resynchronize the configuration.
•CSCtj18827—When you configure the ACE for bridge mode and it has a static ARP entry for the real server, after the ACE reboots, the ARP entry for a real server is in down (dn) state. Workaround: Remove the static entry and readd it.
•CSCtj25371—When the ACE parses an SNMP query, SNMP causes the ACE to reboot and generate the cfgmgr_log.954.tar.gz core file. Workaround: None.
•CSCtj28235—When you remove the last VIP address and reapply it to a Layer 4 class map, the VIP address is not updated in the ARP cache table. Workaround: Remove and add the service policy under the client interface.
•CSCtj36622—When you configure an active ACE for Layer 4 load balancing and a switchover occurs, after the connections are synchronized, HTTP GET requests fail. Workaround: None.
•CSCtj39252—When you configure an object group with a description field that contains a single-quote character ('), ANM does not poll the object-group configuration from an ACE. Workaround: Remove the single-quote character (') from the description.
•CSCtj44768—When a configured TCP probe becomes active on the ACE and the server sends out-of-band data to the ACE, the ACE reboots and generates an hm_core file. Workaround: None.
•CSCtj45034—When you configure a Session Initiation Protocol (SIP) probe for health monitoring (HM), the ACE may incorrectly display the probe as down due to the ACE using the same Call ID for multiple probe instances to different configured real servers. Workaround: Configure the ACE with a different probe type.
•CSCtj48791—After upgrading the ACE, FT auto-sync may not work and active-to-active scenario may occur causing an outage. The banner command had special characters, like a quote ("). The banner command may be deleted on one context. Workaround: Disable auto-sync, manually reconfigure the banner command on both ACEs context, and reenable auto-sync.
•CSCtj48953—The ACE appliance reboots with an NP 0 failed :NP ME Hung error and generates core files. Workaround: None.
•CSCtj56045—When you incorrectly configure a sticky server farm through the CLI or XML, the configuration may fail. Workaround: Reboot the ACE and the configuration succeeds.
•CSCtj67143—When you configure a probe on a host real server and the probe state changes from FAILED to SUCCESS, the ACE generates a cesRserverStateUp trap. However, the ACE should generate a cesRserverStateChange trap. Workaround: None.
•CSCtj71311—When the ACE receives a cookie string that contains many cookies and encounters a space character in the cookie value, it stops processing the cookies. Spaces are not permitted in the cookie name or cookie value. Persistence or stickiness fails. Workaround: None.
•CSCtk64731—When you configure the return code a server farm on the ACE and load-balanced traffic is flowing to multiple contexts simultaneously, occasionally some real servers may remain in the RETCODE-FAILED state. Workaround: Enter the no inservice command followed by the inservice command to return the real servers to the operational state on the NP.
•CSCtk64763—When you manage the ACE with SNMPv3 in CiscoWorks LAN Management Solution (LMS)/CiscoWorks Resource Manager Essentials (RME), the ACE intermittently reports false usmStatsUnknownUserNames (1.3.6.1.6.3.15.1.1.3.0) during LMS/RME inventory collection, and the RME inventory collection may fail occasionally. Workaround: Manage the ACE with SNMPv2 in LMS/RME.
•CSCtk66976—When you set the window scale to ALLOW by configuring the tcp-option window-scale allow command in a parameter map, the window size calculation for the Layer 4 flows does not occur. Since the ACE calculates the window size without taking the window scale into account for Layer 4 flows, the ACE may drop some packets that are legal. Layer 7 flows are not affected. Workaround: Remove the tcp-option window-scale allow command from the parameter map configuration.
•CSCtk76671—When you enable AAA authentication and remote accounting for TACACS on the ACE, verify the creation of a user by using the show users and show user-account commands, and verify AAA accounting, if you enter the no username name command, the ACE reboots. Workaround: None.
Software Version A3(2.7) Open Caveats
The following open caveats apply to ACE software version A3(2.7).
•CSCsu40160—When the ACE configuration has more than 500 service policies and you can ping all VIP addresses, some VIP addresses are not served at all. Workaround: None.
•CSCsu55909—In a redundant configuration, when you configure the ACE with 20 contexts, apply it to the active ACE, and then bring up the standby ACE with the configuration, the active ACE transitions into the Cold state with the following error:
Error on Standby device when applying configuration file replicated from active
Workaround: First bring up the active and standby ACEs individually and then enable redundancy.
•CSCsv64123—When you configure an SNMP user, both active and standby ACEs crash. Workaround: None.
•CSCsx06085—When you enable UDP boost on the ACE, the server-initiated traffic fails because the destination port changes to the source port value. Workaround: Disable UDP boost.
•CSCsx71993—When the ACE, running in software release A3(2.1), is not sending any traffic and traffic occurs only because of an ICMP probe, the show conn command displays the incorrect data 18 percent of the time. But in software release A3(2.1.50), this command displays the incorrect data 87 percent of the time. Workaround: None.
•CSCsz71578—When you apply a service policy globally and then add the VLANs, the ACE displays ACL-merge errors for newly added VLANs and traffic does not flow through them. Workaround: Remove the global service policy and then reconfigure it.
•CSCsz88519—When you configure a TCP-based syslog server and the syslog server application on the remote system is down even though it is reachable from the ACE appliance, the ACE becomes unresponsive and most of its commands either time out or respond slowly. Workaround: Either bring the syslog server application up or remove the configuration for the TCP-based syslog server.
•CSCta74000—The ACE may fail to download a certificate revocation list (CRL). In some cases, the CRL fails to download when it is reapplied to the SSL proxy that is being used in certain VIPs if the previous applications to the SSL proxy had failed to download the same CRL at the point when the CRL server was down. When this situation occurs, the ACE stops downloading the CRL. Workaround: Remove the CRL and reconfigure it.
•CSCta87584—Connections may get dropped intermittently when you use persistence rebalance in a configuration and a rebalance is performed across traffic policies. This behavior typically occurs in a configuration with two different server farms that both contain the same real server with different ports, and the server farms are attached to two different Layer 7 load-balancing policy maps. Workaround: None.
•CSCtb79312—Front-end and end-to-end SSL connections may fail to complete. This behavior can occur during the following configuration settings:
–MTU setting that is larger than or equal to 9000
–End-to-end SSL or front-end SSL configured
–SSL connection with TCP data segments at MTU
Workaround: Do not use an MTU that is larger than or equal to 9000.
•CSCtd19335—If RADIUS traffic is being sent and 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 show conn rserver command.
•CSCte76795—After you change the resource-class configuration and traffic is successfully passing through the ACE, the compression statistics displayed by the show service-policy command do not update. Workaround: None.
•CSCte81895—When you configure HTTP inspection with the URL logging feature and change the HTTP inspection configuration while traffic is passing through the inspection engine, the ACE may reboot due to an inspection engine misbehavior. Workaround: Disable the URL logging feature.
•CSCte98511—When you configure the ACE with the maximum number of elements or match source statements and you add or remove match statements, match item object entries leak. Workaround: None.
•CSCtf02311—When you configure NAT for DNS VIP traffic, the rewrite for an A record with a third-party address may not occur. The ACE forwards the DNS query response from the server with the original A-record address. This issue occurs only with the third-party address for which the ACE fails to find the route. Workaround: You can prevent this issue by adding a static route for the third-party subnet through the following command, ip route third-party-subnet mask gateway.
•CSCtf06483—When you configure HTTP inspection with SSL termination and Layer 7 load balancing, and add inband TCP and retcode health monitoring configurations to the same server farm while HTTP and HTTPS traffic passes through the ACE, the ACE may reboot due to the HTTP inspection engine accessing an invalid session state. Workaround: Disable the HTTP inspection feature.
•CSCtf28699—When you enable the server-connection reuse feature, and a real server becomes unreachable or the outbound interface is shutdown, a few dataplane connection entries may become stuck in a race condition and cannot be used by the ACE. Workaround: Reboot the ACE to recover the resources.
•CSCtf33109—When you configure a real server with the fail-on-all command in a server farm and more than one probe fails, the real server is in the OPERATIONAL state. If you remove the fail-on-all command from the server, it remains stuck in this state. The real server should transition to the PROBE-FAILED state. This issue also occurs when you configure a server farm with the fail-on-all command because the fail-on-all action applies to all real servers in the server farm. Workaround: Enter the no inservice command followed by inservice command to restore the real server and transition it to the PROBE-FAILED state even when one probe fails.
•CSCtf39663—When you configure the send-data command with a length greater than four characters inside a finger probe, the probe fails. When you configure the expect regex command with ".*" string, the probe also fails. Workaround: Configure the probe with a send-data length that is less than 4 characters.
•CSCtf94950—When you remove a class map with a sticky load-balancing policy, the ACE removes sticky groups from other policies that are still using them. Workaround: Removing and adding the sticky group to the policy should download the correct configuration.
•CSCtg03038—When you configure an invalid OID in an SNMP probe, the probe fails due to parse error for the configured OID. Each failing SNMP probe leaks one socket. Eventually, the socket resources for health monitoring are exhausted causing all the probes on the system to fail with Out of Sockets errors. Workaround: Correct the OID under the SNMP probe and reboot the ACE.
•CSCtg31975—Symptom: System account shell access. Condition: A system admin account in the ACE software may allow an authenticated user to inject shell commands. This account does require authentication. Workaround: None.
•CSCtg43409—When you configure DHCP-related changes on the VLAN and BVI interfaces, the ACE becomes unresponsive due to a cfgmgr termination. Workaround: None.
•CSCtg46244—When the ACE has a high rate of SIP calls per second and the SIP inspection engine encounters any errors due to resource allocation failures, the ACE may reboot. This issue occurs only when the SIP inspection engine encounters failures in the initial packet processing, for example, memory allocation, object allocation, and inspection configuration version mismatch failures. Workaround: Disable the SIP inspection feature, if possible.
•CSCtg53196—When you configure the ip options clear or ip options clear-invalid command, and the ACE receives packets that contain the IP options, it drops the packets. Workaround: None.
•CSCtg56876—When you enter the show telnet maxsession context_name command, where the context_name argument is an existing or nonexisting context, the ACE generates a vsh core file in the core directory with a sig 11, Segmentation fault and then displays an internal error during command execution error message. Workaround: None.
•CSCtg67860—When you configure multiple track probes in two user contexts and enter the show cfgmgr internal table track-probe command, the ACE becomes unresponsive due to a Cfgmgr process failure. Workaround: None.
•CSCtg76150—When you configure an inline match statement that has a special character or space in its name under an Layer 7 policy, the checkpoint rollback fails. Workaround: Do not configure inline match statements with special characters or spaces.
•CSCtg96456—When you configure the maximum number of the VIP statements in a single class map of 254 and then delete one of the VIP statements, the ACE cannot add a match VIP address in a single class map and displays the following message:
Error: Exceeded maximum match item limit for the class-map
Workaround: Remove the class map and the reconfigure it again with all of the VIP addresses.
•CSCth00054—The issue is due to an open SIP data channel pinhole facing the client direction. When you allocate a valid port range from 1025 to 65535 for the PAT port and the ACE performs an implicit PAT, the ACE includes the 5060 and 5061 control ports. If the ACE uses these two ports and the next packet matching these pinholes is a new call control packet instead of data, the ACE mishandles the new control packet and promotes the pinhole.
The traffic itself is not interrupted. However, when the ACE releases the resource, since it handled this control packet and the flow as a pinhole promoted data channel and although it does not affect classification in which the flow is still treated as SIP control or inspection, it does not send it for load balancing to release the policy map entry and eventually a resource leak occurs. Workaround: None.
•CSCth04993—When you configure an ACE interface with single NAT IP address in the NAT pool and the ACE receives SIP UDP traffic, it resets subsequent SIP TCP traffic. Workaround: Perform either of the following:
–Perform a checkpoint rollback to a non-SIP configuration and then to the existing configuration.
–Increase the number of IP addresses in the NAT pool.
•CSCth25859—When you use the ACE CLI to configure a context with the + (plus) character in its name and then you attempt to access it through the Device Manager GUI, an error message is displayed. Workaround: None.
•CSCth30572—In a large multiple context configuration, the arp_mgr becomes unresponsive while applying the configuration. Workaround: None.
•CSCth40158—The ACE does not bridge the TCN-BPDU. The ACE does not have a way to handle TCN-BPDU and considers TCN-BPDU as an invalid BPDU packet and drop it because of bad Ethernet frame length. Workaround: None.
•CSCth56931—When you enable FTP inspection and logging to a local buffer at severity 7 (debugging) on the ACE, the ACE reboots and the syslogd process generates a core file. Workaround: None.
•CSCth89244—When you place interfaces up and down several times or configure several interfaces or static routes, some interfaces or static routes may not work properly and connectivity to peers can be lost. Workaround: None.
•CSCtj04665—When you configure a match source address and traffic is sent from that source address, a loadbalance (LB) crash is seen in the policy selection. Workaround: None.
•CSCtj04924—When the Layer 7 TCP path is overutilized that causes the Timer Freelist Empty to be hit several times, the ACE reboots because of the Timer Freelist corruption. Workaround: Reduce the work load of the Layer 7 TCP path.
•CSCtj20321—When you enable XML, the XML output is not seen for the show serverfarm name retcode details command. Workaround: None.
•CSCtj21661—When you configure two or more probes to a server farm, the probe instance is not created after entering the no inservice command, removing one of the probes on the server farm and entering the inservice command on the real server. After this problem occurs, you can correct it by reentering the no service command and the inservice command. Workaround: None.
•CSCtj28496—When approximately 8 k zombie scripted hm processes were on a ACE with a very highly scaled scripted probe configuration, after 48 hours, the ACE rebooted due to low memory. Workaround: None.
•CSCtj38735—If you configure a port channel link between two ACE appliances and configure redundancy over multiple interfaces in the port channel, due to the load-balancing mechanism, the heart beat (HB) always goes though one interface only. If this interface flaps due to port hashing convergence, the ACE may drop the HB for 2 to 4 seconds. Both ACEs may become active-to-active during this time. This issue is a limitation of the current fault tolerant implementation. Workaround: Do not set very aggressive redundant HB and avoid configuring carrier delay on the interfaces.
•CSCtj65382—When you configure an ECHO TCP probe with send-data and regular expression (regex) values, the probe always passes even if the server sends a regex that does not match the sent-data value. Workaround: You can use a TCP probe with send-data and regex values as required instead of an ECHO TCP probe.
•CSCtj65888—When a network error, such as a network interface going down, occurs during the bulk importing of crypto files, the temporary storage space for imported crypto files is not gracefully released. Some of the temporary files remain in the temporary storage area until the system is reloaded. Bulk import procedures do not perceive network failures or inactivity if the transfer of the files has begun. Workaround: None.
•CSCtj66787—When you perform dynamic configurations of usernames in multiple contexts and enter the no username name command in a user context, the ACE unexpectedly reboots and generates an SNMP core file. Workaround: None.
•CSCtj93002—When you connect all four data ports on the ACE appliance to a POE switch and the DP console is also connected to the POE switch, the ACE becomes unresponsive and reboots. Workaround: Do not connect the DP console cable to the POE switch.
•CSCtj95317—Under normal operating conditions, the ACE experiences an DP crash but did not generate all required core files for analysis. Workaround: None.
•CSCtk01910—When you configure the ACE with access lists, objects group and DHCP, and apply the configuration to an interface, an ACL Merge failure occurs. This issue can cause the configuration to be incomplete and you must manually back it out. Workaround: When you configure the ip dhcp relay enable command, do not configure a duplicate configuration. If you initially configure the command, the ACE does not display an error. However, when you configure the command again, the ACE displays an error.
•CSCtk06459—When you incorrectly set the clock on the ACE appliance to the year 2002 and the ACE is using a demo bandwidth license that expires on 12/31/2010, the license expiration did not properly take effect. Workaround: Manually set the correct time and date by using the clock command.
•CSCtk06591—When you configure the ACE to receive its time through the Network Time Protocol (NTP) and the actual time on the ACE is set incorrectly, if you install a 60-day demo license, it works correctly until you reboot the ACE. Workaround: Manually set the correct time correctly by using the clock set command.
•CSCtk53923—On a rare occasion, when you delete a username, the ACE appliance reboots with the last boot reason, service securityd. Workaround: None.
•CSCtk56222—When you configure two leastconns server farms that have the same real servers and each has a unique probe, if a real server in only one server farm transitions from the operational state to the probe-failed state and back to operational state, the ACE load balances all new connections to this real server. Workaround: None.
•CSCtk59163—When you configure the retcode in real servers in multiple contexts and after traffic is passing to the contexts, the ACE displays the real servers in retcode failed state while they are actually in the operational state irrespective of the resume-service timer. Workaround: None.
•CSCtk65542—When you change various VIP-related configurations on the ACE, the ACE load balancer incorrectly reports a KAL-AP load value of 255 for the VIPs forcing the GSS to mark the resource out of service. Workaround: Reboot the ACE to recover from this issue.
•CSCtk65800—When you configure inband HM or a retcode on a server farm, and add and then delete a failing probe on this server farm, some of the real servers in the server farm may remain in the Disabled state on the data plane and cannot service any connections. Workaround: None.
•CSCtk65818—When you configure max connections and an HTTP return code on the same server farm and traffic is hitting both of their thresholds for a real server, the real server may not serve any traffic. However, the show serverfarm command displays it in the OPERATIONAL state. Workaround: None.
Software Version A3(2.7) Command Changes
Table 3 lists the commands and options that have been changed in software version A3(2.7).
Table 3 CLI Commands Changed in Version A3(2.7)
|
Mode
|
Command and Syntax
|
Description
|
Debug |
[no] debug cfgmgr limit-regex-dnld |
Per CSCtg87843, to avoid compiling the Layer 7 match statements when configuration changes do not need Layer 7 compilation, you can optionally enable regex download optimization through the new debug cfgmgr limit-regex-dnld command. Use the no form of this command to reset the default behavior and disable regex download optimization. |
Exec |
show np [1|2] me-stats -shttp |
Per CSCtj42966, the output for this show command now includes the Cookie parse errors ignored counter that increments when the cookie-error-ignore feature, enabled by the parameter-map HTTP cookie-error-ignore command, is in effect for a request. |
Exec |
show download information |
Per CSCtg87843, the new show download information command displays the regex download optimization status, enabled or disabled. |
Exec |
show np [1|2] me-stats -stcp |
Per CSCtj59951, the output for this show command now includes the Reassembly timeouts counter that increments when the timer for a reassembly queue of a TCB times out, indicating that the connection will be closed. |
Exec |
show parameter-map name |
Per CSCtj42966, the output of this show command now displays the status for the cookie-error-ignore command, disabled or enabled. |
Exec |
show running-config name [id] |
Per CSCsu51832, the show running-config command has a new id option to filter the running-config file based on the ID, for example:
|
Exec |
show snmp group name |
Per CSCsy6632, the show snmp group name command now correctly displays the intended output. Previously, it did not display any output. |
Configuration |
[no] crypto rehandshake enabled |
Per CSCth85502, this command allows you to enable SSL rehandshake for all contexts on the ACE. Enter this command in the Admin context. Use the no form of this command to reset the default behavior. By default, the ACE rejects SSL rehandshake and you can enabled it at the SSL-proxy level by configuring the rehandshake enable command in the SSL parameter map. |
Configuration |
[no] regex compilation-timeout minutes |
Per CSCth59240, this new command allows you to configure the timeout for regular expression (regex) compilation. When you configure a regex and its compilation is longer than the configured timeout, the ACE stops the regex compilation. The minutes argument is the time period in minutes. Enter an integer from 1 to 500. The default timeout has been set to 60 minutes. This command is available only in the Admin context for an admin role and is applicable across all contexts. For example, to configure a compilation timeout of 80 minutes, enter:
host/Admin(config)# regex compilation-timeout 80
Use the no form of the command to reset the default timeout of 60. |
Configuration |
service-policy input ... |
Per CSCtg28579, when you enter this command and the number of globally configurable service policies has reached its maximum of 128, the ACE now displays the following error message:
Error: Maximum Number of Global Service-policy reached
for the context
|
CSR parameters |
organization-name name |
Per CSCth64503, the ACE now accepts the & character in a CSR organization name. |
Parameter map HTTP |
[no] cookie-error-ignore |
Per CSCtj42966, this command configures the ACE to ignore malformed cookies in a request and continue parsing the remaining cookies. Use the no form of this command to reset the default behavior. By default, when the ACE finds a malformed cookie in a flow, it stops parsing the remaining packets. |
Policy map load balancing HTTP |
class ... |
Per CSCth53135, when you add a class map that exceeds the limit of maximum class maps, the ACE now displays the following error message:
Error: Reached the limit of L7 class-map that can be
assigned to L7 policy-map(4k - 4096)
|
Probe HTTP or HTTPS |
[no] append-port-hosttag |
Per CSCti44311, the new append-port-hosttag command allows you to configure the ACE to append the port information in the HTTP Host header when a non-default port is used. The following configuration is an example of this command:
request method get url /index.html
By default, this information is not appended to the header. Use the no form of this command to reset the default behavior. |
Real server redirect Server farm redirect Server farm redirect real server |
probe name
ip address address routed |
Per CSCsq87212, the ACE now allows you to configure a probe command to a redirect server. You can configure only probes with an IP address in routed mode under a redirect server, real and server farm. You cannot associate a scripted probe to a redirect server. For more information, see the "Probing a Redirect Server" section. |
Server farm host predictor |
autoadjust maxload |
Per CSCtd04486, the default autoadjust setting for the least-loaded predictor now is average load. Previously, the default setting was maximum load. The new autoadjust maxload command allows you to set the the least-loaded predictor to maximum load. Note If you previously configured the autoadjust command and upgrade to A(3.7) , see the note in the upgrade "Before You Begin" section. If you downgrade from A3(2.7) to A3(2.6), see the downgrade "Before You Begin" section. |
Software Version A3(2.7) System Log Messages
Software version A3(2.7) includes the following system log (syslog) message change per CSCtj33424:
901001
Error Message %ACE-2-901001 kernel: Arpmgr busy, Possible ARP flood, packets arp pkts
were dropped over last seconds secs
Explanation When the arpmgr is busy, this message appears on the console and this syslog.
Recommended Action If a large number of real servers are in the ARP failed state, bring them up. Verify that a broadcast storm is not occurring in the network. Verify that an ARP flood is not occurring in the network. For example, in the case of many servers with Active-Active NIC teaming in the network, change them to Active-Standby NIC teaming or similar.
Software Version A3(2.6) Resolved Caveats, Open Caveats, and Command Change
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats, command changes, and revised system messages in software version A3(2.6):
•Software Version A3(2.6) Resolved Caveats
•Software Version A3(2.6) Open Caveats
•Software Version A3(2.6) Command Changes
•Software Version A3(2.6) System Log Messages
Software Version A3(2.6) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.6).
•CSCsv74410—If a redundant configuration detects any component license mismatch between the active and standby ACE in the Admin context, the show ft group detail command displays the license mismatch and that the running synchronization is disabled. However, the running synchronization functionality is working correctly. Workaround: None.
•CSCsx51701—When any hash predictor is enabled on a server farm and the hashing result is to a real server that is in the STANDBY state, the ACE load balances the incoming request to that server instead of recalculating the hash and finding the next available server. Workaround: None.
•CSCsy77977—When the ACE reboots, it becomes unresponsive and does not generate a core file in the core: directory. However, it creates the dp_printk and hw_state files. Also, the show version command displays the DP failed in the last reboot reason field. Workaround: Reboot the ACE.
•CSCta99217—When you configure the ACE to use sticky with cookies along with persistence rebalance, if a client switches cookies and then switches back in mid-TCP stream, persistence rebalance works. However, the sticky table does not update when the connection closes and connections accumulate in the sticky database. Workaround: Clear the sticky database manually. Configure timeout-active connections.
•CSCtb07092, CSCsz96385—When heavy full-proxy TCP traffic flows which include but do not require SSL acceleration through the ACE, some connections are left open and must wait for an inactivity timeout or an explicit clear conn command to close. Workaround: None.
•CSCtb23691—When you modify the access list by using the access-list command and then enter the resequence option with this command in quick succession, the ACE displays the following error message:
WARNING: Unknown error while processing access-group. Incomplete rule is currently
applied on interface vlan_number. Manual roll back to a previous access rule
configuration on this interface is needed.
Workaround: Do not enter the resequence option with the access-list command in quick succession. Instead, reenter the access-list command again with a different line number.
•CSCtb84824—Occasionally, when the allocation of the regex resource is out of memory, the regex deny counter does not increment in the show resource usage command. Workaround: None.
•CSCtc05736—When you manually place a VIP in the out-of-service state by using the no loadbalance vip inservice command, the VIP continues to respond to ARP requests after it transitioned to the out-of-service state. Workaround: Reboot the ACE.
•CSCtc13833—When you configure the ACE to sends traps when a real server in a server farm changes state and the ACE detects a probe failure, it sends the cesRealServerStateChangeRev1 trap. When the real server becomes operational again and the probe succeeds, the ACE incorrectly sends the cesRealServerStateUpRev1 trap. This trap should only occur after user intervention (for example, after you enter the inservice command). The ACE should send the cesRealServerStateChangeRev1 trap when a server becomes operational after a probe failure. Workaround: Turn off the traps.
•CSCtc15453—When you configure the ACE to send SNMP server-farm traps and apply the server farm to a service policy, the ACE sends out duplicate server-farm traps for each change of state (up or down). Also, if you apply the server farm to more than one class map under a multi-match policy map, duplicate traps occur for each class map. For example, if you apply it to two class maps, four traps occur. Workaround: Turn off the traps.
•CSCtc77412—When the you use the XML management protocol to query the ACE for the context configuration and you enter the show context command in a user-configured context, the ACE can generate invalid XML output for the command. Workaround: Enter the show context command in the Admin context.
•CSCtd13725—When you configure load-balancing inspection with regex strings on the ACE, the output of the show service-policy command does not indicate whether the last regex compilation and download were successful. Workaround: Monitor the regex download status by enabling the syslogs.
•CSCtd16864—When you configure the mac-address autogenerate command with the ip dhcp relay command on an interface, the ACE fails to relay the DHCP request to the configured server and the counters displayed by the dhcp relay statistics command do not increment. Workaround: Remove the mac-address autogenerate command from the interfaces and reboot the ACE.
•CSCtd30151—After failover, the active ACE does not forward the server FIN and RST packets to the client for an existing open connection. This issue occurs only when the server closes its connection before the client sends any packets for this connection. Workaround: Disable normalization.
•CSCtd49660—When you create a context through the ACE CLI and then the ACE appliance Device Manager (DM) performs an automatic CLI synchronization and picks up the context, it returns the following error message:
Error in VC sync up,Error in Virtual transactions in DM
The problem continues after perform manual CLI synchronizations. Workaround: Perform a CLI Sync All in the Device Manager.
•CSCtd77826—When you add server farm, you may exceed the maximum-configurable object limit and cannot add the object. Workaround: Reboot the ACE to clear the problem.
•CSCtd79364—When you configure DNS inspection on the ACE and the ACE is processing large numbers of ICMP error packets, many ICMP single-leg connection entries become stuck and you cannot clear them with the clear conn command. Only a reboot clears those connections. Workaround: None.
•CSCte03192—When using a custom role configuration on the ACE, some Admin commands are not accessible. Workaround: Use the Admin role.
•CSCte18009—When you configure Fault Tolerance (FT) on the ACE or a link bounced and caused a transition on the FT interface, the ACE reboots unexpectedly and generates a core file. Workaround: None.
•CSCte19368—When you configure the following commands, you cannot define a user role group that differs from the default Network-Monitor group, even if the group has the same permissions including the Permit-Monitor group:
–snmp-server user name r1, where r1 is a previously defined role. It writes on the running configuration.
–snmp-server user name Network-Monitor
Workaround: None.
•CSCte28869—When the ACE is performing load balancing and using NAT or PAT, it may reuse a source port faster than the real server can clear it from its TIME-WAIT state. The ACE only uses 4K random source ports out of the available 64K source ports and cycles through the ports in 4 seconds. This issue can lead to the real server responding to a new SYN request with the wrong ACK or Sequence number which results in a connection termination. Workaround: None.
•CSCte44257—When you enter the show logging message all command from the CLI, the command output displays numeric syslogd identifiers for unsupported messages. Workaround: None.
•CSCte49070—When you configure customized scripted probes on the ACE and they crash repeatedly, the resulting core files may fill up the disk and prevent other operations from functioning properly. This issue impacts any activity that implies writing on the disk. Specifically, configurations are truncated because of the insufficient space on the disk. Workaround: None.
•CSCte52972—When you attempt to configure a large ACL through the Device Manager, it fails with an internal error. Workaround: Perform the following:
a. Configure the ACL through the Command Line Interface (CLI).
b. Divide the ACL into smaller pieces and configure them through the DM.
•CSCte54655—When you configure logging on the ACE, syslog messages are not generated when a server farm goes down or the VIP goes to the OUTOFSERVICE state. Workaround: None.
•CSCte56027—When the client is running an older web browser that only supports export-grade encryption, and the ACE is the server terminating SSL and using an International Step-Up or SGC certificate that enables the client's browser to step-up to stronger SSL ciphers, SSL connections hang because the SSL handshake does not complete.
To identify export grade browsers, use the about or help screens to display the supported encryption. Export browsers support 40 or 56 bit encryption only, while non-export browsers support 128-bit or better encryption. Workaround: Use a non-export browser on the client side, or downgrade to export-grade cryptography by using a non-StepUp SSL certificate on the server.
•CSCte57497—When you enter the show sticky database detail command, its output displays hexadecimal equivalents for IP addresses. Workaround: None.
•CSCte58902—Under normal operation, the ACE appliance reboots unexpectedly and generates an AVS core file. Workaround: None.
•CSCte61804—When you perform a dynamic configuration within a user context, the ACE reboots unexpectedly and generates a Configuration Manager (CFGMGR) core file. Workaround: None.
•CSCte72748—When the ACE is running software release A3(2.4) and you use the CSS-to-ACE tool to convert a CSS configuration to the ACE, the persistence reset remap command is not converted properly. Workaround: None.
•CSCte73886—When using KAL-AP with the GSS and redundant ACEs, the GSS may report an invalid Answer state if the ACE VIP fails on the active ACE but not on the standby ACE and there was no failover between the redundant ACE appliances. The active ACE VIP reports an OUTOFSERVICE state and standby ACE VIP reports an INSERVICE state. The VIP state discrepancy can occur due to a probe failure or some other manual intervention. Also, no failover has occurred between the redundant ACEs. The GSS Answer initially transitions to an OFFLINE state when the active ACE VIP fails and then the GSS Answer transitions back to an ONLINE state as it is now receiving KAL-AP load information from the standby ACE. Any new DNS query sent to the GSS receives an A-record VIP response because the Answer is ONLINE but connectivity to the ACE VIP fails due to the fact that the active ACE VIP is still considered down. Workaround: Use the ACE alias IP address rather than both the active and standby ACE interface VLAN IP address so that only the active ACE provides the VIP state.
•CSCte86185—When an FTP control channel has more than 256 data channels and is being closed, the ACE becomes unresponsive when running FTP traffic. Workaround: None.
•CSCte87777—When the ACE is running compression and the response advertised content length is smaller than the actual content size being transmitted, the ACE may encounter a particle double-freed error and the network processor may become unresponsive. Workaround: None.
•CSCte91072—When you configure the ACE with DNS inspection and logging, the ACE reboots unexpectedly and generates a Data Plane (DP) core file. Workaround: Perform the following:
1. Disable logging by using the no logging enable command in each context.
2. Remove DNS inspection from the configuration.
•CSCte91238—When you make a configuration change that changes the real server state from inservice to inservice standby and any configuration changes that results in a configuration download, the outstanding messages in the load-balance queues builds up over time and the ACE eventually becomes unresponsive. Workaround: None.
•CSCte93943—Occasionally, a connection sticks to the wrong server and the show sticky database command displays multiple entries for the same sticky hash. This issue occurs if there is an expired entry that is in the same bucket. Workaround: Clear the sticky database to remove the wrong entries.
•CSCtf02269—The CSS-to-ACE conversion tool does not properly convert catch-all rules from the CSS. Workaround: None.
•CSCtf02273—The CSS-to-ACE conversion tool attaches probes to redirect real servers and server farms on the ACE. However, the ACE does not allow the attaching of probes to redirect server farm or real servers. Workaround: None.
•CSCtf02275—When you use the CSS-to-ACE conversion tool to convert a service that accesses a page for the keepalive, the address is not converted. Workaround: None.
•CSCtf03771—When a VLAN interface was once configured as an SNMP trap source and you attempt to delete it, the interface cannot be remove and the ACE displays the following error message:
Error: interface in use. Cannot delete!
Workaround: Perform the following steps:
1. Reconfigure this interface as the SNMP trap source.
2. Use the no form of the snmp trap-source command to delete the trap source.
3. Remove the VLAN interface
•CSCtf07822—When you remove a class map from a policy map, the ACE continues to respond to the ARP request for the VIP. The show cfgmgr internal table vip command displays the removed VIP, the show arp command displays the ARP entry of the removed VIP, and the show cfgmgr internal table icmp-vip command does not display the entry for the removed VIP. Workaround: Reboot the ACE.
•CSCtf11816—If more than one pair of redundant ACE appliances are on the same network using the same VLANs and there are more than 21 total redundant contexts configured among the ACE pairs, it is not possible to choose Fault Tolerant Group IDs in a manner in which they are not reused. Since the VMAC, the MAC address to alias IP and VIPs, are based on the FT group ID, reusing FT group IDs leads to MAC address collisions. This problem occurs because the allowable FT group IDs are 1 to 21. To allow a second pair of ACEs on the same network, additional FT Group IDs from 21 to 42 would be required. Workaround: Use fewer than 21 redundant contexts. Use separate VLANs for each ACE pair.
•CSCtf17485—When you configure probes on the ACE, the number of management connections displayed by the show resources command slowly increases until there are none available and then any configured probes fail. Workaround: Remove all configured probes so that the management connections are not needed.
•CSCtf17706—When you add more than seven header names or cookie names to a load-balancing policy, the ACE displays the following error message:
Error: Maximum 10 http header map is allowed per policy
Workaround: None.
•CSCtf25326—While you log in to and log out of the ACE in parallel and many times, an MTS leak occurs with the AAA process. Workaround: None.
•CSCtf36720—When you use the context command to create a user context through the ACE CLI, the command fails and the ACE displays a message that the disk is out of space which is not the case. Workaround: Complete an RMA for the Compact Flash (CF) in the ACE appliance to determine if it clears the condition.
•CSCtf38977—When you configure a username with the name of user, the show running-config command does not display this username. Also, the copy running-config startup-config and write memory commands do not save this username in the startup-config file. Workaround: Do not configure the username with the name of user.
•CSCtf43153—When you use the ACE appliance Device Manager GUI to the change the passwords of users created in a context other than the Admin context, the changes do not work. Workaround: Use the ACE CLI to change the password.
•CSCtf45668—When the ACE imports X.509 certificates with public keys larger than 2048 bits, the ACE displays the following error message:
Error: Key Size in the file exceeds system limit (2048 bits in length), not imported
Workaround: Use certificates with public keys that are 2048 bits or less.
•CSCtf49480—When you configure the ACE with HTTP inspection on a policy map, some XML tags are missing in the XML response for the show service-policy command. Workaround: None.
•CSCtf63909—When you enter the show ft group brief command, it does not display the context_id in the XML output. Workaround: None.
•CSCtf70114—When you configure a port-channel number greater than three through the port-channel command and then upgrade the ACE appliance to software release A3(2.5), both the active and standby ACEs reboot repeatedly and generate a portmgr core file on the disks. Workaround: Configure the port-channel number to three or less.
•CSCtf71057—When you configure client authentication with a multi-tiered certificate and the client sends a certificate chain, client authentication fails if the authentication group contains the subordinate CA certificate instead of the root CA certificate. Workaround: Configure the authentication group with the root CA certificate.
•CSCtf72227—When server-side messages contain an RTSP request method, the ACE terminates the RTSP connection prematurely and media playback fails. For example, OPTIONS and SET_PARAMETER are RTSP server-side request methods. Workaround: None.
•CSCtf81824—When the ACE is running software release A3(2.5) and you enable the debug cfgmgr info command, the ACE becomes unresponsive. Workaround: None.
•CSCtf83892—When you use the show resource usage command, it displays that the ACE has a maximum connection rate of 1000000. It should display 120000. Workaround: None.
•CSCtf98697—When you delete a VIP, the ACE may not free some regex memory and regex memory is leaked. Workaround: None.
•CSCtf99201—When you configure a redundant ACE pair with an FT peer, FT interface and query VLAN interface, and then you delete the FT interface within the FT peer, the query VLAN interface is also removed from the FT peer configuration. But, when you enter the show ft peer ... detail command, the query VLAN interface remains. Workaround: Remove the query VLAN interface first. Then, remove the FT interface.
•CSCtg13892—When you configure the expect regex command for HTTP or HTTPS probes, if the web page parsed by the probe is longer than 100 kbytes and the matched string is at the bottom of the page, the probes may fail. Workaround: Use a plain HTTP probe not matching a regex string.
•CSCtg14756—After you attempt to configure a user context through the XML agent or Device Manager (DM), in the rare condition when an error is encountered, the following may occur:
–The VSH process becomes unresponsive, causing the ACE to become unreachable.
–The Admin configuration is corrupted.
–Any user contexts, including the one being configured, are lost and not recoverable from the ACE. This includes configuration, certificate, key, and script files.
Workaround: Perform the following:
a. Make checkpoints of the Admin context before configuring a user context.
b. Make sure all existing user context files are saved remotely from the ACE.
c. Avoid sending non alphanumeric characters to configure a user context.
d. Configure the user context using CLI instead of the XML agent or DM.
•CSCtg15735—The Fault Tolerant (FT) TL connection is the TCP connection between primary and secondary ACE is used for FT communications. When the ACE cannot establish the FT TL connection after a period of several minutes, it stops attempting to reestablish this connection. This results in the ACEs failing to achieve the proper fully redundant state of ACTIVE/STANDBY_HOT.
Workaround: You can use the show conn command in the Admin context to determine whether the TCP connection between the addresses on the FT VLAN exists. If the TCP connection does not exist, enter the shutdown and no shutdown command on the FT VLAN to cause the ACE to attempt to reestablish the TL TCP connection.
If this does not work, investigate why the TCP connection could not be established. After the underlying issue, such as external network interruption which caused the TCP connection to fail, has been resolved, you can retry the workaround.
During the period when the TL connection cannot be established, you can expect delays in the response from some of the FT show commands due to the ACE primarily spending resources in attempts to bring up the TL connection.
•CSCtg24463—If you configure a SIP probe with an IP address, the probes are correctly sent to this address but the payload still contains the real server IP address. Workaround: None.
•CSCtg31963—When you use the dm reload command and other dm commands, you must be logged into the ACE as the original Admin user shipped with the ACE appliance. The Admin user is the only user that the ACE allows to use the dm related commands. Workaround: Enter the dm commands when you are logged in to the ACE locally as the Admin user.
•CSCtg48531—When you enter the show probe detail command from a user context, this command may display invalid output and may generate a vsh core file in the core: directory. Workaround: None.
•CSCtg71468—The output of the show np 1 me-stats -sports command displays incorrect RGMII counter information and all counters display the good packet count. Workaround: None
•CSCtg74029—The ACE cannot obtain the XML format of the logging host commands. These commands in the ACE configuration are not properly converted to the XML form which causes the resulting XML file to load improperly. Workaround: None.
Software Version A3(2.6) Open Caveats
The following open caveats apply to ACE software version A3(2.6).
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsu08736—When you download the DTD file shipped with ACE and check the definitions for features such as CRL, authgroup, DNS, RTSP, and SIP, some of the XML tags definitions are not available. Workaround: None.
•CSCsu40160—When the ACE configuration has more than 500 service policies and you can ping all VIP addresses, some VIP addresses are not served at all. Workaround: None.
•CSCsu55909—In a redundant configuration, when you configure the ACE with 20 contexts, apply it to the active ACE, and then bring up the standby ACE with the configuration, the active ACE transitions into the Cold state with the following error:
Error on Standby device when applying configuration file replicated from active
Workaround: First bring up the active and standby ACEs individually and then enable redundancy.
•CSCsv62417—In some instances, the virtual MAC address is used for both the client-side VIP addresses and server-side NAT pools. With an FT VLAN configuration, the virtual MAC address is used as the source MAC for both client- and server-side packets. This behavior can cause issues in specific network topologies where the client-side and server-side end up learning the same MAC address over two ports. Without the FT VLAN, the internal MAC address is used. Workaround: Use the mac address autogenerate command to enable the autogeneration of a MAC address.
•CSCsv64123—When you configure an SNMP user, both active and standby ACEs crash. Workaround: None.
•CSCsx06085—When you enable UDP boost on the ACE, the server-initiated traffic fails because the destination port changes to the source port value. Workaround: Disable UDP boost.
•CSCsx71993—When the ACE, running in software release A3(2.1), is not sending any traffic and traffic occurs only because of an ICMP probe, the show conn command displays the incorrect data 18 percent of the time. But in software release A3(2.1.50), this command displays the incorrect data 87 percent of the time. Workaround: None.
•CSCsy66327—When you enter the show snmp group command from any context other than the Admin context, it does not display any output. Workaround: None.
•CSCsz71578—When you apply a service policy globally and then add the VLANs, the ACE displays ACL-merge errors for newly added VLANs and traffic does not flow through them. Workaround: Remove the global service policy and then reconfigure it.
•CSCsz88519—When you configure a TCP-based syslog server and the syslog server application on the remote system is down even though it is reachable from the ACE appliance, the ACE becomes unresponsive and most of its commands either time out or respond slowly. Workaround: Either bring the syslog server application up or remove the configuration for the TCP-based syslog server.
•CSCta74000—The ACE may fail to download a certificate revocation list (CRL). In some cases, the CRL fails to download when it is reapplied to the SSL proxy that is being used in certain VIPs if the previous applications to the SSL proxy had failed to download the same CRL at the point when the CRL server was down. When this situation occurs, the ACE stops downloading the CRL. Workaround: Unconfigure and then reconfigure the CRL again.
•CSCta87584—Connections may get dropped intermittently when you use persistence rebalance in a configuration and a rebalance is performed across traffic policies. This behavior typically occurs in a configuration with two different server farms that both contain the same real server with different ports, and the server farms are attached to two different Layer 7 load-balancing policy maps. Workaround: None.
•CSCtb79312—Front-end and end-to-end SSL connections may fail to complete. This behavior can occur during the following configuration settings:
–MTU setting that is larger than or equal to 9000
–End-to-end SSL or front-end SSL configured
–SSL connection with TCP data segments at MTU
Workaround: Do not use an MTU that is larger than or equal to 9000.
•CSCtd19335—If RADIUS traffic is being sent and 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 show conn rserver command.
•CSCte76795—After you change the resource-class configuration and traffic is successfully passing through the ACE, the compression statistics displayed by the show service-policy command do not update. Workaround: None.
•CSCte81895—When you configure HTTP inspection with the URL logging feature and change the HTTP inspection configuration while traffic is passing through the inspection engine, the ACE may reboot due to an inspection engine misbehavior. Workaround: Disable the URL logging feature.
•CSCte98511—When you configure the ACE with the maximum number of elements or match source statements and you add or remove match statements, match item object entries leak. Workaround: None.
•CSCtf02311—When you configure NAT for DNS VIP traffic, the rewrite for an A record with a third-party address may not occur. The ACE forwards the DNS query response from the server with the original A-record address. This issue occurs only with the third-party address for which the ACE fails to find the route. Workaround: You can prevent this issue by adding a static route for the third-party subnet through the following command, ip route third-party-subnet mask gateway.
•CSCtf06483—When you configure HTTP inspection with SSL termination and Layer 7 load balancing, and add inband TCP and retcode health monitoring configurations to the same server farm while HTTP and HTTPS traffic passes through the ACE, the ACE may reboot due to the HTTP inspection engine accessing an invalid session state. Workaround: Disable the HTTP inspection feature.
•CSCtf28699—When you enable the server-connection reuse feature, and a real server becomes unreachable or the outbound interface is shutdown, a few dataplane connection entries may become stuck in a race condition and cannot be used by the ACE. Workaround: Reboot the ACE to recover the resources.
•CSCtf33109—When you configure a real server with the fail-on-all command in a server farm and more than one probe fails, the real server is in the OPERATIONAL state. If you remove the fail-on-all command from the server, it remains stuck in this state. The real server should transition to the PROBE-FAILED state. This issue also occurs when you configure a server farm with the fail-on-all command because the fail-on-all action applies to all real servers in the server farm. Workaround: Enter the no inservice command followed by inservice command to restore the real server and transition it to the PROBE-FAILED state even when one probe fails.
•CSCtf39663—When you configure the send-data command with a length greater than four characters inside a finger probe, the probe fails. When you configure the expect regex command with ".*" string, the probe also fails. Workaround: Configure the probe with a send-data length that is less than 4 characters.
•CSCtf42007—When you apply a real server to multiple server farms and the server recovers from a probe failure, it does not receive any new connections on any of the server farms. The show probe and show serverfarm commands indicate the real server is operational but does not have any current connections. Workaround: Remove the real server from service. Then, place it in service.
•CSCtf50924—When you configure 0.0.0.0/0 as the first VIP on the ACE, all subsequent VIPs inside the show cfgmgr internal table vip command matches 0.0.0.0/0. This command table becomes corrupted with 0.0.0.0/0 as the first VIP. Workaround: Do not configure 0.0.0.0/0 as the first VIP.
•CSCtf94950—When you remove a class map with a sticky load-balancing policy, the ACE removes sticky groups from other policies that are still using them. Workaround: Removing and adding the sticky group to the policy should download the correct configuration.
•CSCtg03038—When you configure an invalid OID in an SNMP probe, the probe fails due to parse error for the configured OID. Each failing SNMP probe leaks one socket. Eventually, the socket resources for health monitoring are exhausted causing all the probes on the system to fail with Out of Sockets errors. Workaround: Correct the OID under the SNMP probe and reboot the ACE.
•CSCtg17350—When you configure the Acceleration and Optimization features on the ACE, the integrated packet capture utility may not capture traffic from all interfaces, even when you configure the capture to capture from all interfaces. Workaround: None.
•CSCtg27611— When you configure the IP relay agent on the ACE VLAN interfaces, due to the fix for CSCtb60599, the ACE DHCP relay agent forwards DHCP unicast packets which is incorrect. Workaround: None.
•CSCtg31255—When you change the cookie name of an HTTP-cookie sticky group, the name does not change. Workaround: Remove the cookie group. Then, reapply it to the policy map.
•CSCtg31975—Symptom: System account shell access. Condition: A system admin account in the ACE software may allow an authenticated user to inject shell commands. This account does require authentication. Workaround: None.
•CSCtg37325—During normal ACE operating conditions, the configuration manager becomes unresponsive and the ACE generates a core file. Workaround: None.
•CSCtg43409—When you configure DHCP-related changes on the VLAN and BVI interfaces, the ACE becomes unresponsive due to a cfgmgr termination. Workaround: None.
•CSCtg45244—After you add multiple configurations and then remove them by deleting contexts, the ACE becomes unresponsive. The backtrace indicates a loop when removing from the good list. Workaround: None.
•CSCtg46244—When the ACE has a high rate of SIP calls per second and the SIP inspection engine encounters any errors due to resource allocation failures, the ACE may reboot. This issue occurs only when the SIP inspection engine encounters failures in the initial packet processing, for example, memory allocation, object allocation, and inspection configuration version mismatch failures. Workaround: Disable the SIP inspection feature, if possible.
•CSCtg53126—When you attempt to delete a server farm with the no serverfarm host command, the ACE displays the following error message:
Error: serverfarm `serverfarm_name' is in use. Cannot delete!
The configuration manager thinks the server farm is still applied to the load-balance policy. Workaround: None.
•CSCtg53196—When you configure the ip options clear or ip options clear-invalid command, and the ACE receives packets that contain the IP options, it drops the packets. Workaround: None.
•CSCtg56876—When you enter the show telnet maxsession context_name command, where the context_name argument is an existing or nonexisting context, the ACE generates a vsh core file in the core directory with a sig 11, Segmentation fault and then displays an internal error during command execution error message. Workaround: None.
•CSCtg67860—When you configure multiple track probes in two user contexts and enter the show cfgmgr internal table track-probe command, the ACE becomes unresponsive due to a Cfgmgr process failure. Workaround: None.
•CSCtg70470—After you add multiple ACE configurations and then remove them by deleting contexts, the ACE becomes unresponsive. The backtrace indicates a WeightBucket-related operation. Workaround: None.
•CSCtg76150—When you configure an inline match statement that has a special character or space in its name under an Layer 7 policy, the checkpoint rollback fails. Workaround: Do not configure inline match statements with special characters or spaces.
•CSCtg77969—When you configure the ACE with client authentication, a best-effort CRL, and to ignore CDP error through the cdp-error ignore command, and the client sends a certificate which has no CDPs and fails client authentication other than a revocation check, the connection fails on the first attempt as expected. But, after a few reconnection attempts, it starts to pass. Workaround: Either use a static CRL or use the no cdp-error ignore command to reset the default behavior where the ACE rejects an SSL connection when CDP or CRL-download errors occur.
•CSCtg79608—When you disable normalization for remote real servers, the ACE may resend a TCP RST for the probe. For a probe TCP SYN, the remote real server responds with a TCP RST. The ACE may respond with a TCP RST in the case where the real servers are reachable through a gateway and you have disabled normalization on the source interface for probe traffic. This issue may occur only if the remote server is another ACE and the VIP is out of service. Workaround: Perform either of the following:
–Enable normalization on the source interface for probe traffic.
–Configure the following ACL command on the ACE for every remote ACE VIP and port for probing from the ACE:
access-list test1_acl line 1 extended deny tcp host RSERVER_VIP_IP eq
RSERVER_VIP_PORT host ACE_INTERFACE_IP
•CSCtg84678—When you attempt to log in to the ACE console with a username containing an @ character, the login attempt fails. For example, if you use the user@cisco username, as soon as you type the @ character, the ACE deletes everything before the character. The login attempt also fails when you enter a username with the # character, acting as a backspace and deleting a character before it. Workaround: Perform either of the following:
–Log in to the ACE over SSH.
–Cause a failed login attempt on the console first before attempting to login with a username with an @ character.
•CSCtg87843— After you change the configuration in a large ACE configuration and enter show commands, the CLI becomes unresponsive for a period of time. In this case, the show processes cpu | include cfgmgr command displays one of the configuration manager (cfgmgr) processes consuming CPU resources. After you apply the configuration change, the cfgmgr CPU usage goes to zero, and the CLI becomes unresponsive. Workaround: Wait until the cfgmgr completes its previous operation before entering the show command.
•CSCtg96456—When you configure the maximum number of the VIP statements in a single class map of 254 and then delete one of the VIP statements, the ACE cannot add a match VIP address in a single class map and displays the following message:
Error: Exceeded maximum match item limit for the class-map
Workaround: Remove the class map and the reconfigure it again with all of the VIP addresses.
•CSCtg96913—When traffic is flowing through the ACE and you change the configuration with respect to the real server, probe and clearing statistics, weight bucket for the real server may become corrupted causing the ACE to reboot. This is an one-time occurrence. Workaround: None.
•CSCth00054—The issue is due to an open SIP data channel pinhole facing the client direction. When you allocate a valid port range from 1025 to 65535 for the PAT port and the ACE performs an implicit PAT, the ACE includes the 5060 and 5061 control ports. If the ACE uses these two ports and the next packet matching these pinholes is a new call control packet instead of data, the ACE mishandles the new control packet and promotes the pinhole.
The traffic itself is not interrupted. However, when the ACE releases the resource, since it handled this control packet and the flow as a pinhole promoted data channel and although it does not affect classification in which the flow is still treated as SIP control or inspection, it does not send it for load balancing to release the policy map entry and eventually a resource leak occurs. Workaround: None.
•CSCth04993—When you configure an ACE interface with single NAT IP address in the NAT pool and the ACE receives SIP UDP traffic, it resets subsequent SIP TCP traffic. Workaround: Perform either of the following:
–Perform a checkpoint rollback to a non-SIP configuration and then to the existing configuration.
–Increase the number of IP addresses in the NAT pool.
•CSCth06234—When you configure a match statement in a match-all class map, you cannot modify the statement. Workaround: Remove the class map from the associated Layer 3 policy and then modify the match statement.
•CSCth12446—When the ACE is using a 1-Gbps throughput license, the throughput output displayed through the show resource command is rounded to the nearest thousand. For example, a value of 134217728 is rounded to 134217000. This issue does not occur with other throughput licenses. Workaround: Install a throughput license that is not 1Gbps and then uninstall the license.
•CSCth13078—When you configure multiple interfaces to share the same multi-match policy, you cannot ping a VIP defined on the ACE. Workaround: Removing and reapplying the class map in the multi-match policy may clear this issue.
•CSCth13221—When TCP probes are sent to specific services which may cause unusual TCP sequences to occur, the ACE may run out of sockets for the probes. The output for the show probe detail command displays the following:
Internal error: Out of sockets
Workaround: Increase the open timer for the probes to increase the time it takes before the ACE runs out of sockets. If you reboot the ACE while the problem is occurring, it temporarily clears this issue.
•CSCth24858—After running the Device Manager GUI for more than a few months or a year, it cannot deploy a configuration to the ACE. There is no impact on the ACE load balancing. It continues to work. Workaround: Enter the dm reload command from the ACE CLI to restart the Device Manager.
•CSCth25859—When you use the ACE CLI to configure a context with the + (plus) character in its name and then you attempt to access it through the Device Manager GUI, an error message appears. Workaround: None.
Software Version A3(2.6) Command Changes
Table 4 lists the commands and options that have been changed in software version A3(2.6).
Table 4 CLI Commands Changed in Version A3(2.6)
|
Mode
|
Command and Syntax
|
Description
|
Exec |
dm reload | help | status |
Per CSCtg31963, the dm command and its keywords are no longer hidden. |
Exec |
ping ip_address count number size max_ping_size |
Per CSCte57599 for the ping command, the maximum ping size allowed from the ACE is now 1440. Previously, the maximum ping size was 452. |
Exec |
show ft {history | memory} show np 1 {me-stats | memory | status} show resource {allocation | internal} |
Per CSCte03192 and CSCtg55065, these commands are now available to users configured with a custom role in both the Admin context and a user-configured context, as well as the predefined Admin and Network-Monitor roles. Because these commands are not context specific, we recommend that you issue them from the Admin context only. If you issue these commands in a user context, they may not display any data if other user context information could be displayed. |
Exec |
show logging message all |
Per CSCte44257, this command no longer display the 609001 through 609013 system log messages. |
Exec |
show parameter-map |
Per CSCtf35290, the persistence rebalance field for this command now displays the enabled strict state when you configure the persistence-rebalance strict command in Parameter map HTTP configuration mode. |
Exec |
show probe detail |
Per CSCtg13892, the regex cache-len field has been added to the output for this command. This field displays the configured cache length. |
Exec |
show probe [name] detail |
Per CSCte00983, the FTP method and FTP filename fields have been removed from the output of this command. |
Exec |
show service-policy [policy_name] [detail] |
Per CSCtd13725, the Regex dnld status field has been added to display the status of a regex download. This field displays the QUEUED, SUCCESSFUL, or FAILED state. |
Exec |
show sticky database |
Per CSCte57497, this command now displays the output for the source and destination IP addresses in dotted decimal notation. Previously, this command displayed these addresses in the hexadecimal equivalent. |
Exec |
show tech-support [details] |
Per CSCtd16607, this command no longer executes the following commands: •show optimization-debug •show np 1 me-stats "-W number" |
Global configuration |
arp ip_address mac_address |
Per CSCsr19346, this command now allows the configuration of a multicast MAC address. |
Global configuration |
ft group group_id |
Per CSCtf11816, this command now allows you to create a maximum of 64 FT groups. Previously, you could create the maximum of 21 FT groups. |
Global configuration |
snmp-server community community_name group group_name snmp-server user name group_name |
Per CSCte19368, the CLI hint now states that Network-Monitor is the only option accepted for the group_name argument. |
Optimize configuration |
concurrent-connections connection_limit no concurrent-connections |
Per CSCte82186, the limit keyword has been removed from the command. |
Parameter map HTTP configuration |
persistence-rebalance strict |
Per CSCtf35290, the new strict option allows you to configure the ACE to load balance each subsequent GET request on the same TCP connection independently. For more information on this command, see the "Configuring Persistence with Load Balancing on Each HTTP Request" section. |
Policy map class |
kal-ap primary-oos no kal-ap primary-oos |
Per CSCte57166, this new command enables the ACE to report the maximum load value of 255 when the primary server farm is down and the backup server farm is in use. When the GSS receives the load value of 255, it recognizes that the primary server farm is down and sends future DNS requests with the IP address of the other data center. To disable the reporting of a load value of 255 when the primary server is down and the backup server is in use, use the no form of this command. For more information on this command, see the "Enabling Maximum Load Notification When the Backup Server Farm is in Use" section. |
Probe configuration |
expect regex string [offset number] [cache [length]] |
Per CSCtg13892, the new cache option for HTTP and HTTPS probes enables regex parsing in cached mode for long web pages. The length option allows you to enter a cache length from 1 to 1000. The default length is 1000. The offset number is from 1 to 4000. However, the offset has been extended from 4001 to 163840 when you are enabling cached mode. For more information on this command, see the "Enabling Caching for Regex Parsing by HTTP or HTTPS Probes" section. |
Software Version A3(2.6) System Log Messages
Per CSCte54655, software version A3(2.6) includes the following new system log (syslog) messages.
441003
Error Message %ACE-5-441003: Serverfarm (name) failed in policy_map (policy_name) -->
class_map (cmap_name) without backup. Number of failovers = count1, number of times
back in service = count2
This syslog message is generated when a server farm has failed without a backup server farm. The count1 variable is the number of times that the primary server farm failed over to the backup server farm. The count2 variable is the number of times the primary server farm returned to service. No action is required.
442007
Error Message %ACE-4-442007: VIP in class: 'VIP' changed state from
OUTOFSERVICE/INSERVICE to INSERVICE/OUTOFSERVICE
When a server farm transitions from the INSERVICE or OUTOFSERVICE state, the VIP state changes respectively and this syslog is generated. No action is required. This syslog is for informational purposes only.
Software Version A3(2.5) Resolved Caveats, Open Caveats, and Command Change
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats, command changes, and revised system messages in software version A3(2.5):
•Software Version A3(2.5) Resolved Caveats
•Software Version A3(2.5) Open Caveats
•Software Version A3(2.5) Command Changes
•Software Version A3(2.5) Revised System Log Messages
Software Version A3(2.5) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.5).
•CSCsg22336—The output of show commands appear to be hidden by the CLI prompt, resulting in missing text on the left side of the last line of the output. This behavior typically occurs when you configure a terminal length of 0. For example:
switch/Admin# terminal len 10
switch/Admin# show telnet
Session ID Remote Host Active Time
3778 IP ADDRESS :51937 0: 0:41
switch/Admin# terminal len 0
switch/Admin# show telnet
Session ID Remote Host Active Time
switch/Admin# IP ADDRESS :51937 0: 0:48
In the show telnet output example shown above, the session ID value is missing from the show telnet command output. Workaround: Do not set a terminal length of 0.
•CSCsu06258—You may encounter HTTP compression issues when you use the default compression MIME type text/.* --[Tt][Ee][Xx][Tt]/.* in a Layer 7 HTTP parameter map. The use of the default HTTP compression MIME type can result in the following configuration issues:
–You are allowed to configure one or more duplicate entries for this MIME type.
–If you want to remove the default MIME type used for compression and use a custom MIME type, you are unable to perform this action because you cannot remove the default MIME type. When this issue occurs, the ACE repeatedly displays an error message that the MIME type does not exist.
Workaround: Use a class map to disable HTTP compression if the user-agent is Internet Explorer 6. This disables HTTP compression for IE6 but other web browsers will function properly. See Table 5 for the associated A3(2.5) command changes.
•CSCsu85286—When using the ACE appliance Device Manager GUI, you may find entries for Device Manager activities in the show accounting log command output display the "dm" user instead of the actual username that was used to log in to the ACE appliance Device Manager GUI. Workaround: None.
•CSCsw42193—When you configure multiple VIPs sharing the same IP address on different ports with the loadbalance vip icmp-reply active command, the VIP stops replying to the ICMP ping whenever any server farm changes state between any policy map load balancing. Workaround: Define the loadbalance vip icmp-reply command without the active option.
•CSCsw91456—After end-to-end SSL traffic runs on the active ACE, proxy entries may be leaked on the standby ACE. Workaround: None.
•CSCsw96035—The secondary cookie that is sent in a URL is not being used for sticky. You may encounter this behavior in a load-balancing configuration that is using sticky; in this case, the secondary cookie fails to stick if it is added to a sticky group after you add a sticky server farm to the Layer 7 load balancing policy. Workaround: Remove the sticky server farm from the Layer 7 load balancing policy map and then readd it.
•CSCsx07132—Whether the sticky option is enabled or disabled in the ACE, if you enable cookie insertion in a sticky group, the ACE creates sticky entries in its static sticky database for the real servers in the backup server farm and also inserts a cookie in the responses coming from the real servers. In this case, even with the sticky option disabled, the ACE creates sticky entries for the real servers in the backup server farm and inserts cookies in the responses coming from the real servers. Workaround: None.
•CSCsx82538—After adding a secondary logging host to an ACE logging configuration, the ACE syslogd process may spike and cause the ACE show commands to become unresponsive. Workaround: Use the following commands to rate limit the 302026 and 302027 syslog messages:
–logging rate-limit number message 302026
–logging rate-limit number message 302027
•CSCsy88397—The TAC diagnostic script showtech generates large output due to the show xlate command. Workaround: None.
•CSCsz54844—After a series of reboots, both ACE appliances 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.
•CSCsz57070—The syslog message 305010 includes the duration of the Xlate translation which is the same as the configure Xlate timeout. The duration should be the actual time that the Xlate has existed. Workaround: None.
•CSCsz67965—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.
•CSCsz69684—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.
•CSCsz70386—When you configure the ACE for redundancy and the FT VLAN goes up and down, the standby ACE may transition to a nonredundant state. Workaround: Configure an FT query VLAN with a management policy and ACL that allow ICMP (pings).
•CSCsz90273—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.
•CSCta07940—When you configure multiple static routes for the same destination but only one route is reachable, the route table output for the show ip route and show ip fib commands displays that the ECMP flag is set for the unique route entries. This flag should be set only if more than one route for the prefix is in the routing table. Workaround: None.
•CSCta14562—When you configure the ACE with a TACACS key containing the comma (,) character and reboot the ACE, you must reconfigure the TACACS key for TACACS Authentication to work. Workaround: Configure the ACE and TACACS server with a key without a comma (,) character.
•CSCta16686—When you configure the MTU on the egress interface of FROM_CP traffic, TCP checksum errors occur for packets generated from the CP. Workaround: Remove the MTU configuration from the egress interface.
•CSCta20975—When the FTP client enters the EPRT command, the FTP server does not accept it and replies with an error. Then, the client tries the PORT command, and the ACE closes the connection with an RST packet. The FTP data channel fails to be established. Workaround: Use another FTP client that does not enter the EPRT and PORT commands consecutively. Enable the EPRT command on the FTP server.
•CSCta29216—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.
•CSCta30616—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.
•CSCta34181—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.
•CSCta43486——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.
•CSCta48090—When the UDP booster is enabled, the ACE drops the UDP packets that originate from the server. Workaround: Disable the UDP booster.
•CSCta49323—The ACE unexpectedly becomes nonresponsive, generating a core dump and then rebooting. This behavior can occur when the TCP receive queue is full, which indicates a high TCP traffic load to the ACE. Workaround: You can control how the ACE applies TCP optimizations to packets on a connection associated with a Layer 7 policy map using a round-trip time (RTT) value by using the set tcp wan-optimization rtt 0 command in parameter map connection configuration mode. For a value of 0, the ACE applies TCP optimizations to packets for the life of a connection. See the Cisco ACE 4700 Series Appliance Security Configuration Guide, Chapter 4, Configuring TCP/IP Normalization and IP Reassembly Parameters.
•CSCta49746—When you configure the set tcp timeout embryonic command, the ACE may not send RSTs at the time specified by the command. The server does not receive retransmitted SYNs from the clients because the retransmits are causing the embryonic connections to be reset. Workaround: None.
•CSCta50123—If a real server is down and you configure a passdetect interval that is less than 30 seconds, overlapping probes can occur leading 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.
•CSCta58817—The ACE SIP probes may fail on certain SIP servers because the probes are not RFC complaint. SIP servers behind the ACE look for the branch ID, which is required as part of a SIP proxy forwarding infrastructure. If the branch ID in the VIA header does not start with z9hG4bK, as provided in RFC probes, the probes may fail. Workaround: None.
•CSCta61638—DNS inspection may not work after you upgrade from software version A3(2.4) 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.
•CSCta67737—When you configure NAT on the ACE and the ACE reports the termination of connection in the connection teardown syslog message, it may display the incorrect amount of data transferred. Workaround: None.
•CSCta73016—You may find that the output of the show resource usage command shows inaccurate information, such as displaying peak information only during the duration of command execution. For example, when you look at the Peak resource usage counter for Connection Rate and SSL-Connection Rate updates during the execution of the show resource usage command, the peak does not show the actual peak over time. Instead, it shows only the highest peak since you ran the show resource usage command since statistics were last cleared, or since the ACE was reloaded. Workaround: None.
•CSCta73408—Inserting a class map into a policy map that contains a nat static statement before inserting a class map with a nat dynamic statement for the same VLAN may cause inbound traffic to the global interface to fail. Informational message logs reflect the static translation messages for VLAN1 instead of the private VLAN. For example:
%ACE-6-305009: Built static translation from vlan1:<private_ip> to
<global_vlan>:<global_ip>
Workaround: Delete the multi-match Layer 3 and Layer 4 policy map and reconfigure it, adding each class map in correct sequence without using the insert-before keyword.
•CSCta95804—When using the ACE appliance Device Manager GUI, rules configured under the L7 Load Balancing section in the Device Manager Virtual Server page Config > Virtual Contexts > context > Load Balancing > Virtual Servers may appear to be in a different sequence than that shown in the CLI. This is also true of the advanced Expert mode on the DM for the L7 load balance policy map. This behavior occurs only when you attempt to edit a virtual server and edit the sequence of the Rules in the L7 Load Balancing section using the Up/Down buttons, and the updated sequence shown on the GUI is not updated on the CLI. The above issue only occurs during an edit of a virtual server; you will not encounter this mismatched behavior during the creation of a new virtual server. Workaround: If the sequence of rules in the L7 Load Balancing section in the Device Manager Virtual Server page is intended to be updated, you can perform the update by deleting and then readding the rules in the intended order rather than using the Up/Down buttons to change the sequence to avoid the mismatch.
•CSCta95875—When using the ACE appliance Device Manager GUI, you may encounter an inconsistency when you manually specify the default-compression-exclusion-mime-type. Initially, the configuration will be deployed correctly. However, the next time you go in the virtual server configuration, the default-compression-exclusion-mime-type will be removed. The default-compression-exclusion-mime-type is created by default by the Device Manager when you use the GZIP HTTP compression format on a Layer 7 SLB policy.Workaround: Create a custom class map that is identical to the default-compression-exclusion-mime-type class map but uses a different name. Reference this new class map in the virtual server configuration.
•CSCta99048—When you use the show rserver command to display a summary or detailed statistics for a named real server or for all real servers, the command output displays more connections than the connections shown when you use the show conns command. This difference causes problems with the maximum allowable number of active connections to a real server when the level of traffic is lower than displayed using the show commands. Workaround: Remove or increase real server maximum connection limits.
•CSCtb03738—Incremental configuration synchronization of the CLI snmp-server unmask-community command (see Table 8) fails from the active ACE to the standby ACE peer. This issue occurs in non-Admin contexts.Workaround: Perform bulk synchronization to resolve the issue by executing the following commands on the active ACE:
–ft auto-sync running-config
–no ft auto-sync running-config
•CSCtb11260—When you configure the ACE for SIP UDP, it does not accept the SIP UDP probe requests because the source port of the 200 OK message is different than the destination port of the OPTIONS method. Workaround: None. See Table 5 for the new rport command.
•CSCtb16968—When you configure the ACE with an access list and then perform multiple dynamic configurations and use the resequence option, duplicate access-list line numbers may occur on the ACE, further resequence commands fail, and you cannot add an object. Workaround: Reboot the ACE to clear this condition.
•CSCtb25150—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.
•CSCtb37322—The ACE becomes unresponsive when its uptime reaches approximately 485 days. Workaround: Gracefully reboot the ACE before its uptime reaches 480 days.
•CSCtb49439—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.
•CSCtb51854—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.
•CSCtb53408—The ACE sends most of the received traffic to a few real servers in a server farm and sends less traffic to the remaining real servers in the server farm. Workaround: Perform one of the following actions to resolve this issue:
–When all real servers are operational, specify a configuration change on any of the real servers in the affected server farm, such as entering the no inservice command and the inservice command.
–Remove the real server weight configuration.
–When all real servers are operational, remove the real server probe from the configuration, wait approximately 30 seconds, and then readd the probe to the real server configuration.
•CSCtb55230—When you specify TCP as the protocol in a global access list configured for DNS traffic, DNS inspection fails. Workaround: Specify only UDP as the protocol in the global access list configured for DNS traffic.
•CSCtb59279—When you change a large configuration on the ACE, one or more VIP addresses on the ACE stop taking connections because the VIP address that fails is using a stale virtual server ID. Workaround: Remove and readd the service policy. If that does not resolve the problem, then remove and readd the VLAN interface configuration.
•CSCtb60599—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.
•CSCtb68431—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.
•CSCtb69958—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.
•CSCtb73557— If you enter a command with more than 2,048 spaces at the CLI, one of the following three problems may occur:
–The ACE may be become unresponsive
–You may lose your Telnet session
–The VSH process may become unresponsive
Workaround: Do not include more than 2,000 characters of white space in the command line.
•CSCtb95646—The memory usage of the sysmgr process in the ACE may increase when you repeatedly log in to and log out of the ACE by using a Telnet or SSH connection, or if you use an XML script to obtain data from the ACE. The XML script causes a logon to the ACE and then closes the connection. Workaround: None.
•CSCtb95964—The order of the TACACS and NTP portion of the global ACE running or startup configuration that is displayed when you enter the show running-config command can change. This behavior may occur when you use a remote monitoring tool to perform a "diff" comparison of the configurations. Workaround: None.
•CSCtb96545—The ACE Admin and user context-specific TAC diagnostic show tech-support [details] command scripts have an invalid command in them which results in an error. Workaround: None. See Table 5 for the associated A3(2.5) command changes.
•CSCtb96577—The TAC diagnostic show tech-support [details] command output contains multiple instances of the same command. Workaround: None. See Table 5 for the associated A3(2.5) command changes.
•CSCtc05774—When a user with a custom role and domain containing between 50 to 100 objects logs into the ACE device manager, it does not display objects other than virtual servers even though the objects are included as objects in the domain. The domain is enforced and works correctly in CLI. Workaround: Stop using a customized domain for the user. Use a default domain or domain with a smaller number of domain objects.
•CSCtc05893—When you use the ACE appliance Device Manager GUI, you may encounter an unsuccessful import of a certificate when attempting a terminal import. This condition occurs when you attempt to import a noncertificate/nonkey such as text (for example, PEM-formatted data without the -----END CERTIFICATE----- or -----END RSA PRIVATE KEY-----) by performing a terminal import from the Device Manager GUI. This behavior can cause a socket timeout exception, which results in an open hanging session on the ACE. Workaround: Clear the SSH session.
•CSCtc33324—If you enter the show crypto chaingroup name command in a user context at the command line interface (CLI), the ACE may become unresponsive and generate a core dump file. Workaround: Avoid using the show crypto chaingroup name command at the CLI.
•CSCtc33530—The show tech-support details command is missing some important commands. Workaround: Enter the commands manually. See Table 5 for the A3(2.5) associated command changes.
•CSCtc52603—New connections on an active ACE that was formerly a standby ACE may ignore their matching sticky database entries. The sticky entry is learned when the ACE is acting as a standby, then the context fails over to the active. The sticky entry must time out before it is refreshed with a new connection that matches the sticky entry. When this happens, the sticky entry is ignored instead of being consulted for the load-balancing decision. Configuring a long sticky timeout will increase the probability that a new connection will refresh the sticky entry prior to its timing out. For UDP connections in particular, short connection inactivity timeouts will also increase this probability. Workaround: Clear the offending connections and force the client to reinitiate its session.
•CSCtc53223—If you create a user context with a name that is a substring (for example, CONTEXTA) of an existing user context name (for example, CONTEXTABC) and you enter the changeto ? command at the CLI, the substring context name does not appear in the list of user contexts. This issue is a CLI hinting problem and is cosmetic only. You can still enter the changeto CONTEXTA command successfully. Workaround: Do not create a user context whose name is a substring of an existing user context name.
•CSCtc56747—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.
•CSCtc63117—If a real server becomes unresponsive, you may observe that the show rserver command indicates the real server status as ARP_FAILED and the show arp command displays the MAC address for the real server, but the MAC address status is displayed as LEARNED instead of RSERVER. Under these conditions, you can ping the real server from the ACE, but the real server is down for load balancing because of its ARP_FAILED state. This issue is seen only on the standby ACE and only when the ARP entry for a host has already been learned by the active ACE and has been synchronized to the standby ACE ARP cache and later the same host is configured as a real server. Workaround: Delete the real server and then reconfigure it.
•CSCtc65236—When you apply an action list to a policy, you may receive the following configuration manager error:
Error: Error in creating link between SLB Policy and action-list.
Workaround: Delete and then recreate the context.
•CSCtc66317—When you enable the compression feature on the ACE and it encounters an HTTP static parse error if the server responds with chunked data, it reboots. Workaround: Disable the compression feature.
•CSCtc66669—The show conn count or show resource usage all | inc conc- command displays a disproportionately higher number of current connections on the standby ACE compared to the active ACE. Also, the show conn | inc CLS command on the standby ACE displays many connections in the CLSRST state. This problem appears to be a race condition when short-lived connections end in an RST. The conn remove directive from the active ACE to standby ACE may arrive before the conn create directive. Workaround: 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 active and standby may warrant configuring a more aggressive idle timeout.
•CSCtc66780—The ACE does not perform SNAT on a passive FTP data connection in bridged mode with catch-all VIP when the FTP inspection is enabled. Workaround: Disable FTP inspection or change the ACE to routed mode.
•CSCtc68051—When the ACE times out an incomplete TCP three-way handshake (for example, SYN, SYN-ACK), it sends an RST and ACK to the client, but only an RST to the server. Workaround: Disabling normalization through the no normalization command may help in some cases.
•CSCtd00069—When you enter the SNMP trap for a server farm and the username command repeatedly from the CLI, the MTS buffers can leak. Over time, a shortage of MTS buffers can cause the ACE to be unresponsive to management commands. Workaround: Do not enter these commands repeatedly 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.
•CSCtd00730—Summary: 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.
See Table 5 for the A3(2.5) associated command changes.
•CSCtd08901—When you configure back-end SSL and compression configured together, occasionally the traffic from the ACE to the HTTP client is delayed by 2 seconds. Workaround: Disable either compression or back-end SSL.
•CSCtd13863—When you enter the changeto command or create or delete a context, you may observe an MTS memory leak. After a long time or after you enter many such CLI commands, the MTS buffer queue may become full, which may result in the failure of show or configuration commands, or, in some cases, a reboot of the ACE. Workaround: Clear any idle Telnet, SSH, or debug plugin sessions that are open in your ACE.
•CSCtd28708—When you change the resource class configuration and use the no limit-resource conc-connections command, the ACE may improperly calculate the value in the conc-connections Max Allocation field displayed by the show resource usage command. Workaround: Reboot the ACE.
•CSCtd28713 —When you assign real server weights, the ACE only takes into consideration the weights for the first two real servers, which can cause incorrect weight assignments to some real servers in the server farm. These incorrect assignments lead to an incorrect connection distribution. Workaround: Do not modify the real server weight.
•CSCtd35468—When you create a server farm with each real server configured with the conn-limit command and a backup real server in a circular arrangement, the ACE unexpectedly reboots and generates a core file. For example:
conn-limit max 200 min 100
conn-limit max 200 min 100
Workaround: Do not configure backup real servers in a circular arrangement.
•CSCtd46422—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.
•CSCtd94521—The documentation examples for the assignment of the IP address and peer IP address on a VLAN could be misleading and require clarification. Workaround: None.
•CSCte61517—When you configure the ACE for SSL client authentication with the crl best-effort command, the ACE logs a CRL download failure message and may reject SSL communications. Workaround: Configure a static CRL.
Software Version A3(2.5) Open Caveats
The following open caveats apply to ACE software version A3(2.5).
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsu40160—When the ACE configuration has more than 500 service policies and you can ping all VIP addresses, some VIP addresses are not served at all. Workaround: None.
•CSCsu55909—In a redundant configuration, when you configure the ACE with 20 contexts, apply it to the active ACE, and then bring up the standby ACE with the configuration, the active ACE transitions into the Cold state with the following error:
Error on Standby device when applying configuration file replicated from active
Workaround: First bring up the active and standby ACEs individually and then enable redundancy.
•CSCsv62417—In some instances, the virtual MAC address is used for both the client-side VIP addresses and server-side NAT pools. With an FT VLAN configuration, the virtual MAC address is used as the source MAC for both client- and server-side packets. This behavior can cause issues in specific network topologies where the client-side and server-side end up learning the same MAC address over two ports. Without the FT VLAN, the internal MAC address is used. Workaround: Use the mac address autogenerate command to enable the autogeneration of a MAC address.
•CSCsv64123—When you configure an SNMP user, both active and standby ACEs crash. Workaround: None.
•CSCsx06085—When you enable UDP boost on the ACE, the server-initiated traffic fails because the destination port changes to the source port value. Workaround: Disable UDP boost.
•CSCsx71993—When the ACE, running in software release A3(2.1), is not sending any traffic and traffic occurs only because of an ICMP probe, the show conn command displays the incorrect data 18 percent of the time. But in software release A3(2.1.50), this command displays the incorrect data 87 percent of the time. Workaround: None.
•CSCsy66327—When you enter the show snmp group command from any context other than the Admin context, it does not display any output. Workaround: None.
•CSCsz71578—When you apply a service policy globally and then add the VLANs, the ACE displays ACL-merge errors for newly added VLANs and traffic does not flow through them. Workaround: Remove the global service policy and then reconfigure it.
•CSCsz88519—When you configure a TCP-based syslog server and the syslog server application on the remote system is down even though it is reachable from the ACE appliance, the ACE becomes unresponsive and most of its commands either time out or respond slowly. Workaround: Either bring the syslog server application up or remove the configuration for the TCP-based syslog server.
•CSCsz96385—When you apply an authentication group and CRL to an SSL configuration that has 250 SSL VIP addresses with traffic flow, the ACE reboots. Workaround: None.
•CSCta07574—The ACE reboots unexpectedly and generates a core file related to connection management. Workaround: None.
•CSCta74000—The ACE may fail to download a certificate revocation list (CRL). In some cases, the CRL fails to download when it is reapplied to the SSL proxy that is being used in certain VIPs if the previous applications to the SSL proxy had failed to download the same CRL at the point when the CRL server was down. When this situation occurs, the ACE stops downloading the CRL. Workaround: Unconfigure and then reconfigure the CRL again.
•CSCta87584—Connections may get dropped intermittently when you use persistence rebalance in a configuration and a rebalance is performed across traffic policies. This behavior typically occurs in a configuration with two different server farms that both contain the same real server with different ports, and the server farms are attached to two different Layer 7 load-balancing policy maps. Workaround: None.
•CSCtb79312—Front-end and end-to-end SSL connections may fail to complete. This behavior can occur during the following configuration settings:
–MTU setting that is larger than or equal to 9000
–End-to-end SSL or front-end SSL configured
–SSL connection with TCP data segments at MTU
Workaround: Do not use an MTU that is larger than or equal to 9000.
•CSCtb94782—When the ACE processes a failed server due to a connection close message, it reboots. Possible triggers to this issue include servers transitioning in and out of service while traffic is flowing through the VIP of interest. Workaround: None.
•CSCtd16864—When you configure the mac-address autogenerate command with the ip dhcp relay command on an interface, the ACE appliance fails to relay the DHCP request to the configured server and the counters displayed by the dhcp relay statistics command do not increment. Workaround: Remove the mac-address autogenerate command from the interfaces and reboot the ACE.
•CSCtd19335—If RADIUS traffic is being sent and 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 show conn rserver command.
•CSCtd30151—After failover, the active ACE does not forward the server FIN and RST packets to the client for an existing open connection. This issue occurs only if the server closes its connection before the client sends any packets for this connection. Workaround: Disable normalization.
•CSCtd90681—When the ACE is under a sustained load, HTTP Layer 4 and Layer 7 load-balancing performance is reduced by 2 percent in comparison with software release A3(2.4). Workaround: None.
•CSCte03192—When using a custom role configuration on the ACE, some Admin commands are not accessible. Workaround: Use the Admin role.
•CSCte15439—When the ACE performs Layer 4 load balancing and uses NAT or PAT, it may reuse a source port faster than the real server and clears it from its TIME-WAIT state. When this behavior occurs, the ACE sends a new SYN request and the real server may respond with an ACK lost segment that contains the wrong ACK and sequence number. The ACE, in its default state with normalization enabled, should drop the ACK lost segment. However, it forwards it to the originating client which resets the TCP connection. Workaround: Migrate to Layer 7 load balancing. Then, the ACE becomes the TCP endpoint and drops the ACK lost segment that contains the wrong ACK and sequence numbers.
•CSCte19368—When you configure the following commands, you cannot define a user role group different from the default Network-Monitor group, even if the group has the same permissions, especially the Permit-Monitor group:
–snmp-server user name r1, where r1 is a previously defined role. It writes on the running configuration.
–snmp-server user name Network-Monitor
Workaround: None.
•CSCte26273—The real server in a server farm is up and operational. However, the ACE incorrectly excludes it from the load-balancing algorithm because of the real server weight. Workaround: From the Command Line Interface (CLI) remove the real server from the server farm. Then, readd it and place it back in service. For example, enter the following:
Wait five seconds, then enter:
•CSCte52972—When you attempt to configure a large ACL through the Device Manager (DM), it fails with an internal error. Workaround: Perform the following:
a. Configure the ACL through the Command Line Interface (CLI).
b. Divide the ACL into smaller pieces and configure them through the DM.
•CSCtg14756—After you attempt to configure a user context through the XML agent or Device Manager (DM), in the rare condition when an error is encountered, the following may occur:
–The VSH process becomes unresponsive, causing the ACE to become unreachable.
–The Admin configuration is corrupted.
–Any user contexts, including the one being configured,are lost and not recoverable from the ACE. This includes configuration, certificate, key, and script files.
Workaround: Perform the following:
a. Make checkpoints of the Admin context before configuring a user context.
b. Make sure all existing user context files are saved remotely from the ACE.
c. Avoid sending nonalphanumeric characters to configure a user context.
d. Configure the user context using CLI instead of the XML agent or DM.
Software Version A3(2.5) Command Changes
Table 5 lists the commands and options that have been changed in software version A3(2.5).
Table 5 CLI Commands Changed in Version A3(2.5)
|
Mode
|
Command and Syntax
|
Description
|
Exec |
clear acl-merge statistics |
Per CSCtd16942, the new clear acl-merge statistics command clears the ACL-merge and compiler statistics displayed by the show acl-merge statistics command. |
Exec |
ping |
Per CSCtd50036 for the extended ping command, the maximum ping size allowed from the ACE is now 1440. Previously, the maximum ping size was 452. To use the extended ping command, enter the ping keyword only with no additional keywords in the command string. Then, the CLI displays prompts for the ping parameters. For example, type ping and press Enter. At the Datagram size prompt, enter value for the ping size.
Target IP address: xx.xx.xx.xx
|
Exec |
show acl-merge event-history |
Per CSCtd16942, the new event-history keyword displays the ACL-merge event history in the Admin context. |
Exec |
show acl-merge statistics |
Per CSCtd16942, the new statistics keyword displays the ACL-merge and compiler statistics in the Admin and user contexts. |
Exec |
show interface |
Per CSCsz70399, this command now displays the following: •The reason for the interface to transition to the Up state •Time stamp when the last change occurred •Number of transitions the interface experienced since it was created •Last three previous states including the time stamp and the reason for the Up or Down transitions |
Exec |
show interface port-channel channel_number |
Per CSCsw97175, if you do not configure a load-balance scheme on the interface, the load-balance scheme field now displays src-dst-mac, which is the default load-balance scheme on the source or destination MAC address. Previously, this field displayed unknown. |
Exec |
show ip interface brief |
Per CSCtd50065, this command now displays the hardware interfaces along with the logical interfaces. It also supports the individual output of each physical interface. For FT interfaces, (ft) appears after the VLAN ID in the output. This change is only applicable in the Admin context. |
Exec |
show np {0 | 1} access-list resource |
Per CSCtd16942, this command now includes the maximum policy action nodes. |
Exec |
show resource usage |
Per CSCsq27067, the Max column now displays the total resources: the minimum allocated and the additional available resources. Previously, the Max column displayed the additional resources beyond the minimum available for use. If all resources were allocated to existing contexts, the Max column displayed the value of 0. |
Exec |
show service-policy |
Per CSCta11539, this command now displays the following compression counter fields: •Gzip—Number of gzip requests from the client. •Deflate—Number of deflate requests from the client. •User-Agent—Number of times that compression does not occur because of a user-agent match. •Accept-Encoding—Number of times that compression does not occur because of an Accept-Encoding error. •Content size—Number of times that compression does not occur because of a response size error. This error occurs when the content size of a packet is less than what the ACE can compress. The default minimum content size is 512 bytes. •Content type—Number of times that compression does not occur because of a response content error. This error occurs when the packet contains a content type that the ACE does not compress. •Not HTTP 1.1—Number of times that compression does not occur because the HTTP version is not 1.1. •HTTP response error—Number of times that compression does not occur because of a server response error. This error occurs when the server response is not 200 OK. •Others—Reserved for future use. |
Exec |
show tech-support |
The show tech-support command no longer displays the output for the following commands: •Per CSCsz67031: –show nat-fabric policies –show np {1 | 2} nat policies However, the show tech-support detail command displays their output. •Per CSCsy88397, the show xlate command. However the show tech-support details command displays its output. •Per CSCtb96545, the show np 1 me-stats -b command, as it is not supported by the ACE appliance. •Per CSCtb96577, duplicate show ft stats command are no longer displayed. |
Exec |
show tech-support [details] |
Per CSCtc33530, the following changes were made to the Admin and, where appropriate, the user context versions of the showtech script: •The following commands were added: –show arp statistics –show cfgmgr internal table sfarm | sfarm-real | icmp-vip –show ft config-error –show hm-internal wrkthread-stats | evmgr-stats | icmp-stat –show ipcp clients –show netio clients –show probe detail –show rserver detail –show service-policy detail –show serverfarm detail –show stats probe –show system kmem | kcache •The show startup-config command was removed. •The following commands were changed: –show conn to show conn display 1000 detail –show ft memory detail to show ft memory –show np 1 me-stats -c c to show np 1 me-stats -c |
Parameter map HTTP configuration |
no compress mimetype type/subtype |
Per CSCsu06258, when you attempt to remove a default Multipurpose Internet Mail Extension (MIME) type and no other MIME type is configured, the following error message is displayed:
Error: At least one user mimetype needs to be
configured before removing the default mimetype
When you remove the only configured MIME type and the default MIME type was previously removed, the default MIME type is restored and the following information message is displayed:
The only user mimetype available is deleted so the
default mimetype is configured
|
Probe SIP UDP configuration |
rport enable no rport enable |
Per CSCtb11260, when you configure the ACE for SIP UDP, this command forces the SIP server to send the 200 OK message from the same port as the destination port of the probe request OPTIONS method per RFC 3581. This command is available under all contexts. When you do not configure the SIP UDP probe option, if the SIP server sends the 200 OK message from a port that is different from the destination port of the probe request, the ACE discards the response packet from the server. Use the no version of this command to reset the default behavior. |
SSL parameter map configuration |
rehandshake enabled no rehandshake enabled |
Per CSCtd00730, this command was added to enable the SSL rehandshake and SSL rehandshake is now disabled by default. In prior releases, the rehandshake was enabled by default that allowed the ACE to automatically perform an SSL rehandshake when necessary. Use the no version of this command to reset the default behavior. Use the show parameter-map command to display the status of the rehandshake enabled command. |
Software Version A3(2.5) Revised System Log Messages
Software version A3(2.5) includes the following revised system log (syslog) messages.
106028
Error Message %ACE-1-106028: String Incomplete rule is currently applied on interface
interface-name. Manual rollback to a previous access rule configuration on this
interface is needed.
Per CSCtd16942, this syslog message has been enhanced with the following string messages:
•CRITICAL: ACL compiler Compressed nodes in context name are exhausted because the system or context limit is reached
•CRITICAL: ACL compiler Compressed nodes in context name are exhausted because the system or context limit is reached
•CRITICAL: ACL compiler Uncompressed nodes in context name are exhausted because the system or context limit is reached
•CRITICAL: ACL compiler Leaf Head nodes in context name are exhausted because the system or context limit is reached
•CRITICAL: ACL compiler Leaf Parameter nodes in context name are exhausted because the system or context limit is reached
•CRITICAL: ACL compiler Policy Action nodes in context name are exhausted because the system limit is reached
•CRITICAL: ACL Merge aborted in context name. Policy Action nodes required exceed what is available.
•CRITICAL: ACL Merge aborted in context name. Policy Action nodes required exceed what is available.
•WARNING: ACL Merge failed to locate the specified ACL in context name
•WARNING: ACL Merge failed to locate the specified ACE in context name
•WARNING: ACL Merge failed to add ACE in specified ACL in context name
•CRITICAL: ACL Merge malloc failure in context name
•WARNING: ACL Merge got a bad ACL instance value in context name
•WARNING: ACL Merge got a bad feature value in context name
•WARNING: Unknown error while processing merged list/access-group/service-policy in context name
305010
Error Message %ACE-6-305010: Teardown {dynamic|static} translation from
interface_name:real_address to interface_name:mapped_address duration time
Per CSCsz57070, the duration time variable now displays the total duration time of the Xlate entry, which is the time that the entry was created until it expired. Previously, the duration time variable displayed the Xlate idle timeout. The duration time variable applies to dynamic NAT or PAT only.
305012
Error Message %ACE-6-305012: Teardown {dynamic|static} {TCP|UDP|ICMP} translation
from interface_name:real_address/{real_port|real_ICMP_ID}to
interface_name:mapped_address/{mapped_port|mapped_ICMP_ID} duration time
Per CSCsz57070, the duration time variable now displays the total duration time of the Xlate entry, which is the time that the entry was created until it expired. Previously, the duration time variable displayed the Xlate idle timeout. The duration time variable applies to dynamic NAT or PAT only.
Software Version A3(2.4) Resolved Caveats, Open Caveats, and Command Change
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats in software version A3(2.4):
•Software Version A3(2.4) Resolved Caveats
•Software Version A3(2.4) Open Caveats
•Software Version A3(2.4) Command Changes
•MIB and Notification Changes for A3(2.4)
Software Version A3(2.4) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.4).
•CSCsq14886, CSCta56617—The ACL merge process may not complete in some cases or may exceed the available system resources. This behavior can typically occur in very large configurations with many ACLs, NAT statements, and class maps. The processing of these configuration commands can require a significant amount of time and internal resources. In a subset of these cases, the processing may become stuck and fail to complete. In other cases, the processing may complete but may end in a situation where the resulting output exceeds the resources available on the ACE. An occurrence of this type may result in the ACE becoming unstable.
•CSCsr81461—When you configure the hash address predictor to instruct the ACE to select a real server using a hash value based on the source or destination IP address, some of the servers may not receive any connections.
•CSCta01286—The ACE reloads and generates core files. You may encounter this behavior when the traffic type is SSL, and the SSL application records are small. In addition, this issue can occur when the ACE is performing TCP reassembly, which can cause a large number (greater than 255) SSL application records to be processed in a single TCP segment.
•CSCta42693—You may find that the ACE reloads as a result of the loadbalancer module in the ACE becoming nonresponsive while processing requests.
•CSCta65386—The ACE can become unstable, consuming and leaking a significant amount of dynamic memory, and eventually become nonresponsive when it receives SSL traffic that involves client authentication for a large number of unique client certificates (greater than 20,000). The rate of memory leak is proportional to the traffic that is using unique client certificates.
•CSCta79145—The ACE may have a memory leak when chained client certifications are presented to it as part of front-end client authentication. The leak can aggregate over a period of time, which will bring the ACE to a state where it cannot allow any new SSL connection.
•CSCta87270—When using application acceleration and optimization, the ACE generates an HTTP 400 bad request error message. This behavior typically occurs when an HTTP header exceeds 8190 bytes. Workaround: Reduce the size of the HTTP header.
•CSCta93804—SSL handshakes may sometimes fail when a client or server certificate chain is changed. This behavior can occur when client or server certificates use multi-tiered chains; SSL handshakes produce inconsistent results if the client or server certificates presented have multi-tiered chains in them, and the order of the certificates within the chain is altered.
•CSCtb27270—In some instances, the show service policy command output fails to show all configured policies. This behavior can occur when the ACE configuration contains a large number of VIPs attached to the policy map.
•CSCtb57502—When operating the ACE with a basic cookie insert configuration, if you perform a trace on the client, you can see that the expiration time "22:49:49 GMT" appears twice as shown below. This issue may occur if you configure cookie insertion without the browser-expire option (the cookie insert browser-expire command). Internet Explorer and Firefox web browsers do not have an issue with the cookie. However, older versions of the Apple Mac operating system (for example, 10.4) ignore the cookie because of this duplication expiration time.
For example:
Set-Cookie: ace-cookie=R3735405039; path=/; expires=Wed, 19-Aug-2009 22:49:49 GMT
22:49:49 GMT\r\n
•CSCtb65959—The ACE may become unresponsive when processing SSL traffic. This behavior can occur with TCP reassembly; SSL application records must be small, with no greater than 254 records contained in a TCP segment.
•CSCtb77451—You may encounter the following syslog message during operation:
%ACE-1-106028: WARNING: Unknown error while processing service-policy. Incomplete rule
is currently applied on interface vlan1. Manual roll back to a previous access rule
configuration on this interface is needed
This syslog is generated when the ACE boots up with a configuration, or copies a configuration, which has a class map that includes a combination of network VIPs and host VIPs. For example:
class-map match-any NWVIPS <<<<<<<<<< Problem
2 match virtual-address 10.0.1.0 255.255.255.0 tcp eq https
4 match virtual-address 10.0.2.0 255.255.255.0 tcp eq https
8 match virtual-address 10.0.0.17 tcp eq https
12 match virtual-address 10.0.0.19 tcp eq https
If only network VIPs are used, the problem is not seen. For example:
class-map match-any NWVIPS2 <<<<<<<<<< No problem
2 match virtual-address 10.0.1.0 255.255.255.0 tcp eq https
4 match virtual-address 10.0.2.0 255.255.255.0 tcp eq https
•CSCtc13377, CSCtc05852—If all of the SSL certificates/keys that are imported into a virtual context match up with each other and are defined in SSL proxies, the SSH session setup by the Device Manager in the Admin context to validate the certificate/key matching fails to close and the SSH session lingers on. When this occurs, it may not be obvious that the Device Manager continues to keep leaking connections in the Admin context even though the above precondition is met in a user context. Once the limit of open SSL sessions is reached, no additional SSH connections to the Admin context management IP address are available. This behavior can occur during Device Manager discovery, Device Manager autosynchronization, or Device Manager CLI synchronization. This condition may be observed irrespective of whether the ACE appliance Device Manger GUI is used or not.
Software Version A3(2.4) Open Caveats
The following open caveats apply to ACE software version A3(2.4).
•CSCsg22336—The output of show commands appear to be hidden by the CLI prompt, resulting in missing text on the left side of the last line of the output. This behavior typically occurs when you configure a terminal length of 0. For example:
switch/Admin# terminal len 10
switch/Admin# show telnet
Session ID Remote Host Active Time
3778 IP ADDRESS :51937 0: 0:41
switch/Admin# terminal len 0
switch/Admin# show telnet
Session ID Remote Host Active Time
switch/Admin# IP ADDRESS :51937 0: 0:48
In the show telnet output example shown above, the sessionID value is missing from the show telnet command output. Workaround: Do not set a terminal length of 0.
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsu06258—You may encounter HTTP compression issues when you use the default compression MIME type text/.* --[Tt][Ee][Xx][Tt]/.* in a Layer 7 HTTP parameter map. The use of the default HTTP compression MIME type can result in the following configuration issues:
–You are allowed to configure one or more duplicate entries for this MIME type.
–If you want to remove the default MIME type used for compression and use a custom MIME type, you are unable to perform this action because you cannot remove the default MIME type. When this issue occurs, the ACE repeatedly displays an error message that the MIME type does not exist.
Workaround: Use a class map to disable HTTP compression if the user-agent is Internet Explorer 6. This disables HTTP compression for IE6 but other web browsers will function properly.
•CSCsu85286—When using the ACE appliance Device Manager GUI, you may find entries for Device Manager activities in the show accounting log command output display the "dm" user instead of the actual username that was used to log in to the ACE appliance Device Manager GUI. Workaround: None.
•CSCsv62417—In some instances, the virtual MAC address is used for both the client-side VIP addresses and server-side NAT pools. With an FT VLAN configuration, the virtual MAC address is used as the source MAC for both client- and server-side packets. This behavior can cause issues in specific network topologies where the client-side and server-side end up learning the same MAC address over two ports. Without the FT VLAN, the internal MAC address is used. Workaround: Use the mac address autogenerate command to enable the autogeneration of a MAC address.
•CSCsw96035—The secondary cookie that is sent in a URL is not being used for sticky. You may encounter this behavior in a load-balancing configuration that is using sticky; in this case, the secondary cookie fails to stick if it is added to a sticky group after you add a sticky server farm to the Layer 7 load balancing policy. Workaround: Remove the sticky server farm from the Layer 7 load balancing policy map and then readd it.
•CSCsx07132—Whether the sticky option is enabled or disabled in the ACE, if you enable cookie insertion in a sticky group, the ACE creates sticky entries in its static sticky database for the real servers in the backup server farm and also inserts a cookie in the responses coming from the real servers. In this case, even with the sticky option disabled, the ACE creates sticky entries for the real servers in the backup server farm and inserts cookies in the responses coming from the real servers. Workaround: None.
•CSCsx82538—After adding a secondary logging host to an ACE logging configuration, the ACE syslogd process may spike and cause the ACE show commands to become unresponsive. Workaround: Configure a single logging host.
•CSCta49323—The ACE unexpectedly becomes nonresponsive, generating a core dump and then rebooting. This behavior can occur when the TCP receive queue is full, which indicates a high TCP traffic load to the ACE. Workaround: You can control how the ACE applies TCP optimizations to packets on a connection associated with a Layer 7 policy map using a round-trip time (RTT) value by using the set tcp wan-optimization rtt 0 command in parameter map connection configuration mode. For a value of 0, the ACE applies TCP optimizations to packets for the life of a connection. See the Cisco ACE 4700 Series Appliance Security Configuration Guide, Chapter 4, Configuring TCP/IP Normalization and IP Reassembly Parameters.
•CSCta73016—You may find that the output of the show resource usage command shows inaccurate information, such as displaying peak information only during the duration of command execution. For example, when you look at the Peak resource usage counter for Connection Rate and SSL-Connection Rate updates during the execution of the show resource usage command, the peak does not show the actual peak over time, it shows only the highest peak since you ran the show resource usage command since statistics were last cleared, or since the ACE was reloaded. Workaround: None.
•CSCta74000—The ACE may fail to download a certificate revocation list (CRL). In some cases, the CRL fails to download when it is reapplied to the SSL proxy that is being used in certain VIPs if the previous applications to the SSL proxy had failed to download the same CRL as the point when the CRL server was down. When this situation occurs, the ACE stops downloading the CRL. Workaround: Unconfigure and then reconfigure the CRL again.
•CSCta73408—Inserting a class map into a policy map that contains a nat static statement before inserting a class map with a nat dynamic statement for the same VLAN may cause inbound traffic to the global interface to fail. Informational message logs reflect the static translation messages for VLAN1 instead of the private VLAN. For example:
%ACE-6-305009: Built static translation from vlan1:<private_ip> to
<global_vlan>:<global_ip>
Workaround: Delete the multi-match Layer 3 and Layer 4 policy map and reconfigure it, adding each class map in correct sequence without using the insert-before keyword.
•CSCta87584—Connections may get dropped intermittently when you use persistence rebalance in a configuration and a rebalance is performed across traffic policies. This behavior typically occurs in a configuration with two different server farms that both contain the same real server with different ports, and the server farms are attached to two different Layer 7 load-balancing policy maps. Workaround: None.
•CSCta95804—When using the ACE appliance Device Manager GUI, rules configured under the L7 Load Balancing section in the Device Manager Virtual Server page Config > Virtual Contexts > context > Load Balancing > Virtual Servers) may appear to be in a different sequence than that shown in the CLI. This is also true of the advanced Expert mode on the DM for the L7 load balance policy map. This behavior occurs only when you attempt to edit a virtual server and edit the sequence of the Rules in the L7 Load Balancing section using the Up/Down buttons, and the updated sequence shown on the GUI is not updated on the CLI. The above issue only occurs during an edit of a virtual server; you will not encounter this mismatched behavior during the creation of a new virtual server. Workaround: If the sequence of rules in the L7 Load Balancing section in the Device Manager Virtual Server page is intended to be updated, you can perform the update by deleting and then readding the rules in the intended order rather than using the Up/Down buttons to change the sequence to avoid the mismatch.
•CSCta95875—When using the ACE appliance Device Manager GUI, you may encounter an inconsistency when you manually specify the default-compression-exclusion-mime-type. Initially, the configuration will be deployed correctly. However, the next time you go in the virtual server configuration, the default-compression-exclusion-mime-type will be removed. The default-compression-exclusion-mime-type is created by default by the Device Manager when you use the GZIP HTTP compression format on a Layer 7 SLB policy.Workaround: Create a custom class map that is identical to the default-compression-exclusion-mime-type class map but uses a different name. Reference this new class map in the virtual server configuration.
•CSCta99048—When you use the show rserver command to display a summary or detailed statistics for a named real server or for all real servers, the command output displays more connections than the connections shown when you use the show conns command. This difference causes problems with the maximum allowable number of active connections to a real server when the level of traffic is lower than displayed using the show commands. Workaround: Remove or increase real server maximum connection limits.
•CSCtb03738—Incremental configuration synchronization of the CLI snmp-server unmask-community command (see Table 8) fails from the active ACE to the standby ACE peer. This issue occurs in non-Admin contexts.Workaround: Perform bulk synchronization to resolve the issue by executing following commands on the active ACE:
–ft auto-sync running-config
–no ft auto-sync running-config
•CSCtb37322—The ACE becomes unresponsive when its uptime reaches approximately 485 days. Workaround: Gracefully reboot the ACE before its uptime reaches 480 days.
•CSCtb53408—The ACE sends most of the received traffic to a few real servers in a server farm and sends less traffic to the remaining real servers in the server farm. Workaround: Perform one of the following actions to resolve this issue:
–When all real servers are operational, specify a configuration change on any of the real servers in the affected server farm, such as entering the no inservice command and the inservice command.
–Remove the real server weight configuration.
–When all real servers are operational, remove the real server probe from the configuration, wait approximately 30 seconds, and then readd the probe to the real server configuration.
•CSCtb79312—Front-end and end-to-end SSL connections may fail to complete. This behavior can occur during the following configuration settings:
–MTU setting that is larger than or equal to 9000
–End-to-end SSL or front-end SSL configured
–SSL connection with TCP data segments at MTU
Workaround: Do not use an MTU that is larger than or equal to 9000.
•CSCtb95646—The memory usage of the sysmgr process in the ACE may increase when you repeatedly log in to and log out of the ACE by using a Telnet or SSH connection, or if you use an XML script to obtain data from the ACE. The XML script causes a logon to the ACE and then closes the connection. Workaround: None.
•CSCtb95964—The order of the TACACS and NTP portion of the global ACE running or startup configuration that is displayed when you enter the show running-config command can change. This behavior may occur when you use a remote monitoring tool to perform a "diff" comparison of the configurations. Workaround: None.
•CSCtb96545—The ACE admin context and user context specific TAC diagnostic show tech-support [details] command scripts have an invalid command in them which results in an error. Workaround: None.
•CSCtb96577—The TAC diagnostic show tech-support [details] command output contains multiple instances of the same command. Workaround: None.
•CSCtc05893—When you use the ACE appliance Device Manager GUI, you may encounter an unsuccessful import of a certificate when attempting a terminal import. This condition occurs when you attempt to import a non-certificate/non-key such as text (for example, PEM-formatted data without the -----END CERTIFICATE----- or -----END RSA PRIVATE KEY-----) by performing a terminal import from the Device Manager GUI. This behavior can cause a socket timeout exception, which results in an open hanging session on the ACE. Workaround: Clear the SSH session.
•CSCte61517—When you configure the ACE for SSL client authentication with the crl best-effort command, the ACE logs a CRL download failure message and may reject SSL communications. Workaround: Configure a static CRL.
Software Version A3(2.4) Command Changes
Table 6 lists the commands and options that have been changed in software version A3(2.4).
Table 6 CLI Commands Changed in Version A3(2.4)
|
Mode
|
Command and Syntax
|
Description
|
Configuration |
snmp-server enable traps slb serverfarm |
The new serverfarm option sends a trap when all servers are down in the server farm or the server farm has changed state. See the "MIB and Notification Changes for A3(2.4)" section for additional details. (Added per CSCta30725.) |
Serverfarm host real server configuration |
description text |
The new description command allows you to provide a description for the real server in a server farm. Enter an unquoted text string with a maximum of 240 alphanumeric characters. If the text string includes spaces, enclose the string in quotes. See the "MIB and Notification Changes for A3(2.4)" section for additional details. (Added per CSCsw49441.) |
MIB and Notification Changes for A3(2.4)
The CISCO-SLB-EXT-MIB MIB now includes the cslbxServerFarmStateChange trap. This notification is supported with the following varbinds:
•cslbxServerFarmName
•cslbxServerFarmState
•cslbxServerFarmStateChangeDescr
•cslbxServerFarmNumOfTimeFailOvers
•cslbxServerFarmNumOfTimeBkInServs
The server farm can change from the inactive to the active state or active to the inactive state. The reasons for changing from the active to the inactive state are as follows:
•All the real servers are down.
•All real servers in a single server farm are out of service because the real server(s) reach the maximum connection or maximum load state, or have a probe failure or an ARP failure.
•The server farm reaches its partial limits.
To address this change in the ACE, the CISCO-ENHANCED-SLB-MIB has been modified. The modifications include:
•Defined the new cesServerFarmRserverDescr OID in cesServerFarmRserverTable.
•Deprecated the following three traps:
–cesRealServerStateUp
–cesRealServerStateDown
–cesRealServerStateChange
•Defined the following three new traps:
–cesRealServerStateUpRev1
–cesRealServerStateDownRev1
–cesRealServerStateChangeRev1
In addition, cesServerFarmRserverDescr has been added as an extra varbind in addition to what was existing in the corresponding trap
•The ACE no longer supports:
–cesRealServerStateUp
–cesRealServerStateDown
–cesRealServerStateChange
•The CISCO-ENHANCED-CAPABILITY-MIB has also been updated.
Table 1-7 identifies the new supported SNMP notifications (traps) for the ACE for the new server farm trap.
.
Table 1-7 SNMP Trap Support for the New serverfarm Trap
|
Notification Name
|
Location of the Notification
|
Description
|
esRealServerStateUpRev1 |
CISCO-ENHANCED-SLB-MIB |
State of a real server configured in a server farm is up due to user intervention.The notification is sent with the following varbinds: •cesRealServerName •cesServerFarmRserverBackupPort •cesServerFarmName •cesServerFarmRserverAdminStatus •cesServerFarmRserverOperStatus •cesRserverIpAddressType •cesRserverIpAddress •cesServerFarmRserverDescr |
cesRealServerStateDownRev1 |
CISCO-ENHANCED-SLB-MIB |
State of a real server configured in a server farm is down due to user intervention. The notification is sent with the following varbinds: •cesRealServerName •cesServerFarmRserverBackupPort •cesServerFarmName •cesServerFarmRserverAdminStatus •cesServerFarmRserverOperStatus •cesServerFarmRserverStateDescr •cesRserverIpAddressType •cesRserverIpAddress •cesServerFarmRserverDescr |
cesRealServerStateChangeRev1 |
CISCO-ENHANCED-SLB-MIB |
State of a real server configured in a server farm changed to a new state as a result of something other than a user intervention. This notification is sent for situations such as ARP failures, probe failures, and so on. The notification is sent with the following varbinds: •cesRealServerName •cesServerFarmRserverBackupPort •cesServerFarmName •cesServerFarmRserverAdminStatus •cesServerFarmRserverOperStatus •cesServerFarmRserverStateDescr •cesRserverIpAddressType •cesRserverIpAddress •cesProbeName •cesServerFarmRserverDescr |
|
Software Version A3(2.3) Resolved Caveats, Open Caveats, and Command Changes
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats in software version A3(2.3):
•Software Version A3(2.3) Resolved Caveats
•Software Version A3(2.3) Open Caveats
•Software Version A3(2.3) Command Changes
•Revised System Log Messages
Software Version A3(2.3) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.3).
•CSCsr48502—By default, the ACE CLI is case sensitive. To disable case-sensitivity matching for HTTP only, you can use the case-insensitive command in an HTTP parameter map. With case-insensitive matching enabled, uppercase and lower case letters are considered the same. The use of case-insensitive matching applies to HTTP header names and values and to HTTP cookie names and values. With the case-insensitive option enabled inside a HTTP parameter map, you may find that dynamic sticky entries are created and stick properly, but when there are some static sticky associations created (for the header value in lowercase), the case-insensitive option in the HTTP parameter map does not work properly with the static sticky entries and results in a miss in the sticky database when load balancing a request.
•CSCsu04109—Users with an expiry date are deployed with a Network-Monitor role instead of the specified role.
•CSCsv30803—Several cross-site scripting (XSS) issues have been identified in the CSS-to-ACE conversion tool on TCP ports 80 and 10443.
•CSCsw81096—In some instances, the show service-policy detail command generates an error and fails to display the show output for all associated class maps when there is a large configuration associated with the policy map. Workaround: None.
•CSCsx05029—With a server farm containing one or more real servers with a configuration that contains real server connection limits and return code checking for the server farm, removing HTTP return code checking for a server farm can move one or more real servers to the UNKNOWN state.
•CSCsx20229—When you are using the HTTP compression feature of ACE, compression may not work properly even though the configuration has been accepted by the ACE without generating an error message. This behavior can occur when HTTP compression is used with other Layer 7 class maps that contain 10 unique cookie/header names. In this case, this configuration exceeds the permitted maximum number of match types within a policy map.
•CSCsx30496—With SSL session-id sticky configured on an ACE, and without SSL termination configured, mobile phone users are unable to properly connect. This behavior can be encountered when the ACE is configured for layer4-payload session-id persistence and the ACE receives an SSL Client Hello packet. The Client Hello packet is smaller than the configured offset and length and does not contain the begin-pattern. These packets are buffered inside the ACE until the client tears down the connection. The "\xST" (STop) metacharacter is now available in software version A3(2.3) 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. See the "Using the"\xST" Metacharacter in Regular Expressions for Layer 4 Generic Data Parsing" section for details.
•CSCsx35868—The ACE can become nonresponsive when you perform reconfigurations on a large number of VIPs (approximately 1500). In addition, the VIPs include client authentication as well as CRLs. In this case, the ACE can run low on system resources when these reconfigurations are performed.
•CSCsx57132—The ACE may periodically reload with the last reboot reason "NP ME Hung." When this ACE reload issue occurs, one or more of the following files will appear in the core: directory: ixp1_crash.txt, np1_core.bin.tar.gz, hw_state, dp_printk. This behavior can occur when you have configured DNS inspection, and the ACE is load balancing DNS for TCP and UDP port 53.
•CSCsx62720—When a server sends traffic to another server in the same subnet using the following as destinations:
–Layer 3—The IP address of the server
–Layer 2—A multicast MAC address
The ACE may transmit the same packet to the server but may change the source MAC address to its own MAC address on the VLAN. In this case, the destination server will see duplicate packets. Workaround: Set up an ACL to block server A to server B traffic on the ACE. For example:
access-list test line 10 extended deny ip host 192.168.33.251 host 192.168.33.200
access-list test line 20 extended permit ip any any
•CSCsx63170—When you import an SSL file that has 40 characters in the name and includes a passphrase, the file may become corrupted. If the SSL filename has 40 characters and there is no passphrase, this file corruption issue does not occur. Workaround: Limit SSL filenames to a maximum of 39 characters.
•CSCsx93472—When one real server sends traffic to another real server in the same subnet using the IP address of the server and a multicast MAC address as the destinations, the ACE may transmit the same packet towards the server but change the source MAC address. In this case, the destination real server will see duplicate packets.
•CSCsy00909—In a redundant configuration, the standby ACE may reboot if you add or delete 20 contexts in a loop for an overnight operation. The standby ACE may reboot after approximately 10 to 12 hours of operation. Workaround: None.
•CSCsy01905—Some SSL connections may continue to be accepted in the ACE even though the reference CRL, against which the revocation check is to be performed, has been removed. When the signature verification for the CRL fails, the CRL is removed from the ACE because it is considered untrusted. There may be some connections that have been accepted in the ACE prior to enabling signature verification of CRL. The fresh SSL connections with those client certificates continue to be accepted even though the reference CRL against which the revocation checks were performed have been removed as a result of a signature verification failure.
•CSCsy07749—With the ACE configured as a Dynamic Host Configuration Protocol (DHCP) agent, if a DHCP server sends a DHCP NAK packet to the ACE, the packet is received by the ACE, but in some cases, is not forwarded to the DHCP client.
•CSCsy10634—If the server farm is configured with the failaction purge command and a real server in the server farm changes its MAC address, the ACE resets both client and server connections without the server ever specifying the PROBE-FAILED or ARP-FAILED status.
•CSCsy13607—A buffer or memory leak is detected using the show np 1 me-stats "-s common" command. The buffer or memory leak may be a result of doing configuration changes to the SSL proxy in the ACE configuration by including a large number of SSL VIPs (approximately 1000) on the ACE.
•CSCsy15107—You may encounter a memory leak in the ACE if you delete or add a match statement in a Layer 7 load-balancing class map.
•CSCsy16439—If you are using application acceleration and optimization, if an embedded URL is fully qualified with https://, the FlashForward function will not be applied. This behavior occurs because the ACE sees all requests in HTTP mode. Workaround: Create a class map similar to the example illustrated below:
class-map type http loadbalance match-any cisco_img_latency_ssl
match http url https://(.*jpg)
match http url https://(.*jpeg)
match http url https://(.*jpe)
match http url https://(.*png)
match http url https://(.*gif)
match http url https://(.*css)
match http url https://(.*js)
match http url https://(.*class)
match http url https://(.*jar)
match http url https://(.*cab)
match http url https://(.*txt)
match http url https://(.*ps)
match http url https://(.*vbs)
match http url https://(.*xsl)
match http url https://(.*xml)
match http url https://(.*pdf)
match http url https://(.*swf)
Attach the following parameter map to this class map:
parameter-map type optimization http PM-modifier
cache key-modifier http://$(1)
•CSCsy16640—While running HTTP load-balancing traffic of approximately 100 users per second to a single VIP for approximately 10 minutes, and you make configuration changes to a load-balancing policy, you may find that both the active and standby ACE appliances become nonresponsive.
•CSCsy23136—When you apply an inline match statement in a policy map and then enter either the show run or write mem command, the ACE may stop responding for a few minutes and fail to deploy the configuration.
•CSCsy27609—When configuring the logging level 251010 to any (nondefault) level, and then removing the command with the no logging message 251010 level number command, you may find that logging continues at the previous level even though the show logging message 251010 displays the default logging level.
•CSCsy30882—The ACE may encounter SSL handshake failures when some unsupported key length crypto files (certificates or keys) are applied to the SSL proxy. When this event occurs, the SSL handshake fails.
•CSCsy34826—The following TCL PROBENOTICE scripted health monitoring probe fails to send an e-mail notification to a configured SMTP server when a real server fails the health probe.
probe scripted EMAILNOTIF
script PROBENOTICE_PROBE /index.html <SMTP_server_IP> user@your_company.com
Workaround: None.
•CSCsy41035—If you Telnet to a standby ACE device's interface IP address, bad packets are sent to the same connection. In this case, the standby ACE sends an ACK packet with a VMAC address for invalid packets.
•CSCsy48513—The ACE sends packets with the source MAC address set to that of a next hop router, which corrupts the MAC table on the intermediate switch.
•CSCsy49533—With a configured bridge-group virtual interface (BVI), the ACE may not properly bridge Bridge Protocol Data Units (BPDUs) in BVI mode.
•CSCsy51481—The ACE internal configuration manager becomes nonresponsive if the number of matching URLs in a single class map exceeds 54.
•CSCsy56718—The combination of HTTP application inspection and HTTP load balancing (including the configuration of server connection reuse) in a policy map that uses the class-default class map can result in HTTP traffic failing to properly pass through the ACE.
•CSCsy65275—An SSL connection may become unresponsive on receiving an erroneous SSL message while waiting for more data from the client.
•CSCsy69662—When the ACE attempts to send a stray connection to a TL server, the TL server becomes unresponsive when that connection is closed.
•CSCsy74111—The ACE forwards a 1-byte packet to servers. In this case, the 1-byte packet is actually a trailer byte that has been internally added by the ACE. When an odd length IP header is encountered, the ACE adds a nonzero trailer to the packet. The remove-eth-pad command has been added in A3(2.3) to enable an internal length check and remove any trailer bytes (appended to the end of an Ethernet IP frame) coming into the ACE. See Table 8 in the "Software Version A3(2.3) Command Changes" section.
•CSCsy75298—When using the ACE appliance Device Manager, if you attempt to edit the Resource Class field, Allocate Interface VLANs field, or Description field on the Primary Attributes page and then click Deploy Now, the configuration deployment can fail and the error "Error in saving to DB: null" will appear on the Device Manager GUI. This behavior typically occurs when a context on the Device Manager GUI is synchronized with the associated CLI copy. There are two ways that a context is synchronized in the ACE:
–Manual synchronization - You click the CLI Sync button after selecting a user context from the Config >Virtual Context screen.
–Automatic synchronization - You make configuration changes from the CLI. The Device Manager periodically checks for the CLI updates and performs synchronization if there are updates.
There is no issue in updating the other attributes on the Primary Attributes page; this issue is specific to the three attributes outlined above.
Workaround: When this problem occurs, perform a manual synchronization on the Admin context by selecting the Admin context from the Config >Virtual Contexts screen and clicking CLI Sync. After you perform this synchronization, you will be able to edit the Resource Class field, Allocate Interface VLANs field, or Description field on the Primary Attributes page. Note the following operating considerations regarding this issue:
–The context on the Device Manager GUI will again enter this error state upon the next Device Manager GUI and CLI synchronization. In this case, the workaround described above is required whenever you attempt to update the Resource Class field, Allocate Interface VLANs field, or Description field on the Primary Attributes page.
–Only a user with the Admin role in the Admin context can apply this workaround since these three fields are configured on the Admin context for all the user contexts.
•CSCsy81674—Removing a PAT pool and then readding a NAT pool with the same range can result in traffic getting NATed. This behavior can be encountered when you remove and add the configuration change in quick succession (within less than a 5-second time interval).
•CSCsy97098—The ACE may fail to send a fatal alert and the connection is torn down when the second packet arrives. This behavior can be encountered if the SSL Application Data and SSL Alert headers are interchanged on an SSL client. If the client sends a request for get/post data after a successful handshake, the ACE fails to send an alert to the client.
•CSCsz05213—When an incomplete certificate/key pair configuration is used by the SSL proxy client, SSL initiation does not work properly. This behavior can be encountered when the SSL proxy client has been configured with only the certificate or only the key.
•CSCsz06342—The output from the show serverfarm command may display current connection entries even when there is no traffic. This behavior can be encountered when the ACE has been configured for point-to-multi-point and point-to-point traffic, and application inspection has been enabled.
•CSCsz12933—After you configure a connection limit and backup real servers in a server farm, you may experience the ACE stopping the load balancing of traffic that is passing through the ACE. When this occurs, the Xscale loadbalance process (loadBalance_g_ns) shows a 99 percent utilization.
•CSCsz15467—Configuration synchronization fails between the active and standby ACE appliances, and the standby ACE continues to be in the STANDBY-HOT state. This behavior occurs for certificate revocation lists (CRLs) in an SSL parameter map, when a CA certification file that is used in the SSL configuration is located on the active ACE but is not available on the standby ACE. In this case, the standby ACE remains in the STANDBY-HOT state.
•CSCsz22806—While operating under normal conditions, the ACE may reboot while processing internal statistics.
•CSCsz32915, CSCte17372—If you create a context with a name that is 64 characters, if you import a crypto file, the file import will fail and you will see the following error message: "Error: No PEM data to import from terminal before 'quit'."
•CSCsz34627—The ACE performs a core dump of the fastpath. This behavior occurs because FP threads are stuck as a result of Fast-tx receiving a RAW packet which is then transmitted with a reference count of 0.
•CSCsz34874—Layer 7 load balancing does not function properly for jumbo frames and when using a maximum transmission unit (MTU) that is above 1500 for an interface.
•CSCsz39874—An attempt to transfer a configuration to the XML agent that is larger than 4 kB results in the ACE becoming nonresponsive and the mesage"500 Internal Server Error" appears. When this behavior occurs, the Application Networking Manager (ANM) may not function properly.
•CSCsz40658—When you develop an SSL traffic policy, the ACE enables persistence rebalance by default for any type of load balancing policy.
•CSCsz52945—When the ACE is running software version A3(2.2) and you are using the Device Manager GUI, if you log in as a non-admin user and attempt to create a new virtual context in the New Virtual Context page, a "java.lang.NullPointerException" pop-up error appears every time you press Deploy Now in a GUI screen.
•CSCsz56671—The ACE drops Layer 4 class-default packets when the client has MTU configured.
•CSCsz57920—With the ACE configured for SSL termination, the ACE may become nonresponsive if it receives a large number of invalid handshake requests from a client. This condition can be identified by a large number of total tried connections in the SSL statistics on the ACE (on the order of 100,000 connections). The ACE appliance will send a fatal alert and close the connection, as expected. After these steps are repeated a certain number of times, the ACE becomes nonresponsive.
•CSCsz59659—The ACE may develop a significant memory leak in internal buffer particles on the data plane. The memory leak occurs with Layer UDP connections (for example, with generic protocol parsing, payload sticky, or UDP fast-age traffic).
•CSCsz61535—The write memory all command generates errors and the output displays the attempted execution of shell commands. This issue occurs when you configure context names that use special symbols interpreted by the command shell, for example a semicolon, pipe, and so on. When defining context names, avoid using an opening brace, closing brace, white space, or any of the following symbols: ` ! $ % & * ( ) \ |; ' " < > / ?.
•CSCsz65702—With the ACE configured for application acceleration and optimization, changing a class map may impact existing optimized connections. Changes made to a class map may cause an interruption to existing sessions due to restarting of internal processes. During the restart of the process, an existing session may receive optimized data that is malformed, which can cause the client to fail the session.
•CSCsz78190—When operating in a redundant configuration, with NAT functionality applied at a high rate, HA heartbeats are missed, causing the active and standby role to be swapped one or more times between ACE devices.
•CSCsz80038—A checkpoint rollback may fail for large configurations that contain a policy map with inline match statements. The execution of the checkpoint rollback command results in the display of the "*** Context 0: cmd exec error ***" for every line of the configuration, which ultimately results in a rollback failure.
•CSCsz87592—Management traffic sent to the ACE is denied even when the traffic rate is very low. If you use the show resource usage command, the output shows that the management traffic rate is unusually high.
•CSCsz89603—In some cases, the installed performance throughput license (see Table 2) is not properly enforced by the ACE.
•CSCta14378—With an MTU greater than 1500 (default setting) configured for an interface, in some cases, the reuse and reproxy functions will fail.
•CSCta21031—For an FTP client, the ACE accepts EPRT commands that have a mismatched IP address that is different than that of the FTP client.
•CSCta34665—The ACE appliance Device Manager GUI requires modifications to support the Server-Maintenance role "permit modify real-inservice" function.
•CSCta35675—For a user that has a custom domain, if that user logs into the ACE appliance Device Manager GUI, there are real servers in the domain definition that do not appear in the Device Manager.
•CSCta56623—When you attempt to upgrade software from software version A3(2.2) to A3(2.3) on your ACE appliances configured as redundant peers, you may encounter problems that prevent you from completing the upgrade. This issue occurs as a result of a duplex command syntax change between A3(2.1) and A3(2.2), if your ACE configuration includes one or more Gigabit Ethernet ports that are configured for full or half duplex operation, before you upgrade from A3(2.2) to A3(2.3) you must first remove the duplex configuration from the startup-configuration file on both the active ACE and standby (peer) ACE. See the "Removing the duplex Command from the ACE Configuration" section in this release note for details.
Note You may also encounter this issue when you attempt to downgrade from software version A3(2.3) to A3(2.2). See the "Before You Begin" section in the "Downgrading Your ACE Software in a Redundant Configuration" section for details.
Software Version A3(2.3) Open Caveats
The following open caveats apply to ACE software version A3(2.3).
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsu85286—When using the ACE appliance Device Manager GUI, you may find entries for Device Manager activities in the show accounting log command output display the "dm" user instead of the actual username that was used to log in to the ACE appliance Device Manager GUI. Workaround: None.
•CSCsv62417—In some instances, the virtual MAC address is used for both the client-side VIP addresses and server-side NAT pools. With an FT VLAN configuration, the virtual MAC address is used as the source MAC for both client- and server-side packets. This behavior can cause issues in specific network topologies where the client-side and server-side end up learning the same MAC address over two ports. Without the FT VLAN, the internal MAC address is used. Workaround: Use the mac address autogenerate command to enable the autogeneration of a MAC address.
•CSCsx82538—After adding a secondary logging host to an ACE logging configuration, the ACE syslogd process may spike and cause the ACE show commands to become unresponsive. Workaround: Configure a single logging host.
•CSCta49323—The ACE unexpectedly becomes nonresponsive, generating a core dump and then rebooting. This behavior can occur when the TCP receive queue is full, which indicates a high TCP traffic load to the ACE. Workaround: You can control how the ACE applies TCP optimizations to packets on a connection associated with a Layer 7 policy map using a round-trip time (RTT) value by using the set tcp wan-optimization rtt 0 command in parameter map connection configuration mode. For a value of 0, the ACE applies TCP optimizations to packets for the life of a connection. See the Cisco ACE 4700 Series Appliance Security Configuration Guide, Chapter 4, Configuring TCP/IP Normalization and IP Reassembly Parameters.
•CSCta65386—The ACE can become unstable, consuming and leaking a significant amount of dynamic memory, and eventually become nonresponsive when it receives SSL traffic that involves client authentication for a large number of unique client certificates (greater than 20,000). The rate of memory leak is proportional to the traffic that is using unique client certificates. Workaround: None.
•CSCta79145—The ACE may have a memory leak when chained client certifications are presented to it as part of front-end client authentication. The leak can aggregate over a period of time, which will bring the ACE to a state where it cannot allow any new SSL connection. Workaround: None.
•CSCta87270—When using application acceleration and optimization, the ACE generates an HTTP 400 bad request error message. This behavior typically occurs when an HTTP header exceeds 8190 bytes. Workaround: Reduce the size of the HTTP header.
•CSCta87290—During operation, the ACE may generate the following message:
Jul 15 2009 17:21:35 10.128.219.150/A75ACE1-B: %ACE-3-456042: Disk cache error. file
IO error. File is /x86/avs/cache/ausr/8/1/4/8/Bdopeh5rvru3iptjv23c3zmp0h.base, exce
ption is errno:17 errno string:File exists.
This message is an internal log message that should not be displayed by the ACE. Workaround: None.
•CSCta95804—When using the ACE appliance Device Manager GUI, if you configure a class map or rule match in a specific order for a virtual server in Advanced View in the Layer 7 Load Balancing Rule Match table (Config > Virtual Contexts > context > Load Balancing > Virtual Servers), the class map or rule match are deployed out of order when displayed from the CLI. If configured in Expert mode, the Layer 7 load-balancing policy map displays a different order as well. This issue may cause an unintended behavior depending on how L7 class/rules are applied for L7 load balanced connections Workaround: Apply the desired configuration in the intended order manually from the CLI and avoid deploying any configuration changes for that virtual server from the Device Manager GUI.
•CSCta95804—When using the ACE appliance Device Manager GUI, rules configured under the L7 Load Balancing section in the Device Manager Virtual Server page Config > Virtual Contexts > context > Load Balancing > Virtual Servers) may appear to be in a different sequence than that shown in the CLI. This is also true of the advanced Expert mode on the DM for the L7 load balance policy map. This behavior occurs only when you attempt to edit a virtual server and edit the sequence of the Rules in the L7 Load Balancing section using the Up/Down buttons, and the updated sequence shown on the GUI is not updated on the CLI. The above issue only occurs during an edit of a virtual server; you will not encounter this mismatched behavior during the creation of a new virtual server. Workaround: If the sequence of rules in the L7 Load Balancing section in the Device Manager Virtual Server page is intended to be updated, perform the update by deleting and then readding the rules in the intended order rather than using the Up/Down buttons to change the sequence to avoid the mismatch.
•CSCta95875—When using the ACE appliance Device Manager GUI, you may encounter an inconsistency in operation when you manually specify the default-compression-exclusion-mime-type. Initially, the configuration will be deployed correctly. However the next time you go in the virtual server configuration, the default-compression-exclusion-mime-type will be removed. The default-compression-exclusion-mime-type is created by default by the Device Manager when you use the Gzip HTTP compression format on a Layer 7 SLB policy.Workaround: Create a custom class map that is identical to the default-compression-exclusion-mime-type class map but uses a different name. Reference this new class map in the virtual server configuration.
•CSCta99048—When you use the show rserver command to display summary or detailed statistics for a named real server or for all real servers, the command output displays more connections then when you use the show conns command. This different in connection causes issues with the maximum allowable number of active connections to a real server when the level of traffic is lower then displayed using the show commands. Workaround: Remove or increase real server maximum connection limits.
•CSCtb03738—Incremental configuration synchronization of the CLI snmp-server unmask-community command (see Table 8) fails from the active ACE to the standby ACE peer. This issue occurs in non-Admin contexts.Workaround: Perform bulk synchronization to resolve the issue by executing following commands on the active ACE:
–ft auto-sync running-config
–no ft auto-sync running-config
•CSCtc05893—When you use the ACE appliance Device Manager GUI, you may encounter an unsuccessful import of a certificate when attempting a terminal import. This condition occurs when you attempt to import a non-certificate/non-key such as text (for example, PEM-formatted data without the -----END CERTIFICATE----- or -----END RSA PRIVATE KEY-----) by performing a terminal import from the Device Manager GUI. This behavior can cause a socket timeout exception, which results in an open hanging session on the ACE. Workaround: Clear the SSH session.
Software Version A3(2.3) Command Changes
Table 8 lists the commands and options that have been changed in software version A3(2.3).
Note For details on the new "\xST" metacharacter that has been added to A3(2.3) for regular expressions used for Layer 4 generic data parsing, see the "Using the"\xST" Metacharacter in Regular Expressions for Layer 4 Generic Data Parsing" section in this release note.
Table 8 CLI Commands Changed in Version A3(2.3)
|
Mode
|
Command and Syntax
|
Description
|
Exec |
show acl-merge {acls internal-vlan [vlan_id] {in | out} [summary]} | {match internal-vlan [vlan_id] {in | out} ip_address1 ip_address2 protocol src_port dest_port} | {merged-list internal-vlan [vlan_id] {in | out} [non-redundant | summary]} |
The new internal-vlan keyword displays the ACL merge information for VLAN 1. (Added per CSCsy38790.) |
Exec |
clear stats resource-usage |
The new resource-usage keyword clears the Peak and Denied fields displayed by the show resource usage command. |
Exec |
show action-list |
A Description field has been added to the show action-list command output. This field displays the previously entered summary about the specific parameter map. (Added per CSCsr89559.) |
Exec |
show crypto crl best-effort |
The new best effort keyword displays summarized information for all best-effort CRLs on the ACE (a maximum of 16 CRLs). The output for this command includes the following fields: •Best-Effort CRL—Identifier to distinguish each best-effort CRL present at this time. At another time, the identifier can vary for the same CRL. •CRL Distribution Point—URL of the CDP. The ACE displays the first 255 characters of the URL. •CRL Downloaded—Whether the CRL is downloaded on the ACE, Yes or No. •CRL Issuer Name—Name of the CRL issuer. The ACE displays the first 255 characters of the name. •Last Update—Contents of the Last Update field extracted from the CRL. The ACE displays the first 64 characters in the field. •Next Update—Contents of the Next Update field extracted from the CRL. The ACE displays the first 64 characters in the field. If a no best-effort CRL exists on the ACE, the ACE displays the following message:
No best effort crl present in the system
(Added per CSCsx53182.) |
Exec |
show license status |
The Count value for Web Optimization in the show license status command output has been modified from "cps" to "concurrent connections." (Added per CSCsz12269) |
Exec |
show parameter-map |
A Description field has been added to the show parameter-map command output. This field displays the previously entered summary about the specific parameter map. (Added per CSCsr89570.) |
Exec |
show serverfarm [name] [detail] |
The fields displayed by this command now include the real server description field as defined by the description command in serverfarm host real server configuration mode. |
Configuration |
context name |
This command now prevents you from configuring a context name that contains opening braces, closing braces, white spaces, or any of the following symbols: ` $ % & * ( ) \ | ; ' " < > / ? (Added per CSCsz61535.) |
Config |
snmp-server engineid number |
The snmp-server engineid command has been added to configure the SNMP engine ID for an ACE context (Admin or user). Use the no form of this command to reset the default engine ID for the context. The number argument specifies the SNMPv3 engine ID that you want to configure. Enter a range of 10 to 64 hexadecimal digits. The ACE allows you to configure an SNMP engine ID for the Admin or user context. By default, the ACE automatically creates an SNMP engine ID for the Admin context and each user context. The SNMP engine represents a logically separate SNMP agent. The IP address for an ACE context provides access to only one SNMP engine ID. For example, to configure engine ID 88439573498573888843957349857388 for the Admin context, enter:
host1/Admin(config)# snmp-server engineID
88439573498573888843957349857388
(Added per CSCsy50303.) |
Configuration |
snmp-server unmask-community no snmp-server unmask-community |
The unmask-community keyword allows you to unmask the snmpCommunityName and snmpCommunitySecurityName OIDs of the SNMP-COMMUNITY-MIB. By default, they are masked. Use the no form of the command to mask them. (Added per CSCsu90547.) |
Action list modify Action list optimization |
description |
The description command has been added to the commands in the action list modify configuration mode and action list optimization configuration mode. Use this command to add a description about the specific action list. Enter a description as an unquoted text string with a maximum of 240 alphanumeric characters. (Added per CSCsr89559.) |
Interface |
remove-eth-pad |
The remove-eth-pad command has been added in A3(2.3) to enable an internal length check and remove any trailer bytes (appended to the end of an Ethernet IP frame) coming into the ACE. This check is performed for each interface and is disabled by default. (Added per CSCsy74111) |
Parameter map connection Parameter map DNS Parameter map generic Parameter map HTTP Parameter map optimization Parameter map RTSP Parameter map SCCP Parameter map SIP Parameter map SSL |
description |
The description command has been added to the commands in the individual parameter map configuration modes. Use this command to add a description about the specific parameter map. Enter a description as an unquoted text string with a maximum of 240 alphanumeric characters. (Added per CSCsr89570.) |
Parameter map HTTP configuration |
set secondary-cookie-start {none | text} no set secondary-cookie-start |
Defines the ASCII-character string at the start of a secondary cookie in a URL or ignores any start string of a secondary cookie in the URL and considers the secondary cookie part of the URL. The keyword and argument for this command are as follows: •none—The secondary cookie start is not configured or the ACE ignores any start string of a secondary cookie in the URL and considers the secondary cookie as part of the URL. When you configure the none keyword to consider the entire URL query string as part of a URL, the commands that rely on the URL query, such as the match cookie secondary and predictor hash cookie secondary commands, do not work. Do not configure these commands under the same real server. •text—The start string of the secondary cookie. Enter a maximum of two characters. The default is ?. Use the no form of this command to reset the start string to the default of ?. (Added per CSCsx98352.) |
Revised System Log Messages
Software version A3(2.3) includes the following revised system log (syslog) messages.
253004
Error Message %ACE-6-253004: Certificate subject_of_certificate revoked, ssl-proxy:
proxy_name, reason: reason
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 is due to one of the following events:
•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.
Recommended Action None required.
441001
Error Message %ACE-5-441001: Serverfarm (name) failed over to backupServerfarm
(backup_name) in policy_map (lb_Policy_Map). Number of failovers = count1, number
of times back in service = count2
Explanation A serverfarm failover event has occurred. The name variable is the name of the server farm. The backup_name is the name of the backup server farm. The lb_Policy_Map is the name of the load-balancing policy map. The count1 variable is the number of times that the primary server farm failed over to the backup server farm. The count2 variable is the number of times that the primary server farm returned to service.
Recommended Action None required.
441002
Error Message %ACE-5-441002: Serverfarm (name) is now back in service in policy_map
(lb_Policy_Map). Number of failovers = count1, number of times back in service =
count2
Explanation A serverfarm in a service event has occurred. The name variable is the name of the server farm. The lb_Policy_Map is the name of the load-balancing policy map. The count1 variable is the number of times that the primary server farm failed over to the backup server farm. The count2 variable is the number of times that the primary server farm returned to service.
Recommended Action None required.
Software Version A3(2.2) Resolved Caveats, Open Caveats, and Command Changes
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats in software version A3(2.2):
•Software Version A3(2.2) Resolved Caveats
•Software Version A3(2.2) Open Caveats
•Software Version A3(2.2) Command Changes
Software Version A3(2.2) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.2).
•CSCsg95099—When you configure SNMP notification using the ACE appliance Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. This information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > CLI Sync or CLI Sync All.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCso29529—A user with the configured role of Network-Monitor is allowed to delete other user directories on the ACE. Workaround: Do not configure a user with the Network-Monitor role. See the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide
•CSCsq58483—When you are using the ACE appliance Device Manager GUI to configure a real server (Config > Virtual Contexts > Load Balancing > Real Servers) and you add a redirect real server, the Web Host Redirection field length cannot exceed 127 characters. If you enter more than 127 characters, an error occurs. Workaround: None.
•CSCsr23197, CSCsq43870—When operating in a redundant configuration, if you perform a reload of the higher priority active ACE in an FT group setup (ACE-1) and the appliance goes back online, if ACE-1 does not receive a heartbeat from the standby ACE-2 peer, ACE-1 assumes that the peer is down and immediately moves to the ACTIVE state. Later, when ACE-1 does receives a heartbeat from the ACE-2 peer, ACE-1 sends its configuration to the ACE-2 peer which now has the higher priority.
Any applied configuration changes that were made to the ACE-2 peer with the lower priority during the time when the higher priority ACE-1 was reloading will be lost once ACE-1 becomes active. In addition, the connections sustained by the ACE-2 peer will also be flushed.
To avoid this behavior, the A3(1.0) software release has added the carrier-delay command to the interface configuration mode to add a configurable transition delay at the physical port level for the FT VLAN. When you configure a carrier-delay transition time for a physical Ethernet port, the active ACE that is proceeding from a reload does not change to the ACTIVE state for the duration of the specified carrier-delay timer. This configurable transition time provides a window for the ACE-2 peer to sense that the other peer has returned from a reload state. At that point, the ACE-2 peer can send a heartbeat to ACE-1. The use of the carrier-delay transition time can provide ACE-1 with sufficient time to return from the reload and properly move into the INIT state, the STANDBY_CONFIG state, the STANDBY_BULK state, and finally to the ACTIVE state. As a result, all configuration changes performed to the ACE-2 peer during the reload period are properly synchronized to ACE-1.
If you downgrade from software version A3(1.0) to A1(7a) or A1(7b), those earlier software releases do not support the use of the carrier-delay feature.
In addition, if you download to A1(8.0) or A1(8.0a), even though the carrier-delay command is a configurable selection, the ACE that is proceeding from a reload moves directly into the ACTIVE state. If the reloaded ACE-1 happens to be of a higher priority, all configuration changes made to the ACE-2 peer during the reload sequence of ACE-1 will be lost once ACE-1 becomes active.
Workaround: If you intend to downgrade from software version A3(1.0) to the A1(8.0) or A1(8.0a) software release, first save the current running-config file on the active ACE before you perform the software downgrade procedure on the active ACE.
For downgrade instructions, see the "Downgrading Your ACE Software in a Redundant Configuration" section.
•CSCsr31048—The XML interface may return the incorrect syntax for policy map multi-match commands. The XML interface may send the following syntax:
policy-map_multimatch type='multi-match'
instead of:
policy-map_multimatch match-type='multi-match
Workaround: None.
•CSCsr56251—The ACE does not allow a cyclic backup of real servers in a server farm. For example, in the configuration outlined below, the ACE displays the following error "Cannot assign backup rservers in cyclic order":
switch/Admin(config-rserver-host)# serverfarm host sf1
switch/Admin(config-sfarm-host)# transparent
switch/Admin(config-sfarm-host)# failaction reassign
switch/Admin(config-sfarm-host)# predictor hash address source
switch/Admin(config-sfarm-host)# probe icmp1
switch/Admin(config-sfarm-host)# rserver rs1
switch/Admin(config-sfarm-host-rs)# backup-rserver rs4
switch/Admin(config-sfarm-host-rs)# inservice
switch/Admin(config-sfarm-host-rs)# rserver rs4
switch/Admin(config-sfarm-host-rs)# backup-rserver rs1
Error: Cannot assign backup rservers in cyclic order
switch/Admin(config-sfarm-host-rs)# inservice
A cyclic backup of real servers in a server farm is a useful feature for firewall loadbalancing. Assuming that rs1 and rs4 are firewalls, with the current cyclic configuration restriction, you cannot back up one firewall with the other firewall. Workaround: None.
•CSCsr67556—When you perform a checkpoint rollback, you may find that an access-group configuration is lost during the rollback. This behavior can occur if during the rollback all of the lines associated with an access-list are removed from the configuration, and then any associated access-group configuration that refer to the access-list is also removed. If the access-group configuration was also part of the configuration in which the rollback was being made to, then this access-group configuration will not be reconfigured. This issue applies to both globally configured access-groups as well as access-groups applied to VLAN subconfigurations. Workaround: To prevent the issue, use access-list remarks. These remarks should be present and identical in the current running-configuration and in the configuration to which you will be rolling back.
For example:
access-list one remark workaround
access-list one ex permit udp any any
access-list one ex permit icmp any any
access-list one remark workaround
access-list one ex permit ip any any
Another way to prevent this issue is to fully remove the access-list from the running-configuration file before you perform the checkpoint rollback. A manual configuration of the lost access-group will resolve it.
Checkpoint rollback will display the configuration that the system was unable to rollback to, as shown below:
switch/test# check roll test2B
---------------------------------------------------------------------
-- This operation will rollback the system's running-config to the --
-- checkpoint's configuration. This can take sometime depending on --
-- the amount of diff between the two configurations. --
---------------------------------------------------------------------
Do you wish to proceed? (y/n) [n] y
Config rollback in progress...failed.
Below diff could not be applied to running-config.
In the above example, the access-group input HTTP command is the command that the ACE could not apply. Manual rollback is then necessary for this command.
Additionally, the output of the show acl-merge merged vlan command would display the message: "% Interface or access-list/service-policy not found."
•CSCsv37247—In some instances, SIP traffic may fail to match a Layer 7 policy and a No Policy Match result displays under LB Statistics in the output of the sh np 1 me-stats "-s lb" command. This behavior can occur when the Call-ID is configured in the Layer 7 class map as well as a sticky server farm. Workaround: Use a different header match (for example, use From or Via) in the Layer 7 class map.
•CSCsv40251—The ACE may reload after you modify a class map by including the match source-address command. This behavior can occur if the match source-address command includes an invalid network mask. Workaround: None.
•CSCsv65894—If you configure RADIUS load balancing with the sticky radius framed-ip command, and a Framed-IP-Address attribute is reused and is load balanced to a different real server, in some cases the sticky entry is not updated. Workaround: Perform one of the following actions:
–Configure the RADIUS client to issue the Framed-IP-Addresses and include them in the RADIUS access request messages.
–Configure separate Framed-IP-Address pools for each RADIUS real server.
•CSCsv66682—User requests that hit a static sticky entry may be dropped. This behavior can occur when a static sticky entry is configured for the current sticky group and the sticky group is not using the cookie insert function. In this case, the real server associated with the static sticky entry (including the backup server if one is configured) is placed out of service. When a user sends a request that hits the sticky entry, the request is dropped. Workaround: None.
•CSCsv69698—The ACE may fail to properly load balance between servers; the load distribution is skewed to the point where some servers may receive no connections and other servers receive thousands of connections. This behavior can occur when you configure the ACE for stickiness with a Least Connections predictor with a configured slowstart. When a probe fails, the real server goes out-of-service. When the real server comes back in service and the probe succeeds, the real server distribution does not recover. Workaround: Reset the predictor method to the default of round-robin and then reselect the Least Connections predictor to resolve this issue.
•CSCsv95366—When you use the ACE appliance Device Manager GUI, in some instances after you log in to the Device Manager you may see a blank page. The issue occurs after upgrading to the A3(x) release. Workaround: Perform one of the following workarounds:
–Enter the reload command in Exec mode to reboot the ACE.
–Upgrade to software version A3(2.2) or higher.
•CSCsw32816—In some instances when the ACE runs software version A2.1.2, it can access invalid memory and generate an SNMPD core dump. Workaround: None.
•CSCsw34406—In a redundant configuration, configuration synchronization may fail between the active and the standby ACE and the fault tolerance is not set properly. This behavior may occur when the ACE has 1023 match statements in a class map. Workaround: None.
•CSCsw35639—The ACE may become unresponsive when certain configuration and show commands are not properly executed in the following situations:
–You configure a relatively small maximum allowable number of active connections to a real server limit (with min-conns equal to max-conns).
–A high volume of traffic is transmitted, resulting in the servers transitioning in and out of the maximum connections setting numerous times per second.
When one of these conditions occurs, the ACE can become unresponsive as a result of frequent updates between the dataplane and the control plane. Workaround: None.
•CSCsw37026—RTSP probes may start to fail when you change the request method from Describe to Options, and the error "Server Reply Timeout" appears. Workaround: Remove the association of the RTSP probe from the real server and server farm and then reconfigure the association.
•CSCsw39950—Reordering class maps under a multi-match policy map may cause other class maps under the same policy to stop working. Workaround: Remove and then add any class map that is not working from the multi-match policy map.
•CSCsw52225—Sticky database entries on Context A for real servers are also configured in Context B. This behavior can occur when a real server in a server farm was deleted in Context A and the real server ID was reused when you added that real server to the server farm in Context B. Workaround: Enter the clear sticky database command in the affected context.
•CSCsw53212—The console or terminal may lock up briefly when you modify match source-address command entries in a configuration with numerous match source IP addresses (more than 2000 entries) while the ACE has a high traffic load. Workaround: None.
•CSCsw71730—The HM process in an ACE terminates on receiving Signal 11, Segmentation Fault. This behavior may occur when you make configuration changes to IP addresses for DNS probes that are attached to several real servers or server farms. Workaround: None.
•CSCsw72386—A VSH core may occur when you enter the show tech-support command. This behavior may occur when you are running end-to-end SSL traffic at a high rate. Workaround: None.
•CSCsw73259—The ACE may reboot when you configure a bandwidth rate. This behavior may occur from an improper memory access or segmentation fault. Workaround: None.
•CSCsw74907—The ACE may reboot when you continuously add and remove a server farm from a configuration. This behavior can occur as a result of a memory leak where the ACE runs out of system memory space. Workaround: None.
•CSCsw80319—The match source-address command in a class map may not function properly when there are more than 4000 IP source addresses in the configuration and you remove and then reconfigure the associated policy map. Workaround: None.
•CSCsw82248—The HM process in an ACE terminates on receiving Signal 11, Segmentation Fault. This behavior may occur when a malformed DNS packet is sent as response to the a DNS probe. Workaround: None.
•CSCsw88220—A large HTTP POST request may not load balance correctly if the server responds while the POST is ongoing. Some part of the data goes to the original server, that server responds with a 4XX error response, and then the remainder of the data is load balanced to another server in the class-default server farm. The request must match a policy that has persistence-rebalance and a class-default configured, and the request/response is an error condition. Typically, this early response can be due to a 401 Not Authorized error. Workaround: Perform one of the following actions:
–Enter the no persistence-rebalance command to remove persistence rebalance from the HTTP parameter map
–Enter the set tcp wan-optimization rtt 0 command to a connection parameter-map.
•CSCsw99027—In a redundant configuration, when a client and server close a TCP-based To-CP (HTTP, HTTPS, Telnet) connection to the standby ACE using an RST with the wrong sequence number, the standby ACE responds with an ACK that uses the virtual MAC address as source IP address. This behavior may create a switching issue because the Layer 2 switches rewrite the path for the virtual MAC pointing it to the standby ACE instead of the active ACE. Workaround: None.
•CSCsx07493—If you perform client authentication with certificate revocation list (CRL) checking, the ACE may fail to verify that the downloaded CRL was signed by a trusted Certificate Authority (CA). This issue can allow another CRL to be substituted and certificate revocation to be bypassed. Workaround: None.
•CSCsx10161—In some instances, although all the real servers in a server farm have reached the maximum number of active connections state (specified through the conn-limit max command), the ACE may not fail over to the backup server farm. As a result, the ACE rejects all new connections that hit the VIP. This behavior can occur when you apply the specified maximum connections limit at the real server level. Workaround: Apply the same maximum connection limit that you configured at the real server level to the real server that is associated with the server farm.
•CSCsx13576—When you perform a checkpoint rollback, in some cases, the checkpoint rollback may fail for a class map source IP address match criteria configuration. This behavior can occur when there are two checkpoints with the same class map name and include 1023 match-source address statements, but the source IP address and subnet mask values are different in these checkpoints and the ACE attempts to switch between these two checkpoints. Workaround: Wait approximately 15 seconds and reapply the match-source address statements that have failed.
•CSCsx13875—The clock displayed from the CLI and from the Device Manager GUI are different. The Device Manager GUI always displays the time in GMT irrespective of the timezone setting of the ACE. Workaround: None.
•CSCsx15199—When concurrent traffic connections are created and closed in the ACE, and you enter the show conn command, the ACE may reboot due to an invalid interface ID in the expired connection entry. Workaround: None.
•CSCsx17585—The file upload function may fail when you are using the Microsoft Internet Explorer browser. You cannot see the file after you attempt an upload, or the file is there and includes the complete client original path name. In some cases, the directory path (for example, image: or core:) is replicated after the upload attempt. Workaround: Use the Firefox browser to perform a file upload.
•CSCsx18460—During an SSL session where a client sends some newer ciphers (such as ECC ciphers) in the ClientHello message, the ACE may select a cipher that does not match. Workaround: Remove any unsupported ciphers from the client cipher list.
•CSCsx20383—With the SYN Cookie enabled, the ACE may reboot when sending HTTP traffic. Workaround: Disable the SYN Cookie function.
•CSCsx21484—In a redundant configuration, both ACE appliances may be active and are able to ping each other across the FT VLAN, yet neither ACE shows a heartbeat received from the other peer ACE. Workaround: Remove the ft peer command from the configuration, and then add it back in to restart the heartbeat.
•CSCsx27840—When you apply a class map with a large configuration (approximately 4000 statements) to multiple policy maps, the ACE may contain an incorrect client map tree and traffic may hit the wrong policy. Workaround: None.
•CSCsx29221—The ACE may reboot when there is SSL back-end traffic (including HTTPS probes). because the SSL server is not using an RSA certificate. Workaround: Ensure that the SSL server uses an RSA certificate.
•CSCsx29572—When the ACE is configured for TACACS user authentication and you are using Application Networking Manager (ANM) software version 2.0 to import the ACE, in some instances, the device import may fail. Workaround: Perform one of the following actions:
–Configure the TACACS user locally on the ACE.
–Restart httpd on the ACE.
•CSCsx31063—After you perform numerous login and logout sequences on the ACE, the ACE may begin to generate disk write errors. For example, you may encounter a disk write error when entering the write memory command:
who: write error: No space left on device
Generating configuration....
running config of context Admin saved
In addition, commands such as dir image: may report negative disk usage values. Workaround: None.
•CSCsx32861—When you associate the primary and backup server farm under a sticky group, if all the real servers specified in the primary server farm go down, the ACE moves the primary server farm to the INACTIVE state but may not fail over to the backup server farm. As a result, all of the incoming connections are rejected. Workaround: None.
•CSCsx41114—In some instances, after you make a configuration change to a policy map, the ACE may record a service policy download error when modifying the configuration on an interface. Workaround: None.
•CSCsx42775—The ACE buffer utilization may increase over time. When this issue occurs, you can view the closed connections by specifying the show conn protocol tcp | inc CLSRST command. The show output displays a large number of connections. Workaround: Enter the clear flow command for all flows in the CLSRST state to free up buffers.
•CSCsx47221—A memory leak may occur on the ACE when you run a heavy volume of HTTP traffic with inspection over a long period of time. This memory leak can occur when you change the HTTP configuration or when you enter the clear connection command while traffic is running. Workaround: None.
•CSCsx55135—The configuration manager (cfgmgr) in the ACE may become unresponsive when a significant number of messages are received by the configuration manager from the LB module. Workaround: None.
•CSCsx73864—In some instances, crypto files may be deleted if high loads are created on the control plane of the ACE. This behavior can occur when you cut and paste a large configuration. Workaround: Cut and paste large configurations in small segments, giving each segment time to properly load on the ACE before moving to the next segment.
•CSCsx76323—When you upgrade the ACE software to A3(2.1), you may see that HTTP health probes are forwarded to ports 80 and 443 instead of to port 80. This behavior is due to the new port inheritance feature of software version A3(2.1). Workaround: None.
Software Version A3(2.2) Open Caveats
The following open caveats apply to ACE software version A3(2.2).
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsu85286—When using the ACE appliance Device Manager GUI, you may find entries for Device Manager activities in the show accounting log command output display the "dm" user instead of the actual username that was used to log in to the ACE appliance Device Manager GUI. Workaround: None.
•CSCsv62417—In some instances, the virtual MAC address is used for both the client-side VIP addresses and server-side NAT pools. With an FT VLAN configuration, the virtual MAC address is used as the source MAC for both client- and server-side packets. This behavior can cause issues in specific network topologies where the client-side and server-side end up learning the same MAC address over two ports. Without the FT VLAN, the internal MAC address is used. Workaround: Use the mac address autogenerate command to enable the autogeneration of a MAC address.
•CSCsw81096—In some instances, the show service-policy detail command generates an error and fails to display the show output for all associated class maps when there is a large configuration associated with the policy map. Workaround: None.
•CSCsx62720—When a server sends traffic to another server in the same subnet using the following as destinations:
–Layer 3—The IP address of the server
–Layer 2—A multicast MAC address
The ACE may transmit the same packet to the server but may change the source MAC address to its own MAC address on the VLAN. In this case, the destination server will see duplicate packets. Workaround: Set up an ACL to block server A to server B traffic on the ACE. For example:
access-list test line 10 extended deny ip host 192.168.33.251 host 192.168.33.200
access-list test line 20 extended permit ip any any
•CSCsx63170—When you import an SSL file that has 40 characters in the name and includes a passphrase, the file may become corrupted. If the SSL filename has 40 characters and there is no passphrase, this file corruption issue does not occur. Workaround: Limit SSL filenames to a maximum of 39 characters.
•CSCsx82538—After adding a secondary logging host to an ACE logging configuration, the ACE syslogd process may spike and cause the ACE show commands to become unresponsive. Workaround: Configure a single logging host.
•CSCsy07749—With the ACE configured as a Dynamic Host Configuration Protocol (DHCP) agent, if a DHCP server sends a DHCP NAK packet to the ACE, the packet is received by the appliance but, in some cases, it is not forwarded towards the DHCP client. Workaround: None.
•CSCsy00909—In a redundant configuration, the standby ACE may reboot if you add or delete 20 contexts in a loop for an overnight operation. The standby ACE may reboot after approximately 10 to 12 hours of operation. Workaround: None.
•CSCsy10634—If the server farm is configured with the failaction purge command and a real server in the server farm changes its MAC address, the ACE resets both client and server connections without the server ever specifying the PROBE-FAILED or ARP-FAILED status. Workaround: Disable the failaction purge command for the server farm.
•CSCsy15107—You may encounter a memory leak in the ACE if you delete or add a match statement in a Layer 7 loadbalance class map. Workaround: None.
•CSCsy16439—If you are using application acceleration and optimization, if an embedded URL is fully qualified with https://, the FlashForward function will not be applied. This behavior occurs because the ACE sees all requests in HTTP mode. Workaround: Create a class map similar to the example illustrated below:
class-map type http loadbalance match-any cisco_img_latency_ssl
match http url https://(.*jpg)
match http url https://(.*jpeg)
match http url https://(.*jpe)
match http url https://(.*png)
match http url https://(.*gif)
match http url https://(.*css)
match http url https://(.*js)
match http url https://(.*class)
match http url https://(.*jar)
match http url https://(.*cab)
match http url https://(.*txt)
match http url https://(.*ps)
match http url https://(.*vbs)
match http url https://(.*xsl)
match http url https://(.*xml)
match http url https://(.*pdf)
match http url https://(.*swf)
Attach the following parameter map to this class map:
parameter-map type optimization http PM-modifier
cache key-modifier http://$(1)
•CSCsy27609—When configuring logging level 251010 to any (nondefault) level, and then removing the command with the no logging message 251010 level number command, you may find that logging continues at the previous level even though the show logging message 251010 displays the default logging level. Workaround: Configure the default logging level using the logging message 251010 level 3 command instead of using the no logging message 251010 level number command.
•CSCsy34826—The following TCL PROBENOTICE scripted health monitoring probe fails to send an e-mail notification to a configured SMTP server when a real server fails the health probe.
probe scripted EMAILNOTIF
script PROBENOTICE_PROBE /index.html <SMTP_server_IP> user@your_company.com
Workaround: None.
•CSCsy75298—When using the ACE appliance Device Manager, if you attempt to edit the Resource Class field, Allocate Interface VLANs field, or Description field on the Primary Attributes page and then click Deploy Now, the configuration deployment can fail and the error "Error in saving to DB: null" will appear on the Device Manager GUI. This behavior typically occurs when a context on the Device Manager GUI is synchronized with the associated CLI copy. There are two ways that a context is synchronized in the ACE:
–Manual synchronization - You click the CLI Sync button after selecting a user context from the Config >Virtual Context screen.
–Automatic synchronization - You make configuration changes from the CLI. The Device Manager periodically checks for the CLI updates and performs synchronization if there are updates.
There is no issue in updating the other attributes on the Primary Attributes page; this issue is specific to the three attributes outlined above.
Workaround: When this problem occurs, perform a manual synchronization on the Admin context by selecting the Admin context from the Config >Virtual Contexts screen and clicking CLI Sync. After you perform this synchronization, you will be able to edit the Resource Class field, Allocate Interface VLANs field, or Description field on the Primary Attributes page. Note the following operating considerations regarding this issue:
–The context on the Device Manager GUI will again enter this error state upon the next Device Manager GUI and CLI synchronization. In this case, the workaround described above is required whenever you attempt to update the Resource Class field, Allocate Interface VLANs field, or Description field on the Primary Attributes page.
–Only a user with the Admin role in the Admin context can apply this workaround since these three fields are configured on the Admin context for all the user contexts.
Software Version A3(2.2) Command Changes
Table 9 lists the commands and options that have been changed in software version A3(2.2).
Table 9 CLI Commands Changed in Version A3(2.2)
|
Mode
|
Command and Syntax
|
Description
|
Exec |
crypto crlparams crl_name cacert ca_cert_filename no crypto crlparams crl_name |
Configures signature verification on a CRL to determine that it is from a trusted certificate authority (CA). The arguments are as follows: •crl_name—Name of an existing CRL. •ca_cert_filename—Name of the CA certificate file used for signature verification. Use the no version of this command to remove signature verification from the CRL. |
Exec |
crypto delete crypto export crypto generate csr crypto generate key crypto import crypto verify |
The crypto commands are now disabled by default for the network-monitor role. |
Exec |
ft switchover |
The ft switchover command is now disabled by default for the network-monitor role. |
Exec |
show crypto cdp-errors |
The new cdp-errors keyword displays the statistics for discrepancies in CRL Distribution Points (CDPs) for the certificates on the ACE; not context specific. A CDP indicates the location of the CRL in the form of a URL. CDP parsing in the certificate occurs only when best effort CRL is in use. The output for this command includes the following fields: •Incomplete—Number of times that the CDPs are missing information required to download the CRLs, for example, host, file name or base information. •Unrecognized Transports—Number of times that the ACE does not recognize or support the transport mechanism in the CDP for the CRL. •Malformed—Number of times that the CDPs are malformed with erroneous information, for example, specifying an incorrect attribute or base information. This counter also includes CDPs with URL lengths exceeding the ACE limit of 255 characters; a truncated URL could point to the wrong CRL. •Missing From Cert—Number of times that the CDPs are missing from the certificate. |
Exec |
show crypto crl name detail |
The new detail keyword displays additional statistics for CRL download failures. For information on the fields for this command, see the "Displaying Detailed CRL-Downloading Statistics" section. |
Exec |
show conn [{address ip_address1 [ip_address2] netmask mask [detail]}
| count | detail | {port number1 [number2] [detail]} | {protocol {tcp | udp} [detail]} | {rserver rs_name [port_number serverfarm sfarm_name1 | serverfarm sfarm_name1] [detail]} | {serverfarm sfarm_name2 [detail]}] |
The new detail option has been added for a specified address, port, protocol, real server, or server farm. This option displays additional information for the connection including idle time, elapsed time, byte count, packet count, and, if applicable, the state of the connection in the reuse pool. |
Exec |
show ft config-error [context_name] |
In a redundant configuration, the new config-error keyword displays the commands that fail on the standby ACE during bulk synchronization. If all commands succeed on the standby ACE, the command displays the following message:
No bulk config apply errors
In the Admin context, the optional context_name argument is the name of a user context. If you do not enter the argument, the command uses the Admin context. In a user context, this argument is not available. |
Exec |
show stats crypto client | server |
The SSL CRL download failed field has been removed. |
Exec |
show stats http |
The output for the show stats http command has been modified. The TCP fin/rst msgs sent, Bounced fin/rst msgs sent, and SSL fin/rst msgs sent fields have been divided into the following new fields in the show stats http command output: •TCP fin msgs sent •TCP rst msgs sent •Bounced fin msgs sent •Bounced rst msgs sent •SSL fin msgs sent •SSL rst msgs sent |
Exec |
show sticky cookie-insert group sticky_group_name |
The new show sticky cookie-insert command displays information that correlates the inserted cookie, the sticky entry, and the final destination for the cookie insert configuration.The output for this command includes the following fields: •Cookie—Cookie-insert hash string for each real server in the associated server farm. •HashKey—64-bit hash value associated with the cookie. •rserver-instance—String containing the server-farm name, real-server name, and real-server port in the following format: server_farm_name/real_server_name:rserver_port |
Exec |
show sticky database static http-cookie cookie_value |
If you enable cookie insertion by using the cookie insert command in sticky-cookie configuration mode, the show sticky database static http-cookie command no longer displays the hash key. |
Exec |
show tech-support |
Per CSCsx33405, this command no longer displays the following: •All show acl-merge acls vlan command output •All show acl-merge merge-list vlan number out command output It also now displays a maximum of four VLANs. |
Class map |
[line_number] match virtual-address address {[mask] | any | {tcp | udp {any | eq port_number | range port1 port2}} | protocol_number} |
Previously, the ACE allowed you to configure a class-map VIP address that overlaps with an ACE interface IP address. Per CSCsv32098, the ACE no longer allows this configuration and displays the following warning:
Error: Entered VIP address is not the first address in
the VIP range
|
Parameter map connection |
set tcp buffer-share |
Per CSCsw88316, you can now configure this command for UDP connections. Previously, buffer share was configurable only for TCP connections. |
Role |
rule number {permit | deny} {create | modify | debug | monitor} [feature changeto-command | exec-commands] |
Previously, you could not configure user-defined roles to use the changeto command. Per CSCsq98981, the new changeto-command option allows a user-defined role to use the changeto command. Also, users retain their privileges when accessing different contexts. By default, this command is disabled for user-defined roles. Previously, the ACE enabled Exec mode commands for user-defined roles. Per CSCsr00851, the new exec-commands option allows a user-defined role to use the capture, clear, debug, delete, gunzip, mkdir, move, rmdir, set, setup, system, tac-pac, untar, write, and undebug commands. By default, these commands are now disabled for user-defined roles. |
Server farm |
predictor hash cookie secondary cookie_name |
Per CSCsr30433, the new secondary keyword selects the server by using the hash value based on the specified name in the cookie name in the URL query string, not the cookie header. For the cookie_name argument, enter a cookie name as an unquoted text string with no spaces and a maximum of 64 alphanumeric characters. For example, consider the following request: GET /index.html?TEST=test123
Cookie: TEST=456 If you configure the predictor hash cookie secondary TEST command, it selects the server using the hash value based on test123. If you configure the predictor hash cookie TEST command, it selects the server using the hash value based on test456. This option allows the ACE to correctly load balance in cases when the query string identifies the actual resource, instead of the URL. In the following example, if the ACE hashes on the URL, it would load balance on the same real server: http://youtube.com/watch?v=C16mk4OfcuM
http://youtube.com/watch?v=cJ3jPzs2NLk |
Serverfarm host real server |
backup-rserver name [port] |
Per CSCsr56251, the ACE now supports cyclic backup of real servers in a server farm. For example, the following configuration can be used under a server farm:
|
Serverfarm host real server |
cookie-string text |
Per CSCsx63665, you can now enter a cookie string value of the real server which is to be used for HTTP cookie insertion when establishing a sticky connection. One cookie string can be configured for each real server. Valid entries are text strings with a maximum of 32 alphanumeric characters. You can include spaces and special characters in a cookie string value, provided that the spaces and special characters are included in double quotes (for example, "test cookie string"). If you use quotes in a cookie string, the specified cookie-string value appears in double quotes in the running-configuration file. Use cookie insertion when you want to use a session cookie for persistence if the server is not currently setting the appropriate cookie. With this feature enabled, the ACE inserts the cookie in the Set-Cookie header of the response from the server to the client. Note The inserted cookie string value also appears in the output of the show sticky database static command. Note the following when configuring a cookie string value: •If you do not configure a cookie string value, when you enable cookie insertion for a sticky group, the ACE generates the cookie string for each real server. The ACE-generated cookie string appears as "Rxxxxxxx" (for example, R2148819051). •If you configure a cookie string value, the user-defined cookie string will have a higher priority and the ACE automatically uses the user-defined cookie string for cookie insertion for a sticky group. •If you configure a cookie string value, and you choose to remove the user-defined cookie string from a real server, the ACE generates the cookie string for the associated real server. Note Ensure that there are no duplicate strings configured for real servers. If there are duplicate cookie strings, the old entry will be removed and sticky database will use the latest configured cookie string for the real server. |
Displaying Detailed CRL-Downloading Statistics
To display the detailed statistics for the downloading of a CRL including failure counters, use the show crypto crl name detail command. Table 10 describes the fields displayed by this 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 Download Attempts |
Number of times the ACE attempted to download the CRL. |
Failed Download Attempts |
Numbers of times that the ACE failed to download the CRL. |
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 load |
Number of times that the ACE could not load the CRL because of the 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 download |
Number of times that the CRL was found ineligible for downloading 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. |
Software Version A3(2.1) Resolved Caveats, Open Caveats, and Command Changes
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats in software version A3(2.1):
•Software Version A3(2.1) Resolved Caveats
•Software Version A3(2.1) Open Caveats
•Software Version A3(2.1) Command Changes
Software Version A3(2.1) Resolved Caveats
The following resolved caveats apply to ACE software version A3(2.1).
•CSCse85906—In a redundant configuration, persistent connections established through an ACE context may become unresponsive after a switchover occurs. Workaround: None.
•CSCso93424—In some cases, when you have a configuration that includes a policy map for both server load-balancing and application inspection, you may encounter a configuration rollback issue if you create two checkpoints where one checkpoint has the policy map associated with a VLAN (checkpoint 1) and the other leaves the policy map unused (checkpoint 2). In some cases, when you perform a rollback from checkpoint 1 to 2, the application inspection policy on the VLAN is not removed and packets continue to be inspected. Workaround: Avoid creating a checkpoint that includes unused policy maps.
•CSCsq20736—In a redundant configuration, when you cause a switchover by using the ft switchover command, there is a brief period of time during which any configuration changes made on the active ACE will not be synchronized to the standby ACE. When the Active to Standby_Hot steady state is reached, the new configuration exists only on the active ACE and not on the standby ACE. Workaround: Do not make any configuration changes after you specify the ft switchover command. Be sure to wait until the FT group reaches the steady state of Active to Standby_Hot.
•CSCsq25310—In a redundant configuration, scripted probes using the vshell configuration command vsh_conf_cmd will fail on the standby ACE when you specify the no ft auto-sync running config command on the active ACE to disable the automatic synchronization of the running-configuration or the startup-configuration files before performing a configuration synchronization.
For example:
switch/Admin# show probe scrip1 detail
----------------------------------------------
port : 0 address : 0.0.0.0 addr type : -
interval : 10 pass intvl : 10 pass count : 2
fail count: 3 recv timeout: 10
script filename : NEW_VSH_SCRIPT
------------------ probe results ------------------
associations ip-address port porttype probes failed passed health
------------ ---------------+-----+--------+--------+--------+--------+------
10.2.0.101 0 -- 3 3 0 FAILED
No. Passed states : 0 No. Failed states : 1
No. Probes skipped : 0 Last status code : 30006
No. Out of Sockets : 0 No. Internal error: 0
Last disconnect err : Internal error: Script error >>Script error in standby ACE
Last probe time : Mon Aug 4 23:14:40 2008
Last fail time : Mon Aug 4 23:14:20 2008
Workaround: None.
•CSCsq38725—In some instances, you may find that the back-end connection SSL handshake fails. This behavior can occur when the size of the server's certificate is greater than 4K bytes. Workaround: Decrease the size of the server's certificate.
•CSCsq57703—When the ACE is configured for FTP inspection, if a client sends an EPRT command with the wrong syntax, the connection is reset by the ACE. When this behavior occurs, you will not see a 500 Error message because the request is not forwarded to the server. Workaround: None.
•CSCsq59069—If you enable the header modify per-request command without persistence rebalance, the ACE may fail to modify the server's response from the second request on even though there is a response action statement in the action list. Workaround: Ensure that persistence rebalance is enabled (the default behavior with the A3(1.0) release).
•CSCsq59495—If your configuration includes a SIP proxy in front of the ACE with a defined NAT policy to enforce UDP and TCP traffic that uses a different source NAT on the back end, the SIP call may drop the 200 OK HTTP status response code for the call hold invitation if the receiver initiates the call hold. Workaround: Avoid having the NAT policy enforce UDP and TCP using a different source NAT.
•CSCsq81190—With persistence rebalance disabled and the header modification on every HTTP request or response function enabled (the header modify per-request command), in some cases, with a load-balancing policy map configuration that includes a Layer 7 class map searching for "/index.html" and the default class map, the ACE may incorrectly modify the response based on the action list. Workaround: None.
•CSCsq91645—In a user-defined action list where one header has multiple matches, the defined action may not occur. For example, if you configure both the SSL URL rewrite location and the HTTP header rewrite for the location header in the response direction to change the path of the URL in the same action list, the SSL URL rewrite function may not occur.
host1/Admin(config-actlist-mod)# action-list type modify http a1 header rewrite
response Location header-value "(http://.*/)index.html" replace "%1home.html" ssl url
rewrite location ".*"
Workaround: Avoid having multiple matches in an action list for a single header. For the above example, you can combine two rewrite actions as follows:
host1/Admin(config-actlist-mod)# action-list type modify http d1 header rewrite
response Location header-value "http://(.*)/index.html" replace "https://(.*)
/home.html"
•CSCsq99661—In a configuration with both SIP application inspection and maximum forward field validation enabled, the ACE should deny any calls with a maximum forward value that is greater than or equal to 1000. In some cases, requests with a maximum forward value that is greater than or equal to 1000 are not dropped. Workaround: None.
•CSCsr02398—Instructing the ACE to compress packets using the deflate HTTP compression method may produce an error when using Internet Explorer. Workaround: None.
•CSCsr11991—When using application acceleration and optimization, with both cache forward and SSL configured, the ACE sends an asynchronous cache request to the server for every GET request. These messages should increment the real servers counter Connection Total field. In some cases, the counter is not incremented. Workaround: Clear the cache by removing and adding the cache forward function from the configuration. See the Cisco 4700 Series Application Control Engine Appliance Application Acceleration and Optimization Configuration Guide.
•CSCsr14725—The ACE allows you to uninstall a base license without first uninstalling the upgrade license if it is a demo license. Workaround: None.
•CSCsr22457—The TCP probe may fail if the real server sends a FIN after completing a 3-way handshake. When the ACE receives a FIN from a real server after completing a 3-way handshake and after the ACE closes the connection by sending a FIN or a RST, the probe is successful. However, if the ACE receives a FIN from a real server after completing a 3-way handshake but before the ACE closes the connection by sending a FIN or a RST, the probe is marked as failed by the ACE. Workaround: Do not configure or use special tools on the server side to send a FIN immediately after the initial 3-way handshake.
•CSCsr29126—No ACL merge list is produced on an access-group addition. This behavior can occur after an ACL download failure by removing the access group on an interface and adding a new access group within five seconds. Workaround: Wait for more than five seconds after deleting an access group from a VLAN interface, or delete the VLAN interface and reconfigure it.
•CSCsr32495—An invalid ACK handshake may move a Layer 7 TCP connection to the ESTABLISHED state. This behavior may be a result of the TCP three-way handshake not being RFC 793 compliant.
For example, a standard three-way handshake functions as follows:
1. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
2. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
3. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
However, with crafted packets, the following three-way handshake may occur, which results in the connection moving to the ESTABLISHED state:
1. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
2. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
3. ESTABLISHED --> <SEQ=101><ACK=300><CTL=ACK> --> ESTABLISHED
In this case, the final ACK handshake is not equal to SEQ+1
Workaround: None.
•CSCsr46695—The ACE may drop connections when you modify the configuration of an unassigned interface. Workaround: None.
•CSCsr49046—The ACE does not allow greater than 2K match source-address statements to be configured under a VIP. This restriction is a device limitation, and the 2K limit applies under all conditions. Workaround: None.
•CSCsr49050—When you are performing application acceleration and optimization, the ACE may reboot when configuration changes are made while HTTP compression traffic is running. Workaround: Do not execute configuration changes while traffic is passing through the ACE.
•CSCsr56562—You may find that the SSL process appears to be unresponsive on the ACE. You may observe this behavior when one or more of the following conditions occur:
–The ACE is using an expired certificate revocation list (CRL).
–The CRL on the CRL server is not updated.
–The SSL parameter map has been configured to reject a client certificate when the CRL in use has expired (the expired-crl reject command). Under this condition, the ACE may attempt to download the CRL for each client connection.
Workaround: Do not use an expired CRL; update the CRL with a new version. If the CRL is expired, do not configure the SSL parameter map to reject a client certificate when the CRL in use has expired. If that flag is on, ensure that the CRL server contains a valid CRL.
To determine if a CRL is expired:
1. On the CRL server, specify the openssl command. For example:
openssl crl -in <crlname> -noout -text
2. Verify the Next Update time in the output. For example:
[root@localhost html]# openssl crl -in test.crl -noout -text
Certificate Revocation List (CRL):
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/ST=california/L=sanjose/O=cisco/OU=adbu/CN=test/emailAddress=sss
Last Update: Jun 10 14:49:39 2008 GMT
Next Update: Jul 10 14:49:39 2008 GMT
CRL extensions:...........
3. On the ACE, enter the show clock command and verify the time. If the show clock command output on the ACE displays a time that is greater than the Next Update time, then the CRL is expired. For example:
Fri Aug 1 02:13:28 ADT 2008.
In this example, the CRL has expired. The show clock command output of the ACE is greater than the Next Update time of the CRL.
•CSCsr67106—With packet capture enabled, large page transfers with end-to-end and back-end SSL connections may become unresponsive. Workaround: Disable the packet capture function for end-to-end and back-end SSL connections with large page transfers.
•CSCsr69631—When operating in a redundant configuration, you may find that TCP flows are disrupted after you perform an FT switchover by using the ft switchover command. This behavior may occur if normalization is disabled on the interface; in this case, connections replicated to the standby ACE are in an embryonic state. As a result, after performing an FT switchover, these connections will be deleted and the data transfer stalls. Workaround: Enable normalization on the VLAN interface.
•CSCsr80332—The real server in a server farm may remain in a MAX_LOAD state even after the least-loaded predictor is removed from the server farm. This behavior can occur when one of the following conditions occur:
–When you configure an SNMP least-loaded predictor probe in a server farm along with any other probe (for example, an HTTP probe; but it can be an SNMP probe as well), and both the SNMP predictor probe and the HTTP probe are in FAILED state. This behavior may be due to a real server being placed into a MAX_LOAD state in the server farm. Under this condition, if you remove the least-loaded predictor, the real server will be stuck in the MAX_LOAD state instead of reverting back to the PROBE_FAILED state.
For example:
predictor least-loaded probe SNMP
In this example, both the SNMP and HTTP probe are in a FAILED state and the real server (rs1) is in MAX_LOAD state, under which the least-loaded SNMP probe is unconfigured.
–When you configure an SNMP least-loaded predictor probe, FAIL-ON-ALL action, and any other probes in a server farm. If a real server in the server farm is in MAX_LOAD state due to an SNMP probe FAILURE, and any one of the other probes is also in FAILED state for that real server, under this condition if you remove least-loaded predictor then you may observe that the real-server is stuck in the MAX_LOAD state. For example:
predictor least-loaded probe SNMP
In this example, either (or both) the HTTP and RADIUS probes are in the FAILED state, along with the SNMP probe, and the real server (rs1) is in MAX_LOAD state, under which the least-loaded SNMP probe is unconfigured.
Workaround: Perform one of the following actions to resolve this issue:
–If the real-server is stuck in the MAX_LOAD state in a server farm, take the real server out of service by entering the no inservice command, and then place it back in service by entering the inservice command. This action can also be performed at the real server level.
–Before removing the least-loaded predictor from the server farm, ensure that no other probes are in the FAILED state for real servers that are in the MAX_LOAD state.
•CSCsr81801—When you create a user with the role that has the ability to permit, create, and place a real server in service to activate or suspend real servers, when this user logs in to the Device Manager GUI, they are able to access the Real Servers table (Config > Operations > Real Servers) but are unable to use the Activate and Suspend buttons to activate or suspend a real server. This behavior occurs only for a user with a role that includes a rule as permit/create/real-inservice. Workaround: Add the following rule for the newly created user: permit/modify/serverfarm. This user will be able to activate and suspend the real servers from the Config > Operations > Real Server page.
•CSCsr82364—You are using the Device Manager GUI and the specification of a nonexistent VLAN in the snmp-server trap-source vlan CLI command causes the Device Manager to fail to synchronize the CLI with the Device Manager GUI for a virtual context. Subsequently, when you attempt to login to the Device Manager GUI, you will see a blank page. This behavior typically occurs when you specify a VLAN using the snmp-server trap-source vlan CLI command and then delete the VLAN from the ACE. This issue can also be encountered when you specify the FT VLAN interface as an SNMP server trap source. Workaround: Recreate the VLAN interface from the ACE CLI and then synchronize the virtual context from the Device Manager GUI. Do not specify the FT VLAN interface as the SNMP server trap source.
•CSCsr87736—When you configure a backup server farm with sticky for a virtual server in the Device Manager GUI (Config > Virtual Contexts > Load Balancing > Virtual Servers) you may find that the CLI is not synchronized to configure the backup server farm. If you edit this virtual server in the Device Manager GUI, you will notice that the backup server farm is not set.
Workaround: Add a backup server farm from the Sticky Groups table as follows:
a. Select Config > Virtual Contexts > context > Load Balancing > Stickiness. The Sticky Groups table appears.
b. Select an existing sticky group you want to modify, then click Edit.
c. Add the backup server farm to this group as a sticky group attribute.
d. Click Deploy Now.
Alternatively, you can:
a. Create a new sticky group with primary and backup server farms from the Sticky Groups table (Config > Virtual Contexts > context > Load Balancing > Stickiness).
b. Use this sticky group in a virtual server.
•CSCsr89280—When performing SIP application inspection, you may find that the ACE drops SIP packets with the Diversion header option in the SIP message header. In this case, the call will be dropped. You can observe application protocol inspections errors as show below:
host1/Admin# show np 1 me-stats -sappinspect`
AppInspect Statistics: (Current)
DROP: Global proxy state seq mismatch: 4572 0
DROP: Conn entry seq mismatch errors: 27 0
DROP: Other conn entry seq mismatch erro 2 0
NAF requests (all) sent: 557568 0
CONN RST: Protocol inspection errors: 93314 0
Total TCP connections processed: 26738 0
SIP: Packets Received: 93314 0
SIP: Drop - Misc: 93314 0
Workaround: None.
•CSCsr90184—You are using the Device Manager GUI and it fails with localhost resolve error. This behavior can occur when you configure a hostname that include the pound sign (#) character, such as "ace4710#2." A pound sign in the hostname causes the Device Manager to ignore all characters following the "#" character, resulting in a failure of the hostname resolution for the local hosts name. Workaround: Do not configure a hostname with the pound sign (#) character.
Note We also recommend that you do not include the underscore (_) character in a hostname.
•CSCsu00262—In some instances, after you configure more than 640 action lists, the ACE may reboot if you enter the show action-list command, use the question mark (?) to get CLI command help, or press the Tab key to complete the CLI command. Workaround: None.
•CSCsu03079—You may encounter buffer leaks on the ACE when you make repeated configuration changes on the ACE while running HTTP traffic. This behavior is typically seen with enhanced HTTP inspection on an HTTP traffic configuration that enables the monitoring of Layer 3 and Layer 4 traffic. The buffer leaks occur when you make configuration changes to the associated HTTP application protocol inspection policy map. Workaround: None.
•CSCsu10546—Port Address Translation (PAT) is a form of Network Address Translation (NAT) that allows multiple hosts in a private network to access a public network using a single, public IP address. This is accomplished by rewriting layer 4 information, specifically TCP and UDP source port numbers and checksums, as packets from the private network traverse a network device that is performing PAT. PAT is configured by network administrators and performed by network devices such as firewalls and routers in situations where public IP addresses are limited.
After the initial multi-vendor DNS advisory was published on July 8th, 2008 it was discovered that in some cases the fixes to DNS implementations to use random source ports when sending DNS queries could be negated when such queries traverse PAT devices. The reason for this is that in these cases the network device performing PAT uses a predictable source port allocation policy, such as incremental allocation, when performing the layer 4 rewrite operation that is necessary for PAT. Under this scenario, the fixes made by DNS vendors can be greatly diminished because, while DNS queries seen on the inside network have random source port numbers, the same queries have potentially predictable source port numbers when they leave the private network, depending on the type of traffic that transits through the device.
Several Cisco products are affected by this issue, and if DNS servers are deployed behind one of these affected products operating in PAT mode then the DNS infrastructure may still be at risk even if source port randomization updates have been applied to the DNS servers.
This bug is for Cisco ACE software, which while does not use an incremental source port allocation policy, it uses a hash algorithm that may make predictable the source port for a specific destination port.
Traditional NAT, that is, allocating one public IP address for each private IP address, is not affected by this problem because, unlike PAT, NAT only rewrites layer 3 information and does not modify layer 4 header information of packets traversing the NAT device.
For more information about the DNS vulnerability mentioned above please refer to the multi-vendor advisory at:
http://www.kb.cert.org/vuls/id/800113
or at the Cisco-specific advisory at:
http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml
•CSCsu27331—When operating in a redundant configuration, the failover and subsequent recovery using FT interface tracking may fail to preserve sessions that relate to the failed interface. When the link is lost on an interface, a failover occurs as expected and existing sessions operate as expected on the newly active ACE. However, on the ACE that transitioned to the standby state, all connections that relate to the interface that lost the link are removed from the connection table. This behavior can make a failover recovery impact client sessions. When the link is restored, the interface comes up and the ACE becomes active once again. However, all client connections that use this interface need to reconnect. Workaround: None.
•CSCsu35289—When TCP server reuse is configured on the ACE, you may find that traffic does not reuse an existing server connection if you have specified a maximum transmission unit (MTU) block size value that is greater than 1460 bytes for either a client or server VLAN interface. Workaround: If you intend to use TCP server reuse, use the default MTU block size of 1460 bytes for a VLAN interface.
•CSCsu35850—The HM process in an ACE terminates on receiving Signal 11, Segmentation Fault. This issue may be encountered when codenomicon tests are run in a configuration that contains multiple contexts that have different types of probes. This behavior is seen frequently with DNS, HTTP, and HTTPS probes with the respective codenomicon tests running. Workaround: None.
•CSCsu36078—Secure Shell (SSH) remote access connections to an ACE may fail when you are using a TACACS+ server for authentication. Workaround: Telnet first to the ACE to establish a user profile, and then use the SSH protocol.
•CSCsu46534—The ACE may reload when you attempt to enter the show parameter-map command to view the parameter map list. This behavior can occur when there are a large number of parameter maps configured on the ACE. Workaround: None.
•CSCsu46894—The ACE may reload when you attempt to use the Tab key with the show parameter-map command to complete the command. This behavior may occur when there are a large number of parameter maps configured on the ACE. Workaround: Specify the name of an existing parameter map when you enter the show parameter-map command. You can find the existing parameter map names from the show running-configuration command.
•CSCsu51232—The ACE may become unresponsive when using a configuration that includes approximately 3100 real servers in a server farm and more than 100 SSL probes configured in the server farm. This behavior may be due to an internal race condition that occurs when the ACE downloads the configuration and performs connection setup for the configured probes. Workaround: None.
•CSCsu53808—When you are operating in a redundant configuration, when the ACE attempts to recover from an active/active state and the FT VLAN is down, the ACE may fail to send gratuitous ARP packets for both its VIP and alias IP addresses to update the upstream neighbor. Workaround: None.
•CSCsu54793—Secure Shell (SSH) remote access connections to an ACE may fail when you are using a TACACS+ server for authentication. Workaround: Access the ACE appliance Device Manager GUI first to establish a user profile, and then use the SSH protocol. See the Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Configuration Guide.
•CSCsu68777—You may find that SSL traffic hangs with fragmentation configured and an MTU block size value that is greater than 1460 bytes configured for a VLAN interface. Workaround: Use the default MTU block size of 1460 bytes without fragmentation configured for a VLAN interface.
•CSCsu73723—The ACE may become unresponsive when you use HTTP compression and the ACE is operating under a stress condition (operating at a maximum bandwidth capacity). Workaround: Disable HTTP compression in your Later 7 policy map, or configure rate limiting to limit the connection rate and the bandwidth rate of a real server in a server farm.
•CSCsu79094—Reapplying a service policy with a specific VLAN interface or globally with all VLAN interfaces may result in a loss of connectivity to a VIP. Workaround: Remove the Layer 3 and Layer 4 class map that defines the VIP from the Layer 3 and Layer 4 multi-match policy map, and then readd the class map to the policy map.
•CSCsu79729—After installing a bundle license (see the "Available ACE Licenses" section), if you upgrade the ACE with one or more individual software licenses, you may find that an additional upgrade using the bundle upgrade license will fail and may cause the original bundle license to become uninstallable. Workaround: If you installed the individual license(s) in addition to the bundle license and you require to upgrade to the next bundle license, uninstall the individual license(s) first before you upgrade the ACE to the next bundle license. For information on uninstalling a software license, see Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
•CSCsu85282—The ACE may reboot or become unresponsive with more than 1K configured source-address match statements. This behavior may occur when you attempt to apply more class maps to a Layer 7 SLB policy map. Workaround: Enter the reload command in Exec mode to reboot the ACE.
•CSCsu85583—In a redundant configuration, when a certificate or key pair that is part of an active chaingroup or authentication group is deleted on the primary ACE without first being removed from the chaingroup or authentication group, it is also deleted on the secondary ACE. Workaround: Remove the certificate or key pair from the chaingroup or authentication group before deleting it.
•CSCsu96861—The Bandwidth Out of Rotation field in the show rserver command output may be incorrect for the configured real servers. In addition, you may find that bandwidth rate limiting fails to properly limit the real-time bandwidth. This behavior may occur with the following conditions:
–The bandwidth rate limit is applied on a real server or a real server in a server farm.
–The server farm has one of the hash-based predictors applied.
Workaround: None.
•CSCsv02005—SSL clients on a dialup link may receive only partial page downloads. This behavior can occur when the ACE is configured for both front and back-end SSL, and the client link is a slow or lossy dialup link. Workaround: None.
•CSCsv02541—The ACE may reboot while performing HTTP compression. Workaround: Disable HTTP compression in the Layer 7 SLB policy map.
•CSCsv13595—The ACE may appear to be unresponsive, and certain configuration and show commands are not properly executed by the ACE. This behavior can occur when you specify a small maximum connections limit, with min-conns equal to max-conns, and a high volume of traffic is sent which results in the servers transitioning in and out of the specified maximum connections limit numerous times per second. In this case, the ACE becomes unresponsive due to the frequent internal updates. Workaround: None.
•CSCsv18396—SIP probes may fail when used with the Cisco Session Border Controller (SBC). The Cisco SBC responds with a SIP "482 Loop Detected" because the same Call-Id and From-Tag are used in all probe requests. Workaround: None.
•CSCsv22516—If the HTTP compression performance license or the application acceleration feature pack license is installed and then uninstalled, the corresponding rate limiting may become erroneous. The show resource usage command output also displays the erroneous values. This behavior can occur when a nondefault resource class is configured. Workaround: None.
•CSCsv24197—You may find that the server load-balancing function becomes unresponsive in the ACE when you remove a real server while traffic is running This behavior can occur under the following conditions:
–A real server is removed using either the no rserver or no inservice command under the server farm.
–The real server had pending connections.
–The corresponding real server had a condition (maxconn or rate limit) that gets reset due to the connection close on the associated real server. This connection close arrives after the real server has been removed.
Workaround: Avoid making this configuration change while the traffic is running.
Software Version A3(2.1) Open Caveats
The following open caveats apply to ACE software version A3(2.1).
•CSCsg95099—When you configure SNMP notification using the ACE appliance Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. This information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > CLI Sync or CLI Sync All.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCso29529—A user with the configured role of Network-Monitor is allowed to delete other user directories on the ACE. Workaround: Do not configure a user with the Network-Monitor role. See the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsr23197, CSCsq43870—When operating in a redundant configuration, if you perform a reload of the higher priority active ACE in an FT group setup (ACE-1) and the appliance goes back online, if ACE-1 does not receive a heartbeat from the standby ACE-2 peer, ACE-1 assumes that the peer is down and immediately moves to the ACTIVE state. Later, when ACE-1 does receives a heartbeat from the ACE-2 peer, ACE-1 sends its configuration to the ACE-2 peer which now has the higher priority.
Any applied configuration changes that were made to the ACE-2 peer with the lower priority during the time when the higher priority ACE-1 was reloading will be lost once ACE-1 becomes active. In addition, the connections sustained by the ACE-2 peer will also be flushed.
To avoid this behavior, the A3(1.0) software release has added the carrier-delay command to the interface configuration mode to add a configurable transition delay at the physical port level for the FT VLAN. When you configure a carrier-delay transition time for a physical Ethernet port, the active ACE that is proceeding from a reload does not change to the ACTIVE state for the duration of the specified carrier-delay timer. This configurable transition time provides a window for the ACE-2 peer to sense that the other peer has returned from a reload state. At that point, the ACE-2 peer can send a heartbeat to ACE-1. The use of the carrier-delay transition time can provide ACE-1 with sufficient time to return from the reload and properly move into the INIT state, the STANDBY_CONFIG state, the STANDBY_BULK state, and finally to the ACTIVE state. As a result, all configuration changes performed to the ACE-2 peer during the reload period are properly synchronized to ACE-1.
If you downgrade from software version A3(1.0) to A1(7a) or A1(7b), those earlier software releases do not support the use of the carrier-delay feature.
In addition, if you download to A1(8.0) or A1(8.0a), even though the carrier-delay command is a configurable selection, the ACE that is proceeding from a reload moves directly into the ACTIVE state. If the reloaded ACE-1 happens to be of a higher priority, all configuration changes made to the ACE-2 peer during the reload sequence of ACE-1 will be lost once ACE-1 becomes active.
Workaround: If you intend to downgrade from software version A3(1.0) to the A1(8.0) or A1(8.0a) software release, first save the current running-config file on the active ACE before you perform the software downgrade procedure on the active ACE.
For downgrade instructions, see the "Downgrading Your ACE Software in a Redundant Configuration" section.
•CSCsr67556—When you perform a checkpoint rollback, you may find that an access-group configuration is lost during the rollback. This behavior can occur if during the rollback all of the lines associated with an access-list are removed from the configuration, and then any associated access-group configuration that refer to the access-list is also removed. If the access-group configuration was also part of the configuration in which the rollback was being made to, then this access-group configuration will not be reconfigured. This issue applies to both globally configured access-groups as well as access-groups applied to VLAN subconfigurations. Workaround: To prevent the issue, use access-list remarks. These remarks should be present and identical in the current running-configuration and in the configuration to which you will be rolling back.
For example:
access-list one remark workaround
access-list one ex permit udp any any
access-list one ex permit icmp any any
access-list one remark workaround
access-list one ex permit ip any any
Another way to prevent this issue is to fully remove the access-list from the running-configuration file before you perform the checkpoint rollback. A manual configuration of the lost access-group will resolve it.
Checkpoint rollback will display the configuration that the system was unable to rollback to, as shown below:
switch/test# check roll test2B
---------------------------------------------------------------------
-- This operation will rollback the system's running-config to the --
-- checkpoint's configuration. This can take sometime depending on --
-- the amount of diff between the two configurations. --
---------------------------------------------------------------------
Do you wish to proceed? (y/n) [n] y
Config rollback in progress...failed.
Below diff could not be applied to running-config.
In the above example, the access-group input HTTP command is the command that the ACE could not apply. Manual rollback is then necessary for this command.
Additionally, the output of the show acl-merge merged vlan command would display the message: "% Interface or access-list/service-policy not found."
•CSCsv66682—User requests that hit a static sticky entry may be dropped. This behavior can occur for a static sticky entry that is configured for the current sticky group and the sticky group is not using the cookie insert function. In this case, the real server associated with the static sticky entry (including the backup server if one is configured) is placed out of service, and when a user sends a request that hits the sticky entry, the request is dropped. Workaround: None.
•CSCsv95366—When you use the ACE appliance Device Manager GUI, in some instances after you login to the Device Manager you may encounter a blank page. The issue occurs after upgrading to the A3(x) release. Workaround: Perform one of the following workarounds:
–Enter the reload command in Exec mode to reboot the ACE.
–Upgrade to software version A3(2.2) or higher.
Software Version A3(2.1) Command Changes
Table 11 lists the commands and options that have changed in software version A3(2.1).
Table 11 CLI Commands Changed in Version A3(2.1)
|
Mode
|
Command and Syntax
|
Description
|
Exec |
show service-policy [policy_name [class-map class_name]] [detail | summary] |
Added the optional class-map class_name and summary keywords to this existing command. You can now specify summary statistics for server load-balancing policies. In addition, you can specify detailed or summary statistics for a particular policy with all its associated class maps or a particular class map associated with a particular policy. The output of the summary option in tabular format includes the following fields: •Service-policy—Unique identifier of the policy map. •Class—Name of the class map associated with the policy map. •VIP—Virtual IP address specified in the class map. •Protocol—Protocol specified in the class map. •Port—Port specified in the class map. •VLAN—VLAN ID of the interface to which the policy map has been applied. •State—Operational state of the VIP. Possible states are: IN-SRVC (in service) and OUT-SRVC (out of service). •Curr Conns—Number of active connections to the VIP. •Hit Count—Total number of requests for the VIP. •Dropped Conns—Number of requests for the VIP that were dropped. |
Exec |
show stats crypto [client | server] [alert | authentication | cipher | termination] |
With the A3(2.1) release, you can now choose to display a specific subset of the total TLS and SSL client or server statistics The keywords are as follows: •alert—Display back-end SSL alert statistics. •authentication—Display back-end SSL authentication statistics. •cipher—Display back-end SSL cipher statistics. •termination—Display back-end SSL termination statistics. You can still enter the show stats crypto client or show stats crypto server command to display the complete TLS and SSL client or server statistics for the current context. |
Exec |
clear stats crypto [client | server] [alert | authentication | cipher | termination] |
With the A3(2.1) release, you can now choose to clear a specific subset of the total TLS and SSL client or server statistics The keywords are as follows: •alert—Clear back-end SSL alert statistics. •authentication—Clear back-end SSL authentication statistics. •cipher—Clear back-end SSL cipher statistics. •termination—Clear back-end SSL termination statistics. You can still enter the clear stats crypto client or clear stats crypto server command to clear the complete TLS and SSL client or server statistics for the current context. |
Configuration |
snmp-server trap-source vlan number |
The ACE now restricts you from selecting the VLAN number of the FT VLAN interface that has been specified between redundant ACE appliances as the trap source address contained in the SNMP v1 trap PDU. |
Software Version A3(2.0) Open Caveats
The following open caveat applies to software version A3(2.0):
•CSCsu79729—After installing a bundle license (see the "Available ACE Licenses" section), if you upgrade the ACE with one or more individual software licenses, you may find that an additional upgrade using the bundle upgrade license will fail and may cause the original bundle license to become uninstallable. Workaround: If you installed the individual license(s) in addition to the bundle license and you require to upgrade to the next bundle license, uninstall the individual license(s) first before you upgrade the ACE to the next bundle license. For information on uninstalling a software license, see Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
The remaining open caveats for software version A3(2.0) are the same as those for software version A3(1.0). For details, see the "Software Version A3(1.0) Resolved and Open Caveats" section.
Software Version A3(1.0) Resolved and Open Caveats
The following sections contain the resolved and open caveats in software version A3(1.0):
•Software Version A3(1.0) Resolved Caveats
•Software Version A3(1.0) Open Caveats
Note This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev3.
Software Version A3(1.0) Resolved Caveats
The following resolved caveats apply to ACE software version A3(1.0).
•CSCsh95585—When multiple virtual servers (class maps) are using the same IP address with different ports and the VIP must be pingable when it is active, you must configure the loadbalance vip icmp-reply active command for all virtual servers that share the same VIP. If you have multiple class maps with the same IP address and configure the loadbalance vip icmp-reply active command only for some of them, the ACE may not respond at all, even if the virtual servers that are configured with the loadbalance vip icmp-reply active command are alive. Workaround: All virtual servers that use the same IP address must have the loadbalance vip icmp-reply active command configured.
•CSCsh96086—The Device Manager GUI fails to add real servers to custom domains on the ACE appliance. In this case, a real server that you create in a custom domain in the Device Manager appears in the default-domain on the ACE appliance. This behavior occurs because the real server is deployed to the CLI using the Admin credentials and is created in the default-domain only.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Admin > Role-Based Access Control > Domains > Add.
2. Create a domain.
3. In the Domain Object subtable, add a real server.
4. Select Admin > Role-Based Access Control > Roles > Add.
5. Create a new role.
6. In the Rule subtable, add entries that grant Permit permission for Create, Debug, Modify, and Monitor operations for the real server.
7. Select Admin > Role-Based Access Control > Users > Add.
8. Add a user, assigning the role and domain created in Steps 2 and 5.
9. Log into the Device Manager as the new user.
10. Select Config > Virtual Contexts > Load Balancing > Real Servers > Add.
11. Add a real server.
12. Using the CLI, verify that the real server is created on the ACE appliance. The real server is created on the ACE appliance but is added to default-domain instead of the user domain.
Workarounds:
–Using the CLI, add objects to a user-defined domain.
–Using the Device Manager, select the affected context (Config > Virtual Contexts), and click CLI Sync.
•CSCsi24066, CSCso18391—When you perform a checkpoint rollback and enter the no nat dynamic n vlan nnn CLI command, the ACE displays the following messages:
Generating configuration....
Errors while applying diff, please see log below.
policy-map multi-match xxxxx
no nat dynamic 1 vlan 150
Error: Called API timed out
This behavior appears to be related to larger configurations with many regular expressions (regexes). Workaround: Enter the no nat dynamic command before you perform the rollback operation.
•CSCsj68643—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 accessing the ACE context through XML. Workaround: None.
•CSCsl09286—When you use the ACE appliance Device Manager GUI to configure an HTTP cookie sticky connection for a sticky group and you enable cookie insertion, the Device Manager does not support the configuration of the client's browser to expire a cookie when the session ends. The browser-expire field is missing as a sticky group attribute.
You can enable cookie insertion in the following Device Manager screens:
–Config > Virtual Contexts > Load Balancing > Stickiness > Add or Edit
–Config > Virtual Contexts > Load Balancing > Virtual Servers > L7 Load-Balancing
–Config > Virtual Contexts > Load Balancing > Virtual Servers > Default L7 Load-Balancing Action
Workaround: To allow a browser to expire the cookie when the session ends, use the optional browser-expire keyword of the cookie insert CLI command in sticky-cookie configuration mode. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl13788, CSCsm60957—You are running the ACE appliance Device Manager GUI in the Internet Explorer 6.0 web browser and you attempt to use the Device Manager to add a new ACL to the ACLs table (Config > Virtual Contexts > context > Network > VLAN Interface). The "error on this page" message appears at the bottom of the Internet Explorer 6.0 web browser and the ACL table fails to appear in the Device Manager GUI.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > context > Network > VLAN Interface. The VLAN Interface table appears.
2. Add a new VLAN or select an existing VLAN.
3. Select the VLAN interface that you want to associate with an ACL, and then select the Access Group tab. The Access Group table appears.
4. Click Add to associate a new ACL with the selected VLAN interface. The Access Group configuration screen appears.
5. Click the + icon to the left of the ACL Name field to add a new ACL into the ACL table. The "error on this page" message appears at the bottom of the Internet Explorer 6.0 web browser and the ACL table fails to appears in the Device Manager GUI.
Workaround: Use the Firefox 2.0 web browser instead of the Internet Explorer 6.0 web browser to run the Device Manager GUI, and add a new ACL from the Access Group tab as described in the above procedure.
If you want to use the Internet Explorer 6.0 web browser, perform the following procedure:
1. Select Config > Virtual Contexts > context > Security > ACLs and add a new ACL from the ACL configuration screen.
2. Select Config > Virtual Contexts > context > Network > VLAN Interface. The VLAN Interface table appears.
3. Select the VLAN interface that you want to associate with an ACL, and then select the Access Group tab. The Access Group table appears.
4. Click Add to associate a new ACL with the selected VLAN interface. The Access Group configuration screen appears.
5. Select the ACL entry added in Step 1 from the drop-down list.
6. Continue with the remainder of the configuration.
•CSCsl74755—ACE sockets may become depleted when you repeatedly (approximately 250 attempts) access the ACE using SSH. For example, entering the ssh admin@192.168.1.123 sh ver command may cause the ACE to generate the following message to the client:
Received disconnect from 192.168.1.123: 2: Could not create socket pairs: Too many
open files in system.
In some cases, this condition generates the following message on the ACE console:
socket: Limiting socket usage, no more sockets, Max allowed is 512 and current_usage
is 512
Workaround: Avoid excessive SSH logins. After the condition occurs, you must reboot the ACE to clear the resource depletion. No other workaround is currently available.
•CSCsm43859, CSCso32175—If you enable the logging of syslog messages during console sessions and you set the severity level to 6 (Information messages) or 7 (Debug messages), this deletion may result in the generation of a large number of syslogs that can overload the syslogd as it attempts to process these messages. When this occurs, the ACE may appear to be unresponsive.
Workaround: If you must use logging of syslog messages during console sessions with a message severity level of 6 or 7, perform one of the following actions:
–Enter the logging fastpath command to enable the logging of connection setup and teardown messages at a faster rate (that is, at the connection rate).
–Enter the logging rate-limit command to limit the rate at which the ACE generates messages in the syslog.
•CSCsm85882—The ACE may not automatically send gratuitous ARP packets when you either reload the appliance or specify the shutdown and no shutdown command sequence to change the state of a physical Ethernet interface. This behavior may occur when you connect the ACE directly to a Catalyst 6500 series switch. However, when you connect the ACE to a Linux host or to traffic testing equipment, gratuitous ARP packets are received without problem. If you connect an ACE to a Catalyst 6500 series switch, your configuration on the switch may include the Spanning-Tree Protocol (STP). However, the ACE does not support STP. In this case, you may find that the Layer 2 convergence time is much longer than the physical port up time. During this period, any packet, including gratuitous ARP packets, will be dropped by the Catalyst 6500 series switch. Workaround: With A1(8.0), the carrier-delay command allows you to add a configurable delay at the physical port level to address this transition time, based on the variety of peers.
•CSCso00038—In some cases, when you attempt to log into an ACE context as a user other than admin, the ACE returns a message that login is temporarily unavailable and prevents login from occurring. This behavior can occurs regardless of the user's role. If the admin user is applied to the context, remote access can be gained only as the admin user.
For example:
login is temporarily unavailable as startup configuration is being applied; try after
some time ...
Workaround: Create a nonredundant admin context or disable running-config synchronization on the admin context.
•CSCso22472—When you use class maps of type http loadbalance match-any to select a server farm and some of these class maps are empty, the ACE may make an incorrect load-balancing (LB) decision. This incorrect LB decision causes unexpected LB results. For example:
class-map type http loadbalance match-any A
2 match source-address 192.168.1.1 255.255.255.255
class-map type http loadbalance match-any B <<< empty
2 match virtual-address 192.168.1.10 tcp eq telnet
policy-map type loadbalance first-match LB
Workaround: In the above configuration, you must add a dummy match statement under class map B. For example:
class-map type http loadbalance match-any B
2 match source-address 172.16.27.5 255.255.255.255
•CSCso25654—With the UDP probe interval set to 2 seconds, UDP probes take longer than expected to enter the failed state. Workaround: Use a time interval that is greater than or equal to 5 seconds for UDP probes.
•CSCso33364—When you use the ACE appliance Device Manager GUI to modify the port number of a virtual server that is associated with an application protocol inspection function (Config > Virtual Contexts > context > Load Balancing > Virtual Server), the Device Manager may display the following message:
Infringing CLI command: no 2 match virtual-address tcp eq with reason: Error: Cannot
delete this object as this is referenced by inspect action.
Workaround: Perform the following procedure in the Device Manager GUI to modify the port number of a virtual server:
1. Select Config > Virtual Contexts > context > Load Balancing > Virtual Server. The Virtual Servers table appears.
2. Click Edit to modify the existing virtual server.
3. Access the Advanced View properties.
4. If necessary, document the current application protocol inspection settings that you currently have enabled as the virtual server properties.
5. Disable application protocol inspection, then click Deploy Now.
6. Edit the virtual server properties in the Advanced View with the desired port number and reenable application protocol inspection.
7. Click Deploy Now to deploy the configuration on the ACE.
•CSCso53538—The ip name-server CLI commands are missing from the ip CLI commands. Workaround: None.
•CSCso58617—In some cases, a GigabitEthernet interface configured for full duplex mode may operate in half duplex. Workaround: None.
•CSCso63101—In some cases, when performing RTSP application inspection, the Windows Media Player may send a FIN message after receiving the RTSP/SDP reply for the Describe request. This behavior can be due to the Content-Length value in the RTSP/SDP reply to Describe request is not updated correctly by the ACE even though the real server IP to VIP address translation is performed correctly in the SDP body. The issue is specific to Windows Media Player. The Windows Media Player sends "a=control:rtsp://<url>/....." in the SDP which results in the ACE performing a application inspection fixup of the URL but not performing a fixup of the content length since it was treated as the part of control_base header. If the size of the VIP address and real server IP address is the same, the ACE will not encounter this issue since content-length update is not required. Workaround: None.
•CSCso63218—Some configuration CLI commands may partially or completely fail to synchronize to the standby ACE when one appliance is running either software version A1(7a) or A1(7b) and the other ACE is running software version A1(8.0) or greater. This behavior may exhibit itself during the software upgrade or downgrade procedure between the A1(7x) and A1(8.0) images.
On an upgrade where the active ACE is running version A1(7x) and the standby ACE is booted with the A1(8.0) image, the configuration and connection replication will be replicated in bulk from A1(7x) to A1(8.0). The issue is that there is a problem with incremental configuration synchronization. Certain commands have been identified to fail if they are incrementally synchronized from the active ACE running version A1(7x) to the standby ACE running version A1(8.0). The commands that fail in this manner can, but are not necessarily limited to, the following commands: access-list, action-list type optimization http, parameter-map type http, parameter-map type optimization, policy-map (of all types), and sticky ip-netmask.
Workaround: When you upgrade from A1(7x) to A1(8.0), before you run any configuration commands in a context, enter the no ft auto-sync running-config command in the context that is about to undergo changes. When the changes are complete, enter the ft auto-sync running-config command in that context.
We recommend that you immediately initiate a failover to the new ACE after the bulk configuration synchronization occurs and the FT group is in ACTIVE/STANDBY_HOT state. We do not recommend that you enter any new configuration command on the ACE that is running version A1(7x) in this configuration. After you initiate a failover to version A1(8.0), be sure to immediately upgrade the other ACE to A1(8.0) as well. See the "Upgrading Your ACE Software in a Redundant Configuration" section.
During a downgrade where the active ACE is running version A1(8.0) and the standby ACE is booted with version A1(7x), configuration synchronization is disabled. The configuration will not be synchronized from the active ACE running A1(8.0). The ACE that is running version A1(7x) will apply its startup-configuration upon bootup, at which time only the A1(7x) configurations will be recognized. Configuration synchronization is disabled between the active ACE running version A1(8.0) and the standby ACE running version A1(7x) because the A1(8.0) configurations relate to the new features in the A1(8.0) release and will not be understood by the ACE running the A1(7x) release. See the "Downgrading Your ACE Software in a Redundant Configuration" section.
•CSCso66799—If you configure the same IP address with different ports on multiple class maps and your application requires that the VIP is pingable when it is active, you must configure the loadbalance vip icmp-reply active command under all class maps that share that same VIP. If you have multiple rules with the same IP address and you configure the loadbalance vip icmp-reply active command only under some of the class maps in a policy map, the ACE may not respond at all even if the VIPs configured with the loadbalance vip icmp-reply active command are alive. Workaround: Configure the loadbalance vip icmp-reply active command under all class maps that have the same IP address in a policy map.
•CSCso73385—With inspect ftp configured on a policy map, the ACE resets the FTP connection of traffic that matches the policy after it sends an extended PASV (EPSV) command to the FTP server. Workaround: None.
•CSCso79559—When you use the ACE appliance Device Manager GUI to edit existing match conditions for an HTTP deep packet inspection class map using the Expert configuration option, the ACE appliance may display an error message indicating "line number already exists".
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > context > Expert > Class Map. The Class Map table appears.
2. Add a class map.
3. Select Layer 7 HTTP Deep Packet Inspection.
4. Select Match-any or Match-all.
5. Click Deploy Now.
6. Add a match condition.
7. Select type as Content.
8. Click Deploy Now.
9. Edit the same match condition.
10. Change the type to any of the following:
–Header-mime-type
–Port-misuse
–Request-method
–Transfer-encoding
–Url
–Url-length
The ACE appliance may return an error indicating "line number already exists" because the ACE appliance CLI does not contain the appropriate no form of the command to remove the existing match condition before adding the new match condition.
Workaround: Perform the following procedure in the Device Manager GUI to modify the HTTP deep packet inspection match conditions:
1. Select Config > Virtual Contexts > context > Expert > Class Map.
2. In the Match Conditions table for the Layer 7 HTTP Deep packet Inspection class map, delete the match condition.
3. Click Deploy Now.
4. Select Config > Virtual Contexts > context > Expert > Class Map.
5. Create the new match condition.
6. Click Deploy Now.
•CSCso93610—When you use the ACE appliance Device Manager GUI to configure a virtual server (Config > Virtual Contexts > Load Balancing > Virtual Server), the Device Manager will not recognize the ICMP Reply setting if you specify the primary-inservice option. When you edit the virtual server, you may notice that None is displayed as the ICMP Reply for this virtual server. The Device Manager does not affect the current configuration for the ICMP Reply setting as long as the value is unchanged. If you use the Expert configuration screen, the ICMP Reply value will not display if it is set to primary-inservice. Adding a ICMP Reply will silently overwrite the ICMP Reply setting. Workaround: Leave None as the ICMP Reply setting for the virtual server if you configure ICMP Reply primary-inservice from the CLI.
•CSCso94404—When you configure 12 or more user contexts with application acceleration enabled in all user contexts, you may notice that the VIP addresses of user contexts 14 and higher will not accept traffic. If you make configuration changes from the ACE CLI, the following error message may appear:
%ACE-3-729001: Regular expression config download failed due to out of memory. No
regexp rules are currently applied on class-map LB-VIP in service-policy PoM-L47.
Manual roll back to a previous regexp configuration on this service-policy is needed.
Workaround: None.
•CSCso97092—The header rewrite and insert functions may not accept a null string ("") as a valid selection for the header value and replace options. This behavior may occur when you configure HTTP header rewrite and insert in an HTTP header modify action list; you will be unable to specify a null string for the header value or rewrite value. Workaround: To specify a null value for the header rewrite function, specify "\x20*" (0 or more white space). For example, enter:
host1/Admin(config)# action-list type modify http HTTP_MODIFY_ACTLIST
host1/Admin(config-actlist-mod)# header rewrite both Myheader2 header-value "\x20*"
replace "Mozilla"
•CSCso98451—The ACE appliance Device Manager GUI is unable to log in to a user context using an alias IP address. Workaround: Use the primary IP address on the interface instead of the alias IP address when you log in to the Device Manager GUI (for example, https://<primary-ip-address>).
•CSCsq02433—In rare cases, the configuration manager in the ACE may initiate a core dump when you configure the match http header header-value command in class map HTTP load balancing configuration mode or policy map load balancing configuration mode. This behavior may occur as a result when the header name string is at the end of page in memory. The following illustrates a typical system message that may display when this issue occurs:
Apr 4 2008 08:28:24 Admin: %ACE-2-443001: System experienced fatal failure.Service
name:cfgmgr(928) has terminated on receiving signal 11,reloading system
Service name:cfgmgr(928) has terminated on receiving signal 11
6K-1_ACE2-1 login: dir coApr 4 2008 08:28:45 Admin: %ACE-2-443001: System experienced
fatal failure.Service name:cfgmgr(928) crashed, last core saved,reloading system
Workaround: None.
•CSCsq05232—If you are using application acceleration, in some cases, the client may receive a connection reset when a back-end server sends an RST packet at the end of the response instead of the FIN packet. This behavior may be due to a non-cooperating or misconfigured back-end server improperly resetting the connection before closing it. If the back-end server issues an RST packet before sending a FIN packet to indicate a shutdown, the application acceleration and optimization function used to handle such condition as a read error may result in the client connection being reset. Workaround: None.
•CSCsq05929—Malformed TLS packets can result in a degradation of service. If the ACE comes under attack with these packets, you will be eventually denied access to the ACE appliance Device Manager GUI. Once the attack stops, you will be able to access the CLI on the ACE, but you will be denied access to the Device Manager GUI. Workaround: After the attack stops, restart the Device Manager DM GUI using the dm reload CLI command in Exec mode.
Note You must be the global administrator to access the dm reload command. Restarting the Device Manager does not impact ACE functionality; however, it may take a few minutes for the Device Manager to reinitialize as it reads the ACE CLI configuration.
•CSCsq08718—In a redundant configuration, the ACE may experience intermittent reboots when you enter the ft switchover command to force a switchover. This behavior typically occurs in the load balancer process of the ACE when you configure the leastconns load-balancing (predictor) method predictor and when you configure the maxconn connection limit for a real server in a server farm. Workaround: With the leastconns predictor configured, attempt to slowly perform the FT switchover process.
•CSCsq08747, CSCsq11239—The ACE may encounter dataplane problems and reboot while you are configuring connection limit on one or more real servers. This intermittent rebooting behavior may occur when you attempt to configure a connection limit on real servers and traffic is running in the background at a high rate (more then 10K TPS). Workaround: Do not change the connection limit on the real servers while traffic is running in the background.
•CSCsq06148—With IP sticky and HTTP compression enabled, the ACE may experience a memory buffer leak while traffic is running. This issue can occur when the server is sending an HTTP 408 request timeout response code; it does not happen for the other response messages. Workaround: Try to avoid having the server send an HTTP 408 response code when you enable IP sticky and HTTP compression in the ACE.
•CSCsq14328—The first VIP in a match-any statement in a Layer 3 and Layer 4 class map cannot be removed from the class map but the subsequent VIPs can be removed. Though the first VIP cannot be removed and it shows up in the running-config file, you will observe that it is removed if you enter the show cfgmgr internal vip table CLI command. In some cases, removing and readding the VIP using the line numbers or the match virtual-address commands can result in a core dump of the configuration manager. Workaround: None.
•CSCsq18142—The Load Balancer module in the ACE may generate a "No match policy error" when a setup request is sent from the client. The other control messages received are load balanced properly, but when the setup request is received by the ACE, the connection is reset. Workaround: Apply a default policy to let the traffic pass properly.
•CSCsq20809—If you have a real server configured to be shared across two server farms, in some cases, when one instance of the real server goes into the MAXCONNS state causing the parent real server to also go into the MAXCONNS state, connections to a real server in a server farm may fail even after the parent real server comes out of a MAXCONNS state. Workaround: Specify the inservice command to place the server in service, followed by the no inservice command on the parent real server.
•CSCsq21514—The syslogd daemon may become unresponsive when logging syslog messages during console sessions with a severity level of 7 (debugging messages) for long periods of time. When this behavior occurs, you will not be able to access the console because the syslogd daemon has become unresponsive. Workaround: Change the syslog output location to a buffer (logging buffer command) or to a telnet or an SSH session (logging monitor command) instead of logging messages to the console.
•CSCsq24177—The ACE data plane may become unresponsive when you configure HTTP return-code checking (retcode map) for a server farm and too many retcodes are processed by the ACE. Workaround: None.
•CSCsq29691—If the pattern repetition specified in the header rewrite function is configured in a format such as "([a-b]{m,n})", and the header value in the incoming request has x number of a characters, b characters, or both (where m < x < n), the ACE may replace the %1 in the replacement string with only the first m characters in the header value instead of the x characters. When this behavior occurs, instead of using all the x characters to replace the %1, the ACE uses only the first m characters. Workaround: None.
•CSCsq30059—With receiving HTTP/1.0 connections with TCP server reuse enabled in an HTTP parameter map, you may find that transfers fail. The content-length header functions with the HTTP/1.0 connections. However, if content-length is missing, the request may become unresponsive. Workaround: Disable TCP server reuse.
•CSCsq30322—With an ACE configured for application acceleration, the ACE may insert a superfluous "SAM" HTTP header in load-balanced traffic that is forwarded to the real servers. This behavior causes no network issues; the problem is not in connectivity but is rather an observation made of packet traces. However, it is an unexpected and incorrect occurrence. Workaround: None.
•CSCsq30578—In some cases, the ACE is unable to insert an SSL proxy service from a previously created class map match statement. This behavior can be seen for Layer 3 and Layer 4 policy maps with multiple inline match statements that contain more than one SSL proxy and NAT configuration. Workaround: None.
•CSCsq30371—With an ACE configured for application acceleration, the ACE may duplicate an X-Forwarded-For: HTTP header in load-balanced traffic forwarded to the real servers. This behavior causes no network issues; the problem is not in connectivity but is rather an observation made of packet traces. However, it is an unexpected and incorrect occurrence. Workaround: None.
•CSCsq31705—Changes in the common probe parameters such as interval, passdetect interval, passdetect count, faildetect count, or receive timeout may fail to take effect. This behavior may occur when a probe associated with multiple real servers is removed from one of the real servers. If you change any of the common probe parameters, the changes may not take effect and the probes continue to use the old values. Workaround: After you make any change in the probe parameter, remove the probe association from one of the real servers, and then readd the probe association to that real server.
•CSCsq34284—The connections for an HTTPS probe may become stuck in the CLSRST state when the HTTPS server is not reachable and the initial 3-way handshake fails. In this case, the HTTPS probe fails due to a server reply timeout. You may encounter this issue with a configuration that contains more than 8 to 10 HTTPS probe instances to an unreachable HTTPS server. Workaround: None.
•CSCsq34967—You may be unable to delete an ACE software image when you remotely log into the ACE using TACACS+ server authentication. Workaround: Perform local user authentication using the local database, and then delete the ACE software image.
•CSCsq38977—You enable a VIP to reply to ICMP ECHO requests by using the loadbalance vip icmp-reply active command in policy-map class configuration mode. In some cases, the ACE fails to respond to an ICMP Echo Request to the VIP address. This behavior can occur when the same VIP address is configured in the class map with different IP ports, and one of these VIP match statements has been deleted from the class map.
Workarounds:
–Do not delete individual match statements in a class map with the same VIP in multiple match statements. If configuration changes are necessary, reboot the ACE.
–If you must delete individual match statements for the same VIP, you can either reboot the ACE or delete the policy map and the reconfigure it.
•CSCsq43661—The ACE may encounter dataplane problems and reboot when a partial server farm failover has been configured or if all the real servers in the server farm go offline and the backup server farm takes over. In either situation, while the ACE processes the failover message, the Load Balancer module may become unresponsive while processing this request. Workaround: None.
•CSCsq44108—In some instances, the ACE may become unresponsive and reboot while running Real-Time Streaming Protocol (RTSP) traffic. Workaround: None.
•CSCsq46575—The ACE appliance may incorrectly send a null password to a RADIUS server when it receives an encrypted session key from an SSHv1 client and a Service_Request message from an SSHv2 client. The client is then prompted for the SSH password and authentication is successful. The initial null password that is sent may be logged as a Login Failure by the RADIUS server. Workaround: Use an alternate authentication method (see the Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide).
•CSCsq47543—When operating in a redundant configuration, you may find that Layer 7 connections replicated to a standby ACE are not synchronized properly while traffic is flowing. When this situation occurs, the active connections will not be inspected or load balanced properly. Workaround: None
•CSCsq48491—RADIUS packets with the same framed-ip address and calling-station id are forwarded to different real server even though a valid sticky entry exists. This behavior may occur when very few sticky entries have been allocated to a context and sticky entries are reused. Workaround: Allocate a sufficiently high number of sticky resources to a context to avoid reusing sticky entries (see the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide).
•CSCsq52729—You may find that connections are rejected when the following show stats loadbalance command output statistics increment:
–Total Layer7 Rejections
–Total Layer7 LB Policy Misses
This behavior may occur when you configure SSL cipher-based encryption level for HTTP load balancing. Workaround: None.
•CSCsq53771—The HM process in an ACE terminates on receiving Signal 11, Segmentation Fault. This issue may be encountered in a configuration that contains multiple contexts that have different types of probes. This behavior is seen frequently with SNMP and SIP probes. Another side effect is that the ACE may randomly insert the IP address of a different real server in the HTTP host header instead of the IP address of the real server that is being probed. Workaround: None.
•CSCsq55351—Use of the show np 1 me-stats -Y command may result in the ACE rebooting. Workaround: Do not use the show np 1 me-stats -Y command.
•CSCsq55389—The Vacd process in the ACE may become unresponsive and case the ACE to reboot if you perform a continuous SNMP walk of the CISCO-L4L7MODULE-RESOURCE-LIMIT-MIB tables. Workaround: None.
•CSCsq56765—In some cases, the ACE is unable to apply an SSL proxy service in a Layer 3 and Layer 4 policy map after you recreate the same policy map by inserting class maps and ssl-proxies into the policy map. For example, if you perform a fast copy and paste of CLI commands to add or delete a class map, server farm, or ssl-proxy into the Layer 3 and Layer 4 policy map, the error message "Called API encountered error" appears. Workaround: None.
•CSCsq60082—Multi-word strings within quotes in object names such as class maps, policy maps, contexts, authentication groups and so on result in an error when the configuration is saved and the ACE reloaded. This issue occurs because the quotes are not saved by the ACE as part of the running-config file. For example, the object name "ab c" does not appear in quotes when you view the running-config file.
switch/Admin(config)# context "ab c"
switch/Admin(config-context)# end
switch/Admin# show running-config
Generating configuration....
Workaround: When naming an object group, always enter an unquoted text string with no spaces. Do not use multi-word strings with quotes in object names.
•CSCsq60150—The ACE may reboot when you attempt to display or clear server farm or service policy statistics using one of the following commands: show serverfarm, show service-policy, clear serverfarm, or clear service-policy. Workaround: None.
•CSCsq60664—Multiple Cisco products contain either of two authentication vulnerabilities in the Simple Network Management Protocol version 3 (SNMPv3) feature. These vulnerabilities can be exploited when processing a malformed SNMPv3 message. These vulnerabilities could allow the disclosure of network information or may enable an attacker to perform configuration changes to vulnerable devices. The SNMP server is an optional service that is disabled by default in Cisco products. Only SNMPv3 is impacted by these vulnerabilities. Workarounds are available for mitigating the impact of the vulnerabilities described in this document.
Note SNMP versions 1, 2 and 2c are not impacted by these vulnerabilities.
The United States Computer Emergency Response Team (US-CERT) has assigned Vulnerability Note VU#878044 to these vulnerabilities.
Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-0960 has also been assigned to these vulnerabilities.
This advisory is posted at:
http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml
•CSCsq62792—When you limit the connection rate and the bandwidth rate of a real server that had previously reached those limits, the Load Balancer module in the ACE may become unresponsive after the ACE attempts to reenable a real server that below the specified limits. This behavior may occur with high traffic where there is a slight delay in processing server add rotation messages. This delay results in duplicate messages being sent. Workaround: None.
•CSCsq65194—When a real server is configured to be shared across server farms with multiple real servers that have the same connection rate and rate limits as the real server, if the real server and the parent real server reach the same connection rate and rate limit at the same time, both real servers stop accepting connections at the same time. Workaround: Specify the inservice command to place the server in service followed by the no inservice command on the parent real server to take the server out of service.
•CSCsq69873—A username defined on a TACACS server with a backslash ("\") character does not operate with the ACE. In this case, the backslash character is treated as an escape character. Workaround: Do not use a backslash character in a username defined on a TACACS server.
•CSCsq69875—If you are using a configuration that includes HTTP compression, HTTP cookie sticky, and HTTP header insertion, you may find that the ACE reboots after receiving traffic at 40,000 transactions per second (TPS). Workaround: None.
•CSCsq73896—When you configure a significant number of SNMP server users (for example, 27,000) through the snmp-server user command, the SNMP process (snmpd) may become unresponsive and the ACE reboots. Workaround: None.
•CSCsq90660—The ACE may encounter dataplane problems and reboot when you configure the least-connections predictor method for the server farm for the slow-start mode while traffic is flowing. This behavior typically occurs when there is at least one real server with a backup real server in the server farm and you change the least-connections predictor a couple of times while the traffic is running. Workaround: None.
•CSCsq92148—In a configuration with a primary real server configured with a backup real server, in some cases, the ACE does not perform the bandwidth measurement which can result in bandwidth-related rate limits not being properly applied. Workaround: Remove the backup real server for the primary real server.
•CSCsq93111—When you enable case-insensitivity in an HTTP parameter map, the ACE may fail to consider the case of the character for pattern matching when performing the HTTP header rewrite or delete function. Workaround: None.
•CSCsq93387—The ACE may reboot when you configure the least-connections predictor method for the server farm from roundrobin to the slow-start mode. Workaround: Change the weight of the standby real server to a value that is greater than or equal to that of the primary real server before you change the predictor to roundrobin.
•CSCsq96366—When operating in a redundant configuration and you instruct the ACE to use the forward command to forward requests that match a particular Layer 7 policy map without performing load balancing on the request, a connection replication failure may result. Workaround: None.
•CSCsq98949—Probes may not show a failed status even when one of the following actions occur:
–An unconfigured expect status has been received for TCP-based probes.
–An unconfigured expect address has been received for DNS probes.
This behavior can be triggered when you remove the configured values for the expect status or the expect address from a configured probe after you remove the association of the probe with the real server and then add the probe back to the real server. Workaround: Remove the expect status or expect address fields by keeping the probe association with the real server.
•CSCsq98965—In some cases, when you place a real server or real server in a server farm in service through the inservice command, the ACE is unable to take the real servers in a server farm in service and out-of-service. This behavior can occur when:
–The user role has the real-inservice feature and no other features enabled; the user cannot specify a real server or a real server in a server farm.
–The predefined roles SLB-Admin and Server-Appln-Maintenance do not allow you to configure the real server and real server in a server farm into the inservice state.
Workaround: None.
•CSCsr00727—The configuration manager (cfgmgr) in the ACE may become unresponsive and the ACE reboots. This behavior may occur when your configuration includes a large number of class maps and you associate an SSL proxy server service with a Layer 3 and Layer 4 policy map. You may find that the configuration manager may become unresponsive and the ACE reboots when you enter the show service-policy detail command. Workaround: None.
•CSCsr02178—After sending traffic at 25,000 transactions per second (TPS) in a single context, the configured real servers may not receive any connection. This behavior may occur when you enable max-conns and apply rate-limit to the real server. Workaround: None.
•CSCsr03886—The HM process in an ACE terminates on receiving Signal 11, Segmentation Fault. This issue may be encountered when you configure credentials for RADIUS probes. This behavior can occur if the number of characters in the username and password configured in the RADIUS probe credential exceeds 80 characters. Workaround: None.
•CSCsr07287—If you are using a configuration that includes HTTP compression, HTTP cookie sticky, and server connection reuse, you may find that the ACE reboots under stress conditions. Workaround: None.
•CSCsr08061—If you are using application acceleration, the ACE may bypass a qualified GET request of a persistent connection in load-balanced traffic that is forwarded to a real server. The second request of a persistent connection is a RST from the client side to the application acceleration function in the ACE and is sent directly over the already open connection to the real server. This behavior causes no network issues; the problem is not due to connectivity but is rather an observation made of packet traces. However, it is an unexpected and incorrect occurrence. Workaround: None.
•CSCsr12204—In some cases, you may find that secure (SSL) Hypertext Transfer Protocol (HTTP) traffic does not pass through the ACE after you add an ssl-proxy to a Layer 3 and Layer 4 policy map and you apply that policy map to a service policy that is attached to multiple VLAN interfaces. Workaround: None.
•CSCsr14503—The ACE may reboot if you make rate-limit connection or bandwidth configuration changes to a real server to a context in a 20-context configuration with traffic running. This behavior may be seen when a real server has been moved out-of-rotation due to the rate limit or bandwidth being reached and needs to be brought back into rotation. Workaround: None.
•CSCsr16045—While rebalancing a client request from one server farm to a different server farm due to a rule change, if the real server is the same real server that is used for the previous request, the ACE may not measure the response time for the previous request response to the real server instance in the original server farm in use.
For example, assume that the app-req-to-resp response predictor is configured in two different server farms (SF1 and SF2) that have one real server (RS2) in common. The two server farms are associated to class maps C1(looking for /index1.html) and C2 (looking for /index2.html) in a load-balanced policy map. In this configuration, if the client opens a connection to the VIP and sends a /index1.html in it, then the request is load balanced to one of the real servers (RS1) in the server farm (SF1). If the client sends /index2.html as the second request, then the request is rebalanced to real server RS2 in the server farm SF2. While rebalancing the second request to a different real server to a different server farm, the ACE properly updates the response time for the first request-response for the real server RS1. If the client sends /index3.html as its third request, then that request is rebalanced to real server RS2 in the server farm SF1. However, the response time for real server RS2 in server farm SF2 is not updated.
Workaround: None.
•CSCsr16219—Connectivity to a configured VIP may fail after you perform a reload on the ACE. The reload of the ACE causes all load-balanced traffic to the VIP packets to get dropped when the client is on the same subnet as the VIP, and the upstream switch is running spanning tree on the corresponding VLAN interface without a portfast configuration. If there is a shared-vlan configuration on ACE, the VIP or MAC address may change after you perform the reload, which results in an outdated MAC address in the ARP table on the ACE.
Workarounds:
–Clear the ARP table on the ACE, or specify a shutdown and no shutdown sequence on the ACE to retrigger a convergence.
–Enable a carrier delay that is greater than 30 seconds on the ACE physical Ethernet port.
•CSCsr17226—In a configuration that includes HTTP persistence rebalance and HTTP cookie stickiness, when the server is in the MAXCONNS state, multiple requests on the same connection with different cookies may be load balanced to the same server and the sticky entries are open to the same server. Workaround: None.
•CSCsr18122—In some cases, the connection to a back-end server is not added into the reuse pool. The client sends a RST instead of a FIN to terminate a connection. If the RST is piggybacked with an ACK (indicating the acknowledgement of entire server response), then the RST is forwarded to the server even if the connection has reuse enabled. Workaround: None.
•CSCsr19951—All sticky entries may not get replicated properly during a redundancy upgrade from software version A1(8.0x) to A3(1.0) if the active ACE is upgraded first. If you upgrade the active ACE first with the A3(1.0) image, the ACE standby which is still running the software version A1(8.0x) image will take over as new active ACE. Since with the A1(8.0x) image sticky replication takes approximately 80 minutes, you need to wait for the replication to finish to ensure that all entries from the new active ACE that is running the A1(8.0x) image are replicated to the new standby ACE that is runningA3(1.0) before you perform a switchover. If you do not wait 80-minutes, some entries may not get replicated. Workaround: Upgrade the image on the standby ACE first as described in the "Upgrading Your ACE Software in a Redundant Configuration" section.
•CSCsr22940—After the ACE has been idle for a lengthy period of time, in some cases, when you enter the show running-config command, the boot system image line is missing from the show running-config output. For example, enter:
191876336 Jul 8 23:37:37 2008 c4710ace-mz.A3_2_0.bin
191880545 Jul 9 10:01:57 2008 c4710ace-mz.A1_8_0A.bin
Usage for image: filesystem
741044224 bytes total used
switch/Admin# show running-config | be boot
Generating configuration....
Enter configuration commands, one per line. End with CNTL/Z.
switch/Admin(config)# boot system image:c4710ace-mz.A3_2_0.bin
Validating system image...
switch/Admin# show running-config | be boot
Generating configuration.... <<<--- No boot string set
Workaround: None.
•CSCsr26006—In a redundant configuration, with a heavy volume of end-to-end to SSL traffic, repeatedly specifying the show tech-support command may cause redundancy to toggle between ACE peers. When this behavior occurs, you may find that the standby ACE momentarily becomes the active ACE, and then returns to the standby state with out any intervention. Workaround: Do not repeatedly execute the show tech-support command while a heavy volume of traffic is running.
•CSCsr30325—The speed and duplex settings for an ACE physical Ethernet port may not be synchronized properly to a standby ACE. Workaround: Manually configure the speed and duplex settings on the standby ACE (see the Cisco 4700 Series Application Control Engine Appliance Routing and Bridging Configuration Guide).
•CSCsr30478—In a redundant configuration, the configuration manager in the ACE may become unresponsive after the active ACE resynchronizes with an ACE peer. Workaround: None.
•CSCsr38687—The ACE may reboot with a least-connections predictor configured and SIP traffic running. Workaround: None.
•CSCsr47316—In a redundant configuration, the ACE peer may become stuck in a STANDBY_CONFIG state while waiting for configuration synchronization from the active ACE. Workaround: Perform one of the following actions to resolve this issue:
–Disable, and then enable the auto-synchronization of the running-configuration file by using the no ft auto-sync running-config and ft auto-sync running-config commands.
–Disable, and then enable the FT VLAN by using the shutdown and no shutdown commands.
•CSCsr49222—In a redundant configuration, the ACE may reboot with the "BUG: unable to handle NULL pointer" message when you modify either the FT VLAN or Quality of Service (QoS) configuration for an Ethernet port. Workaround: None.
•CSCsr49730—When using a configuration with syn-cookie and TCP server reuse enabled, you may find that packets larger than 536 bytes are dropped by the ACE. This behavior may lead to a connection stall and an eventual connection timeout. Workaround: Disable TCP server reuse or syn-cookie from your ACE configuration.
•CSCsr55491—When you use the ACE appliance Device Manager GUI, you may find that you are unable to login to the Device Manager and the following error message appears: "DM initialization failed .... Contact your technical support team". This behavior typically occurs during startup when the Device Manager is unable to upload the CLI configuration. Workaround: Restart the Device Manager using the dm reload command (you must be the global administrator to access the dm reload command). Restarting the Device Manager does not impact ACE functionality; however, it may take a few minutes for the Device Manager to reinitialize as it reads the ACE CLI configuration. Once the Device Manager restarts, you can login to the GUI.
•CSCsr56562—If you are using SSL, you may find that the SSL process becomes unresponsive when:
–You are using an expired certificate revocation list (CRL).
–The CRL on the CRL server is not updated.
–The SSL parameter map is configured to reject a client certificate when the CRL in use has expired through the expired-crl reject command.
To verify if a CRL is expired, perform the following procedure:
a. Enter the openssl command as follows:
switch/Admin# openssl crl -in crlname -noout -text
b. Verify the timestamp for the Next Update field in the output. For example:
switch/Admin# openssl crl -in test.crl -noout -text
Certificate Revocation List (CRL):
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/ST=california/L=sanjose/O=cisco/OU=adbu/CN=test/emailAddress=sss
Last Update: Jun 10 14:49:39 2008 GMT
Next Update: Jul 10 14:49:39 2008 GMT
CRL extensions:...........
c. Enter the show clock command and verify the time of the ACE. If the time of the ACE is a value that is later that what is displayed in the openssl command Next Update field, then the CRL is expired. In the example shown below, the show clock output is a later timestamp than the CRL:
Fri Aug 1 02:13:28 ADT 2008.
Workaround: Ensure that you do not use an expired CRL. If the CRL is expired, do not include the the expired-crl reject command in the SSL parameter map. If that flag is on, ensure that CRL server has a non-expired CRL.
•CSCsr63058—The ACE may becomes unresponsive when you change the global real server from inservice to out of service. This behavior can also occur in a configuration with the weighted least-connections predictor. Workaround: Place the individual real server into the OUTOFSERVICE state rather than the global real server.
•CSCsr66010—The ACE may become unresponsive when you configuration includes RTSP load balancing and RTSP inspection with the least-connections predictor, with the ACE operating under stress traffic conditions (for example, traffic is sent continuously at approximately 200 connections per seconds for over 8 hours). Workaround: None.
•CSCsr71701—Traffic to a real server may fail even though the real server appears to be operational. In this case, the number of current connections on the real server may be stuck or may show a high number of open connections. Workaround: Configure the maximum connection limit for all real servers in the server farm such that proper processing of the real server is properly performed.
Software Version A3(1.0) Open Caveats
The following open caveats apply to ACE software version A3(1.0).
•CSCse85906—In a redundant configuration, persistent connections established through an ACE context may become unresponsive after a switchover occurs. Workaround: None.
•CSCsg95099—When you configure SNMP notification using the ACE appliance Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. This information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > CLI Sync or CLI Sync All.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCso29529—A user with the configured role of Network-Monitor is allowed to delete other user directories on the ACE. Workaround: Do not configure a user with the Network-Monitor role. See the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide
•CSCso93424—In some cases, when you have a configuration that includes a policy map for both server load-balancing and application inspection, you may encounter a configuration rollback issue if you create two checkpoints where one checkpoint has the policy map associated with a VLAN (checkpoint 1) and the other leaves the policy map unused (checkpoint 2). In some cases, when you perform a rollback from checkpoint 1 to 2, the application inspection policy on the VLAN is not removed and packets continue to be inspected. Workaround: Avoid creating a checkpoint that includes unused policy maps.
•CSCsq20736—In a redundant configuration, when you cause a switchover by using the ft switchover command, there is a brief period of time during which any configuration changes made on the active ACE will not be synchronized to the standby ACE. When the Active to Standby_Hot steady state is reached, the new configuration exists only on the active ACE and not on the standby ACE. Workaround: Do not make any configuration changes after you specify the ft switchover command. Be sure to wait until the FT group reaches the steady state of Active to Standby_Hot.
•CSCsq25310—In a redundant configuration, scripted probes using the vshell configuration command vsh_conf_cmd will fail on the standby ACE when you specify the no ft auto-sync running config command on the active ACE to disable the automatic synchronization of the running-configuration or the startup-configuration files before performing a configuration synchronization.
For example:
switch/Admin# show probe scrip1 detail
----------------------------------------------
port : 0 address : 0.0.0.0 addr type : -
interval : 10 pass intvl : 10 pass count : 2
fail count: 3 recv timeout: 10
script filename : NEW_VSH_SCRIPT
------------------ probe results ------------------
associations ip-address port porttype probes failed passed health
------------ ---------------+-----+--------+--------+--------+--------+------
10.2.0.101 0 -- 3 3 0 FAILED
No. Passed states : 0 No. Failed states : 1
No. Probes skipped : 0 Last status code : 30006
No. Out of Sockets : 0 No. Internal error: 0
Last disconnect err : Internal error: Script error >>Script error in standby ACE
Last probe time : Mon Aug 4 23:14:40 2008
Last fail time : Mon Aug 4 23:14:20 2008
Workaround: None.
•CSCsq57703—When the ACE is configured for FTP inspection, if a client sends an EPRT command with the wrong syntax, the connection is reset by the ACE. When this behavior occurs, you will not see a 500 Error message because the request is not forwarded to the server. Workaround: None.
•CSCsq59069—If you enable the header modify per-request command without persistence rebalance, the ACE may fail to modify the server's response from the second request on even though there is a response action statement in the action list. Workaround: Ensure that persistence rebalance is enabled (the default behavior with the A3(1.0) release).
•CSCsq59495—If your configuration includes a SIP proxy in front of the ACE with a defined NAT policy to enforce UDP and TCP traffic that uses a different source NAT on the back end, the SIP call may drop the 200 OK HTTP status response code for the call hold invitation if the receiver initiates the call hold. Workaround: Avoid having the NAT policy enforce UDP and TCP using a different source NAT.
•CSCsq81190—With persistence rebalance disabled and the header modification on every HTTP request or response function enabled (the header modify per-request command), in some cases, with a load-balancing policy-map configuration that includes a Layer 7 class map searching for "/index.html" and the default class-map, the ACE may incorrectly modify the response based on the action list. Workaround: None.
•CSCsq91645—In a user-defined action list where one header has multiple matches, the defined action defined may not occur. For example, if you configure both the SSL URL rewrite location and the HTTP header rewrite for the location header in the response direction to change the path of the URL in the same action list, the SSL URL rewrite function may not occur.
host1/Admin(config-actlist-mod)# action-list type modify http a1 header rewrite
response Location header-value "(http://.*/)index.html" replace "%1home.html" ssl url
rewrite location ".*"
Workaround: Avoid having multiple matches in an action list for a single header. For example, for the above example, combine two rewrite actions to:
host1/Admin(config-actlist-mod)# action-list type modify http d1 header rewrite
response Location header-value "http://(.*)/index.html" replace "https://(.*)
/home.html"
•CSCsq99661—In a configuration with both SIP application inspection and maximum forward field validation enabled, the ACE should deny any calls with a maximum forward value that is greater than or equal to 1000. In some cases, requests with a maximum forward value that is greater than or equal to 1000 are not dropped. Workaround: None.
•CSCsr11991—When using application acceleration and optimization, with both cache forward and SSL configured, the ACE sends asynchronous cache request to the server for every GET request. These messages should increment the real servers counter Connection Total field. In some cases, the counter is not incremented. Workaround: Clear the cache by removing and adding the cache forward function from the configuration. See the Cisco 4700 Series Application Control Engine Appliance Application Acceleration and Optimization Configuration Guide.
•CSCsr14725—The ACE allows you to uninstall a base license without first uninstalling the upgrade license if it is a demo license. Workaround: None.
•CSCsr21689—The first packet of a TCP, UDP, or ICMP connection may not be captured; however, the remaining packets are captured for the same flow. This behavior can occur when you have the packet capture function configured for a specific ACL and for Layer 7 load-balanced traffic. Workaround: None.
•CSCsr22457—The TCP probe may fail if the real server sends a FIN after completing a 3-way handshake. When the ACE receives a FIN from a real server after completing a 3-way handshake and after the ACE closes the connection by sending a FIN or a RST, the probe is successful. However, if the ACE receives a FIN from a real server after completing a 3-way handshake but before the ACE closes the connection by sending a FIN or a RST, the probe is marked as failed by the ACE. Workaround: Do not configure or use special tools on the server side to send a FIN immediately after the initial 3-way handshake.
•CSCsr23197, CSCsq43870—When operating in a redundant configuration, if you perform a reload of the higher priority active ACE in an FT group setup (ACE-1) and the appliance goes back online, if ACE-1 does not receive a heartbeat from the standby ACE-2 peer, ACE-1 assumes that the peer is down and immediately moves to the ACTIVE state. Later, when ACE-1 does receives a heartbeat from the ACE-2 peer, ACE-1 sends its configuration to the ACE-2 peer which now has the higher priority.
Any applied configuration changes that were made to the ACE-2 peer with the lower priority during the time when the higher priority ACE-1 was reloading will be lost once ACE-1 becomes active. In addition, the connections sustained by the ACE-2 peer will also be flushed.
To avoid this behavior, the A3(1.0) software release has added the carrier-delay command to the interface configuration mode to add a configurable transition delay at the physical port level for the FT VLAN. When you configure a carrier-delay transition time for a physical Ethernet port, the active ACE that is proceeding from a reload does not change to the ACTIVE state for the duration of the specified carrier-delay timer. This configurable transition time provides a window for the ACE-2 peer to sense that the other peer has returned from a reload state. At that point, the ACE-2 peer can send a heartbeat to ACE-1. The use of the carrier-delay transition time can provide ACE-1 with sufficient time to return from the reload and properly move into the INIT state, the STANDBY_CONFIG state, the STANDBY_BULK state, and finally to the ACTIVE state. As a result, all configuration changes performed to the ACE-2 peer during the reload period are properly synchronized to ACE-1.
If you downgrade from software version A3(1.0) to A1(7a) or A1(7b), those earlier software releases do not support the use of the carrier-delay feature.
In addition, if you download to A1(8.0) or A1(8.0a), even though the carrier-delay command is a configurable selection, the ACE that is proceeding from a reload moves directly into the ACTIVE state. If the reloaded ACE-1 happens to be of a higher priority, all configuration changes made to the ACE-2 peer during the reload sequence of ACE-1 will be lost once ACE-1 becomes active.
Workaround: If you intend to downgrade from software version A3(1.0) to the A1(8.0) or A1(8.0a) software release, first save the current running-config file on the active ACE before you perform the software downgrade procedure on the active ACE.
For downgrade instructions, see the "Downgrading Your ACE Software in a Redundant Configuration" section.
•CSCsr29126—No ACL merge list is produced on an access-group addition. This behavior can occur after an ACL download failure by removing the access-group on an interface and adding a new access-group within five seconds. Workaround: Wait for more than five seconds after deleting an access-group from a VLAN interface, or delete the VLAN interface and reconfigure it.
•CSCsr67106—With packet capture enabled, large page transfers with end-to-end and back-end SSL connections may become unresponsive. Workaround: Disable the packet capture function for end-to-end and back-end SSL connections with large page transfers.
•CSCsr67556—When you perform a checkpoint rollback, you may find that an access-group configuration is lost during the rollback. This behavior can occur if during the rollback all of the lines associated with an access-list are removed from the configuration, and then any associated access-group configuration that refer to the access-list is also removed. If the access-group configuration was also part of the configuration in which the rollback was being made to, then this access-group configuration will not be reconfigured. This issue applies to both globally configured access-groups as well as access-groups applied to VLAN subconfigurations. Workaround: To prevent the issue, use access-list remarks. These remarks should be present and identical in the current running-configuration and in the configuration to which you will be rolling back.
For example:
access-list one remark workaround
access-list one ex permit udp any any
access-list one ex permit icmp any any
access-list one remark workaround
access-list one ex permit ip any any
Another way to prevent this issue is to fully remove the access-list from the running-configuration file before you perform the checkpoint rollback. A manual configuration of the lost access-group will resolve it.
Checkpoint rollback will display the configuration that the system was unable to rollback to, as shown below:
switch/test# check roll test2B
---------------------------------------------------------------------
-- This operation will rollback the system's running-config to the --
-- checkpoint's configuration. This can take sometime depending on --
-- the amount of diff between the two configurations. --
---------------------------------------------------------------------
Do you wish to proceed? (y/n) [n] y
Config rollback in progress...failed.
Below diff could not be applied to running-config.
In the above example, the access-group input HTTP command is the command that the ACE could not apply. Manual rollback is then necessary for this command.
Additionally, the output of the show acl-merge merged vlan command would display the message: "% Interface or access-list/service-policy not found."
•CSCsr69631—When operating in a redundant configuration, you may find that TCP flows are disrupted after you perform an FT switchover by using the ft switchover command. This behavior may occur if normalization is disabled on the interface; in this case, connections replicated to the standby ACE are in an embryonic state. As a result, after performing an FT switchover, these connections will be deleted and the data transfer stalls. Workaround: Enable normalization on the VLAN interface.
•CSCsr80332—The real server in a server farm may remain in a MAX_LOAD state even after the least-loaded predictor is removed from the server farm. This behavior can occur when one of the following conditions occur:
–When you configure an SNMP least-loaded predictor probe in a server farm along with any other probe (for example, an HTTP probe; but it can be an SNMP probe as well), and both the SNMP predictor probe and the HTTP probe are in FAILED state. This behavior may be due to a real server being placed into a MAX_LOAD state in the server farm. Under this condition, if you remove the least-loaded predictor, the real server will be stuck in the MAX_LOAD state instead of reverting back to PROBE_FAILED state. For example:
predictor least-loaded probe SNMP
In this example, both the SNMP and HTTP probe are in a FAILED state and the real server (rs1) is in MAX_LOAD state, under which the least-loaded SNMP probe is unconfigured.
–When you configure an SNMP least-loaded predictor probe, FAIL-ON-ALL action, and any other probes in a server farm. If a real server in the server farm is in MAX_LOAD state due to an SNMP probe FAILURE, and any one of the other probes is also in FAILED state for that real server, under this condition if you remove least-loaded predictor then you may observe that the real-server is stuck in the MAX_LOAD state. For example:
predictor least-loaded probe SNMP
In this example, either (or both) the HTTP and RADIUS probes are in the FAILED state, along with the SNMP probe, and the real server (rs1) is in MAX_LOAD state, under which the least-loaded SNMP probe is unconfigured.
Workaround: Perform one of the following actions to resolve this issue:
–If the real-server is stuck in the MAX_LOAD state in a server farm, take the real server out of service by entering the no inservice command, and then place it back in service by entering the inservice command. This action can also be performed at the real server level.
–Before removing the least-loaded predictor from the server farm, ensure that no other probes are in the FAILED state for real servers that are in the MAX_LOAD state.
•CSCsr81801—When you create a user with the role that has the ability to permit, create, and place a real server in service to activate or suspend real servers, when this user logs in to the Device Manager GUI, they are able to access the Real Servers table (Config > Operations > Real Servers) but are unable to use the Activate and Suspend buttons to activate or suspend a real server. This behavior occurs only for a user with a role that includes a rule as permit/create/real-inservice. Workaround: Add the following rule for the newly created user: permit/modify/serverfarm. This user will be able to activate and suspend the real servers from the Config > Operations > Real Server page.
•CSCsr87736—When you configure a backup server farm with sticky for a virtual server in the Device Manager GUI (Config > Virtual Contexts > Load Balancing > Virtual Servers) you may find that the CLI is not synchronized to configure the backup server farm. If you edit this virtual server in the Device Manager GUI, you will notice that the backup server farm is not set.
Workaround: Add a backup server farm from the Sticky Groups table as follows:
a. Select Config > Virtual Contexts > context > Load Balancing > Stickiness. The Sticky Groups table appears.
b. Select an existing sticky group you want to modify, then click Edit.
c. Add the backup server farm to this group as a sticky group attribute.
d. Click Deploy Now.
Alternatively, you can:
a. Create a new sticky group with primary and backup server farms from the Sticky Groups table (Config > Virtual Contexts > context > Load Balancing > Stickiness).
b. Use this sticky group in a virtual server.
•CSCsv95366—When you use the ACE appliance Device Manager GUI, in some instances after you login to the Device Manager you may encounter a blank page. The issue occurs after upgrading to the A3(x) release. Workaround: Perform one of the following workarounds:
–Enter the reload command in Exec mode to reboot the ACE.
–Upgrade to software version A3(2.2) or higher.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned 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. (1005R)
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.
© 2010 Cisco Systems, Inc. All rights reserved.
Feedback