Cisco Services Modules

Table Of Contents

Release Note for the Cisco Application Control Engine Module

Contents

New Software Features in Version A2(1.1)

Configuring the Reverse IP Stickiness Feature

Overview of Reverse IP Stickiness

Configuration Requirements and Restrictions

Configuring Reverse IP Stickiness

Displaying Reverse IP Sticky Status and Statistics

Reverse IP Stickiness Configuration Examples

Configuring the Switch Mode Feature

New Software Features in Version A2(1.0)

Available ACE Licenses

Ordering an Upgrade License and Generating a License Key

Upgrading Your ACE Software

Changing the Admin Password

Changing the www User Password

Checking Your Configuration for FT Priority and Preempt

Creating a Checkpoint

Updating Your Application Protocol Inspection Configurations

Downgrading Your ACE Software from Version A2(1.0) to 3.0(0)A1(6.x) in a Redundant Configuration

Before You Begin

Downgrade Procedure

ACE Operating Considerations

ACE Documentation Set

Software Version A2(1.2) Resolved Caveats, Open Caveats, and Command Changes

Software Version A2(1.2) Resolved Caveats

Software Version A2(1.2) Open Caveats

Software Version A2(1.2) Command Changes

Software Version A2(1.1a) Resolved Caveats and Open Caveats

Software Version A2(1.1a) Resolved Caveats

Software Version A2(1.1a) Open Caveats

Software Version A2(1.1) Resolved Caveats, Open Caveats, and Command Changes

Software Version A2(1.1) Resolved Caveats

Software Version A2(1.1) Open Caveats

Software Version A2(1.1) Command Changes

Software Version A2(1.0a) Resolved and Open Caveats

Software Version A2(1.0a) Resolved Caveats

Software Version A2(1.0a) Open Caveats

Software Version A2(1.0) Resolved Caveats and Open Caveats

Software Version A2(1.0) Resolved Caveats

Software Version A2(1.0) Open Caveats

Obtaining Documentation, Obtaining Support, and Security Guidelines

Release Note for the Cisco Application Control Engine Module

---

September 9, 2008

---

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

---

Contents

This release note applies to the following software versions for the Cisco Application Control Engine Module (ACE), models ACE10 (ACE10-6500-K9) and ACE20 (ACE20-MOD-K9):

•A2(1.2)

•A2(1.1a)

•A2(1.1)

•A2(1.0a)

•A2(1.0)

The ACE10 and the ACE20 are module options for the Catalyst 6500 series switch and require Cisco IOS Release 12.2(18)SXF4 or later with a Multilayer Switch Feature Card (MSFC3) and the following models of Supervisor 720 Engines: WS-SUP720, WS-SUP720-3B, and WS-SUP720-3BXL.

The ACE10 and the ACE20 modules require Cisco IOS Release 12.2(33)SXH or later running on a Catalyst 6500 series switch with a Multilayer Switch Feature Card (MSFC3) and the following models of Supervisor 720-10GE engines: VS-S720-10G-3C and VS-S720-10G-3CXL.

The ACE10 and the ACE20 are also module options for the Cisco 7600 series router and require either Cisco IOS Release 12.2(18)SXF4 or 12.2(33)SRB or later with Supervisor Engines WS-SUP720, WS-SUP720-3B, or WS-SUP720-3BXL. Note that Cisco IOS Release 12.2(33)SXH runs only on the Catalyst 6500 series switch; therefore, the Supervisor 720-10GE Engines are not supported in the Cisco 7600 series router.

The ACE10 and the ACE20 modules require Cisco IOS Release 12.2(33)SRC or later running on a Cisco 7600 series router with the Cisco Route Switch Processor (RSP) 720.

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

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

This release note contains the following sections:

•New Software Features in Version A2(1.1)

•New Software Features in Version A2(1.0)

•Available ACE Licenses

•Ordering an Upgrade License and Generating a License Key

•Upgrading Your ACE Software

•Downgrading Your ACE Software from Version A2(1.0) to 3.0(0)A1(6.x) in a Redundant Configuration

•ACE Operating Considerations

•ACE Documentation Set

•Software Version A2(1.2) Resolved Caveats, Open Caveats, and Command Changes

•Software Version A2(1.1a) Resolved Caveats and Open Caveats

•Software Version A2(1.1) Resolved Caveats, Open Caveats, and Command Changes

•Software Version A2(1.0) Resolved Caveats and Open Caveats

•Obtaining Documentation, Obtaining Support, and Security Guidelines

New Software Features in Version A2(1.1)

The A2(1.1) software maintenance release provides the following two new features:

•Configuring the Reverse IP Stickiness Feature

•Configuring the Switch Mode Feature

Configuring the Reverse IP Stickiness Feature

This section describes the reverse IP stickiness feature that is used primarily in firewall load balancing (FWLB) to ensure that applications with separate control and data channels use the same firewall for ingress and egress flows for a given connection. It contains the following subsections:

•Overview of Reverse IP Stickiness

•Configuration Requirements and Restrictions

•Configuring Reverse IP Stickiness

•Displaying Reverse IP Sticky Status and Statistics

•Reverse IP Stickiness Configuration Examples

Overview of Reverse IP Stickiness

Reverse IP stickiness is an enhancement to regular stickiness and is used mainly in FWLB. It ensures that multiple distinct connections that are opened by hosts at both ends (client and server) are load-balanced and stuck to the same firewall. Reverse stickiness applies to such protocols as FTP, RTSP, SIP, and so on where there are separate control channels and data channels opened by the client and the server, respectively.

