Guest

Cisco Services Modules

Release Note vA5(2.x), Cisco ACE Application Control Engine Module

  • Viewing Options

  • PDF (1.4 MB)
  • Feedback
Release Note for the Cisco Application Control Engine Module

Table Of Contents

Release Note for the Cisco Application Control Engine Module

Contents

New Software Features in Version A5(2.1)

Configuring HTTP URL Rewrite

Related CLI Changes

Guidelines and Restrictions

SSL Sticky Configuration in a Two-Tier ACE Deployment

Support for Radius IPv6 Load Balancing

Related CLI Commands

Guidelines and Restrictions

Device Monitoring: Bandwidth, Total Active SSL Connections, and NAT Pool Utilization

Bandwidth and Active SSL Connections

NAT Pool Utilization

New Software Features in Version A5(2.0)

Buddy Sticky Groups that Enable Persistence Across Multiple Server Farms

Guidelines and Restrictions

One-to-One Association Application Example

Asymmetric Association Application Example

Many-to-One Association Application Example

Displaying Buddy Sticky Group Information

Support for Static NAT IPv4-to-IPv6 and IPv6-to-IPv4 Translation

Static Destination NAT and Dynamic Source NAT Mixed-Mode Application

Static Destination NAT and Static Source NAT Mixed-Mode Application

Static NAT for Subnets

Support for DNS IPv4-to-IPv6 and IPv6-to-IPv4 Load Balancing with Inspection

Maintaining a Full Proxy Connection During a TCP Handshake Mismatch

Support for a Wildcard KAL-AP GSS IP Address

SSL Probe Configuration Option for Ignoring the Certificate Expiration Date

Support for Additional Syslog Logging Hosts

Support for SSL Session ID Stickiness

Using the Modified sticky Command for SSL Session ID Stickiness

Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness

Support for the ACE No Payload Encryption Software Version

Support for Creation of RDP Parameter Maps

Configuring an RDP Parameter Map

Defining a Description to the RDP Parameter Map

Enabling Routing Token Rebalance in the RDP Parameter Map

Associating the RDP Parameter Map with a Layer 3 and Layer 4 Network Traffic Policy Map

Ability to Enable Regular Expression Download Optimization

Extended Range of Supported Characters in a URL

Configuring an SNMP Peer Engine ID for the Standby ACE

Configuring an SNMP User Authentication Password for the Standby ACE

Ability for the ACE to Accept a User Account with an Expired Date

Addressing SSL Certificates With a Subject or Issuer That is Greater Than 256 Bytes

ACE Probes Use the Interface MAC Address as the Source MAC Address

Chassis, Supervisor Engine, and Cisco IOS Support for the ACE30 Module

Virtual Switching System Support

ACE Operating Considerations

Available ACE Licenses

Ordering an Upgrade License and Generating a License Key

Upgrading Your ACE Module Software in a Redundant Configuration

Before You Begin

Changing the Admin Password

Changing the www User Password

Creating a Checkpoint

Copying the Startup Configuration of Each Context

Checking Your Configuration for FT Priority and Preempt

Upgrade Procedure

Downgrading Your ACE Module Software in a Redundant Configuration

Before You Begin

Downgrade Procedure

ACE Documentation Set

ACE Troubleshooting Wiki

Software Version A5(2.1) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

Software Version A5(2.1) Resolved Caveats

Software Version A5(2.1) Open Caveats

Software Version A5(2.1) Command Changes

Software Version A5(2.1) System Log Messages

445004

445005

Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

Software Version A5(2.0) Resolved Caveats

Software Version A5(2.0) Open Caveats

Software Version A5(2.0) Command Changes

Software Version A5(2.0) System Log Messages

251006

251010

Obtaining Documentation and Submitting a Service Request


Release Note for the Cisco Application Control Engine Module


February 28, 2013


Note The most current Cisco documentation for released products is available on Cisco.com.


Contents

This release note applies to the following software versions for the Cisco Application Control Engine (ACE) module, model ACE30 (ACE30_MOD_K9).

A5(2.1)

A5(2.0)

For information on the ACE module features and configuration details, see the ACE documentation located at:

http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html

This release note contains the following sections:

New Software Features in Version A5(2.1)

New Software Features in Version A5(2.0)

Chassis, Supervisor Engine, and Cisco IOS Support for the ACE30 Module

Virtual Switching System Support

ACE Operating Considerations

Available ACE Licenses

Ordering an Upgrade License and Generating a License Key

Upgrading Your ACE Module Software in a Redundant Configuration

Downgrading Your ACE Module Software in a Redundant Configuration

ACE Documentation Set

ACE Troubleshooting Wiki

Software Version A5(2.1) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

Software Version A5(2.1) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

Obtaining Documentation and Submitting a Service Request

New Software Features in Version A5(2.1)

This section describes the new features associated with ACE Module software version A5(2.1).

Software version A5(2.1) provides the following new features:

Configuring HTTP URL Rewrite

SSL Sticky Configuration in a Two-Tier ACE Deployment

Support for Radius IPv6 Load Balancing

Device Monitoring: Bandwidth, Total Active SSL Connections, and NAT Pool Utilization

Configuring HTTP URL Rewrite

The HTTP URL rewrite feature enables the ACE to rewrite URI/URL pathnames in HTTP requests. When you request a certain URL, the server receives the request containing the URL modified by the ACE. This feature allows you to process application transactions on the backend real server/server farm in a unified manner. HTTP URL rewrite uses the rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs instantly which provides a flexible and powerful mechanism for URL manipulation. These URL manipulations depend on various tests of HTTP headers.

HTTP URL rewrite operates on the URLs and generates query string parts as the result. It effectively searches for the HTTP regex pattern on a URL and replaces the matched search pattern with the defined rewrite pattern.

You can rewrite the URL value in an HTTP request from a client using the url rewrite command in action-list modify configuration mode.

url rewrite url_regex replace new_url_regex

The keywords, parameters, and arguments of the url rewrite command are as follows:

url_regex—Specifies that the ACE is to match an HTTP URL present in HTTP request packets from clients.

replace—Specifies the replacement pattern for a new URL.

new_url_regex—Specifies that the ACE is to replace the new HTTP URL regex value.

In the following configuration example, the Layer 7 class matches any URL beginning with /foo/. Under the action-list, it then matches a more specific URL than the Layer 7 class and delineates two sections, which are saved as variables %1 and %2. The replace statement constructs the new URL using the %1, %2, and %h built-in variables.

class-map type http loadbalance match-any urlmatch
2 match http url /foo/.*
 
   
action-list type modify http Action_question1
 url  rewrite  "/index.html[?]ram=[?]cookie" replace "/test"

Related CLI Changes

The new HTTP URL rewrite feature includes a set of statistics counters and error counters, and the following command line interface (CLI) commands have been modified:

show stats http—The show stats http command is modified to include the following statistics in the output:

URLs Rewritten—Counter to show the number of replacements performed for the current context

URLs Rewrite Errors—Counter to show the number of failed rewrites for the current context

URL Rewrites Configured—Counter to show how many URL Rewrite rules have been configured

The following example shows how to use the show stats http command:

switch/ctx1# show stats http
--------------HTTP Statistics-----------
LB parse result msgs sent : 2 , TCP data msgs sent : 2
Inspect parse result msgs : 0 , SSL data msgs sent : 0
sent
TCP fin/rst msgs sent : 0 , Bounced fin/rst msgs sent: 0
SSL fin/rst msgs sent : 0 , Unproxy msgs sent : 1
Drain msgs sent : 1 , Particles read : 21
Reuse msgs sent : 0 , HTTP requests : 2
Reproxied requests : 0 , Headers removed : 0
Headers inserted : 0 , HTTP redirects : 0
HTTP chunks : 0 , Pipelined requests : 0
HTTP unproxy conns : 1 , Pipeline flushes : 0
Whitespace appends : 0 , Second pass parsing : 0
Response entries recycled : 0 , Analysis errors : 0
Header insert errors : 0 , Max parselen errors : 0
Static parse errors : 0 , Resource errors : 0
Invalid path errors : 0 , Bad HTTP version errors : 0
Headers rewritten : 1 , Header rewrite errors : 0
URLs rewritten : 4 , URL rewrite errors : 0
 
   

show action-list—The show action-list command is modified to include the URL Rewrite field in the output.

The following example shows how to use the show action-list command:

switch/ctx1# show action-list
Number of action-lists : 2
Action-list : act1
Type : Modify
Header Insert Request : name: Host value: 31.0.0.248
Header Insert Response :
Header Insert Both :
Header Delete Request :
Header Delete Response :
Header Delete Both :
Header Rewrite Request :
Header Rewrite Response :
Header Rewrite Both :
SSL Rewrite Location :
URL Rewrite :
 
   
Action-list : act2
Type : Modify
Header Insert Response :
Header Insert Both :
Header Delete Request :
Header Delete Response :
Header Delete Both :
Header Rewrite Request : name: Host value: 41(.*)100 replace: 31%1249
Header Rewrite Response :
Header Rewrite Both :
SSL Rewrite Location :
URL Rewrite : url regex: /index.html replace: /test.html

Guidelines and Restrictions

The url rewrite command must have the url_regex and new_url_regex replacement pattern. In addition to the built-in variables, the following variables are supported:

%h

%u

Optionally, you can use user-defined variables.

Only one rewrite rule is allowed per action list because the Layer 7 class map is used to match the URLs that need to be written.

A total of 1000 URL rewrites are supported per ACE.

If the url rewrite command is used for a URL that contains the "?" character, this character needs to be represented as [?]. For example:

url rewrite "/index.html[?]ram=cookie" replace "/test.html" 

SSL Sticky Configuration in a Two-Tier ACE Deployment

ACE software version A5(2.1) allows you to optimize multiple SSL sticky entries associated with the tier-one of a two-tier ACE deployment into a single SSL sticky entry. The SSL stickiness feature in a two-tier ACE deployment ensures persistent SSL connections across multiple server farms and helps reduce multiple sticky entries.

By default, SSL Session ID reuse feature is disabled in the ACE. If you intend to configure a SSL sticky in two-tier ACE deployment, enable the SSL session ID reuse feature in the tier-two ACE and configure the response sticky with 4 byte SSL ID parsing in the tier-one ACE.

The following example shows tier-one response sticky with four byte SSL ID parse configuration:

sticky ssl SSL
length 4
serverfarm sf1
response sticky
 
   

Each SSL connection is uniquely identified by its SSL session ID and uses the unique four bytes of the first burned-in MAC addresses of a two-tier ACE. These four bytes are used by the one-tier ACE to parse the session ID and to identify the corresponding sticky entries in the two-tier ACE deployment.

Figure 1 shows the deployment architecture of the one-tier and two-tier ACE.

Figure 1 Two-Tier ACE Deployment Architecture

For more information about configuring stickiness, see the "Configuring Stickiness" chapter in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.

Support for Radius IPv6 Load Balancing

ACE software version A5(2.1) supports load balancing of RADIUS IPv6 with session persistence (stickiness) on the ACE. It is applicable to mobile wireless deployments. In such a deployment, the ACE load balancing is requested from Cisco GGSN (Gateway GPRS Support Node) to Cisco Content Services Gateway (CSG). The GGSN ensures that a prefix is assigned to one end user only. The ACE load balances the RADIUS requests and creates the sticky entries based on the framed IPv6 prefix. The sticky lookup based on the source IP address for IPv6 end user packets match the sticky entries created by the RADIUS packets.

The sticky replication message is modified to include an additional 64 bit field because the support for RADIUS IPv6 load balancing requires the sticky hash key to be 128 bits.

For background information about creating a RADIUS-attribute sticky group, see the "Creating a RADIUS-Attribute Sticky Group" section of the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.

Related CLI Commands

New CLI Commands

ACE software version A(2.1) provides the new CLI command enduser-v6-prefix-length to configure the prefix length of end user packets from the radius sticky configuration mode. The ACE uses the end user prefix length to mask the source ip address of the end user packets during the sticky lookup for IPV6 packets.

The sticky radius framed-ip command allows you to access the radius sticky configuration mode. The only syntax for the enduser-v6-prefix-length command is:

enduser-v6-prefix-length prefix_length_value

The enduser-v6-prefix-length command is used to configure prefix length for end user packets from the radius sticky mode. The valid prefix range is 1 to 128 bits. The default prefix length is 64 bits.

The following examples show how to use the enduser-v6-prefix-length command to define a prefix length of 112:

host1/Admin# config 
host1/Admin(config)#
host1/Admin(config)# sticky radius framed-ip fip-farm-v6
host1/Admin(config-sticky-radius)# enduser-v6-prefix-length 112
 
   

Use the no form of this command to remove the prefix length for end user packets from the configuration.

Modified CLI Commands

The following CLI show commands are modified to include IPv6 statistics:

show stats loadbalance radius

The following example shows the show stats loadbalance radius command:

switch/Admin# show stats loadbalance radius 
+-------------------------------------------------+
+--------- Radius Loadbalance statistics ---------+
+-------------------------------------------------+
 Total requests received               : 0
 Total responses received              : 0
 Total retry packets received          : 0
 Total header parse results received   : 0
 Total body parse results received     : 0
 Total data parse results received     : 0
 Total packets sent out                : 0
 Total sessions allocated              : 0
 Total sessions deleted                : 0
 Total username sticky added           : 0
 Total calling-station sticky added    : 0
 Total framed-ip sticky added          : 0
 Total framed-ipv6 sticky added        : 0
 Total v6 end-user pkt sticky success  : 13
 Total v6 end-user pkt sticky failure  : 0
 Total end-user packet sticky success  : 0
 Total end-user packet sticky failure  : 0
 Total Acct-On/Off requests received   : 0
 Total Acct-On/Off responses received  : 0
 Total Acct-On/Off with no rules       : 0
 Total Acct-On/Off req processing done : 0
 Total NULL packet received errors     : 0
 Total parse errors                    : 0
 Total invalid proxy mapper entries    : 0
 Total sticky addition failures        : 0
 Total proxy mapper alloc failures     : 0
 Total stale packet errors             : 0
 Total Radius sessions failures        : 0
 Total proxy mapper lookup failures    : 0
 
   

show sticky database detail

The following example shows the show sticky database detail command:

switch/Admin# show sticky database detail
 
   
processor (0/3):             0
results index:               1 of 1
sticky group:                fip-farm-v4
sticky type:                 RADIUS
rserver:                     v4-rs-01
realPort:                    0
timeout (secs):              86400
sticky-entry:                0x2002000000000000 0000000014110000
internal entry-id:           0x200003
time-to-expire (secs):       26025
sticky-hit-count:            3
active-conn-count:           0
in-use reference count:      0
static entry:                FALSE
reverse entry:               FALSE
active entry:                TRUE
timeout-active-conns:        FALSE
created-from-HA-peer:        FALSE
HA-replicated-at-least-once: TRUE
Radius Wait-For-Ack:         FALSE
 
   
Total Sticky Entries: 1
 
   

show sticky database

The following example shows the show sticky database command:

switch/Admin# show sticky database
 
   
sticky group : fip-farm-v4
type         : RADIUS
timeout      : 1440          timeout-activeconns : FALSE
  sticky-entry          rserver-instance                 time-to-expire flags
  ---------------------+--------------------------------+--------------+-------+
  0x2002000000000000    v4-rs-01:0                       26021          -
	0000000014110000

Guidelines and Restrictions

When you downgrade the software to a previous release, the higher 64 bits of the sticky entry are not synchronized because the previous release does not support 128 bit sticky hash keys.

If the framed-ipv6-prefix and framed-ip attributes are present in the same request or response packet, the sticky entry is created based on the framed-ip.

Multiple framed-ipv6-prefixes within the same request or response are not supported.

Device Monitoring: Bandwidth, Total Active SSL Connections, and NAT Pool Utilization

ACE software version A5(2.1) generates a notification when the ACE resource usage exceeds or fails to meet the configured threshold. It allows the ACE to monitor resources and notify the Network Manager (NM) when the resources reach the maximum/minimum threshold. The notifications to the NM are sent through SNMP traps.

The ACE generates notifications when the usage of the following resources exceed or fail to meet one of the following specified threshold limits:

Bandwidth and Active SSL Connections

NAT Pool Utilization

Bandwidth and Active SSL Connections

You can configure the ACE to issue SNMP traps and syslog messages when resource usage by the ACE or a specific context breaches the specified thresholds (high, low, and watermark) for the following monitored resources:

Bandwidth

Active SSL Connections

Related CLI Configuration and Changes

ACE software version A5(2.1) provides the new CLI command resource usage-threshold to configure the resource usage threshold limits at both system level and context level. This command is configured in the configuration mode.


Note The threshold limits for the resource usage (at system level and context level) can be configured using the CLI only. ACE software version A5(2.1) does not support XML configuration for threshold limits for resource usage.


The resource usage-threshold command is used to configure the resource usage threshold. The following example shows how to use the resource usage-threshold command:

switch/Admin(config)# resource usage-threshold 
switch/Admin(config-resrc-thres)# 
 
   

The system-level command determines the resource usage threshold configured at the system level. The syntax of the system-level command is as follows:

system-level {bandwidth | active-ssl-conn} high threshold_value low threshold_value watermark threshold_value

The following example shows how to use the system-level command to configure threshold for bandwidth and active SSL connections:

switch/Admin(config-resrc-thres)# system-level bandwidth high 90 low 50 watermark 88
switch/Admin(config-resrc-thres)# system-level active-ssl-conn high 98 watermark 95
 
   

The keywords, arguments, and options in the above commands are as follows:

system-level—Specifies the parameters configured at the system level and can only be configured by the administrator.

bandwidth—Configures the usage threshold for resource bandwidth and can be configured at the system level.

active-ssl-conn—Configures the usage threshold for active SSL connections at the system level and can be configured by the administrator only.

high—Indicates the highest value of the threshold defined. This value is configured as a percentage between 1 to 100 and is represented as the highest percentage of the maximum number of allocated resources. The ACE sends a notification/trap to the NM when the current resource usage exceeds the highest threshold value.

low—Indicates the lowest value of the threshold defined. This value is configured as a percentage between 1 to 100 and is represented as the lowest percentage of the minimum number of allocated resources. The ACE sends a notification/trap to the NM when the current resource usage is less than the specified lowest threshold value.

watermark—Indicates the defined watermark threshold. A watermark is configured as a percentage between 1 to 100 and is represented as the percentage of the maximum and minimum allocated resource. It is used to reset the high/low traps and to optimize the number of traps that are sent.

Watermark Calculation

The high watermark value is calculated as follows:

high watermark value = watermark * maximum allocation/100
 
   

The ACE sends a "Falling Watermark" notification when the current usage is below the high watermark value. See the "Related SNMP Trap Configuration and Changes" section for details.

The low watermark value is calculated as follows:

low watermark value = watermark * minimum allocation/100
 
   

The ACE sends a "Rising Watermark" notification when the current usage exceeds the low watermark value. See the "Related SNMP Trap Configuration and Changes" section for details.

The resource usage threshold parameters are configured within the following range:
1 <= low < watermark < high <= 100


Note Based on the current statistics, the ACE resends notifications for the following conditions:

Create a new contact

Create/modify/attach resource-class to a context

Modify resource-usage-threshold configuration

Related SNMP Trap Configuration and Changes

SNMP notification traps are system alerts that ACE generates when the resource usage exceeds or fails to meet the specified threshold. For background information about enabling SNMP notifications, see the "Enabling SNMP Notifications" section in the Administration Guide vA5(1.0), Cisco ACE Application Control Engine.

The following commands are used to configure SNMP traps at context and system levels:

switch/Admin(config)# snmp-server enable traps rate-limit system-level bandwidth
switch/Admin(config)# snmp-server enable traps rate-limit system-level active-ssl-conn
switch/Admin(config)# snmp-server enable traps rate-limit bandwidth

The following objects are defined to generate a notification when the current usage exceeds or fails to meet the specified threshold:

clrResourceRateLimitReachedRev1—defined in CISCO-L4L7MODULE-RESOURCE-LIMIT-MIB.my

Table 1 lists the subobjects included in the notification.

Table 1 Notification Objects for clrResourceRateLimitReachedNotif

Object
Description

crlRateLimitResourceMin

Displays the minimum value of the configured threshold

crlRateLimitResourceMax

Displays the maximum value of the configured threshold

crlRateLimitResourceCurrentUsage

Displays the current usage of the resource

crlNotifType

Identifies which one of the following traps is sent:

risingHighThresh(1)—Sent when the current usage exceeds the configured high threshold value

fallingMinThresh(2)—Sent when the current usage fails to meet the configured low threshold value

fallingWatermarkThresh(3)—Sent when the current usage exceeds the configured high watermark value

risingWatermarkThresh(4)—Sent when the current usage fails to meet the configured low watermark value

crlNotifContextName

Displays the context name

crlNotifMaxThresholdPcnt

Displays the configured high threshold value as a percentage

crlNotifMinThresholdPcnt

Displays the configured low threshold value as a percentage

crlNotifCurrentUsagePcnt

Displays the current usage of the specified resource

crlNotifContextorSystem

Notifies whether the trap was generated at the Context Level or System Level

crlNotifWatermarkPcnt

Displays the configured watermark threshold value as a percentage


cspSSLResourceLimitReached—Defined in -SSL-PROXY-MIB.my and notifies when the active SSL connections usage exceeds the configured threshold values. Because SSL connections do not have a lower limit, the notifications related to the low resource usage are not sent.

Table 2 lists the subobjects included in the notification.

 
   

Table 2 Notification Objects for cspSSLResourceLimitReached

Object
Description

cspSslTrapType

Identifies which one of the following traps is sent:

risingHighThresh(1)—Displays when the current usage exceeds the configured threshold value

fallingHighThresh(3)—Displays when the current usage fails to meet the configured high watermark value

cspSslMaxConn

Displays the maximum allowed connections at system level

cspSslActiveConn

Displays the active SSL connections

cspSslConfigMaxConnPcnt

Displays the highest threshold value as a percentage

cspSslActiveConnPcnt

Displays the current usage of the resource as a percentage

cspSslConfigWatermarkPcnt

Displays the configured watermark threshold value as a percentage

 
   

For more information about the SNMP notification (traps) supported by the ACE, see the "ACE SNMP Notifications (Traps)" section in the Administration Guide vA5(1.0), Cisco ACE Application Control Engine.

NAT Pool Utilization

As a part of the show nat-fabric CLI command, the nat-pool-utilization parameter has been added in the ACE software version A5(2.1) to provide information on Network Address Translation (NAT) pool utilization. The NAT pool utilization information in the show command output has the following details: User Pool ID, NP Utilization, Lower/Upper Ip Addresses fields, and Context name.

Enter the following command to display the NAT pool utilization:

switch/Admin# show nat-fabric nat-pool-utilization
 
   

The following example shows how to use the show nat-fabric command to determine NAT pool utilization:

switch/Admin# show nat-fabric nat-pool-utilization
------------------------------------------------------------------

Pool ID
NP
Total/Usage/Utiliz. (%)
LowerIP/ 
UpperIP
 
        
Context
11
1
11/
0/
0
1.1.1.11 
1.1.1.21
 
        
C1
11
1
11/
0/
0
1.1.1.11 
1.1.1.21
 
        
Admin
22
1
11/
0/
0
1.1.1.22 
1.1.1.32
 
        
Admin
22
1
11/
0/
0
1.1.1.22 
1.1.1.32
 
        
C1


