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 rewriteurl_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.

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 commandallows 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:

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

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:

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.

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:

•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.

•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:

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 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:

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.

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:

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:

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:

•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.

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.

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.

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":

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_namedetail 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:

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:

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.

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

lengthid_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.

•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 sslsession_id keyword and argument options.

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.

Support for the ACE No Payload Encryption Software Version

•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 servicename

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

–authgroup

–cert

–chaingroup

–crl

–key

–ocspserver

–revcheckprio

–ssl

•probe httpsname

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

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

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 rdpname

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:

descriptiontext

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:

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:

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:

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:

•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:

•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:

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:

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.

•peerpeer_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.

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

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.

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):

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

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)

3The 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.

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 serverfarmname 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 bandwidth1 Gbps compression1,000 SSL TPS5 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 bandwidth6 Gbps compression30,000 SSL TPS250 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 bandwidth6 Gbps compression30,000 SSL TPS250 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 bandwidth6 Gbps compression30,000 SSL TPS250 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 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).

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.

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:

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.

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:

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):

•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.

•CSCtx77127—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.

•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.

•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:

•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.

•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:

•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.

•CSCua22740—After 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.

•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.

•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.

•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.

•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.

•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.

•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.

•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.

•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.

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.

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

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

(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 serverfarmname command may display some real servers with current connections after the traffic has stopped and the connections have closed. 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).

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)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.

•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.

•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:

•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:

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:

•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:

•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:

•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.

•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

•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:

•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).

•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.

•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.

•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.

•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.

•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.

•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.

•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.

•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.

•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:

•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.

•CSCua22740—After 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.

•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.

–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

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.

•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.

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).

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.

251010

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:

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.