You configure reverse IP stickiness as an action under a Layer 7 load-balancing policy map by associating an existing IP address sticky group with the policy using the reverse-sticky command. Then you associate the Layer 7 policy map with a Layer 4 multi-match policy map and apply the Layer 4 policy map as a service policy on the ACE interface between the firewalls and the ACE. When incoming traffic matches the policy, the ACE verifies that a reverse IP sticky group is associated with the policy. If the association exists, the ACE creates a sticky entry in the sticky table that maps the opposite IP address (for example, the destination IP address if source IP sticky is configured) to the real server ID, which is the ID of the firewall. To obtain the real ID of the firewall, the ACE uses the encapsulation (encap) ID from the traffic coming from the firewall as a lookup key into the list of real servers in the server farm.

---

Note The ACE sticky table, which holds a maximum of 4 million entries, is shared across all sticky types, including reverse IP stickiness.

---

This section contains the following topics:

•Symmetric Topology

•Asymmetric Topology

Symmetric Topology

A typical firewall load-balancing topology (symmetric) includes two dedicated ACEs with the firewalls positioned between the ACEs. In this scenario, the ACEs are used exclusively for FWLB and simply forward traffic through their host interfaces in either direction. See Figure 1.

The hosts in either VLAN 31 or VLAN 21 can initiate the first connection and the hosts on both sides of the connection can "see" each other directly. Therefore, only catch-all VIPs (with an IP address of 0.0.0.0 and a netmask of 0.0.0.0) are configured on the ACE interfaces.

Figure 1 Typical Symmetric Firewall Load-Balancing Topology for Reverse IP Stickiness

For the network diagram shown in Figure 1, the following steps describe a possible connection scenario with reverse IP stickiness:

---

Step 1 Host A (a client) initiates an FTP control channel connection to the IP address of Host C (an FTP server).

Step 2 ACE 1 load balances the connection to one of the two firewalls (FW1 or FW2) in the FWS-OUT server farm. ACE 1 is configured with a source IP sticky group that is associated with a policy map, which is applied to interface VLAN 113. This configuration ensures that all connections coming from the same host (or directed to the same host) are load balanced to the same firewall. The ACE creates a sticky entry that maps the IP address of Host A to one of the firewalls.

Step 3 The firewall that receives the packets from ACE 1 forwards them to ACE 2.

Step 4 Assume that a sticky group that is based on the destination IP address is associated with a policy map and is applied to interface VLAN 21. The same sticky group is associated as a reverse sticky group with the policy that is applied to VLAN 111. When it receives the packets, ACE 2 creates a sticky entry in the sticky database based on the source IP address (because the sticky group is based on the destination IP address in this case), which maps the Host A IP address to the firewall in the FWS-IN server farm from which the traffic was received. Then, ACE 2 forwards the packets to the FTP server (Host C) in the server farm.

Step 5 If you have enabled the mac-sticky command on the VLAN 111 interface, ACE 2 forwards return traffic from the same connection to the same firewall from which the incoming traffic was received. The firewall routes the return traffic through ACE 1, which in turn forwards it to the MSFC and from there to the client.

Step 6 Now suppose that Host C (an FTP server) opens a new connection (for example, the corresponding FTP data channel of the previously opened FTP control channel) to the IP address of Host A. Because a sticky group based on destination IP is associated with the policy applied to interface VLAN 21, ACE 2 performs a sticky lookup and finds a valid sticky entry (the one created in Step 4) in the sticky database that allows ACE 2 to load balance the packets to the same firewall that the control connection traversed.

Step 7 The firewall routes the packets through ACE 1, which in turn forwards them to the MSFC and from there to the client (Host A).

---

Follow these guidelines and observations when you configure reverse IP stickiness:

•When reverse IP sticky is enabled, the sticky entry is populated in one direction (for incoming traffic) and looked up in the opposite direction (for outgoing traffic), allowing traffic to flow through the same firewall in both directions.

•The example that is described in the steps above is symmetric because it does not matter on which side of the connections that the clients and servers reside. Everything would work in a similar manner if Host C was a client opening the FTP control channel and Host A was a server opening the FTP data channel, assuming that a reverse sticky group was also configured on the ACE 1 VLAN 112 interface. To make reverse IP stickiness work symmetrically, you must apply a reverse sticky group to the ACE interfaces that are associated with the firewall server farm (in this example, VLAN 112 and VLAN 111) and apply the same sticky group as a regular sticky group to the ACE interfaces associated with the hosts (in this example, VLAN 113 and VLAN 21).

•In this example, the assumption is to have a regular sticky group based on the source IP associated with the VLAN 113 interface of the ACE 1 module and another sticky group based on the destination IP associated with the VLAN 21 interface of the ACE 2 module (the reverse sticky groups on VLAN 112 and VLAN 111 would be based on the opposite IPs). Everything would work correctly if the regular sticky groups were reversed, that is, the sticky group on VLAN 113 was based on the destination IP and the one on VLAN 21 was based on the source IP, or if both regular sticky groups were based on both the source and the destination IP.

Asymmetric Topology

The following scenario is asymmetric because it cannot work equally in both directions as in the previous scenario. In this setup, one of the load balancers is unknown (Unknown LB) so that it is uncertain whether the load balancer supports reverse sticky. The clients must be on one side of the connection and the servers must be on the other side with the clients opening the first connection to the servers. See Figure 2. In this scenario, the ACE performs only FWLB and forwards traffic to the real servers in the server farm.

Figure 2 Asymmetric Firewall Load Balancing Topology for Reverse IP Stickiness

For the network diagram shown in Figure 2, the following steps describe the sequence of events for establishing a connection with reverse IP stickiness:

---