Note ACE software version A5(2.1) does not determine Port Address Translation (PAT) utilization.


New Software Features in Version A5(2.0)

This section describes the new features associated with ACE module software Version A5(2.0). The information presented in this section builds on the information available in the documentation set for ACE software Version A5(1.0), which you can find at the following URLs:

ACE configuration documentation doc set:

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_installation_and_configuration_guides_list.html

ACE command reference:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA5_1_0/command/reference/ACE_cr.html

Software version A5(2.0) provides the following new features:

Buddy Sticky Groups that Enable Persistence Across Multiple Server Farms

Support for Static NAT IPv4-to-IPv6 and IPv6-to-IPv4 Translation

Support for DNS IPv4-to-IPv6 and IPv6-to-IPv4 Load Balancing with Inspection

Maintaining a Full Proxy Connection During a TCP Handshake Mismatch

Support for a Wildcard KAL-AP GSS IP Address

SSL Probe Configuration Option for Ignoring the Certificate Expiration Date

Support for Additional Syslog Logging Hosts

Support for SSL Session ID Stickiness

Support for the ACE No Payload Encryption Software Version

Support for Creation of RDP Parameter Maps

Ability to Enable Regular Expression Download Optimization

Extended Range of Supported Characters in a URL

Configuring an SNMP Peer Engine ID for the Standby ACEConfiguring an SNMP User Authentication Password for the Standby ACE

Ability for the ACE to Accept a User Account with an Expired Date

Addressing SSL Certificates With a Subject or Issuer That is Greater Than 256 Bytes

ACE Probes Use the Interface MAC Address as the Source MAC Address

Buddy Sticky Groups that Enable Persistence Across Multiple Server Farms

ACE software version A5(2.0) allows you to create buddy sticky groups that enable persistence to a real server or real server group across multiple server farms. Prior software releases allow you to configure stickiness within a single server farm only using sticky groups.

You use the buddy sticky group feature for the following applications:

One-to-one association—Sticks the client to the same physical server instances in two different server farms (see the "One-to-One Association Application Example" section).

Asymmetric association—Sticks a client to a real server that is configured on different server farms even when the client comes back with a non-HTTP request or different HTTP header (see the "Asymmetric Association Application Example" section).

Many-to-one association—Sticks multiple, first-tier real servers to one real server in a second tier that contains fewer servers (see the "Many-to-One Association Application Example" section).


Note The ACE buddy sticky group feature does not support the one-to-many application.


To use the buddy group feature, you perform the following steps while configuring the ACE for load balancing:

1. Create real server buddy sticky groups when specifying the real servers in a server farm.

You make a real server a member of a real server buddy group by using the new buddy command in the server farm host real server configuration mode. The command syntax is as follows:

buddy group_name

where group_name is the name of a new or existing real server buddy sticky group. Enter 1 to 64 alphanumeric characters.

Example
host1/admin(config)# serverfarm sfarm1
host1/admin(config-sfarm-host)# rserver rserv12
host1/admin(config-sfarm-host-rs)# buddy blue
 
   

2. Create sticky server farm buddy groups when specifying the server farms in a sticky group.

You make a sticky server farm a member of a buddy sticky group by using the new member command in sticky configuration mode. The command syntax is as follows:

member group_name

where group_name is the name of a new or existing server farm buddy sticky group. Enter 1 to 64 alphanumeric characters.

Example
host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-cart
host1/admin(config-sticky-ip)# serverfarm http
host1/admin(config-sticky-ip)# member alpha
 
   

This section includes the following topics:

Guidelines and Restrictions

One-to-One Association Application Example

Asymmetric Association Application Example

Many-to-One Association Application Example

Displaying Buddy Sticky Group Information

Guidelines and Restrictions

When two sticky groups with different timeout values are buddied together, the ACE uses the shortest timeout value for the buddy group.

Sticky groups to be buddied together must of the same type, such as all IP-sticky, all http-cookie, and so forth. The ACE does not support different types of sticky groups buddied together.

When two sticky groups are buddied together and one of them is configured for timeout active connections, the member group is also configured for timeout active connections.

When two sticky groups are configured with different IP netmask (IPv4) or prefix-length (IPv6), the ACE uses the one with the most granular netmask or prefix-length.

When a static entry is created under a buddy sticky group, its behavior is unchanged and it sticks to the same real server configured regardless of the buddy group that real server is associated with.

Before you can configure a sticky group as a member, you must have a server farm configured under that sticky group and all the real servers that belong to that server farm have buddy group configured under them. This requirement prevents invalid configurations.

The ACE does not support configuring the following types of sticky groups as buddy sticky group members:

SSL

RTSP Header

The ACE supports PTMP sticky group such as SIP sticky; however, you must make sure that the configuration is the same across both sticky groups for the buddy sticky group feature to work.

For real server backup applications:

We recommend only 1 level of backup-rserver with buddy sticky.

If you add a buddy group to the primary real server, the backup server inherits this buddy group. However, if you remove the buddy group from the primary real server, the buddy group is not removed from the backup real server and vice versa.

You can display information related to buddy sticky group configurations (see the "Displaying Buddy Sticky Group Information" section).

One-to-One Association Application Example

In a one-to-one buddy sticky group association, you create a buddy sticky group that sticks the client to the same physical server instances in two different server farms. In the network example shown in Figure 2, the ACE is configured with the following server farms, their associated real servers, and the buddy sticky groups that group both items:

Server Farm
Server Farm
Buddy Member Group
Real Server
Real Server
Buddy Group

http
(for HTTP requests)

alpha

1nx1:192.168.1.11:80

blue

1nx2:192.168.1.12:80

red

https
(for HTTPS requests)

alpha

1nx1:192.168.1.11:443

blue

1nx2:192.168.1.12:443

red


Figure 2 Buddy Sticky Groups: One-to-One Association

The ACE is configured to load balance HTTP requests to server farm http using either real server 1nx1:192.168.1.11:80 or 1nx2:192.168.1.12:80. The ACE is also configured to load balance HTTPS requests using server farm https and either real server 1nx1:192.168.1.11:443 or 1nx2:192.168.1.12:443. The buddy groups allow the ACE to stick a client to the same real server (for example, 1nx1) while building a shopping cart using HTTP requests and then checking out using HTTPS.

In this example, the client hits VIP 172.16.1.100, destination port 80 with an HTTP request to begin to build a shopping cart. The ACE load balances the request to server farm http, real server 1nx1:192.168.1.11:80 and creates a sticky entry based on the corresponding sticky group (for example, source IP address) that sticks the client to the real server while the client builds their shopping cart. When the client moves to the secured connection (port 443) for checkout, it hits the VIP with destination port 443 and the ACE sends the client to server farm https. The ACE finds an existing sticky entry with real server Inx1:192.168.1.11:80 and directs the client to 1nx1:192.168.1.11:443 because the two real servers are buddied together under the blue buddy group.

CLI Sample Configuration

The following example configuration applies to Figure 2 and shows the buddy group-related values in bold text:

host1/admin(config)# serverfarm http
host1/admin(config-sfarm-host)# rserver lnx1
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# rserver lnx2
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# serverfarm https
host1/admin(config-sfarm-host)# rserver lnx1 443
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# rserver lnx2 443
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-cart
host1/admin(config-sticky-ip)# serverfarm http
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-credit
host1/admin(config-sticky-ip)# serverfarm https
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# class-map cart-vip
host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq www
host1/admin(config-cmap)# exit
 
   
host1/admin(config)# class-map checkout-vip
host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq https
host1/admin(config-cmap)# exit
 
   
host1/admin(config)# policy-map type loadbalance http first-match cart-lb
host1/admin(config-pmap-lb)# class class-default
host1/admin(config-pmap-lb-c)# sticky-serverfarm stick-cart
host1/admin(config-pmap-lb-c)# exit
host1/admin(config-pmap-lb)# exit
 
   
host1/admin(config)# policy-map type loadbalance http first-match checkout-lb
host1/admin(config-pmap-lb)# class class-default
host1/admin(config-pmap-lb-c)# sticky-serverfarm stick-credit
host1/admin(config-pmap-lb-c)# exit
host1/admin(config-pmap-lb)# exit
 
   
host1/admin(config)# policy-map multi-match shopping-cart
host1/admin(config-pmap)# class cart-vip
host1/admin(config-pmap-c)# loadbalance vip inservice
host1/admin(config-pmap-c)# loadbalance policy cart-lb
host1/admin(config-pmap-c)# exit
host1/admin(config-pmap)# exit
 
   
host1/admin(config-pmap)# class checkout-vip
host1/admin(config-pmap-c)# loadbalance vip inservice
host1/admin(config-pmap-c)# loadbalance policy checkout-lb
 
   

Asymmetric Association Application Example

In an asymmetric buddy sticky group association, you create a buddy sticky group that sticks all Layer 7 traffic from a client to a specific real server even when some of the traffic does not match the Layer 7 class map.

In the network example shown in Figure 3, the ACE is configured to include the following server farms, their associated real servers, and assigned real server buddy sticky groups:

Server Farm
Server Farm
Buddy Member Group
Real Server
Real Server
Buddy Group

foo bar

alpha

1nx1

blue

1nx2

red

foo

alpha

1nx1

blue

bar

alpha

1nx2

red


Figure 3 Buddy Sticky Groups: Asymmetric Association

The ACE is configured to send client traffic with Layer 3 matches to server farm foobar, which contains real servers that are also configured on server farms foo and bar. The ACE load balances the client traffic to one of the real servers based on Layer 7 class map matches. By defining buddy sticky groups, the ACE is also able to stick non-matching client traffic to the same real server.

In this example, the client sends traffic with Layer 3 matches that the ACE directs and sticks (using ip sticky) to server farm foobar. The ACE uses a Layer 7 class map to check for HTTP URL and if present, sends the traffic to server farm foo and sticks the client traffic to that server using sticky that is based on the source IP address. Using a buddy stick group, the ACE uses the sticky entry to send any other traffic type from the client to the same real server. For example, if the ACE sticks the client HTTP traffic to server farm foo:real server lnx1 based on a Layer 7 class map match, the buddy stick group allows the ACE to send non-HTTP traffic from the client to the same real server.

CLI Sample Configuration

The following example configuration applies to Figure 3 and shows the buddy group-related values in bold text:

host1/admin(config)# serverfarm foo
host1/admin(config-sfarm-host)# rserver lnx1
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# serverfarm bar
host1/admin(config-sfarm-host)# rserver lnx2
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# serverfarm foobar
host1/admin(config-sfarm-host)# rserver lnx1
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# rserver lnx2
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-foo
host1/admin(config-sticky-ip)# serverfarm foo
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-bar
host1/admin(config-sticky-ip)# serverfarm bar
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-foobar
host1/admin(config-sticky-ip)# serverfarm foobar
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# class-map app-vip
host1/admin(config-cmap)# match virtual-address 172.16.1.100 any
host1/admin(config-cmap)# exit
 
   
host1/admin(config)# class-map type http loadbalance match-all app-foo
host1/admin(config-cmap)# match http url /app-foo/.*
host1/admin(config-cmap)# exit
 
   
host1/admin(config)# class-map type http loadbalance match-all app-bar
host1/admin(config-cmap)# match http url /app-bar/.*
host1/admin(config-cmap)# exit
 
   
host1/admin(config)# policy-map type loadbalance http first-match slb
host1/admin(config-pmap-lb)# class app-foo
host1/admin(config-pmap-lb-c)# sticky-serverfarm foo
host1/admin(config-pmap-lb-c)# exit
host1/admin(config-pmap-lb)# class app-bar
host1/admin(config-pmap-lb-c)# sticky-serverfarm bar
host1/admin(config-pmap-lb-c)# exit
host1/admin(config-pmap-lb)# class class-default
host1/admin(config-pmap-lb-c)# sticky-serverfarm foobar
 
   

Many-to-One Association Application Example

In a many-to-one buddy sticky group association, you create a buddy sticky group that sticks a group of real servers to a specific real server, which is useful when clients are load balanced to a first-tier server farm containing many real servers and are then directed to a second-tier server farm that contains fewer real servers. In this type of application, you create buddy sticky groups that stick each first-tier real server group to a specific second-tier real server.

In the network example shown in Figure 4, the ACE is configured with the following server farms, their associated real servers, and assigned real server buddy groups:

Server Farm
Server Farm
Buddy Member Group
Real Server
Real Server
Buddy Group

web (first tier)

alpha

1nx1:192.168.1.11:80

blue

1nx2:192.168.1.12:80

blue

1nx3:192.168.1.13:80

red

1nx4:192.168.1.14:80

red

app (second tier)

alpha

db1:192.168.1.21:123

blue

db1:192.168.1.22:123

red


Figure 4 Buddy Sticky Groups: Many-to-One Association

The buddy sticky groups blue and red divide the first-tier real servers into groups and then sticks each of these groups to a specific second-tier real server.

In this example, when the ACE load balances clients to either real server 1nx1 or 1nx2 in the server farm web, the clients are directed only to real server db1 when they are ready to move to the server farm app. Notice also that clients that the ACE load balances to 1nx3 and 1nx4 are directed only to real server db2 when they are ready to move to the server farm app.

CLI Sample Configuration

The following example configuration applies to Figure 4 and shows the buddy group-related values in bold text:

host1/admin(config)# serverfarm web 
host1/admin(config-sfarm-host)# rserver lnx1 80
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# inservice
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# rserver lnx2 80
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# inservice
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# rserver lnx3 80
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# inservice
host1/admin(config-sfarm-host)# rserver lnx4 80
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# inservice
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# serverfarm app
host1/admin(config-sfarm-host)# rserver db1
host1/admin(config-sfarm-host-rs)# buddy blue
host1/admin(config-sfarm-host-rs)# inservice
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# rserver db2
host1/admin(config-sfarm-host-rs)# buddy red
host1/admin(config-sfarm-host-rs)# inservice
host1/admin(config-sfarm-host-rs)# exit
host1/admin(config-sfarm-host)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address source web
host1/admin(config-sticky-ip)# serverfarm web
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# sticky ip-netmask 255.255.255.255 address source db
host1/admin(config-sticky-ip)# serverfarm db
host1/admin(config-sticky-ip)# member alpha
host1/admin(config-sticky-ip)# exit
 
   
host1/admin(config)# class-map web
host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq 80
host1/admin(config-cmap)# exit
host1/admin(config)# class-map db
host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq 81
host1/admin(config-cmap)# exit
 
   
host1/admin(config)# policy-map type loadbalance http first-match web
host1/admin(config-pmap-lb)# class class-default
host1/admin(config-pmap-lb-c)# sticky-serverfarm web
host1/admin(config-pmap-lb-c)# exit
host1/admin(config-pmap-lb)# exit
 
   
host1/admin(config)# policy-map type loadbalance http first-match db
host1/admin(config-pmap-lb)# class class-default
host1/admin(config-pmap-lb-c)# sticky-serverfarm db
host1/admin(config-pmap-lb-c)# exit
host1/admin(config-pmap-lb)# exit
 
   
host1/admin(config)# policy-map multi-match web-db
host1/admin(config-pmap)# class web
host1/admin(config-pmap-c)# loadbalance vip inservice
host1/admin(config-pmap-c)# loadbalance policy web
host1/admin(config-pmap-c)# exit
host1/admin(config-pmap)# class db
host1/admin(config-pmap-c)# loadbalance vip inservice
host1/admin(config-pmap-c)# loadbalance policy db
 
   

Displaying Buddy Sticky Group Information

The following CLI show commands have been modified to include buddy sticky group information:

show sticky database—Command now includes the buddy keyword, which displays buddy sticky entries separately from sticky entries.

Example

host1/Admin# show sticky database buddy
member group : red
type         : IP    
timeout      : 720           timeout-activeconns : TRUE 
  sticky-entry          rserver-instance         time-to-expire flags   
  ---------------------+-----------------+--------------+-------+
  250232353865662720    rs1:0                        43196          
Total Sticky Entries: 1
 
   

show rserver detail—Command output now includes the buddy group associated with the real server in a particular server farm.

Example

switch/Admin# show rserver detail 
 
   
 rserver              : rs1, type: HOST
 state                : OPERATIONAL (verified by arp response)
 description          : -
 max-conns            : -         ,  out-of-rotation count  : -
 min-conns            : -         
 conn-rate-limit      : -         ,  out-of-rotation count  : -
 bandwidth-rate-limit : -         ,  out-of-rotation count  : -
 weight               : 8
 ---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total               
   ---+---------------------+------+------------+----------+--------------------
   serverfarm: sf1
       10.10.10.2:0           8      OPERATIONAL  0          2                   
         max-conns            : -         ,  out-of-rotation count  : -
         min-conns            : -         
         conn-rate-limit      : -         ,  out-of-rotation count  : -
         bandwidth-rate-limit : -         ,  out-of-rotation count  : -
         total conn-failures  : 0
         buddy group 		: blue
 
   
   serverfarm: sf2
       10.10.10.2:0           8      OPERATIONAL  0          0                   
         max-conns            : -         ,  out-of-rotation count  : -
         min-conns            : -         
         conn-rate-limit      : -         ,  out-of-rotation count  : -
         bandwidth-rate-limit : -         ,  out-of-rotation count  : -
         total conn-failures  : 0
         buddy group 		: red 
 
   

show serverfarm detail—Command output now includes the buddy group associated with the real servers in the server farm.

Example

switch/Admin# show serverfarm detail 
 serverfarm     : sf1, type: HOST
 total rservers : 5
 active rservers: 5
 description    : -
 state          : ACTIVE
 predictor      : ROUNDROBIN
 failaction     : -
 back-inservice    : 0
 partial-threshold : 0
 num times failover       : 1
 num times back inservice : 4
 total conn-dropcount : 0
 ---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total      failures 
   ---+---------------------+------+------------+----------+----------+---------
   rserver: rs1
       10.10.10.2:0           8      OPERATIONAL  0          2          0
         max-conns            : -         , out-of-rotation count : -
         min-conns            : -         
         conn-rate-limit      : -         , out-of-rotation count : -
         bandwidth-rate-limit : -         , out-of-rotation count : -
         retcode out-of-rotation count : -
         buddy group 	  : blue
 
   
   rserver: rs2
       10.10.10.3:0           8      OPERATIONAL  0          0          0
         max-conns            : -         , out-of-rotation count : -
         min-conns            : -         
         conn-rate-limit      : -         , out-of-rotation count : -
         bandwidth-rate-limit : -         , out-of-rotation count : -
         retcode out-of-rotation count : -
         buddy group 		 : red
 
   

show stats sticky—Command output now includes the following attribute that shows the total number of sticky entries that are part of any buddy group:

Total active buddy sticky entries

Example

host1/Admin# show stats sticky 
+------------------------------------------+
+----------- Sticky statistics ------------+
+------------------------------------------+
 Total sticky entries reused                           : 0
 prior to expiry
 Total active sticky entries                           : 1
 Total active reverse sticky entries                   : 0
 Total active buddy sticky entries                     : 1
 Total active sticky conns                             : 0
 Total static sticky entries                           : 0
 Total sticky entries from Global Pool                 : 1
 Total insertion failures due to lack of resources     : 0
 
   

show buddy-group—New command that displays the list of buddy groups configured in the virtual context. The command syntax is as follows:

show buddy-group [group]

The optional group argument displays all server farms and associated real servers that belong to the specified buddy group.

Example

host1/Admin# show buddy-group    
Buddy-Grp         Rserver         Port       Serverfarm
 +-----------------+---------------+----------+---------------
  blue
                     rs1-v4         0          sf-v4-1
 
   
                     rs5-v4         0          sf-v4-1
 
   
                     r1             0          sf-v6-1
 
   
                     r5-backup      0          sf-v6-1
 
   
                     r3             0          sf-v6-2
 
   
                     rs1-v4         0          sf1-main
 
   
                     rs-main        0          sf2-main
 
   
                     rs1-v4         0          sf2-nobuddy 
 
   
 
   

Support for Static NAT IPv4-to-IPv6 and IPv6-to-IPv4 Translation

ACE software version A5(2.0) allows you to configure mixed-mode static network address translation (NAT) configurations in which the connections between the client and server use a mix of IPv4 and IPv6 addresses as follows:

IPv4 server or source address to an IPv6 address

IPv6 server or source address to an IPv4 address

These configuration options are in addition to the same-mode static NAT mapping options (IPv4 to IPv4 and IPv6 to IPv6) available with previous software releases, which do not support mixed-mode static NAT configurations.

The three static NAT applications for mixed mode are as follows:

Static Destination NAT and Dynamic Source NAT— Uses a combination of static destination NAT and dynamic source NAT for mapping a mixed mode application in which the client uses IPv4 and the application server uses IPv6 (see the "Static Destination NAT and Dynamic Source NAT Mixed-Mode Application" section).

Static Destination NAT and Static Source NAT—Use static NAT only for mapping a mixed mode application in which the client uses IPv4 and the application server uses IPv6 (see the "Static Destination NAT and Static Source NAT Mixed-Mode Application" section).

Static NAT for a Subnet—Use static NAT to map a set of private IP addresses to a set of global IP addresses with a subnet (also referred to as the many-to-many application).

Guidelines and Restrictions

For details about configuring static NAT, see the "Configuring Static NAT and Static Port Redirection as a Policy Action" section in the Security Guide vA5(1.0), Cisco ACE Application Control Engine Guide. The information that the guide provides for configuring same-mode static NAT mapping can be used for mixed-mode configurations.

This section includes the following topics:

Static Destination NAT and Dynamic Source NAT Mixed-Mode Application

Static Destination NAT and Static Source NAT Mixed-Mode Application

Static NAT for Subnets

Static Destination NAT and Dynamic Source NAT Mixed-Mode Application

This section describes how to use a combination of static destination NAT and dynamic source NAT for mapping a mixed mode application in which the client uses IPv4 and the application server uses IPv6 (see Figure 5). In this application, static destination NAT maps the server IPv6 source address to an IPv4 address and dynamic NAT translates the client IPv4 address to an IPv6 address.

Figure 5 Mixed Mode Static Destination NAT and Dynamic Source NAT Application

For this application, the two types of NAT are used as follows:

Static Destination NAT: Maps S6 (IPv6) to S'4 (IPv4) in client side VLAN

Dynamic Source NAT: Maps C'6 (IPv4) to S6 (IPv6) after NAT maps C4 to C'6

Example

The following example shows how to configure the ACE for the application described in this section:

access-list acl-01 line 8 extended permit ip any any
class-map match-any ANY
  2 match any
 
   
class-map match-all nat
  2 match source-address 2001:3008::1:1/128 	-->Server IP address
 
   
policy-map multi-match doSrcNatANY
  class ANY 	-->Src NAT any traffic hitting client VLAN
    nat dynamic 10 vlan 3008
 
   
policy-map multi-match static_nat
  class nat 	-->Matching server IPv6
    nat static 10.8.2.1 netmask 255.255.255.255 vlan 2008	-->Mapped to IPv4 IP
	hosted on client VLAN 2008 
 
   
