December 17, 2016 | Author: anukeeperi4959 | Category: N/A
Release Note for the Cisco ACE Application Control Engine Module July 26, 2012
Note
The most current Cisco documentation for released products is available on Cisco.com.
Contents This release note applies to software version A5(2.0) for the Cisco Application Control Engine Module (ACE), model ACE30 (ACE30_MOD_K9). For information on the ACE module features and configuration details, see the ACE documentation located at: http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html This release note contains the following sections: •
New Software Features in Version A5(2.0)
•
Chassis, Supervisor Engine, and Cisco IOS Support for the ACE30 Module
•
Virtual Switching System Support
•
ACE Operating Considerations
•
Available ACE Licenses
•
Ordering an Upgrade License and Generating a License Key
•
Upgrading Your ACE Module Software in a Redundant Configuration
•
Downgrading Your ACE Module Software in a Redundant Configuration
•
ACE Documentation Set
•
ACE Troubleshooting Wiki
•
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
•
Obtaining Documentation and Submitting a Service Request
Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2012 Cisco Systems, Inc. All rights reserved.
New Software Features in Version A5(2.0)
New Software Features in Version A5(2.0) This section describes the new features associated with ACE module software Version A5(2.0). The information presented in this section builds on the information available in the documentation set for ACE software Version A5(1.0), which you can find at the following URLs: •
ACE configuration documentation doc set: http://www.cisco.com/en/US/products/hw/modules/ps2706/products_installation_and_configuratio n_guides_list.html
•
ACE command reference: http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA5_1_0/command/r eference/ACE_cr.html
Software version A5(2.0) provides the following new features: •
Buddy Sticky Groups that Enable Persistence Across Multiple Server Farms
•
Support for Static NAT IPv4-to-IPv6 and IPv6-to-IPv4 Translation
•
Support for DNS IPv4-to-IPv6 and IPv6-to-IPv4 Load Balancing with Inspection
•
Maintain a Full Proxy Connection During a TCP Handshake Mismatch
•
Support for a Wildcard KAL-AP GSS IP Address
•
SSL Probe Configuration Option for Ignoring the Certificate Expiration Date
•
Support for Additional Syslog Logging Hosts
•
Support for SSL Session ID Stickiness
•
Support for the ACE No Payload Encryption Software Version
•
Support for Creation of RDP Parameter Maps
•
Ability to Enable Regular Expression Download Optimization
•
Extended Range of Supported Characters in a URL
•
Configuring an SNMP Peer Engine ID for the Standby ACE
•
Configuring an SNMP User Authentication Password for the Standby ACE
•
Ability for the ACE to Accept a User Account with an Expired Date
•
Addressing SSL Certificates With a Subject or Issuer That is Greater Than 256 Bytes
•
ACE Probes Use the Interface MAC Address as the Source MAC Address
Release Note for the Cisco ACE Application Control Engine Module
2
OL-26643-01
New Software Features in Version A5(2.0)
Buddy Sticky Groups that Enable Persistence Across Multiple Server Farms ACE software version A5(2.0) allows you to create buddy sticky groups that enable persistence to a real server or real server group across multiple server farms. Prior software releases allow you to configure stickiness within a single server farm only using sticky groups. You use the buddy sticky group feature for the following applications: •
One-to-one association—Sticks the client to the same physical server instances in two different server farms (see the “One-to-One Association Application Example” section on page 4).
•
Asymmetric association—Sticks a client to a real server that is configured on different server farms even when the client comes back with a non-HTTP request or different HTTP header (see the “Asymmetric Association Application Example” section on page 6).
•
Many-to-one association—Sticks multiple, first-tier real servers to one real server in a second tier that contains fewer servers (see the “Many-to-One Association Application Example” section on page 9).
Note
The ACE buddy sticky group feature does not support the one-to-many application.
To use the buddy group feature, you perform the following steps while configuring the ACE for load balancing: 1.
Create real server buddy sticky groups when specifying the real servers in a server farm. You make a real server a member of a real server buddy group by using the new buddy command in the server farm host real server configuration mode. The command syntax is as follows: buddy group_name where group_name is the name of a new or existing real server buddy sticky group. Enter 1 to 64 alphanumeric characters. Example host1/admin(config)# serverfarm sfarm1 host1/admin(config-sfarm-host)# rserver rserv12 host1/admin(config-sfarm-host-rs)# buddy blue
2.
Create sticky server farm buddy groups when specifying the server farms in a sticky group. You make a sticky server farm a member of a buddy sticky group by using the new member command in sticky configuration mode. The command syntax is as follows: member group_name where group_name is the name of a new or existing server farm buddy sticky group. Enter 1 to 64 alphanumeric characters. Example host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-cart host1/admin(config-sticky-ip)# serverfarm http host1/admin(config-sticky-ip)# member alpha
This section includes the following topics: •
Guidelines and Restrictions, page 4
•
One-to-One Association Application Example, page 4
•
Asymmetric Association Application Example, page 6
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
3
New Software Features in Version A5(2.0)
•
Many-to-One Association Application Example, page 9
•
Displaying Buddy Sticky Group Information, page 11
Guidelines and Restrictions •
When two sticky groups with different timeout values are buddied together, the ACE uses the shortest timeout value for the buddy group.
•
Sticky groups to be buddied together must of the same type, such as all IP-sticky, all http-cookie, and so forth. The ACE does not support different types of sticky groups buddied together.
•
When two sticky groups are buddied together and one of them is configured for timeout active connections, the member group is also configured for timeout active connections.
•
When two sticky groups are configured with different IP netmask (IPv4) or prefix-length (IPv6), the ACE uses the one with the most granular netmask or prefix-length.
•
When a static entry is created under a buddy sticky group, its behavior is unchanged and it sticks to the same real server configured regardless of the buddy group that real server is associated with.
•
Before you can configure a sticky group as a member, you must have a server farm configured under that sticky group and all the real servers that belong to that server farm have buddy group configured under them. This requirement prevents invalid configurations.
•
The ACE does not support configuring the following types of sticky groups as buddy sticky group members: – SSL – RTSP Header
•
The ACE supports PTMP sticky group such as SIP sticky; however, you must make sure that the configuration is the same across both sticky groups for the buddy sticky group feature to work.
•
For real server backup applications: – We recommend only 1 level of backup-rserver with buddy sticky. – If you add a buddy group to the primary real server, the backup server inherits this buddy group.
However, if you remove the buddy group from the primary real server, the buddy group is not removed from the backup real server and vice versa. •
You can display information related to buddy sticky group configurations (see the “Displaying Buddy Sticky Group Information” section on page 11).
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 1, the ACE is configured with the following server farms, their associated real servers, and the buddy sticky groups that group both items:
Server Farm http (for HTTP requests)
Server Farm Buddy Member Group
Real Server
Real Server Buddy Group
alpha
1nx1:192.168.1.11:80
blue
1nx2:192.168.1.12:80
red
Release Note for the Cisco ACE Application Control Engine Module
4
OL-26643-01
New Software Features in Version A5(2.0)
Server Farm Buddy Member Group
Server Farm
https alpha (for HTTPS requests)
Real Server Buddy Group
1nx1:192.168.1.11:443
blue
1nx2:192.168.1.12:443
red
Buddy Sticky Groups: One-to-One Association
Int: 172.16.1.5 VIP 172.16.1.100 Internet Client
VLAN 20 172.16.1.1 Multilayer Switch Feature Card
VLAN 40
1nx1 192.168.1.11:80 192.168.1.11:443
Server Farm http (alpha)
blue
192.168.1.1 ACE 1nx2 192.168.1.12:80 192.168.1.12:443
Server Farm https (alpha) 332431
Figure 1
Real Server
red
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 1 and shows the buddy group-related values in bold text: host1/admin(config)# serverfarm http host1/admin(config-sfarm-host)# rserver lnx1 host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# rserver lnx2 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# exit host1/admin(config)# serverfarm https host1/admin(config-sfarm-host)# rserver lnx1 443
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
5
New Software Features in Version A5(2.0)
host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# rserver lnx2 443 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-cart host1/admin(config-sticky-ip)# serverfarm http host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-credit host1/admin(config-sticky-ip)# serverfarm https host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# class-map cart-vip host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq www host1/admin(config-cmap)# exit host1/admin(config)# class-map checkout-vip host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq https host1/admin(config-cmap)# exit host1/admin(config)# policy-map type loadbalance http first-match cart-lb host1/admin(config-pmap-lb)# class class-default host1/admin(config-pmap-lb-c)# sticky-serverfarm stick-cart host1/admin(config-pmap-lb-c)# exit host1/admin(config-pmap-lb)# exit host1/admin(config)# policy-map type loadbalance http first-match checkout-lb host1/admin(config-pmap-lb)# class class-default host1/admin(config-pmap-lb-c)# sticky-serverfarm stick-credit host1/admin(config-pmap-lb-c)# exit host1/admin(config-pmap-lb)# exit host1/admin(config)# policy-map multi-match shopping-cart host1/admin(config-pmap)# class cart-vip host1/admin(config-pmap-c)# loadbalance vip inservice host1/admin(config-pmap-c)# loadbalance policy cart-lb host1/admin(config-pmap-c)# exit host1/admin(config-pmap)# exit host1/admin(config-pmap)# class checkout-vip host1/admin(config-pmap-c)# loadbalance vip inservice host1/admin(config-pmap-c)# loadbalance policy checkout-lb
Asymmetric Association Application Example In an asymmetric buddy sticky group association, you create a buddy sticky group that sticks all Layer 7 traffic from a client to a specific real server even when some of the traffic does not match the Layer 7 class map. In the network example shown in Figure 2, the ACE is configured to include the following server farms, their associated real servers, and assigned real server buddy sticky groups:
Release Note for the Cisco ACE Application Control Engine Module
6
OL-26643-01
New Software Features in Version A5(2.0)
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 2
Buddy Sticky Groups: Asymmetric Association
Server Farm foo (alpha)
Internet Client
VLAN 20 172.16.1.1 Multilayer Switch Feature Card
VLAN 40 192.168.1.1 ACE
1nx1 192.168.1.11 blue Server Farm bar (alpha)
Server Farm foobar (alpha)
1nx2 192.168.1.12 red
332433
Int: 172.16.1.5 VIP 172.16.1.100
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 2 and shows the buddy group-related values in bold text: host1/admin(config)# serverfarm foo host1/admin(config-sfarm-host)# rserver lnx1 host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# exit
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
7
New Software Features in Version A5(2.0)
host1/admin(config-sfarm-host)# exit host1/admin(config)# serverfarm bar host1/admin(config-sfarm-host)# rserver lnx2 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# exit host1/admin(config)# serverfarm foobar host1/admin(config-sfarm-host)# rserver lnx1 host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# rserver lnx2 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-foo host1/admin(config-sticky-ip)# serverfarm foo host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-bar host1/admin(config-sticky-ip)# serverfarm bar host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address both stick-foobar host1/admin(config-sticky-ip)# serverfarm foobar host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# class-map app-vip host1/admin(config-cmap)# match virtual-address 172.16.1.100 any host1/admin(config-cmap)# exit host1/admin(config)# class-map type http loadbalance match-all app-foo host1/admin(config-cmap)# match http url /app-foo/.* host1/admin(config-cmap)# exit host1/admin(config)# class-map type http loadbalance match-all app-bar host1/admin(config-cmap)# match http url /app-bar/.* host1/admin(config-cmap)# exit host1/admin(config)# policy-map type loadbalance host1/admin(config-pmap-lb)# class app-foo host1/admin(config-pmap-lb-c)# sticky-serverfarm host1/admin(config-pmap-lb-c)# exit host1/admin(config-pmap-lb)# class app-bar host1/admin(config-pmap-lb-c)# sticky-serverfarm host1/admin(config-pmap-lb-c)# exit host1/admin(config-pmap-lb)# class class-default host1/admin(config-pmap-lb-c)# sticky-serverfarm
http first-match slb foo
bar
foobar
Release Note for the Cisco ACE Application Control Engine Module
8
OL-26643-01
New Software Features in Version A5(2.0)
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 3, 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
db1:192.168.1.21:123
blue
db1:192.168.1.22:123
red
app (second tier)
alpha
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
9
New Software Features in Version A5(2.0)
Figure 3
Buddy Sticky Groups: Many-to-One Association
First Tier Servers
Second Tier Servers
Server Farm web (alpha)
Server Farm app (alpha)
1nx1 192.168.1.11:80 blue db1 192.168.1.21:123 1nx2 192.168.1.12:80
1nx3 192.168.1.13:80 red
1nx4 192.168.1.14:80
332432
db2 192.168.1.22:123
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 3 and shows the buddy group-related values in bold text: host1/admin(config)# serverfarm web host1/admin(config-sfarm-host)# rserver lnx1 80 host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# inservice host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# rserver lnx2 80 host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# inservice host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# rserver lnx3 80 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# inservice
Release Note for the Cisco ACE Application Control Engine Module
10
OL-26643-01
New Software Features in Version A5(2.0)
host1/admin(config-sfarm-host)# rserver lnx4 80 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# inservice host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# exit host1/admin(config)# serverfarm app host1/admin(config-sfarm-host)# rserver db1 host1/admin(config-sfarm-host-rs)# buddy blue host1/admin(config-sfarm-host-rs)# inservice host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# rserver db2 host1/admin(config-sfarm-host-rs)# buddy red host1/admin(config-sfarm-host-rs)# inservice host1/admin(config-sfarm-host-rs)# exit host1/admin(config-sfarm-host)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address source web host1/admin(config-sticky-ip)# serverfarm web host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# sticky ip-netmask 255.255.255.255 address source db host1/admin(config-sticky-ip)# serverfarm db host1/admin(config-sticky-ip)# member alpha host1/admin(config-sticky-ip)# exit host1/admin(config)# class-map web host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq 80 host1/admin(config-cmap)# exit host1/admin(config)# class-map db host1/admin(config-cmap)# match virtual-address 172.16.1.100 tcp eq 81 host1/admin(config-cmap)# exit host1/admin(config)# policy-map type loadbalance http first-match web host1/admin(config-pmap-lb)# class class-default host1/admin(config-pmap-lb-c)# sticky-serverfarm web host1/admin(config-pmap-lb-c)# exit host1/admin(config-pmap-lb)# exit host1/admin(config)# policy-map type loadbalance http first-match db host1/admin(config-pmap-lb)# class class-default host1/admin(config-pmap-lb-c)# sticky-serverfarm db host1/admin(config-pmap-lb-c)# exit host1/admin(config-pmap-lb)# exit host1/admin(config)# policy-map multi-match web-db host1/admin(config-pmap)# class web host1/admin(config-pmap-c)# loadbalance vip inservice host1/admin(config-pmap-c)# loadbalance policy web host1/admin(config-pmap-c)# exit host1/admin(config-pmap)# class db host1/admin(config-pmap-c)# loadbalance vip inservice host1/admin(config-pmap-c)# loadbalance policy db
Displaying Buddy Sticky Group Information The following CLI show commands have been modified to include buddy sticky group information: •
show sticky database—Command now includes the buddy keyword, which displays buddy sticky entries separately from sticky entries.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
11
New Software Features in Version A5(2.0)
Example host1/Admin# show sticky database buddy member group : red type : IP timeout : 720 timeout-activeconns : TRUE sticky-entry rserver-instance time-to-expire flags ---------------------+-----------------+--------------+-------+ 250232353865662720 rs1:0 43196 Total Sticky Entries: 1
•
show rserver detail—Command output now includes the buddy group associated with the real server in a particular server farm. Example switch/Admin# show rserver detail rserver : rs1, type: HOST state : OPERATIONAL (verified by arp response) description : max-conns : , out-of-rotation count : min-conns : conn-rate-limit : , out-of-rotation count : bandwidth-rate-limit : , out-of-rotation count : weight : 8 ------------------------------------------connections----------real weight state current total ---+---------------------+------+------------+----------+-------------------serverfarm: sf1 10.10.10.2:0 8 OPERATIONAL 0 2 max-conns : , out-of-rotation count : min-conns : conn-rate-limit : , out-of-rotation count : bandwidth-rate-limit : , out-of-rotation count : total conn-failures : 0 buddy group : blue serverfarm: sf2 10.10.10.2:0 max-conns min-conns conn-rate-limit bandwidth-rate-limit total conn-failures buddy group : red
•
8 : : : : :
0
OPERATIONAL 0 0 , out-of-rotation count , ,
out-of-rotation count out-of-rotation count
: : : -
show serverfarm detail—Command output now includes the buddy group associated with the real servers in the server farm. Example switch/Admin# show serverfarm detail serverfarm : sf1, type: HOST total rservers : 5 active rservers: 5 description : state : ACTIVE predictor : ROUNDROBIN failaction : back-inservice : 0 partial-threshold : 0 num times failover : 1 num times back inservice : 4
Release Note for the Cisco ACE Application Control Engine Module
12
OL-26643-01
New Software Features in Version A5(2.0)
total conn-dropcount : 0 ------------------------------------------connections----------real weight state current total failures ---+---------------------+------+------------+----------+----------+--------rserver: rs1 10.10.10.2:0 8 OPERATIONAL 0 2 0 max-conns : , out-of-rotation count : min-conns : conn-rate-limit : , out-of-rotation count : bandwidth-rate-limit : , out-of-rotation count : retcode out-of-rotation count : buddy group : blue rserver: rs2 10.10.10.3:0 8 OPERATIONAL 0 0 max-conns : , out-of-rotation count : min-conns : conn-rate-limit : , out-of-rotation count : bandwidth-rate-limit : , out-of-rotation count : retcode out-of-rotation count : buddy group : red
•
0
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 prior to expiry Total active sticky entries Total active reverse sticky entries Total active buddy sticky entries Total active sticky conns Total static sticky entries Total sticky entries from Global Pool Total insertion failures due to lack of resources
•
: 0 : : : : : : :
1 0 1 0 0 1 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
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
13
New Software Features in Version A5(2.0)
r3
0
sf-v6-2
rs1-v4
0
sf1-main
rs-main
0
sf2-main
rs1-v4
0
sf2-nobuddy
Support for Static NAT IPv4-to-IPv6 and IPv6-to-IPv4 Translation ACE software version A5(2.0) allows you to configure mixed-mode static network address translation (NAT) configurations in which the connections between the client and server use a mix of IPv4 and IPv6 addresses as follows: •
IPv4 server or source address to an IPv6 address
•
IPv6 server or source address to an IPv4 address
These configuration options are in addition to the same-mode static NAT mapping options (IPv4 to IPv4 and IPv6 to IPv6) available with previous software releases, which do not support mixed-mode static NAT configurations. The three static NAT applications for mixed mode are as follows: •
Static Destination NAT and Dynamic Source NAT— Uses a combination of static destination NAT and dynamic source NAT for mapping a mixed mode application in which the client uses IPv4 and the application server uses IPv6 (see the “Static Destination NAT and Dynamic Source NAT Mixed-Mode Application” section on page 14).
•
Static Destination NAT and Static Source NAT—Use static NAT only for mapping a mixed mode application in which the client uses IPv4 and the application server uses IPv6 (see the “Static Destination NAT and Static Source NAT Mixed-Mode Application” section on page 16).
•
Static NAT for a Subnet—Use static NAT to map a set of private IP addresses to a set of global IP addresses with a subnet (also referred to as the many-to-many application).
Guidelines and Restrictions
For details about configuring static NAT, see the “Configuring Static NAT and Static Port Redirection as a Policy Action” section in the Security Guide vA5(1.0), Cisco ACE Application Control Engine Guide. The information that the guide provides for configuring same-mode static NAT mapping can be used for mixed-mode configurations. This section includes the following topics: •
Static Destination NAT and Dynamic Source NAT Mixed-Mode Application, page 14
•
Static Destination NAT and Static Source NAT Mixed-Mode Application, page 16
•
Static NAT for Subnets, page 16
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 4). 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.
Release Note for the Cisco ACE Application Control Engine Module
14
OL-26643-01
New Software Features in Version A5(2.0)
Mixed Mode Static Destination NAT and Dynamic Source NAT Application
ACE
Client
C4 (IPv4)
S’4
Server C’6
S6 (IPv6) 343990
Figure 4
S6 mapped to S'4 (Static NAT) C4 mapped to C'6 (Static NAT), C'6 mapped to S6 (Dymanic NAT) For this application, the two types of NAT are used as follows: •
Static Destination NAT: Maps S6 (IPv6) to S’4 (IPv4) in client side VLAN
•
Dynamic Source NAT: Maps C’6 (IPv4) to S6 (IPv6) after NAT maps C4 to C’6
Example
The following example shows how to configure the ACE for the application described in this section: access-list acl-01 line 8 extended permit ip any any class-map match-any ANY 2 match any class-map match-all nat 2 match source-address 2001:3008::1:1/128 policy-map multi-match doSrcNatANY class ANY nat dynamic 10 vlan 3008
-->Server IP address
-->Src NAT any traffic hitting client VLAN
policy-map multi-match static_nat class nat -->Matching server IPv6 nat static 10.8.2.1 netmask 255.255.255.255 vlan 2008 -->Mapped to IPv4 IP hosted on client VLAN 2008 access-group input acl-01 interface vlan 2008 ip address 10.8.0.3 255.255.0.0 alias 10.8.0.1 255.255.0.0 peer ip address 10.8.0.2 255.255.0.0 service-policy input doSrcNatAny -->Do src NAT on all traffic hitting the client VLAN no shutdown interface vlan 3008 ipv6 enable ip address 2001:3008::1/100 ip address 192.168.0.3 255.255.0.0 nat-pool 10 2001:3008::3:1 2001:3008::3:1/100 -->Choose one of the IP from the pool service-policy input static_nat -->Static NAT applied on egress/server side VLAN no shutdown
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
15
New Software Features in Version A5(2.0)
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 5). 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. Mixed-Mode Static NAT Application
ACE
Client
C4 (IPv4)
S’4
Server C’6
S'4 mapped to S6 (Static NAT) C'6 mapped to C4 (Static NAT)
S6 (IPv6) 343989
Figure 5
For this application, static NAT is used as follows: •
Static Destination NAT: Maps S6 (IPv6) to S’4 (IPv4) in client side VLAN
•
Static Source NAT: Maps C’6 (IPv4) to S6 (IPv6) after NAT maps C4 to C’6
Example
The following example shows how to configure the ACE for the application described in this section: class-map 2 match class-map 2 match
match-all src_server_s6 source-address 2001:3017::1:1 match-all src_client_c4 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.
Release Note for the Cisco ACE Application Control Engine Module
16
OL-26643-01
New Software Features in Version A5(2.0)
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 2 match class-map 2 match
match-all src_server_s6 source-address 2001:3017::1:0/120 match-all src_client_c4 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.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
17
New Software Features in Version A5(2.0)
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 ip address inservice rserver host ip address inservice rserver host ip address inservice rserver host ip address inservice rserver host ip address inservice rserver host ip address inservice rserver host ip address inservice rserver host ip address inservice
v4-rs-01 10.10.1.1 v4-rs-02 10.10.1.2 v4-rs-03 10.10.1.3 v4-rs-04 10.10.1.4 v6-rs-01 2002::1e11:101 v6-rs-02 2002::1e11:102 v6-rs-03 2002::1e11:103 v6-rs-04 2002::1e11:104
serverfarm host mixed-farm rserver v4-rs-01 inservice rserver v6-rs-01 inservice serverfarm host v4-sf-01
Release Note for the Cisco ACE Application Control Engine Module
18
OL-26643-01
New Software Features in Version A5(2.0)
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 2 match class-map 2 match class-map 2 match class-map 2 match
match-any v4-vip-traffic-01 virtual-address 172.16.2.1 udp match-any v4-vip-traffic-02 virtual-address 172.16.2.2 udp match-any v6-vip-traffic-01 virtual-address 2002::1411:201 match-any v6-vip-traffic-02 virtual-address 2002::1411:202
eq domain eq domain udp eq domain 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
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
19
New Software Features in Version A5(2.0)
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
Maintain 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.
Release Note for the Cisco ACE Application Control Engine Module
20
OL-26643-01
New Software Features in Version A5(2.0)
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:
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
21
New Software Features in Version A5(2.0)
– All GSS devices in the cluster use a secure channel for a KAL-AP message exchange with the
ACE. Do not use the wildcard IP address if any GSS in the cluster uses an insecure channel. – All or a set of GSS devices in the cluster use the same MD5 secret.
Note
You can only use the wildcard VIP address for one set of GSS devices that use the same MD5 secret. You must configure all other GSS devices individually for KAL-AP.
•
When using the no form of the command to remove a KAL-AP IP address, using the wildcard IP address removes only those VIPs that use the secret associated with the wildcard value. KAL-AP IP addresses that were defined using a specific GSS IP addresses remain and must be removed individually.
•
For details about using the CLI to configure a secure KAL-AP, see the “Configuring Secure KAL-AP” section in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.
Examples
The following example shows how to configure a secure KAL-AP on the ACE using the wildcard IP address (0.0.0.0) for all GSS devices that use the secret “andromeda”: host1/admin(config)# kalap udp host1/admin(config-kalap-udp)# ip address 0.0.0.0 encryption md5 secret andromeda
The following example shows how to configure a secure KAL-AP on the ACE using a specific GSS IP address (192.168.11.1): host1/admin(config)# kalap udp host1/admin(config-kalap-udp)# ip address 192.168.11.1 encryption md5 secret andromeda2
To disable the secure KAL-AP for all GSS devices that use the secret associated with the wildcard IP address (in this example, andromeda), enter: host1/admin(config-kalap-udp)# no ip address 0.0.0.0
SSL Probe Configuration Option for Ignoring the Certificate Expiration Date ACE software version A5(2.0) allows you to configure an SSL probe to ignore the certificate expiration date, which allows the ACE to establish the connection even when the SSL certificate has expired. Previous software releases do not provide the option to ignore the certificate expiration date. The ssl https probe configuration mode command now includes the certificate- expiration ignore command option that configures the probe to ignore the SSL certificate expiration date. The output of the show probe probe_name detail now includes information about the state of the certificate expiration ignore setting. Guidelines and Restrictions
For more information about using the CLI to configure an SSL probe, see the “Configuring an HTTPS Probe” section in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.
Release Note for the Cisco ACE Application Control Engine Module
22
OL-26643-01
New Software Features in Version A5(2.0)
Examples
The following example shows how to configure an SSL probe that ignores the certificate expiration date: host1/admin(config)# probe https ssl_probe host1/admin(config-probe-https)# ssl certificate-expiration ignore
The following example shows how to display the probe details, including the state of the certificate expiration ignore setting: host1/admin# show ssl_probe detail probe
: ssl_probe
type
: HTTPS
state
: INACTIVE
description : ---------------------------------------------port
: 443
addr type : pass count: 3
address
: 0.0.0.0
interval
: 15
fail count: 3
SSL version
: All
SSL cipher
: RSA_ANY
pass intvl
: 60
recv timeout: 10
SSL certificate-check : Ignore http method
: GET
http url
: /
conn termination : GRACEFUL expect offset
: 0
regex cache-len
: 0
expect regex
: -
send data
, open timeout
: 1
: ------------------ probe results ------------------
associations
ip-address
port porttype probes failed passed health
------------ ----------------------+----+--------+------+------+------+------
Support for Additional Syslog Logging Hosts ACE software version A5(2.0) allows you to specify up to four hosts (the syslog servers) to receive the syslog messages sent by the ACE. Previous software releases allow you to specify a maximum of two syslog servers. To configure the ACE with a syslog server, you use the logging host command in configuration mode. To specify additional syslog servers, repeat the command for each server. To remove a syslog server, use the no form of the command. Guidelines and Restrictions •
On an ACE module, you can enable 256 servers only. That is, if there are four syslog servers in a context, then you can only configure 64 such contexts. You cannot a add a syslog server for the 65th context.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
23
New Software Features in Version A5(2.0)
•
For more information about using the CLI to configure the ACE with syslog logging hosts, see the “Sending Syslog Messages to a Syslog Server” section in the System Message Guide vA5(1.0), Cisco ACE Application Control Engine. Examples The following example show how to use the CLI to configure the ACE with a syslog server: host1/Admin(config)# logging host 192.168.10.1 tcp/1025 format emblem default-udp The following example show how to use the CLI to remove a syslog server: host1/Admin(config)# no logging host 192.168.10.1
Support for SSL Session ID Stickiness ACE software version A5(2.0) allows you to configure SSL session ID stickiness using the new SSL sticky and HTTPS policy map features. Previous software releases require a more involved process to configure SSL session ID stickiness in which you configure a generic protocol-parsing policy and a sticky group of type layer-4-payload with attributes configured to locate the SSL session ID inside the payload. To configure SSL session ID stickiness using ACE software version A5(2.0), the sticky command has been modified to include the ssl option and the policy-map type loadbalance command has been modified to include the https option. After creating the SSL sticky, you apply it to an HTTPS policy map. This section includes the following topics: •
Using the Modified sticky Command for SSL Session ID Stickiness, page 24
•
Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness, page 25
Using the Modified sticky Command for SSL Session ID Stickiness The modified syntax of the sticky configuration mode command is as follows: sticky {http-content | http-cookie | http-header | ip-netmask | layer4-payload | radius | rtsp-header | sip|header | ssl | v6-prefix} name no sticky {http-content | http-cookie | http-header | ip-netmask | layer4-payload | radius | rtsp-header | sip|header | ssl | v6-prefix} name The ssl keyword has been added for configuring a sticky that is based on the SSL session ID. When you enter this command, the prompt changes to the sticky SSL content configuration mode (config-sticky-content) where you use the commands listed in Table 1 to define the SSL sticky attributes. Table 1
Sticky SSL Content Configuration Mode Commands
Command
Description
length id_length
Specify the number of bytes in the SSL ID to parse. For the id_length argument, enter a value from 1 to 65535. The default is 32 bytes.
replicate sticky
Instructs the ACE to replicate SSL content sticky table entries on the standby ACE.
Release Note for the Cisco ACE Application Control Engine Module
24
OL-26643-01
New Software Features in Version A5(2.0)
Table 1
Sticky SSL Content Configuration Mode Commands (continued)
Command
Description
response sticky
Enables the sticky for response.
serverfarm server_farm
Specifies a server farm entry for the sticky group. For the argument, enter a unique server farm identifier using an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.
static ssl-id ssl_id
Defines the static SSL session ID string. For the ssl_id argument, enter the SSL ID ASCII or hex string (for hex: \xstring). The maximum string length is 255 characters.
timeout {timeout | activeconns} Configures the SSL sticky timeout as follows: •
timeout—Specifies the number of minutes that the ACE remembers the last real server to which a client made a sticky connection. Enter a value from 1 to 65535. The default timeout value is 1440 minutes (24 hours).
•
activeconns—Specifies that sticky entries are timed out when the sticky timer expires even if there are active connections.
Guidelines and Restrictions •
By default, the SSL sticky offset is set to 43 bytes and the begin pattern is set to \x20|\x00\xST.
•
To display the SSL sticky statistics, the show sticky database command now includes the ssl session_id keyword and argument options.
•
After creating the SSL sticky, you must apply it to an HTTPS policy map (see the “Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness” section on page 25).
•
For more information about using the CLI to configure stickiness, see the “Configuring Stickiness” chapter in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.
Examples
The following example shows to create an SSL sticky (SSL_STICKY) and configure its attributes: host1/Admin(config)# sticky ssl host1/Admin(config-sticky-ssl)# host1/Admin(config-sticky-ssl)# host1/Admin(config-sticky-ssl)#
SSL_STICKY length 125 serverfarm SERVERFARM_SSL timeout 720
The following example shows to remove an SSL sticky: host1/Admin(config)# no sticky ssl SSL_STICKY
Using the Modified policy-map type loadbalance Command for SSL Session ID Stickiness The modified syntax of the policy-map type loadbalance configuration mode command is as follows: policy-map type loadbalance {first-match | generic | http | https | radius | rdp | rtsp | sip} The https keyword has been added for configuring a policy map for a sticky that is based on the SSL session ID. The complete syntax for the command when using the https keyword is as follows: policy-map type loadbalance https first-match map_name
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
25
New Software Features in Version A5(2.0)
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:
Step 1
Command
Purpose
match name source-address
Specifies the source address as the inline match condition, which is the only inline match condition required for SSL session parsing.
Example host1/Admin(config-pmap-lb-https)# match HTTPS source-address
Step 2
class class-default Example host1/Admin(config-pmap-lb-https)# class class-default
Step 3
sticky-serverfarm sfarm_name Example host1/Admin(config-pmap-lb-https-c)# sticky-serverfarm SERVERFARM_SSL
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). 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. Specifies the sticky server farm associated with the SSL sticky group (see the “Using the Modified sticky Command for SSL Session ID Stickiness” section on page 24).
Guidelines and Restrictions
For more information about using the CLI to create a policy map, see the “Configuring Traffic Policies for Server Load Balancing” chapter in the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine. Examples
The following example shows how to configure an HTTPS policy map to include the server farm (SERVERFARM_SSL) associated with the SSL sticky (SSL_STICKY) created in the previous section: host1/Admin(config)# policy-map type loadbalance https first-match PMAP_HTTPS host1/Admin(config-pmap-lb-https)# match HTTPS source-address host1/Admin(config-pmap-lb-https)# class class-default host1/Admin(config-pmap-lb-https-c)# sticky-serverfarm SERVERFARM_SSL
Release Note for the Cisco ACE Application Control Engine Module
26
OL-26643-01
New Software Features in Version A5(2.0)
Support for the ACE No Payload Encryption Software Version With ACE software Version A5(2.0), Cisco makes available the following two ACE software versions: •
ACE Payload Encryption (PE)—CLI commands related to payload encryption protocols are enabled. The ACE uses the payload encryption protocols, such as SSL, to encrypt through-the-box traffic. The ACE PE software version contains the same payload encryption functionality found in previous ACE software versions.
•
ACE No Payload Encryption (NPE)—CLI commands related to payload encryption protocols are either removed or do not function because the key encryption configuration commands have been removed. The new ACE NPE software version supports customers located in countries where the United States has imposed export restrictions on crypto functions. Without the use of payload encryption protocol commands, you cannot configure the ACE to perform data encryption tasks, such as configuring it as a virtual Secure Sockets Layer (SSL) server for SSL initiation or termination.
Note
Modifications made to the ACE NPE software version do not affect management protocols, such as SSH, which is required to access the Device Manager GUI.
Table 2 lists the CLI commands that are removed from the ACE A5(2.0) NPE software version. Table 2
Commands Removed from the ACE A5(2.0) NPE Software Version
CLI Mode Exec
Removed Commands •
crypto {delete | export | generate csr | import | verify}
•
ssl-proxy service name
host1/Admin#
Config
Removal of this command also removes the following related SSL proxy configuration mode commands:
host1/Admin(config)#
(accessed using the config command from Exec mode)
– authgroup – cert – chaingroup – crl – key – ocspserver – revcheckprio – ssl •
probe https name
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
27
New Software Features in Version A5(2.0)
Table 3 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 2). Table 3
Non-Functioning or Modified Commands in the ACE A5(2.0) NPE Software Version
CLI Mode
Removed Commands
Exec
Non functioning commands:
host1/Admin#
•
backup exclude ssl-files
•
clear stats crypto [client | server [alert | authentication | cipher | termination]]
•
debug cfgmgr sslstats
•
restore [all] disk0:archive_filename exclude ssl-files [licenses]
•
show cfgmgr internal table ssl-proxy [all | context | detail]
•
show crypto {aia-errors | authgroup | cdp-errors | certificate | chaingroup | crl | csr-params | files | key | ocspserver | session}
•
show ip https
•
show np 1 me-stats ucdump_option where ucdump_option is one of the following: – F – A – a
•
show stats crypto {client [alert | authentication | cipher | termination]} | server [alert | authentication | cipher | insert | redirect | termination]}
•
show stats probe type https
Modified commands: •
show license status: Command output does not contain the SSL transactions per second listing.
•
show resource usage resource rate ssl-connections counter [all | current | denied | peak]: Command output does not contain SSL connection information.
Release Note for the Cisco ACE Application Control Engine Module
28
OL-26643-01
New Software Features in Version A5(2.0)
Table 3
Non-Functioning or Modified Commands in the ACE A5(2.0) NPE Software Version
CLI Mode
Removed Commands
Config
Non functioning commands:
host1/Admin(config)#
•
access-list name extended {permit | deny} tcp {ipv4_address | ipv6address | any | anyv6 | host | object-group} {any | eq | gt | host | lt | neq | object-group | range} {ldaps | https}
•
ip https certificate cert key
•
parameter-map type ssl name
(accessed using the config command from Exec mode)
Removal of this command also removes the following related ssl parameter-map configuration mode commands: – authentication failure – cdp-error ignore – cipher – close-protocol – expired-crl reject – purpose-check disabled – queue-delay timeout – rehandshake enabled – session-cache timeout – version
Non functioning commands:
Action list modify host1/Admin(config-actlistmodify)#
(accessed using the action-list type modify http name command) Policy map class
•
ssl header-insert {client-cert specific_field | server-cert specific_field | session specific_field} [prefix prefix_string | rename new_field_name]
•
ssl url rewrite location expression [clearport number] [sslport number]
Non functioning commands:
host1/Admin(config-pmap-c)#
(accessed using the policy-map type multi-match name command from config mode and then the class name command from the policy map mode)
•
nat static [ipv6_address/prefix_length | ipv4_address netmask mask] tcp eq https vlan number
•
ssl-proxy server name
Non functioning commands:
Policy map class
•
host1/Admin(config-pmap-c)#
ssl-proxy server name
(accessed using the policy-map type first-match name command from config mode and then the class name command from the policy map mode)
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
29
New Software Features in Version A5(2.0)
Table 3
Non-Functioning or Modified Commands in the ACE A5(2.0) NPE Software Version
CLI Mode
Removed Commands
Policy map load balancing HTTP class
Non functioning commands: •
ssl-proxy client
host1/Admin(config-pmap-lb-c)#
(accessed using the class name command from policy map load balancing HTTP config mode) Class map HTTP load balancing
Non functioning commands: •
host1/Admin(config-cmap-http-lb)#
match cipher {equal-to | less-than} cipher
(accessed using the class-map type http loadbalance match-any name command from config mode) Role configuration
Non functioning commands:
host1/Admin(config-role)#
•
(accessed using the role name command from config mode)
rule number {permit | deny} {create | debug | modify | monitor} feature {pki | ssl}
Support for Creation of RDP Parameter Maps The Microsoft Remote Desktop Protocol (RDP) provides users with remote display and input capabilities over network connections for Windows-based applications running on a terminal server. In a load-balancing configuration, the ACE distributes incoming session connections across the terminal servers in a server farm according to the load-balancing method configured on the server farm. For background on RDP load balancing as performed by the ACE, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine. Per CSCua04753, the ACE now supports the use of a parameter map for RDP load-balancing connections. By default, if the real server that matches the routing token information in the RDP packet from the client is DOWN, the connection will be reset and the RDP packet will be dropped. By configuring routing-token-rebalance under an RDP-type parameter map and applying that parameter map to a VIP, if the real server that matches the routing token information is DOWN, RDP packets will not be dropped and the connection will be redirected to another server. The following topics describe how to define an RDP parameter map and associate it with a server-load balancing policy map: •
Configuring an RDP Parameter Map
•
Defining a Description to the RDP Parameter Map
•
Enabling Routing Token Rebalance in the RDP Parameter Map
•
Associating the RDP Parameter Map with a Layer 3 and Layer 4 Network Traffic Policy Map
Release Note for the Cisco ACE Application Control Engine Module
30
OL-26643-01
New Software Features in Version A5(2.0)
Configuring an RDP Parameter Map The parameter map type rdp command specifies an RDP-type parameter map. After you create the parameter map, you configure settings in RDP parameter map configuration mode. You then reference this parameter map in the policy map using the appl-parameter rdp advanced-options command. The syntax of the parameter map type rdp configuration mode command is as follows: parameter map type rdp name The name argument specifies the name assigned to the RDP parameter map. Enter an unquoted text string with no spaces and a maximum of 64 alphanumeric characters. For example, to create a RDP-type parameter map called RDP_MAP, enter: host1/Admin(config)# parameter-map type rdp RDP_MAP host1/Admin(config-parammap-rdp)#
To remove the RDP parameter map, use the no form of this command.
Defining a Description to the RDP Parameter Map You can provide a brief summary of the RDP parameter map by using the description command in RDP parameter map configuration mode. The syntax of this command is as follows: description text For the text argument, enter an unquoted text string with a maximum of 240 alphanumeric characters including spaces. For example, to specify a description of an RDP parameter map, enter the following command: host1/Admin(config-parammap-rdp)# description Remote Desktop Protocol parameter map
To remove the description from the RDP parameter map, enter: host1/Admin(config-parammap-rdp)# no description
Enabling Routing Token Rebalance in the RDP Parameter Map You enable the routing-token-rebalance function in the RDP parameter map by using the routing-token-rebalance command in RDP parameter map configuration mode. There are no arguments for this command. For example, enter the following command: host1/Admin(config-parammap-rdp)# routing-token-rebalance
To remove the routing-token-rebalance command from the RDP parameter map, enter: host1/Admin(config-parammap-rdp)# no routing-token-rebalance
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
31
New Software Features in Version A5(2.0)
Associating the RDP Parameter Map with a Layer 3 and Layer 4 Network Traffic Policy Map You associate the RDP parameter map with a Layer 3 and Layer 4 network traffic policy map by using the appl-parameter rdp advanced-options command in policy-map class configuration mode.
Note
For details on configuring a Layer 3 and Layer 4 policy map for network traffic, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine. The syntax of this command is as follows: appl-parameter rdp advanced-options name The name argument identifies the existing RDP parameter map. For example, to specify the appl-parameter rdp advanced-options command as an action for the network traffic policy map, enter: host1/Admin(config)# policy-map multi-match L4SLBPOLICY host1/Admin(config-pmap)# class FILTERRDP host1/Admin(config-pmap-c)# appl-parameter rdp advanced-options RDP_MAP
To disassociate the RDP parameter map as an action from the network traffic policy map, enter: host1/Admin(config-pmap-c)# no appl-parameter rdp advanced-options RDP_MAP
Ability to Enable Regular Expression Download Optimization When you perform a number of configuration changes while traffic is running, either administrative tasks such as putting a real server inservice and out-of-service, or Layer 7 configuration changes such as modifying one or more class maps within a policy, these changes may result in traffic hitting an incorrect policy and being sent to the incorrect server farm. In this case, the HTTP regex tree gets recompiled and downloaded after every configuration change even if the change is limited to inservice/no inservice of a real server which does not alter the HTTP regex tree. Per CSCtz37625, the ACE now displays the hidden command limit-regex-dnld enable in configuration mode to enable regular expression download optimization. When you specify the limit-regex-dnld enable command, the HTTP regex tree is not re-compiled and downloaded when performing processes such as putting a real server inservice and out-of-service. This feature is disabled by default. To view information related to the regex download optimization status, the show download information command has been added to software version A5(2.0). switch/Admin# show download information context: Admin Regex download optimization status: ENABLED Interface Download-status -----------------------------------------------------200 Completed 165 Completed 1006 Completed
Release Note for the Cisco ACE Application Control Engine Module
32
OL-26643-01
New Software Features in Version A5(2.0)
Extended Range of Supported Characters in a URL In software releases prior to A5(2.0), the ACE HTTP parser accepted characters in the range of 32 to 126 characters in the UTF-8 encoding schema for URLs. Per CSCts64534, with software release A5(2.0) the ACE has extended support for characters in the range from 128 to 255 (all characters) in the UTF-8 encoding schema for URLs. This extended range is allowed only when the parsing non-strict command is configured in the HTTP parameter map configuration mode.
Configuring an SNMP Peer Engine ID for the Standby ACE In prior releases, the ACE allowed you to configure an SNMP engine ID that applied to both the active and standby ACE. Per CSCtq59860, you can configure a different engine ID for the standby ACE in a redundant configuration. The snmp-server engineid command in configuration mode includes the new peer engineid peer_value option. The syntax of this command is as follows: snmp-server engineid local_value [peer engineid peer_value] The local_value argument is the engine ID for the active ACE. If you do not enter the peer engineid value_2 option, the local_value argument applies to both the active and standby ACEs. To change the value of an engine ID, you must change both values. Otherwise, the ACE displays the following error message: Enter valid value for engineid/peer engineid Either both should be same or both should change
To change the peer_value argument, you must also change the local_value argument, or visa versa, for example: host/Admin(config)# snmp-server engineid 1234567892 peer engineid 2234567891 host/Admin(config)# snmp-server engineid 2134567892 peer engineid 2324567891
To change a configuration in which the active and standby engine IDs are different to a value that is the same value for both engine IDs, you must enter a value that is different for both IDs, for example: host/Admin(config)# snmp-server engineid 2134567892 peer engineid 2324567891 host/Admin(config)# snmp-server engineid 4567892213
When synchronization occurs in a redundant configuration, consider the following: •
When both the active and standby ACEs are running software versionA5(2.0) and you configure different local and peer engine IDs on the active ACE, the active ACE sends the local engine ID as the peer ID to the standby ACE, and the peer engine ID as the local ID. For example, the running configuration on the ACEs will be similar to the following: – On the active ACE: snmp-server engineid 2134567892 peer engineid 2324567891 – On the standby ACE: snmp-server engineid 2324567891 peer engineid 2134567892
•
When the active ACE is running software version A5(2.0) and the standby ACE is running a software version less than A5(2.0) and you configure different local and peer engine IDs on the active ACE, the active ACE verifies that the software version on the standby ACE and sends only the peer engine ID as the local ID to the standby ACE. For example, the running configuration on the ACEs will be similar to the following: – On the active ACE: snmp-server engineid 2134567892 peer engineid 2324567891 – On the standby ACE: snmp-server engineid 2324567891
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
33
New Software Features in Version A5(2.0)
•
When the active ACE is running a software version less than A5(2.0) and the standby ACE is running software version A5(2.0) and since you can configure only one engine ID on the active ACE, the active ACE sends the engine ID to the standby ACE. The local and peer engine IDs on the standby ACE will have the same value. For example, the running configuration on the ACEs will be similar to the following: – On the active ACE: snmp-server engineid 2134567892 – On the standby ACE: snmp-server engineid 2134567892 peer engineid 2134567892
Use the no form of this command to delete the SNMP engine IDs. If you delete one engine ID, the other engine ID is also deleted. The show snmp engineID command has been modified to display the identification of the peer SNMP engine in addition to the local SNMP engine configured on the ACE. If you use the show snmp engineID command on the standby ACE, the local SNMP engine ID will be the peer engine ID presented in the active ACE. For example, you can configure different SNMPv3 engine IDs for active and standby ACEs: host1/Admin(config)# snmp-server engineid 1234567890 peer engineid 0987654321 host1/Admin(config)# do show snmp engineID Local SNMP engineID: 1234567890 PEER SNMP engineID: 0987654321
Release Note for the Cisco ACE Application Control Engine Module
34
OL-26643-01
New Software Features in Version A5(2.0)
Configuring an SNMP User Authentication Password for the Standby ACE Per CSCtq60293, when you configure Simple Network Management Protocol (SNMP) user information, you can specify a peer privacy password for user authentication parameters or user encryption parameters. Upon a switchover from an active ACE to the standby ACE, the snmp-server user command privacy passwords synchronize between the active and standby ACEs. The modified keywords, arguments, and options are as follows: snmp-server user user_name [group_name] [auth {md5 | sha} local_password1 peer peer_password1] [priv [aes-128] local_password2 peer peer_password 2] [localizedkey]] •
Note
peer peer_password1—(Optional) Used for user authentication parameters to specify an authentication password for a peer user on a standby ACE. Enter an unquoted text string with no space and a maximum of 130 alphanumeric characters. The ACE automatically synchronizes the SNMP authentication password as the password for the CLI user on the standby ACE. The peer password is optional; if you do not enter a peer password the ACE will use the local password for the peer user on a standby ACE. The ACE supports the following special characters in a password: , . / = + - ^ @ ! % ~ # $ * ( ) .
•
Note
peerpeer_password2 —(Optional) Used for user encryption parameters to specify a privacy password for a peer user on a standby ACE. The peer password is optional; if you do not enter a peer password the ACE will use the local password for the peer user on a standby ACE. Note the following specifications for the user encryption peer password: – The AES priv password can have a minimum of eight characters. – If the passphrases are specified in clear text, you can specify a maximum of 64 alphanumeric
characters. – If you use the localized key, you can specify a maximum of 130 alphanumeric characters.
Spaces are not allowed. The ACE supports the following special characters in a password: , . / = + -^@!%~#$*(). By default, the ACE automatically creates an SNMP engine ID for the Admin context and each user context. The SNMP engine represents a logically separate SNMP agent. In prior releases, the ACE allowed you to configure an SNMP engine ID that applied to both the active and standby ACE. With software version A5(2.0), you can configure a different engine ID for the standby ACE in a redundant configuration (see the “Configuring an SNMP Peer Engine ID for the Standby ACE” section). Included below are a set of running configuration examples that illustrate the interaction between the SNMP engine ID and SNMP user password configured for the active and standby ACEs in a redundant configuration. SNMP Engine ID is the Same for the Active and Standby ACEs and SNMP User Password is the Same for the Active and Standby ACEs host1/Admin(config)# snmp-server engineid 1234567890 peer engineid 1234567890 host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer abcd12345 host1/Admin(config)# do show running-config | inc snmp Generating configuration.... snmp-server engineid 1234567890 peer engineid 1234567890 snmp-server user usr1 Network-Monitor auth md5 0xea2410e3deaf422dab2ad979d406825 7 peer 0xea2410e3deaf422dab2ad979d4068257 localizedkey
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
35
New Software Features in Version A5(2.0)
SNMP Engine ID is the Same for the Active and Standby ACEs and SNMP User Password is Different for the Active and Standby ACEs host1/Admin(config)# snmp-server engineid 1234567890 peer engineid 1234567890 host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer ghijk12345 host1/Admin(config)# do show running-config | inc snmp Generating configuration.... snmp-server engineid 1234567890 peer engineid 1234567890 snmp-server user usr1 Network-Monitor auth md5 0xea2410e3deaf422dab2ad979d406825 7 peer 0x2285eb39064716bdae814e038bcba6c4 localizedkey
SNMP Engine ID is Different for the Active and Standby ACEs and SNMP User Password is the Same for the Active and Standby ACEs host1/Admin(config)# snmp-server engineid 123456789010 peer engineid 0987654321 host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer abcd12345 host1/Admin(config)# do show running-config | inc snmp Generating configuration.... snmp-server engineid 123456789010 peer engineid 0987654321 snmp-server user usr1 Network-Monitor auth md5 0x4d1d46812f0484674e98ba5757ed7aa 7 peer 0x95312cbb53b1ef8c8c556fa5a2378fa7 localizedkey
SNMP Engine ID is Different for the Active and Standby ACEs and SNMP User Password is Different for the Active and Standby ACEs host1/Admin(config)# snmp-server engineid 123456789010 peer engineid 0987654321 host1/Admin(config)# snmp-server user usr1 auth md5 abcd12345 peer dfgh12345 host1/Admin(config)# do show running-config | inc snmp Generating configuration.... snmp-server engineid 123456789010 peer engineid 0987654321 snmp-server user usr1 Network-Monitor auth md5 0x4d1d46812f0484674e98ba5757ed7aa 7 peer 0x30778af5b6239945f2bae806112676b3 localizedkey
Release Note for the Cisco ACE Application Control Engine Module
36
OL-26643-01
New Software Features in Version A5(2.0)
Ability for the ACE to Accept a User Account with an Expired Date You create a user and define the associated role and operating domains by using the username command in configuration mode. You can optionally specify an expiration date of the user account. In software releases prior to A4(2.3), when the user account is configured with a specified expiration date in the past (with reference to the ACE system clock), the ACE displays the error message “date should be in the future, expiry date wrong” and the configuration is then rejected. When operating in a redundant configuration, when the username expires, the expired configuration is not removed from the running-configuration file on the active ACE which can result in synchronization issues. Per CSCtx45830, with software release A4(2.3), when the user account is configured with an expiry date in the past (with reference to the ACE system clock), the ACE displays the error message “User created with expiry date in the past, please edit to make it usable, which allows the configuration to be accepted. You can then modify the expiration date associated with the user account. The change allows an expired “username” configuration to be accepted. For example: host1/Admin(config)# do show clock Wed Mar 14 11:16:09 UTC 2012 host1/Admin(config)# username abcd pass cisco123 expire 2012-03-10 role Network-Monitor domain default-domain User created with expiry date in the past, please edit to make it usable host1/Admin(config)#
Addressing SSL Certificates With a Subject or Issuer That is Greater Than 256 Bytes Per CSCtx64223, when the subject or issuer of an imported SSL certificate is greater than 256 bytes the ACE truncates the output of imported certificate when displayed by using the show crypto certificate all command. Note that the imported certificate is not affected by this truncation; if you export the certificate you will still be able to see the correct (greater than 256 byte) subject or issuer in the certificate. As an example, included below is authcert2 with the full subject: Subject: /C=US/ST=Georgia/L= Friendly Village of Crooked Creek/O=State Community College of Friendly Village of Crooked Creek/OU=Department of Thermonuclear and Quantum Physics/CN=www.statecommununitycollegeoffriendlyvillageofcrookedcreek.edu/emailAddress=adm
[email protected]
Included below is an example of the current show crypto certificate all command output behavior in releases prior to 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/emailAddresIssue r: / C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division,CN=Thawte Server CA/
[email protected] Not Before: Dec 8 14:57:27 2009 GMT Not After: Sep 3 14:57:27 2012 GMT CA Cert: FALSE
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
37
New Software Features in Version A5(2.0)
And here is an example of this updated show crypto certificate all command output behavior in software version A5(2.0). host1/Admin# show crypto cert all authcert2 Subject: /C=US/ST=Georgia/L= Friendly Village of Crooked Creek/O=State Community College of Friendly Village of Crooked Creek/OU=Department of Thermonuclear and Quantum Physics/CN=www.statecommununitycollegeoffriendlyvillageofcrookedcreek.edu/emailAddres Issuer: / C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division,CN=Thawte Server CA/
[email protected] Not Before: Dec 8 14:57:27 2009 GMT Not After: Sep 3 14:57:27 2012 GMT CA Cert: FALSE
With software version A5(2.0), the ACE prints a warning message when importing a certification with a subject or issuer that is greater than 256 bytes. host1/Admin# crypto import terminal 1.pem Please enter PEM formatted data. End with "quit" on a new line. -----BEGIN CERTIFICATE----MIIEOzCCA6SgAwIBAgIJAOKKpTWQqvrjMA0GCSqGSIb3DQEBBQUAMGsxCzAJBgNV BAYTAkpQMQ4wDAYDVQQIDAVUb2t5bzEQMA4GA1UECgwHQ29tcGFueTEMMAoGA1UE CwwDdHMzMRAwDgYDVQQDDAdqdW5pY2hpMRowGAYJKoZIhvcNAQkBFgtqdW5AanVu LmNvbTAeFw0xMjAxMTcwNTA5NDRaFw0xMzAxMTYwNTA5NDRaMIIB1TELMAkGA1UE BhMCSlAxSTBHBgNVBAgMQGFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWExSTBHBgNVBAcMQGJiYmJi YmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi YmJiYmJiYmJiYmIxSTBHBgNVBAoMQGNjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2MxSTBHBgNVBAsM QGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRk ZGRkZGRkZGRkZGRkZGRkZGQxSTBHBgNVBAMMQGVlZWVlZWVlZWVlZWVlZWVlZWVl ZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWUxTzBN BgkqhkiG9w0BCQEWQGZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmYwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALolNEP5y5UhhnzXmam3UZo1z9JuLc8ZcYHc415SDA5LKHDFIZN8 WKjJjypRe+jadalXaK8WM1yDGDlaM3JxQXZ4F+V5FNHhpTUxtfnvnpePWMmrP4jZ owehkThgaXBqRq3XyLFhErxqE3VIIOU6j9EYbFeiZIfNlCiTvr5xFiOHAgMBAAGj ezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVk IENlcnRpZmljYXRlMB0GA1UdDgQWBBT0DegeQfhf5TKa7E1Ixcw3gTYLODAfBgNV HSMEGDAWgBQgBnaGwQfnkTa5vsz+38FffwKlyDANBgkqhkiG9w0BAQUFAAOBgQBG lH6ipRK2my5ND391XJGnf7xraRuBGKRdXAbCArCtH2Nbt5nM//kQHZx0im7go+Zq 25bzBnyFvUoS6HM09P+elzPeY4ZjeJ+vRL8qbQgOsI1yEUEAwbeNilYGjFwI1SZG ubvFPJRYplab7Bb217C9u4J6wZDmxdcSbRAh7pNHUA== -----END CERTIFICATE----quit Warning: this cert has a subject or issuer DN that is longer than 256 bytes, the 'show crypto certificate all' command truncates anything beyond 256 bytes in the subject and issuer fields
ACE Probes Use the Interface MAC Address as the Source MAC Address When an ACE-configured probe closes internally or times-out internally, a RST is generated. Per CSCtj65372, a change has occurred in this RST to have the source MAC address use the nterface MAC address instead of the current behavior of using the virtual MAC address. The inclusion of the interface MAC address allows both the active and standby ACEs in an HA pair to send the RST packet out with the source MAC as its respective interface MAC rather than a common virtual MAC address. This changes impacts the following probes types: TCP, FTP, HTTP, and HTTPS.
Release Note for the Cisco ACE Application Control Engine Module
38
OL-26643-01
Chassis, Supervisor Engine, and Cisco IOS Support for the ACE30 Module
Chassis, Supervisor Engine, and Cisco IOS Support for the ACE30 Module Table 4 and Table 5 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 4
Chassis, Supervisor Engine, and Cisco IOS Support for the ACE 30 in a Catalyst 6500 Series Switch with a Multilayer Switch Feature Card (MSFC3 or Later)
Catalyst 6500 Series Switch Chassis Supervisor Engine Model 6503-E
VS-S2T-10G 3
6504-E
VS-S2T-10G-XL WS-SUP720-3B
6506-E 6509-E
1
15.0(1)SY (or later) 12.2(33)SXI4 or later releases
WS-SUP720-3BXL
6509-V-E
VS-S720-10G-3C(=)
6513
VS-S720-10G-3CXL(=)
6513-E
Minimum Required Cisco IOS Version
2
1. The Catalyst 6509-E chassis supports up to six ACE 30 modules with Supervisor Engine 2T (VS-S2T-10G or VS-S2T-10G-XL), and running Cisco IOS software version 15.0(1)SY1 (or later) with ACE module software version A5(2.0). 2. The Catalyst 6513-E chassis supports up to nine ACE 30 modules with Supervisor Engine 2T (VS-S2T-10G or VS-S2T-10G-XL), and running Cisco IOS software version 15.0(1)SY1 (or later) with ACE module software version A5(2.0). 3. The minimum required ACE30 module software version for Supervisor Engine 2T support is A5(1.1) or later. This software version supports both supervisor engine models: VS-S2T-10G and VS-S2T-10G-XL.
Table 5
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
15.0(1)S or later releases
7604
WS-SUP720-3BXL
7609
RSP720-3C-GE(=)
7613
RSP720-3CXL-GE(=)
7603-S
RSP720-3C-10GE
7604-S
RSP720-3CXL-10GE
7606-S 7609-S
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
39
Virtual Switching System Support
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 6. We recommend that you do not make any configuration changes during this time and that you do not keep the ACEs in this state for an extended period of time. However, if you must make configuration changes while the ACEs are in split mode, ensure that you manually synchronize to the standby ACE any configuration changes that you make on the active ACE. After you complete the software upgrade of both ACEs, a bulk sync occurs automatically to replicate the entire configuration of the new active ACE to the new standby ACE. At this time, dynamic incremental sync will be enabled again. For details about config sync, see Chapter 6, “Configuring Redundant ACEs” in the Administration Guide, Cisco ACE Application Control Engine.
Table 6
Redundancy Feature Availability Between Major ACE Software Versions
Platform
Active
Standby
Bulk Sync
Incr Sync
Conn Repl
Sticky Repl
Operation
Comments
Module
A2(x)
A5(x)
Yes
No
Yes
Yes
Upgrade
—
Module
A4(1.x)
A5(x)
Yes
No
Yes
Yes
Upgrade
—
Module
A4(2.x)
A5(x)
Yes
No
Yes
Yes
Upgrade
—
Release Note for the Cisco ACE Application Control Engine Module
40
OL-26643-01
ACE Operating Considerations
Table 6
Redundancy Feature Availability Between Major ACE Software Versions (continued)
Platform
Active
Standby
Bulk Sync
Incr Sync
Conn Repl
Sticky Repl
Operation
Module
A5(x)
A2(x)
No
No
No
No
Downgrade Functionality not supported due to architectural differences between the ACE20 and the ACE30 hardware
Module
A5(x)
A4(1.x)
Yes
No
Yes (IPv4 flows)
Yes (IPv4 flows)
Downgrade Standby supports only IPv4
Module
A5(x)
A4(2.x)
Yes
No
Yes (IPv4 flows)
Yes (IPv4 flows)
Downgrade Standby supports only IPv4
•
Comments
During an upgrade in a redundant configuration, we recommend that you do not run the two ACEs with different versions of software (split mode) for an extended period of time. However, if you must remain in split mode for a period of time to make configuration changes, we strongly recommend that you disable configuration synchronization (config sync) by entering the following command: host1/Admin(con)# no ft auto-sync running-config
When you have finished making configuration changes to the active ACE, reenable config sync by entering the following command: host1/Admin(con)# ft auto-sync running-config
After you reenable config sync, the ACE automatically synchronizes the configuration changes from the active ACE to the standby ACE. •
We strongly recommend that you do not make any CLI changes when the ACE modules in a redundant configuration are running different software versions. Unexpected results may occur. Remove any new feature commands before performing a downgrade on the ACE.
•
In software version A4(1.0) or later, all four of the network processors (NPs) must transition into the retcode or inband failed state before the ACE marks the real server as RETCODE-FAILED or INHAND-HM-FAILED, respectively, and places it on the reactivate list for recovery. This is also true for the maxconn limit, where the threshold values are divided among all four NPs similar to the retcode and inband failed states. The real servers will move to the MAXCONN state only when all four NPs reach the MAXCONN state. Note that the following may occur: – When some NPs are in the retcode failed state and the other NPs are in the inband failed state
due to a traffic pattern that hashes connections to specific NPs, the real servers are in the OPERATIONAL state as displayed by the show serverfarm name command because the NPs are deadlocked waiting until the other NPs reach the retcode or inband failed state, respectively. – When some NPs are in the retcode or inband failed state due to a traffic pattern that hashes only
to some NPs and not to the other NPs, the real servers are left in the OPERATIONAL state until all NPs transition into the retcode or inband failed state, respectively.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
41
Available ACE Licenses
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 7. Table 7
ACE30 License Bundles
License Bundle
Product ID (PID)
License File
Description
Base (default)
ACE30-BASE-04-K9
None required
4 Gbps bandwidth 1 Gbps compression 1,000 SSL TPS 5 Virtual Contexts
Base to 4 Gbps
ACE30-MOD-UPG1= ACE30-MOD-UPG1
4 Gbps Bundle
ACE30-MOD-04-K9
4 Gbps bandwidth 6 Gbps compression ACE30-MOD-04-K9 30,000 SSL TPS 250 Virtual Contexts
Release Note for the Cisco ACE Application Control Engine Module
42
OL-26643-01
Ordering an Upgrade License and Generating a License Key
Table 7
ACE30 License Bundles (continued)
License Bundle
Product ID (PID)
License File
4 Gbps to 8 Gbps
ACE30-MOD-UPG2= ACE30-MOD-UPG2
8 Gbps Bundle
ACE30-MOD-08-K9
Description
8 Gbps bandwidth 6 Gbps compression ACE30-MOD-08-K9 30,000 SSL TPS 250 virtual contexts
8 Gbps to 16 Gbps ACE30-MOD-UPG3= ACE30-MOD-UPG3 16 Gbps Bundle
ACE30-MOD-16-K9
16 Gbps bandwidth 6 Gbps compression ACE30-MOD-16-K9 30,000 SSL TPS 250 virtual contexts
You can also obtain an ACE demo license for each license bundle. You can get a demo license that is valid for 30 or 90 days. At the end of this period, you will need to update the demo license with a permanent license to continue to use the ACE software. To view the expiration of the demo license, use the show license usage command in Exec mode. If you need to replace the ACE module, you can copy and install the licenses onto the replacement module.
Note
You can access the license and show license commands only in the Admin context. You must have the Admin role in the Admin context to perform the tasks of installing, removing, and updating the license.
Ordering an Upgrade License and Generating a License Key This section describes the process to order an upgrade license and to generate a license key for your ACE. To order an upgrade license, perform the following steps: Step 1
Order one of the licenses from the list in the “Obtaining Documentation and Submitting a Service Request” section using any of the available Cisco ordering tools on Cisco.com.
Step 2
When you receive the Software License Claim Certificate from Cisco, follow the instructions that direct you to the cisco.com website. As a registered user of cisco.com, go to this URL: http://www.cisco.com/go/license
Step 3
Enter the Product Authorization Key (PAK) number found on the license certificate as your proof of purchase.
Step 4
Provide all the requested information to generate a license key.
Step 5
After the system generates the license key, you will receive a license key e-mail with an attached license file and installation instructions. Save the license key e-mail in a safe place in case you need it in the future (for example, to transfer the license to another ACE).
For information about installing and managing ACE licenses, refer to Chapter 3, Managing ACE Software Licenses, in the Administration Guide, Cisco ACE Application Control Engine.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
43
Upgrading Your ACE Module Software in a Redundant Configuration
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.0), 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.0) the procedure in the following section assumes that your ACEs are configured as redundant peers to ensure that there is no disruption to existing connections during the upgrade process. In the following procedure, the active ACE is referred to as ACE-1 and the standby ACE is referred to as ACE-2. This section includes the following topics: •
Before You Begin
•
Upgrade Procedure
Before You Begin Before you upgrade your ACE software, be sure that your ACE configurations meet the upgrade prerequisites in the following sections:
Note
•
Changing the Admin Password
•
Changing the www User Password
•
Creating a Checkpoint
•
Copying the Startup Configuration of Each Context
•
Checking Your Configuration for FT Priority and Preempt
If you are upgrading a redundant configuration from A5(1.x), A4(2.x), or A4(1.x) to version A5(2.0) while the two ACEs are in split mode with the earlier software version running on the active ACE and software version A5(2.0) 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.
Release Note for the Cisco ACE Application Control Engine Module
44
OL-26643-01
Upgrading Your ACE Module Software in a Redundant Configuration
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#
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
45
Upgrading Your ACE Module Software in a Redundant Configuration
Step 2
Save the running configurations of every context by entering the write memory all command in Exec mode in the Admin context of each ACE. ACE-1/Admin# write memory all
Step 3
Create a checkpoint in each context of both ACEs by entering the checkpoint create command in Exec mode. ACE-1/Admin# checkpoint create ADMIN_CHECKPOINT ACE-1/Admin# changeto C1 ACE-1/C1# checkpoint create C1_CHECKPOINT
Step 4
Copy the new software image to the image directory of each ACE (active and standby) by entering the copy ftp, copy sftp, or the copy tftp command in Exec mode. For example, to copy the image with the name c6ace-t1k9-mz.A5_2_0.bin through FTP, enter: ACE-1/C1# changeto Admin ACE-1/Admin# copy ftp://server1/images//c6ace-t1k9-mz.A5_1_0.bin image: Enter source filename[/images/c6ace-t1k9-mz.A5_2_0.bin]? Enter the destination filename[]? [c6ace-t1k9-mz.A5_2_0.bin] File already exists, do you want to overwrite?[y/n]: [y] Enter hostname for the ftp server[server1]? Enter username[]? user1 Enter the file transfer mode[bin/ascii]: [bin] Enable Passive mode[Yes/No]: [Yes] no Password:
Step 5
Ensure that the new software image is present on both the active and standby ACEs by entering the dir command in Exec mode. For example, enter: ACE-1/Admin# dir image:c6ace-t1k9-mz.A5_2_0.bin 35913728 June 1 2012 01:17:01 c6ace-t1k9-mz.A5_2_0.bin Usage for image: 828182528 54165504 882348032
Step 6
filesystem bytes total used bytes free bytes total
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
Release Note for the Cisco ACE Application Control Engine Module
46
OL-26643-01
Upgrading Your ACE Module Software in a Redundant Configuration
Step 9
Step 10
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.
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
Step 11
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.
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.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
47
Downgrading Your ACE Module Software in a Redundant Configuration
Downgrading Your ACE Module Software in a Redundant Configuration If you need to downgrade your ACE software from version A5(2.0) 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.0) 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.0) 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#
Release Note for the Cisco ACE Application Control Engine Module
48
OL-26643-01
Downgrading Your ACE Module Software in a Redundant Configuration
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.0) commands in the startup-configuration file.
Note
Step 5
Dynamic incremental sync is automatically disabled while the active ACE is running software version A5(2.0) and the standby ACE is running software version A5(1.x), A4(2.x), or A4(1.x).
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.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
49
ACE Documentation Set
ACE Documentation Set You can access the ACE module documentation on www.cisco.com at: http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html For information about installing the ACE module hardware, see the following documents on Cisco.com: Document Title
Description
Installation Note, Cisco ACE Provides information for installing the ACE module into the Catalyst Application Control Engine 6500 series switch or a Cisco 7600 series router. ACE30 Module To familiarize yourself with the ACE module software, see the following documents on Cisco.com: Document Title
Description
Release Note for the Cisco Application Control Engine Module
Provides information about operating considerations and caveats for the ACE.
Getting Started Guide, Cisco ACE Application Control Engine Module
Describes how to perform the initial setup and configuration tasks for the ACE module.
In addition to this document, the ACE module software documentation set includes the following: Document Title
Description
Administration Guide, Cisco ACE Application Control Engine
Describes how to perform the following administration tasks on the ACE: •
Setting up the ACE
•
Establishing remote access
•
Managing software licenses
•
Configuring class maps and policy maps
•
Managing the ACE software
•
Configuring SNMP
•
Configuring redundancy
•
Configuring the XML interface
•
Upgrading the ACE software
Cisco Application Control Engine Provides examples of common configurations for load (ACE) Configuration Examples Wiki balancing, security, SSL, routing and bridging, virtualization, and so on. Cisco Application Control Engine (ACE) Troubleshooting Wiki
Describes the procedures and methodology in wiki format to troubleshoot the most common problems that you may encounter during the operation of your ACE.
Release Note for the Cisco ACE Application Control Engine Module
50
OL-26643-01
ACE Documentation Set
Document Title
Description
Command Reference, Cisco ACE Application Control Engine
Provides an alphabetical list and descriptions of all CLI commands by mode, including syntax, options, and related commands.
Cisco CSM-to-ACE Conversion Tool Describes how to use the CSM-to-ACE module conversion tool User Guide to migrate Cisco Content Switching Module (CSM) running- or startup-configuration files to the ACE. Cisco CSS-to-ACE Conversion Tool User Guide
Describes how to use the CSS-to-ACE conversion tool to migrate Cisco Content Services Switches (CSS) running-configuration or startup-configuration files to the ACE.
Routing and Bridging Guide, Cisco ACE Application Control Engine
Describes how to perform the following routing and bridging tasks on the ACE:
Security Guide, Cisco ACE Application Control Engine
Server Load-Balancing Guide, Cisco ACE Application Control Engine
•
VLAN interfaces
•
IPv6, including transitioning IPv4 networks to IPv6, IPv6 header format, IPv6 addressing, and supported protocols
•
Routing
•
Bridging
•
Dynamic Host Configuration Protocol (DHCP)
Describes how to perform the following ACE security configuration tasks: •
Security access control lists (ACLs)
•
User authentication and accounting using a Terminal Access Controller Access Control System Plus (TACACS+), Remote Authentication Dial-In User Service (RADIUS), or Lightweight Directory Access Protocol (LDAP) server
•
Application protocol and HTTP deep packet inspection
•
TCP/IP normalization and termination parameters
•
Network Translation (NAT)
Describes how to configure the following server load-balancing features on the ACE: •
Real servers and server farms
•
Class maps and policy maps to load balance traffic to real servers in server farms
•
Server health monitoring (probes)
•
Stickiness
•
Dynamic workload scaling (DWS)
•
Firewall load balancing
•
TCL scripts
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
51
ACE Troubleshooting Wiki
Document Title
Description
SSL Guide, Cisco ACE Application Control Engine
Describes how to configure the following Secure Sockets Layer (SSL) features on the ACE: •
SSL certificates and keys
•
SSL initiation
•
SSL termination
•
End-to-end SSL
System Message Guide, Cisco ACE Application Control Engine
Describes how to configure system message logging on the ACE. This guide also lists and describes the system log (syslog) messages generated by the ACE.
Virtualization Guide, Cisco ACE Application Control Engine
Describes how to operate your ACE in a single context or in multiple contexts.
For detailed configuration information on the Cisco Application Networking Manager (ANM), see the following software document on Cisco.com: User Guide, Cisco Application Networking Manager
Describes how to use Cisco Application Networking Manager (ANM), a networking management application for monitoring and configuring network devices, including the ACE.
ACE Troubleshooting Wiki The ACE documentation set now includes the ACE Troubleshooting Wiki. This wiki is a collaborative site that describes the basic procedures and methodology to assist you in troubleshooting the most common problems that you may encounter while you are operating your ACE. As a registered user of Cisco.com, we strongly encourage you to add content to this site in the form of troubleshooting tips, procedures, or even entire sections. When you add content to the site, you should adhere to the format that has been established for the wiki. To access the Troubleshooting Wiki on Cisco DocWiki, click the following URL: http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_%28ACE%29_Troubleshooting_G uide
Release Note for the Cisco ACE Application Control Engine Module
52
OL-26643-01
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages This release note includes resolved and open caveats that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats in software version A5(2.0): •
Software Version A5(2.0) Resolved Caveats
•
Software Version A5(2.0) Open Caveats
•
Software Version A5(2.0) Command Changes
•
Software Version A5(2.0) System Log Messages
Software Version A5(2.0) Resolved Caveats The following resolved caveats apply to software version A5(2.0): •
CSCtd33226—The SNMP daemon can be very slow to respond (for example, a delay of approximately 10 to 15 minutes) when the ACE receives a malformed SNMP packet or there is a heavy utilization of SNMP polls. Workaround: None.
•
CSCtf28855—If you configure the no inservice standby command under a real server, when you reboot the ACE, the running-configuration file incorrectly lists "inservice standby" in the configuration file. The running-configuration file should be the same as before and after the reboot of the ACE. Workaround: None.
•
CSCtg87855—After you change the configuration in a large ACE configuration and enter show commands, the CLI becomes unresponsive for a period of time. In this case, the show processes cpu | include cfgmgr command displays one of the configuration manager (cfgmgr) processes consuming CPU resources. After you apply the configuration change, the cfgmgr CPU usage goes to zero, and the CLI becomes unresponsive. Workaround: Wait until the cfgmgr completes its previous operation before entering the show command.
•
CSCth20813—In a multi-threaded code, some calls are unsafe and may cause the ACE to reboot. Workaround: None.
•
CSCth67961—When you enter the show snmp group command from any context other than the Admin context, it does not display any output. Workaround: None.
•
CSCth77759—The CSS2ACE conversion link can be directly accessed with a non-Admin role. Workaround: Access the CSS2ACE conversion link from the ACE main index page.
•
CSCti85313—When using the sticky-serverfarm command to specify that all requests that match a Layer 7 policy map are load balanced to a sticky server farm, if a server farm goes down, the ACE fails to display the following system message %ACE-5-441003: Serverfarm (name) failed in policy_map (policy_name) --> class_map (cmap_name) without backup. Number of failovers = count1, number of times back in service = count2
Workaround: None. •
CSCtj18833—When you configure an ACE in a bridge mode which has a static ARP entry for the real server, and after the ACE reboots, the ARP entry for a real server is in the down (dn) state. Workaround: Remove the static entry and readd it.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
53
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
•
CSCtj24719—When the ACE has mixed TCP and UDP SIP traffic running at a high rate for five to six hours to a combination of Layer 7 and Layer 4 VIPs, the show serverfarm name command may display some real servers with current connections after the traffic has stopped and the connections have closed. Workaround: None.
•
CSCtj60979—The ACE suddenly reloads with the reason identified as “me-dumper crash.” In rare cases, the show np 1 me-stats command causes the me-dumper crash.Workaround: None.
•
CSCtk12683—All SSL probes on the ACE fail with the following reason: “No SYN/ACK returned from server”. However, if you perform a trace, the trace shows that the TCP SYN from the ACE is not on the wire. This behavior is due to a configuration change that caused the access control list (ACL) to be downloaded to the internal VLAN 4095. The ACL failed, causing the Data Plane (DP) to reject the TCP SYN for the SSL probes being sent by the Control Plane (CP). Workaround: Reboot the ACE. If this action does not resolve the issue, try another configuration change to force the ACL to be downloaded again to the internal VLAN.
•
CSCtk68122—When you configure the least loaded predictor in a server farm, the ACE does not set the autoadjust average option. Workaround: None.
•
CSCtl20133—When you enable the logging persistent command, it allows the ACE to save a specified syslog to its flash memory. As expected, the ACE creates a "messages" file on disk0. However, after you delete this file, the logging persistent command does not work again until you remove and reconfigure the command. Workaround: Remove and reconfigure the logging persistent command.
•
CSCtl76773—When you create a real server, class map, policy map, KAL-AP tag, server farm, or context name that includes a space in it, an ACE redundant configuration can become out of synchronization. Workaround: Do not use spaces when naming an object on the ACE.
•
CSCtn31362—When remote AAA server are configured in multiple contexts and XML requests through HTTP are sent to multiple contexts, occasionally the ACE reboots when the AAA daemon becomes unresponsive. For this configuration, the structure for the session is getting freed. After freeing, the session.vcid element is used for printing causing the AAA daemon to become unresponsive. Also the other local variable is used for printing. Workaround: None.
•
CSCtn78507—When either a SIP or RADIUS protocol-related configuration is present on the ACE that requires per-request load balancing, the ACE does not generate a connection teardown syslog and any translation syslogs that the ACE generates have a corrupt IP address. Workaround: None.
•
CSCtn98107—When you configure the ACE for redundancy with many contexts and some of these contexts have large configurations, and then you reboot the ACE, a context transitions to the STANDBY COLD state. The FT-related output did not display the correct command that failed in the context. Workaround: Perform the no inservice command and then the inservice command on the FT group. For the context in the STANDBY COLD state, assign it with a context ID number greater than one.
•
CSCto02825—The ACE allows users to configure inconsistent netmasks and fails to notify them of the inconsistency. For example, in this case the access-lists have inconsistent netmasks: access-list acl1 extended deny ip any 10.45.15.192 0.0.0.15 access-list acl1 extended deny ip any 10.45.15.192 0.0.9.0
Workaround: Manually unconfigure the objects (such as access-lists) that have an inconsistent netmask and then reconfigure them with consistent netmasks. •
CSCto45906—Each time that the standby ACE reboots, a context on it transitions to the STANDBY_COLD state and the ACE displays the following error: Error on Standby device when applying configuration file
Release Note for the Cisco ACE Application Control Engine Module
54
OL-26643-01
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
It is a timing issue due to the configuration size and total number of contexts. This issue can lead to a lot of Configuration Manager (CFGMGR) download processing which can lead to a command failure. CSCtn50357 is tracking the issue of the actual failing command that is not properly placed in the error logs. Workaround: Perform either of the following: – On the FT group for the context in the STANDBY_COLD state, enter the no inservice
command followed by the inservice command. – Change the context FT group ID in the FT group to a higher number so that the context with the
largest configuration does the configuration synchronization last. •
CSCto54476—When an SSL certificate or key is in use on the ACE, you can delete it. Workaround: Before removing the certificate or key, manually verify whether it is being referenced in the configuration.
•
CSCto58886—When the ACE detects a bad DRAM component on the NP, it does not generate syslogs due to the corruption caused by the bad hardware. Workaround: None.
•
CSCto65011—When you configure SUP SVI as the gateway to the ACE module, the client fails to reach the ACE module. Workaround: Configure the gateway farther from the switch and use SUP as the L2 device.
•
CSCto77306—The following warning message is displayed when MTS messages to a command shell are processed (while executing an user command). Warning:- MTS queue is full for opcode %d sap %d pid %d clear idle debug plugin sessions or telnet/ssh connections to recover"
Workaround: Close all the debug plugin sessions and terminate command execution in all telnet/ssh connections to prevent these warning messages. •
CSCto91249—When you enter the show parameter-map command to list all of the parameter maps in the context and the first parameter map in the list is a connection type, the ACE does not display all of the parameter maps. Workaround: None.
•
CSCtq32935 —When you configure an ACE with multiple classes (maximum of three classes) under the same policy-map type load balance, the source addresses of the subnets in these classes do not match. The ACE load balancing process fails and the subnet with the highest class map is considered. Workaround: When you configure multiple classes, the source address for all subnets should be same as the address defined in first class.
•
CSCtq59860—When you configure an SNMP engine ID that is applied to both the active and standby ACE using the CLI command snmp-server engineid , the Network Management Station (NMS) does not know which ACE to connect to. Workaround: Use the following CLI command snmp-server engineid per engineid .
•
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
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
55
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
•
CSCtq63912—SNMP traps are not sent when the SNMP trap queue is full. When this situation occurs, the ACE displays the following error messages: snmpd[1027]: (ctx:9)send_notification: new: enqueueing notification........ snmpd[1027]: (ctx:9)ERROR: notif_enqueue_tail : Size of the notif queue is more than the MAX size 250
Software version A4(2.3) increased the queue size from 250 to 2000 and added new a counter in the show snmp command output to print the number of traps dropped because of a full SNMP queue. Workaround: None. •
CSCtr36240—With the ACE configured for end-to-end SSL, if the backend server sends its full encrypted payload to the ACE, followed by an SSL close notify and a TCP RST, the ACE forwards the full payload to the client but then forwards the TCP RST to the client without sending an SSL close notify. Workaround: None.
Note
This issue can also occur with nonencrypted servers sending a RST.
•
CSCtr40282—Under normal operation with regexp resources in use, the clear stats resource-usage command may fail to clear the regexp peak counter. Workaround: Reload the ACE.
•
CSCtr44960—The HTTP response header for a CRL download fails if the server sets 'Content-length' instead of 'Content-Length' (lower-case "l" instead of an uppercase "L). When this happens, the ACE fails in downloading the CRL file and returns the following error: %ACE-6-253008: CRL My_CRL could not be retrieved, reason: invalid format of data
Workaround: None. •
CSCtr66995—When you configure real servers in server farms and run a checkpoint rollback for couple of times, ACE reloads due to insufficient memory. Workaround: None.
•
CSCtr69215—When the ACE is servicing a high volume of traffic, has sticky configured, and the show tech command is executed continuously on the control plane, the ACE may become unresponsive. Workaround: None.
•
CSCtr77030—With Network Address Translation (NAT) and Port Address Translation (PAT) configured in the ACE, the ACE may become unresponsive and reload. When this behavior occurs, network processor files indicate a duplicate buffer release in the transmit module. Workaround: Configure NAT and PAT in separate pools of global source addresses.
•
CSCtr93395—When UDP Booster is enabled on the ACE to load balance DNS traffic, the source IP address does not appear in the show conn command output. CSCtr93395—When UDP Booster is enabled on the ACE to load balance DNS traffic, the source IP address does not appear in the show conn command output. host1/Admin# show conn conn-id np dir proto vlan source destination state ----------+--+---+-----+----+---------------------+---------------------+----101646 1 in UDP 302 0.0.38.114:0 80.58.61.250:53 -
Workaround: None. •
CSCts07333—During a configuration change on the ACE, the ACE reloaded because the cfgmgr becomes unresponsive. This behavior could be due to a memory corruption problem. Workaround: None.
•
CSCts09006—Under normal operations with SNMP, the ACE unexpectedly reloads and generates a core file. Workaround: None.
Release Note for the Cisco ACE Application Control Engine Module
56
OL-26643-01
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
•
CSCts24977—The service name:snmpd(1395) terminates upon receiving signal 8. This issue can occur when polling the ACE CPU utility MIB in a loop; the snmpd process can become unresponsive and cause the ACE to reload. For this particular issue, the OID polled was .1.3.6.1.4.1.9.9.480.1.1.7.1. Workaround: Do not poll the ACE CPU utility MIB continuously in a loop.
•
CSCts29208—With one or more sticky groups and failaction reassign configured under one of the server farms, the ACE may experience the load balance issue while incrementing real server connection counts. Workaround: When this behavior occurs, do not configure the failaction reassign command with the server farm.
•
CSCts35635—A denial of service vulnerability has been found in the way the multiple overlapping ranges are handled by the Apache HTTPD server. Multiple Cisco products could be affected by this vulnerability. Mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this Advisory: http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=24024 This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110830-apache.shtml. PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 7.8/7.8: https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&ve ctor=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:H/RL:U/RC:C CVE ID CVE-2011-3192 has been assigned to document this issue. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
•
CSCts43521—The ACE requires measures to mitigate the effect of CVE-2004-0230. Part of the measures are already in place; however this bug tracks the implementation of the full set. Workaround: None. PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5.0/4.3: https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&ve ctor=AV:N/AC:L/Au:S/C:P/I:N/A:N/E:F/RL:OF/RC:C CVE ID CVE-2004-0230 has been assigned to document this issue. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
•
CSCts44219—The ACE is configured with access control lists (ACLs) which reference object groups. The ACL is part of a policy which is applied globally or to an interface. When dynamic changes are made to the ACL or object group, the following ACL merge error may occur: "%ACE-1-106028: WARNING: ACL Merge failed to add ACE..." and this leave the service policy incomplete and can cause traffic to be mis-handled.
Workaround: Perform one of the following actions: – Delete the ACL which logged the merge error, reconfigure the policy, and reapply. – Reboot the ACE.
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
57
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
•
CSCts50072—When running an ACE module for over 100 days under normal conditions but with a large configuration, the ACE warns of low memory. Workaround: Reduce the size of the configuration. Reboot the ACE when the memory falls below one percent.
•
CSCts66857—When you enter the no command with the full match statement, or without the line number for "match anyv6", or vice versa as shown in the following example, no 2 match anyv6 no 3 match port- v6 tcp range 6 600 no 2 match any
You cannot apply the "match port tcp/udp…." after removing the "match anyv6" config from the L3/4n/w traffic class map. The following error message is displayed: Class contains Ipv6 match statement
Workaround: Use the no command with the line number only. •
CSCts99950—With backend SSL configured on the ACE, the ACE may become unresponsive and generate a core file. Workaround: None.
•
CSCtt08380—After experiencing packet loss, the ACE inconsistently sends ACKs. This behavior is due to the length of reassembly queue in TCP (32 buffer particle). With software version A4(2.3), this length has been tied to the size of rcv-wnd (typically 64 buffer particle). Workaround: None.
•
CSCtt08473—In an Admin context configuration with a big banner, the config sync between the Active and Standby ACE fails with the Standby ACE stuck in the STANDBY_CONFIG state. After four hours, the HA config sync times out, and the Standby ACE changes to the STANDBY_COLD state. The show proc cpu command displays the config_cntlr process with more than 50% of CPU utilization. Workaround: Remove the banner from the running and startup config of the context.
•
CSCtt24046—When the ACE performs multiple simultaneous SNMP requests on the cpmProcessTable, this may result in an SNMP timeout. Workaround: Perform only sequential SNMP requests on the Cisco Process MIB.
•
CSCtt30579—When you use the show cfgmgr internal table slb-policy command, the output incorrectly displays all the entries as invalid. Workaround: None.
•
CSCtt33804—During a modification of an ACL within a context, an ACL merge error may be reported on one or more of the interfaces where the ACL list is applied, leaving the interface in an inconsistent state. When this issue occurs, the following system message appears: %ACE-1-106028: WARNING: ACL Merge failed to locate specified ACL in context 10049. Error while processing service-policy. Incomplete rule is currently applied on interface vlan200. Configuration on this interface needs to be manually reverted
Workaround: Perform one of the following actions: – Remove the offending lines one at a time from the ACL until the ACL can be successfully
applied. – Reload the ACE. •
CSCtt61028—When operating in a redundant configuration, SSL probes fail intermittently even if the ACE module is in standby mode. Workaround: Reload the ACE.
•
CSCtt76277—In n 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
Release Note for the Cisco ACE Application Control Engine Module
58
OL-26643-01
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
Note
When the fix is out, be sure to delete the file with the del disk0:skip_reset_cde_hash_table command.
– Configure an input ACL on the ACE VLAN interfaces to deny multicast traffic. For example,
enter: access-list deny_mcast line 10 extended deny ip any 224.0.0.0 240.0.0.0 access-list deny_mcast line 20 extended permit icmp any any access-list deny_mcast line 30 extended permit ip any any
•
CSCtu10624—Establishing a Telnet connection from the ACE to a remote device is silent with no indication of a successful connection or DNS resolution. When this occurs, the lines "trying ..." and "connected..." are not seen. Workaround: None.
•
CSCtu18281—The restore process may fail if the Admin context in the backup configuration has TACACS authorization and the configuration is associated with a domain (add-object command). When this issue occurs, the restore process fails and the non-Admin contexts are not imported. However, for the Admin context, the configurations are properly applied. Workaround: Remove "domain TACACS" from the backup configuration and perform the restore.
•
CSCtu33484—When setting the idle timeout on the ACE, an extra second is added for every minute of idle time. When this issue occurs, the connection disappears from the statistics on the configured time. The reset is not sent until the idle time plus the extra time expires. Workaround: None.
•
CSCtu34037— User context configurations (including certificates and keys) are lost after the ACE reloads. When this issue occurs, the Admin context configuration is reduced to the minimal, initial configuration. This issue can occur when you specify the reload command, or if the FT link is interrupted by high CPU usage on the switch that the ACE is connected to. Workaround: None.
•
CSCtu36146—The ACE becomes unresponsive due to a configuration manager (Cfgmgr) process failure with the last boot reason: Service "cfgmgr." The following example system error log messages may appear shortly before the ACE reloads: MG6509:7:Admin 443001 Critical 24-Oct-2011 08:29:09 System experienced fatal failure.Service name:cfgmgr(1050) has terminated on receiving signal 11,system will not be reloaded MG6509:7:Admin 443001 Critical 24-Oct-2011 08:30:23 System experienced fatal failure.Service name:cfgmgr(1050) crashed, last core saved,system will not be reloaded MG6509:7:Admin 199006 Critical 24-Oct-2011 08:30:31 Orderly reload started at Mon Oct 24 13:30:28 2011 by System. Reload reason: Service "cfgmgr"
Workaround: None. •
CSCtv17196—The show script code command returns an invalid call. Workaround: Reboot the ACE.
•
CSCtw54107—The ACE requires the ability to display the hidden parameter of a server farm when using the show cfgmgr internal table sfarm det command
•
CSCtw70949—Currently, the ucdump -w a debugging command does not show the allocated buffers. This debugging command display incorrect output. Workaround: None.
•
CSCtw76940—You may find that double quotations in a description are replaced by spaces. For example, if you configure description t"e"st, this description is displayed as (config-sticky- in the show running configuration command output as follows: (config-if)# description t"e"st (config-if)# do sh run | i desc Generating configuration.... description t e st
Release Note for the Cisco ACE Application Control Engine Module OL-26643-01
59
Software Version A5(2.0) Resolved Caveats, Open Caveats, Command Changes, and System Log Messages
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 Load average: Processes : CPU states : Memory usage:
system resources 1 minute: 0.10 5 minutes: 0.05 15 minutes: 0.01 5606 total, 1 running nan% user, nan% kernel, nan% idle