Step 1 A client initiates a connection (for example, an FTP control channel connection) to the IP address of one of the servers in the server farm.

Step 2 The Unknown LB load balances the connection to one of the two firewalls in the FWS-OUT server farm. The Unknown LB should, at a minimum, support load balancing based on the source or destination IP address hash predictor. These predictors ensure that all connections coming from the same client (or destined to the same server) are load balanced to the same firewall. Assume in this example that a predictor based on source IP hash is configured in the Unknown LB, so that all traffic coming from the same client will be directed to the same firewall.

Step 3 The firewall that receives the packet forwards it to the ACE.

Step 4 Assume that a sticky group that is based on the destination IP address is associated with a policy map that is applied to interface VLAN 21 using a service policy. The same sticky group is associated as a reverse sticky group with the policy that is applied to VLAN 111. When it receives the packets, the ACE creates a sticky entry in the sticky database based on the source IP address (because the sticky group is based on the destination IP in this case), which maps the Host A IP address to the firewall in the FWS-IN server farm from which the traffic was received. Then, the ACE forwards the packets to the FTP server (Host C) in the server farm.

Step 5 If you have enabled the mac-sticky command on VLAN 111, the ACE forwards the return traffic for the same connection to the same firewall from which the incoming traffic was received. The firewall routes the return traffic through the Unknown-LB, which in turn forwards it to the MSFC and then to the client.

Step 6 Now suppose that the FTP server opens a new connection (for example, the corresponding FTP data channel of the previously opened FTP control channel) to the IP address of the client. Because a sticky group based on the destination IP address is associated with the policy applied to interface VLAN 21, the ACE performs a sticky lookup and finds a valid sticky entry (the one created in Step 4) in the sticky database that allows the ACE to load balance the packets to the same firewall that the control connection traversed.

Step 7 The firewall routes the packet through the Unknown LB, which in turn forwards it to the MSFC and then to the client.

---

In this scenario, reverse sticky would also work properly under the following conditions:

•The sticky group is associated with the policy map as a regular sticky group based on source the IP and applied to the VLAN 21 interface.

•The sticky group is associated with the policy map as a reverse sticky group (based on the destination IP address) and applied to the VLAN 111 interface.

•The Unknown LB has a predictor based on the hash of the destination IP.

For more information about configuring firewall load balancing, see the Cisco Application Control Engine Module Server Load-Balancing Guide.

Configuration Requirements and Restrictions

Before attempting to configure reverse IP stickiness, be sure that you have met the following configuration requirements and restrictions:

•A sticky group of type IP netmask based on source IP, destination IP, or both must be present in your configuration.

•The sticky group cannot be a static sticky group.

•Once you have associated reverse IP stickiness with a sticky group, you cannot change that sticky group to a static sticky group.

•For firewall load balancing, configure the mac-sticky command on the ACE interface that is connected to the firewall.

Configuring Reverse IP Stickiness

To configure reverse IP stickiness, use the reverse-sticky command in policy map loadbalance class configuration mode. The syntax of this command is as follows:

reverse-sticky name

The name argument specifies the unique identifier of an existing IP address sticky group. Enter the name of an existing IP address sticky group as an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

For example, to configure reverse IP stickiness for a sticky group called DEST_IP_STICKY, enter the following sequence of commands:

host1/Admin(config)# sticky ip-netmask 255.255.255.255 address destination DEST_IP_STICKY

host1/Admin(config-sticky-ip)# serverfarm FWS-IN

host1/Admin(config)# policy-map type loadbalance first-match L7PMAP_TO_REALS

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

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

host1/Admin(config-pmap-lb-c)# reverse-sticky DEST_IP_STICKY

Displaying Reverse IP Sticky Status and Statistics

Use the following show commands to display the state of the reverse-sticky command and reverse sticky statistics:

•show sticky database detail—Provides the reverse entry field that indicates the state (TRUE or FALSE) of reverse IP stickiness for each configured sticky group.

•show stats sticky—Provides the Total active reverse sticky entries field that displays the total number of active reverse IP sticky entries in the sticky database.

•show service-policy route detail—Provides the reverse sticky group field that displays the name of the sticky group configured for reverse IP stickiness.

Reverse IP Stickiness Configuration Examples

This section contains configuration examples that show how to configure reverse IP stickiness with a symmetric firewall load balancing configuration. These configuration examples correspond with the network diagram in Figure 1. The examples are as follows:

•ACE 1 Configuration

•ACE 2 Configuration

ACE 1 Configuration

access-list acl1 line 8 extended permit ip any any

rserver host FW1

  ip address 10.10.40.10

  inservice

rserver host FW2

  ip address 10.10.40.20

  inservice

serverfarm host FWS-OUT

  transparent

  rserver FW1

    inservice

  rserver FW2

    inservice

sticky ip-netmask 255.255.255.255 address source SOURCE_IP_STICKY

  serverfarm FWS-OUT

class-map match-all CATCH-ALL-VIP

  2 match virtual-address 0.0.0.0 0.0.0.0 any

policy-map type management first-match MGMT-POLICY

  class class-default

    permit

policy-map type loadbalance first-match LB_PMAP_TO_REALS

  class class-default

    sticky-serverfarm SOURCE_IP_STICKY

policy-map type loadbalance first-match ROUTE_PMAP

  class class-default

    forward

    reverse-sticky SOURCE_IP_STICKY

policy-map multi-match LB

  class CATCH-ALL-VIP

    loadbalance vip inservice

    loadbalance policy LB_PMAP_TO_REALS

policy-map multi-match ROUTE

  class CATCH-ALL-VIP

    loadbalance vip inservice

    loadbalance policy ROUTE_PMAP