access-group input acl-01
 
   
interface vlan 2008
  ip address 10.8.0.3 255.255.0.0
  alias 10.8.0.1 255.255.0.0
  peer ip address 10.8.0.2 255.255.0.0
  service-policy input doSrcNatAny -->Do src NAT on all traffic hitting the client VLAN
  no shutdown
 
   
interface vlan 3008
  ipv6 enable
  ip address 2001:3008::1/100
  ip address 192.168.0.3 255.255.0.0
  nat-pool 10 2001:3008::3:1 2001:3008::3:1/100 -->Choose one of the IP from the pool
  service-policy input static_nat	-->Static NAT applied on egress/server side VLAN
  no shutdown
 
   

Static Destination NAT and Static Source NAT Mixed-Mode Application

This section describes how to use static NAT for mapping a mixed mode application in which the client uses IPv4 and the application server uses IPv6 (see Figure 6). In this application, static destination NAT maps the server IPv6 source address to an IPv4 address and static source NAT translates the client IPv4 address to an IPv6 address.

Figure 6 Mixed-Mode Static NAT Application

For this application, static NAT is used as follows:

Static Destination NAT: Maps S6 (IPv6) to S'4 (IPv4) in client side VLAN

Static Source NAT: Maps C'6 (IPv4) to S6 (IPv6) after NAT maps C4 to C'6

Example

The following example shows how to configure the ACE for the application described in this section:

class-map match-all src_server_s6
  2 match source-address 2001:3017::1:1
class-map match-all src_client_c4
  2 match source-address 10.17.1.2 255.255.255.255
 
   
 
   
policy-map multi-match dst_nat_s6_static
  class src_server_s6
    nat static 10.17.2.1 netmask 255.255.255.255 vlan 2017
Policy-map multi-match src_nat_s4_static
  class src_client_c4
    nat static 2001:3017:2017::1 vlan 3017
 
   
interface vlan 2017
  ip address 10.17.0.2 255.255.0.0
  service-policy input src_nat_s4_static
  no shutdown
 
   
interface vlan 3017
  ipv6 enable
  ip address 2002::1e11:2/112
  ip address 192.168.0.2 255.255.0.0
  service-policy input dst_nat_s6_static
  no shutdown
 
   

Static NAT for Subnets

This section describes how to use static NAT to map a set of private IP addresses to a set of global IP addresses using a subnet, which you can do in mixed mode or non-mixed mode.

This static NAT application takes the host portion of the NAT IP address and appends it to the server host portion. For example, if NAT IP address 10.1.1.0 is mapped to the server host 192.168.2.0, then client 10.1.1.10 is sent to the server host as 192.168.2.10.

Guidelines and Restrictions

In a mixed mode application, the prefix length and IPv4 netmask must match. For example, if you configure the IPv4 netmask as 255.255.255.0 /24, then the IPv6 prefix length must be 120. The last octet (8 bits) is taken as the host portion for network address translation.

Example

The following example shows how to configure the ACE so that client 20.17.1.1 connects to mapped IP address 20.17.2.5 and is then translated to the destination as 2001:3017::1:5 (5 is derived from the NAT IP address):

class-map match-all src_server_s6 
  2 match source-address 2001:3017::1:0/120 
class-map match-all src_client_c4 
  2 match source-address 20.17.1.0 255.255.255.0 
 
policy-map multi-match dst_nat_s6_static 
  class src_server_s6 
    nat static 20.17.2.1 netmask 255.255.255.0 vlan 2017
Policy-map multi-match src_nat_s4_static 
  class src_client_c4 
    nat static 2001:3017:2017::0/120  vlan 3017
 
interface vlan 2017
  ip address 20.17.0.2 255.255.0.0
  service-policy input src_nat_s4_static 
  no shutdown
 
   
interface vlan 3017
  ipv6 enable
  ip address 2002::1e11:2/112
  ip address 30.17.0.2 255.255.0.0
  service-policy input dst_nat_s6_static 
  no shutdown
 
   

Support for DNS IPv4-to-IPv6 and IPv6-to-IPv4 Load Balancing with Inspection

ACE software version A5(2.0) supports Domain Name System (DNS) inspection when using mixed-mode dynamic source network address translation (NAT), which performs NAT using the combinations of IPv4 and IPv6 connection types:

IPv4 client connects to a IPv4 VIP and is load balanced to a IPv6 real server

IPv6 client connects to a IPv6 VIP and is load balanced to a IPv4 real server

In both cases, the ACE translates the client address to an address in the NAT pool that matches the real server type and translates the VIP to the real server address.

Previous software releases support DNS inspection only when using same-mode dynamic source NAT in which NAT is performed on applications that use either IPv4 or IPv6 for all connections.

Guidelines and Restrictions

ACE software version A5(2.0) does not support a static NAT configuration for a DNS payload translation that requires a DNS Record type conversion, which is the process of converting an A record type to AAAA or AAAA to A. Because DNS record type conversion is not supported, the following related items are also not supported:

Record type conversion, which is required for translating an IPv4 address to IPv6 and IPv6 to IPv4 in the DNS payload.


Note ACE software version A5(2.0) does support static NAT translations of the same type (IPv4 to IPv4 or IPv6 to IPv6) in the DNS payload.


DNS64 because DNS record type conversion is required.

For details about configuring static NAT, see the "Configuring Dynamic NAT and PAT" section in the Security Guide vA5(1.0), Cisco ACE Application Control Engine Guide. The information that the guide provides for configuring same-mode static NAT mapping can be used for mixed-mode configurations.

Example

The following example shows a mixed-mode dynamic source NAT configuration in which DNS inspection is enabled using the inspect dns command (shown in bold):

access-list acl-01 line 8 extended permit ip any any 
access-list acl-v6 line 8 extended permit ip anyv6 anyv6 
 
   
 
   
 
   
rserver host v4-rs-01
  ip address 10.10.1.1
  inservice
rserver host v4-rs-02
  ip address 10.10.1.2
  inservice
rserver host v4-rs-03
  ip address 10.10.1.3
  inservice
rserver host v4-rs-04
  ip address 10.10.1.4
  inservice
rserver host v6-rs-01
  ip address 2002::1e11:101
  inservice
rserver host v6-rs-02
  ip address 2002::1e11:102
  inservice
rserver host v6-rs-03
  ip address 2002::1e11:103
  inservice
rserver host v6-rs-04
  ip address 2002::1e11:104
  inservice
 
   
serverfarm host mixed-farm
  rserver v4-rs-01
    inservice
  rserver v6-rs-01
    inservice
serverfarm host v4-sf-01
  rserver v4-rs-01
    inservice
  rserver v4-rs-02
  rserver v4-rs-03
  rserver v4-rs-04
serverfarm host v6-sf-01
  rserver v6-rs-01
    inservice
  rserver v6-rs-02
  rserver v6-rs-03
  rserver v6-rs-04
 
   
class-map match-any v4-vip-traffic-01
  2 match virtual-address 172.16.2.1 udp eq domain
class-map match-any v4-vip-traffic-02
  2 match virtual-address 172.16.2.2 udp eq domain
class-map match-any v6-vip-traffic-01
  2 match virtual-address 2002::1411:201 udp eq domain
class-map match-any v6-vip-traffic-02
  2 match virtual-address 2002::1411:202 udp eq domain
 
   
policy-map type management first-match mgmt
  class class-default
    permit
policy-map type management first-match mgmt2
  class class-default-v6
    permit
 
   
policy-map type loadbalance first-match mixed-dns-pol
  class class-default
    serverfarm mixed-farm
policy-map type loadbalance first-match v4-dns-pol-01
  class class-default
    serverfarm v4-sf-01
policy-map type loadbalance first-match v6-dns-pol-01
  class class-default
    serverfarm v6-sf-01
 
   
policy-map multi-match v4-vip-pol-01
  class v4-vip-traffic-01
    loadbalance vip inservice
    loadbalance policy v4-dns-pol-01
    loadbalance vip icmp-reply
    inspect dns
policy-map multi-match v4_to_mixed-vip
  class v4-vip-traffic-02
    loadbalance vip inservice
    loadbalance policy mixed-dns-pol
    loadbalance vip icmp-reply
    nat dynamic 2 vlan 3017
    inspect dns
policy-map multi-match v6-vip-pol-01
  class v6-vip-traffic-01
    loadbalance vip inservice
    loadbalance policy v6-dns-pol-01
    loadbalance vip icmp-reply
    inspect dns
policy-map multi-match v6_to_mixed-vip
  class v6-vip-traffic-02
    loadbalance vip inservice
    loadbalance policy mixed-dns-pol
    loadbalance vip icmp-reply
    nat dynamic 1 vlan 3017
    inspect dns
 
   
service-policy input mgmt
service-policy input mgmt2
access-group input acl-01
access-group input acl-v6
 
   
interface vlan 2017
  ipv6 enable
  ip address 2002::1411:2/112
  alias 2002::1411:1/112
  peer ip address 2002::1411:3/112
  ip address 172.16.0.2 255.255.0.0
  alias 172.16.0.1 255.255.0.0
  peer ip address 172.16.0.3 255.255.0.0
  service-policy input v4-vip-pol-01
  service-policy input v6-vip-pol-01
  service-policy input v4_to_mixed-vip
  service-policy input v6_to_mixed-vip
  no shutdown
interface vlan 3017
  ipv6 enable
  ip address 2002::1e11:2/112
  alias 2002::1e11:1/112
  peer ip address 2002::1e11:3/112
  ip address 192.168.0.2 255.255.0.0
  alias 192.168.0.1 255.255.0.0
  peer ip address 192.168.0.3 255.255.0.0
  nat-pool 1 2002::1e11:a 2002::1e11:f/128 
  nat-pool 1 192.168.0.150 192.168.0.150 netmask 255.255.255.255
  nat-pool 2 2002::1e11:10 2002::1e11:15/128 
  nat-pool 2 192.168.0.160 192.168.0.160 netmask 255.255.255.255
  no shutdown
 
   

Maintaining a Full Proxy Connection During a TCP Handshake Mismatch

ACE software version A5(2.0) allows the ACE to splice together the client front-end and the server back-end connections when the ACE is proxying Layer 7 traffic flow and the negotiated front-end and back-end TCP handshakes do not match. Previous software releases do not have this option and drop connections in which the TCP handshakes do not match.

When the ACE is proxying Layer 7 flow, it completes the front-end TCP handshake before it initiates the back-end handshake. This process can cause issues for TCP options that are negotiated or specified during the TCP handshake. The ACE does provide the option of specifying the TCP handshake values in a connection parameter map but this method is not scalable as it needs to be defined per connection and it is difficult to predict these values as it requires significant coordination between the application, networking, and security teams. A mismatch in maximum segment size (MSS) and other TCP parameters results in slow or broken connections.

The parameter map type connection configuration mode command now includes the full-proxy-mss-mismatch command option that configures the ACE to force a connection to maintain full proxy when there is an MSS mismatch between the front-end and back-end connections.

When an MSS mismatch occurs, the ACE generates a syslog that provides information on why the ACE had to force a proxy connection due to an MSS mismatch. The ACE now also includes a counter that tracks the number of MSS mismatches, which you can display using the show np 1 me-stat -stcp command.

Guidelines and Restrictions

For details about using the CLI to create a parameter map for a TCP connection, see the "Creating a Connection Parameter Map for TCP/IP, UDP, and ICMP" section in the Security Guide vA5(1.0), Cisco ACE Application Control Engine.

Examples

The following example shows how to use the CLI to create a connection parameter map (TCP_MISMATCH) that enables the TCP handshake mismatch feature:

switch/admin(config)# parameter-map type connection TCP_MISMATCH

switch/admin(config-parammap-conn)# full-proxy-mss-mismatch

The following example shows how to use the show np 1 me-stat -stcp command to show how many MSS mismatches have occurred:

host1/admin# show np 1 me-stat -stcp
	TCP Statistics: (Current)
	--------------
	TCP RX Messages received:
	TCP TX Messages received: 
	.
	.
	.
	MSS mismatch counter:
 
   

Support for a Wildcard KAL-AP GSS IP Address

ACE software version A5(2.0) allows you to configure the ACE with a wildcard KAL-AP Cisco Global Site Selector (GSS) IP address (0.0.0.0) to establish a secure communications channel between the ACE and multiple GSS devices that use the same MD5 encryption secret. With previous software releases, you must create a separate KAL-AP for each GSS IP address even when all or a set of GSS devices in a cluster use the same MD5 encryption secret.

To enable secure KAL-AP, you configure the IP address to the GSS and the shared secret using the ip address command from the KAL-AP UDP configuration mode. Use the no form of this command to remove the IP address and the shared secret from the configuration.

ip address ip_address encryption md5 secret

no ip address ip_address

The arguments are as follows:

ip_address—GSS IP address. Enter the IP address using dotted-decimal notation (for example, 192.168.11.1). Use the 0.0.0.0 wildcard value when multiple GSS devices in a cluster use the same secret.

secret—Shared secret between the GSS and the ACE. Enter the shared secret as a case-sensitive string with no spaces and a maximum of 31 alphanumeric characters.

Guidelines and Restrictions

The ACE supports KAL-AP using IPv4 only.

Use the wildcard IP address when both of the following conditions exist:

All GSS devices in the cluster use a secure channel for a KAL-AP message exchange with the ACE. Do not use the wildcard IP address if any GSS in the cluster uses an insecure channel.

All or a set of GSS devices in the cluster use the same MD5 secret.


Note You can only use the wildcard VIP address for one set of GSS devices that use the same MD5 secret. You must configure all other GSS devices individually for KAL-AP.


When using the no form of the command to remove a KAL-AP IP address, using the wildcard IP address removes only those VIPs that use the secret associated with the wildcard value. KAL-AP IP addresses that were defined using a specific GSS IP addresses remain and must be removed individually.

For details about using the CLI to configure a secure KAL-AP, see the "Configuring Secure KAL-AP" section in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.

Examples

The following example shows how to configure a secure KAL-AP on the ACE using the wildcard IP address (0.0.0.0) for all GSS devices that use the secret "andromeda":

host1/admin(config)# kalap udp

host1/admin(config-kalap-udp)# ip address 0.0.0.0 encryption md5 secret andromeda

The following example shows how to configure a secure KAL-AP on the ACE using a specific GSS IP address (192.168.11.1):

host1/admin(config)# kalap udp

host1/admin(config-kalap-udp)# ip address 192.168.11.1 encryption md5 secret andromeda2

To disable the secure KAL-AP for all GSS devices that use the secret associated with the wildcard IP address (in this example, andromeda), enter:

host1/admin(config-kalap-udp)# no ip address 0.0.0.0

SSL Probe Configuration Option for Ignoring the Certificate Expiration Date

ACE software version A5(2.0) allows you to configure an SSL probe to ignore the certificate expiration date, which allows the ACE to establish the connection even when the SSL certificate has expired. Previous software releases do not provide the option to ignore the certificate expiration date.

The ssl https probe configuration mode command now includes the certificate- expiration ignore command option that configures the probe to ignore the SSL certificate expiration date.

The output of the show probe probe_name detail now includes information about the state of the certificate expiration ignore setting.

Guidelines and Restrictions

For more information about using the CLI to configure an SSL probe, see the "Configuring an HTTPS Probe" section in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.

Examples

The following example shows how to configure an SSL probe that ignores the certificate expiration date:

host1/admin(config)# probe https ssl_probe

host1/admin(config-probe-https)# ssl certificate-expiration ignore

The following example shows how to display the probe details, including the state of the certificate expiration ignore setting:

host1/admin# show ssl_probe detail

probe : ssl_probe

type : HTTPS

state : INACTIVE

description :

----------------------------------------------

port : 443 address : 0.0.0.0

addr type : - interval : 15 pass intvl : 60

pass count: 3 fail count: 3 recv timeout: 10

SSL version : All

SSL cipher : RSA_ANY

SSL certificate-check : Ignore

http method : GET

http url : /

conn termination : GRACEFUL

expect offset : 0 , open timeout : 1

regex cache-len : 0

expect regex : -

send data : -

------------------ probe results ------------------

associations ip-address port porttype probes failed passed health

------------ ----------------------+----+--------+------+------+------+------

Support for Additional Syslog Logging Hosts

ACE software version A5(2.0) allows you to specify up to four hosts (the syslog servers) to receive the syslog messages sent by the ACE. Previous software releases allow you to specify a maximum of two syslog servers.

To configure the ACE with a syslog server, you use the logging host command in configuration mode. To specify additional syslog servers, repeat the command for each server. To remove a syslog server, use the no form of the command.

Guidelines and Restrictions

On an ACE module, you can enable 256 servers only. That is, if there are four syslog servers in a context, then you can only configure 64 such contexts. You cannot a add a syslog server for the 65th context.

For more information about using the CLI to configure the ACE with syslog logging hosts, see the "Sending Syslog Messages to a Syslog Server" section in the System Message Guide vA5(1.0), Cisco ACE Application Control Engine.

Examples

The following example show how to use the CLI to configure the ACE with a syslog server:

host1/Admin(config)# logging host 192.168.10.1 tcp/1025 format emblem default-udp

The following example show how to use the CLI to remove a syslog server:

host1/Admin(config)# no logging host 192.168.10.1

Support for SSL Session ID Stickiness

ACE software version A5(2.0) allows you to configure SSL session ID stickiness using the new SSL sticky and HTTPS policy map features. Previous software releases require a more involved process to configure SSL session ID stickiness in which you configure a generic protocol-parsing policy and a sticky group of type layer-4-payload with attributes configured to locate the SSL session ID inside the payload.

To configure SSL session ID stickiness using ACE software version A5(2.0), the sticky command has been modified to include the ssl option and the policy-map type loadbalance command has been modified to include the https option. After creating the SSL sticky, you apply it to an HTTPS policy map.

This section includes the following topics:

Using the Modified sticky Command for SSL Session ID Stickiness

Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness

Using the Modified sticky Command for SSL Session ID Stickiness

The modified syntax of the sticky configuration mode command is as follows:

sticky {http-content | http-cookie | http-header | ip-netmask | layer4-payload | radius | rtsp-header | sip|header | ssl | v6-prefix} name

no sticky {http-content | http-cookie | http-header | ip-netmask | layer4-payload | radius | rtsp-header | sip|header | ssl | v6-prefix} name

The ssl keyword has been added for configuring a sticky that is based on the SSL session ID. When you enter this command, the prompt changes to the sticky SSL content configuration mode (config-sticky-content) where you use the commands listed in Table 3 to define the SSL sticky attributes.

Table 3 Sticky SSL Content Configuration Mode Commands 

Command
Description

length id_length

Specify the number of bytes in the SSL ID to parse. For the id_length argument, enter a value from 1 to 65535. The default is 32 bytes.

replicate sticky

Instructs the ACE to replicate SSL content sticky table entries on the standby ACE.

response sticky

Enables the sticky for response.

serverfarm server_farm

Specifies a server farm entry for the sticky group. For the argument, enter a unique server farm identifier using an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

static ssl-id ssl_id

Defines the static SSL session ID string. For the ssl_id argument, enter the SSL ID ASCII or hex string (for hex: \xstring). The maximum string length is 255 characters.

timeout {timeout | activeconns}

Configures the SSL sticky timeout as follows:

timeout—Specifies the number of minutes that the ACE remembers the last real server to which a client made a sticky connection. Enter a value from 1 to 65535. The default timeout value is 1440 minutes (24 hours).

activeconns—Specifies that sticky entries are timed out when the sticky timer expires even if there are active connections.


Guidelines and Restrictions

By default, the SSL sticky offset is set to 43 bytes and the begin pattern is set to \x20|\x00\xST.

To display the SSL sticky statistics, the show sticky database command now includes the ssl session_id keyword and argument options.

After creating the SSL sticky, you must apply it to an HTTPS policy map (see the "Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness" section).

For more information about using the CLI to configure stickiness, see the "Configuring Stickiness" chapter in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.

Examples

The following example shows to create an SSL sticky (SSL_STICKY) and configure its attributes:

host1/Admin(config)# sticky ssl SSL_STICKY
host1/Admin(config-sticky-ssl)# length 125
host1/Admin(config-sticky-ssl)# serverfarm SERVERFARM_SSL
host1/Admin(config-sticky-ssl)# timeout 720
 
   

The following example shows to remove an SSL sticky:

host1/Admin(config)# no sticky ssl SSL_STICKY
 
   
 
   

Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness

The modified syntax of the policy-map type loadbalance configuration mode command is as follows:

policy-map type loadbalance {first-match | generic | http | https | radius | rdp | rtsp | sip}

The https keyword has been added for configuring a policy map for a sticky that is based on the SSL session ID. The complete syntax for the command when using the https keyword is as follows:

policy-map type loadbalance https first-match map_name

where map_name is the policy map name. Enter an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

When you enter this command, the prompt changes to the policy map loadbalance HTTPS configuration mode (config-pmap-lb-https) where you use the following procedure to configure the policy map with the match condition and sticky server farm:

 
Command
Purpose

Step 1 

match name source-address

Example

host1/Admin(config-pmap-lb-https)# match HTTPS source-address

Specifies the source address as the inline match condition, which is the only inline match condition required for SSL session parsing.

Enter an unquoted text string with no spaces. The length of the inline match statement name plus the length of the policy map name with which it is associated cannot exceed a total maximum of 64 alphanumeric characters. For example, if the policy map name is L7_POLICY (nine characters), an inline match statement name under this policy cannot exceed 55 alphanumeric characters (64 - 9 = 55).

Step 2 

class class-default

Example

host1/Admin(config-pmap-lb-https)# class class-default

Enters the policy map load balancing HTTPS class configuration mode. The class-default is the only class option available because it is the only class required for SSL session parsing.

Step 3 

sticky-serverfarm sfarm_name

Example

host1/Admin(config-pmap-lb-https-c)# sticky-serverfarm SERVERFARM_SSL

Specifies the sticky server farm associated with the SSL sticky group (see the "Using the Modified sticky Command for SSL Session ID Stickiness" section).

Guidelines and Restrictions

For more information about using the CLI to create a policy map, see the "Configuring Traffic Policies for Server Load Balancing" chapter in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.

Examples

The following example shows how to configure an HTTPS policy map to include the server farm (SERVERFARM_SSL) associated with the SSL sticky (SSL_STICKY) created in the previous section:

host1/Admin(config)# policy-map type loadbalance https first-match PMAP_HTTPS
host1/Admin(config-pmap-lb-https)# match HTTPS source-address
host1/Admin(config-pmap-lb-https)# class class-default
host1/Admin(config-pmap-lb-https-c)# sticky-serverfarm SERVERFARM_SSL
 
   

Support for the ACE No Payload Encryption Software Version

Cisco makes available the following two ACE software versions:

ACE Payload Encryption (PE)—CLI commands related to payload encryption protocols are enabled. The ACE uses the payload encryption protocols, such as SSL, to encrypt through-the-box traffic. The ACE PE software version contains the same payload encryption functionality found in previous ACE software versions.

ACE No Payload Encryption (NPE)—CLI commands related to payload encryption protocols are either removed or do not function because the key encryption configuration commands have been removed. The new ACE NPE software version supports customers located in countries where the United States has imposed export restrictions on crypto functions. Without the use of payload encryption protocol commands, you cannot configure the ACE to perform data encryption tasks, such as configuring it as a virtual Secure Sockets Layer (SSL) server for SSL initiation or termination.

