Table Of Contents
Release Note for the Cisco 4700 Series Application Control Engine Appliance
Contents
New Software Features in A1(8.0)
New Performance Throughput and HTTP Compression Licenses
Configuring KAL-AP
Enabling KAL-AP on the ACE
Configuring a KAL-AP VIP Address
Configuring KAL-AP TAGs as Domains
Configuring Secure KAL-AP
Displaying Global-Server Load-Balancing Load Information
Displaying Global-Server Load-Balancing Statistics
Autogenerating a MAC Address for a VLAN Interface
Enabling Source MAC Validation
Changes to the Packet Capture Utility
Bandwidth Reservation for Management Traffic
Setting the Maximum Receive or Transmit Buffer Share
Configuring the Rate Limit for Gratuitous ARP Packets
Configuring a Bank of MAC Addresses for Shared VLANs
Source NAT Using a VIP
Configuring the ACE to Reply to a Ping to a VIP only if the Primary Server Farm is in Service
New Redundancy State for Software Upgrade or Downgrade
Modifications to the Cisco CSS-to-ACE Conversion Tool
Modifications to the Setup Script
Software Feature Changes in A1(8.0)
Available ACE Licenses
Ordering an Upgrade License and Generating a Key
Upgrading Your ACE Software from A1(7x) to A1(8.0x) in a Redundant Configuration
Before You Begin
Changing the Admin Password
Changing the www User Password
Checking Your Configuration for FT Priority and Preempt
Upgrade Procedure
Downgrading Your ACE Software from Version A1(8.0x) to A1(7x) in a Redundant Configuration
Before You Begin
Downgrade Procedure
Supported Browsers for ACE Appliance Device Manager
ACE Operating Considerations
Verifying the ACE Appliance Hardware Revision
Using Dynamic ETag and HTTP Compression
Using Application Acceleration FlashForward With IP Address Stickiness
ACE Documentation Set
Software Version A1(8.0a) Resolved Caveats
Software Version A1(8.0) Resolved Caveats, Open Caveats, and Command Changes
Software Version A1(8.0) Resolved Caveats
Software Version A1(8.0) Open Caveats
Software Version A1(8.0) Command Changes
Software Version A1(7b) Resolved and Open Caveats
Software Version A1(7b) Resolved Caveats
Software Version A1(7b) Open Caveats
Software Version A1(7a) Resolved and Open Caveats
Software Version A1(7a) Resolved Caveat
Software Version A1(7a) Open Caveats
Software Version A1(7) Open Caveats
Obtaining Documentation and Submitting a Service Request
Release Note for the Cisco 4700 Series Application Control Engine Appliance
June 9, 2008
Note 
The most current Cisco documentation for released products is also available on Cisco.com.
Contents
This release note applies to the following software versions for the Cisco 4700 Series Application Control Engine (ACE) appliance:
•A1(8.0a)
•A1(8.0)
•A1(7b)
•A1(7a)
•A1(7)
For information on the ACE appliance features and configuration details, see the ACE documentation located on www.cisco.com at:
http://www.cisco.com/en/US/products/ps7027/tsd_products_support_series_home.html
This release note contains the following sections:
•New Software Features in A1(8.0)
•Software Feature Changes in A1(8.0)
•Available ACE Licenses
•Ordering an Upgrade License and Generating a Key
•Upgrading Your ACE Software from A1(7x) to A1(8.0x) in a Redundant Configuration
•Downgrading Your ACE Software from Version A1(8.0x) to A1(7x) in a Redundant Configuration
•Supported Browsers for ACE Appliance Device Manager
•ACE Operating Considerations
•ACE Documentation Set
•Software Version A1(8.0a) Resolved Caveats
•Software Version A1(8.0) Resolved Caveats, Open Caveats, and Command Changes
•Software Version A1(7b) Resolved and Open Caveats
•Software Version A1(7a) Resolved and Open Caveats
•Software Version A1(7) Open Caveats
•Obtaining Documentation and Submitting a Service Request
New Software Features in A1(8.0)
This section describes the new features in ACE software version A1(8.0). It contains the following topics:
•New Performance Throughput and HTTP Compression Licenses
•Configuring KAL-AP
•Autogenerating a MAC Address for a VLAN Interface
•Enabling Source MAC Validation
•Changes to the Packet Capture Utility
•Bandwidth Reservation for Management Traffic
•Setting the Maximum Receive or Transmit Buffer Share
•Configuring the Rate Limit for Gratuitous ARP Packets
•Configuring a Bank of MAC Addresses for Shared VLANs
•Source NAT Using a VIP
•Configuring the ACE to Reply to a Ping to a VIP only if the Primary Server Farm is in Service
•New Redundancy State for Software Upgrade or Downgrade
•Modifications to the Cisco CSS-to-ACE Conversion Tool
•Modifications to the Setup Script
For details on these software features as implemented in the Device Manager GUI, see the Online Help system provided with the GUI.
Note For a list of the commands and options that have been modified in software version A1(8.0), see the "Software Version A1(8.0) Command Changes" section.
New Performance Throughput and HTTP Compression Licenses
With the release of A1(8.0), the following new performance throughput and HTTP compression licenses are now available:
•ACE-AP-04-LIC: 4-Gbps performance throughput license
•ACE-AP-04-UP2: Upgrade from 2-Gbps to 4-Gbps performance throughput license
•ACE-AP-C-2000-LIC: 2-Gbps HTTP compression license
•ACE-AP-C-2000-LIC=: 2-Gbps HTTP compression license spare
•ACE-AP-C-UP3=: Upgrade from 1-Gbps to 2-Gbps HTTP compression license
See the "Available ACE Licenses" section for details.
Configuring KAL-AP
A keepalive-appliance protocol (KAL-AP) on the ACE allows communication between the ACE and the Global Site Selector (GSS) by sending KAL-AP requests to report the server states and loads for global-server load-balancing (GSLB) decisions. The ACE uses KAL-AP through a UDP connection to calculate weights and provide information for server availability to the KAL-AP device. The ACE acts as a server and listens for KAL-AP requests. When KAL-AP is initialized on the ACE, the ACE listens on the standard 5002 port for any KAL-AP requests. You cannot configure any other port.
The ACE supports VIP-based and TAG-based KAL-AP probes. For a VIP-based KAL-AP, when the ACE receives a kal-ap-by-vip request, it verifies whether the VIP addresses are active in all Layer 3 class maps that are configured with the addresses. The ACE ignores all other protocol-specific information for the VIP addresses. For each Layer 3 class map, the ACE locates the associated Layer 7 policies and associated real servers in server farms. The ACE determines the total number of servers associated with these VIPs and those servers in the Operational state.
The ACE calculates a load number from 0 to 255 and reports the server load of the VIP to the KAL-AP device. The load values are indicators of VIP and server availability. A load value of 0 indicates that the VIP address is not available. This value is also sent in the case of any VIP lookup failures. A load value of 1 is reserved to indicate that the VIP is offline and not available for use. Valid load values are from 2 to 255. A load value of 2 indicates that the VIP is least loaded (most of the servers are available and all servers are up) and a load value of 255 indicates that the VIP is fully loaded (none of the servers are available at the moment). For example, if the total number of servers is 10 and only 5 are operational, the load value is 127, which means that half of the servers are available.
Note If the same real server is associated with more than one server farm, the ACE includes it twice in the load calculation.
You can configure a TAG-based KAL-AP domain associated with a VIP address that corresponds to a TAG in the ACE. When the ACE receives a kal-ap-by-tag request, the process is similar to VIP-based KAL-AP probes. The load calculation considers the Layer 3 class map, server farm, and real server objects. All other objects under the domain are ignored during the load calculation. The calculation for the domain is similar to a VIP address. However, the only difference is that the real server objects and server farm objects are considered in the calculation. The ACE gathers the server availability information for any Layer 3 VIP addresses within the domain. The ACE considers all of the server farms associated with the domain. If the real servers are in a domain, the ACE adds them to the current total and then performs a division to determine their availability as TAG objects. The ACE reports this final number in the KAL-AP response.
This section contains the following topics:
•Enabling KAL-AP on the ACE
•Configuring a KAL-AP VIP Address
•Configuring KAL-AP TAGs as Domains
•Configuring Secure KAL-AP
•Displaying Global-Server Load-Balancing Load Information
•Displaying Global-Server Load-Balancing Statistics
Enabling KAL-AP on the ACE
To enable KAL-AP on the ACE, you must configure a management class map and policy map, and apply it to the appropriate interface. The KAL-AP server listens on the standard 5002 port to all KAL-AP requests.
You can configure the class map for KAL-AP over a UDP management access connection by using the match protocol kalap-udp command in the class map management configuration mode. The syntax of this command is as follows:
match protocol kalap-udp any | [source-address ip_address subnet_mask]
The keywords and arguments are as follows:
•any—Specifies any client source address for the management traffic classification.
•source-address—Specifies a client source host IP address and subnet mask as the network traffic matching criteria. As part of the classification, the ACE implicitly obtains the destination IP address from the interface on which you apply the policy map.
•ip_address—Source IP address of the client. Enter the IP address in dotted-decimal notation (for example, 192.168.11.1).
•mask—Subnet mask of the client entry in dotted-decimal notation (for example, 255.255.255.0).
For example, to specify a KAL-AP class map from any source IP address, enter:
host1/Admin(config)# class-map type management KALAP-CM
host1/Admin(config-cmap-mgmt)# match protocol kalap-udp any
host1/Admin(config-cmap-mgmt)# exit
To remove the class map, enter:
host1/Admin(config-cmap-mgmt)# no match protocol kalap-udp source-address any
After you create the KAL-AP class map, create a KAL-AP management policy map and apply the class map to it. To create the policy map and access policy map management configuration mode, use the policy-map type management command in configuration mode. For example, to create the KALAP-MGMT management policy map and apply the KALAP-CM class map to it, enter:
host1/Admin(config)# policy-map type management KALAP-MGMT
host1/Admin(config-pmap-mgmt)# class KALAP-CM
host1/Admin(config-cmap-mgmt)# permit
host1/Admin(config-cmap-mgmt)# exit
To apply the policy map to an interface, use the interface vlan command in configuration mode. For example, to apply the KALAP-MGMT policy map to VLAN interface 10, enter:
host1/Admin(config)# interface vlan 10
host1/Admin(config-if)# ip address 10.1.0.1 255.255.255.0
host1/Admin(config-if)# service-policy input KALAP-MGMT
host1/Admin(config-if)# no shutdown
host1/Admin(config-if)# exit
Note When you modify or remove a KAL-AP policy, you must clear the existing KAL-AP connections manually.
Configuring a KAL-AP VIP Address
You can configure VIP-based KAL-AP by configuring a Layer 3/4 class map that contains a VIP address match statement. You can define a 3-tuple flow of VIP address, protocol, and port as matching criteria by using the match virtual-address command in class map configuration mode. You can configure multiple match criteria statements to define the VIPs for SLB. The syntax of this command is as follows:
[line_number] match virtual-address vip_address {[mask] | any | {tcp | udp {any | eq
port_number | range port1 port2}} | protocol_number}
For information on the keywords and arguments, see the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
Note For KAL-AP, the ACE verifies whether the VIP addresses are active in all Layer 3 class maps that are configured with the addresses. It ignores all other protocol-specific information for the VIP addresses.
For example, to create a class map VIP-20 that matches traffic destined to VIP address 10.10.10.10 with a wildcard value for the IP protocol value (TCP or UDP), enter:
host1/Admin(config)# class-map VIP-20
host1/Admin(config-cmap)# match virtual-address 10.10.10.10 any
To remove the VIP match statement from the class map, enter:
host1/Admin(config-cmap)# no match virtual-address 10.10.10.10 any
Configuring KAL-AP TAGs as Domains
You can configure KAL-AP TAGs as domains by using the domain command in configuration mode. The syntax of this command is as follows:
domain name
The name is the name of the KAL-AP TAG.
Note For the domain load calculation, the ACE considers the Layer 3 class map, server farm, and real server objects. All other objects under the domain are ignored during the calculation.
For example, to configure KAL-AP-TAG1 as a domain, enter:
host1/Admin(config)# domain KAL-AP-TAG1
After you create the domain, use the add-object class-map command in domain configuration mode to add each class map that you want to associate with the TAG domain. For example, to add the VIP-20 and VIP-71 class maps to the TAG domain, enter:
host1/Admin(config-domain)# add-object class-map VIP-20
host1/Admin(config-domain)# add-object class-map VIP-71
To remove the domain, enter:
host1/Admin(config)# no domain KAL-AP-TAG1
For more information about configuring class maps, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide. For more information about configuring domains, see the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide.
Configuring Secure KAL-AP
The ACE supports secure KAL-AP for MD5 encryption of data between it and the GSS. For encryption, you must configure a shared secret as a key for authentication between the GSS and the ACE context.
To configure secure KAL-AP on the ACE, access KAL-AP UDP configuration mode through the kalap udp command in configuration mode. The syntax of this command is as follows:
kalap udp
For example, enter:
host1/Admin(config)# kalap udp
host1/Admin(config-kalap-udp)#
To remove the KAL-AP configuration and all VIP entries, enter the following command:
host1/Admin(config)# no kalap udp
In this mode, you enable secure KAL-AP by configuring the VIP address to the GSS and the shared secret through the ip address command. The syntax of this command is as follows:
ip address ip_address encryption md5 secret
The keywords and arguments are as follows:
•ip_address—The VIP address for the GSS. Enter the IP address in dotted-decimal notation (for example, 192.168.11.1).
•encryption—Specifies the encryption method.
•md5—Specifies the MD5 encryption method.
•secret—Shared secret between the KAL-AP device and the ACE. Enter the shared secret as a case-sensitive string with no spaces and a maximum of 31 alphanumeric characters.
For example, to enable secure KAL-AP and configure the VIP address for the GSS and shared secret, enter:
host1/Admin(config-kalap-udp)# ip address 10.1.0.1 encryption md5 andromeda
To disable secure KAL-AP, use the no form of the ip address command. For example, enter:
host1/Admin(config-kalap-udp)# no ip address 10.1.0.1
Displaying Global-Server Load-Balancing Load Information
You can display the latest load information for a VIP address or domain name provided to the KAL-AP request by using the show kalap udp load command in Exec mode. The syntax of the command is as follows:
show kalap udp load {vip ip_address} | {domain name}
The keywords and arguments are as follows:
•vip ip_address—Displays the latest load information for the specified VIP address. Enter the IP address in dotted-decimal notation (for example, 192.168.11.1).
•domain name—Displays the latest load information for the specified domain name.
The output fields for the show kalap udp load command display the VIP address or domain name, its load value, and the time stamp.
For example, to display the latest load information to the KAL-AP request for VIP address 10.10.10.10, enter:
host1/Admin# show kalap udp load vip 10.10.10.10
To display the latest load information to the KAL-AP request for domain KAL-AP-TAG1, enter:
host1/Admin# show kalap udp load domain KAL-AP-TAG1
Displaying Global-Server Load-Balancing Statistics
You can display the global-server load-balancing statistics per context by using the show stats kalap command in Exec mode. The syntax of the command is as follows:
show stats kalap
For example, enter:
host1/Admin# show stats kalap
Table 1-1 lists the output fields displayed by this command.
Table 1-1 Field Descriptions for the show stats kalap Command
Field
|
Description
|
Total bytes received
|
Total number of bytes received.
|
Total bytes sent
|
Total number of bytes sent.
|
Total requests received
|
Total number of requests received.
|
Total responses sent
|
Total number of responses sent.
|
Total requests successfully received
|
Total number of requests successfully received.
|
Total responses successfully sent
|
Total number of responses successfully sent.
|
Total secure requests received
|
Total number of secure requests received.
|
Total secure responses sent
|
Total number of secure responses sent.
|
Total requests with errors
|
Total number of requests with errors.
|
Total requests with parse errors
|
Total number of requests with parse errors.
|
Total response transfer errors
|
Total number of response transfer errors.
|
Autogenerating a MAC Address for a VLAN Interface
By default, the ACE does not allow traffic from one context to another context over a transparent firewall. The ACE assumes that VLANs in different contexts are in different Layer 2 domains, unless it is a shared VLAN. The ACE allocates the same MAC address to each context interface using a shared VLAN.
When you are using a firewall service module (FWSM) to bridge traffic between two contexts on the ACE, you must assign two Layer 3 VLANs to the same bridge domain. To support this configuration, these VLAN interfaces require different MAC addresses.
To enable the autogeneration of a MAC address on a VLAN interface, use the mac address autogenerate command in interface configuration mode. The syntax of this command is as follows:
mac address autogenerate
For example, enter:
host1/Admin(config-if)# mac address autogenerate
To disable MAC address autogeneration on the VLAN, use the no mac address autogenerate command. For example, enter:
host1/Admin(config-if)# no mac address autogenerate
Note When you use the mac address autogenerate command, the ACE assigns a MAC address from the bank of MAC addresses for shared VLANs. If you use the no mac address autogenerate command, the interface retains this address. To revert to a MAC address for an unshared VLAN, you must delete the interface and then add the interface again.
Enabling Source MAC Validation
Source MAC validation allows you to instruct the ACE to check the source MAC address in an Ethernet header against the sender's MAC address in an ARP payload for every ARP packet received by the ACE on the specified interface. The ACE does not learn or update the ARP or MAC tables for packets with different MAC addresses. By default, source MAC validation is disabled.
Note If ARP inspection fails, then the ACE does not perform source MAC validation. For details about ARP inspection, see the Cisco 4700 Series Application Control Engine Appliance Routing and Bridging Configuration Guide.
To configure source MAC validation, use the arp inspection command in interface configuration mode. The syntax of this command is as follows:
arp inspection validate src-mac [flood | no-flood]
The options are as follows:
•flood—Enables ARP forwarding for the interface and forwards ARP packets with nonmatching source MAC addresses to all interfaces in the bridge group. This is the default option when you enable source MAC validation.
•no-flood—Disables ARP forwarding for the interface and drops ARP packets with nonmatching source MAC addresses.
Note Regardless of whether you enter the flood or the no-flood option, if the source MAC address of the ARP packet does not match the MAC address of the Ethernet header, then the source MAC validation fails and the ACE increments the Smac-validation Failed counter of the show arp statistics command.
For example, to enable source MAC validation and instruct the ACE to drop ARP packets with nonmatching source MAC addresses, enter:
host1/Admin(config-if)# arp inspection validate src-mac no-flood
To disable source MAC validation, enter:
host1/Admin(config-if)# no arp inspection validate src-mac no-flood
Changes to the Packet Capture Utility
Now when you start the packet capture function using the start keyword and the ACE displays the messages on the session console as it receives the packets, the CLI prompt returns and you can type other commands at the same time that the ACE is capturing packets. To stop the capture process, enter stop. The packet capture function automatically stops when the buffer is full unless you enable the circular buffer function.
Note Under high traffic conditions, you may observe up to 64 packets printing on the console after you enter the stop keyword. These additional messages can occur because the packets were in transit or buffered before you entered the stop keyword.
If you delete an interface that is in use by the packet capture function, the ACE stops the capture automatically. If you check the status of the packet capture using the show capture buffer_name status command, you will notice that the capture stopped because of an interface deletion. At this point, you can perform any operation (for example, saving the old capture) on the capture except starting the capture. To restart the capture, you must delete the old capture and configure a new one. The ACE handles the deletion of an ACL or an ACL entry in a similar manner.
If you add an interface while you are already capturing all interfaces, the capture continues using all the original interfaces. If you add an ACL entry during an existing ACL capture, the capture continues normally using the original ACL criteria.
Note If you enable packet capture for jumbo packets, the ACE captures only the first 1,860 bytes of data.
For details about running the packet capture utility, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Bandwidth Reservation for Management Traffic
The bandwidth keyword of the limit-resource command limits total ACE throughput in bytes per second for one or more contexts. The maximum bandwidth rate per context is determined by your bandwidth license. By default, the entry-level ACE has a 1-Gbps through-traffic bandwidth and a 1-Gbps management-traffic bandwidth for a total maximum bandwidth of 2 Gbps. With the 2-Gbps license, the ACE has a 2-Gbps through-traffic bandwidth and a 1-Gbps management-traffic bandwidth for a total maximum bandwidth of 3 Gbps.
You can upgrade the ACE with either an optional 2-Gbps or 4-Gbps bandwidth license (see the "Available ACE Licenses" section).
The syntax of this command is as follows:
limit-resource rate {bandwidth | mgmt-traffic {minimum number} {maximum {equal-to-min |
unlimited}}
When you configure a minimum bandwidth value for a resource class in the ACE, the ACE subtracts that configured value from the total bandwidth maximum value of all contexts in the ACE, regardless of the resource class with which they are associated. The total bandwidth rate of a context consists of the following two components:
•throughput—Limits through-the-ACE traffic. This is a derived value (you cannot configure it directly) and it is equal to the bandwidth rate minus the mgmt-traffic rate for the 1-Gbps and 2-Gbps licenses.
•mgmt-traffic—Limits management (to-the-ACE) traffic in bytes per second. This parameter is independent of the limit-resource all minimum command. To guarantee a minimum amount of management traffic bandwidth, you must explicitly allocate a minimum percentage of resources to management traffic using the limit-resource rate mgmt-traffic minimum command. When you allocate a minimum percentage of bandwidth to management traffic, the ACE subtracts that value from the maximum available management traffic bandwidth for all contexts in the ACE. By default, management traffic is guaranteed a minimum bandwidth rate of 0 and a maximum bandwidth rate of 1 Gbps, regardless of the bandwidth license that you install in the ACE.
In addition, with the A1(8.0) release, the managed system resources of the ACE for management connections through the limit-resource rate mgmt-connections maximum command has been increased to 100,000 connections (from 5000 connections).
For details about how the ACE manages bandwidth for throughput and management traffic rates, see the examples of the show resource-usage command output that follow. For each bandwidth license, examples are shown for the default values, 25 percent minimum allocation to all resources, and both a 25 percent minimum allocation to all resources and a 10 percent minimum allocation to management traffic. The output has been modified to show only the relevant fields.
Note All values are in bytes per second; to convert to bits per second, multiply each value by 8.
switch/Admin# show resource usage
Example 1-1 Default Show Resource Usage Command Output for 1-Gbps License
Example 1-2 Show Resource Usage Command Output for 1-Gbps License with 25 Percent Minimum Allocation for All Resources
Example 1-3 Show Resource Usage Command Output for 1-Gbps License with 25 Percent Minimum Allocation for All Resources and 10 Percent Minimum Allocation for Management Traffic
Example 1-4 Default Show Resource Usage Command Output for 2-Gbps License
Example 1-5 Show Resource Usage Command Output for 2-Gbps License with 25 Percent Minimum Allocation for All Resources
Example 1-6 Show Resource Usage Command Output for 2-Gbps License with 25 Percent Minimum Allocation for All Resources and 10 Percent Minimum Allocation for Management Traffic
Example 1-7 Default Show Resource Usage Command Output for 4-Gbps License
Example 1-8 Show Resource Usage Command Output for 4-Gbps License with 25 Percent Minimum Allocation for All Resources (continued)
Example 1-9 Show Resource Usage Command Output for 4-Gbps License with 25 Percent Minimum Allocation for All Resources and 10 Percent Minimum Allocation for Management Traffic
The minimum keyword specifies the lowest acceptable value for a resource. Enter an integer from 0.00 to 100.00 percent (two-decimal places of granularity). The number argument specifies a percentage value for all contexts that are members of the resource class. When used with the rate keyword, the number argument specifies a value per second. When you configure a minimum value for a resource in a particular resource class in the ACE, the ACE assigns the minimum resources only to the contexts that are members of the resource class. For all contexts, the ACE subtracts that configured minimum value from the maximum value of that resource, regardless of the resource class with which the contexts are associated. If the resource class has more than one context associated with it, the minimum value that the ACE subtracts from the maximum value is multiplied by the number of contexts in the resource class.
For example, with a 4-Gbps bandwidth license, if there are two contexts associated with the resource class and you configure a 25 percent minimum allocation for the bandwidth rate for the class, each context in the resource class would have the values that are shown in Example 1-10 for the show resource usage command output for the bandwidth rate and throughput rate.
Example 1-10 Show Resource Usage Command Output for 4-Gbps License with 25 Percent Minimum Allocation for Bandwidth
All other contexts in the ACE would have the same maximum values as shown in Example 1-10, but would have zero minimum values. Compare the values in Example 1-10 with the values in Example 1-5, which represents one context in a resource class.
Setting the Maximum Receive or Transmit Buffer Share
To improve throughput and overall performance, the ACE checks the number of buffered bytes on a TCP connection against the configured buffer setting before accepting new receive or transmit data. By default, the maximum size of the receive or transmit buffer for each TCP connection is 32768 bytes. For large bandwidth and delay network connections, you may want to increase the default buffer size to improve your network performance. To set the maximum receive or transmit buffer size for each TCP connection, use the set tcp buffer-share command in parameter map connection configuration mode. The syntax of this command is as follows:
set tcp buffer-share number
The number argument is the maximum size of the receive or transmit buffer in bytes for each TCP connection. Enter an integer from 8192 to 262143 bytes. The default is 32768 bytes.
Caution If you are using the ACE to terminate SSL traffic, do not decrease the buffer share value below the default value of 32 KB. With a buffer share value of less than 32 KB, SSL connections are significantly slower.
For example, enter:
host1/C1(config-parammap-conn)# set tcp buffer-share 16384
To reset the buffer limit to the default value of 32768 bytes, enter:
host1/C1(config-parammap-conn)# no set tcp buffer-share
Configuring the Rate Limit for Gratuitous ARP Packets
By default, the rate limit for gratuitous ARPs sent by the ACE is 512 packets per second. To configure this rate limit, use the arp ratelimit command in configuration mode. This command is available only in the Admin context. This rate limit applies to the module and not per context.
The syntax of this command is as follows:
arp ratelimit number
The number argument defines the rate limit as packets per second. Enter an integer from 100 to 8192. The default is 512.
Note The rate limit applies to all gratuitous ARPs sent for local addresses on new configurations, module reboot, and on MAC address changes.
For example, to specify a rate limit of 1000 packets per second, enter:
host1/Admin(config)# arp ratelimit 1000
To restore the default value of 512 packets per second, use the no arp ratelimit command. For example, enter:
host1/Admin(config)# no arp ratelimit
Configuring a Bank of MAC Addresses for Shared VLANs
When contexts share a VLAN, the ACE assigns a different MAC address to the VLAN on each context. The MAC addresses reserved for shared VLANs are 0x001243dc6b00 to 0x001243dcaaff, inclusive. All ACE appliances derive these addresses from a global pool of 16,000 MAC addresses. This pool is divided into 16 banks, each containing 1024 addresses. Each subnet can have a maximum of 16 ACEs.
Each ACE supports 1024 shared VLANs, and uses only one bank of MAC addresses out of the pool. A shared MAC address is associated with a shared VLAN interface.
By default, the bank of MAC addresses that the ACE uses is randomly selected at boot time. However, if you configure two ACE appliances in the same Layer 2 network and they are using shared VLANs, the ACEs may select the same address bank, which results in the use of the same MAC addresses. To avoid this conflict, you must configure the bank that the ACEs will use.
To configure the MAC address bank to be used by the peer ACE with a shared VLAN, use the peer shared-vlan-hostid command in configuration mode in the Admin context. Use this command with the shared-vlan-hostid command to prevent MAC address conflicts between two peer ACEs sharing the same VLAN. Be sure to select a bank of MAC addresses for the peer that is different from the bank that is used by the local ACE.
The syntax of this command is as follows:
peer shared-vlan-hostid number
The number argument indicates the bank of MAC addresses that the ACE uses. Enter an integer from 1 to 16. Be sure to configure unique bank numbers for multiple ACEs. For example, to configure bank 2 of MAC addresses for the peer ACE, enter:
host1/Admin(config)# peer shared-vlan-hostid 2
Source NAT Using a VIP
The ACE now allows you to configure a virtual IP (VIP) address in the network address translation (NAT) pool for dynamic NAT and PAT. This action is useful when you want to source-NAT real server-originated connections (bound to the client) using the VIP address. Use this feature when there are a limited number of real world IP addresses on the client-side network. To perform PAT for different real servers that are source-NATed to the same IP address (VIP), you must configure the pat keyword in the nat-pool command.
For details about configuring dynamic NAT and PAT for source NAT, see the Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide.
Configuring the ACE to Reply to a Ping to a VIP only if the Primary Server Farm is in Service
The primary-inservice option has been added to the loadbalance vip icmp-reply active command in policy map class configuration mode. When you specify this option, the ACE replies to an ICMP ping only if the primary server farm state is UP, regardless of the state of the backup server farm. If this option is enabled and the primary server farm state is DOWN, the ACE discards the ICMP request and the request times out.
The syntax of this command is as follows:
loadbalance vip icmp-reply [active [primary-inservice]]
For example, to instruct the ACE to respond to a ping to a VIP only if the primary server farm is in service, enter:
host1/Admin(config-pmap-c)# loadbalance vip icmp-reply active primary-inservice
To remove this command from the configuration, enter:
host1/Admin(config-pmap-c)# no loadbalance vip icmp-reply active primary-inservice
New Redundancy State for Software Upgrade or Downgrade
A new redundancy state called STANDBY_WARM has been introduced for upgrading or downgrading the ACE software. When you upgrade or downgrade the ACE from one software version to another, there is a point in the process when the two ACEs have different software versions and, therefore, a CLI incompatibility. Prior to software version A1(8.0), such a condition would cause configuration and state synchronization to fail and the standby ACE would enter the STANDBY_COLD state.
When the software versions are different while upgrading or downgrading, the STANDBY_WARM state allows the configuration and state synchronization process to continue on a best-effort basis, which means that the active ACE will continue to synchronize configuration and state information to the standby even though the standby may not recognize or understand the CLI commands or state information. This new standby state allows the standby ACE to come up with best-effort support. In the STANDBY_WARM state, as with the STANDBY_HOT state, the configuration mode is disabled and configuration and state synchronization continues. A failover from the active to the standby based on priorities and preempt can still occur while the standby is in the STANDBY_WARM state.
Note Although support for the STANDBY_WARM state has been introduced in software version A1(8.0), it is intended for use only during an upgrade or downgrade procedure involving software versions A1(8.0) and higher. The STANDBY_WARM state will not be available in an upgrade or downgrade procedure involving A1(8.0) and the A1(7a) or A1(7b) software versions.
When upgrading or downgrading the ACE software (see the "Upgrading Your ACE Software from A1(7x) to A1(8.0x) in a Redundant Configuration" and "Downgrading Your ACE Software from Version A1(8.0x) to A1(7x) in a Redundant Configuration" sections), we recommend that you first upgrade or downgrade the standby ACE. After the standby ACE boots up, it may take a few minutes to reach the STANDBY_HOT state again. Once the standby ACE moves to the STANDBY_HOT state, you may then perform a graceful failover of all contexts from the active ACE to the standby ACE and then upgrade the other ACE.
Table 2 System Messages on the Operating Status of the Concurrent Connection Limit
Error Message
|
Explanation
|
Recommended Action
|
%ACE-LB_GENERAL-2-728035:
Disabled Web Application
Acceleration: Maximum
configured concurrent
connections limit (<count>)
reached, sending connections
to real servers
|
This message is informational. It is logged when the number of application acceleration concurrent connections exceed the configured or default concurrent connections limit (as specified through the optimize mode concurrent-connections limit command) and new connections are sent to the real servers without optimization.
|
None required.
|
%ACE-LB_GENERAL-2-728036:
Enabled Web Application
Acceleration: New
connections will be sent for
Optimization.(concurrent
connections count <count>)
|
This message is informational. It is logged when application acceleration connections have gone below the configured or default concurrent connections limit (as specified through the optimize mode concurrent-connections limit command) and optimization has been resumed for all new connections.
|
None required.
|
Modifications to the Cisco CSS-to-ACE Conversion Tool
The Cisco CSS-to-ACE conversion tool in the A1(8.0) release has been modified as follows:
•The CSS-to-ACE conversion tool globally applies the converted service policies to all available VLANS interfaces associated with a context on the ACE. If you want a specific service policy applied to a VLAN interface, you must manually attach the traffic policy to the VLAN interface.
•The conversion tool now creates the permit ip any any global access list to match the CSS allow-all functionality and automatically applies this access list to all VLAN interfaces.
•The Include Domain Commands checkbox has been added to the CSS-to-ACE conversion tool to allow you to choose whether domains are to be created and populated with objects. Automatically adding domains as part of the CSS conversion may make the resulting configuration unnecessarily long. The Include Domain Commands checkbox provides you with the flexibility to choose whether to actively enable or disable the inclusion of CSS domains. When you check this checkbox, if the CSS configuration contains a content under a owner group, all domains will then be created as part of the conversion.
Modifications to the Setup Script
With the A1(8.0a) release, the setup script now prompts you to change the Admin and www user passwords as a step when you boot the ACE for the first time and the ACE does not detect a startup-configuration file. The intent of the setup script is to guide you through the process of configuring a management VLAN on the ACE through one of its Gigabit Ethernet ports.
Note the following if you do not change the default Admin or www user passwords:
•If you do not change the default Admin password, after you upgrade the ACE software you will only be able to log in to the ACE through the console port.
•If you do change the default www user password, 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.
The following screen output illustrates the changes to the setup script with the A1(8.0a) release:
Starting sysmgr processes.. Please wait...Done!!!
Please change the password for admin user.
Admin user is allowed to login only from console until the password is changed.
User 'www' is disabled.Please change the password to enable the user.
Cisco Application Control Software (ACSW) TAC support: http://www.cisco.com/tac Copyright
(c) 1985-2007 by Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by other third parties and are
used and distributed under license.
Some parts of this software are covered under the GNU Public License. A copy of the
license is available at http://www.gnu.org/licenses/gpl.html.
---- Basic System Configuration Dialog ----
This setup utility will guide you through the basic configuration of the system. Setup
configures only enough connectivity to the ACE appliance Device Manager GUI of the system.
*Note: setup is mainly used for configuring the system initially, when no configuration is
present. So setup always assumes system defaults and not the current system configuration
values.
Press Enter at anytime to skip a dialog. Use ctrl-c at anytime to skip the remaining
dialogs.
Would you like to enter the basic configuration dialog (yes/no): yes
Please change the password for admin user.
Admin user is allowed to login only from console until the password is changed.
WARNING!! PASSWORD CHANGE WILL BE EFFECTIVE IMMEDIATELY
Enter the password for "admin":
Confirm the password for "admin":
User 'www' is disabled.Please change the password to enable the user.
WARNING!! PASSWORD CHANGE WILL BE EFFECTIVE IMMEDIATELY
Enter the password for "www":
Confirm the password for "www":
Which port is used to carry Management vlan (1 - 4)? [1]:
Software Feature Changes in A1(8.0)
Cisco has refined the ACE application acceleration functionality in software version A1(8.0) by removing features that are rarely used. The following list summarizes the application acceleration CLI commands and associated functions that are no longer supported in the ACE appliance, starting with software release A1(8.0):
•Action list optimization configuration mode commands: cache forward-with-wait, fast-redirect, flashconnect, flashconnect-object, image, meta refresh-to-302, urlmap scope, xslt merge
•Optimize configuration mode commands: prefix flashconnect
•Parameter map optimization configuration mode commands: flashconnect limit, image,
urlmap non-html, xslt merge-debug, xslt pretransformer, xslt stylesheet
For information on the use of the application acceleration and configuration features of the ACE, see the updated Device Manager GUI online help system and the Cisco 4700 Series Application Control Engine Appliance Application Acceleration and Optimization Configuration Guide located at:
http://www.cisco.com/en/US/docs/app_ntwk_service/data_center_app_services/ace_applicanes/vA1_7_/configuration/app_acceleration_and_optimization/guide/weboptgd.html
Note With the removal of the subset of the application acceleration functionality, an incompatibility has been introduced between release 1.2 of the Cisco Application Networking Manager (ANM) software and release A1(8.0) of the ACE appliance. Specifically, if you attempt to configure the ANM 1.2 to utilize a removed application acceleration command, the deployment will fail and the ANM displays an error message that is related to the removed application acceleration function.
To bypass this configuration issue in the ANM software, we recommend that you use the ACE appliance Device Manager to make the application acceleration and optimization configuration changes for the ACE.
Note that this incompatibility will be addressed in the next release of the ANM software.
Available ACE Licenses
By default, the ACE supports the following features and capabilities:
•Performance: 1 gigabit per second (Gbps) appliance throughput
•Virtualization: 1 admin context and 5 user contexts
•Secure Sockets Layer (SSL): 1000 transactions per second (TPS)
•Hypertext Transfer Protocol (HTTP) compression: 100 megabits per second (Mbps)
•Application Acceleration: 50 connections
You can increase the performance and operating capabilities of your ACE product by purchasing one of the licensing options.
You can order your ACE product by either of these methods:
•Ordering a license bundle. Each license bundles includes the ACE appliance and a series of software licenses.
•Ordering separate license options.
You must have the Admin role in the Admin context to perform the tasks of installing, removing, and updating the license. You can access the license and show license commands only in the Admin context.
Table 3 summarizes the contents of the available license bundles. Table 4 provides a list of the default and upgrade ACE appliance licensing options.
Note Table 3 and Table 4 contain the software license models that are supported for the A1(x.x) software. Any license that you may receive that is not listed in these tables cannot be used on the A1(x.x) software.
Table 3 ACE Licensing Bundles
License Model
|
Description
|
ACE-4710-2F-K9
|
This license bundle includes the following items:
•ACE 4710 appliance
•2-Gbps throughput license
•7500 SSL transactions per second (TPS) license
•1-Gbps compression license
•5 virtual contexts license (default)
•Application acceleration license (50 connections)
|
ACE-4710-1F-K9
|
This license bundle includes the following items:
•ACE 4710 appliance
•1-Gbps throughput license
•5000 SSL TPS license
•500-Mbps compression license
•5 virtual contexts license (default)
•Application acceleration license (50 connections)
|
Table 4 ACE Licensing Options
Feature
|
License Model
|
Description
|
ACE Appliance Software License
|
ACE-AP-SW-1.8
|
A1(8.0) software.
|
Performance Throughput
|
ACE-AP-01-LIC (default)
|
1-Gbps throughput.
|
ACE-AP-02-LIC
|
2-Gbps throughput.
|
ACE-AP-04-LIC
|
4-Gbps throughput.
|
ACE-AP-04-UP2
|
Upgrade from 2-Gbps to 4-Gbps throughput.
|
Virtualization
|
Default
|
1 admin/5 user contexts.
|
ACE-AP-VIRT-020
|
1 admin/20 user contexts.
|
SSL
|
Default
|
1000 TPS.
|
ACE-AP-SSL-05K-K9
|
5000 TPS.
|
ACE-AP-SSL-07K-K9
|
7500 TPS.
|
ACE-AP-SSL-UP1-K9
|
Upgrade from 5000 TPS to 7500 TPS.
|
HTTP Compression
|
Default
|
100-Mbps.
|
ACE-AP-C-500-LIC
|
500-Mbps.
|
ACE-AP-C-1000-LIC
|
1-Gbps.
|
ACE-AP-C-2000-LIC
|
2-Gbps.
|
ACE-AP-C-2000-LIC=
|
2-Gbps license spare.
|
ACE-AP-C-UP1=
|
Upgrade from 500 Mbps to 1 Gbps.
|
ACE-AP-C-UP3=
|
Upgrade from 1 Gbps to 2 Gbps.
|
Application Acceleration Feature Pack License
|
ACE-AP-OPT-LIC-K9
|
Application acceleration and optimization. By default, the ACE performs up to 50 concurrent connections. With the application acceleration and optimization software feature pack installed, the ACE can provide greater than 50 concurrent connections.
This license increases the operating capabilities of the following features:
•Delta optimization
•Adaptive dynamic caching
•Flashforward
•Dynamic Etag
|
|
ACE demo licenses are available through your Cisco account representative. A demo license is valid for only 60 days. At the end of this period, you must update the demo license with a permanent license to continue to use the ACE software. To view the expiration of a demo license, from the CLI, use the show license usage command in Exec mode. If you need to replace the ACE appliance, you can copy and install the licenses onto the replacement appliance.
Ordering an Upgrade License and Generating a Key
This section describes the process that you use to order an upgrade license and to generate a license key for your ACE. To order an upgrade license, follow these steps:
Step 1 Order one of the licenses from the list in the "Software Feature Changes in A1(8.0)" section using any of the available Cisco ordering tools on cisco.com.
Step 2 When you receive the Software License Claim Certificate from Cisco, follow the instructions that direct you to the following Cisco.com website:
•If you are a registered user of cisco.com, go to the following location:
http://www.cisco.com/go/license
•If you are not a registered user of cisco.com, go to the following location:
http://www.cisco.com/go/license/public
Step 3 Enter the Product Authorization Key (PAK) number found on the Software License Claim Certificate as your proof of purchase.
Step 4 Provide all the requested information to generate a license key. Once the system generates the license key, you will receive a license key e-mail with an attached license file and installation instructions.
Step 5 Save the license key e-mail in a safe place in case you need it in the future (for example, to transfer the license to another ACE).
For information on installing and managing ACE licenses:
•From the ACE appliance CLI, see Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
•From ACE appliance Device Manager, see Chapter 2, Configuring Virtual Contexts, in the Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Configuration Guide.
Note If you need to downgrade from version A1(8.0) back to A1(7x) (see the "Downgrading Your ACE Software from Version A1(8.0x) to A1(7x) in a Redundant Configuration" section), and your ACE includes a new 4-Gbps performance throughput license or a new 2-Gbps HTTP compression license, ensure that you first uninstall the following prior to downgrading:
Uninstall the 4-Gbps performance throughput license and reinstall the 2-Gbps license.
Uninstall the 2-Gbps HTTP compression license and reinstall the 1-Gbps license.
See Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Upgrading Your ACE Software from A1(7x) to A1(8.0x) in a Redundant Configuration
This procedure 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.
For complete instructions on how to upgrade your ACE software, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Before You Begin
Before you upgrade your ACE software, please be sure that your ACE configurations meet the upgrade prerequisites in the following sections:
•Changing the Admin Password
•Changing the www User Password
•Checking Your Configuration for FT Priority and Preempt
Changing the Admin Password
Before you upgrade to software version A1(8.0a) or higher, you must change the default Admin password if you have not already done so. Otherwise, after you upgrade the ACE software, you will only be able to log in to the ACE through the console port.
Caution If you do not change the Admin password prior to upgrading to A1(8.0a) or higher, configuration synchronization may fail and the context may not be in the STANDBY_HOT state.
See, Chapter 1, Setting Up the ACE, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide for details on changing the default Admin password.
Note If your ACE is managed by the Cisco Application Networking Manager (ANM) software, you must change the Admin password on the ANM in the Primary Attributes page instead of the ACE CLI. From the ANM, click the Change Password button on Primary Attributes page (Config > Devices > System > Primary Attributes).
Changing the www User Password
Before you upgrade to software version A1(8.0a) or higher, you must change the default www user password if you have not already done so. Otherwise, after you upgrade the ACE software, the www user will be disabled and you will not be able to use Extensible Markup Language (XML) to remotely configure an ACE until you change the default www user password.
See Chapter 2, Configuring Virtualization, in the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide for details on changing a user account password. In this case, the user would be www.
Caution If you do not change the www user password prior to upgrading to A1(8.0a) or higher, configuration synchronization may fail and the context may not be in the STANDBY_HOT state.
Checking Your Configuration for FT Priority and Preempt
If you want the currently active ACE to remain active after the software upgrade, be sure that the active ACE has a higher priority than the standby (peer) ACE and that the preempt command is configured. To check the redundant configuration of your ACEs, use the show running-config ft command. Note that the preempt command is enabled by default and does not appear in the running-config.
Upgrade Procedure
To upgrade your ACE A1(7x) software to A1(8.0x) in a redundant configuration, follow these steps:
Step 1 Log in to both the active and standby ACEs. The Exec mode prompt appears at the CLI. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the Admin context. If necessary, log directly in to, or change to the Admin context.
Step 2 Save the running configurations of every context by entering the write memory all command in Exec mode in the Admin context of each ACE.
ACE-1/Admin# write memory all
Step 3 Create a checkpoint in each context of both ACEs by entering the checkpoint create command in Exec mode.
ACE-1/Admin# checkpoint create ADMIN_CHECKPOINT
ACE-1/C1# checkpoint create C1_CHECKPOINT
Step 4 Copy the new software image to image directory of each ACE (active and standby) by entering the copy ftp, copy sftp, or the copy tftp command in Exec mode. For example, to copy the image with the name c4710ace-mz.A1_8.bin through FTP, enter:
ACE-1/Admin# copy ftp://server1/images//c4710ace-mz.A1_8.bin image:
Step 5 Ensure that the new software image is present on both the active and standby ACEs by entering the dir command in Exec mode. For example, enter:
ACE-1/Admin# dir image:c4710ace-mz.A1_8.bin
176876624 Apr 08 2008 14:15:31 c4710ace-mz.A1_8.bin
176876624 Feb 25 14:15:31 2008 c4710ace-mz.A1_7b.bin
Usage for image: filesystem
896978944 bytes total used
Step 6 On the active ACE, enter the show running-config command and verify if any of the unsupported application acceleration CLI commands are enabled in the action list, parameter map, or optimize sections of the running-configuration file. Include the pipe character (|) to enable an output modifier that filters the command output.
The following list summarizes the application acceleration CLI commands that are no longer supported in the ACE appliance, starting with software release A1(8.0):
–Action list optimization configuration mode commands: cache forward-with-wait, fast-redirect, flashconnect, flashconnect-object, image, meta refresh-to-302, urlmap scope, xslt merge
–Optimize configuration mode commands: prefix flashconnect
–Parameter map optimization configuration mode commands: flashconnect limit, image,
urlmap non-html, xslt merge-debug, xslt pretransformer, xslt stylesheet
For example, enter:
ACE-1/Admin# show running-config action-list | include flashconnect
Generating configuration....
Step 7 If any of the unsupported application acceleration commands are present, remove them by specifying the no form of the associated command. For example, enter:
ACE-1/Admin# show running-config action-list
Generating configuration....
action-list type optimization http AL-AVS
Enter configuration commands, one per line. End with CNTL/Z.
ACE-1/Admin(config)# action-list type optimization http AL-AVS
ACE-1/Admin(config-actlist-optm)# no flashconnect
ACE-1/Admin(config-actlist-optm)# no flashconnect-object
ACE-1/Admin(config-actlist-optm)# exit
ACE-1/Admin(config)# exit
Step 8 Verify the current BOOT environment variable and configuration register setting by entering the show bootvar command in Exec mode. For example, enter:
ACE-1/Admin# show bootvar
BOOT variable = "disk0:c4710ace-mz.A1_7b.bin"
Configuration register is 0x1
Step 9 Remove the existing image from the boot variable on ACE-1 by entering the no boot system image: command in configuration mode. For example, enter:
Enter configuration commands, one per line. End with CNTL/Z.
ACE-1/Admin(config)# no boot system image:c4710ace-mz.A1_7b.bin
Step 10 Configure ACE-1 to autoboot from the A1(8.0) image. To set the boot variable and configuration register to 0x1 (perform auto boot and use startup-config file), use the boot system image: and config-register commands in configuration mode. For example, enter:
ACE-1/Admin(config)# boot system image:c4710ace-mz.A1_8.bin
ACE-1/Admin(config)# config-register 0x1
ACE-1/Admin(config)# exit
ACE-1/Admin# show bootvar
BOOT variable = "disk0:c4710ace-mz.A1_8.bin"
Configuration register is 0x1
Step 11 On the standby ACE appliance (ACE-2), perform the following:
–Enter the show running-config command and ensure that all the changes made in the active ACE (ACE-1) are also reflected on the standby ACE.
–Enter the show bootvar command to verify that the boot variable was synchronized with ACE-1.
Step 12 Verify the state of each ACE by entering the show ft group detail command in Exec mode. Upgrade the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command in Exec mode. After ACE-2 boots up, it may take a few minutes to reach the STANDBY_HOT state again. Configuration synchronization is still enabled and the connections through ACE-1 are still being replicated to ACE-2.
Note Do not add any more commands to the ACE-1 configuration. At this point in the upgrade procedure, any incremental commands that you add to the ACE1 configuration may not be properly synchronized to the ACE-2 configuration.
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 13 After the standby ACE reboots, log in and perform the following actions to verify the state of the standby ACE:
–Enter the show version command in Exec mode to verify that the appliance has properly rebooted with the A1(8.0x) software image.
–Enter the show ft group detail command in Exec mode to verify that the standby ACE has recovered to a STANDBY_HOT state.
Note You may encounter synchronization issues if the active peer, which has not been rebooted at this point in the procedure, still contains the deprecated application acceleration commands in its running-configuration file when you reload the standby ACE. In this case, when the next configuration synchronization occurs between the two peers, the configuration sync will fail and the standby ACE enters the STANDBY_COLD state.
If the deprecated application acceleration commands appear in the startup-config file of either the standby ACE or the active ACE, the console displays exceptions during the reload process. If the running-config file of the active ACE is in the correct state, you can correct the startup-config file mismatch between the two peers by entering the copy running-config startup-config command, followed by the write mem command.
Step 14 Perform a graceful failover of all contexts from ACE-1 to ACE-2 by entering the ft switchover all command in Exec mode on ACE-1. ACE-2 becomes the new active ACE and assumes mastership of all active connections with no interruption to existing connections.
ACE-1/Admin# ft switchover all
Step 15 Upgrade ACE-1 by reloading it. Verify that ACE-1 enters the STANDBY_HOT state (this action may take several minutes) by entering the show ft group detail command in Exec mode.
Because both ACE-1 and ACE-2 are running the same version of software now, the configuration mode is enabled. The configuration is synchronized from ACE 2 (currently active) to ACE-1. If ACE-1 is configured with a higher priority and preempt is configured on the FT group, ACE-1 reasserts mastership after it has received all configuration and state information from ACE-2, making ACE-2 the new standby. ACE-1 becomes the active ACE once again.
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 16 Verify that ACE-1 is in the ACTIVE state and ACE-2 is in the STANDBY_HOT state by entering the show ft group detail command in Exec mode.
Downgrading Your ACE Software from Version A1(8.0x) to A1(7x) in a Redundant Configuration
If you need to downgrade your ACE software from version A1(8.0x) to an earlier version, use the procedure that follows. This procedure assumes that your ACEs are configured as redundant peers to ensure that there is no disruption to existing connections during the downgrade process. In the following procedure, the active ACE is referred to as ACE-1 and the standby ACE is referred to as ACE-2.
Before You Begin
Before you downgrade your ACE software, ensure that the following conditions exist:
•Identical versions of A1(7.x) software images reside in the image: directory of both ACEs.
•The active ACE has a higher priority than the standby ACE and preempt is enabled on the FT group if you want the active ACE to remain active after the downgrade procedure.
If your ACE includes a new 4-Gbps performance throughput license or a new 2-Gbps HTTP compression license, ensure that you first uninstall the following prior to downgrading:
•Uninstall the 4-Gbps performance throughput license and reinstall the 2-Gbps license.
•Uninstall the 2-Gbps HTTP compression license and reinstall the 1-Gbps license.
See Chapter 3, Managing ACE Software Licenses, in the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Downgrade Procedure
To downgrade your A1(8.0x) software in a redundant configuration, perform the following steps:
Step 1 If you have previously created checkpoints in your A1(7.x) running-configuration files (highly recommended), roll back the configuration in each context on each ACE to the check-pointed configuration. For example:
host1/Admin# checkpoint rollback CHECKPOINT_ADMIN
host1/C1# checkpoint rollback CHECKPOINT_C1
Do the same on the other ACE. For information about creating checkpoints and rolling back configurations, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
Step 2 Configure ACE-1 to automatically boot from the A1(7.x) image. To set the boot variable and configuration register to 1, use the boot system image: and config-register commands in configuration mode. For example, enter:
host1/Admin(config)# boot system image:c4710ace-mz.A1_7b.bin
host1/Admin(config)# config-register 1
host1/Admin(config)# exit
You can set up to two images through the boot system command. If the first image fails, the ACE tries to boot from the second image.
Note Use the no boot system image: command to remove the configured A1(8.0) boot variable.
Step 3 Verify that the boot variable was synchronized to ACE-2 by entering the following command on ACE-2:
host1/Admin# show bootvar
BOOT variable = "disk0:c4710ace-mz.A1_7b.bin"
Configuration register is 0x1
Step 4 Verify the state of each ACE by entering the show ft group detail command in Exec mode. Downgrade the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command.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 A1(7.x) software does not recognize the A1(8.0x) commands in the startup-configuration file. After ACE-2 boots up, it may take a few minutes to reach the STANDBY_HOT state again. At this time, configuration synchronization is disabled, but the connections through ACE-1 are still being replicated to ACE-2.
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 5 Perform a graceful failover of all contexts from ACE-1 to ACE-2 by entering the ft switchover all command in Exec mode on ACE-1. ACE-2 becomes the new active ACE and assumes mastership of all active connections with no interruption to existing connections.
host1/Admin# ft switchover all
Step 6 Reload ACE-1 with the same A1(7.x) software version as ACE-2. Again, you may observe a few errors as ACE-1 loads the startup-configuration file.
After ACE-1 boots up, it assumes the role of standby and enters the STANDBY_HOT state (this may take several minutes). You can verify the states of both ACEs by entering the show ft group detail command in Exec mode. Because both ACE-1 and ACE-2 are running the same version of software now, configuration mode is enabled. The configuration is synchronized from ACE 2 (currently active) to ACE-1. If ACE-1 is configured with a higher priority and preempt is configured on the FT group, ACE-1 reasserts mastership after it has received all configuration and state information from ACE-2, making ACE-2 the new standby. ACE-1 becomes the active ACE once again.
Step 7 Perform manual cleanup in the running-configuration files of both ACEs to remove unnecessary version A1(8.0x) configuration elements. For example, you may need to remove a service policy from an interface that was part of the version A1(8.0) configuration that is no longer needed in version A1(7.x).
Step 8 Enter the write memory all command in both ACEs to save the running-configuration files in all configured contexts to their respective startup-configuration files. This action will eliminate future errors when the ACEs reload their startup-configuration files.
Supported Browsers for ACE Appliance Device Manager
The ACE appliance Device Manager is supported on the following browsers:
•Microsoft Internet Explorer 6.0 Service Pack 2 on Windows XP and Windows 2000
•Firefox 2.0 on Windows XP, Windows 2000, and Red Hat Enterprise Linux AS v.4
All browsers require cookies and DHTML (JavaScript) to be enabled.
ACE Operating Considerations
This section outlines the following ACE operating considerations:
•Verifying the ACE Appliance Hardware Revision
•Using Dynamic ETag and HTTP Compression
•Using Application Acceleration FlashForward With IP Address Stickiness
Verifying the ACE Appliance Hardware Revision
Certain ACE appliances have been programmed with a hardware revision of 65535.65535 in the IDProm instead of the correct hardware revision of 1.1. This is a cosmetic issue only and has no functional impact on the operation of the ACE appliance.
To verify the hardware revision of your ACE appliance, enter the show hardware command as shown in the example below:
switch/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: QCN1208007N
Hardware Rev: 65535.65535
MFG Part Num: 800-29070-02
Using Dynamic ETag and HTTP Compression
When you operate the ACE with application acceleration, and you define a policy map that includes dynamic ETag (entity tag) and HTTP compression, you may encounter behavioral issues when using a Microsoft Internet Explorer web browser (typically, Internet Explorer 6.0) that prevents the dynamic ETag function from properly leveraging the web browser cache. With HTTP compression and dynamic ETag configured, upon an Internet Explorer web browser refresh of the same page without any content changes, the browser will continue to retrieve the new (unchanged) content along with a new ETag header and the HTTP "200 OK" request succeeded response. Typically, when you use dynamic ETags and the web content has not changed, the browser receives a 304 Not Modified response and no data. This response prevents users from downloading objects on each request.
This operating consideration with the Microsoft Internet Explorer web browser does not result in broken pages or functionality but rather in a failed attempt at application acceleration, which results in the unnecessary download of objects that should be cached.
This behavior does not occur with the Firefox 2.0 web browser, so we recommend that you use the Firefox 2.0 web browser instead of the Internet Explorer 6.0 web browser if you plan to configure dynamic ETag (entity tag) with HTTP compression.
Using Application Acceleration FlashForward With IP Address Stickiness
When you operate the ACE with application acceleration, if your configuration includes the following elements:
•FlashForward object acceleration to extend the ACE appliance's bandwidth usage reduction and download acceleration benefits to objects that are embedded within HTML pages, and
•IP address stickiness to stick a client to the same server for multiple subsequent connections as needed to complete a transaction
you may find that there will more than one sticky entry created for the same session when a single user (one client IP address) attempts to retrieve one HTML page. The creation of multiple sticky entries is the expected behavior; in addition to the sticky entry created for the user session, a second sticky entry will be created for the application acceleration cache renew requests for the FlashForward embedded objects.
This behavior can be encountered when one of the following conditions occur:
•The client already contains the cached page in the browser cache.
•The application acceleration cache expires maximum setting (the expires-setting command in parameter map optimization configuration mode) is at the default of 300 seconds.
•The IP address sticky timeout setting (timeout command in sticky-IP configuration mode) is set to a lower value (for example, two minutes).
Under these conditions, when the client request an HTML page, the request is then load-balanced to multiple real servers. With IP address stickiness enabled, you may expect that the request would stick with a single real server and serve the HTML page from that server.
For example, in the show serverfarm output illustrated below, both servers increment and form two sticky entries.
switch/Admin# clear serverfarm WWWfarm
switch/Admin# show serverfarm WWWfarm
serverfarm : WWWfarm, type: HOST
num times back inservice : 0
---------------------------------
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
192.168.10.12:0 8 OPERATIONAL 1 1 0
max-conns : - , out-of-rotation count : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
192.168.10.99:0 8 OPERATIONAL 1 1 0
max-conns : - , out-of-rotation count : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
ACE Documentation Set
You can access the ACE appliance documentation on www.cisco.com at:
http://www.cisco.com/en/US/products/ps7027/tsd_products_support_series_home.html
For information about installing the Cisco ACE 4710 appliance hardware, see the following documents on Cisco.com:
Document Title
|
Description
|
Cisco 4710 Application Control Engine Appliance
Hardware Installation Guide
|
Provides hardware information for installing the Cisco ACE 4710 appliance.
|
Regulatory Compliance and Safety Information for the Cisco 4710 Application Control Engine Appliance
|
Provide regulatory compliance and safety information for the Cisco ACE 4710 appliance.
|
To familiarize yourself with the ACE appliance software, see the following documents on Cisco.com:
Document Title
|
Description
|
Release Note for the Cisco 4700 Series Application Control Engine Appliance
|
Provides information about operating considerations and caveats for the ACE.
|
Cisco 4700 Series Application Control Engine Appliance CLI Quick Configuration Note
|
Describes how to use the ACE appliance CLI to perform the initial setup and configuration tasks.
|
Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Quick Configuration Note
|
Describes how to use the ACE appliance Device Manager GUI to perform the initial setup and VIP load-balancing configuration tasks.
|
For detailed configuration information on the ACE appliance Device Manager, see the following software documents on Cisco.com:
Document Title
|
Description
|
Cisco 4700 Series Application Control Engine Appliance Device Manager GUI Configuration Guide
|
Describes how to use the ACE appliance Device Manager. The Device Manager resides in Flash memory on the ACE appliance to provide a browser-based graphical user interface for configuring and managing the ACE.
|
For detailed configuration information on the ACE CLI, see the following software documents on Cisco.com:
Document Title
|
Description
|
Cisco 4700 Series Application Control Engine Appliance Administration Guide
|
Describes how to perform the following administration tasks on the ACE:
•Setting up the ACE
•Establishing remote access
•Managing software licenses
•Configuring class maps and policy maps
•Managing the ACE software
•Configuring SNMP
•Configuring redundancy
•Configuring the XML interface
•Upgrading the ACE software
|
Cisco 4700 Series Application Control Engine Appliance Application Acceleration and Optimization Configuration Guide
|
Describes the configuration of the application acceleration and optimization features of the ACE. It also provides an overview and description of the application acceleration features and operation.
|
Cisco 4700 Series Application Control Engine Appliance Command Reference
|
Provides an alphabetical list and descriptions of all CLI commands by mode, including syntax, options, and related commands.
|
Cisco 4700 Series Application Control Engine Appliance Security Configuration Guide
|
Describes how to perform the following ACE security configuration tasks:
•Security access control lists (ACLs)
•User authentication and accounting using a Terminal Access Controller Access Control System Plus (TACACS+), Remote Authentication Dial-In User Service (RADIUS), or Lightweight Directory Access Protocol (LDAP) server
•Application protocol and HTTP deep packet inspection
•TCP/IP normalization and termination parameters
•Network Address Translation (NAT)
|
Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide
|
Describes how to configure the following server load-balancing tasks on the ACE:
•Real servers and server farms
•Class maps and policy maps to load balance traffic to real servers in server farms
•Server health monitoring (probes)
•Stickiness
•Firewall load balancing
•TCL scripts
|
Cisco 4700 Series Application Control Engine Appliance SSL Configuration Guide
|
Describes how to configure the following Secure Sockets Layer (SSL) tasks on the ACE:
•SSL certificates and keys
•SSL initiation
•SSL termination
•End-to-end SSL
|
Cisco 4700 Series Application Control Engine Appliance System Message Guide
|
Describes how to configure system message logging on the ACE. This guide also lists and describes the system log (syslog) messages generated by the ACE.
|
Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide
|
Describes how to operate your ACE in a single context or in multiple contexts.
|
Cisco CSS-to-ACE Conversion Tool User Guide
|
Describes how to use the CSS-to-ACE conversion tool to migrate Cisco Content Services Switches (CSS) running-configuration or startup-configuration files to the ACE.
|
Software Version A1(8.0a) Resolved Caveats
The following resolved caveats applies to ACE software version A1(8.0a).
•CSCso55063—A user with the debug user role is able to run the setup script through the setup command in Exec mode. The intent of the setup script is to guide you through the process of configuring a management VLAN on the ACE through one of its Gigabit Ethernet ports. Because configuration mode is disabled for the debug user role, if you attempt to use the setup script it will fail and generate errors as show in the example below:
---- Basic System Configuration Dialog ----
Would you like to edit the configuration? (yes/no) [n]:
Use this configuration? (yes/no) [y]:
Error: There was an error executing at least one of the commands
Please verify the following log for the command execution errors.
`interface gigabitEthernet 1/2`
`interface gigabitEthernet 1/2`
*** Context 0: cmd parse error ***
`switchport trunk allow vlan 10`
`switchport trunk allow vlan 10`
*** Context 0: cmd parse error ***
Workaround: None
•CSCsq60664—Multiple Cisco products contain either of two authentication vulnerabilities in the Simple Network Management Protocol version 3 (SNMPv3) feature. These vulnerabilities can be exploited when processing a malformed SNMPv3 message. These vulnerabilities could allow the disclosure of network information or may enable an attacker to perform configuration changes to vulnerable devices. The SNMP server is an optional service that is disabled by default in Cisco products. Only SNMPv3 is impacted by these vulnerabilities. Workarounds are available for mitigating the impact of the vulnerabilities described in this document.
Note SNMP versions 1, 2 and 2c are not impacted by these vulnerabilities.
The United States Computer Emergency Response Team (US-CERT) has assigned Vulnerability Note VU#878044 to these vulnerabilities.
Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-0960 has also been assigned to these vulnerabilities.
This advisory is posted at:
http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml
Software Version A1(8.0) Resolved Caveats, Open Caveats, and Command Changes
The following sections contain the resolved and open caveats, and command changes, in software version A1(8.0):
•Software Version A1(8.0) Resolved Caveats
•Software Version A1(8.0) Open Caveats
•Software Version A1(8.0) Command Changes
Software Version A1(8.0) Resolved Caveats
The following resolved caveats apply to ACE software version A1(8.0).
•CSCsj88500—If a large configuration contains many different service policy actions, some of the show service-policy command output may be missing. The ACE may not display some of the actions associated with the service policy. Workaround: None.
•CSCsk02170—If you configure a less-specific route before a more-specific route, ACE-originated traffic may not use the more specific route. For example, if you configure the following routes in the order shown:
Admin/host(config)# ip route 1.0.0.0 255.0.0.0 10.0.0.1
Admin/host(config)# ip route 1.1.1.1 255.255.255.255 192.168.0.1
The output of the show ip route command displays the route for 1.1.1.1, but the ACE may continue to use the 10.0.0.1 next hop. This behavior is dependent on the order in which the routes are configured on the ACE and affects ACE-originated traffic only.
Workaround: To restore routing as expected from the show ip route command output, perform the following steps:
1. Configure a less-specific dummy route.
2. Remove the less-specific route.
This sequence does not affect the routing table, but it does cause the cache to refresh, which corrects the routing problem.
•CSCsk23763—You may encounter issues with TACACS+ authentication if your configuration include a global preshared key. When you attempt to authenticate with Cisco Secure ACS, the authentication may fail, and the Cisco Secure ACS displays the error message "key mismatch". This issue is not encountered with a RADIUS configuration. Workaround: Use the tacacs-server host command to enable an authentication key.
•CSCsk34767—The FTP inspection statistics associated with the show stats inspect command cannot be cleared using the clear stats inspect command. Workaround: None.
•CSCsk38275—With a Layer 7 load-balancing configuration and a large number of concurrent Layer 7 load-balancing connections, the ACE may reboot. Workaround: None.
•CSCsk39152—You may be unable to execute the show tech-support and show conn commands and a message appears indicating that there is no space left on the ACE. For example:
switch/Admin# show tech-support cp: writing `/tmp/tech_details.22399': No space left
on device
switch/Admin# show conn de | be 21.111.21.232 cat: write error: No space left on
device
This behavior can occur when there is a high number of concurrent connections, which can result in the output from show tech-support and show conn commands overflowing the tmp directory. Workaround: None.
•CSCsk46544—In a redundant configuration, the logging configuration may only be partially synchronized through the FT link. Workaround: None.
•CSCsk59228—With the inspect dns command configured, approximately 4 M concurrent connections (mostly DNS), and 1 M NAT operations, the ACE may become unresponsive if the network processor becomes overloaded and stops processing messages on the internal queues. Workaround: Remove the inspect dns command from the configuration.
•CSCsk61805—UDP probes may stay alive even when the ACE receives ICMP host-unreachable messages. This behavior applies only to host-unreachable messages. The UDP probe behavior is correct with port-unreachable messages. Workaround: None.
•CSCsk68396—In a firewall load-balancing configuration where the firewalls are positioned between two ACEs and you configure the mac-sticky command on the ACEs, an ICMP error packet from a router located between the second ACE and the real server is forwarded to a firewall that is different from the firewall that received the original IP packet that generated the ICMP error. Workaround: None.
•CSCsk73349—When ACE is configured for use with a TACACS+ server and a username contains the "@" character, TACACS+ authentication fails. Workaround: Remove the "@" character from a username when using ACE with a TACACS+ server.
•CSCsk74766—While copying and pasting the commands necessary to configure sticky server farms for a load-balancing policy map, the ACE may display the following message: "Error: Add link failed!" This behavior is intermittent. Workaround: Manually configure the commands needed to add the sticky server farm to the load-balancing policy map instead of copying and pasting the commands.
•CSCsk83277—When using the show running-config command, the ACE may insert one or two blank lines between the resource-class portion and the TACACS+ portion of the configuration in the resulting show command output. Workaround: None.
•CSCsk86070—When you enter the class class_name insert-before class_name command, the ACE may log the following message:
%ACE-1-106028: WARNING: Unknown error while processing access-group.
The ACE may also log the following message if the debug access-list merge errors and the debug access-list merge info commands are enabled:
acl: (ctx:0) ACL-MERGE add acl: instance:1 feature:SECURITYprotocol:IPv4 priority:0
ace-count:1 sec-level:0x7context:0
acl: (ctx:0) ACL-MERGE-ERROR:Duplicate lineno: lineno already exists in
insert_ace_in_acl ../security/acl/acl_merge.c:3728
acl: (ctx:0) ACL-MERGE-ERROR:insertion in list failed in acl_merge_add_acl_to_list
../security/acl/acl_merge.c:4967
Workaround: Enter the write memory command and then reload the ACE. Alternatively, you can delete the interface on which the offending service policy is configured using the no interface vlan vlan_id command and then reconfigure the interface with the IP addresses, the service-policy, and so on. You must perform these actions for every interface on which the service policy is configured.
•CSCsk89562—If you configure dynamic NAT with PAT on an ACE for ICMP traffic, you may observe that a large number of NAT pool allocations fail (as displayed by the show np 1 me-stats -socm | i NAT command) and that ICMP ports (ICMP IDs) are not released to the NAT pool for reuse when the connections close. Eventually, the number of active NAT pool allocations (NAT Pool Alloc and NAT Pool Free counters) may increase beyond the number of active connections indicating that the NAT resources are not being reused. When no ports are available, NAT allocation failures result and the ACE forwards the traffic unNATed. This behavior has not been observed with UDP or TCP connections.
Workaround: If possible, avoid NAT of ICMP traffic. If NAT of ICMP traffic is necessary for your application or if NAT resources have already been leaked, schedule periodic reboots of the ACE to free NAT pool resources. If you schedule the reboots before the ports are totally depleted, then you will not observe any adverse network effect. When the difference between the NAT Pool Alloc and the NAT Pool Free counters is approximately 32,000, the ACE has reached the upper limit of resources that may be leaked before an adverse network effect is noticed and NAT Pool Alloc failures associated with unNATed connections occur. Rebooting the ACE before the difference between the NAT Pool Alloc and the NAT Pool Free counters is 30,000 will protect your network from any unexpected event.
•CSCsk91129—Application issues and possible timeouts may occur with connections to an HTTPS VIP address. For example, a GET request is made to obtain data from a server and the returned data is in excess of 125 KB. Though the ACE sends this data to the client, there may be indications that the client has missed some data and requests a retransmission of that data. When this occurs, the ACE may ignore the data retransmission request, which results in a connection timeout. Note that this connection timeout behavior may not occur with a lesser amount of returned data (less than 125 KB).
•CSCsk96968—When SSL termination is configured on the ACE and a connection parameter-map that includes the nagle feature is applied, you may observe a delay in the time that is required to complete an SSL handshake. This behavior should not cause the connection to fail. For connections where a large amount of data will be passed, the time required to send the data will be much greater than the delay caused by completing the SSL handshake. In these cases, you may not notice a delay. However, for connections with only a small amount of data, the handshake delay may be more apparent.
Workaround: If you observe the handshake delay and consider it to be a problem, disable nagle in the connection parameter map.
•CSCsk98100—Changing the IP address of a VIP causes the new VIP to stop responding to ICMP pings even though the new VIP is configured to respond to ICMP pings with the loadbalance vip icmp-reply active command. Workaround: Disable and then reenable the loadbalance vip icmp-reply active command associated with the traffic class.
•CSCsk98229—The system uptime value resets after 49 days and 17 hours. Workaround: None.
•CSCsk98342—When you remove a real server from a server farm configuration, Layer 3 and Layer 4 connections may fail to be removed and subsequent traffic on the connection will still be sent to the removed real server. Workaround: Instruct the ACE to purge Layer 3 and Layer 4 connections by using the failaction purge command prior to removing the real server from the server farm. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl04936—The IP address and protocol information contained in syslog message 106023 (an IP packet was denied by an ACL) may be incorrect. Workaround: None.
•CSCsl06233—With server connection reuse configured and a very heavy traffic rate, the ACE may become unresponsive. Workaround: None.
•CSCsl08608—If you apply the connection limit to a real server, but you do not apply the same connection limit under the associated server farm level, the ACE may not properly reflect the global values for the real server under the server farm. As a result, even though the real server has attained its maximum connection, it is still shown as OPERATIONAL in the show serverfarm detail command output. Workaround: Modify the global connection limit value once again under both the real server and the server farm.
•CSCsl23515—During an SSL handshake from the client, the ACE may fail to respond with a Server Hello message. The use of SSL termination on the ACE may lead to this behavior.
•CSCsl24291—The ACE may fail to honor a RST (Reset) with data from a server even after a FIN (Finish) was previously received by the appliance. In this case, the ACE ignores the RST and retransmits data to the server.
•CSCsl31301—In a Layer 7 configuration, the ACE does not retransmit a FIN in a TCP packet that does not have data in it. Workaround: The associated client-server connections will time out eventually. No action is required.
•CSCsl32646—When you are using the least-connections load-balancing predictor, if a server goes out of service ungracefully and then comes back into service later, the ACE may not assign the appropriate number of new connections to the server. This behavior may impact other real servers in the server farm. Workaround: If you observe this condition, use the round-robin predictor instead of least connections. If least connections is necessary for your application, try changing the predictor to round-robin temporarily, wait 60 seconds, and then change back to least connections. If the problem does not resolve itself, use round-robin if possible.
•CSCsl34397—When the ACE is running in bridge mode and SNMP notifications are enabled, the ACE may reboot with an SNMP daemon (snmpd) core dump. Workaround: None.
•CSCsl35473—Because the DNS inspection hash table entry timeout is fixed at approximately 100 seconds, when DNS inspection is configured and there are many unanswered requests, the hash table may become full. When the table is full, the ACE stops inspecting new DNS traffic. Workaround: None.
•CSCsl38035—The ACE may reboot with a single WGET request when you modify an SSL proxy client service in a Layer 7 policy map. Workaround: None.
•CSCsl38632—Occasionally, uploading or downloading files over SSL may fail. This behavior may occur when the ACE is the receiver of TCP data. The TCP buffer-share feature implements TCP sliding windows on the ACE and can cause the ACE to advertise a zero window size to the sender of the data. If a duplicate ACK arrives at the ACE soon after the module advertised a zero window segment, then the ACE fails to reopen its advertised window and the connection stalls. Workaround: None.
•CSCsl42384—When the ACE is terminating a connection, is in zero window-mode (because of a delayed ACK from the client or the server is transmitting faster than the client can respond), and the server keeps sending ACKs and/or data, the ACE may unnecessarily shrink the TCP window. This behavior can cause end hosts to become confused and in-flight segments to be incorrectly dropped because of failing window checks on the ACE. Workaround: None.
•CSC44187— cpmProcessExtRevTable may fail return a value from any user context outside of the Admin context. Workaround: Change to the Admin context to retrieve this SNMP data.
•CSCsl48103—When the ACE is configured for TACACS+ authentication with a user context and the Cisco ACS sends the cisco-av-pair* attribute before the ACE custom shell attribute, you cannot log in to the ACE via TACACS+ and use the Admin role. Workaround: Do not use the ACE TACACS+ authentication for an Admin role. If you must use TACACS+ authentication for an Admin role, do not configure the Cisco ACS to send the cisco-av-pair* attribute.
•CSCsl48846—With HTTP-cookie sticky configured, when the ACE parses the cookie value, the module occasionally rejects GETs from Internet Explorer (IE). The ACE sends a TCP RST to the client to close the connection and the Static Parse Errors counter in the show stats http command output increments for each RST sent by the ACE. The ACE does not reject GETs from Firefox. The difference between the two browsers is that IE sometimes sends a GET containing a cookie with the following form:
Cookie: COOKIE; COOKIE2=VALUE
^ Note that there is a space following the delimiting semicolon.
The ACE is configured to parse the value of COOKIE2 in the above cookie string.
You may observe this behavior only when you are using HTTP parsing of a cookie in which the above construct occurs. If the ACE is not performing cookie sticky or otherwise requiring that the cookie string be parsed, this type of traffic is not a problem. In that case, the ACE either routes or load balances the traffic, depending on your configuration.
Note that none of the following cookie constructs generates a RST:
Cookie: COOKIE1;COOKIE2=VALUE (no space following the delimiter)
Cookie: COOKIE1=;COOKIE2=VALUE (explicit equals; no space following the delimiter)
Cookie: COOKIE1=; COOKIE2=VALUE (explicit equals; space following the delimiter)
Workaround: Avoid the offending construct by using Firefox or use a non-Layer 7 load-balancing policy for this traffic.
•CSCsl50781—Configuration rollback may fail due to the banner message-of-the-day, which can result in an FT sync failure. This behavior can occur if the banner message-of-the-day text contains spaces along with quotes around the message text. For example, the following banner will fail rollback:
For example, the following banner message-of-the-day text may result in a configuration rollback failure:
switch/Admin(config)# banner motd "test banner"
However, a similar banner with the space removed will work correctly:
switch/Admin(config)# banner motd "testbanner"
Workaround: Avoid configuring the banner message-of-the-day text with spaces and quotes.
•CSCsl67984—A user context configuration is lost when a bulk config sync is triggered in the Admin context. This issue may occur under the following conditions:
–The Admin context is active on one peer and a user context is active on the other peer.
–You bring the FT VLAN down so that both the Admin and the user contexts enter the ACTIVE/STANDBY_COLD state.
–You make a change in the Admin context configuration on either ACE.
–You bring the FT VLAN back up, which triggers a bulk config sync for the Admin context.
Workaround: Configure both the Admin and the user context FT groups to be active on a single peer.
•CSCsl71709—When content with highly repetitive patterns are configured for compression by the ACE, the result may not be as optimal as when the ACE compresses content directly with gzip. The result could be small packets being sent on the network. A longer compressed payload can lead to noticeable extra latency in a WAN environment.
Workaround: There is currently no workaround to improve the compression ratio and address the resulting delay in WAN environment. The number of small packets can be reduced by turning on the TCP Nagle algorithm. You can enable Nagle's algorithm by using the nagle command in parameter map connection configuration mode. By default, this command is disabled.
•CSCsl72808—Microsoft Outlook Web Access (OWA) Gnome Evolution-Exchange sends TLS v1.1 in the initial Client Hello. Because the ACE does not support TLS Version 1.1, the ACE does not respond and the connection times out and terminates. Workaround: Clients connecting to the ACE should use TLS Version 1.0.
•CSCsl82712—When the ACE is configured for Layer 7 load balancing, an HTTP method request that exceeds the default (2000 bytes) or configured maximum HTTP header parse length is dropped and a TCP reset is sent to the client. Workaround: Increase the maximum HTTP header parse length in a parameter map using the set header-maxparse-length command.
•CSCsl87663—When FTP inspection is configured, the ACE permits the dynamically negotiated data channel to pass through bypassing the security checks based on ACLs. However, this bypass behavior applies incorrectly only to inbound ACLs configured on the ingress interface and not to any outbound ACLs configured on the egress interface. As a result, if the configuration has outbound ACLs that deny the data channel traffic, FTP connections will fail, despite the application inspection configuration. Workaround: Remove the outbound ACLs that deny the data channel traffic.
•CSCsl89772—With a UDP probe configured on port 69 (TFTP), the concurrent connections counter of the show resource usage command output keeps incrementing. Workaround: None.
•CSCsl95191—If you remove a service policy (either globally or from an interface) and then re-add it or if you remove a NAT pool from an interface and then re-add it, some of the NAT fabric entries are lost. Workaround: Remove the relevant class map and the policy map and then re-add them to the configuration.
•CSCsl95565—When you are using SNMP with notifications enabled in multiple contexts and redundancy is configured, the standby ACE may reboot with a last reboot reason of service snmpd. When the ACE comes back up, it may be in an odd state with some of the contexts not functioning properly. Workaround: None.
•CSCsl99468—Clients who connect through the ACE using the default set tcp buffer-share size and set ack-delay values (32 KB and 200 ms, respectively) may experience a slow response time. Approximately 95 percent of the responses are returned in 30 to 40 ms. However, the remaining 5 percent of responses are returned in approximately 250 ms.
Workaround: You can minimize (but not eliminate) the percentage of delayed packets by increasing the TCP buffer-share size. You can minimize the delay lengths by decreasing the TCP ACK delay value. Because each situation is affected by different variables, the best values for the set tcp buffer-share and the set ack-delay commands need to be determined by testing response times with various values.
You can reduce some of the delay by allowing the TCP window to continuously update and send a window update when the window size is below 1 maximum segment size (MSS) rather than when the window size reaches 0. You can reduce additional delay by changing the ACE behavior so that an ACK is not delayed if the unupdated window size is below 2 MSS rather than waiting for the window update. This action prevents a latency if the unupdated window is below 2 MSS and the updated window is above 2 MSS.
•CSCsm03018—When you enable logging for syslog message IDs 302022 to 302025, changing the logging level for syslog messages 302022 to 302025 from Level 6 to Level 4 also affects the logging level for messages 302028 to 3020311. Logging rate limiting does not work for message IDs 302028 to 302031 and you cannot change the logging level for messages 302028 to 302031directly because these syslogs are not supported by the relevant CLI commands. Workaround: None.
•CSCsm10390—An ACE process produced a core dump, but the compressed core dump file was not saved in the core: directory for analysis. When the ACE was reloaded, the generated core file was lost, leaving no way to analyze the problem that caused the reload. This behavior was a single occurrence that may be related to a previously failed ephemeral process such as a script or a shell invocation that had occurred over the previous several months of uninterrupted operation of the ACE module. Workaround: None.
•CSCsm10896—Enabling the persistence rebalance command while a server farm is configured with any of the hash-based load-balancing predictors may cause the ACE to ignore the hash-based predictor after the first HTTP GET request. Instead, the ACE continues to load balance requests to the same real server that it previously selected if the requests match the same Layer 7 policy. Otherwise, the ACE load balances requests to a new real server in the server farm. Workaround: None.
•CSCsm16881—A configuration that includes HTTP persistence rebalance, sticky, and application acceleration may result in an unexpected redirection of multiple packet requests from the client side. For example, for two consecutive GET requests to the same connection, with persistence rebalance enabled, the first GET request is to be directed to the real server on the ACE and the second GET request is to be sent to the application acceleration module on the ACE. In this case, the two consecutive messages are sent to the real server because the ACE does not properly reuse the back-end connection. As a result, the second GET request is not sent to the application acceleration module.
•CSCsm17268—In a redundant configuration, when you add a single line to an existing config (for example, Admin(config)# snmp community public ro) and the ACE performs a subsequent incremental synchronization, the snmp community command appears in the running-config on the peer, but the process seems to cause an internal failure, that makes the peer transition to the STANDBY_COLD state. The running-config sync status is reported as Peer in Cold State. Incremental Sync Failure: snmp config sync to sby failed. Workaround: If possible, avoid the use of the snmp command while this behavior is under investigation.
•CSCsm18847—If you change the logging level for syslog messages 302028 to 302031 when they are enabled using the logging fastpath command, the ACE still uses level 6 to rate-limit these syslogs. Workaround: None.
•CSCsm21677—Crypto information may be missing from the show tech-support command output. Workaround: Use the different show crypto commands to display the summary and detailed reports on files containing SSL certificates, key pairs, and chain groups.
•CSCsm37228—After executing TACACS related commands on the active ACE in a redundant configuration, the TACACS+ process fails on the standby device (both contexts), resulting in an ACE reload. Workaround: None.
•CSCsm40004—When you are creating a certificate signing request (CSR) at the ACE CLI using the csr-generate command, you cannot use the space character in the State value. Workaround: Use the state abbreviation.
•CSCsm46153—The ACE fails to forward IP fragments that are greater than 68 bytes in length if this fragment is not the last fragment. Workaround: None.
•bCSCsm52480—All IPv6 multicast packets are dropped even though the ACE module is configured as follows:
access-list acl_name ethertype permit ipv6
This symptom occurs only with IPv6 multicast packets. It does not occur with IPv6 unicast packets. Workaround: None.
•CSCsm60573—The Cavium Networks OCTEON network processor in the ACE requires a set of pass 3 changes as recommended by Cavium Networks. Workaround: None.
•CSCsm60918—The show hardware command in Exec mode displays the following system hardware information in the output:
switch/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: 1234567890
The following system hardware additions to the show hardware command output have been implemented:
switch/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: 1234567890
MFG Part Num: abcdefghijkl
•CSCsm67051—If you are using application accleration, when the server closes the connection with a FIN (Finish), in some instances the ACE may close the server side connection but keeps the client side connection open for approximately 10 seconds. If a client sends a new HTTP request during those 10 seconds, this can result in the generation of an HTTP error message. Workaround: Setup the server not to initiate a close connection.
•CSCsm68031, CSCsm74832—If you are using application acceleration and you have FlashForward enabled, when you make indirect requests to the VIP, the connection may be reset (RST) after the second request. The FlashForward function may not work properly. Workaround: None.
•CSCsm77269—A portion of the policy-map section of the running-config file may disappear from the file without you performing any other manual configuration activities. If this behavior occurs, and you attempt to readd the configuration, the following error may appear:
switch/Admin# (config)# policy-map multi-match TCP-requests
switch/Admin(config-pmap)# class ATLAS-VIP-TCP Error: Unable to add object. Possibly
exceeded max configurable object limit!
switch/Admin(config-pmap)#
Workaround: Enter the reload command to reboot the ACE to clear this behavior and resume operation.
•CSCsm83733—When you are using the ACE appliance Device Manager GUI, and you select Admin > Role-Based Access Control > Active Users to view a list of the users currently logged into the ACE, in some cases, the Device Manager GUI displays the following error message: "The element type "users_user" must be terminated by the matching end-tag "</users_user>"." As a result, the Device Manager GUI is unable to display a list of active users. Workaround: Establish a direct serial connection between your terminal or a PC and the ACE and log in to ACE through the console port. This action removes the error condition from the Device Manager GUI and allows you to view a list of active users.
•CSCsm89594—The XML output is not properly formatted for the following show commands: show ft stats, show ft track 1 detail, show ft track 1 summary, show ft track 1 status, show tacacs-server sorted, show running-config policy-map, show running-config probe, show serverfarm sf1 detail, and show rserver detail. Workaround: None.
•CSCsm90293—With an SMTP probe configured on the ACE, a new mail server rejects the probe as syntactically invalid because of the use of an underscore (_) that breaks the new rules in RFC 2821 and causes the probed server to never becomes active.
The probe configuration is as follows:
description Generic SMTP application
This behavior is not observed with older mail servers that still adhere to or permit the SMTP command arguments accepted by RFC 821. Workaround: None.
•CSCso02922—If the disk0: directory of the Admin context consumes all the ACE flash disk space, an SSL certificate cannot be imported into a user context. As a result, some of the directories that are needed for a context to work cannot be created.
Workaround:
1. Free up some flash disk space by deleting unnecessary files in the disk0: directory.
2. Remove and readd the context that was impacted.
•CSCso03244—When operating the ACE with application acceleration, when a default class is used as the match criteria in an optimization policy, traffic is not processed for the application acceleration. For example, this behavior may be observed when the following class-default configuration is used in an HTTP optimization policy:
host1/Admin(config)# policy-map type optimization http first-match Rewrite_Policy
host1/Admin(config-pmap-c)# class class-default
host1/Admin(config-pmap-optmz-c)# action HTTP-HTTPS-Rewrite
Workaround: To resume forwarding and processing traffic for application acceleration, modify the above configuration as follows:
host1/Admin(config)# class-map type http loadbalance match-all CM-LB
host1/Admin(config-cmap-http-lb)# 2 match http url .*
host1/Admin(config)# policy-map type optimization http first-match Rewrite_Policy
host1/Admin(config-pmap-c)# class CM-LB
host1/Admin(config-pmap-optmz-c)# action HTTP-HTTPS-Rewrite
host1/Admin(config-pmap-optmz-c)# exit
host1/Admin(config-pmap-c)# class class-default
host1/Admin(config-pmap-optmz-c)# action HTTP-HTTPS-Rewrite
•CSCso12722—When you configure the ACE for SSL termination and a client sends a POST request, the request does not fully traverse the ACE to the real server. This behavior results in a timeout from the real server, which is waiting for the rest of the POST. Workaround: None.
•CSCso15818—Users that are properly defined in a TACACS+ or RADIUS server are unable to log to the ACE appliance Device Manager GUI. Those same users do have the proper authorization to log in to the ACE appliance from the CLI. This behavior may be related to how the Device Manager GUI verifies the role and domain for remote users. Workaround: None.
•CSCso20415—After you import into an ACE context a certificate containing the special character ampersand (&) in any of the fields of the certificate subject, the synchronization between the ACE and ANM for that context fails. This behavior is caused by the ACE XML response to the show crypto certificate command's not translating the special reference "&" to the corresponding escape character "&". The error causes ANM to display the following error message:
Device discovery failed: Exception occurred for model:CryptoCertificateModel The
entity name must immediately follow the '&' in the entity reference.
Workaround: None.
•CSCso28789—A syslog server that is receiving messages from the ACE fails to display messages that are formatted incorrectly. A few ACE syslog messages are missing a colon after the syslog message ID number. An example of an incorrectly formatted message is as follows:
%ACE-3-251008 Health probe failed for server....
The format should include a colon after the ID number as follows:
%ACE-3-251008: Health probe failed for server....
Workaround: View the local syslog buffer on the ACE by using the show logging history command.
•CSCso34171, CSCsl77474—Configuring the shared-vlan-hostid 16 command causes any interfaces configured on shared VLANs using that ID to become unreachable. These interfaces are in the various user contexts on the ACE, and failing traffic includes ARPs, probes, and so on. In this case, the interface address becomes completely unreachable. Any interface created on a shared VLAN while the shared-vlan-hostid 16 command is enabled is also unreachable. The show arp command displays a MAC address of 00:12:43:dc:ab:00 or higher on such interfaces. Workaround: Do not configure the shared-vlan-hostid 16 command. You can use any of the other available host IDs (1 through 15) for the shared-vlan-hostid command.
The ACE randomly assigns a host ID to shared VLANs if you do not configure a host ID. The ACE never chooses a host ID of 16 when performing this random assignment. You will observe this behavior only if you configure the shared-vlan-hostid 16 command on your ACE.
•CSCso41908—After rebooting the ACE, you may find that the ACL merge list for one of the VLAN interfaces may not be present. As a result, all traffic coming in on that interface is denied. Workaround: Apply the context config after the ACE boots up.
•CSCso45260—If you attempt to troubleshoot a TACACS+ problem directly within a user context, you may find that the associated TACACS+ debug log messages are not displayed on either the console or Telnet session. Workaround: Use the tacacs debug mode commands only in the Admin context.
•CSCso46209—When you attempt to configure an LDAP server, errors may result. For example, consider the following configuration:
switch/Admin(config)# ldap-server host 10.86.215.90 rootDN "cn=admin,dc=cisco,dc=com"
password 7 abc0123 port 389 timeout 45
When you display the configuration in the running-configuration, it appears incorrectly as follows:
switch/Admin# show running-config
ldap-server host 10.86.215.90 rootDN "cn=admin" password dc=cisco dc=com port 7
timeout abc0123
LDAP functions as intended and the LDAP server configuration appears correctly as follows:
total number of servers : 1
following LDAP servers are configured:
timeout: 45 port: 389 rootDN: cn=admin,dc=cisco,dc=com
In a redundant configuration, configuration synchronization may not complete properly. After a reboot, the ACE may not be able to reapply the LDAP configuration and may produce an error similar to the following:
ldap-server host 10.86.215.90 rootDN "cn=admin" password dc=cisco dc=com port 7
timeout abc0123`
*** Context 0: cmd parse error ***
This behavior may result in the secondary ACE entering the STANDBY_COLD state.
Workaround: To recover from this state, perform the following steps:
a. Enter the no ft auto-sync running-config command to disable auto synchronization.
b. Manually remove the LDAP configuration lines, described earlier.
c. Reenable auto synchronization by entering the ft auto-sync running-config command. The secondary ACE should enter the STANDBY_HOT state after the synchronization completes.
To avoid this behavior, use one of the following workarounds if possible:
•Use a rootDN with only a single domain component.
•Avoid using the LDAP feature in ACE software releases that exhibit this behavior.
•CSCso68175—When you use the ACE appliance Device Manager GUI to configure a Layer 7 server load-balancing class map within a virtual server (Config > Virtual Contexts > context > Load Balancing > Virtual Server), and you specify match-all as the match condition, the ACE selects match-any. Workaround: None.
•CSCso74865—If you make load-balancing-related configuration changes (for example, changing the server farm predictor or configuring real server connection limits), the load-balancing (LB) process may fail while it is processing a list related to keeping track of real servers that are currently not used in the LB decision. You may also observe this behavior when a real server goes into or out of the MAXCONNS state. Workaround: None.
Software Version A1(8.0) Open Caveats
The following open caveats apply to ACE software version A1(8.0).
•CSCse85906—In a redundant configuration, persistent connections established through an ACE context may become unresponsive after a switchover occurs. Workaround: None.
•CSCsg95099—When you configure SNMP notification using the ACE appliance Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. Note that this information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > Sync or Sync All.
•CSCsh89272—When you are using the ACE appliance Device Manager GUI to develop or modify a policy map in Expert configuration mode (Expert > Policy Map), after you insert a new class map or match condition before existing class map or match condition, a wrong action list appears under the newly added class map or match condition. As a result, if you add a new action to this list, it will be associated with wrong class map or match condition. This behavior will occur when you add a policy map Rule (class map or match condition) in Expert configuration mod, and you have added at least one action under that Rule. This issue can appear whenever you use the Insert Before feature from the Device Manager GUI, and it is applicable to all policy map types.Workaround: Perform the following procedure to prevent this issue from occurring when you use the Insert Before function:
a. After you insert the new class map or match condition before the existing rule, click the Rule tab. The Rules table appears.
b. Select the newly added rule. An empty action list appears for that rule.
c. Add one or more actions to this rule.
•CSCsh95585—When multiple virtual servers (class maps) are using the same IP address with different ports and the VIP must be pingable when it is active, you must configure the loadbalance vip icmp-reply active command for all virtual servers that share the same VIP. If you have multiple class maps with the same IP address and configure the loadbalance vip icmp-reply active command only under some of them, the ACE may not respond at all, even if the virtual servers that are configured with the loadbalance vip icmp-reply active command are alive. Workaround: All virtual servers that use the same IP address must have the loadbalance vip icmp-reply active command configured.
•CSCsh96086—The Device Manager GUI fails to add real servers to custom domains on the ACE appliance. In this case, a real server that you create in a custom domain in the Device Manager appears in the default-domain on the ACE appliance. This behavior occurs because the real server is deployed to the CLI using the Admin credentials and is created in the default-domain only.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Admin > Role-Based Access Control > Domains > Add.
2. Create a domain.
3. In the Domain Object subtable, add a real server.
4. Select Admin > Role-Based Access Control > Roles > Add.
5. Create a new role.
6. In the Rule subtable, add entries that grant Permit permission for Create, Debug, Modify, and Monitor operations for the real server.
7. Select Admin > Role-Based Access Control > Users > Add.
8. Add a user, assigning the role and domain created in Steps 2 and 5.
9. Log into the Device Manager as the new user.
10. Select Config > Virtual Contexts > Load Balancing > Real Servers > Add.
11. Add a real server.
12. Using the CLI, verify that the real server is created on the ACE appliance. The real server is created on the ACE appliance but is added to default-domain instead of the user domain.
Workarounds:
–Using the CLI, add objects to a user-defined domain.
–Using the Device Manager, select the affected context (Config > Virtual Contexts), and click Sync.
•CSCsi19809—When you use the Device Manager GUI to import an ACE appliance license, the Device Manager does not display a confirmation message before overwriting an existing license.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > System > Licenses, and click Import License.
2. In the Import License File dialog box, enter the information, then click OK.
3. Import the same license using the same destination. No message appears to indicate that this action will overwrite an existing license, and the first license is overwritten with the second.
Workaround: Do not reimport an existing license.
•CSCsj64833—The network utility traceroute does not work for a configured ACE IP interface if the underlying protocol is UDP or TCP. Workaround: ICMP traceroute will work. The default of most traceroute utilities is UDP so a command line option might be necessary. For Linux, use the -I option.
•CSCsj68643—The following log messages may appear sporadically in the ACE log:
–can_wait_specific_msg: Aborting call (SAP 27, pid 959). Another thread is also waiting for a specific msg.
–can_wait_specific_msg: Aborting call (SAP 27, pid 905). Another thread is also waiting for a specific msg.
These messages do not impact the operation of the ACE. The messages may be caused by more than one device accessing the ACE context through XML. Workaround: None.
•CSCsj70522—In a redundant configuration with multiple contexts and logging enabled for the console and the buffer on both ACEs, log messages appear only on the standby console when a probe to a server fails. No new messages are observed in the buffers on either ACE. After entering the changeto command to another context and then back to the original context, log messages appear on the active ACE console, but the log buffer is not updated. Workaround: None.
•CSCsj80265—With the ACE configured for TACACS+ authentication and SSHv1 management access and the SSH keys generated in RSA1 format, SSH fails to authenticate a user because of a bad password when you attempt to connect to the ACE using an SSH client. You can connect to the ACE using Telnet and the session works. If you Telnet to the ACE with the same credentials (username and password) that you attempted to use with SSH, and then subsequently try to connect to the ACE using SSH, the SSH session is established. Workaround: Use SSHv2 to connect to the ACE by generating the SSH key in an RSA format instead of an RSA1 format. For example, enter the following CLI command: ssh key rsa 1024 force.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCsl09286—When you use the ACE appliance Device Manager GUI to configure an HTTP cookie sticky connection for a sticky group and you enable cookie insertion, the Device Manager does not support the configuration of the client's browser to expire a cookie when the session ends. The browser-expire field in missing as a sticky group attribute.
You can enable cookie insertion in the following Device Manager screens:
–Config > Virtual Contexts > Load Balancing > Stickiness > Add or Edit
–Config > Virtual Contexts > Load Balancing > Virtual Servers > L7 Load-Balancing
–Config > Virtual Contexts > Load Balancing > Virtual Servers > Default L7 Load-Balancing Action
Workaround: To allow a browser to expire the cookie when the session ends, use the optional browser-expire keyword of the cookie insert CLI command in sticky-cookie configuration mode. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl74755—ACE sockets may become depleted when you repeatedly (approximately 250 attempts) access the ACE using SSH. For example, entering the ssh admin@192.168.1.123 sh ver command may cause the ACE to generate the following message to the client:
Received disconnect from 192.168.1.123: 2: Could not create socket pairs: Too many
open files in system.
In some cases, this condition generates the following message on the ACE console:
socket: Limiting socket usage, no more sockets, Max allowed is 512 and current_usage
is 512
Workaround: Avoid excessive SSH logins. After the condition occurs, you must reboot the ACE to clear the resource depletion. No other workaround is currently available.
•CSCsm43859, CSCso32175—If you enable the logging of syslog messages during console sessions and you set the severity level to 6 (Information messages) or 7 (Debug messages), this deletion may result in the generation of a large number of syslogs that can overload the syslogd as it attempts to process these messages. When this occurs, the ACE may appear to be unresponsive.
Workaround: If you must use logging of syslog messages during console sessions with a message severity level of 6 or 7, perform one of the following actions:
–Enter the logging fastpath command to enable the logging of connection setup and teardown messages at a faster rate (that is, at the connection rate).
–Enter the logging rate-limit command to limit the rate at which the ACE generates messages in the syslog.
•CSCsm56713—The ACE appliance Device Manager GUI Primary Attributes page (Config >Virtual Contexts > System > Primary Attributes) may be missing some of the mandatory fields, such as the VLAN to Use, Management IP, and Management Netmask fields. This issue can occur when you partially configure a management interface (VLAN, IP address, policy, and so on) from the ACE CLI. After you synchronize the configuration for the selected virtual context on the Device Manager, you may notice the missing IP address on the Primary Attributes configuration screen.
You may encounter this issue when a management interface is not fully defined as shown in the example below. In this example, the IP address is missing:
service-policy input remote_mgmt_policy
Note that you can have multiple management interfaces defined with at least one fully defined and functional interface so that the ACE and the Device Manager are still reachable and configurable. For example:
service-policy input remote_mgmt_policy
ip address 172.20.28.43 255.255.255.128
service-policy input remote_mgmt_policy
In this case, after synchronization is completed, the Device Manager chooses the first interface, instead of the first fully defined interface, and displays the attributes on the Primary Attributes configuration screen.
Note As long as there is at least one working management interface on the ACE appliance, you will be able to successfully access the ACE CLI and the Device Manager GUI.
Workaround: To resolve this issue, perform the following actions:
1. Add the missing CLI commands on a partially defined interface and verify that the interface is functional.
2. From the Device Manager GUI, use the Sync function (Config > Virtual Contexts) from the All Virtual Contexts table to synchronize the CLI configuration.
•CSCsm60957, CSCsl13788—You are running the ACE appliance Device Manager GUI in the Internet Explorer 6.0 web browser and you attempt to use the Device Manager to add a new ACL to the ACLs table (Config > Virtual Contexts > context > Network > VLAN Interface). The "error on this page" message appears at the bottom of the Internet Explorer 6.0 web browser and the ACL table fails to appear in the Device Manager GUI.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > context > Network > VLAN Interface. The VLAN Interface table appears.
2. Add a new VLAN or select an existing VLAN.
3. Select the VLAN interface that you want to associate with an ACL, and then select the Access Group tab. The Access Group table appears.
4. Click Add to associate a new ACL with the selected VLAN interface. The Access Group configuration screen appears.
5. Click the + icon to the left of the ACL Name field to add a new ACL into the ACL table. The "error on this page" message appears at the bottom of the Internet Explorer 6.0 web browser and the ACL table fails to appears in the Device Manager GUI.
Workaround: Use the Firefox 2.0 web browser instead of the Internet Explorer 6.0 web browser to run the Device Manager GUI, and add a new ACL from the Access Group tab as described in the above procedure.
If you want to use the Internet Explorer 6.0 web browser, perform the following procedure:
1. Select Config > Virtual Contexts > context > Security > ACLs and add a new ACL from the ACL configuration screen.
2. Select Config > Virtual Contexts > context > Network > VLAN Interface. The VLAN Interface table appears.
3. Select the VLAN interface that you want to associate with an ACL, and then select the Access Group tab. The Access Group table appears.
4. Click Add to associate a new ACL with the selected VLAN interface. The Access Group configuration screen appears.
5. Select the ACL entry added in Step 1 from the drop-down list.
6. Continue with the remainder of the configuration.
•CSCsm85882—The ACE may not automatically send gratuitous ARP packets when you either reload the appliance or specify the shutdown and no shutdown command sequence to change the state of a physical Ethernet interface. This behavior may occur when you connect the ACE directly to a Catalyst 6500 Series Switch. However, when you connect the ACE to a Linux host or to traffic testing equipment, gratuitous ARP packets are received without problem. If you connect an ACE to a Catalyst 6500 series switch, your configuration on the Catalyst may include the Spanning-Tree Protocol (STP). However, the ACE does not support STP. In this case, you may find that the Layer 2 convergence time is much longer than the physical port up time. During this period, any packet, including gratuitous ARP packets, will be dropped by the Catalyst. Workaround: With A1(8.0), the carrier-delay command allows you to add a configurable delay at the physical port level to address this transition time, based on the variety of peers. See the "Software Version A1(8.0) Command Changes" section.
•CSCso18391—When you perform a checkpoint rollback and enter the no nat dynamic n vlan nnn CLI command, the ACE displays the following messages:
Generating configuration....
Errors while applying diff, please see log below.
policy-map multi-match xxxxx
no nat dynamic 1 vlan 150
Error: Called API timed out
This behavior appears to be related to larger configurations with many regular expressions (regexes). Workaround: Enter the no nat dynamic command before you perform the rollback operation.
•CSCso21265—If you use the ACE appliance Device Manager GUI to remove the primary real server from a server farm (Config > Virtual Contexts > context > Load Balancing > Server Farms), in some cases, the ACE fails to remove the backup real server. In the Device Manager, the Real Servers table is empty. However, if you verify this removal from the ACE CLI by using the show serverfarm command, you will observe that only the primary real server has been deleted. Workaround: Use the ACE CLI to remove the primary real server from a server farm (see the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide).
•CSCso22472—When you use class maps of type http loadbalance match-any to select a server farm and some of these class maps are empty, the ACE may make an incorrect load-balancing (LB) decision. This incorrect LB decision causes unexpected LB results. For example:
class-map type http loadbalance match-any A
2 match source-address 192.168.1.1 255.255.255.255
class-map type http loadbalance match-any B <<< empty
2 match virtual-address 192.168.1.10 tcp eq telnet
policy-map type loadbalance first-match LB
Workaround: In the above configuration, you must add a dummy match statement under class map B. For example:
class-map type http loadbalance match-any B
2 match source-address 172.16.27.5 255.255.255.255
•CSCso25654—With the UDP probe interval set to 2 seconds, UDP probes take longer than expected to enter the failed state. Workaround: Use a time interval that is greater than or equal to 5 seconds for UDP probes.
•CSCso33364—When you use the ACE appliance Device Manager GUI to modify the port number of a virtual server that is associated with an application protocol inspection function (Config > Virtual Contexts > context > Load Balancing > Virtual Server), the Device Manager may display the following message:
Infringing CLI command: no 2 match virtual-address tcp eq with reason: Error: Cannot
delete this object as this is referenced by inspect action.
Workaround: Perform the following procedure in the Device Manager GUI to modify the port number of a virtual server:
1. Select Config > Virtual Contexts > context > Load Balancing > Virtual Server. The Virtual Servers table appears.
2. Click Edit to modify the existing virtual server.
3. Access the Advanced View properties.
4. If necessary, document the current application protocol inspection settings that you currently have enabled as the virtual server properties.
5. Disable application protocol inspection, then click Deploy Now.
6. Edit the virtual server properties in the Advanced View with the desired port number and reenable application protocol inspection.
7. Click Deploy Now to deploy the configuration on the ACE.
•CSCso33371—When you use the ACE appliance Device Manager GUI to define the SSL Initiation and Insert HTTP Headers values for Layer 7 server load-balancing in a virtual server (Config > Virtual Contexts > context > Load Balancing > Virtual Server), and you enable HTTP compression, the ACE may fail to configure the SSL initiation and HTTP header insertion functions. Workaround: Configure the SSL Initiation and Insert HTTP Headers values in a Layer 7 policy map using the Expert configuration options (Config > Virtual Contexts > Expert > Policy Map) prior to enabling Layer 7 server load balancing (including HTTP compression) in a virtual server.
•CSCso52092—If the combined permanent storage of the core:, disk0:, and image: file systems is full, the ACE may become unresponsive after several hours. Workaround: Ensure that the flash memory storage is not full, and that the usage is kept to a minimum. Use the appropriate dir command to display the contents of a specified ACE file system (core:, disk0:, or image:) and review the value in the Bytes Free field.
•CSCso63101—In some cases, when performing RTSP application inspection, the Windows Media Player may send a FIN message after receiving the RTSP/SDP reply for the Describe request. This behavior can be due to the Content-Length value in the RTSP/SDP reply to Describe request is not updated correctly by the ACE even though the real server IP to VIP address translation is performed correctly in the SDP body. The issue is specific to Windows Media Player. The Windows Media Player sends "a=control:rtsp://<url>/....." in the SDP which results in the ACE performing a application inspection fixup of the URL but not performing a fixup of the content length since it was treated as the part of control_base header. If the size of the VIP address and real server IP address is the same, the ACE will not encounter this issue since content-length update is not required. Workaround: None.
•CSCso63218—Some configuration CLI commands may partially or completely fail to synchronize to the standby ACE when one appliance is running version A1(7x) and the other ACE is running version A1(8.0). This behavior may exhibit itself during the software upgrade or downgrade procedure between the A1(7x) and A1(8.0) images.
On an upgrade where the active ACE is running version A1(7x) and the standby ACE is booted with the A1(8.0) image, the configuration and connection replication will be replicated in bulk from A1(7x) to A1(8.0). The issue is that there is a problem with incremental configuration synchronization. Certain commands have been identified to fail if they are incrementally synchronized from the active ACE running version A1(7x) to the standby ACE running version A1(8.0). The commands that fail in this manner can, but are not necessarily limited to, the following commands: access-list, action-list type optimization http, parameter-map type http, parameter-map type optimization, policy-map (of all types), and sticky ip-netmask.
Workaround: When you upgrade from A1(7x) to A1(8.0), before you run any configuration commands in a context, enter the no ft auto-sync running-config command in the context which is about to undergo changes. When the changes are complete, enter the ft auto-sync running-config command in that context.
We recommend that you immediately initiate a failover to the new ACE after the bulk configuration synchronization occurs and the FT group is in ACTIVE/STANDBY_HOT state. We do not recommend that you enter any new configuration command on the ACE that is running version A1(7x) in this configuration. After you initiate a failover to version A1(8.0), be sure to immediately upgrade the other ACE to A1(8.0) as well. See the "Upgrading Your ACE Software from A1(7x) to A1(8.0x) in a Redundant Configuration" section.
During a downgrade where the active ACE is running version A1(8.0) and the standby ACE is booted with version A1(7x), configuration synchronization is disabled. The configuration will not be synchronized from the active ACE running A1(8.0). The ACE that is running version A1(7x) will apply its startup- config upon bootup, at which time only the A1(7x) configurations will be recognized. Configuration synchronization is disabled between active ACE running version A1(8.0) and the standby ACE running version A1(7x) because the A1(8.0) configurations relate to the new features in the A1(8.0) release and will not be understood by the ACE running the A1(7x) release. See the "Downgrading Your ACE Software from Version A1(8.0x) to A1(7x) in a Redundant Configuration" section.
•CSCso66799—If you configure the same IP address with different ports on multiple class maps and your application requires that the VIP is pingable when it is active, you must configure the loadbalance vip icmp-reply active command under all class maps that share that same VIP. If you have multiple rules with the same IP address and you configure the loadbalance vip icmp-reply active command only under some of the class maps in a policy map, the ACE may not respond at all even if the VIPs configured with the loadbalance vip icmp-reply active command are alive. Workaround: Configure the loadbalance vip icmp-reply active command under all class maps that have the same IP address in a policy map.
•CSCso68167—The ACE allows you to designate an Ethernet port or a port-channel interface to carry the FT VLAN dedicated for redundancy. The FT VLAN must be configured on the Ethernet port or the port-channel interface using the ft-port vlan command. Do not configure the FT VLAN on the Ethernet port or port-channel interface using the switchport access or switchport trunk commands to avoid the following performance issues:
–Redundancy performance drops in heavy traffic.
–During the standby state, the FT VLAN between the redundant peer may be temporarily disconnected as a result of the physical port on the standby ACE entering the shutdown and no shutdown states.
Workaround: To prevent these issues, use only the ft-port vlan command to associate the FT VLAN with a dedicated physical Ethernet port or a port-channel interface on the ACE.
•CSCso73385—With inspect ftp configured on a policy map, the ACE resets the FTP connection of traffic that matches the policy after it sends an extended PASV (EPSV) command to the FTP server. Workaround: None.
•CSCso77018—When you use the ACE appliance Device Manager GUI, and you attempt to define a custom application acceleration configuration for Layer 7 server load-balancing for a virtual server (Config > Virtual Contexts > context > Load Balancing > Virtual Server), the Device Manager may be unable to retain the association that you make between a Rule Match and an associated Action. When this behavior occurs, after you specify the Rule Match and associated Action, the Actions field is blank. Workaround: Click Edit and manually select the appropriate action from the Actions drop-down list.
•CSCso79559—When you use the ACE appliance Device Manager GUI to edit existing match conditions for an HTTP deep packet inspection class map using the Expert configuration option, the ACE appliance may display an error message indicating "line number already exists".
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > context > Expert > Class Map. The Class Map table appears.
2. Add a class map.
3. Select Layer 7 HTTP Deep Packet Inspection.
4. Select Match-any or Match-all.
5. Click Deploy Now.
6. Add a match condition.
7. Select type as Content.
8. Click Deploy Now.
9. Edit the same match condition.
10. Change the type to any of the following:
–Header-mime-type
–Port-misuse
–Request-method
–Transfer-encoding
–Url
–Url-length
The ACE appliance may return an error indicating "line number already exists" because the ACE appliance CLI does not contain the appropriate no form of the command to remove the existing match condition before adding the new match condition.
Workaround: Perform the following procedure in the Device Manager GUI to modify the HTTP deep packet inspection match conditions:
1. Select Config > Virtual Contexts > context > Expert > Class Map.
2. In the Match Conditions table for the Layer 7 HTTP Deep packet Inspection class map, delete the match condition.
3. Click Deploy Now.
4. Select Config > Virtual Contexts > context > Expert > Class Map.
5. Create the new match condition.
6. Click Deploy Now.
•CSCso93610—When you use the ACE appliance Device Manager GUI to configure a virtual server (Config > Virtual Contexts > Load Balancing > Virtual Server), the Device Manager will not recognize the ICMP Reply setting if you specify the primary-inservice option. When you edit the virtual server, you may notice that None is displayed as the ICMP Reply for this virtual server. The Device Manager does not affect the current configuration for the ICMP Reply setting as long as the value is unchanged. If you use the Expert configuration screen, the ICMP Reply value will not display if it is set to primary-inservice. Adding a ICMP Reply will silently overwrite the ICMP Reply setting. Workaround: Leave None as the ICMP Reply setting for the virtual server if you configure ICMP Reply primary-inservice from the CLI.
•CSCso94404—When you configure 12 or more user contexts with application acceleration enabled in all user contexts, you may notice that the VIP addresses of user contexts 14 and higher will not accept traffic. If you make configuration changes from the ACE CLI, the following error message may appear:
%ACE-3-729001: Regular expression config download failed due to out of memory. No
regexp rules are currently applied on class-map LB-VIP in service-policy PoM-L47.
Manual roll back to a previous regexp configuration on this service-policy is needed.
Workaround: None.
•CSCsq02433—In rare cases, the configuration manager in the ACE may initiate a core dump when you configure the match http header header-value command in class map HTTP load balancing configuration mode or policy map load balancing configuration mode. This behavior may occur as a result when the header name string is at the end of page in memory. The following illustrates a typical system message that may display when this issue occurs:
Apr 4 2008 08:28:24 Admin: %ACE-2-443001: System experienced fatal failure.Service
name:cfgmgr(928) has terminated on receiving signal 11,reloading system
Service name:cfgmgr(928) has terminated on receiving signal 11
6K-1_ACE2-1 login: dir coApr 4 2008 08:28:45 Admin: %ACE-2-443001: System experienced
fatal failure.Service name:cfgmgr(928) crashed, last core saved,reloading system
Workaround: None.
•CSCsq08718—In a redundant configuration, the ACE may experience intermittent reboots when you enter the ft switchover command to force a switchover. This behavior typically occurs in the load balancer process of the ACE when you configure the leastconns load-balancing (predictor) method predictor and when you configure the maxconn connection limit for a real server in a server farm. Workaround: With the leastconns predictor configured, attempt to slowly perform the FT switchover process.
•CSCsq08747—The ACE may encounter dataplane problems and reboot while you are configuring connection limit on one or more real servers. This intermittent rebooting behavior may occur when you attempt to configure a connection limit on real servers and traffic is running in the background at a high rate (more then 10K TPS). Workaround: Do not change the connection limit on the real servers while traffic is running in the background.
•CSCsq06148—With IP sticky and HTTP compression, enabled, the ACE may experience a memory buffer leak while traffic is running. This issue can occur when the server is sending an HTTP 408 request timeout response code; it does not happen for the other response messages. Workaround: Try to avoid having the server send an HTTP 408 response code when you enable IP sticky and HTTP compression in the ACE.
•CSCsq11239—The ACE may encounter dataplane problems and reboot when you are making a configuration rollback change. This behavior can occur when you attempt a rollback from a IP sticky to a non-IP sticky configuration and traffic is running in the background at a rate more then 10K TPS with more then 100 IP clients. Workaround: Ensure that traffic is not running when you perform a rollback change from a IP sticky to a non-IP sticky configuration.
•CSCsv95366—When you use the ACE appliance Device Manager GUI, in some instances after you login to the Device Manager you may encounter a blank page. Workaround: Enter the reload command in Exec mode to reboot the ACE.
Software Version A1(8.0) Command Changes
Table 5 lists the commands and options that have been added in software version A1(8.0).
Table 5 CLI Commands Added in Version A1(8.0)
Mode
|
Command and Syntax
|
Description
|
Exec
|
clear serverfarm name [retcode]
|
Resets all HTTP return code (retcode) statistics to zero for the specified server farm.
|
Interface configuration mode
|
carrier-delay seconds
|
If you connect an ACE to a Catalyst 6500 series switch, your configuration on the Catalyst may include the Spanning-Tree Protocol (STP). However, the ACE does not support STP. In this case, you may find that the Layer 2 convergence time is much longer than the physical port up time. For example, the physical port would normally be up within 3 seconds, but STP moving to the forward state may need approximately 30 seconds. During this transitional time, although the ACE declares the port to be up, the traffic will not pass.
With A1(8.0), the carrier-delay command allows you to add a configurable delay at the physical port level to address this transition time, based on the variety of peers. The seconds argument specifies the carrier transition delay in seconds. Valid values are 0 to 120 seconds. The default is 0 (no carrier delay).
|
Parameter map SSL configuration mode
|
authentication-failure ignore
|
Enables the ACE to ignore expired or invalid server certificates and to continue setting up the back-end connection in an SSL initiation configuration. This command allows the ACE to ignore the following nonfatal errors with respect to server certificates:
•Certificate not yet valid
•Certificate has expired
•Unable to get issuer certificate
•Certificate revoked
|
Table 6 lists the commands and options that have changed in software version A1(8.0).
Table 6 CLI Commands Changed in Version A1(8.0)
Mode
|
Command and Syntax
|
Description
|
Exec
|
line console
|
This command has been removed from the CLI.
|
show checkpoint all
|
The output for the show checkpoint all command has been modified to include checkpoint time stamps. The fields in the show checkpoint all command include the following checkpoint data:
•Checkpoint—Name of the checkpoint
•Size—Size (in bytes) of the checkpoint
•Date—Date and time at which the checkpoint was created
For example:
host1/Admin# show checkpoint all
------------------------------------------------------
Checkpoint Size (in bytes) Date (created on)
------------------------------------------------------
Checkpt1 14246 Wed May 14 09:16:18 2008
blank 0 Wed May 14 09:16:18 2008
Checkpt2 11694 Wed May 14 09:16:18 2008
|
show context
|
The show context command output for the ACE has been expanded as follows:
host1/Admin# show context c1
|
| |
show hardware
|
The show hardware command output for the ACE has been expanded as follows:
host1/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: QCN21220038
MFG Part Num: 800-29070-01
|
show ipcp pci
|
This command has been removed from the CLI.
|
show environment
|
This command has been removed from the CLI.
|
show fifo
|
This command has been removed from the CLI.
|
show interface g1/x
|
You can configure flow control on each Ethernet port of a Catalyst 6500 series switch. However, the ACE does not support flow control. If you connect an ACE to a Catalyst 6500 series switch, the flow control functionality is disabled on the ACE.
The output of the show interface g1/x command on the ACE now displays the "input flow-control is off, output flow control is off" flow-control status line regardless of the state of flow control on the Catalyst 6500 series switch port to which the ACE is connected.
For example:
host1/Admin# show interface g1/1
GigabitEthernet Port 1/1 is UP, line protocol is UP
Harware is ACE Appliance 1000Mb 802.3, address is
00:01:02:03:04:06
input flow-control is off, output flow-control is off
|
Configuration mode
|
interface vlan number
|
With the A1(8.0) release, you can now configure one or more VLAN interfaces in any user context before you assign those VLAN interfaces to the associated user contexts through the allocate-interface vlan command in the Admin context.
With ACE software releases prior to A1(8.0), the appliance required that you first use the allocate-interface vlan command in the Admin context to assign VLAN interfaces to a specific user context before configuring the VLAN interface for a user context.
|
logging reject-newconn {cp-buffer-full | rate-limit-reached | tcp-queue-full}
|
This command has been removed from the CLI.
|
logging rate-limit level severity_level
|
The level severity_level keyword identifies the specific syslog level that you want to rate limit. The severity level you enter indicates that you want all syslog messages at the specified level to be rate-limited.
For example, if you enter:
host1/Admin(config)# logging rate-limit level 7
the ACE applies a rate limit only to level 7 (debugging messages). If you want to apply a logging rate limit on a different severity level, you must configure the logging rate-limit level command for that level as well.
Allowable entries include:
•0—emergencies (System unusable messages)
•1—alerts (Take immediate action)
•2—critical (Critical condition)
•3—errors (Error message)
•4—warnings (Warning message)
•5—notifications (Normal but significant condition)
•6—informational (Information message)
•7—debugging (Debug messages)
|
Real server (host or redirect) configuration mode
|
conn-limit max maxconns min minconns
|
The ranges for the minconns and maxconns values have changed from 2 to 4294967295 to 1 to 4000000 and the default value has changed from 4294967295 to 4000000.
|
Server farm (host or redirect) real server configuration mode
|
conn-limit max maxconns min minconns
|
The ranges for the minconns and maxconns values have changed from 2 to 4294967295 to 1 to 4000000 and the default value has changed from 4294967295 to 4000000.
|
Software Version A1(7b) Resolved and Open Caveats
The following sections contain the resolved and open caveats in software version A1(7b):
•Software Version A1(7b) Resolved Caveats
•Software Version A1(7b) Open Caveats
Software Version A1(7b) Resolved Caveats
The following resolved caveats apply to ACE software version A1(7b).
•CSCsh84999—When you use the ACE to perform application acceleration, and the ACE reaches the maximum concurrent connections, the appliance stops accepting any additional concurrent connections. When the ACE reaches this maximum, the appliance does not generate a syslog to inform you that the additional application acceleration concurrent connections have been rejected.
•CSCsi89897—The ACE appliance Device Manager GUI does not support Secure Trivial File Transfer Protocol (SFTP) as a method in the Import License File dialog box (Config > Virtual Contexts > System > Licenses > Import Licenses) to import a software license to the disk0: file system on the ACE appliance.
Workaround: From the ACE appliance CLI, use the copy command in Exec mode from the Admin context to copy the file from the network server to disk0: on the ACE. For detailed information on copying files from a remote server, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
•CSCsl21847—If you activate or suspend a virtual server using the Operations screen (Config > Operations > Virtual Servers) on the ACE appliance Device Manager GUI, and the virtual server is associated with one or more Layer 7 rules (Config > Virtual Contexts > Virtual Servers > L7 Load-Balancing), the match conditions for the class map rules are deleted. This situation does not occur if you configure Layer 7 Load-Balancing rules using the Inline Match option.
Workaround: Use the Virtual Server configuration screen to place the virtual server in or out of service:
1. Select Config > Virtual Context > Load Balancing > Virtual Servers > Edit.
2. In the Properties configuration subset, select In-service or Out-of-service in the Status field.
•CSCsl31753—When you attempt to deploy a sticky group using the ACE appliance Device Manager GUI (Config> Devices> Load Balancing> Stickiness), the following error message may appear:
error in saving to DB: Can't create sticky because resource is not allocated
This behavior occurs because the Device Manager assumes that the minimum sticky percentage allocated to the resource class is 1 percent. However, any value greater than zero should be sufficient to allow sticky to allocate resources for sticky entries.
Workaround: Configure stickiness from the ACE appliance CLI. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl57808—When you use the ACE appliance Device Manager GUI to configure URL mapping in an action list (Config > Virtual Contexts > context > Expert > Action List) for application acceleration and optimization, and you specify regular expressions for the Source and Destination fields in the URL Map configuration screen, the following error message may appear below either field in the screen:
Invalid value ID (letters, numbers, underscore, hyphen only)
The expected behavior is that the Source and Destination fields allow all the characters in a regular expression.
•CSCsl88829—The ACE appliance supports only alphanumeric characters and a small subset of the allowed SNMP community string characters when defining an SNMP community string. The ACE appliance does not support all special characters for an SNMP community string.
•CSCsm13262—Periodically, when importing an SSL certificate or SSL key pair file into a specific virtual context, the ACE appliance Device Manager GUI does not display the certificate or key file in the Certificates table or in the Keys table. You may find that clicking Refresh to resynchronize the context in the Device Manager fails to update the certificate or key in the associated table.
Workaround: Use the show crypto files command in Exec mode from the ACE appliance CLI to display a list of all available SSL certificate and key pair files.
•CSCsm16881—A configuration that includes HTTP persistence rebalance, sticky, and application acceleration may result in an unexpected redirection of multiple packet requests from the client side. For example, for two consecutive GET requests to the same connection, with persistence rebalance enabled, the first GET request is to be directed to the real server on the ACE and the second GET request is to be sent to the application acceleration module on the ACE. In this case, the two consecutive messages are sent to the real server because the ACE fails to properly reuse the back-end connection. As a result, the second GET request bypasses being sent to the application acceleration module.
•CSCsm16908— The removal of a user context from the ACE may affect the traffic flow for another context VIP which has a configuration that includes server load balancing, HTTP persistence rebalance, and application acceleration configured with FlashForward object acceleration. The removal of the user context can result in the resetting of the client connection for the connection that requires server load balancing and application acceleration processing. The ACE resets the connection that requires application acceleration processing because it fails to find a valid Layer 7 server load-balancing policy.
Display load-balancing statistics by using the show stats loadbalance command in Exec mode.The ACE will increment the Total Layer 7 Rejections and Total Layer 7 LB Policy Misses fields when the appliance encounters this issue.
Workarounds: Perform one of the following actions to resolve this behavior:
–Remove and re-add those user contexts that exhibit this problem, or
–Use the reload command in Exec mode to reboot the ACE.
•CSCsm60918—The show hardware command in Exec mode displays the following system hardware information in the output:
switch/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: 1234567890
Cisco manufacturing has requested the following system hardware additions to the show hardware command output:
switch/Admin# show hardware
Product Number: ACE-4710-K9
Serial Number: 1234567890
MFG Part Num: abcdefghijkl
Software Version A1(7b) Open Caveats
The following open caveats apply to ACE software version A1(7b).
•CSCse85906—When a switchover occurs in a Layer 7 load-balancing persistence-rebalance configuration, connections with multiple GETs may not proceed. Workaround: None.
•CSCsg95099—When you configure SNMP notification using the ACE appliance Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. Note that this information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > Sync or Sync All.
•CSCsj64833—The network utility traceroute does not work for a configured ACE IP interface if the underlying protocol is UDP or TCP. Workaround: ICMP traceroute will work. The default of most traceroute utilities is UDP so a command line option might be necessary. For Linux, use the -I option.
•CSCsh89272—When configuring HTTP optimization policy maps in the Device Manager GUI, the Insert Before option for a class map overwrites an existing action list. For example, if you select the Insert Before option when associating a class map with a Layer 7 HTTP optimization policy map that is already associated with a class map and action list, if you add an action list to the Action subtable without refreshing the Rule subtable, the Device Manager associates both action lists with the original class map.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Create two action lists (Config > Virtual Contexts > Expert > Action List).
2. Create two Layer 7 server load-balancing class maps (Config > Virtual Contexts > Expert > Class Map).
3. Create one Layer 7 HTTP optimization policy map (Config > Virtual Contexts > Expert > Policy Map).
4. In the policy map Rule subtable, associate one of the class maps with the policy map.
5. In the policy map Action subtable, associate one of the action lists with the class map.
6. In the Rule subtable, follow these steps:
a. Click Add to add the second class map.
b. Select True in the Insert Before field.
c. Select the previously associated class map in the Insert Before Policy Rule field.
d. Click Deploy Now.
7. In the Action subtable, add the second action list, and click Deploy Now. When the screen refreshes, both action lists are associated with the first class map, and neither are associated with the second class map.
Workaround: Replace Step 7 in the above procedure with the following steps:
7. Click the Rule tab to refresh the Rule subtable.
8. Select the class map that you added in Step 6.
9. In the Action subtable, add the second action list, and click Deploy Now. When the screen refreshes, each action list is associated with its respective class map.
•CSCsh96086—The Device Manager GUI fails to add real servers to custom domains on the ACE appliance. In this case, a real server that you create in a custom domain in the Device Manager appears in the default-domain on the ACE appliance. This behavior occurs because the real server is deployed to the CLI using the Admin credentials and is created in the default-domain only.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Admin > Role-Based Access Control > Domains > Add.
2. Create a domain.
3. In the Domain Object subtable, add a real server.
4. Select Admin > Role-Based Access Control > Roles > Add.
5. Create a new role.
6. In the Rule subtable, add entries that grant Permit permission for Create, Debug, Modify, and Monitor operations for the Rserver feature.
7. Select Admin > Role-Based Access Control > Users > Add.
8. Add a user, assigning the role and domain created in Steps 2 and 5.
9. Log into the Device Manager as the new user.
10. Select Config > Virtual Contexts > Load Balancing > Real Servers > Add.
11. Add a real server.
12. Using the CLI, verify that the real server is created on the ACE appliance. The real server is created on the ACE appliance but is added to default-domain instead of the user domain.
Workarounds:
–Using the CLI, add objects to a user-defined domain.
–Using the Device Manager, select the affected context (Config > Virtual Contexts), and click Sync.
•CSCsi19809—When you use the Device Manager GUI to import an ACE appliance license, the Device Manager does not display a confirmation message before overwriting an existing license.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > System > Licenses, and click Import License.
2. In the Import License File dialog box, enter the information, then click OK.
3. Import the same license using the same destination. No message appears to indicate that this action will overwrite an existing license, and the first license is overwritten with the second.
Workaround: Do not reimport an existing license.
•CSCsj68643—The following log messages may appear sporadically in the ACE log:
–can_wait_specific_msg: Aborting call (SAP 27, pid 959). Another thread is also waiting for a specific msg.
–can_wait_specific_msg: Aborting call (SAP 27, pid 905). Another thread is also waiting for a specific msg.
These messages do not impact the operation of the ACE. The messages may be caused by more than one device accessing the ACE context through XML. Workaround: None.
•CSCsj70522—In a redundant configuration with multiple contexts and logging enabled for the console and the buffer on both ACEs, log messages appear only on the standby console when a probe to a server fails. No new messages are observed in the buffers on either ACE. After entering the changeto command to another context and then back to the original context, log messages appear on the active ACE console, but the log buffer is not updated. Workaround: None.
•CSCsj80265—With the ACE configured for TACACS+ authentication and SSHv1 management access and the SSH keys generated in RSA1 format, SSH fails to authenticate a user because of a bad password when you attempt to connect to the ACE using an SSH client. You can connect to the ACE using Telnet and the session works. If you Telnet to the ACE with the same credentials (username and password) that you attempted to use with SSH, and then subsequently try to connect to the ACE using SSH, the SSH session is established. Workaround: Use SSHv2 to connect to the ACE by generating the SSH key in an RSA format instead of an RSA1 format. For example, enter the following CLI command: ssh key rsa 1024 force.
•CSCsj88500—If a large configuration contains many different service-policy actions, some of the show service-policy command output may be missing. The ACE may not display some of the actions associated with the service policy. Workaround: None.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCsk34767—FTP inspection statistics associated with the show stats inspect command cannot be cleared using the clear stats inspect command. Workaround: None.
•CSCsk89562—When you use dynamic Network Address Translation (NAT) and Port Address Translation (PAT) on ICMP connections, these connections do not release the used ports back into the pool of IP addresses for dynamic NAT when the connections close. In this case, the unreleased ports are unavailable for further NAT operations because ICMP connections use the ICMP ID as a port, which is similar to the way that the source port uses PAT in UDP/TCP connections. When no ports are available by the ACE, the ACE forwards the traffic that use the affected NAT pool without performing NAT.
If you suspect that this behavior is occurring by the ACE, use the show np 1 me-stats -socm command to monitor the NAT Pool Free and NAT Pool Alloc fields in the command output for the Octeon processor. A NAT Pool Free counter value of approximately 32,000 is the upper limit of what may be leaked before you notice a network effect and NAT Pool Alloc failures begin to increment.
Workaround: You should perform a periodic scheduled reboot of the ACE to free nat-pool resources. However, we do not recommend that you use dynamic NAT and PAT on ICMP connections. If you find that NAT is a requirement on ICMP connections, reboot the ACE before it reaches a counter value of 30,000 to prevent any network issues associated with this ICMP connection behavior.
•CSCsk98342—When you remove a real server from a server farm configuration, Layer 3 and Layer 4 connections fail to be removed and subsequent traffic on the connection is still sent to the removed real server. Workaround: Instruct the ACE to purge Layer 3 and Layer 4 connections by using the failaction purge command prior to removing the real server from the server farm. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl09286—When you use the ACE appliance Device Manager GUI to configure an HTTP cookie sticky connection for a sticky group and you enable cookie insertion, the Device Manager does not support the configuration of the client's browser to expire a cookie when the session ends. The browser-expire field in missing as a sticky group attribute.
You can enable cookie insertion in the following Device Manager screens:
–Config > Virtual Contexts > Load Balancing > Stickiness > Add or Edit
–Config > Virtual Contexts > Load Balancing > Virtual Servers > L7 Load-Balancing
–Config > Virtual Contexts > Load Balancing > Virtual Servers > Default L7 Load-Balancing Action
Workaround: To allow a browser to expire the cookie when the session ends, use the optional browser-expire keyword of the cookie insert CLI command in sticky-cookie configuration mode. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl04936—The IP address and protocol information contained in syslog message 106023 (an IP packet was denied by an ACL) may be incorrect. Workaround: None.
•CSCsl71709—When contents with highly repetitive patterns are configured to be compressed by the ACE, the result may not be as optimal as when compressed directly with gzip, possibly resulting in many small packets being sent on the network. A longer compressed payload can lead to noticeable extra latency in a WAN environment.
Workaround: There is currently no workaround to improve the compression ratio and address the resulting delay in WAN environment. The number of small packets can be reduced by turning on the TCP Nagle algorithm. You can enable Nagle's algorithm by using the nagle command in parameter map connection configuration mode. By default, this command is disabled.
•CSCsl71820—When you create a checkpoint (or snapshot) of a running configuration on your ACE and use the rollback service to revert to the last known stable configuration, probes may remain in the INIT state.
Workaround: Use the reload command in Exec mode to reboot the ACE.
•CSCsm56713—The ACE appliance Device Manager GUI Primary Attributes page (Config >Virtual Contexts > System > Primary Attributes) may be missing some of the mandatory fields, such as the VLAN to Use, Management IP, and Management Netmask fields. This issue can occur when you partially configure a management interface (VLAN, IP address, policy, and so on) from the ACE CLI. After you synchronize the configuration for the selected virtual context on the Device Manager, you may notice the missing IP address on the Primary Attributes configuration screen.
You may encounter this issue when a management interface is not fully defined as shown in the example below. In this example, the IP address is missing:
service-policy input remote_mgmt_policy
Note that you can have multiple management interfaces defined with at least one fully defined and functional interface so that the ACE and the Device Manager are still reachable and configurable. For example:
service-policy input remote_mgmt_policy
ip address 172.20.28.43 255.255.255.128
service-policy input remote_mgmt_policy
In this case, after synchronization is completed, the Device Manager chooses the first interface, instead of the first fully defined interface, and displays the attributes on the Primary Attributes configuration screen.
Note As long as there is at least one working management interface on the ACE appliance, you will be able to successfully access the ACE CLI and the Device Manager GUI.
Workaround: To resolve this issue, perform the following actions:
1. Add the missing CLI commands on a partially defined interface and verify that the interface is functional.
2. From the Device Manager GUI, use the Sync function (Config > Virtual Contexts) from the All Virtual Contexts table to synchronize the CLI configuration.
•CSCsm60957—You are running the ACE appliance Device Manager GUI in the Internet Explorer 6.0 web browser and you attempt to use the Device Manager to add a new ACL to the ACLs table (Config > Virtual Contexts > context > Network > VLAN Interface). The "error on this page" message appears at the bottom of the Internet Explorer 6.0 web browser and the ACL table fails to appear in the Device Manager GUI.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > context > Network > VLAN Interface. The VLAN Interface table appears.
2. Add a new VLAN or select an existing VLAN.
3. Select the VLAN interface that you want to associate with an ACL, and then select the Access Group tab. The Access Group table appears.
4. Click Add to associate a new ACL with the selected VLAN interface. The Access Group configuration screen appears.
5. Click the + icon to the left of the ACL Name field to add a new ACL into the ACL table. The "error on this page" message appears at the bottom of the Internet Explorer 6.0 web browser and the ACL table fails to appears in the Device Manager GUI.
Workaround: Use the Firefox 2.0 web browser instead of the Internet Explorer 6.0 web browser to run the Device Manager GUI, and add a new ACL from the Access Group tab as described in the above procedure.
If you want to use the Internet Explorer 6.0 web browser, perform the following procedure:
1. Select Config > Virtual Contexts > context > Security > ACLs and add a new ACL from the ACL configuration screen.
2. Select Config > Virtual Contexts > context > Network > VLAN Interface. The VLAN Interface table appears.
3. Select the VLAN interface that you want to associate with an ACL, and then select the Access Group tab. The Access Group table appears.
4. Click Add to associate a new ACL with the selected VLAN interface. The Access Group configuration screen appears.
5. Select the ACL entry added in Step 1 from the drop-down list.
6. Continue with the remainder of the configuration.
•CSCsm74832—In a configuration that includes application acceleration Flashforward, HTTP persistence rebalance, and server connection reuse enabled, GET requests for embedded dynamic objects may be reset by the ACE. To monitor this behavior, use the show stats loadbalance command in Exec mode. You should observe that the counter associated with the Total Times Rserver Was Unavailable field is incremented. Workaround: Disable TCP server reuse by using the no form of the server-conn reuse command in HTTP parameter-map configuration mode. All GET requests for embedded dynamic objects will be served correctly by the server to the ACE.
•CSCsm83733—You are using the ACE appliance Device Manager GUI, and you select Admin > Role-Based Access Control > Active Users to view a list of the users currently logged into the ACE. In some cases, the Device Manager GUI displays the following error message: "The element type "users_user" must be terminated by the matching end-tag "</users_user>"." As a result, the Device Manager GUI is unable to display a list of active users. Workaround: Establish a direct serial connection between your terminal or a PC and the ACE and log in to ACE through the console port. This action removes the error condition from the Device Manager GUI and allows you to view a list of active users.
•CSCsv95366—When you use the ACE appliance Device Manager GUI, in some instances after you login to the Device Manager you may encounter a blank page. Workaround: Enter the reload command in Exec mode to reboot the ACE.
Software Version A1(7a) Resolved and Open Caveats
The following sections contain the resolved and open caveats in software version A1(7a):
•Software Version A1(7a) Resolved Caveat
•Software Version A1(7a) Open Caveats
Software Version A1(7a) Resolved Caveat
The following resolved caveat applies to ACE software version A1(7a).
•CSCsm26663—The ACE appliance may fail to boot up and continuously reboot with the A1(7) software image. When you attempt to boot the ACE appliance with the c4710ace-mzg.A1_7.bin image, the following message may appear:
insmod: error inserting '/isan/bin/klm_octeon_device.klm': -1 No such device
error inserting /isan/bin/klm_octeon_device.klm
Daughter Card Not Found. Rebooting..
INIT: Sending all processes the TERM signal...
The display of this message is due to a recently discovered hardware incompatibility, which may cause the ACE appliance to continuously reboot.
Workaround: Upgrade to the c4710ace-mzg.A1_7a.bin software image to resolve the rebooting issue.
Software Version A1(7a) Open Caveats
The following open caveats apply to ACE software version A1(7a).
•CSCse85906—When a switchover occurs in a Layer 7 load-balancing persistence-rebalance configuration, connections with multiple GETs may not proceed. Workaround: None.
•CSCsg95099—When configuring SNMP notification using the Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. Note that this information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > Sync or Sync All.
•CSCsj64833—The network utility traceroute does not work for a configured ACE IP interface if the underlying protocol is UDP or TCP. Workaround: ICMP traceroute will work. The default of most traceroute utilities is UDP so a command line option might be necessary. For Linux, use the -I option.
•CSCsh89272—When configuring HTTP optimization policy maps in the Device Manager GUI, the Insert Before option for a class map overwrites an existing action list. For example, if you select the Insert Before option when associating a class map with a Layer 7 HTTP optimization policy map that is already associated with a class map and action list, if you add an action list to the Action subtable without refreshing the Rule subtable, the Device Manager associates both action lists with the original class map.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Create two action lists (Config > Virtual Contexts > Expert > Action List).
2. Create two Layer 7 server load-balancing class maps (Config > Virtual Contexts > Expert > Class Map).
3. Create one Layer 7 HTTP optimization policy map (Config > Virtual Contexts > Expert > Policy Map).
4. In the policy map Rule subtable, associate one of the class maps with the policy map.
5. In the policy map Action subtable, associate one of the action lists with the class map.
6. In the Rule subtable, follow these steps:
a. Click Add to add the second class map.
b. Select True in the Insert Before field.
c. Select the previously associated class map in the Insert Before Policy Rule field.
d. Click Deploy Now.
7. In the Action subtable, add the second action list, and click Deploy Now. When the screen refreshes, both action lists are associated with the first class map, and neither are associated with the second class map.
Workaround: Replace Step 7 in the above procedure with the following steps:
7. Click the Rule tab to refresh the Rule subtable.
8. Select the class map that you added in Step 6.
9. In the Action subtable, add the second action list, and click Deploy Now. When the screen refreshes, each action list is associated with its respective class map.
•CSCsh96086—The Device Manager GUI fails to add real servers to custom domains on the ACE appliance. In this case, a real server that you create in a custom domain in the Device Manager appears in the default-domain on the ACE appliance. This behavior occurs because the real server is deployed to the CLI using the Admin credentials and is created in the default-domain only.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Admin > Role-Based Access Control > Domains > Add.
2. Create a domain.
3. In the Domain Object subtable, add a real server.
4. Select Admin > Role-Based Access Control > Roles > Add.
5. Create a new role.
6. In the Rule subtable, add entries that grant Permit permission for Create, Debug, Modify, and Monitor operations for the Rserver feature.
7. Select Admin > Role-Based Access Control > Users > Add.
8. Add a user, assigning the role and domain created in Steps 2 and 5.
9. Log into the Device Manager as the new user.
10. Select Config > Virtual Contexts > Load Balancing > Real Servers > Add.
11. Add a real server.
12. Using the CLI, verify that the real server is created on the ACE appliance. The real server is created on the ACE appliance but is added to default-domain instead of the user domain.
Workarounds:
–Using the CLI, add objects to a user-defined domain.
–Using the Device Manager, select the affected context (Config > Virtual Contexts), and click Sync.
•CSCsi19809—When you use the Device Manager GUI to import an ACE appliance license, the Device Manager does not display a confirmation message before overwriting an existing license.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > System > Licenses, and click Import License.
2. In the Import License File dialog box, enter the information, then click OK.
3. Import the same license using the same destination. No message appears to indicate that this action will overwrite an existing license, and the first license is overwritten with the second.
Workaround: Do not reimport an existing license.
•CSCsj68643—The following log messages may appear sporadically in the ACE log:
–can_wait_specific_msg: Aborting call (SAP 27, pid 959). Another thread is also waiting for a specific msg.
–can_wait_specific_msg: Aborting call (SAP 27, pid 905). Another thread is also waiting for a specific msg.
These messages do not impact the operation of the ACE. The messages may be caused by more than one device accessing the ACE context through XML. Workaround: None.
•CSCsj70522—In a redundant configuration with multiple contexts and logging enabled for the console and the buffer on both ACEs, log messages appear only on the standby console when a probe to a server fails. No new messages are observed in the buffers on either ACE. After entering the changeto command to another context and then back to the original context, log messages appear on the active ACE console, but the log buffer is not updated. Workaround: None.
•CSCsj80265—With the ACE configured for TACACS+ authentication and SSHv1 management access and the SSH keys generated in RSA1 format, SSH fails to authenticate a user because of a bad password when you attempt to connect to the ACE using an SSH client. You can connect to the ACE using Telnet and the session works. If you Telnet to the ACE with the same credentials (username and password) that you attempted to use with SSH, and then subsequently try to connect to the ACE using SSH, the SSH session is established. Workaround: Use SSHv2 to connect to the ACE by generating the SSH key in an RSA format instead of an RSA1 format. For example, enter the following CLI command: ssh key rsa 1024 force.
•CSCsj88500—If a large configuration contains many different service-policy actions, some of the show service-policy command output may be missing. The ACE may not display some of the actions associated with the service policy. Workaround: None.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCsk34767—FTP inspection statistics associated with the show stats inspect command cannot be cleared using the clear stats inspect command. Workaround: None.
•CSCsk89562—When you use dynamic Network Address Translation (NAT) and Port Address Translation (PAT) on ICMP connections, these connections do not release the used ports back into the pool of IP addresses for dynamic NAT when the connections close. In this case, the unreleased ports are unavailable for further NAT operations because ICMP connections use the ICMP ID as a port, which is similar to the way that the source port uses PAT in UDP/TCP connections. When no ports are available by the ACE, the ACE forwards the traffic that use the affected NAT pool without performing NAT.
If you suspect that this behavior is occurring by the ACE, use the show np 1 me-stats -socm command to monitor the NAT Pool Free and NAT Pool Alloc fields in the command output for the Octeon processor. A NAT Pool Free counter value of approximately 32,000 is the upper limit of what may be leaked before you notice a network effect and NAT Pool Alloc failures begin to increment.
Workaround: You should perform a periodic scheduled reboot of the ACE to free nat-pool resources. However, we do not recommend that you use dynamic NAT and PAT on ICMP connections. If you find that NAT is a requirement on ICMP connections, reboot the ACE before it reaches a counter value of 30,000 to prevent any network issues associated with this ICMP connection behavior.
•CSCsk98342—When you remove a real server from a server farm configuration, Layer 3 and Layer 4 connections fail to be removed and subsequent traffic on the connection is still sent to the removed real server. Workaround: Instruct the ACE to purge Layer 3 and Layer 4 connections by using the failaction purge command prior to removing the real server from the server farm. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl09286—When you use the Device Manager GUI to configure an HTTP cookie sticky connection for a sticky group and you enable cookie insertion, the Device Manager does not support the configuration of the client's browser to expire a cookie when the session ends. The browser-expire field in missing as a sticky group attribute.
You can enable cookie insertion in the following Device Manager screens:
–Config > Virtual Contexts > Load Balancing > Stickiness > Add or Edit
–Config > Virtual Contexts > Load Balancing > Virtual Servers > L7 Load-Balancing
–Config > Virtual Contexts > Load Balancing > Virtual Servers > Default L7 Load-Balancing Action
Workaround: To allow a browser to expire the cookie when the session ends, use the optional browser-expire keyword of the cookie insert CLI command in sticky-cookie configuration mode. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl04936—The IP address and protocol information contained in syslog message 106023 (an IP packet was denied by an ACL) may be incorrect. Workaround: None.
•CSCsl21847—If you activate or suspend a virtual server using the Operations screen (Config > Operations > Virtual Servers) and the virtual server is associated with one or more Layer 7 rules (Config > Virtual Contexts > Virtual Servers > L7 Load-Balancing), the match conditions for the class map rules are deleted. This situation does not occur if you configure Layer 7 Load-Balancing rules using the Inline Match option.
Workaround: Use the Virtual Server configuration screen to place the virtual server in or out of service:
1. Select Config > Virtual Context > Load Balancing > Virtual Servers > Edit.
2. In the Properties configuration subset, select In-service or Out-of-service in the Status field.
•CSCsv95366—When you use the ACE appliance Device Manager GUI, in some instances after you login to the Device Manager you may encounter a blank page. Workaround: Enter the reload command in Exec mode to reboot the ACE.
Software Version A1(7) Open Caveats
The following open caveats apply to ACE software version A1(7).
•CSCse85906—When a switchover occurs in a Layer 7 load-balancing persistence-rebalance configuration, connections with multiple GETs may not proceed. Workaround: None.
•CSCsg95099—When configuring SNMP notification using the Device Manager GUI (Config > Virtual Contexts > System > SNMP > SNMP Notification), the following occurs:
–If you select the SLB option, the following commands are issued on the ACE appliance:
snmp-server enable traps slb vserver
snmp-server enable traps slb real
–If you select the SNMP option, the following commands are issued on the ACE appliance:
snmp-server enable traps snmp linkup
snmp-server enable traps snmp linkdown
This behavior occurs because the Device Manager operates at a more granular level than the ACE appliance for these options. Note that this information is used only for northbound notification and has no impact on Device Manager operations or monitoring functions.
Workarounds:
–When configuring SNMP notification, select the more specific options. For example, select SLB real or SLB vserver instead of SLB (Config > Virtual Contexts > System > SNMP > SNMP Notification > Add >Options).
–Synchronize configurations by selecting Config > Virtual Contexts > Sync or Sync All.
•CSCsj64833—The network utility traceroute does not work for a configured ACE IP interface if the underlying protocol is UDP or TCP. Workaround: ICMP traceroute will work. The default of most traceroute utilities is UDP so a command line option might be necessary. For Linux, use the -I option.
•CSCsh89272—When configuring HTTP optimization policy maps in the Device Manager GUI, the Insert Before option for a class map overwrites an existing action list. For example, if you select the Insert Before option when associating a class map with a Layer 7 HTTP optimization policy map that is already associated with a class map and action list, if you add an action list to the Action subtable without refreshing the Rule subtable, the Device Manager associates both action lists with the original class map.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Create two action lists (Config > Virtual Contexts > Expert > Action List).
2. Create two Layer 7 server load-balancing class maps (Config > Virtual Contexts > Expert > Class Map).
3. Create one Layer 7 HTTP optimization policy map (Config > Virtual Contexts > Expert > Policy Map).
4. In the policy map Rule subtable, associate one of the class maps with the policy map.
5. In the policy map Action subtable, associate one of the action lists with the class map.
6. In the Rule subtable, follow these steps:
a. Click Add to add the second class map.
b. Select True in the Insert Before field.
c. Select the previously associated class map in the Insert Before Policy Rule field.
d. Click Deploy Now.
7. In the Action subtable, add the second action list, and click Deploy Now. When the screen refreshes, both action lists are associated with the first class map, and neither are associated with the second class map.
Workaround: Replace Step 7 in the above procedure with the following steps:
7. Click the Rule tab to refresh the Rule subtable.
8. Select the class map that you added in Step 6.
9. In the Action subtable, add the second action list, and click Deploy Now. When the screen refreshes, each action list is associated with its respective class map.
•CSCsh96086—The Device Manager GUI fails to add real servers to custom domains on the ACE appliance. In this case, a real server that you create in a custom domain in the Device Manager appears in the default-domain on the ACE appliance. This behavior occurs because the real server is deployed to the CLI using the Admin credentials and is created in the default-domain only.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Admin > Role-Based Access Control > Domains > Add.
2. Create a domain.
3. In the Domain Object subtable, add a real server.
4. Select Admin > Role-Based Access Control > Roles > Add.
5. Create a new role.
6. In the Rule subtable, add entries that grant Permit permission for Create, Debug, Modify, and Monitor operations for the Rserver feature.
7. Select Admin > Role-Based Access Control > Users > Add.
8. Add a user, assigning the role and domain created in Steps 2 and 5.
9. Log into the Device Manager as the new user.
10. Select Config > Virtual Contexts > Load Balancing > Real Servers > Add.
11. Add a real server.
12. Using the CLI, verify that the real server is created on the ACE appliance. The real server is created on the ACE appliance but is added to default-domain instead of the user domain.
Workarounds:
–Using the CLI, add objects to a user-defined domain.
–Using the Device Manager, select the affected context (Config > Virtual Contexts), and click Sync.
•CSCsi19809—When you use the Device Manager GUI to import an ACE appliance license, the Device Manager does not display a confirmation message before overwriting an existing license.
This behavior is exhibited when you perform the following procedure using the Device Manager GUI:
1. Select Config > Virtual Contexts > System > Licenses, and click Import License.
2. In the Import License File dialog box, enter the information, then click OK.
3. Import the same license using the same destination. No message appears to indicate that this action will overwrite an existing license, and the first license is overwritten with the second.
Workaround: Do not reimport an existing license.
•CSCsj68643—The following log messages may appear sporadically in the ACE log:
–can_wait_specific_msg: Aborting call (SAP 27, pid 959). Another thread is also waiting for a specific msg.
–can_wait_specific_msg: Aborting call (SAP 27, pid 905). Another thread is also waiting for a specific msg.
These messages do not impact the operation of the ACE. The messages may be caused by more than one device accessing the ACE context through XML. Workaround: None.
•CSCsj70522—In a redundant configuration with multiple contexts and logging enabled for the console and the buffer on both ACEs, log messages appear only on the standby console when a probe to a server fails. No new messages are observed in the buffers on either ACE. After entering the changeto command to another context and then back to the original context, log messages appear on the active ACE console, but the log buffer is not updated. Workaround: None.
•CSCsj80265—With the ACE configured for TACACS+ authentication and SSHv1 management access and the SSH keys generated in RSA1 format, SSH fails to authenticate a user because of a bad password when you attempt to connect to the ACE using an SSH client. You can connect to the ACE using Telnet and the session works. If you Telnet to the ACE with the same credentials (username and password) that you attempted to use with SSH, and then subsequently try to connect to the ACE using SSH, the SSH session is established. Workaround: Use SSHv2 to connect to the ACE by generating the SSH key in an RSA format instead of an RSA1 format. For example, enter the following CLI command: ssh key rsa 1024 force.
•CSCsj88500—If a large configuration contains many different service-policy actions, some of the show service-policy command output may be missing. The ACE may not display some of the actions associated with the service policy. Workaround: None.
•CSCsk15979—When UDP and TCP class maps share the same VIP and both have the idle timer set to infinite, connections made that are associated with these class maps may sit idle for several hours. When a change is made to the UDP class map to time out these connections in 60 seconds, the ACE clears the TCP and UDP connections. Workaround: None.
•CSCsk34767—FTP inspection statistics associated with the show stats inspect command cannot be cleared using the clear stats inspect command. Workaround: None.
•CSCsk89562—When you use dynamic Network Address Translation (NAT) and Port Address Translation (PAT) on ICMP connections, these connections do not release the used ports back into the pool of IP addresses for dynamic NAT when the connections close. In this case, the unreleased ports are unavailable for further NAT operations because ICMP connections use the ICMP ID as a port, which is similar to the way that the source port uses PAT in UDP/TCP connections. When no ports are available by the ACE, the ACE forwards the traffic that use the affected NAT pool without performing NAT.
If you suspect that this behavior is occurring by the ACE, use the show np 1 me-stats -socm command to monitor the NAT Pool Free and NAT Pool Alloc fields in the command output for the Octeon processor. A NAT Pool Free counter value of approximately 32,000 is the upper limit of what may be leaked before you notice a network effect and NAT Pool Alloc failures begin to increment.
Workaround: You should perform a periodic scheduled reboot of the ACE to free nat-pool resources. However, we do not recommend that you use dynamic NAT and PAT on ICMP connections. If you find that NAT is a requirement on ICMP connections, reboot the ACE before it reaches a counter value of 30,000 to prevent any network issues associated with this ICMP connection behavior.
•CSCsk98342—When you remove a real server from a server farm configuration, Layer 3 and Layer 4 connections fail to be removed and subsequent traffic on the connection is still sent to the removed real server. Workaround: Instruct the ACE to purge Layer 3 and Layer 4 connections by using the failaction purge command prior to removing the real server from the server farm. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl09286—When you use the Device Manager GUI to configure an HTTP cookie sticky connection for a sticky group and you enable cookie insertion, the Device Manager does not support the configuration of the client's browser to expire a cookie when the session ends. The browser-expire field in missing as a sticky group attribute.
You can enable cookie insertion in the following Device Manager screens:
–Config > Virtual Contexts > Load Balancing > Stickiness > Add or Edit
–Config > Virtual Contexts > Load Balancing > Virtual Servers > L7 Load-Balancing
–Config > Virtual Contexts > Load Balancing > Virtual Servers > Default L7 Load-Balancing Action
Workaround: To allow a browser to expire the cookie when the session ends, use the optional browser-expire keyword of the cookie insert CLI command in sticky-cookie configuration mode. See the Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Guide.
•CSCsl04936—The IP address and protocol information contained in syslog message 106023 (an IP packet was denied by an ACL) may be incorrect. Workaround: None.
•CSCsl21847—If you activate or suspend a virtual server using the Operations screen (Config > Operations > Virtual Servers) and the virtual server is associated with one or more Layer 7 rules (Config > Virtual Contexts > Virtual Servers > L7 Load-Balancing), the match conditions for the class map rules are deleted. This situation does not occur if you configure Layer 7 Load-Balancing rules using the Inline Match option.
Workaround: Use the Virtual Server configuration screen to place the virtual server in or out of service:
1. Select Config > Virtual Context > Load Balancing > Virtual Servers > Edit.
2. In the Properties configuration subset, select In-service or Out-of-service in the Status field.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
CCDE, CCVP, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0801R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007-2008 Cisco Systems, Inc. All rights reserved.
Feedback