service-policy input mgmt-policy

interface vlan 112

  description outside FW vlan

  bridge-group 15

  mac-sticky enable

  access-group input acl1

  service-policy input ROUTE

  no shutdown

interface vlan 113

  description client vlan

  bridge-group 15

  access-group input acl1

  service-policy input LB

  no shutdown

interface bvi 15

  ip address 10.10.40.2 255.255.255.0

  alias 10.10.40.3 255.255.255.0

  no shutdown

ip route 0.0.0.0 0.0.0.0 10.10.40.1

ACE 2 Configuration

access-list acl1 line 8 extended permit ip any any 

rserver host FW1

  ip address 10.10.50.10

  inservice

rserver host FW2

  ip address 10.10.50.20

  inservice

serverfarm host FWS-IN

  transparent

  rserver FW1

    inservice

  rserver FW2

    inservice

sticky ip-netmask 255.255.255.255 address destination DEST_IP_STICKY

  serverfarm FWS-IN

class-map match-all CATCH_ALL_VIP

  2 match virtual-address 0.0.0.0 0.0.0.0 any

policy-map type management first-match mgmt-policy

  class class-default

    permit

policy-map type loadbalance first-match L7PMAP_TO_FWS

  class class-default

    sticky-serverfarm DEST_IP_STICKY

policy-map type loadbalance first-match L7PMAP_TO_REALS

  class class-default

    forward

    reverse-sticky DEST_IP_STICKY

policy-map multi-match L4_TO_FWS

  class CATCH_ALL_VIP

    loadbalance vip inservice

    loadbalance policy L7PMAP_TO_FWS

policy-map multi-match L4_TO_REALS

  class CATCH_ALL_VIP

    loadbalance vip inservice

    loadbalance policy L7PMAP_TO_REALS

service-policy input mgmt-policy

interface vlan 21

  ip address 21.1.1.1 255.255.255.0

  access-group input acl1

  service-policy input L4_TO_FWS

  no shutdown

interface vlan 111

  description inside FW vlan

  ip address 10.10.50.1 255.255.255.0

  mac-sticky enable

  access-group input acl1

  service-policy input L4_TO_REALS

  no shutdown

Configuring the Switch Mode Feature

Use the switch mode feature to change the way that the ACE handles TCP connections that are not destined to a particular VIP and those connections that do not have any policies associated with their traffic. When you enable this feature, the ACE still creates connection objects for those TCP sessions that are not destined to the VIP. The ACE processes these connections as stateless connections, which means that they do not undergo any TCP normalization checks (for example, TCP window, TCP state, TCP sequence number, and other normalization checks).

The ACE also creates stateless connections for non-SYN TCP packets if they satisfy all other configured requirements, for example, ACLs and other policies. This process ensures that a long-lived persistent connection passes through the ACE successfully (even if it times out) by being reestablished by any incoming packet related to the connection.

By default, these stateless connections time out after 2 hours and 15 minutes unless you configure the timeout otherwise. When a stateless connection times out, the ACE does not send a TCP RST packet but instead closes the connection silently. Even though these connections are stateless, the TCP RST and FIN-ACK flags are honored and the connections are closed when the ACE sees these flags in the received packets.

To change the default timeout for these stateless connections, use the set timeout inactivity command in parameter map connection configuration mode. For details about this command, see theCisco Application Control Engine Module Security Configuration Guide.

The SYN cookie feature still operates normally for these stateless connections that are not destined to any VIP.

The default timeout value of 2 hours and 15 minutes is also applicable to the UDP connections that are not destined to any VIP.

To enable the switch mode feature, use the switch-mode command in configuration mode. The syntax of this command is as follows:

switch-mode

For example, to enable the switch mode feature, enter the following command:

host1/Admin(config)# switch-mode

To disable the switch mode feature, enter the following command:

host1/Admin(config)# no switch-mode

New Software Features in Version A2(1.0)

The A2(1.0) software release provides the following expanded features and functions:

•Enhanced load-balancing support:

–SIP

–Extended RTSP

–RADIUS

–RDP

–Generic protocol parsing

•Enhanced predictors:

– Adaptive algorithms

– Least loaded

– Least bandwidth

•General SLB enhancements:

– KAL-AP

– HTTP header rewrite

– Partial server farm failover

– Application-based probes

– SNMP-based probes

– UDP fast age

•SSL enhancements:

– Hardware accelerated

– Hardware-assisted probes

– Session ID stickiness

– Session ID reuse

– SSL queue delay

– Client authentication

– URL rewrites for SSL

•Fast DNS load balancing—UDP booster

•XML-tagged configuration

•ANM 1.2 support

•Real-time TCP dump

•Management traffic protection

•Redundancy (high availability) sync improvements

•Source NAT changes

–Source NAT using a VIP

–Server-farm based NAT

•Protocol inspection enhancements:

– SIP

– ILS/LDAP

– Skinny

•ACL improvements—object grouping

•Denial-of-service protection—SYN cookie per interface

•Rate-limiting enhancements:

– Connection-rate

– Bandwidth-rate

•HTTP firewall features:

– Inspect HTTP POST body

– Inspect HTTP secondary cookies

Available ACE Licenses

By default, the ACE supports virtualization with one Admin context and five user contexts, 4 gigabits per second (Gbps) module bandwidth, 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 following licenses:

•ACE-VIRT-020—20 virtual contexts.

•ACE-VIRT-050—50 virtual contexts.

•ACE-VIRT-100—100 virtual contexts.

•ACE-VIRT-250—250 virtual contexts.

•ACE-08G-LIC—8 Gbps bandwidth.