Table 4 lists the CLI commands that are removed from the ACE A5(2.0) NPE software version.

Table 4 Commands Removed from the ACE A5(2.0) NPE Software Version 

CLI Mode
Removed Commands

Exec

host1/Admin#

crypto {delete | export | generate csr | import | verify}

Config

host1/Admin(config)#
 
        

(accessed using the config command from Exec mode)

ssl-proxy service name

Removal of this command also removes the following related SSL proxy configuration mode commands:

authgroup

cert

chaingroup

crl

key

ocspserver

revcheckprio

ssl

probe https name


Table 5 lists the CLI commands that are either not functioning or are modified as a result of the commands removed from the ACE A5(2.0) NPE software version (see Table 4).

Table 5 Non-Functioning or Modified Commands in the ACE A5(2.0) NPE Software
Version 

CLI Mode
Removed Commands

Exec

host1/Admin#

Nonfunctioning commands:

backup exclude ssl-files

clear stats crypto [client | server [alert | authentication | cipher | termination]]

debug cfgmgr sslstats

restore [all] disk0:archive_filename exclude ssl-files [licenses]

show cfgmgr internal table ssl-proxy [all | context | detail]

show crypto {aia-errors | authgroup | cdp-errors | certificate | chaingroup | crl | csr-params | files | key | ocspserver | session}

show ip https

show np 1 me-stats ucdump_option

where ucdump_option is one of the following:

F

A

a

show stats crypto {client [alert | authentication | cipher | termination]} | server [alert | authentication | cipher | insert | redirect | termination]}

show stats probe type https

Modified commands:

show license status: Command output does not contain the SSL transactions per second listing.

show resource usage resource rate ssl-connections counter [all | current | denied | peak]: Command output does not contain SSL connection information.

Config

host1/Admin(config)#
 
        

(accessed using the config command from Exec mode)

nonfunctioning commands:

access-list name extended {permit | deny} tcp {ipv4_address | ipv6address | any | anyv6 | host | object-group} {any | eq | gt | host | lt | neq | object-group | range} {ldaps | https}

ip https certificate cert key

parameter-map type ssl name

Removal of this command also removes the following related ssl parameter-map configuration mode commands:

authentication failure

cdp-error ignore

cipher

close-protocol

expired-crl reject

purpose-check disabled

queue-delay timeout

rehandshake enabled

session-cache timeout

version

Action list modify

host1/Admin(config-actlist- 
modify)#
 
        

(accessed using the action-list type modify http name command)

nonfunctioning commands:

ssl header-insert {client-cert specific_field | server-cert specific_field | session specific_field} [prefix prefix_string | rename new_field_name]

ssl url rewrite location expression [clearport number] [sslport number]

Policy map class

host1/Admin(config-pmap-c)#
 
        

(accessed using the policy-map type multi-match name command from config mode and then the class name command from the policy map mode)

nonfunctioning commands:

nat static [ipv6_address/prefix_length | ipv4_address netmask mask] tcp eq https vlan number

ssl-proxy server name

Policy map class

host1/Admin(config-pmap-c)#
 
        

(accessed using the policy-map type first-match name command from config mode and then the class name command from the policy map mode)

nonfunctioning commands:

ssl-proxy server name

Policy map load balancing HTTP class

host1/Admin(config-pmap-lb-c)#
 
        

(accessed using the class name command from policy map load balancing HTTP config mode)

nonfunctioning commands:

ssl-proxy client

Class map HTTP load balancing

host1/Admin(config-cmap-http-lb)#
 
        

(accessed using the class-map type http loadbalance match-any name command from config mode)

nonfunctioning commands:

match cipher {equal-to | less-than} cipher

Role configuration

host1/Admin(config-role)#
 
        

(accessed using the role name command from config mode)

nonfunctioning commands:

rule number {permit | deny} {create | debug | modify | monitor} feature {pki | ssl}


Support for Creation of RDP Parameter Maps

The Microsoft Remote Desktop Protocol (RDP) provides users with remote display and input capabilities over network connections for Windows-based applications running on a terminal server. In a load-balancing configuration, the ACE distributes incoming session connections across the terminal servers in a server farm according to the load-balancing method configured on the server farm. For background on RDP load balancing as performed by the ACE, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine.

Per CSCua04753, the ACE now supports the use of a parameter map for RDP load-balancing connections. By default, if the real server that matches the routing token information in the RDP packet from the client is DOWN, the connection will be reset and the RDP packet will be dropped. By configuring routing-token-rebalance under an RDP-type parameter map and applying that parameter map to a VIP, if the real server that matches the routing token information is DOWN, RDP packets will not be dropped and the connection will be redirected to another server.

The following topics describe how to define an RDP parameter map and associate it with a server-load balancing policy map:

Configuring an RDP Parameter Map

Defining a Description to the RDP Parameter Map

Enabling Routing Token Rebalance in the RDP Parameter Map

Associating the RDP Parameter Map with a Layer 3 and Layer 4 Network Traffic Policy Map

Configuring an RDP Parameter Map

The parameter map type rdp command specifies an RDP-type parameter map. After you create the parameter map, you configure settings in RDP parameter map configuration mode. You then reference this parameter map in the policy map using the appl-parameter rdp advanced-options command.

The syntax of the parameter map type rdp configuration mode command is as follows:

parameter map type rdp name

The name argument specifies the name assigned to the RDP parameter map. Enter an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

For example, to create a RDP-type parameter map called RDP_MAP, enter:
host1/Admin(config)# parameter-map type rdp RDP_MAP
host1/Admin(config-parammap-rdp)#
 
   

To remove the RDP parameter map, use the no form of this command.

Defining a Description to the RDP Parameter Map

You can provide a brief summary of the RDP parameter map by using the description command in RDP parameter map configuration mode. The syntax of this command is as follows:

description text

For the text argument, enter an unquoted text string with a maximum of 240 alphanumeric characters including spaces.

For example, to specify a description of an RDP parameter map, enter the following command:

host1/Admin(config-parammap-rdp)# description Remote Desktop Protocol parameter map
 
   

To remove the description from the RDP parameter map, enter:

host1/Admin(config-parammap-rdp)# no description
 
   

Enabling Routing Token Rebalance in the RDP Parameter Map

You enable the routing-token-rebalance function in the RDP parameter map by using the routing-token-rebalance command in RDP parameter map configuration mode. There are no arguments for this command.

For example, enter the following command:

host1/Admin(config-parammap-rdp)# routing-token-rebalance
 
   

To remove the routing-token-rebalance command from the RDP parameter map, enter:

host1/Admin(config-parammap-rdp)# no routing-token-rebalance
 
   

Associating the RDP Parameter Map with a Layer 3 and Layer 4 Network Traffic Policy Map

You associate the RDP parameter map with a Layer 3 and Layer 4 network traffic policy map by using the appl-parameter rdp advanced-options command in policy-map class configuration mode.


Note For details on configuring a Layer 3 and Layer 4 policy map for network traffic, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine.


The syntax of this command is as follows:

appl-parameter rdp advanced-options name

The name argument identifies the existing RDP parameter map.

For example, to specify the appl-parameter rdp advanced-options command as an action for the network traffic policy map, enter:

host1/Admin(config)# policy-map multi-match L4SLBPOLICY
host1/Admin(config-pmap)# class FILTERRDP
host1/Admin(config-pmap-c)# appl-parameter rdp advanced-options RDP_MAP
 
   

To disassociate the RDP parameter map as an action from the network traffic policy map, enter:

host1/Admin(config-pmap-c)# no appl-parameter rdp advanced-options RDP_MAP
 
   

Ability to Enable Regular Expression Download Optimization

When you perform a number of configuration changes while traffic is running, either administrative tasks such as putting a real server inservice and out-of-service, or Layer 7 configuration changes such as modifying one or more class maps within a policy, these changes may result in traffic hitting an incorrect policy and being sent to the incorrect server farm. In this case, the HTTP regex tree gets recompiled and downloaded after every configuration change even if the change is limited to inservice/no inservice of a real server which does not alter the HTTP regex tree.

Per CSCtz37625, the ACE now displays the hidden command limit-regex-dnld enable in configuration mode to enable regular expression download optimization. When you specify the limit-regex-dnld enable command, the HTTP regex tree is not re-compiled and downloaded when performing processes such as putting a real server inservice and out-of-service. This feature is disabled by default.

To view information related to the regex download optimization status, the show download information command has been added to software version A5(2.0).

switch/Admin# show download information 
 
   
context: Admin
Regex download optimization status: ENABLED
Interface                     Download-status
------------------------------------------------------
     200                           Completed
     165                           Completed
    1006                           Completed

Extended Range of Supported Characters in a URL

In software releases prior to A5(2.0), the ACE HTTP parser accepted characters in the range of 32 to 126 characters in the UTF-8 encoding schema for URLs. Per CSCts64534, with software release A5(2.0) the ACE has extended support for characters in the range from 128 to 255 (all characters) in the UTF-8 encoding schema for URLs. This extended range is allowed only when the parsing non-strict command is configured in the HTTP parameter map configuration mode.

Configuring an SNMP Peer Engine ID for the Standby ACE

In prior releases, the ACE allowed you to configure an SNMP engine ID that applied to both the active and standby ACE. Per CSCtq59860, you can configure a different engine ID for the standby ACE in a redundant configuration. The snmp-server engineid command in configuration mode includes the new peer engineid peer_value option. The syntax of this command is as follows:

snmp-server engineid local_value [peer engineid peer_value]

The local_value argument is the engine ID for the active ACE. If you do not enter the peer engineid value_2 option, the local_value argument applies to both the active and standby ACEs.

To change the value of an engine ID, you must change both values. Otherwise, the ACE displays the following error message:

Enter valid value for engineid/peer engineid
Either both should be same or both should change
 
   

To change the peer_value argument, you must also change the local_value argument, or visa versa, for example:

host/Admin(config)# snmp-server engineid 1234567892 peer engineid 2234567891
host/Admin(config)# snmp-server engineid 2134567892 peer engineid 2324567891
 
   

To change a configuration in which the active and standby engine IDs are different to a value that is the same value for both engine IDs, you must enter a value that is different for both IDs, for example:

host/Admin(config)# snmp-server engineid 2134567892 peer engineid 2324567891
host/Admin(config)# snmp-server engineid 4567892213
 
   

When synchronization occurs in a redundant configuration, consider the following:

When both the active and standby ACEs are running software versionA5(2.0) and you configure different local and peer engine IDs on the active ACE, the active ACE sends the local engine ID as the peer ID to the standby ACE, and the peer engine ID as the local ID. For example, the running configuration on the ACEs will be similar to the following:

On the active ACE: snmp-server engineid 2134567892 peer engineid 2324567891

On the standby ACE: snmp-server engineid 2324567891 peer engineid 2134567892

When the active ACE is running software version A5(2.0) and the standby ACE is running a software version less than A5(2.0) and you configure different local and peer engine IDs on the active ACE, the active ACE verifies that the software version on the standby ACE and sends only the peer engine ID as the local ID to the standby ACE. For example, the running configuration on the ACEs will be similar to the following:

On the active ACE: snmp-server engineid 2134567892 peer engineid 2324567891

On the standby ACE: snmp-server engineid 2324567891

When the active ACE is running a software version less than A5(2.0) and the standby ACE is running software version A5(2.0) and since you can configure only one engine ID on the active ACE, the active ACE sends the engine ID to the standby ACE. The local and peer engine IDs on the standby ACE will have the same value. For example, the running configuration on the ACEs will be similar to the following:

On the active ACE: snmp-server engineid 2134567892

On the standby ACE: snmp-server engineid 2134567892 peer engineid 2134567892

Use the no form of this command to delete the SNMP engine IDs. If you delete one engine ID, the other engine ID is also deleted.

The show snmp engineID command has been modified to display the identification of the peer SNMP engine in addition to the local SNMP engine configured on the ACE. If you use the show snmp engineID command on the standby ACE, the local SNMP engine ID will be the peer engine ID presented in the active ACE.

For example, you can configure different SNMPv3 engine IDs for active and standby ACEs:

host1/Admin(config)# snmp-server engineid 1234567890 peer engineid 0987654321
host1/Admin(config)# do show snmp engineID
Local SNMP engineID: 1234567890
PEER SNMP engineID: 0987654321
 
   

Configuring an SNMP User Authentication Password for the Standby ACE

Per CSCtq60293, when you configure Simple Network Management Protocol (SNMP) user information, you can specify a peer privacy password for user authentication parameters or user encryption parameters. Upon a switchover from an active ACE to the standby ACE, the snmp-server user command privacy passwords synchronize between the active and standby ACEs.

The modified keywords, arguments, and options are as follows:

snmp-server user user_name [group_name] [auth {md5 | sha} local_password1 peer peer_password1] [priv [aes-128] local_password2 peer peer_password 2] [localizedkey]]

peer peer_password1—(Optional) Used for user authentication parameters to specify an authentication password for a peer user on a standby ACE. Enter an unquoted text string with no space and a maximum of 130 alphanumeric characters. The ACE automatically synchronizes the SNMP authentication password as the password for the CLI user on the standby ACE.


Note The peer password is optional; if you do not enter a peer password the ACE will use the local password for the peer user on a standby ACE.


The ACE supports the following special characters in a password: , . / = + - ^ @ ! % ~ # $ * ( ) .

peerpeer_password2 —(Optional) Used for user encryption parameters to specify a privacy password for a peer user on a standby ACE.


Note The peer password is optional; if you do not enter a peer password the ACE will use the local password for the peer user on a standby ACE.


Note the following specifications for the user encryption peer password:

The AES priv password can have a minimum of eight characters.

If the passphrases are specified in clear text, you can specify a maximum of 64 alphanumeric characters.

If you use the localized key, you can specify a maximum of 130 alphanumeric characters.

Spaces are not allowed. The ACE supports the following special characters in a password: , . / = + - ^ @ ! % ~ # $ * ( ) .

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. In prior releases, the ACE allowed you to configure an SNMP engine ID that applied to both the active and standby ACE. With software version A5(2.0), you can configure a different engine ID for the standby ACE in a redundant configuration (see the "Configuring an SNMP Peer Engine ID for the Standby ACE" section).

Included below are a set of running configuration examples that illustrate the interaction between the SNMP engine ID and SNMP user password configured for the active and standby ACEs in a redundant configuration.

SNMP Engine ID is the Same for the Active and Standby ACEs and SNMP User Password is the Same for the Active and Standby ACEs

host1/Admin(config)# snmp-server engineid 1234567890 peer engineid 1234567890
host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer abcd12345
host1/Admin(config)# do show running-config | inc snmp
Generating configuration....
snmp-server engineid  1234567890 peer engineid 1234567890
snmp-server user usr1 Network-Monitor auth md5 0xea2410e3deaf422dab2ad979d406825
7 peer 0xea2410e3deaf422dab2ad979d4068257 localizedkey
 
   

SNMP Engine ID is the Same for the Active and Standby ACEs and SNMP User Password is Different for the Active and Standby ACEs

host1/Admin(config)# snmp-server engineid 1234567890 peer engineid 1234567890
host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer ghijk12345
host1/Admin(config)# do show running-config | inc snmp
Generating configuration....
snmp-server engineid  1234567890 peer engineid 1234567890
snmp-server user usr1 Network-Monitor auth md5 0xea2410e3deaf422dab2ad979d406825
7 peer 0x2285eb39064716bdae814e038bcba6c4 localizedkey
 
   

SNMP Engine ID is Different for the Active and Standby ACEs and SNMP User Password is the Same for the Active and Standby ACEs

host1/Admin(config)# snmp-server engineid 123456789010 peer engineid 0987654321 
host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer abcd12345
host1/Admin(config)# do show running-config | inc snmp
Generating configuration....
snmp-server engineid  123456789010 peer engineid 0987654321
snmp-server user usr1 Network-Monitor auth md5 0x4d1d46812f0484674e98ba5757ed7aa
7 peer 0x95312cbb53b1ef8c8c556fa5a2378fa7 localizedkey
 
   

SNMP Engine ID is Different for the Active and Standby ACEs and SNMP User Password is Different for the Active and Standby ACEs

host1/Admin(config)# snmp-server engineid 123456789010 peer engineid 0987654321 
host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer dfgh12345
host1/Admin(config)# do show running-config | inc snmp
Generating configuration....
snmp-server engineid  123456789010 peer engineid 0987654321
snmp-server user usr1 Network-Monitor auth md5 0x4d1d46812f0484674e98ba5757ed7aa
7 peer 0x30778af5b6239945f2bae806112676b3 localizedkey
 
   

Ability for the ACE to Accept a User Account with an Expired Date

You create a user and define the associated role and operating domains by using the username command in configuration mode. You can optionally specify an expiration date of the user account. In software releases prior to A4(2.3), when the user account is configured with a specified expiration date in the past (with reference to the ACE system clock), the ACE displays the error message "date should be in the future, expiry date wrong" and the configuration is then rejected. When operating in a redundant configuration, when the username expires, the expired configuration is not removed from the running-configuration file on the active ACE which can result in synchronization issues.

Per CSCtx45830, with software release A4(2.3), when the user account is configured with an expiry date in the past (with reference to the ACE system clock), the ACE displays the error message "User created with expiry date in the past, please edit to make it usable, which allows the configuration to be accepted. You can then modify the expiration date associated with the user account.

The change allows an expired "username" configuration to be accepted.

For example:

host1/Admin(config)# do show clock
Wed Mar 14 11:16:09 UTC 2012
host1/Admin(config)# username abcd pass cisco123 expire 2012-03-10 role Network-Monitor 
domain default-domain
User created with expiry date in the past, please edit to make it usable
host1/Admin(config)#
 
   

Addressing SSL Certificates With a Subject or Issuer That is Greater Than 256 Bytes

Per CSCtx64223, when the subject or issuer of an imported SSL certificate is greater than 256 bytes the ACE truncates the output of imported certificate when displayed by using the show crypto certificate all command. Note that the imported certificate is not affected by this truncation; if you export the certificate you will still be able to see the correct (greater than 256 byte) subject or issuer in the certificate.

As an example, included below is authcert2 with the full subject:

Subject: /C=US/ST=Georgia/L= Friendly Village of Crooked Creek/O=State Community College 
of Friendly Village of Crooked Creek/OU=Department of Thermonuclear and Quantum 
Physics/CN=www.statecommununitycollegeoffriendlyvillageofcrookedcreek.edu/emailAddress=adm
in@statecommununitycollegeoffriendlyvillageofcrookedcreek.edu
 
   

Included below is an example of the current show crypto certificate all command output behavior in releases prior to software version A5(2.x):

host1/Admin# show crypto cert all
authcert2
Subject: /C=US/ST=Georgia/L= Friendly Village of Crooked Creek/O=State Community College 
of Friendly Village of Crooked Creek/OU=Department of Thermonuclear and Quantum 
Physics/CN=www.statecommununitycollegeoffriendlyvillageofcrookedcreek.edu/emailAddresIssue
r: / C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services 
Division,CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Not Before: Dec  8 14:57:27 2009 GMT
Not After: Sep  3 14:57:27 2012 GMT
CA Cert: FALSE
 
   

And here is an example of this updated show crypto certificate all command output behavior in software version A5(2.0):

host1/Admin# show crypto cert all
authcert2
Subject: /C=US/ST=Georgia/L= Friendly Village of Crooked Creek/O=State Community College 
of Friendly Village of Crooked Creek/OU=Department of Thermonuclear and Quantum 
Physics/CN=www.statecommununitycollegeoffriendlyvillageofcrookedcreek.edu/emailAddres
Issuer: / C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification 
Services Division,CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Not Before: Dec  8 14:57:27 2009 GMT
Not After: Sep  3 14:57:27 2012 GMT
CA Cert: FALSE
 
   

With software version A5(2.0), the ACE prints a warning message when importing a certification with a subject or issuer that is greater than 256 bytes:

host1/Admin# crypto import terminal 1.pem 
Please enter PEM formatted data. End with "quit" on a new line.
 -----BEGIN CERTIFICATE-----
 MIIEOzCCA6SgAwIBAgIJAOKKpTWQqvrjMA0GCSqGSIb3DQEBBQUAMGsxCzAJBgNV
 BAYTAkpQMQ4wDAYDVQQIDAVUb2t5bzEQMA4GA1UECgwHQ29tcGFueTEMMAoGA1UE
 CwwDdHMzMRAwDgYDVQQDDAdqdW5pY2hpMRowGAYJKoZIhvcNAQkBFgtqdW5AanVu
 LmNvbTAeFw0xMjAxMTcwNTA5NDRaFw0xMzAxMTYwNTA5NDRaMIIB1TELMAkGA1UE
 BhMCSlAxSTBHBgNVBAgMQGFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
 YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWExSTBHBgNVBAcMQGJiYmJi
 YmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi
 YmJiYmJiYmJiYmIxSTBHBgNVBAoMQGNjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj
 Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2MxSTBHBgNVBAsM
 QGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRk
 ZGRkZGRkZGRkZGRkZGRkZGQxSTBHBgNVBAMMQGVlZWVlZWVlZWVlZWVlZWVlZWVl
 ZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWUxTzBN
 BgkqhkiG9w0BCQEWQGZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm
 ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmYwgZ8wDQYJKoZIhvcNAQEBBQAD
 gY0AMIGJAoGBALolNEP5y5UhhnzXmam3UZo1z9JuLc8ZcYHc415SDA5LKHDFIZN8
 WKjJjypRe+jadalXaK8WM1yDGDlaM3JxQXZ4F+V5FNHhpTUxtfnvnpePWMmrP4jZ
 owehkThgaXBqRq3XyLFhErxqE3VIIOU6j9EYbFeiZIfNlCiTvr5xFiOHAgMBAAGj
 ezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVk
 IENlcnRpZmljYXRlMB0GA1UdDgQWBBT0DegeQfhf5TKa7E1Ixcw3gTYLODAfBgNV
 HSMEGDAWgBQgBnaGwQfnkTa5vsz+38FffwKlyDANBgkqhkiG9w0BAQUFAAOBgQBG
 lH6ipRK2my5ND391XJGnf7xraRuBGKRdXAbCArCtH2Nbt5nM//kQHZx0im7go+Zq
 25bzBnyFvUoS6HM09P+elzPeY4ZjeJ+vRL8qbQgOsI1yEUEAwbeNilYGjFwI1SZG
 ubvFPJRYplab7Bb217C9u4J6wZDmxdcSbRAh7pNHUA==
 -----END CERTIFICATE-----
 quit
 
   
Warning: this cert has a subject or issuer DN that is longer than 256 bytes, the 'show 
crypto certificate all' command truncates anything beyond 256 bytes in the subject and 
issuer fields

ACE Probes Use the Interface MAC Address as the Source MAC Address

When an ACE-configured probe closes internally or times-out internally, a RST is generated. Per CSCtj65372, a change has occurred in this RST to have the source MAC address use the nterface MAC address instead of the current behavior of using the virtual MAC address. The inclusion of the interface MAC address allows both the active and standby ACEs in an HA pair to send the RST packet out with the source MAC as its respective interface MAC rather than a common virtual MAC address.

This changes impacts the following probes types: TCP, FTP, HTTP, and HTTPS.