If you purchase an ACE with a bandwidth of 4 Gbps, you can upgrade the module bandwidth to 8 Gbps by using the ACE-UPG1-LIC license.

•ACE-16G-LIC—16 Gbps bandwidth (ACE20-MOD-K9 module only)

If you purchase an ACE with a bandwidth of 8 Gbps, you can upgrade the module bandwidth to 16 Gbps by using the ACE-UPG2-LIC license (ACE20-MOD-K9 module only).

•ACE-SSL-5K-K9—SSL with 5,000 TPS.

•ACE-SSL-10K-K9—SSL with 10,000 TPS.

•ACE-SSL-15K-K9—SSL with 15,000 TPS.

You can upgrade virtualization in increments, provided that you do not exceed the limits of the ACE (a maximum of 250 contexts), by using the following licenses:

•ACE-VIRT-UP1—Upgrades 20 to 50 contexts

•ACE-VIRT-UP2—Upgrades 50 to 100 contexts

•ACE-VIRT-UP3—Upgrades 100 to 250 contexts

You can upgrade SSL in 5,000 TPS increments up to a maximum of 15,000 TPS by using the following SSL upgrade licenses:

•ACE-SSL-UP1-K9—Upgrades SSL from 5,000 TPS to 10,000 TPS (3.0(0)A1(3) or later).

•ACE-SSL-UP2-K9—Upgrades SSL from 10,000 TPS to 15,000 TPS (3.0(0)A1(3) or later).

You can also obtain an ACE demo license for each type of virtualization, bandwidth, or SSL TPS license, including upgrade increments for contexts. A demo license is valid for only 60 days. At the end of this period, you will need to update the demo license with a permanent license to continue to use the ACE software. To view the expiration of the demo license, use the show license usage command in Exec mode. If you need to replace the ACE module, you can copy and install the licenses onto the replacement module.

---

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

---

Ordering an Upgrade License and Generating a License Key

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

---

Step 1 Order one of the licenses from the list in the "New Software Features in Version A2(1.0)" section using any of the available Cisco ordering tools on Cisco.com.

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

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

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

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

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

---

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

Upgrading Your ACE Software

For complete instructions on how to upgrade your ACE software, see the Cisco Application Control Engine Module Administration Guide

---

Note To upgrade your ACE software to version A2(1.x), your ACE must be running software version 3.0(0)A1(5a) or higher.

---

An incompatibility exists between certain ACE software versions in the 3.0(0)A1.6.3x and A2.1x release trains. In a redundant configuration, the FT ACE pairs will not recognize each other and will report the following status as part of the show ft peer detail command output: "SRG Compatibility: INCOMPATIBLE".

The following software version combinations that are indicated with an "x" are incompatible:

A1(6.3x) Release	A2(1.0)	A2(1.0a)	A2(1.1)	A2(1.1a)	A2(1.2)
3.0(0)A1(6.3b)	x		x	x
3.0(0)A1(6.3c)	x	x	x	x

Before you upgrade your ACE software, be sure that your ACE configurations meet the upgrade prerequisites in the following sections:

•Changing the Admin Password

•Changing the www User Password

•Checking Your Configuration for FT Priority and Preempt

•Creating a Checkpoint

•Updating Your Application Protocol Inspection Configurations

Changing the Admin Password

Before you upgrade to software version A2(1.1) or higher, you must change the default Admin password, if you have not already done so. Otherwise, after you upgrade the ACE software, you will be able to log in to the ACE only through the console port or through the supervisor engine of the Catalyst 6500 series switch or the Cisco 7600 series router. For details about changing the Admin password, see the Cisco Application Control Engine Module Administration Guide.

Changing the www User Password

Before you upgrade to software version A2(1.1) or higher, you must change the default www user password if you have not already done so. Otherwise, after you upgrade the ACE software, the www user will be disabled and you will not be able to use Extensible Markup Language (XML) to remotely configure an ACE until you change the default www user password. For details about changing the www user password, see the Cisco Application Control Engine Module Administration Guide.

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. Note that the preempt command is enabled by default and does not appear in the running-config.

Creating a Checkpoint

We strongly recommend that you create a checkpoint in the running-configuration file of each context in your ACE. A checkpoint creates a snapshot of your configuration that you can later roll back to in case a problem occurs with an upgrade and you want to downgrade the software to a previous release. Use the checkpoint create command in Exec mode in each context for which you want to create a configuration checkpoint and name the checkpoint. For details about creating a checkpoint and rolling back a configuration, see Cisco Application Control Engine Module Administration Guide. For information about downgrading your ACE, see the "Downgrading Your ACE Software from Version A2(1.0) to 3.0(0)A1(6.x) in a Redundant Configuration" section.

Updating Your Application Protocol Inspection Configurations

Because the ACE version A2(1.x) software has stricter error checks for application protocol inspection configurations than A1(x) software versions, be sure that your inspection configurations meet the guidelines that follow. The error checking process in A2(1.x) software denies misconfigurations in inspection classifications (class maps) and displays error messages. If such misconfigurations exist in your startup- or running-configuration file before you load the A2(1.x) software, the standby ACE in a redundant configuration may boot up to the STANDBY_COLD state. For information about redundancy states, see the Cisco Application Control Engine Module Administration Guide.

If the class map for the inspection traffic is generic (match . . . any or class-default is configured) so that noninspection traffic is also matched, the ACE displays an error message and does not accept the inspection configuration. For example:

switch/Admin(config)# class-map match-all TCP_ANY

switch/Admin(config-cmap)# match port tcp any

switch/Admin(config)# policy-map multi-match FTP_POLICY