Chassis, Supervisor Engine, and Cisco IOS Support for the ACE30 Module

Table 6 and Table 7 summarize the chassis, supervisor engine model, and Cisco IOS version support for the ACE30 module in the Catalyst 6500E series switch and the Cisco 7600 series router, respectively.

Table 6 Chassis, Supervisor Engine, and Cisco IOS Support for the ACE 30 in a Catalyst 6500 Series Switch with a Multilayer Switch Feature Card (MSFC3 or Later)

Catalyst 6500 Series Switch Chassis
Supervisor Engine Model
Minimum Required Cisco IOS Version

6503-E

6504-E

6506-E

6509-E1

6509-V-E

6513

6513-E2

VS-S2T-10G 3

VS-S2T-10G-XL

15.0(1)SY (or later)

WS-SUP720-3B

WS-SUP720-3BXL

VS-S720-10G-3C(=)

VS-S720-10G-3CXL(=)

12.2(33)SXI4 or later releases

1 The Catalyst 6509-E chassis supports up to six ACE 30 modules with Supervisor Engine 2T (VS-S2T-10G or VS-S2T-10G-XL), and running Cisco IOS software version 15.0(1)SY1 (or later) with ACE module software version A5(2.0).

2 The Catalyst 6513-E chassis supports up to nine ACE 30 modules with Supervisor Engine 2T (VS-S2T-10G or VS-S2T-10G-XL), and running Cisco IOS software version 15.0(1)SY1 (or later) with ACE module software version A5(2.0).

3 The minimum required ACE30 module software version for Supervisor Engine 2T support is A5(1.1) or later. This software version supports both supervisor engine models: VS-S2T-10G and VS-S2T-10G-XL.


Table 7 Cisco Supervisor Engine, Route Switch Processor (RSP), and Cisco IOS Support for the ACE30 in a Cisco 7600 Series Router with a Multilayer Switch Feature Card (MSFC3 or Later)

Cisco 7600 Series Router Chassis
Supervisor Engine or RSP
Minimum Required Cisco IOS Version

7603

WS-SUP720-3B

WS-SUP720-3BXL

RSP720-3C-GE(=)

RSP720-3CXL-GE(=)

RSP720-3C-10GE

RSP720-3CXL-10GE

15.0(1)S or later releases

7604

7609

7613

7603-S

7604-S

7606-S

7609-S


Virtual Switching System Support

The ACE30 running ACE software version A4(1.0) or later releases and installed in a Catalyst 6500 series switch running Cisco IOS release 12.2(33)SXI4 or later releases support the Virtual Switching System (VSS). VSS is a system Virtualization technology that allows the pooling of multiple Catalyst 6500 switches into a single virtual switch for increased operational efficiency by simplifying the network. Interchassis Supervisor switchover (SSO) boosts nonstop communication. For more information about VSS, see the Cisco IOS version 12.2(33)SXI4 Configuration Guide.

ACE Operating Considerations

The ACE operating considerations are as follows:

Starting with software version A4(1.0), the default connection inactivity timeout settings for the ACE have changed to the following values:

ICMP—2 seconds

TCP—3600 seconds (1 hour)

HTTP/SSL—300 seconds

UDP—10 seconds

The default HTTP and SSL ports (80 and 443) now have a default inactivity timeout of 300 seconds.

Starting with software version A4(1.0), it is no longer necessary to configure a resource class in the Admin context to allocate resources for stickiness. You can still allocate sticky resources if you wish, but skipping this step will not affect sticky functionality.