switch/Admin(config-pmap)# class TCP_ANY 

switch/Admin(config-pmap-c)# inspect ftp

Error: This class doesn't have tcp protocol and a specific port

The following examples show some of the generic class-map match statements and an ACL that are not allowed in A2(1.x) inspection configurations:

•match port tcp any

•match port udp any

•match port tcp range 0 65535

•match port udp range 0 65535

•match virtual-address 192.168.12.15 255.255.255.0 any

•match virtual-address 192.168.12.15 255.255.255.0 tcp any

•access-list acl1 line 10 extended permit ip any any

For application protocol inspection, the class map must have a specific protocol (related to the inspection type) configured and a specific port or range of port numbers.

For HTTP, FTP, RTSP, Skinny, and ILS protocol inspection, the class map must have TCP as the configured protocol and a specific port or range of ports. For example, enter the following commands:

host1/Admin(config)# class-map match-all L4_CLASS

host1/Admin(config-cmap)# match port tcp eq www

For SIP protocol inspection, the class map must have TCP or UDP as the configured protocol and a specific port or range of ports. For example, enter the following commands:

host1/Admin(config)# class-map match-all L4_CLASS

host1/Admin(config-cmap)# match port tcp eq 124

or

host1/Admin(config-cmap)# match port udp eq 135

For DNS inspection, the class map must have UDP as the configured protocol and a specific port or range of ports. For example, enter the following commands:

host1/Admin(config)# class-map match-all L4_CLASS

host1/Admin(config-cmap)# match port udp eq domain

For ICMP protocol inspection, the class map must have ICMP as the configured protocol. For example, enter the following commands:

host1/Admin(config)# access-list ACL1 extended permit icmp 192.168.12.15 255.255.255.0 
192.168.16.25 255.255.255.0 echo

host1/Admin(config)# class-map match-all L4_CLASS

host1/Admin(config-cmap)# match access-list ACL1

Downgrading Your ACE Software from Version A2(1.0) to 3.0(0)A1(6.x) in a Redundant Configuration

If you need to downgrade your ACE software from version A2(1.0) to an earlier version, use the procedure that follows. You can downgrade your ACE from software version A2(1.0) to 3.0(0)A1(6.1) or higher. Downgrading your ACE software to a software version below 3.0(0)A1(6.1) is not supported and not recommended. We recommend that you downgrade to the highest 3.0(0)A1(6.x) software version that is available. 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.

This section contains the following topics:

•Before You Begin

•Downgrade Procedure

Before You Begin

Before you downgrade your ACE software, ensure that the following conditions exist:

•Identical versions of 3.0(0)A1(6.x) software images reside 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 A2(1.0) software in a redundant configuration, perform the following steps:

---

Step 1 If you have created checkpoints in your 3.0(0)A1(6.x) running-configuration files (highly recommended), roll back the configuration in each context on each ACE to the check-pointed configuration. For example:

host1/Admin# checkpoint rollback CHECKPOINT_ADMIN

host1/Admin# changeto C1

host1/C1# checkpoint rollback CHECKPOINT_C1

Do the same on the other ACE. For information about creating checkpoints and rolling back configurations, see Chapter 4, Managing the ACE Software.

Step 2 Configure ACE-1 to automatically boot from the 3.0(0)A1(6.x) image. To set the boot variable and configuration register to 1, use the boot system image: and config-register commands in configuration mode. For example, enter:

host1/Admin# config

host1/Admin(config)# boot system image:c6ace-t1k9-mzg.3.0.0_A1_6_3.bin

host1/Admin(config)# config-register 1

host1/Admin(config)# exit

host1/Admin# 

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

---

Note Use the no boot system image: command to remove the configured A2(1.0) boot variable.

---

Step 3 Verify that the boot variable was synchronized to ACE-2 by entering the following command on ACE-2:

host1/Admin# show bootvar

BOOT variable = "disk0:c6ace-t1k9-mzg.3.0.0_A1_6_3.bin"

Configuration register is 0x1

host1/Admin#

Step 4 Use the show ft group detail command to verify the state of each module. Upgrade the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command.When ACE-2 loads the startup-configuration file, you may observe a few errors if you did not roll back the configuration to a checkpoint. These errors are harmless and occur because the 3.0(0)A1(6.x) software does not recognize the A2(1.0) commands in the startup-configuration file. After ACE-2 boots up, it may take a few minutes to reach the STANDBY_HOT state again. At this time, configuration synchronization is disabled, but the connections through ACE-1 are still being replicated to ACE-2.

host1/Admin# reload

This command will reboot the system

Save configurations for all the contexts. Save? [yes/no]: [yes]

Step 5 Perform a graceful failover of all contexts from ACE-1 to ACE-2 by entering the ft switchover all command in Exec mode on ACE-1. ACE-2 becomes the new active ACE and assumes mastership of all active connections with no interruption to existing connections.

host1/Admin# ft switchover all

Step 6 Reload ACE-1 with the same 3.0(0)A1(6.x) software version as ACE-2. Again, you may observe a few errors as ACE-1 loads the startup-configuration file.

host1/Admin# reload

After ACE-1 boots up, it assumes the role of standby and enters the STANDBY_HOT state (this may take several minutes). You can verify the states of both ACEs by entering the show ft group detail command in Exec mode. Because both ACE-1 and ACE-2 are running the same version of software now, configuration mode is enabled. The configuration is synchronized from ACE 2 (currently active) to ACE-1. If ACE-1 is configured with a higher priority and preempt is configured on the FT group, ACE-1 reasserts mastership after it has received all configuration and state information from ACE-2, making ACE-2 the new standby. ACE-1 becomes the active ACE once again.

Step 7 Perform manual cleanup in the running-configuration files of both ACEs to remove unnecessary version A2(1.0) configuration elements. For example, you may need to remove a service policy from an interface that was part of the version A2(1.0) configuration that is no longer needed in version 3.0(0)A1(6.x).

Step 8 Enter the write memory all command in both ACEs to save the running-configuration files in all configured contexts to their respective startup-configuration files. This action will eliminate future errors when the ACEs reload their startup-configuration files.

---

ACE Operating Considerations

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.

Software version A2(1.0) introduces hardware-assisted SSL (HTTPS) probes. For that reason, the ACE uses the all option for the default SSL version and uses the routing table (which may bypass the real server IP address) to direct HTTPS probes to their destination regardless of whether you specify the routed option in the ip address command. If you are using HTTPS probes in your A1(6.x) configuration with the default SSL version (SSLv3) or without the routed option, you may observe that your HTTPS probes behave differently with version A2(1.0). For more information about HTTPS probes, see the Cisco Application Control Engine Module Server Load-Balancing Guide.

In software version A2(1.2), the maximum number of match statements per ACE has been increased from 4,096 to 16,384.

ACE Documentation Set

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

Document Title	Description
Cisco Application Control Engine Module Hardware Installation Note	This guide provides information for installing the ACE into the Catalyst 6500 series switch and the Cisco 7600 series router.
Cisco Application Control Engine Module Getting Started Guide	This guide describes how to perform the initial setup and configuration tasks for the ACE.
Cisco Application Control Engine Module Administration Guide	This guide describes how to perform administration tasks on the ACE, including initial setup, establish remote access, configure class maps and policy maps, manage the ACE software, configure SNMP, define system message logging, configure redundancy, and upgrade your ACE software.
Cisco Application Control Engine Module Virtualization Configuration Guide	This guide provides instructions on how to operate your ACE in a single-context or in multiple-contexts. Multiple-contexts use the concept of virtualization to partition your ACE into multiple virtual devices or contexts.
Cisco Application Control Engine Module Routing and Bridging Configuration Guide	This guide provides instructions for configuring the routing and bridging features of the ACE. This guide provides a routing overview and describes how to perform ACE configuration tasks, including: •Configuring VLANs •Configuring routing •Configuring bridging •Configuring Address Resolution Protocol (ARP) •Configuring Dynamic Host Configuration Protocol (DHCP)
Cisco Application Control Engine Module Server Load-Balancing Configuration Guide	This guide describes how to perform ACE server load-balancing configuration tasks, including: •Server health monitoring •Real servers and server farms •Stickiness •Class maps and policy maps to load-balance traffic to real servers in server farms •Firewall load balancing •TCL scripts
Cisco Application Control Engine Module Security Configuration Guide	This guide describes how to perform ACE security configuration tasks, including: •Security access control lists (ACLs) •User authentication and accounting using a TACACS+, RADIUS, or LDAP server •Application protocol and HTTP deep packet inspection •TCP/IP normalization and termination parameters •Network address translation (NAT)
Cisco Application Control Engine Module SSL Configuration Guide	This guide describes how to perform ACE SSL configuration tasks, including: •SSL certificates and keys •SSL initiation •SSL termination •End-to-end SSL
Cisco Application Control Engine Module System Message Guide	Describes how to configure system message logging on the ACE. This guide lists and describes the system log messages generated by the ACE.
Cisco Application Control Engine Module Command Reference	This reference provides an alphabetical list of all command line interface (CLI) commands including syntax, options, and related commands.
Cisco CSM-to-ACE Conversion Tool User Guide	Describes how to use the CSM-to-ACE conversion tool to migrate Cisco Content Switching Module (CSM) running-configuration or startup-configuration files to the ACE.
Cisco CSS-to-ACE Conversion Tool User Guide	Describes how to use the CSS-to-ACE conversion tool to migrate Cisco Content Services Switches (CSS) running-configuration or startup-configuration files to the ACE.

Software Version A2(1.2) Resolved Caveats, Open Caveats, and Command Changes

The following sections contain the resolved and open caveats in software version A2(1.1a):

•Software Version A2(1.2) Resolved Caveats

•Software Version A2(1.2) Open Caveats

•Software Version A2(1.2) Command Changes

Software Version A2(1.2) Resolved Caveats

The following resolved caveats apply to software version A2(1.2):

•CSCsi13378—If you configure certain commands in the ACE (for example, object-group, action-list, and so on) and you enable the xml-show command, the output of the show running-config command displays data outside the XML tags or incorrect XML tags. Workaround: None.

•CSCsm65534—You may find that sequential readings of the Client Byte Count and the Server Byte Count fields in the show service-policy command output increment or decrement by large values without the expected changes in network traffic. This behavior is a display-only issue and does not affect traffic forwarded by the ACE. You may encounter this behavior after the byte counters exceed the maximum of 4294967295 bytes. Workaround: None.

•CSCsm89594—XML outputs are not well formatted for the following show commands:

–show ft stats

–show ft track 1 detail

–show ft track 1 summary

–show ft track 1 status

–show tacacs-server sorted

–show running-config policy-map

–show running-config probe

–show serverfarm sf1 detail

–show rserver detail

Workaround: None.

•CSCsm89835—The ACE rejects HTTP requests that contain non-ASCII characters that are not percent-encoded and are placed after the question mark (?) in a URL. Non-English websites may use those characters to pass data (for example, names) and web servers do accept such characters. Workaround: None.