In a redundant configuration, dynamic incremental sync is a form of config sync that copies configuration changes that you make on the active ACE to the standby ACE when the two ACEs are running the same version of software and when both ACEs are up. When you upgrade from one major release of ACE software to another major release (for example, from A2(3.0) to A5(1.0) or later, bulk sync, dynamic incremental sync, and connection replication are automatically disabled only while the active ACE is running software version A5(1.0) or later and the standby ACE is running software version A2(3.0). See Table 8.

We recommend that you do not make any configuration changes during this time and that you do not keep the ACEs in this state for an extended period of time. However, if you must make configuration changes while the ACEs are in split mode, ensure that you manually synchronize to the standby ACE any configuration changes that you make on the active ACE. After you complete the software upgrade of both ACEs, a bulk sync occurs automatically to replicate the entire configuration of the new active ACE to the new standby ACE. At this time, dynamic incremental sync will be enabled again. For details about config sync, see Chapter 6, "Configuring Redundant ACEs" in the Administration Guide, Cisco ACE Application Control Engine.

Table 8 Redundancy Feature Availability Between Major ACE Software Versions 

Platform
Active
Standby
Bulk Sync
Incr Sync
Conn Repl
Sticky Repl
Operation
Comments

Module

A2(x)

A5(x)

Yes

No

Yes

Yes

Upgrade

Module

A4(1.x)

A5(x)

Yes

No

Yes

Yes

Upgrade

Module

A4(2.x)

A5(x)

Yes

No

Yes

Yes

Upgrade

Module

A5(x)

A2(x)

No

No

No

No

Downgrade

Functionality not supported due to architectural differences between the ACE20 and the ACE30 hardware

Module

A5(x)

A4(1.x)

Yes

No

Yes (IPv4 flows)

Yes (IPv4 flows)

Downgrade

Standby supports only IPv4

Module

A5(x)

A4(2.x)

Yes

No

Yes (IPv4 flows)

Yes (IPv4 flows)

Downgrade

Standby supports only IPv4


After migrating from ACE10/20 to ACE30 or ACE4710 the "ssl-connections rate" ACE reports via "show resource usage" or SNMP is significantly lower than what ACE10/20 reported, if the SSL Session ID Reuse feature is enabled. The reason for this difference, which can easily be a factor of 10, is that ACE30 and ACE4710 do not count a reused/resumed SSL connection towards the "ssl-connections rate", while ACE10/20 does.

During an upgrade in a redundant configuration, we recommend that you do not run the two ACEs with different versions of software (split mode) for an extended period of time. However, if you must remain in split mode for a period of time to make configuration changes, we strongly recommend that you disable configuration synchronization (config sync) by entering the following command:

host1/Admin(con)# no ft auto-sync running-config
 
   

When you have finished making configuration changes to the active ACE, reenable config sync by entering the following command:

host1/Admin(con)# ft auto-sync running-config
 
   

After you reenable config sync, the ACE automatically synchronizes the configuration changes from the active ACE to the standby ACE.

We strongly recommend that you do not make any CLI changes when the ACE modules 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.

In software version A4(1.0) or later, all four of the network processors (NPs) must transition into the retcode or inband failed state before the ACE marks the real server as RETCODE-FAILED or INHAND-HM-FAILED, respectively, and places it on the reactivate list for recovery. This is also true for the maxconn limit, where the threshold values are divided among all four NPs similar to the retcode and inband failed states. The real servers will move to the MAXCONN state only when all four NPs reach the MAXCONN state.

Note that the following may occur:

When some NPs are in the retcode failed state and the other NPs are in the inband failed state due to a traffic pattern that hashes connections to specific NPs, the real servers are in the OPERATIONAL state as displayed by the show serverfarm name command because the NPs are deadlocked waiting until the other NPs reach the retcode or inband failed state, respectively.

When some NPs are in the retcode or inband failed state due to a traffic pattern that hashes only to some NPs and not to the other NPs, the real servers are left in the OPERATIONAL state until all NPs transition into the retcode or inband failed state, respectively.

When the traffic distribution is uniform across all NPs, these issues do not occur.

The ACE requires a route back to the client before it can forward a request to a server. If the route back to the client is not present, the ACE cannot establish a flow and drops the client request. Make sure that you configure the appropriate routing to the client network on the ACE VLAN where the client traffic enters the ACE module.

When you downgrade the ACE software, the features and commands of the higher release are lost because they are not supported by the lower release.

When redundant ACEs lose connectivity (for example, because of a network interruption) and they attempt to reestablish their connection, if you enter the show ft peer or show ft group command during this time, the response to this command may be delayed.

If you are using the Application Networking Manager (ANM) to manage an ACE module and you configure a named object at the ACE CLI, ANM does not support all of the special characters that the ACE CLI supports for a named object. If you use special characters that ANM does not support, you may not be able to import or manage the ACE using ANM.

When naming ACE objects (such as a real server, virtual server, parameter map, class map, health probe, and so on) for use with ANM, enter an alphanumeric string of 1 to 64 characters, which can include the following special characters: underscore (_), hyphen (-), dot (.), and asterisk (*). Spaces are not allowed.

When you remove a NAT pool configuration, wait more than five seconds before adding a NAT pool with the same ID.

The Account Expiry field for the show user-account command displays the date, if any, when the user account expires. This date is based on Coordinated Universal Time (UTC/GMT) which the ACE keeps internally. If you use the clock timezone command to configure a UTC offset, this field displays the UTC date and does not reflect the date with the offset as displayed by the show clock command.

Available ACE Licenses

By default, the ACE supports virtualization with one Admin context and five user contexts, 4 gigabits per second (Gbps) module bandwidth, 1 Gbps compression, and 1,000 SSL transactions per second (TPS). You can increase the number of default user contexts, module bandwidth, and SSL TPS by purchasing the licenses shown in Table 9.

Table 9 ACE30 License Bundles 

License Bundle
Product ID (PID)
License File
Description

Base (default)

ACE30-BASE-04-K9

None required

4 Gbps bandwidth
1 Gbps compression
1,000 SSL TPS
5 Virtual Contexts

Base to 4 Gbps

4 Gbps Bundle

ACE30-MOD-UPG1=

ACE30-MOD-04-K9

ACE30-MOD-UPG1

ACE30-MOD-04-K9

4 Gbps bandwidth
6 Gbps compression
30,000 SSL TPS
250 Virtual Contexts

4 Gbps to 8 Gbps

8 Gbps Bundle

ACE30-MOD-UPG2=

ACE30-MOD-08-K9

ACE30-MOD-UPG2

ACE30-MOD-08-K9

8 Gbps bandwidth
6 Gbps compression
30,000 SSL TPS
250 virtual contexts

8 Gbps to 16 Gbps

16 Gbps Bundle

ACE30-MOD-UPG3=

ACE30-MOD-16-K9

ACE30-MOD-UPG3

ACE30-MOD-16-K9

16 Gbps bandwidth
6 Gbps compression
30,000 SSL TPS
250 virtual contexts


You can also obtain an ACE demo license for each license bundle. You can get a demo license that is valid for 30 or 90 days. At the end of this period, you will need to update the demo license with a permanent license to continue to use the ACE software. To view the expiration of the demo license, use the show license usage command in Exec mode. If you need to replace the ACE module, you can copy and install the licenses onto the replacement module.


Note You can access the license and show license commands only in the Admin context. You must have the Admin role in the Admin context to perform the tasks of installing, removing, and updating the license.


Ordering an Upgrade License and Generating a License Key

This section describes the process to order an upgrade license and to generate a license key for your ACE. To order an upgrade license, perform the following steps:


Step 1 Order one of the licenses from the list in the "Obtaining Documentation and Submitting a Service Request" section using any of the available Cisco ordering tools on Cisco.com.

Step 2 When you receive the Software License Claim Certificate from Cisco, follow the instructions that direct you to the cisco.com website. As a registered user of cisco.com, go to this URL:

http://www.cisco.com/go/license

Step 3 Enter the Product Authorization Key (PAK) number found on the license certificate as your proof of purchase.

Step 4 Provide all the requested information to generate a license key.

Step 5 After the system generates the license key, you will receive a license key e-mail with an attached license file and installation instructions. Save the license key e-mail in a safe place in case you need it in the future (for example, to transfer the license to another ACE).


For information about installing and managing ACE licenses, refer to Chapter 3, Managing ACE Software Licenses, in the Administration Guide, Cisco ACE Application Control Engine.

Upgrading Your ACE Module Software in a Redundant Configuration

To upgrade your ACE software from version A2(3.x) or A2(1.6a) or later to version A5(2.x), you must also migrate your ACE10 or ACE20 module to a new ACE30 module. For details about migrating to an ACE30 and upgrading your software to A4(1.0) or later, see the procedure in the Installation Note, Cisco ACE Application Control Engine ACE30 Module.

To upgrade your ACE software from A5(1.x), or from either A4(2.x) or A4(1.x), to version A5(2.x) the procedure in the following section assumes that your ACEs 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.

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

Creating a Checkpoint

Copying the Startup Configuration of Each Context

Checking Your Configuration for FT Priority and Preempt


Note If you are upgrading a redundant configuration from A5(1.x), A4(2.x), or A4(1.x) to version A5(2.x) while the two ACEs are in split mode with the earlier software version running on the active ACE and software version A5(2.x) running on the standby, config sync is disabled. If you make any configuration changes on the active ACE during this time, your changes are not synchronized to the standby and are lost. After you complete the upgrade, config sync is automatically reenabled. We recommend that you do not make any configuration changes while the two ACEs are in split mode.


Changing the Admin Password

Before you upgrade your ACE software, 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 or through the supervisor engine of the Catalyst 6500 series switch or the Cisco 7600 series router.

For details on changing the default Admin password, see Chapter 1, Setting Up the ACE, in the Administration Guide, Cisco ACE Application Control Engine.

Changing the www User Password

Before you upgrade the ACE software, 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 Virtualization Guide, Cisco ACE Application Control Engine. In this case, the user would be www.


Caution If you do not change the www user password prior to upgrading the ACE software, configuration synchronization may fail and the context may not be in the STANDBY_HOT state.

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 Administration Guide, Cisco ACE Application Control Engine.

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.

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.

ACE-1/Admin# 
 
   

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/Admin# changeto C1
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 c6ace-t1k9-mz.A5_2_0.bin through FTP, enter:

ACE-1/C1# changeto Admin
ACE-1/Admin# copy ftp://server1/images//c6ace-t1k9-mz.A5_1_0.bin image: 
Enter source filename[/images/c6ace-t1k9-mz.A5_2_0.bin]? 
Enter the destination filename[]? [c6ace-t1k9-mz.A5_2_0.bin] File already exists, do you 
want to overwrite?[y/n]: [y] 
Enter hostname for the ftp server[server1]?
Enter username[]? user1
Enter the file transfer mode[bin/ascii]: [bin] Enable Passive mode[Yes/No]: [Yes] no
Password:
 
   

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:c6ace-t1k9-mz.A5_2_0.bin 
35913728  June 1 2012 01:17:01 c6ace-t1k9-mz.A5_2_0.bin 
 
   
           Usage for image: filesystem
                  828182528 bytes total used
                   54165504 bytes free
                  882348032 bytes total
 
   

Step 6 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:c6ace-t1k9-mz.A5_2_0.bin"
Configuration register is 1
 
   

Step 7 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 A4(1.0) image, enter:

ACE-1/Admin# configure
Enter configuration commands, one per line. End with CNTL/Z.
ACE-1/Admin(config)# no boot system image:c6ace-t1k9-mz.A4_1_0.bin 
 
   

Step 8 Configure ACE-1 to autoboot from the latest ACE image. To set the boot variable and configuration register to1 (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:c6ace-t1k9-mz.A5_2_0.bin 
ACE-1/Admin(config)# config-register 1
ACE-1/Admin(config)# exit
ACE-1/Admin# show bootvar
BOOT variable = "image:c6ace-t1k9-mz.A5_2_0.bin"
Configuration register is 1
 
   

Step 9 On the standby ACE module (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 10 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.

ACE-2/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
 
   

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 11 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 module has properly rebooted with the latest ACE software image.

Enter the show ft group detail command in Exec mode to verify that the standby ACE has recovered to a STANDBY_WARM state.

Step 12 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 13 Upgrade ACE-1 by reloading it. Verify that ACE-1 enters the STANDBY_WARM 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.

ACE-1/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
 
   

Step 14 Verify that ACE-1 is in the ACTIVE state and ACE-2 is in the STANDBY_WARM state by entering the show ft group detail command in Exec mode.


Downgrading Your ACE Module Software in a Redundant Configuration

If you need to downgrade your ACE software from version A5(2.x) to an earlier supported ACE software version (version A2(3.x) or A2(1.6a) or later), use the procedure in the Installation Note, Cisco ACE Application Control Engine ACE30 Module.

If you need to downgrade your ACE software from version A5(2.x) to software version A5(1.x), A4(2.x), or A4(1.x), 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

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.

Downgrade Procedure

To downgrade your A5(2.x) software in a redundant configuration, perform 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/Admin# changeto C1
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 Administration Guide, Cisco ACE Application Control Engine.

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
ACE-1/Admin(config)# boot system image:c6ace-t1k9-mz.A5_1_2.bin 
ACE-1/Admin(config)# config-register 1
ACE-1/Admin(config)# exit
ACE-1/Admin# 
 
   

You can set up to two images through the boot system command. If the first image fails, the ACE tries to boot from the second image.

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:c6ace-c6ace-t1k9-mz.A5_1_2.bin" 
Configuration register is 1
host1/Admin#
 
   

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.

ACE-2/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
 
   

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 A5(2.x) commands in the startup-configuration file.


Note Dynamic incremental sync is automatically disabled while the active ACE is running software version A5(2.x) and the standby ACE is running software version A5(1.x), A4(2.x), or A4(1.x).


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.

ACE-1/Admin# reload
 
   

After ACE-1 boots up, it assumes the role of standby and enters the STANDBY_HOT state (this may take several minutes). You can verify the states of both ACEs by entering the show ft group detail command in Exec mode. Because 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 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.


ACE Documentation Set

You can access the ACE module documentation on www.cisco.com at:

http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html

For information about installing the ACE module hardware, see the following documents on Cisco.com:

Document Title
Description

Installation Note, Cisco ACE Application Control Engine ACE30 Module

Provides information for installing the ACE module into the Catalyst 6500 series switch or a Cisco 7600 series router.


To familiarize yourself with the ACE module software, see the following documents on Cisco.com:

Document Title
Description

Release Note for the Cisco Application Control Engine Module

Provides information about operating considerations and caveats for the ACE.

Getting Started Guide, Cisco ACE Application Control Engine Module

Describes how to perform the initial setup and configuration tasks for the ACE module.


In addition to this document, the ACE module software documentation set includes the following:

Document Title
Description

Administration Guide, Cisco ACE Application Control Engine

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 Application Control Engine (ACE) Configuration Examples Wiki

Provides examples of common configurations for load balancing, security, SSL, routing and bridging, virtualization, and so on.

Cisco Application Control Engine (ACE) Troubleshooting Wiki

Describes the procedures and methodology in wiki format to troubleshoot the most common problems that you may encounter during the operation of your ACE.

Command Reference, Cisco ACE Application Control Engine

Provides an alphabetical list and descriptions of all CLI commands by mode, including syntax, options, and related commands.

Cisco CSM-to-ACE Conversion Tool User Guide

Describes how to use the CSM-to-ACE module conversion tool to migrate Cisco Content Switching Module (CSM) running- or startup-configuration files to the ACE.

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.

Routing and Bridging Guide, Cisco ACE Application Control Engine

Describes how to perform the following routing and bridging tasks on the ACE:

VLAN interfaces

IPv6, including transitioning IPv4 networks to IPv6, IPv6 header format, IPv6 addressing, and supported protocols

Routing

Bridging

Dynamic Host Configuration Protocol (DHCP)

Security Guide, Cisco ACE Application Control Engine

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 Translation (NAT)

Server Load-Balancing Guide, Cisco ACE Application Control Engine

Describes how to configure the following server load-balancing features 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

Dynamic workload scaling (DWS)

Firewall load balancing

TCL scripts

SSL Guide, Cisco ACE Application Control Engine

Describes how to configure the following Secure Sockets Layer (SSL) features on the ACE:

SSL certificates and keys

SSL initiation

SSL termination

End-to-end SSL

System Message Guide, Cisco ACE Application Control Engine

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.

Virtualization Guide, Cisco ACE Application Control Engine

Describes how to operate your ACE in a single context or in multiple contexts.


For detailed configuration information on the Cisco Application Networking Manager (ANM), see the following software document on Cisco.com:

User Guide, Cisco Application Networking Manager

Describes how to use Cisco Application Networking Manager (ANM), a networking management application for monitoring and configuring network devices, including the ACE.


ACE Troubleshooting Wiki

The ACE documentation set now includes the ACE Troubleshooting Wiki. This wiki is a collaborative site that describes the basic procedures and methodology to assist you in troubleshooting the most common problems that you may encounter while you are operating your ACE.

As a registered user of Cisco.com, we strongly encourage you to add content to this site in the form of troubleshooting tips, procedures, or even entire sections. When you add content to the site, you should adhere to the format that has been established for the wiki. To access the Troubleshooting Wiki on Cisco DocWiki, click the following URL:

http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_%28ACE%29_Troubleshooting_Guide

Software Version A5(2.1) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

This release note includes resolved and open caveats 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 A5(2.1):

Software Version A5(2.1) Resolved Caveats

Software Version A5(2.1) Open Caveats

Software Version A5(2.1) Command Changes

Software Version A5(2.1) System Log Messages

Software Version A5(2.1) Resolved Caveats

The following resolved caveats apply to software version A5(2.1):

CSCti28299—When an rserver reaches the MAXCONN state, ACE generates the SNMP trap cesRealServerStateUpRev1 instead of the cesRealServerStateChangeRev1 trap. Workaround: None.

CSCtx27765—During the normal booting process, the ACE intermittently fails to reload due to NAT initialization. Workaround: None. ACE reboots and resumes the next reload.

CSCtx50989—In the HTTP or HTTPS webhost redirection directive when you use special characters in the beginning of an URL (for example: //), the ACE skips few characters on the path URL. This causes application error out. Workaround: Do not use special characters in the beginning of the path URL.

CSCtx57994—After performing a software upgrade or while using software version A4(2.2), the ACE rebroadcasts a non-IP logical-link control (LLC) broadcast packet generated by an IBM server. As a result, this action causes the ACE to believe that the IBM server now resides off the ACE switchport. When this behavior occurs, you will see the following message:

%MAC_MOVE-SP-4-NOTIF: Host <IBM-SERVER-MAC> in vlan XX is flapping between port 
<ACE-PORT> and port <SERVER-PORT>  
 
   

Workaround: If necessary, downgrade to an earlier version of ACE software.

CSCtx76894—If you try to import a license while the /isan/ partition is full (due to CSCtx03563), the import will fail because the file copied in the partition is empty. This issue will also cause issues with the liccheck process when it tries to parse an empty file. Workaround: Reload the ACE and try to import the license again.

CSCtx77127CSCty08887—The ACE resets a connection if the HTTP header is approximately 14K in length while the VIP configuration does not require HTTP parsing. Workaround: Create an HTTP parameter map that includes the set header-maxparse-length command followed by a proper value.

CSCty24597—In a redundant configuration, with the ACE configured as a Fault Tolerant (FT) peer, when the FT state is being established, it may fail several times due to a select error before correctly going from ACTIVE to STANDBY. Workaround: None. The error is logged, but the FT peer eventually comes up normally.

CSCty43331—Under a normal server load-balancing operation when you add or modify a virtual IP (VIP) address, you may find that the VIP addresses do not appear in the show cfgmgr internal table icmp-vip output. Workaround: Reload the ACE.

CSCty61047—When you configure DHCPv6 relay on an interface and use the wide-dhcp IPv6 DHCP server as the DHCP server, the DHCP relay fails to function properly. Workaround: None.

CSCtz28887—When you use/configure "Admin" as a part of the name for a load-balancing context, the FT synchronization fails and goes into the FSM_FT_STATE_STANDBY_CONFIG state for a long time before moving to the FSM_FT_STATE_STANDBY_COLD state. Workaround: Do not include "Admin" in the name of a load-balancing context.

CSCtz42584—During normal operation, the ACE reboots when generating the syslogd core file. Workaround: None.

CSCtz42618—When real servers are down and you try to telnet to the VIP IP, a connection is established in the ACE because the ICM (Ingress Connection Manager) is not checking the VIP status. If you send another request, the connection is dropped with an L7 rejection. Workaround: None.

CSCtz62067—When you use a password/passphrase within the cr command, the show accounting log command displays the password in the clear text instead of being masked. Workaround: None.

CSCtz69599—The ACE includes a version of Openssl that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs. CVE-2012-1165.

PSIRT Evaluation

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.8:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:U/RC:C

CVE ID CVE-2012-1165 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

CSCtz92969—When you configure "vlan internal allocation policy descending" on the supervisor engine, the "interface vlan 4094" appears in the admin context even though the vlan number 2094 is neither configured nor assigned to the ACE.

Workaround: Do not configure "vlan internal allocation policy descending" on the supervisor engine.

CSCua12420—The ACE includes a version of OpenSSL that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: CVE-2012-2131. Additional details about the vulnerabilities is available at http://cve.mitre.org/cve/cve.html.

PSIRT Evaluation

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.5:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:U/RC:C

CVE ID CVE-2012-2131 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

CSCua12426—The ACE includes a version of OpenSSL that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: CVE-2012-2110. Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html.

PSIRT Evaluation

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.5:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:U/RC:C

CVE ID CVE-2012-2110 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

CSCua12454—Cisco ACE includes a version of OpenSSL that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: 2011-4576

Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html

PSIRT Evaluation

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.5:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:N/A:N/E:POC/RL:U/RC:C

CVE ID CVE-2011-4576 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

CSCua16421—The client does not receive large replies, approximately 1500 bytes, from VIP and PMTUD does not work. This is seen in the following cases:

The Virtual IP is configured with a specific port

IPv6 is configured on the client side

IPv4 is configured on the rserver side

The MTU on the path from the ACE to the client is lower than the MTU on the path from the ACE to the rserver.

Workaround: Perform either of the following:

Configure the MTU on the path from the ACE to the rserver to be lower than the MTU on the path from the ACE to the client.

Limit maximum MSS for connections to rservers on the ACE with the connection parameter map: parameter-map type connection NAME set tcp mss min 0 max <Maximum MSS on IPv6 side>

CSCua18092—The ACE does not do the mapping between ICMPv6 and ICMPv4 packets. Therefore, the ACE does not send ICMPv4 packets because the mapping of ICMPv6 to ICMPv4 is not done for this VIP by a device. This is seen in the following cases:

The VIP is a classmap that is configured with the protocol/port "any"

IPv6 is configured on the client side and IPv4 is configured on the rserver side

The MTU on the path from the ACE to the client is lower than the MTU on the path from the ACE to the rserver

Client requests result in a large reply size that is greater than the MTU of the ACE to the client path

Workaround: Configure VIP with a specific port.

CSCua18882—When IPv6 ssl termination is configured to load balance an IPv6 web server, the ACE IPv6 ssl termination VIP does not load a web page. The TCP MSS between the client and ACE is 1220. The packets are dropped when the packet size exceeds the MSS as follows:

ACE/Context# sh np 1 me-stats "-stcp" | i MSS Drops due to packet size exceed MSS: 21 0

Workaround: Configure the exceed-mss allow in connection parameter-map for VIP.

parameter-map type connection TCP-Options   exceed-mss allow  policy-map multi-match 
VIPS   class IPv6-SSL-Term-Vip     connection advanced-options TCP-Options
 
   

CSCua18919—When the backtrace decode points to a specific fastpath crash due to a corrupt buffer chain for transition, the ACE reboots with the last boot reason "NP Failed:NP ME Hung". Workaround: None.

CSCua19020—If you configure an ACE with two VIPs having the same address but on separate ports, and when you remove one VIP (with the other VIP operational), and later reconfigure it, the reconfigured VIP remains inactive for a long time.

Workaround: For the VIP addresses that are inactive, remove the configuration in the multi-match policy and reapply them.

CSCua22740After you configure an NTP server in the ACE and later remove it from the configuration, the NTP server still remains active (even after it is removed from the configuration). Workaround: None.

CSCua30450—The ACE unexpectedly reboots. If you specify the show version command, the ACE reloads with the last boot reason: Service cfgmgr. Workaround: None.

CSCua35646—When an ACE is running the software version A5(1.2), the ACE becomes unresponsive with the incorrect message: "HANG DETECTED on core 15". The correct message "Program terminated with signal 11" should be displayed.

Workaround: None.

CSCua41824—When the ACE is configured with a large number of connections (approximately, more than 6,000,000 for a module and 80,000 for an appliance), the module/appliance reboots when you enter the show np <x> me-stats "-call command.

Workaround: Do not enter the show np <x> me-stats "-call command with a large number of connections.

CSCua48058—The ACE30 module crashes and generates two core files snmpd_log.1033 and snmpd_log,1035 with the last boot reason: Service snmpd. Workaround: None.

CSCua65184—When you import the active and the standby ACE into more than two ANMs, the standby ACE reloads with the last boot reason service: snmpd. Workaround: None.

CSCua81138—The ACE stops inserting the SSL session ID header when the cached session reaches 100,000 sessions (approximately). Workaround: Remove the session cache timeout.

CSCua85445—When multiple snmpwalk requests are made along with the load-balancing traffic for extended hours, the ACE reboots with the reason NP4 Failed: NP ME Hung. Workaround: None.

CSCua99477—When SSL termination is configured on an ACE and the client connects with an expired certificate, the configured action-list adds incorrect values in the HTTP header. The HTTP verify-result header on the server shows the status as "OK" even though the certificate is expired. This problem occurs only when the CRL check is configured on the ACE.

Workaround: Remove the CRL check from the configuration.

CSCub05455—The ACE reloads with the following last boot reason: AAA Daemon, and generates core files. Workaround: None.

CSCub14821—When you enter the snmpwalk command on cippflpFilterConfig with large number of access-list elements, the ACE displays the following message on syslogs:

May  2 2012 15:10:03 : %ACE-2-901001 kernel: unable to alloc and fill in a new mtsbuf 
(pid=1017,
sap=1124, ret_val = -97, size=85608, opc=4001)
May  2 2012 15:10:03 : %ACE-2-901001 kernel: unable to alloc and fill in a new mtsbuf 
(pid=1017,
sap=1124, ret_val = -97, size=85608, opc=4001)
May  2 2012 15:10:03 : %ACE-2-901001 kernel: unable to alloc and fill in a new mtsbuf 
(pid=1017,
sap=1124, ret_val = -97, size=85608, opc=4001)
May  2 2012 15:10:04 : %ACE-2-901001 kernel: unable to alloc and fill in a new mtsbuf 
(pid=1017,
sap=1124, ret_val = -97, size=85608, opc=4001)
 
   

Workaround: None.

CSCub21785—In an end to end SSL connection, the ACE fails to reduce the MTU path for IPv6 when receiving huge ICMPv6 packets from the remote end point. The ACE ignores the "ICMpv6 Packet Too Big Message" message and attempts to send the same sized packets again. Workaround: Reduce the max MSS value on the ACE with a connection parameter map and apply that parameter map to the VIP.

CSCub47038—When you load the A5.0.33 NPE appliance image to the ACE, the ACE appliance goes into an infinite reload loop. Workaround: None.

CSCub56420—When an echo request (with the Routing Header Type value of 0 and Segment Left value of 0) is received by an ACE, it does not respond with ICMP parameter problem. Ideally, the should discard the echo request and send an ICMP Parameter Problem: Code 0, message to clients's Global Address. Workaround: None.

Software Version A5(2.1) Open Caveats

The following open caveats apply to software version A5(2.1):

CSCtx12159—The ACE becomes unresponsive and reboots with the last reboot reason of "CP kernel crash." Workaround: None.

CSCty02827—The primary ACE30 running ACE software version A4(2.2) crashes with the last boot reason as "NP 1 Failed : NP ME Hung". Workaround: None.

CSCty58098—The ACE when configured with a class map containing wildcards within the regex expression match string may result in an inconsistency in the matching criteria. Workaround: None.

CSCtz47012—When the ACE is running on a bridged mode, the FT goes into the down state because the multicast packets cause a loop with the Real Time Streaming Protocol (RSTP). Workaround: None.

CSCtz78330—When you configure an HTTP probe with the request method GET and send the server response in more than one data packet, the ACE sends a RST and the HTTP probe fails with the status code 200ok and the last disconnect error "Unrecognized or invalid response". Workaround: Change the request method to HEAD.

CSCua07021—Under normal operating conditions, the ACE module reboots with the last boot reason Service: TACACS Daemon and generates a tacacsd core file. Workaround: None.

CSCua13827—Continuous and excessive traffic to the CP affects the performance of the CP and causes functions (such as probes) to fail. Workaround: None.

CSCua54940—In a HA pair of ACE 30 modules, the HA process is stuck on the Active ACE. The CP fails to notice the crash and does not send any HA messages to the other CP, which results in the ACE pair to be in an Active-Active state. Workaround: None.

CSCua77618—The ACE module reloads without generating any core file. Workaround: None.

CSCua84753—When you configure an ACE module in FT with 16K Rservers configured and probes enabled, the ARPMGR busy messages are displayed with MTS queue filling up high CP traffic. Workaround: Reduce the amount of traffic towards the CP.

CSCua9011—When simultaneous script sessions (four/five) are running continuous telnet login and logout to management port for more than four hours, the VSH processes are not cleared even after exiting from the telnet. Workaround: None.

CSCub18452—The SNMPD process on both active ACE and standby ACE crashes and generates a core file. Workaround: None.

CSCub43916—When you change the service policy from the global mode and apply it to the VLAN interface, the ICMP to the VIP starts failing continuously while load balancing traffic works fine. Workaround: Reapply the service policy after some time (approximately after 30 minutes).

CSCub43983—The ACE CP is not reachable on the network which affects all ARP entries and results in the ACE losing all routes. This problem affects the traffic through the ACE and the applications running at the backend which happens when the communication between the internal ACE components (CP and NP) is blocked because of the VERNI FPGA interface. Workaround: None.

CSCub43986—The Standby ACE goes into the STANDBY_COLD state with the following error message:

Unknown:FT Vlan Down or TL down. 
 
   

Workaround: None

CSCub51545—The HTTP requests with front-end SSL and multiple SSL records are dropped when the -shttp counter "Exceed max buffer errors:" increments. This problem occurs when the HTTP request have 10 or more headers, and each header is encrypted in its own SSL record in the HTTP request. Workaround: Configure a larger header max parse length.

CSCub61401—The ACE30 module crashes and generates two core files snmpd_log.1033 and snmpd_log,1035 with the last boot reason: Service snmpd. Workaround: None.

CSCub71303—Although identical ARP entries for RSERVER exist on the active and standby ACE, the active ACE can ping the ip address of the RSERVER but the standby ACE cannot. Workaround: Delete the ARP entries for the RSERVER IP address on the active ACE. This process triggers the arp requests from the ACE and adds RSERVER IPs as "LEARNED" entries on both active and standby. A ping from the standby ACE then works successfully.

CSCub82057—When an ACE running the software version A5(1.2) restarts, the IFMGR log file is generated with the exit code "signal 4 (core dumped)" in Service ifmgr. Workaround: None.

CSCua83798—When you configure a sticky group of type rtsp-header, open a Telnet session and send RTSP requests (OPTION, DESCRIBE, SETUP, and Play), a wrong rserver gets inserted in the RTSP sticky entry.

CSCub09577—ACE reuses the sticky entry before reaching the maximum sticky resource usage limit. Workaround: None.

CSCub83580—When an ACE uses ssl client authentication and if the number of concurrent accesses exceed 100 -200 TPS, few accesses fail due to certificate revocation. Workaround: None.

CSCub86891—The ACE fails to update the window size even after receiving the acknowledgement from the server. This problem occurs when the client sends large POST packets with less MSS. Workaround: Increase the TCP buffer-share value.

CSCub88717—After a NAT pool is removed from an interface, the entry still remains in the routing table as "N" entry. In a configuration where 20 or more VIPs are configured on an ACE that uses the same class map and NAT pool IP address, and you remove the NAT pools from the interface first, the entry still remains in the routing table. Workaround: None.

CSCub89648—The ACE does not support the MIB object cesRserverLocality when you run the snmpwalk command on a cesRserverTable. Workaround: None.

CSCub90808—The ACE reloads with the reason "NP1 Failed: CP Initiated Crash". Workaround: None.

CSCub95867—In an active ACE, the following error message is displayed when you enter the show tech-support command using XML. Workaround: None.

CSCub96733—The ACE (when configured with SSL sticky) crashes when dynamic configuration entries are made to SSL configuration, and the show serverfarm command is entered. Workaround: None.

CSCuc04894—The ACE reloads without generating the core file and displays the crash reason as "Unhandled kernel unaligned access or invalid instruction". Workaround: None.

CSCuc05001—The ACE reloads with last boot reason as "Reserved instruction in kernel code" seen in the show version output.

CSCuc05426—The snmpbulkget command times out if the max-repetitions exceed 70. Workaround: None.

CSCuc06322—Which you configure sticky entries in multiple context, the entries in the context point to the rservers that are configured in context 1. Workaround: Reboot the ACE.

CSCuc06329—When probe fails, the sticky entries are not inserted due to lack of resources and the following system log message is displayed:

%ACE-LB_STICKY-3-728007: Internal communications error (sticky) -- type 4 
 
   

Workaround: Perform a failover or reload the ACE.

CSCuc19624—The ACE does not pass IPv6 multicast traffic when running on a bridged mode. Workaround: None.

CSCuc23470—The ACE module when running on bridged mode sends ICMPv6 NA response to VLAN A and VLAN B. The ICMPv6 response is received by VLAN A only. However, ACE understands that the response is received by VLAN B instead of VLAN A. Workaround: Configure IPv6 neighbors statically.

Software Version A5(2.1) Command Changes

Table 10 lists the command changes in software version A5(2.1).


Note For a summary of new features for software version A5(2.1), including the associated new or modified commands, see the "New Software Features in Version A5(2.1)" section.


Table 10 CLI Command Changes in Version A5(2.1) 

Mode
Command and Syntax
Description

Configuration

url rewrite

The url rewrite command enables the ACE to rewrite URI/URL pathnames in HTTP requests. See the "Configuring HTTP URL Rewrite" section for more details.

RADIUS Sticky Configuration

enduser-v6-prefix-length

The enduser-v6-prefix-length command is used to configure prefix length for end user packets from the radius sticky mode. The valid prefix range is 1 to 128 bits. The default range is 64 bits. See the "Related CLI Changes" section for more details.

Configuration

resource usage-threshold

The resource usage-threshold command is used to configure the resource usage threshold. See the "Bandwidth and Active SSL Connections" section for more details.

Configuration

system-level

The system-level command determines the resource usage threshold configured at the system level. See the "Bandwidth and Active SSL Connections" section for more details.

Exec

show nat-fabric

The show nat-fabric command determines the NAT pool utilization displays the following information: User Pool ID, NP Utilization, Lower/Upper Ip Addresses fields, and Context name. See the "NAT Pool Utilization" section for more details.


Software Version A5(2.1) System Log Messages

Software version A5(2.1) includes the following system log (syslog) message changes:

445004

Error Message    %ACE-5-445004
Current Bandwidth usage[98%] exceeds configured high threshold[95%] at system level
Current Bandwidth usage[1%] falls below configured low threshold [10%] at system level
Current Bandwidth usage[78%] within configured threshold limits at system level
Current Active SSL connections usage[98%] exceeds configured high threshold[95%] at system 
level
Current Active SSL connections usage[78%] within configured threshold limits at system 
level

Explanation    The syslog notifications (at system level) when enabled are generated along with the SNMP notifications.

Recommended Action    None required.

445005

Error Message    %ACE-5-445005: 
Current Bandwidth usage[98%] exceeds configured high threshold[95%] at context level, 
context Admin
Current Bandwidth usage[1%] falls below configured low threshold [10%] at context level, 
context Admin
Current Bandwidth usage[78%] within configured threshold limits at context level, context 
Admin

Explanation    The syslog notifications (at context level) when enabled are generated along with the SNMP notifications.

Recommended Action    None required.

Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages

This release note includes resolved and open caveats 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 A5(2.0):

Software Version A5(2.0) Resolved Caveats

Software Version A5(2.0) Open Caveats

Software Version A5(2.0) Command Changes

Software Version A5(2.0) System Log Messages

Software Version A5(2.0) Resolved Caveats

The following resolved caveats apply to software version A5(2.0):

CSCtd33226—The SNMP daemon can be very slow to respond (for example, a delay of approximately 10 to 15 minutes) when the ACE receives a malformed SNMP packet or there is a heavy utilization of SNMP polls. Workaround: None.

CSCtf28855—If you configure the no inservice standby command under a real server, when you reboot the ACE, the running-configuration file incorrectly lists "inservice standby" in the configuration file. The running-configuration file should be the same as before and after the reboot of the ACE. Workaround: None.

CSCtg87855—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.

CSCth20813—In a multi-threaded code, some calls are unsafe and may cause the ACE to reboot. Workaround: None.

CSCth67961—When you enter the show snmp group command from any context other than the Admin context, it does not display any output. Workaround: None.

CSCth77759—The CSS2ACE conversion link can be directly accessed with a non-Admin role. Workaround: Access the CSS2ACE conversion link from the ACE main index page.

CSCti85313—When using the sticky-serverfarm command to specify that all requests that match a Layer 7 policy map are load balanced to a sticky server farm, if a server farm goes down, the ACE fails to display the following system 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
 
   

Workaround: None.

CSCtj18833—When you configure an ACE in a bridge mode which has a static ARP entry for the real server, and after the ACE reboots, the ARP entry for a real server is in the down (dn) state. Workaround: Remove the static entry and readd it.

CSCtj24719—When the ACE has mixed TCP and UDP SIP traffic running at a high rate for five to six hours to a combination of Layer 7 and Layer 4 VIPs, the show serverfarm name command may display some real servers with current connections after the traffic has stopped and the connections have closed. Workaround: None.

CSCtj60979—The ACE suddenly reloads with the reason identified as "me-dumper crash." In rare cases, the show np 1 me-stats command causes the me-dumper crash.Workaround: None.

CSCtk12683—All SSL probes on the ACE fail with the following reason: "No SYN/ACK returned from server". However, if you perform a trace, the trace shows that the TCP SYN from the ACE is not on the wire. This behavior is due to a configuration change that caused the access control list (ACL) to be downloaded to the internal VLAN 4095. The ACL failed, causing the Data Plane (DP) to reject the TCP SYN for the SSL probes being sent by the Control Plane (CP).

Workaround: Reboot the ACE. If this action does not resolve the issue, try another configuration change to force the ACL to be downloaded again to the internal VLAN.

CSCtk68122—When you configure the least loaded predictor in a server farm, the ACE does not set the autoadjust average option. Workaround: None.

CSCtl20133—When you enable the logging persistent command, it allows the ACE to save a specified syslog to its flash memory. As expected, the ACE creates a "messages" file on disk0. However, after you delete this file, the logging persistent command does not work again until you remove and reconfigure the command. Workaround: Remove and reconfigure the logging persistent command.

CSCtl76773—When you create a real server, class map, policy map, KAL-AP tag, server farm, or context name that includes a space in it, an ACE redundant configuration can become out of synchronization. Workaround: Do not use spaces when naming an object on the ACE.

CSCtn31362—When remote AAA server are configured in multiple contexts and XML requests through HTTP are sent to multiple contexts, occasionally the ACE reboots when the AAA daemon becomes unresponsive. For this configuration, the structure for the session is getting freed. After freeing, the session.vcid element is used for printing causing the AAA daemon to become unresponsive. Also the other local variable is used for printing. Workaround: None.

CSCtn78507—When either a SIP or RADIUS protocol-related configuration is present on the ACE that requires per-request load balancing, the ACE does not generate a connection teardown syslog and any translation syslogs that the ACE generates have a corrupt IP address. Workaround: None.

CSCtn98107—When you configure the ACE for redundancy with many contexts and some of these contexts have large configurations, and then you reboot the ACE, a context transitions to the STANDBY COLD state. The FT-related output did not display the correct command that failed in the context. Workaround: Perform the no inservice command and then the inservice command on the FT group. For the context in the STANDBY COLD state, assign it with a context ID number greater than one.

CSCto02825—The ACE allows users to configure inconsistent netmasks and fails to notify them of the inconsistency. For example, in this case the access-lists have inconsistent netmasks:

access-list acl1 extended deny ip any 10.45.15.192 0.0.0.15
access-list acl1 extended deny ip any 10.45.15.192 0.0.9.0
 
   

Workaround: Manually unconfigure the objects (such as access-lists) that have an inconsistent netmask and then reconfigure them with consistent netmasks.

CSCto45906—Each time that the standby ACE reboots, a context on it transitions to the STANDBY_COLD state and the ACE displays the following error:

Error on Standby device when applying configuration file

It is a timing issue due to the configuration size and total number of contexts. This issue can lead to a lot of Configuration Manager (CFGMGR) download processing which can lead to a command failure. CSCtn50357 is tracking the issue of the actual failing command that is not properly placed in the error logs. Workaround: Perform either of the following:

On the FT group for the context in the STANDBY_COLD state, enter the no inservice command followed by the inservice command.

Change the context FT group ID in the FT group to a higher number so that the context with the largest configuration does the configuration synchronization last.

CSCto54476—When an SSL certificate or key is in use on the ACE, you can delete it. Workaround: Before removing the certificate or key, manually verify whether it is being referenced in the configuration.

CSCto58886—When the ACE detects a bad DRAM component on the NP, it does not generate syslogs due to the corruption caused by the bad hardware. Workaround: None.

CSCto65011—When you configure SUP SVI as the gateway to the ACE module, the client fails to reach the ACE module.

Workaround: Configure the gateway farther from the switch and use SUP as the L2 device.

CSCto77306—The following warning message is displayed when MTS messages to a command shell are processed (while executing an user command).

Warning:- MTS queue is full for opcode %d sap %d pid %d clear idle debug plugin 
sessions or telnet/ssh connections to recover"

Workaround: Close all the debug plugin sessions and terminate command execution in all telnet/ssh connections to prevent these warning messages.

CSCto91249—When you enter the show parameter-map command to list all of the parameter maps in the context and the first parameter map in the list is a connection type, the ACE does not display all of the parameter maps. Workaround: None.

CSCtq32935 —When you configure an ACE with multiple classes (maximum of three classes) under the same policy-map type load balance, the source addresses of the subnets in these classes do not match. The ACE load balancing process fails and the subnet with the highest class map is considered. Workaround: When you configure multiple classes, the source address for all subnets should be same as the address defined in first class.

CSCtq59860—When you configure an SNMP engine ID that is applied to both the active and standby ACE using the CLI command snmp-server engineid value, the Network Management Station (NMS) does not know which ACE to connect to. Workaround: Use the following CLI command snmp-server engineid value per engineid value.

CSCtq60293—You can configure Simple Network Management Protocol (SNMP) user information by specifying a peer privacy password for user authentication parameters or user encryption parameters. When you configure an ACE with "snmp-server user" profile (with or without the privacy password), and configure each module with a unique SNMPv3 "engineid", the standby ACE reloads. Upon a switchover from an active ACE to the standby ACE, the snmp-server user command privacy passwords synchronize between the active and standby ACEs. This results in the SNPv3 access failure to the standby ACE.

Workaround: Use the peer engine id for the configuration.

CSCtq63901—When you configure long probe names, long server farm names, and long real server names, the probe server farm or real server length can become too large (greater than 128 bytes) and the ACE can encounter a problem parsing the ciscoSlbHealthMonMIBObjects MIB object. In this case, when the ACE attempt to poll the ciscoSlbHealthMonMIBObjects, an SNMP query timeout will occur or there will be missing probe information. Workaround: None

CSCtq63912—SNMP traps are not sent when the SNMP trap queue is full. When this situation occurs, the ACE displays the following error messages:

snmpd[1027]: (ctx:9)send_notification: new: enqueueing notification........ 
snmpd[1027]: (ctx:9)ERROR: notif_enqueue_tail : Size of the notif queue is more than 
the MAX size 250 
 
   

Software version A4(2.3) increased the queue size from 250 to 2000 and added new a counter in the show snmp command output to print the number of traps dropped because of a full SNMP queue. Workaround: None.

CSCtr36240—With the ACE configured for end-to-end SSL, if the backend server sends its full encrypted payload to the ACE, followed by an SSL close notify and a TCP RST, the ACE forwards the full payload to the client but then forwards the TCP RST to the client without sending an SSL close notify. Workaround: None.


Note This issue can also occur with non encrypted servers sending a RST.


CSCtr40282—Under normal operation with regexp resources in use, the clear stats resource-usage command may fail to clear the regexp peak counter. Workaround: Reload the ACE.

CSCtr44960—The HTTP response header for a CRL download fails if the server sets 'Content-length' instead of 'Content-Length' (lower-case "l" instead of an uppercase "L). When this happens, the ACE fails in downloading the CRL file and returns the following error:

%ACE-6-253008: CRL My_CRL could not be retrieved, reason: invalid format of data
 
   

Workaround: None.

CSCtr66995—When you configure real servers in server farms and run a checkpoint rollback for couple of times, ACE reloads due to insufficient memory. Workaround: None.

CSCtr69215—When the ACE is servicing a high volume of traffic, has sticky configured, and the show tech command is executed continuously on the control plane, the ACE may become unresponsive.

Workaround: None.

CSCtr77030—With Network Address Translation (NAT) and Port Address Translation (PAT) configured in the ACE, the ACE may become unresponsive and reload. When this behavior occurs, network processor files indicate a duplicate buffer release in the transmit module. Workaround: Configure NAT and PAT in separate pools of global source addresses.

CSCtr93395—When UDP Booster is enabled on the ACE to load balance DNS traffic, the source IP address does not appear in the show conn command output.

CSCtr93395—When UDP Booster is enabled on the ACE to load balance DNS traffic, the 
source IP address does not appear in the show conn command output.
host1/Admin# show conn
conn-id    np dir proto vlan source               destination           state
----------+--+---+-----+----+---------------------+---------------------+-----
101646    1  in  UDP   302  0.0.38.114:0         80.58.61.250:53       -
 
   

Workaround: None.

CSCts07333—During a configuration change on the ACE, the ACE reloaded because the cfgmgr becomes unresponsive. This behavior could be due to a memory corruption problem. Workaround: None.

CSCts09006—Under normal operations with SNMP, the ACE unexpectedly reloads and generates a core file. Workaround: None.

CSCts24977—The service name:snmpd(1395) terminates upon receiving signal 8. This issue can occur when polling the ACE CPU utility MIB in a loop; the snmpd process can become unresponsive and cause the ACE to reload. For this particular issue, the OID polled was .1.3.6.1.4.1.9.9.480.1.1.7.1. Workaround: Do not poll the ACE CPU utility MIB continuously in a loop.

CSCts29208—With one or more sticky groups and failaction reassign configured under one of the server farms, the ACE may experience the load balance issue while incrementing real server connection counts. Workaround: When this behavior occurs, do not configure the failaction reassign command with the server farm.

CSCts35635—A denial of service vulnerability has been found in the way the multiple overlapping ranges are handled by the Apache HTTPD server. Multiple Cisco products could be affected by this vulnerability.

Mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this Advisory:

http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=24024

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110830-apache.shtml.

PSIRT Evaluation:

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 7.8/7.8:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:H/RL:U/RC:C

CVE ID CVE-2011-3192 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

CSCts43521—The ACE requires measures to mitigate the effect of CVE-2004-0230. Part of the measures are already in place; however this bug tracks the implementation of the full set. Workaround: None.

PSIRT Evaluation:

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5.0/4.3:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C

CVE ID CVE-2004-0230 has been assigned to document this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

CSCts44219—The ACE is configured with access control lists (ACLs) which reference object groups. The ACL is part of a policy which is applied globally or to an interface. When dynamic changes are made to the ACL or object group, the following ACL merge error may occur:

"%ACE-1-106028: WARNING: ACL Merge failed to add ACE..."    and this leave the service 
policy incomplete and can cause traffic to be mis-handled.
 
   

Workaround: Perform one of the following actions:

Delete the ACL which logged the merge error, reconfigure the policy, and reapply.

Reboot the ACE.

CSCts50072—When running an ACE module for over 100 days under normal conditions but with a large configuration, the ACE warns of low memory. Workaround: Reduce the size of the configuration. Reboot the ACE when the memory falls below one percent.

CSCts66857—When you enter the no command with the full match statement, or without the line number for "match anyv6", or vice versa as shown in the following example,

no 2 match anyv6
no 3 match port- v6 tcp range 6 600
no 2 match any

You cannot apply the "match port tcp/udp...." after removing the "match anyv6" config from the L3/4n/w traffic class map. The following error message is displayed:

Class contains Ipv6 match statement

Workaround: Use the no command with the line number only.

CSCts99950—With backend SSL configured on the ACE, the ACE may become unresponsive and generate a core file. Workaround: None.

CSCtt08380—After experiencing packet loss, the ACE inconsistently sends ACKs. This behavior is due to the length of reassembly queue in TCP (32 buffer particle). With software version A4(2.3), this length has been tied to the size of rcv-wnd (typically 64 buffer particle). Workaround: None.

CSCtt08473—In an Admin context configuration with a big banner, the config sync between the Active and Standby ACE fails with the Standby ACE stuck in the STANDBY_CONFIG state. After four hours, the HA config sync times out, and the Standby ACE changes to the STANDBY_COLD state. The show proc cpu command displays the config_cntlr process with more than 50% of CPU utilization. Workaround: Remove the banner from the running and startup config of the context.

CSCtt24046—When the ACE performs multiple simultaneous SNMP requests on the cpmProcessTable, this may result in an SNMP timeout. Workaround: Perform only sequential SNMP requests on the Cisco Process MIB.

CSCtt30579—When you use the show cfgmgr internal table slb-policy command, the output incorrectly displays all the entries as invalid. Workaround: None.

CSCtt33804—During a modification of an ACL within a context, an ACL merge error may be reported on one or more of the interfaces where the ACL list is applied, leaving the interface in an inconsistent state. When this issue occurs, the following system message appears:

%ACE-1-106028: WARNING: ACL Merge failed to locate specified ACL in context 10049. 
Error while processing service-policy. Incomplete rule is currently applied on 
interface vlan200. Configuration on this interface needs to be manually reverted

Workaround: Perform one of the following actions:

Remove the offending lines one at a time from the ACL until the ACL can be successfully applied.

Reload the ACE.

CSCtt61028—When operating in a redundant configuration, SSL probes fail intermittently even if the ACE module is in standby mode. Workaround: Reload the ACE.

CSCtt76277—In a redundant configuration, the standby ACE module is in an active state when it is reloaded from the Catalyst supervisor engine through the no power enable or hw module reset command. Workaround: Perform one of the following actions:

-Create the file "skip_reset_cde_hash_table" by specifying the following command sequence on the Catalyst supervisor engine:

show clock > disk0:skip_reset_cde_hash_table

Note When the fix is out, be sure to delete the file with the del disk0:skip_reset_cde_hash_table command.


Configure an input ACL on the ACE VLAN interfaces to deny multicast traffic. For example, enter:

access-list deny_mcast line 10 extended deny ip any 224.0.0.0 240.0.0.0 
access-list deny_mcast line 20 extended permit icmp any any 
access-list deny_mcast line 30 extended permit ip any any
 
   

CSCtu10624—Establishing a Telnet connection from the ACE to a remote device is silent with no indication of a successful connection or DNS resolution. When this occurs, the lines "trying ..." and "connected..." are not seen. Workaround: None.

CSCtu18281—The restore process may fail if the Admin context in the backup configuration has TACACS authorization and the configuration is associated with a domain (add-object command). When this issue occurs, the restore process fails and the non-Admin contexts are not imported. However, for the Admin context, the configurations are properly applied. Workaround: Remove "domain TACACS" from the backup configuration and perform the restore.

CSCtu33484—When setting the idle timeout on the ACE, an extra second is added for every minute of idle time. When this issue occurs, the connection disappears from the statistics on the configured time. The reset is not sent until the idle time plus the extra time expires. Workaround: None.

CSCtu34037— User context configurations (including certificates and keys) are lost after the ACE reloads. When this issue occurs, the Admin context configuration is reduced to the minimal, initial configuration. This issue can occur when you specify the reload command, or if the FT link is interrupted by high CPU usage on the switch that the ACE is connected to. Workaround: None.

CSCtu36146—The ACE becomes unresponsive due to a configuration manager (Cfgmgr) process failure with the last boot reason: Service "cfgmgr."

The following example system error log messages may appear shortly before the ACE reloads:

MG6509:7:Admin 443001 Critical 24-Oct-2011 08:29:09 System experienced fatal 
failure.Service name:cfgmgr(1050) has terminated on receiving signal 11,system will 
not be reloaded 
MG6509:7:Admin 443001 Critical 24-Oct-2011 08:30:23 System experienced fatal 
failure.Service name:cfgmgr(1050) crashed, last core saved,system will not be reloaded
MG6509:7:Admin 199006 Critical 24-Oct-2011 08:30:31 Orderly reload started at Mon Oct 
24 13:30:28 2011 by System. Reload reason: Service "cfgmgr"

Workaround: None.

CSCtv17196—The show script code command returns an invalid call. Workaround: Reboot the ACE.

CSCtw54107—The ACE requires the ability to display the hidden parameter of a server farm when using the show cfgmgr internal table sfarm det command

CSCtw70949—Currently, the ucdump -w a debugging command does not show the allocated buffers. This debugging command display incorrect output. Workaround: None.

CSCtw76940—You may find that double quotations in a description are replaced by spaces. For example, if you configure description t"e"st, this description is displayed as (config-sticky- in the show running configuration command output as follows:

(config-if)# description t"e"st
(config-if)# do sh run | i desc 
Generating configuration....
  description t e st

You may encounter this behavior when strings between double quotations do not include a space. This show output display issue does not occur if you insert a space between the double quotations (for example, description t" e"st). In this case, a space is inserted between " and e. For example:

(config-if)# description t" e"st
(config-if)# do sh run | i desc
Generating configuration....
  description t " e" st
 
   

Workaround: None.

CSCtw79419—An error occurs when you attempt to delete a server farm, and the ACE prevents you from performing the deletion. This behavior can occur when the ACE configuration manager still associates the server farm with a load-balancing policy. For example:

ACE/1(config)# no serverfarm host 2081bancaPR
Error: serverfarm 'SERVERFARM_X' is in use. Cannot delete! 

Workaround: Reboot the ACE.

CSCtw81056—When performing Layer 7 load balancing with TCP server connection reuse enabled, you may find that intermittent client connections are reset. Traces show a Reset from the backend server occurring immediately after the ACE forwards the client's GET request on the backend. The ACE attempts to reuse a connection on the backend server that was closed on the server. Prior to this failure, the server attempted to close an inactive backend connection, but the ACE ignored and dropped the Fin Ack packets received from the server. Workaround: Reboot the ACE.

CSCtx03563—If the ACE has been operating for approximately 150 days, you may find that it may produce huge httpd logs over time when you use the XML interface. This behavior causes the file system to become full and the following messages may appear: "write error: No space left on device." If ACE reloads when in this state, and you save the configuration on reload when prompted, this action will cause the ACE to wipe all configurations. Workaround: Perform the following actions:

Do not save the configuration when prompted on reload.

If necessary, contact Cisco TAC to provide a workaround script.

CSCtx19842—An ICMP packet with asymmetric routing is dropped by the OCM on the ACE module. When the ICMP packet goes out and comes in on different interfaces of the ACE module at the server side, the packet is dropped at the incoming interface because there is no matching connection for the ICMP reply connection.

For example:

host1/Admin# show np 1 me-stats "-s ocm"
OCM Statistics: (Current)
--------------
(snip)
Drop [redundant connection]:                     38             0

Workaround: Configure the client NAT to force the servers to send the response back on the same interface.

CSCtx20459—When you specify the show system resources command, CPU states values are shown as "nan%". For example:

ACE/Admin# show system resources 
Load average:   1 minute: 0.10   5 minutes: 0.05   15 minutes: 0.01
Processes   :   5606 total, 1 running
CPU states  :   nan% user,   nan% kernel,   nan% idle  <<<<<<<<<<<<<
Memory usage:      5955K total,      1623K used,      4331K free
                     21K buffers,     858K cache
Average ME Utilization Statistics 
 
   

Workaround: None.

CSCtx27638—The ACE may suddenly display the following log message with no operational impact:

%ACE-3-251006: Health probe failed for server x.x.x.x on port nnnnn, internal error: 
failed to setup a socket    

Workaround: None.

CSCtx45830—In a redundant configuration, the config sync process fails because of an expired user account configured on the ACE. This issue occurs when a user account is configured with a specified expiration date in the past (with reference to the ACE system clock), the ACE displays the error message "date should be in the future, expiry date wrong" and the configuration is then rejected. Workaround: Remove the expired user account from the active ACE configuration.

CSCtx53490—In a redundant configuration, the ACE may generate a high volume of Generic Attribute Registration Protocols (GARP) which result in a high CPU load. In this situation, the he ACE will not stop sending the GARPs until you reload it. This behavior can occur under the following conditions:

The ACE is running software release A4(2.1) or later.

Your configuration includes: two ACEs in FT setup with FT preemption enabled, host tracking for a default-gateway of which the ARP can not be solved, and SNAT.

All ARP entries of real servers and default-gateway devices have the ARP entry type of VIP(SNAT) as "NAT" instead of "VSERVER".

Workaround: To resolve this issue, address one or more of the configuration items listed above.

CSCtx55728—In a redundant configuration, the ACE30 module unexpectedly reloaded and generated a Network Processor (NP) core file. In this case, the ACE30 module was an Fault Tolerant (FT) peer running software version A4(2.x) to the ACE20 module running software version A2(3.4). Workaround: None.

CSCtx58666—The ACE displays the "internal error: failed to setup a socket" error message when it is unable to send a probe due to a network issue. Workaround: None.

CSCtx59909—If you log into the ACE appliance Device Manager GUI using the "admin" username with custom role permissions within a context, when you attempt to change the configuration, you may see a popup window that displays the following error: "Failed to deploy config to device: Infringing CLI command: with reason: reached max checkpoint limit 10."

Workaround: Do not use "admin" as the username within the sub-context. Any other username will not trigger this error message.

CSCtx64223—When there are more than 255 characters in the SSL Subject (with 255 being the maximum value), certain characters in the SSL Subject are then omitted. Workaround: None.

CSCtx76894—If you try to import a license while the /isan/ partition is full (due to CSCtx03563), the import will fail because the file copied in the partition is empty. This issue will also cause issues with the liccheck process when it tries to parse an empty file. Workaround: Reload the ACE and try to import the license again.

CSCtx92484—During a Layer 7 file transfer is terminated after transferring approximately 16 kB of data. Workaround: Configure an HTTP parameter map and set the content-maxparse-length and header-maxparse-length to larger values. For example:

parameter-map type http PM-HTTP
  persistence-rebalance
  set header-maxparse-length 65535
  set content-maxparse-length 65535

Note If you set the set content-maxparse-length or set header-maxparse-length command in HTTP parameter-map configuration mode to a value that is greater than 32 KB, you must configure the set tcp buffer-share command in a connection parameter map to a value that is greater than either of the other command's value. If you do not, even if you configure length-exceed continue command, the ACE may not completely parse a content string or a header packet that is greater than 32 KB. The reason is that the default value of the set tcp buffer-share command buffer size (32 KB) will not accommodate the larger content string size


CSCtx96626—In a redundant configuration, when multiple track priorities are configured in an FT track host configuration, you may find that some track states are TRACK_DOWN. In this case, the FT track priority is not properly decreasing as expected after the ACE reboots. Workaround: Reconfigure the FT track priority using the probe [probe_name] priority [priority] command or change all track states from TRACK_DOWN to TRACK_UP.

CSCty01285—With the ACE configured for SSL termination with client authentication and OCSP, when the ACE makes an OCSP request to the OCSP server, the server responds with a certificate status of unknown. Workaround: Disable OCSP.

CSCty01615—Under normal operating conditions, you may find that the ACE corrupts packet data when reassembling the packets. Workaround: None

CSCty11329—In a redundant configuration, while attempting to remove a virtual IP address from a class map, both the active and standby ACE appliances reboot and create a cfgmgr core file. Workaround: None.

CSCty14193—If the ACE receives an ACK with 1 greater than the current sequence number, the ACE responds with its own ACK instead of ignoring the received ACK. If the rate of these ACKs are high enough, this situation can lead to buffer depletion. Workaround: None.

CSCty24597—In a redundant configuration, with the ACE configured as a Fault Tolerant (FT) peer, when the FT state is being established it may fail several times due to a select error before correctly going from ACTIVE to STANDBY. Workaround: None. The error is logged, but the FT peer eventually comes up normally.

CSCty29030—Few ssh sessions fail to respond on the ACE as the LAN Management System (LMS) is always responsive with the TCP keepalive. This holds good when the sessions are closed on the LMS side. Workaround: Change the parameter on the ACE sshd.conf from ClientAliveInterval0 to ClientAliveInterval300. The ssh session will log out if it is active for 300 seconds.

CSCty47743—In a redundant configuration, if you configure a description under an interface that contains a valid ACE command, the bulk synchronization script may parse the description as a command, change it, and attempt to apply it to the configuration. For example:

interface vlan X
  description Admin context Mgmt VLAN IP address
 
   

On the standby ACE, the "IP address" section is parsed as an actual command and changed to the peer ip address command. When the ACE applies this command, it fails because the command is incomplete. The following config synchronization error appears:

cdn-ace--2/Admin# sh ft config-error
Tue Mar 6 22:56:56 CET 2012
`peer ip address`
*** Context 5: cmd parse error ***
--
*** Context 5: Config can not been applied fully. Please try again***
 
   

Workaround: Remove or modify the description string. For example, insert a dash (-) or underscore (_) instead of using a space

CSCty60596—If you configure an ACE with the same VIP that listens on two separate ports, with both VIPs performing server-conn reuse using the same server farm, once one VIP receives the traffic this can result in operational issues with the other VIP. This behavior can occur because the ACE uses a real server ID to index to the reuse pool for sending the server connection to the pool or for retrieving server connection from the pool. Configuring the same server farm for both an HTTP policy and an HTTPS policy results in the ACE using identical real server IDs to index to the same reuse pool to store or retrieve the server connections for both HTTP and HTTPS traffic (ingress).

Workaround: In order for the ACE to generate two different real server IDs for the same real server to separately serve the HTTP and HTTPS traffic, create a new server farm to contain the same real servers. Associate one server farm to the HTTP policy and another server farm to the HTTPS policy. The ACE will generate two different real server IDs for this real server because it is configured with two server farms. The server connections for HTTP traffic are stored to and retrieved from the reuse pool indexed by one real server ID, and server connections for HTTPS traffic are stored to and retrieved from the reuse pool indexed by a different real server ID.

CSCty62216—If the amount of memory (HighFree) falls below five percent, SSH access is disallowed. Workaround: Reload the ACE.

CSCty77522—When you enter the show sticky database buddy command on the ACE module, the show command does not display the buddy entries properly. Workaround: None.

CSCty79229—When you remove specific configs from a sticky http content group, the no http-content in the http-content group deletes all the configs in that group, including the member. This results in member table leak. Workaround: Remove the member from the table before you enter the no command, and then add it back.

CSCty87543—The Configuration Manager (cfgmgr) process becomes unresponsive when a few buddy groups are grouped under real (buddy green) and you enter "no buddy".

Workaround: Use "no buddy green" instead of "no buddy.

CSCty91438—When you configure a SSL sticky group with the response token, the entries are created in the outbound direction from the server side. However, when the server sends a SSL session id, sticky entries are not created. Workaround: None.

CSCty91659—Cisco ACE with default configuration includes a version of Apache that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs: CVE-2012-0053. Additional details about the vulnerabilities listed above can be found at

http://cve.mitre.org/cve/cve.html.

PSIRT Evaluation:

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.3:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:P/I:N/A:N/E:U/RL:U/RC:UC

CVE ID CVE-2012-0053 has been assigned to document this issue.Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

CSCty97116—When you add or remove a member from the sticky group that has replicate sticky configured in that group, the sticky group is removed from the Context link list. The sticky entries in this group do not appear even after they are created.Workaround: Remove the replicate sticky before adding/removing a member from the sticky group, and then add the replicate group back.

CSCtz01656—When you run a combination of http, ssl, ftp, dns, sip & rtsp v4 SLB traffic with the inspect enabled at 1000 connections per second on an ACE module, the module reloads with the last boot reason "NP 2 Failed : NP ME Hung".

Workaround: None.

CSCtz06900—After you configure bannermotd #ACE30-performance ace6# on an ACE and reload the console, the following message is displayed every five minutes making the console unusable for configuration:

INIT: Id "T0" respawning too fast: disabled for 5 minutes  INIT: Id "T0" respawning 
too fast: disabled for 5 minutes  INIT: Id "T0" respawning too fast: disabled for 5 
minutes  INIT: Id "T0" respawning too fast: disabled for 5 minutes  INIT: Id "T0" 
respawning too fast: disabled for 5 minutes
 
   

Workaround: None.

CSCtz21908—The ACE database gets corrupted when you use a port redirection on the serverfarm and do a HTTP cookie insert based sticky in ACE30 module running ACE software version A5(1.1) or later releases. The ACE generates the same hash key value and same http cookie pointing to multiple server instances. Workaround: Use Static cookies.

CSCtz30731—When you configure an HTTP probe with the request method GET and send the server response in more than one data packet, the ACE sends a RST and the HTTP probe fails with the status code 200ok and the last disconnect error "Unrecognized or invalid response".

Workaround:Change the request method to HEAD.

CSCtz33568—The sticky entry is not created as the sticky group is not downloaded properly. Workaround: None.

CSCtz37185—When you configure an ACE with the MSS mismatch CLI in param-map and configure the server MSS less than the client MSS, the ACE sends a request for two or more packet responses from the client to server. The ACE transmits the first packet only and drops the other packet (which is an HTTP drop).

Workaround: None.

CSCtz37625—In ACE, the hidden command cfgmgr limit-regex-dnld enable is made visible and changed to limit-regex-dnld enable. Workaround: None.

CSCtz43740—When you use the sftp/tftp/ftp within copy command along with the password, the show accounting log command displays the password in a text format instead of the password being masked. The passwords used in the sftp/tftp/ftp within copy command are not masked. Workaround: None.

CSCtz44186—The following system message appears when the ACE appliance is

Running the software version A(51.0), has configured a large multi-match policy, and you attempt to apply the sevice-policy t0 the interface.

Running the software A4(1.0) has configured a large multi-match policy, and you attempt to upgrade to the version A5(1.0).

%ACE-2-443001: System experienced fatal failure.Service name:cfgmgr(1961) has 
terminated on receiving signal 11,system will not be reloaded    Service 
name:cfgmgr(1961) has terminated on receiving signal 11 The ACE will then reboot and 
generate cfgmgr_log core files.
 
   

Workaround: Revert to the software version A4(1.0) using the recovery image.

CSCtz45930—When the primary server farm is down and the backup server farm has a sticky keyword with the member group configured (that is, the backup server farm is operational), the buddy sticky do not stick to a particular server. The buddy sticky does not work as expected for the backup sticky server farm. Workaround: Do not configure backup server farm.

CSCtz61791—If the size of a reassembled IPv6 packet exceeds the Maximum Transmission Unit (MTU), the packet is dropped. This happens when the packet is reassembled in one Network Processor (NP) and transferred to another NP for processing. Workaround: None.

CSCtz68413—When you enter the show sticky database static command, the same entry is displayed twice. Workaround: None. This is just a display. Use the sh stats sticky command for the exact count.

CSCtz77264—When an ACE, running the software version A5(1.x), receives multiple fragmented packets, it reassembles these packets before forwarding them. If the reassembled packet is greater than the MTU of the outbound interface, and if the DF bit is set, then ACE will not forward the reassembled packets. Workaround: Use the command ip df clear to clear the DF bit, and permit the packet.

CSCtz82714—The ACE creates multiple sticky entries created for the same hash value. Workaround: None.

CSCtz86093—During the upgrade process of an ACE appliance, the SSL sticky synchronizes with the 512a image. This occurs when you configure the ACE appliance as follows:

Load the appliance with 512a and configure FT, and ensure that the appliance is in Active/Standby Hot state.

Upgrade the stand by ACE to A520 and ensure that the ACE is in the standby-warm state.

Do a FT-switchover and verify whether the appliance with the A520 image is active and the appliance with A512 is in the standby-warm state.

Configure SSL sticky groups and associate these groups under the https policy map.

The CLI is not synchronized with the standby appliance and the SSL sticky is reflected in the appliance with 512a.

Workaround: None.

CSCtz95887—The ACE does not allow you to configure a same member group under different sticky groups, and displays the following error message:

Cannot configure dissimilar sticky groups under same member

Workaround: None.

CSCtz99489—The TCP connections are not proxied when the SYN cookie is set and the MSS value does not match the MTU (that is, the MSS of the client is greater than the MSS of the server). This occurs in one of the following conditions:

When the minimum MSS value is set in the param-map type connection

When the SYN cookie is set in an ACE

The full-proxy-mss-mismatch CLI is added in the param-map type parameter

For example: If a syn attack is transmitted with the value more than the value set in SYN-cookie, the ACE sends SYN-ACK with a MTU of 536 bytes. If the MSS of the server is less than 536 bytes, a GET request is sent instead of SYN-attack. The ACE does not proxy the TCP connections.

Workaround: None.

CSCua06191—In a configuration that contains a large number of contexts, the ACE becomes unresponsive when you enter the clear sticky database all command. Workaround: Decrease the number of contexts in the configuration.

CSCua18838—When a probe is shared across several server farms, the show probe output is incomplete. The output does not list one or more server farms in the <CmdBold>show probe<NoCmdBold> or <CmdBold>show probe detail<NoCmdBold> output.

Workaround: Perform either of the following

Define another probe with the same characteristics and associate it to the missing server farm.

Use the following command with the correct probe to list the missing server farms correctly in the probe output: <CmdBold>show probe <NoCmdBold><CmdArg>probename<NoCmdArg>

CSCua23743—When a backup real server, configured with the same buddy as primary, is added or deleted, the buddy sticky entries are sent to different rservers. Workaround: Remove buddy from the backup real server.

CSCua26437—When the server response is chunked encoded and the VIP is configured for cookie-based sticky, the ACE may fail to forward the server response to the client. To determine if chunked encoding is present in the network, use the show stats http | inc chunk command to check if the HTTP chunks counter increases per context:

ACE/Admin# show stats http | inc chunk
HTTP chunks               : 0          , Pipelined requests       : 0
 
   

Workaround: Use IP-based stick.

CSCua35519—When you try to remove an existing VIP and add a VIP simultaneously through a script/interface, the old VIP is not deleted completely and appears in show arp command.

Workaround: Do not remove and add a VIP simultaneously.

CSCua38338—VIP stops when you use the connection: "Keep-Alive" with a large chunk response (~> 36KB) . Workaround: Use the connection: "close".

CSCua41824—When the ACE is configured with a large number of connections (approximately, more than Six Million for a module and 80,000 for an appliance), the module/appliance reboots when you execute the show np x me-stats "-call command.

Workaround: Do not execute the show np x me-stats "-call command with large number of connections.

CSCua48058—The ACE30 module crashes and generates two core files snmpd_log.1033 and snmpd_log,1035 with the last boot reason: Service snmpd. Workaround: None.

CSCua55846—When you add ACE30 to ANM, the ACE reloads. This occurs due to an overloaded buffer, which in turn overwrites the data pointer. Workaround: None.

CSCua64539—The ACE becomes unresponsive when you add and delete a "member" of the sticky group multiple times.

Workaround: None.

CSCua65007—When you perform SNMP polling continuously, the ACE starts running out of memory. Workaround: Free the allocated memory for the tnrpc response, thereby increasing the allocated memory.

CSCua65184—When you import the active and the standby ACE into more than two ANMs, the standby ACE reloads with the last boot reason service: snmpd. Workaround: None.

CSCua85445—When multiple snmpwalk requests are made along with the LB traffic for extended hours, the ACE reboots with the reason NP4 Failed: NP ME Hung. Workaround: None.

Software Version A5(2.0) Open Caveats

The following open caveats apply to software version A5(2.0):

CSCsq65274When you configure the HTTP header insert feature on the ACE, the configured HTTP header insert and the escape character is not translated properly. Workaround: None.

CSCti28299When an rserver reaches the MAXCONN state, ACE generates the SNMP trap cesRealServerStateUpRev1 instead of the cesRealServerStateChangeRev1 trap. Workaround: None.

CSCtt23176—You are using an ICMP probe attached to a transparent server farm, and the probe stops sending an ICMP echo request after about 12 hours of continuos operation. Workaround: Use a UDP or TCP probe.

CSCtx12159—The ACE becomes unresponsive and reboots, with the last reboot reason of "CP kernel crash." Workaround: None.

CSCtx27765—During the normal booting process, the ACE intermittently fails to reload due to NAT initialization. Workaround: None. ACE reboots and resumes the next reload.

CSCtx53917—The ACE A235 module fails to reboot if it is run with 20 contexts and has traffic on all contexts. Workaround: None.

CSCtx57994—After performing a software upgrade or while using software version A4(2.2), the ACE rebroadcasts a non-IP logical-link control (llc) broadcast packet generated by an IBM server. As a result, this action causes the ACE to believe that the IBM server now resides off the ACE switchport. When this behavior occurs, you will see the following message:

%MAC_MOVE-SP-4-NOTIF: Host <IBM-SERVER-MAC> in vlan XX is flapping between port 
<ACE-PORT> and port <SERVER-PORT> 
 
   

Workaround: If necessary, downgrade to an earlier version of ACE software.

CSCtx64126—The ACE contains static ARP entries even though no static ARPs have recently been configured. This issue may be related to static ARPs configured in the past and then removed. In this case, the ACE failed to remove the entries. Workaround: Readd the static ARP entry, and then remove it. This action will remove the static ARP from the ACE.

CSCty08887—The ACE resets a connection if the HTTP header is approximately 14K in length while the VIP configuration does not require HTTP parsing. Workaround: Create an HTTP parameter map that includes the set header-maxparse-length command followed by a proper value.

CSCty09558—When you configure multiple probes on the ACE and make the probes fail using iptables, the ha_mgr process in the ACE goes into an unresponsive state after the switchover is checked. Workaround: None.

CSCty18004—The HTTP probe fails if the data has the control character (NULL) "\0". This issue is not seen in a normal UNIX server from which the file is fetched but is seen only with IXIA because it can manipulate the data. Workaround: The data/header portion of the reply should not have a NULL character.

CSCty24258—Under normal operating conditions, the ACE module reboots during the Load Balancing process. Workaround: None.

CSCty37843—When you enter the show service-policy detail or show service-policy url-summary commands, the show service-policy command becomes unresponsive on ACE20 and only a part of the output is shown on the console. Workaround: Break the command by pressing <Ctrl-C>.

CSCty43331—Under a normal server load-balancing operation when you add or modify a virtual IP (VIP) address, you may find that the VIP addresses do not appear in the show cfgmgr internal table icmp-vip output. Workaround: Reload the ACE.

CSCty58098—With the ACE configured with a class map containing wildcards within the regex expression match string this may result in inconsistency in the matching criteria. Workaround: None.

CSCty58343—In a FT setup, when you do a checkpoint rollback to a blank config in an Active ACE, the standby ACE reboots with the cfgmgr.

Workaround: Shutdown or disable the FT interface and do a checkpoint rollback to an empty config in an active ACE module.

CSCty61047—When you configure DHCPv6 relay on an interface and use wide-dhcp IPv6 DHCP server as the DHCP server, the DHCP relay fails to function properly. Workaround: None.

CSCty70458—When you apply the configuration for front-end SSL, remove and then add an rserver under the server farm, and press Ctrl+C, the ACE crashes with the last reboot reason ME Dumper Process Crashed. Workaround: None.

CSCty96856—Under normal operating conditions, ACE reboots with the reason "ha_mgr". Workaround: None.

CSCtz17453—The syslogd process running on the ACE reboots when the Control Plane (CP) is under a stress test with multiple ssh/telnet/probe/xml/snmp scripts. Workaround: None.

CSCtz20802—When you configure a certificate or a key name using special characters during a backup process and use the show restore errors command, the restore process fails with the following message:

Component:Cert/Key" & "Error, decipher failed for keys
 
   

Workaround: Do not use special characters when you configure certificates and key names.

CSCtz27907—The HTTP probe fails if the data has the control character (NULL) "\0" as a part of the data. This issue is not seen in a normal UNIX server from which the file is fetched but is seen only with IXIA because it can manipulate the data. Workaround: The data/header portion of the reply should not have a NULL character.

CSCtz28887—When you use/configure "Admin" as a part of the name for a load balancing context, the FT synchronization fails, and goes into the FSM_FT_STATE_STANDBY_CONFIG state for a long time before moving to the FSM_FT_STATE_STANDBY_COLD state. Workaround: Do not include "Admin" in the name of a load balancing context.

CSCtz30476—When you configure a non matching regex in an HTTP probe, the probe passes and fails intermittently. The probe fails because the binary data response does not have the same regex configured. Workaround: None.

CSCtz30478—When you configure a non matching regex in an HTTP probe, the probe passes and fails intermittently. The probe fails because the binary data response does not have the same regex configured. Workaround: None.

CSCtz30667—When you configure a HTTP probe with expected regex, and sent the response from the server with "Len:" instead of "Content-Length:", the HTTP probe skips. Workaround: None.

CSCtz41341—During normal operation, the ACE reboots when generating the syslogd core file. Workaround: None. The ACE reboots and automatically corrects itself.

CSCtz42584—During normal operation, the ACE reboots when generating the syslogd core file. Workaround: None.

CSCtz42618—When real servers are down and you try to telnet to the VIP IP, a connection is established in the ACE because the ICM (Ingress Connection Manager) is not checking the VIP status. If you send another request, the connection is dropped with a L7 rejection.

Workaround: None.

CSCtz45804—When the ACE is running on a bridged mode, the FT goes into the down state because the multicast packets cause a loop with the real time streaming protocol (RSTP). Workaround: None.

CSCtz47000—On the ACE, when you enable the normalization feature on one interface and disable this feature on another interface, the user traffic is initiated from the former interface. Two IP addresses share a single mac address. ACE selects the encap id of a previously added IP address server which has no static arp entry. This results in ACE clearing/dropping the existing connection when the arp time is reached. Workaround: Disable normalization on both interfaces.

CSCtz47012—When the ACE is running on a bridged mode, the FT goes into the down state because the multicast packets cause a loop with the real time streaming protocol (RSTP). Workaround: None.

CSCtz47825—Under normal operating conditions, the ACE module with the HTTP probes configured reboots when allocating memory or parsing an HTTP probe response. Workaround: Change the HTTP probes to TCP probes, and reset the ACE.

CSCtz92969—When you configure "vlan internal allocation policy descending" on the supervisor engine, the "interface vlan 4094" appears in the admin context even though the vlan number 2094 is neither configured nor assigned to the ACE.

Workaround: Do not configure "vlan internal allocation policy descending" on the supervisor engine.

CSCtz96319—The ACE reboots when you do a checkpoint rollback on a config which has user "Admin" in a non-default domain. Workaround: None.

CSCua07021—Under normal operating conditions, the ACE module reboots with the last boot reason Service: TACACS Daemon and generates a tacacsd core file. Workaround: None.

CSCua13827Continuous and excessive traffic to the CP affects the performance of the CP, thereby causing functions, like probes, to fail. Workaround: None.

CSCua16421—The client does not receive large replies, approximately 1500 bytes, from VIP and PMTUD does not work. This is seen in the following cases:

Virtual IP is configured with a specific port

IPv6 is configured on the client side

IPv4 is configured on the rserver side

MTU on the path from ACE to client is lower than the MTU on the path from ACE to rserver.

Workaround: Perform either of the following:

Configure MTU on the path from ACE to rserver to be lower than the MTU on the path from ACE to client.

Limit maximum MSS for connections to rservers on ACE with the connection parameter map: parameter-map type connection NAME set tcp mss min 0 max <Maximum MSS on IPv6 side>

CSCua18092—The ACE does not do the mapping between ICMPv6 and ICMPv4 packets. Therefore, the ACE does not send ICMPv4 packets because the mapping of ICMPv6 to ICMPv4 is not done for this VIP by a device. This is seen in the following cases:

The VIP is a class-map that is configured with the protocol/port "any"

IPv6 is configured on the client side and IPv4 is configured on the rserver side

The MTU on the path from the ACE to the client is lower than the MTU on the path from the ACE to the rserver

Client requests result in a large reply size that is greater than the MTU of the ACE to the client path

Workaround: Configure VIP with a specific port.

CSCua18882—When IPv6 ssl termination is configured to load balance an IPv6 web server, the ACE IPv6 ssl termination VIP does not load a web page. The TCP MSS between the client and ACE is 1220. The packets are dropped when the packet size exceeds the MSS as follows:

ACE/Context# sh np 1 me-stats "-stcp" | i MSS Drops due to packet size exceed MSS: 21 0

Workaround: Configure the following exceed-mss allow in a connection parameter-map for VIP.

parameter-map type connection TCP-Options   exceed-mss allow  policy-map multi-match 
VIPS   class IPv6-SSL-Term-Vip     connection advanced-options TCP-Options
 
   

CSCua18919—When the backtrace decode points to a specific fastpath crash due to a corrupt buffer chain for transition, the ACE reboots with the last boot reason: NP Failed:NP ME Hung. Workaround: None.

CSCua19020—If you configure an ACE with two VIP having the same address but on separate ports, and when you remove one of the VIP (with the other VIP operational), and later reconfigure it, the reconfigured VIP remains inactive for a long time.

Workaround: For the VIP addresses that are inactive, remove the configuration in the multi-match policy and reapply them.

CSCua22740After you configure a NTP server in ACE and later remove it from the configuration, the NTP server still remains active (even after it is removed from the configuration). Workaround: None.

CSCua25656—When you configure ACE with high syslogging, the ACE CLI becomes unresponsive when you enter the commands such as show running, show logging, write mem, and so on. Workaround: Reduce syslogging.

CSCua30450—The ACE unexpectedly reboots. If you specify the show version command, the ACE reloads with the last boot reason: Service cfgmgr. Workaround: None.

CSCua34721—When you enable the TCP timestamp on an ACE, the ACE uses the incorrect timestamp when it acknowledges a packet from the backend server. Though the ACE acknowledges the latest packet, it uses the timestamp of a previous packet.

Workaround: Perform one of the following:

Add "set tcp wan-optimization rtt 0" to the connection parameter-map

Remove "tcp-options timestamp allow" from TCP connection parameter-map.

CSCua35646—When an ACE is running the software version A5(1.2), the ACE becomes unresponsive with the incorrect title "HANG DETECTED on core 15". The title "Program terminated with signal 11" should be displayed.

Workaround: None.

CSCua37075—The ACE 30 module reloads with the last boot reason: CP Kernal Crash, and generates the "crashinfo" file. Workaround: None.

CSCua66222—The ACE reloads with the last reboot reason: "NP 1 Failed : NP ME Hung". This occurs in one of the following conditions:

The "doAddition" function fails and fills the freelist up to 100%

100% ME utilization in the core file

Workaround: None.

CSCua69350—A POST request received from the client matches the class-default instead of matching the class-map. This occurs when ACE is configured in one of the following ways:

The ACE uses a L7 VIP with multiple class-maps including class-default.

The HTTP transactions is a POST with HTTP header "Content-Type: application/x-www-form-urlencoded"

The POST content length is greater than TCP buffer share but lesser than the content-maxparse-length

Workaround: Perform one of the following:

Set "content-maxparse-length" to "1"

Create a connection parameter map with a tcp buffer share of 65535

CSCua71445—The client request decryption stalls for five seconds. This occurs if the client request contains "Content-Type: application/x-www-form-urlencoded" and hits a policy map which contains at least one class that matches the secondary cookies.

Workaround: Configure HTTP on the front end.

CSCua78518—The ACE console displays the following error message when the no probe command is entered.

Error: Cannot delete probe associated with tracking. 

This occurs in one of the following conditions:

When the ft track host is configured and is associated with the probe

If the 'no track-host [ip address]' and 'no peer track-host [ip address]' commands are entered before the ft track is removed

Workaround: Remove the ft track host commands 'no track-host [ip address]' and 'no peer track-host [ip address]'.

CSCua78518—The ACE console displays the following error message when the no probe command is entered.

Error: Cannot delete probe associated with tracking. 

This occurs in one of the following conditions:

When the ft track host is configured and is associated with the probe

If the no track-host [ip address] and no peer track-host [ip address] commands are entered before the ft track is removed

Workaround: Remove the ft track host commands no track-host [ip address] and no peer track-host [ip address].

CSCua81138—The ACE stops inserting the SSL session ID header when the cached session reaches 1,00,000 sessions (approximately). Workaround: Remove the session cache timeout.

CSCua92808—When you use the percent sign in the <number> value in the limit-resource all minimum <number> command, the ACE translates the <number> incorrectly and divides the numerical value by 100.

For example, execute the command in the following configuration,

ACE/Admin(config)# resource-class RC1
ACE/Admin(config-resource)# limit-resource all minimum 20% maximum equal-to-min
 
   

The following output of the above command appears in the configuration:

resource-class RC1
limit-resource all minimum 0.20 maximum equal-to-min
 
   

The output of show resource-usage confirms that the ACE assigns only 0.2% (instead of 20%) of resources to all contexts, which are member of this class.

Workaround: Remove the percent sign ('%') from the "limit-resource" command. The ACE accepts any non-numerical characters (even multiple of these characters) in the <number> field without any error.

CSCua99477—When SSL termination is configured on an ACE and the client connects with an expired certificate, the configured action-list adds incorrect values in the HTTP header. The HTTP verify-result header on the server shows the status as "OK" even though the certificate is expired. This occurs only when the CRL check is configured on the ACE.

Workaround: Remove the CRL check from the configuration.

CSCub05455—The ACE reloads with following last boot reason: AAA Daemon and generates core files. Workaround: None.

CSCub07887—In an ACE, when you modify one of the class-maps in a management policy, a part of the management traffic towards the ACE drops. Workaround: Reapply the management service-policy to the interface.

CSCub12816—When there are multiple contents with the same VIP address, protocol, and port in a configuration, only one policy-map is created. If the contents have different match statements, muliple class-maps are created. However, the L7 match statement and action is missing from the L7 policy-map.

Workaround: Create a single content with all the match statements in it.

Software Version A5(2.0) Command Changes

Table 11 lists the command changes in software version A5(2.0).


Note For a summary of new features for software version A5(2.0), including the associated new or modified commands, see the "New Software Features in Version A5(2.0)" section.


Table 11 CLI Command Changes in Version A5(2.0) 

Mode
Command and Syntax
Description

Exec

show download information

Per CSCtz37625, the ACE now displays the hidden command limit-regex-dnld enable in configuration mode (as described below). To view information related to the regex download optimization status, the show download information command has been added to software version A5(2.0).

See the "Support for Creation of RDP Parameter Maps" section for details.

Configuration

limit-regex-dnld enable

Per CSCtz37625, the ACE now displays the hidden command limit-regex-dnld enable in configuration mode. You would use this command to enable regular expression download optimization.

See the "Support for Creation of RDP Parameter Maps" section for details.

Parameter map HTTP

parsing error-drop

Per CSCts66950, when you configure advanced HTTP behavior for SLB connections in an HTTP parameter map, you can configure the ACE to drop a packet when there is an HTTP parse error defected even if there is a class-default class map configured in the same policy. By default, when there is a class-default class map configured in the same policy, the ACE will attempt to perform Layer 4 load-balancing even when an HTTP parsing error is encountered. The new parsing drop-error command provides you with the option to drop the parse error connection instead of performing Layer 4 load-balancing.

For details on configuring an HTTP parameter map, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine.


Software Version A5(2.0) System Log Messages

Software version A5(2.0) includes the following system log (syslog) message changes.

251006

Error Message    %ACE-3-251006: Health probe failed for server A.B.C.D on port P, 
internal error: error message 

Per CSCtx58666, the "failed to setup a socket" error message has been removed as one of the possible values of the error message variable from syslog %ACE-3-251006.

251010

Error Message    %ACE-3-251010: Health probe failed for server A.B.C.D on port P, error message 

Per CSCtx58666, connection error message "Network or Host is unreachable" has been added as one of the possible values of the error message variable in syslog %ACE-3-251010.

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.