•CSCso22472—When you use class maps of type http loadbalance match-any to select a server farm and some of these class maps are empty, the ACE may make an incorrect load-balancing (LB) decision. This incorrect LB decision causes unexpected LB results. For example:

class-map type http loadbalance match-any A

  2 match source-address 192.168.1.1 255.255.255.255

class-map type http loadbalance match-any B <<< empty

class-map match-all VIP

  2 match virtual-address 192.168.1.10 tcp eq telnet

policy-map type loadbalance first-match LB

  class A

    serverfarm A

  class B

    serverfarm B

  class class-default

    serverfarm C    

Workaround: In the above configuration, you must add a dummy match statement under class map B. For example:

class-map type http loadbalance match-any B 

  2 match source-address 172.16.27.5 255.255.255.255 

•CSCso38316—Following negative XML testing, a core dump occurred. The core dump did not cause the ACE module to reload, nor was there any negative impact to the ACE module. Workaround: None.

•CSCso38327—While running SSL client authentication, the browser intermittently does not recognize that a certificate has been revoked. Instead, the browser indicates that the server has failed or could not connect. Workaround: None.

•CSCso55673—Over time, the ACE can leak memory when it has a light continuous load of SSL client authentication traffic. The ACE will typically display a log message indicating this low memory condition before the CLI becomes unresponsive and the ACE possibly reloads. The ACE indicates that it is low on directly mapped memory by displaying the following message:

"Available CP memory less than 1%: 8380416 bytes. Free high memory: 2093056 bytes".

Workaround: None.

•CSCso65486—With the SYN cookie feature configured on an ACE interface that is forwarding nonload-balanced traffic to a routed server, all legitimate traffic that is receiving a SYN cookie is being reset. A packet capture for failed connections shows that the ACE completes a three-way handshake with the client and then with the server before it resets the connection. This behavior may also be observed with load-balanced FTP traffic. Workaround: None.

•CSCso73385—When you enter the inspect ftp command in a policy map, the ACE resets the FTP connection of the traffic that matches the policy after it sends an extended PASV (EPSV) command to the FTP server. Workaround: None.

•CSCso79767—When DNS traffic matches a rule that contains the inspect dns command and the DNS response from the server contains a VIP address, the ACE drops the DNS response. Workaround: Disable the inspect dns command.

•CSCso81191—The ACE module exits to the ROMMON prompt during an import into ANM when the configuration includes a Layer 7 SLB policy map that contains the drop or forward action. Workaround: None.

•CSCso81172—An ACE shows dropped ICMP packets on servers that are tagged for a load-balancing VLAN. If you change the servers to a non-loadbalancing VLAN, the packet loss is not observed. Packet loss is also observed with just a bridged VLAN interface (BVI) group configured. Workaround: Reload the ACE.

•CSCso91403—You may observe connection resets when you modify a large configuration. These resets may occur even if you modify a service policy that is not assigned to an interface. Workaround: None.

•CSCsq18476—In a RADIUS authentication configuration, if all of the RADIUS servers fail, the ACE falls back to the local database for authentication even if you change the default from local to the RADIUS servers. For example:

10.10.10.10 key 7 "abc" authentication accounting radius-server host

10.10.10.11 key 7 "abc" authentication accounting aaa group server

radius RADIUS_SERVERS

  server 10.10.10.10

  server 10.10.10.11

aaa authentication login default group RADIUS_SERVERS < not have local option

aaa authentication login console group RADIUS_SERVERS < not have local option

Workaround: None.

•CSCsq25300—When you configure fastpath logging to a syslog host in the ACE, the connection setup and teardown messages that are sent to the syslog server may contain an incorrect duration time stamp and may be formatted improperly. Workaround: None.

•CSCsq28177—An ACE is present in the chassis, but while trying to perform an SNMP walk on the instance reported by the cefcModuleOperStatus MIB, a message states that the module is missing. Walking cefcModuleOperStatus(1.3.6.1.4.1.9.9.117.1.2.1.1.2) returns the complete value "SNMPv2-SMI::enterprises.9.9.117.1.2.1.1.2.1 = INTEGER: 2". While trying to walk "SNMPv2-SMI::enterprises.9.9.117.1.2.1.1.2.1", a message states that "No Such Instance currently exists at this OID."

Workaround: Perform an SNMP walk on cefcModuleOperStatus(1.3.6.1.4.1.9.9.117.1.2.1.1.2).

•CSCsq38934—The ACE may fail to respond to an ICMP Echo Request to the VIP address when a policy map is configured with the loadbalance vip icmp-reply active command and the same VIP address is configured in the class map with different IP ports and one of these VIP match statements is deleted.

Workarounds:

–In a class map with the same VIP in multiple match statements, do not delete individual match statements. If you must make configuration changes, reboot the ACE.

–If individual match statements for the same VIP need to be deleted, either reboot the ACE or delete the policy map and reconfigure it.

•CSCsq45437—When you remove a probe that is associated with multiple real servers from one of the real servers, changes to the common probe parameters (for example, interval, passdetect interval, passdetect count, faildetect count, receive timeout, and so on) do not take effect and the probes continue to use the old values. Workaround: After you change the probe parameters, remove the probe association from one of the real servers and then reassociate the probe with the server.

•CSCsq48296— If the persistence-rebalance command is enabled under an HTTP parameter map, the ACE may lose the MSS setting in the middle of a flow. Workaround: Configure the set tcp wan-optimization rtt 0 command under a connection parameter map.

•CSCsq68949—When you use the CSM2ACE utility, a duplicate parameter map may be created when the utility converts a CSM vserver to the ACE equivalent class map. Workaround: Manually delete duplicate parameter maps and update the ACE configuration to use the consolidated parameter map.

•