Table Of Contents
Release Note for the Cisco Application Control Engine Module
Contents
Supervisor Engine and Cisco IOS Support for the ACE Module
Virtual Switching System Support
ACE Module Troubleshooting Wiki
New Software Features in Version A2(3.0)
ACE Operating Considerations
Software Version A2(3.0) Resolved Caveats and Open Caveats
Software Version A2(3.0) Resolved Caveats
Software Version A2(3.0) Open Caveats
Available ACE Licenses
Ordering an Upgrade License and Generating a License Key
Upgrading Your ACE Software
Changing the Admin Password
Changing the www User Password
Checking Your Configuration for FT Priority and Preempt
Creating a Checkpoint
Updating Your Application Protocol Inspection Configurations
Downgrading Your ACE Software from Version A2(1.0) or Higher to 3.0(0)A1(6.x) in a Redundant Configuration
Before You Begin
Downgrade Procedure
ACE Documentation Set
Obtaining Documentation and Submitting a Service Request
Release Note for the Cisco Application Control Engine Module
October 12, 2009
Note 
The most current Cisco documentation for released products is available on Cisco.com.
Contents
This release note applies to software version A2(3.0) for the Cisco Application Control Engine Module (ACE), models ACE10 (ACE10-6500-K9) and ACE20 (ACE20-MOD-K9).
For information on the ACE module features and configuration details, see the ACE documentation located at:
http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html
This release note contains the following sections:
•New Software Features in Version A2(3.0)
•ACE Operating Considerations
•Software Version A2(3.0) Resolved Caveats and Open Caveats
•Available ACE Licenses
•Ordering an Upgrade License and Generating a License Key
•Upgrading Your ACE Software
•Downgrading Your ACE Software from Version A2(1.0) or Higher to 3.0(0)A1(6.x) in a Redundant Configuration
•ACE Documentation Set
•Obtaining Documentation and Submitting a Service Request
Supervisor Engine and Cisco IOS Support for the ACE Module
Table 1 and Table 2 summarize the supervisor engine model and Cisco IOS version support for the ACE module in the Catalyst 6500 series switch and the Cisco 7600 series router, respectively.
Table 1 Supervisor Engine and Cisco IOS Support for the ACE Module in a Catalyst 6500 Series Switch with a Multilayer Switch Feature Card (MSFC3)
Supervisor Engine Model
|
Minimum Required IOS Version
|
Other IOS Version Support
|
WS-SUP720
|
12.2(18)SXF4 (or later)
|
12.2(33)SXH (or later), 12.2(33)SXI1 (or later)
|
WS-SUP720-3B
|
WS-SUP720-3BXL
|
VS-S720-10G-3C
|
12.2(33)SXH (or later)
|
VS-S720-10G-3CXL
|
Table 2 Supervisor Engine, Route Switch Processor (RSP), and Cisco IOS Support for the ACE Module in a Cisco 7600 Series Router with an MSFC3
Supervisor Engine or RSP
|
Minimum Required IOS Version
|
Other IOS Version Support
|
WS-SUP720
|
12.2(18)SXF4 (or later)
|
12.2(33) SRB (or later)
Not supported: 12.2(33)SXH1
|
WS-SUP720-3B
|
WS-SUP720-3BXL
|
RSP720
|
12.2(33)SRC (or later)
|
None
|
For more information about Cisco IOS releases, see the Release Notes for Cisco IOS Release 12.2SXF and Rebuilds and the Release Notes for Cisco IOS Release 12.2(33)SXH and Later Releases.
Virtual Switching System Support
The ACE10 and the ACE20 running ACE software version A2(1.2) or later and installed in a Catalyst 6500 series switch running IOS software version 12.2(33)SXI or later support the Virtual Switching System (VSS). VSS is a system virtualization technology that allows the pooling of multiple Catalyst 6500 switches into a single virtual switch for increased operational efficiency by simplifying the network. Inter-chassis Supervisor switchover (SSO) boosts non-stop communication. For more information about VSS, see the Cisco IOS Version 12.2(33)SXI Configuration Guide.
ACE Module Troubleshooting Wiki
The ACE documentation set now includes the ACE Module Troubleshooting Wiki. This wiki is a collaborative site that describes the basic procedures and methodology to assist you in troubleshooting the most common problems that you may encounter while you are operating your ACE.
As a registered user of Cisco.com, we strongly encourage you to add content to this site in the form of troubleshooting tips, procedures, or even entire sections. When you add content to the site, you should adhere to the format that has been established for the wiki. To access the ACE Module Troubleshooting Wiki on Cisco DocWiki, click the following URL:
http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_(ACE)_Module_Troubleshooting_ Guide,_Release_A2(x)
New Software Features in Version A2(3.0)
The A2(3.0) software release provides the following new features:
•HTTP insert of SSL session, client, and server header information (see the Cisco Application Control Engine Module SSL Configuration Guide)
•SSL redirect on SSL session setup failure (see the Cisco Application Control Engine Module SSL Configuration Guide)
•Sample SSL certificate and key (see the Cisco Application Control Engine Module SSL Configuration Guide)
•Backup and restore of configuration files, licenses, SSL certificates and keys, and checkpoints (see the Cisco Application Control Engine Module Administration Guide)
•SNMP MIB and trap enhancements (see the Cisco Application Control Engine Module Administration Guide)
•Failaction reassign across VLANs (see the Cisco Application Control Engine Module Server Load-Balancing Guide)
•Secondary IP address support for multiple subnets on the same VLAN (see the Cisco Application Control Engine Module Routing and Bridging Configuration Guide)
•Large configuration download optimization (see the Cisco Application Control Engine Module Administration Guide)
ACE Operating Considerations
•The ACE requires a route back to the client before it can forward a request to a server. If the route back to the client is not present, the ACE cannot establish a flow and drops the client request. Make sure that you configure the appropriate routing to the client network on the ACE VLAN where the client traffic enters the ACE module.
•Software version A2(1.0) introduces hardware-assisted SSL (HTTPS) probes. For that reason, the ACE uses the all option for the default SSL version and uses the routing table (which may bypass the real server IP address) to direct HTTPS probes to their destination regardless of whether you specify the routed option in the ip address command. If you are using HTTPS probes in your A1(6.x) configuration with the default SSL version (SSLv3) or without the routed option, you may observe that your HTTPS probes behave differently with version A2(1.x) or higher. For more information about HTTPS probes, see the Cisco Application Control Engine Module Server Load-Balancing Guide.
Additionally, hardware-assisted probes are subject to the same key-pair size limitations as SSL termination. The maximum size of a public key in a server SSL certificate that the ACE can process is 2048 bits. For more information about HTTPS probes, see the Cisco Application Control Engine Module Server Load-Balancing Guide.
•By design, if you set the maximum resources for sticky to unlimited using the limit-resource command, the ACE ignores the setting and sets the maximum value to equal-to-min. In addition, the maximum resource value for sticky in the show resource usage command output displays as 0. This behavior occurs because the ACE does not allow sticky resources to become oversubscribed as with other configurable resources. Instead, when the sticky resource usage reaches the minimum value, the ACE ages out older sticky entries in the sticky table and reuses them for new sticky entries.
•In software version A2(1.2), the maximum number of match statements per ACE has been increased from 4,096 to 16,384.
•The Total Conn-failures counter in the show rserver detail command displays the total number of connection attempts that failed to establish a connection to the real server.
–For Layer 4 traffic with normalization on, the count increments if the three-way handshake fails to be established for either of the following reasons:
- An RST comes from the client or the server after a SYN-ACK.
- The server does not reply to a SYN. The connection times out.
–For Layer 4 traffic with normalization off, the count does not increment.
–For Layer 7 traffic (normalization is always on), the count increments if the three-way handshake fails to be established for either of the following reasons:
- An RST comes from the server after the front-end connection is established.
- The server does not reply to a SYN. The connection times out.
•In software version A2(2.0), the ACE supports a maximum of 3,800 certificates and 3,800 key pairs.
•In software version A2(2.0), the ACE now supports an SSL filename with a maximum of 39 characters.
•When you downgrade the ACE software, the features and commands of the higher release are lost because they are not supported by the lower release.
•Per CSCsz87533, the outbound UDP connection may timeout shortly after the ACE receives a RADIUS request, but before it gets the response for this request from the server. This situation can cause the ACE to improperly forward subsequent RADIUS traffic. If the server is not expected to initiate connections through the ACE, we recommend that you apply an inbound ACL on the server interface to block these connections.
The ACE requires a route back to the client before it can forward a request to a server. If the route back to the client is not present, the ACE cannot establish a flow and drops the client request. Make sure that you configure the appropriate routing to the client network on the ACE VLAN where the client traffic enters the ACE module.
Software version A2(1.0) introduced hardware-assisted SSL (HTTPS) probes. For that reason, the ACE uses the all option for the default SSL version and uses the routing table (which may bypass the real server IP address) to direct HTTPS probes to their destination regardless of whether you specify the routed option in the ip address command. If you are using HTTPS probes in your A1(6.x) configuration with the default SSL version (SSLv3) or without the routed option, you may observe that your HTTPS probes behave differently with version A2(1.x) or higher. For more information about HTTPS probes, see the Cisco Application Control Engine Module Server Load-Balancing Guide.
Additionally, hardware-assisted probes are subject to the same key-pair size limitations as SSL termination. The maximum size of a public key in a server SSL certificate that the ACE can process is 2048 bits. For more information about HTTPS probes, see the Cisco Application Control Engine Module Server Load-Balancing Guide.
In software version A2(1.2), the maximum number of match statements per ACE was increased from 4,096 to 16,384.
The Total Conn-failures counter in the show rserver detail command displays the total number of connection attempts that failed to establish a connection to the real server.
•For Layer 4 traffic with normalization on, the count increments if the three-way handshake fails to be established for either of the following reasons:
–An RST comes from the client or the server after a SYN-ACK.
–The server does not reply to a SYN. The connection times out.
•For Layer 4 traffic with normalization off, the count does not increment.
•For Layer 7 traffic (normalization is always on), the count increments if the three-way handshake fails to be established for either of the following reasons:
–An RST comes from the server after the front-end connection is established.
–The server does not reply to a SYN. The connection times out.
The ACE supports a maximum of 3,800 certificates and 3,800 key pairs.
The ACE now supports an SSL filename with a maximum of 39 characters.
When you downgrade the ACE software, the features and commands of the higher release are lost because they are not supported by the lower release.
Software Version A2(3.0) Resolved Caveats and Open Caveats
This release note includes resolved and open defects that have a severity level of Sev1, Sev2, and customer-use Sev 3. The following sections contain the resolved and open caveats in software version A2(3.0):
•Software Version A2(3.0) Resolved Caveats
•Software Version A2(3.0) Open Caveats
Software Version A2(3.0) Resolved Caveats
The following resolved caveats apply to software version A2(3.0):
•CSCsu29301—When the ACE module is in a Catalyst 6500 series chassis where SPAN is configured for RX or both, it duplicates ingress SPAN packets and does not duplicate TX packets. Workaround: None.
•CSCsu88684, CSCsq27062—When you configure the ACE with a large number of contexts and enable redundancy, as traffic flows on the ACE, the ACE becomes unresponsive and displays the following messages on the console:
mts_acquire_q_space() failing - no space in sap 516
sap=516 rq=102048 lq=0 pq=0 nq=0 sq=0 buf_in_transit=937, bytes_in_transit=82456
sap=1118 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=936, bytes_in_transit=145904
sap=514 rq=937 lq=0 pq=0 nq=0 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1084 rq=935 lq=0 pq=0 nq=1 sq=0 buf_in_transit=0, bytes_in_transit=0
sap=1025 rq=0 lq=0 pq=0 nq=0 sq=0 buf_in_transit=102052, bytes_in_transit=9388784
The ACE reboots after the messages are displayed. Workaround: None.
•CSCsv52942—When a server farm with no backup goes to an inactive state because all the real servers go to a MAXCONNS state, the ACE DP processor does not accept connections to the real servers even when they are no longer in a MAXCONNS state until the DP processor gets a "Back-in-service message" from the CP processor. Workaround: Configure a backup to the server farm.
•CSCsv74527— When DNS traffic is consistently running at more than 10000 cps in an ACE HA environment, after approximately 2 hours, proxy entries are leaked on the standby ACE. The proxy entries are leaked and not cleared on the standby ACE due to connection validation errors. Workaround: None.
•CSCsv98101—When using A2(1.2), the ACE console and remote access failed but network traffic continued to pass. Workaround: Reboot the ACE.
•CSCsw40764—When the ACE executes the no access-list command to delete an ACL configured with 64,000 entries, an API timeout occurs. Workaround: Do not delete all of these entries from an ACL at one time. Delete the entries from an ACL one at a time or in small chunks.
•CSCsx19525—When you configure 1,000 SSL VIPs on the ACE and then you change the configuration on those VIPs, a buffer leak occurs as displayed by the show np 1 me-stats command "-scommon" output and traffic conditions. Workaround: Reboot the ACE and do not make configuration changes that affects those VIPs.
•CSCsx39224—When you configure the sticky-serverfarm command in the policy map rather than the serverfarm command and the real servers are placed in an out-of-service state to make the server farm inactive, the backup server farm does not accept the connections. Workaround: Configure the serverfarm command in the policy map instead of the sticky-serverfarm command.
•CSCsx68671—A Layer 7 UDP connection with generic protocol parsing, payload sticky, and UPD fast age traffic may cause a large memory leak in the internal buffer particles on the ACE dataplane. Workaround: None.
•CSCsx93137 and CSCsx93995—When you enter either of the following commands in any context, but you do not enter the remote host password when prompted, the ACE waits for your input:
–crypto import ftp | sftp | {bulk ftp}
–crypto export ftp | sftp
Then, if you enter one of the following commands, the session may appear to be in an unresponsive state:
–crypto delete
–crypto export
–crypto generate csr
–crypto generate key
–crypto import
–crypto verify
–show crypto authgroup
–show crypto certificate
–show crypto chaingroup
–show crypto files
–show crypto key
After a while, the command aborts with a "SSL PKI subsystem is busy. Please try again later" message. Reissuing the command results in the same behavior.
Workaround: Enter the remote host password as requested by the associated crypto import | export command. If the problem persists, clear the relevant sessions by executing one of the following commands:
–clear users
–clear telnet session_ID
–clear ssh session_ID
You can execute those commands if you have the appropriate privileges (for example, Admin). For details about role-based access control (RBAC) and user roles, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
•CSCsx97484—When you reload the ACE while the primary server farm is out of service, the traffic does not switch to the backup server farm. This condition is specific to bootup only and does not occur if the primary server farm fails in runtime, such as when arp/probe fails for all real servers. Workaround: Configure one real server under Primary, which may trigger the failover.
•CSCsy34814— The syslog message 305010 includes the duration of the Xlate translation. However, this duration is always equal to the xlate idle timeout. Workaround: Use the timestamps in the creation and tear down of the xlate connections to calculate the xlate duration.
•CSCsz77633—When there are more than 14 Layer 4 sticky connection requests and the ACE is processing both Layer 4 and Layer 7 traffic either in the same context or in different contexts, the ACE incorrectly resets and drops the connections after traffic is sent for some duration. Workaround: None.
•CSCsz86630, CSCtb44983—When you upgrade the ACE from version A2(1.1) to A2(1.2) or greater, the DNS Inspect function may not work after the upgrade. When this condition exists, the following two errors occur under me-stats -sfixup statistics: +[Hash miss errors] + [NAT app fixup response error]. Workaround: Disable DNS Inspect and configure more aggressive timeouts (for example, 4 seconds) for UDP and port 53.
•CSCta03825, CSCtb44976—When the UDP booster feature is enabled, every first packet is not forwarded to the real server on each NP, which results in two packets being dropped per session. Workaround: Disable the UDP booster feature.
•CSCta29049, CSCtb44970—When the UDP booster feature is enabled, the ACE drops UDP packets that originate from the server. Workaround: Disable the UDP booster feature.
•CSCta93957—If you upgrade a redundant ACE pair to software version A2(2.1), downgrade the standby to software version A2(1.4) and allow the pair to synchronize configurations, and then upgrade the standby again to A2(2.1), the standby ACE does not lock configuration mode, allowing you to make configuration mode changes. Workaround: Enable a bulk synchronization by entering the no ft auto-sync command followed by the ft auto-sync command on the active ACE.
•CSCtb05686—When an interface is configured with multiple service policies and you delete one of the service policies, the Layer 7 connections in the other service policies may reset. Workaround: None.
•CSCtb47541—When "failaction reassign" is enabled in a firewall load-balancing configuration under the server farm and all of the rservers in the server farm are down and their probes all fail at the same time, the ACE becomes unresponsive to most CLI commands. When this condition occurs, the CPU spikes up to 100 percent by the cfgmgr process. This condition does not occur if any of the rservers are online and are passing any probe. Workaround: Disable the failaction reassign command under the server farm.
Software Version A2(3.0) Open Caveats
The following open caveats apply to software version A2(3.0):
•CSCse12120—When you press Ctrl-D and attempt to log in to the ACE with a valid username and password using the session command through EOBC from the supervisor engine, the login attempt fails. Workaround: Press Ctrl-D twice to access the switch login, and then log in.
•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 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 command: host1/Admin# ssh key rsa 1024 force.
•CSCsm93110—When you configure Microsoft Internet Information Services (IIS) version 5.0 to accept client certificates, SSL initiation through the ACE may fail. Workaround: Upgrade to IIS version 6.0.
•CSCso33506—In a redundant configuration with the FT pair running mismatched code (A1(x) and A2(x)) and mismatched licenses, if the active ACE is rebooted, the Admin context comes up, but, in user contexts, the running-config file is blank. This behavior occurs only when there is both a license and a code mismatch. Workaround: Resolve one of the mismatches and reload the ACEs or enter the copy start run command in each user context.
•CSCso55790—While trying to copy core dump files from the core: directory to an FTP server, the copy operation fails and the following error message is displayed:
local: /TN-COREFILE/core.618: Permission denied
Workaround: Copy the files from debug or from the console after you modify the permissions using debug.
•CSCso76159—When you dynamically modify a service policy to use an HTTP parameter map with the header modify per request command, the ACE does not insert a header into every GET request for existing long-lived persistent flows. However, the ACE does insert a header into every GET request for new flows. Workaround: None.
•CSCso82657—While moving a VLAN from a Cisco Firewall Services Module (FWSM) to an ACE or from an ACE to an FWSM, IP routing is not updated on the ACE to reflect the change. This behavior occurs when you are making a change to the svclc commands and the shut and no shut commands on the ACE interfaces. Workaround: None.
•CSCsq03035—The ACE was configured with an idle timeout of 0 (never time out), while TCP and UDP traffic was sent and left in an idle state over an extended period of time. The idle timeout was then changed from infinite to 60 seconds. The UDP traffic was immediately cleared, while the TCP traffic was not. After waiting more than 15 minutes, the idle TCP flows still had not been cleared. Workaround: None.
•CSCsq64401—If you configure the switch-mode command in an ACTIVE user context in a redundant configuration, the command is not synchronized to the STANDBY_HOT user context on the other ACE. This problem occurs only in a redundant configuration where an ACE has its Admin context in the STANDBY_HOT state and a user context in the ACTIVE state.
There are two possible workarounds for this behavior as follows:
•Never allow a user context to be in the ACTIVE state on the standby ACE.
•Reload the ACE that has its user context in the STANDBY_HOT state.
•CSCsr01570, CSCsy90965—The Set-Cookie: length is null. Changing the default class-map from a sticky server farm to none does not eliminate a cookie insertion. Workaround: Remove and then reenter the class class-default command.
•CSCsr76812—When you configure the ACE with Layer 7 load balancing, TCP connection may be disrupted. Packets arrive at the client in reverse order or packets are forced to be resent. Workaround: None.
•CSCsu76777—When you have configured context names that use special characters that are interpreted by the command shell (for example, semicolon, pipe, and so on) and you enter the write memory all command, the command generates errors and the output shows the attempted execution of shell commands. Workaround: When you define a context name, avoid using white space or any of the following special characters: `$&*()\|;'"<>/?.
•CSCsv09963—When you repeatedly add and remove VLANs on a context, the ACE loses memory. Workaround: None.
•CSCsv31046—When you configure the least-connections predictor on the ACE, the ACE may not sustain 160,000 CPS traffic. Workaround: None.
•CSCsv54222—When an HTTP client sends pipelined requests, if the next request comes in the middle of the server response, the HTTP connection becomes unresponsive and data is missing on the web page. Workaround: Configure a connection parameter-map with the set tcp wan-optimization rtt 0 command.
•CSCsv92321, CSCsx25981—The ACE module reboots unexpectedly and writes a core file to disk. Workaround: None.
•CSCsw51821—When you enable RTSP inspection on the ACE and the server sends the next request without responding to the previous client request, a static parse error occurs and the packet is dropped. Also if you configure RTSP inspection on the ACE, the ACE resets the connection. Workaround: Make sure that the server responds to every client request with the proper return code (for example, 200 OK) before sending the next request.
•CSCsx05150—When using 2048-bit certificate and key pairs with block and export ciphers, a rehandshake may lead to stuck connections. Workaround: Either use nonblock and nonexport ciphers or use certificate and key pairs that are less than 2048 bits.
•CSCsx13147—When you import a number of SSL PKI key or certificate files into a context by using the crypto import command, if you remove the context without first removing the files through the crypto delete command, the ACE may not import additional SSL PKI key or certificate files. The failure is due to a lack of resources or during a subsequent file import process, some or all of the previously imported key or certificate files may be forcibly removed from some or all contexts. Workaround: Use the crypto delete command to explicitly delete the SSL PKI key or certificate files from the contexts before removing the context. Try rebooting the ACE if this problem has already happened.
•CSCsx28656—When you create a large configuration consisting of interfaces and ACLs in a redundant configuration, if you remove a context from the active ACE, the context is not removed from the standby and the standby ACE transitions to the Hot state even though configuration synchronization failed. Workaround: Disable redundancy. Remove the configuration manually from the standby ACE and then reenable redundancy.
•CSCsx37047—When you configure and unconfigure an object group on an ACE, it allows invalid traffic and the acl-merge list becomes corrupted. Workaround: Remove and readd the access group to the interface or globally.
•CSCsx38885—When the ACE contains a large configuration, if you quickly add and remove multiple class maps under a Layer 7 policy map, API timeout errors occur. Workaround: Do not add and remove class maps under a Layer 7 policy map in quick succession.
•CSCsx41539—The ACE module may reboot and generate the following core files:
last boot reason: NP 0 Failed : NP Process Crashed
182284 Feb 1 15:53:45 2009 qnx_1_mecore_log.999.tar.gz
687601 Feb 1 15:53:41 2009 qnx_1_io-net_core_log.114693.tar.gz
113726 Feb 1 15:53:47 2009 ixp1_crash.txt
Workaround: None.
•CSCsx41858—When you configure redundancy on the ACE and it reboots, IP connectivity to and from the ACE fails. For example, if you Telnet or ping to or from the ACE, it fails. All the interfaces are down for the following reason:
VLAN not assigned from the supervisor
Workaround: Reconfigure the VLANs and the svclc module number vlan-group number command on the Supervisor module.
•CSCsx52128—When you copy a large configuration with many ACLs to the running-config file and perform other configuration changes continuously, the aclmerged process does not get the CPU and also the configurations result in API errors. Workaround: When you copy a large configuration with many ACLs to the running-config file, wait approximately 2 minutes for it to complete. Do not perform any configuration changes at that time.
•CSCsx80363—When the ACE uses a single IP source NAT with server connection reuse, PAT, and a high rate of traffic of approximately 30,000 connections per second in a one-arm topology, it reboots. Workaround: None.
•CSCsx80970—When you configure a multi-match policy map with more than one class map, if you perform an inspect policy change in a class map, the traffic to other class maps may be hit. Workaround: Do not make any inspect changes on the multi-match policy map when traffic is running.
•CSCsy04371—When a server farm with no backup transitions to the Inactive state after all the real servers transition to the MAXCONNS state, if the real servers transition out of the MAXCONNS state, they may not accept connections. Workaround: Configure a backup to the server farm.
•CSCsy23268—The ACE may send probe traffic with the source IP address of the alias IP address instead of the local interface IP address. This issue occurs on the active ACE only. Workaround: None.
•CSCsy29181—If either of the DP processors is at MAXCONN, the ACE should show MAXCONN in the show commands. However, the ACE waits until both DP processors are at MAXCONN. This issue occurs when the cde-same-port-hash is configured. Workaround: None.
•CSCsy65650—When the ACE reports the termination of TCP flows, it may display incorrect values for the duration and amount of data transferred. This issue occurs with HTTP and connections that are terminated with TCP RST. Workaround: None. If accounting is needed and relies on this log, use another method.
•CSCsy88379—The TAC diagnostic script showtech generates large output due to the show xlate command. Workaround: None.
•CSCsy98701—The standby ACE generates a load-balancing core file when you configure two ACEs as FT pairs that are replicating sticky entries and you enter certain show commands on the active/master ACE. Workaround: None.
•CSCsz10107—When you configure preempt and the Catalyst 6500 with an active ACE module is reloaded, the ACE may not correctly replicate connections when it reboots and becomes active again. Some connections may get dropped. Workaround: None. This issue does not occur when reloading only the ACE or if preempt is not configured.
•CSCsz14634—The ACE has issues when you copy large configurations from TFTP to the running-configuration and use the snmp-server community command to add the public group Network-Monitor to a context when the command was not in the original configuration. Workaround: None.
•CSCsz18739—The ACE reloads when running software version A2(1.4) and RADIUS AAA is configured. Workaround: None.
•CSCsz19849—You cannot import an ACE VIP in WAF. Importing works in software version A2(1.2) and in A2(1.3). Workaround: None.
•CSCsz28035—Accessing the qnx shell from the physical console port of either NP on an ACE puts you in a shell. If you type exit, the NP console hangs and becomes inaccessible. Workaround: None.
•CSCsz31739—When the VIP is out of service and loadbalance icmp-reply is not configured, the virtual server entry still exists in the ARP cache. The ACE will respond to ARP requests sent for this VIP. Workaround: None.
•CSCsz34011—After a series of reboots, both ACE modules lose their context configurations. If the active ACE halts and reloads, after it reboots it will read the first half of the startup-config, establish FT with the standby ACE (the new active), and synchronized the configuration to obtain the rest of the configurations from the other ACE. If the other ACE stops functioning, the active ACE will not have obtained the rest of the configurations, including context configurations. Context configurations may be lost, although they still exist in the startup-config. Workaround: None.
•CSCsz34933—The ACE may send a reset with the sequence number zero for a probe configured with the connection term forced command. Workaround: Use the graceful termination no connection term command.
•CSCsz40699—When you use the SLB-Admin, Server-Appln-Maintenance, or a custom role with a create feature server farm rule, you cannot bring real servers in or out of service under the server farm. Workaround: None. There are currently no workarounds using these specific roles. However, you can complete these tasks using the Admin role.
•CSCsz49088—When you monitor the ACE CPU, you can only monitor it using an Admin role. The show processes cpu command is available only in the Admin role. The Network-Monitor role, which should have access to all show commands is unable to access the show processes cpu command. Configuring a new role on the ACE does not allow you to monitor the system feature. Therefore, only Admin users are able to run this command. Workaround: Run the show processes cpu command in an Admin role.
•CSCsz67761—When a network error, such as a network interface going down, occurs during the bulk importing of crypto files, the temporary storage space for imported crypto files is not gracefully released. Some of the temporary files remain in the temporary storage area until the system is reloaded. Bulk import procedures currently do not perceive network failures or inactivity if the transfer of the files has begun. Workaround: None.
•CSCsz85367—When you configure and unconfigure access lists in a loop, the ACE experiences a memory leak. Workaround: Do not configure and unconfigure access lists in a loop.
•CSCta20756, CSCsx15558—When the ACE has over 120,000 concurrent SSL connections, it displays SSL connection rate denies, FastQ transmit back pressure, and SSL RX back pressure. Eventually, the ACE becomes unresponsive. Workaround: None.
•CSCta39372—When you perform repetitive checkpoint rollbacks, the ACE becomes unresponsive after 5 to 6 hours. Workaround: None.
•CSCta45580—When the ACE is unable to download a CRL because the CRL server is down, it does not always attempt another download when the CRL server returns to an online state. This condition occurs when more than 50 VIPs use the same SSL proxy with CRL applied. Workaround: Remove the CRL configuration and then configure it again.
•CSCta73571—When you configure ft track for an interface that is constantly down and then attempt a checkpoint rollback from a large configuration to an empty configuration, the rollback ends prematurely, resulting in a partial rollback. The ACE, however, indicates that the rollback is complete. Workaround: Attempt the rollback once again. If it fails again, configure ft track with a greater difference between the active and standby priority settings.
•CSCta83978—If you download an unusually large number of best-effort CRLs from a server, the SSL process on the control plane may become unresponsive. Workaround: Do not use best-effort CRLs.
•CSCta92673—When SSL traffic is flowing and you reconfigure SSL proxies that contain authgroups, the ACE may leak memory in the control plane. The memory leak is directly proportional to the number of reconfigurations that you perform. Workaround: Avoiding reconfiguring an SSL proxy when an authgroup is applied to the proxy.
•CSCta92891—If you change the load-balance predictor from least conns to hash url with a mixed traffic flow that consists of both TCP and UDP, the ACE may become unresponsive and generate a loadBalance_g_ns core dump file. Workaround: None.
•CSCtb02056—When you configure the ACE with SSL certificates and keys in multiple contexts, the output of the show crypto certificate all command may become corrupted. Workaround: Use the show crypto certificate cert_name command instead of the show crypto certificate all command.
•CSCtb03138—When the configuration for the VLAN that you use as an SNMP trap source is missing either the IP address or peer IP address, the SNMP configuration does not synchronize to the standby ACE. This condition creates the following error: Incremental Sync Failure: snmp config syn. Workaround: Configure the VLAN with an IP address and peer IP address.
•CSCtc14102—When the total size of all headers exceeds the maximum size of 512 bytes, the CLI does not issue an error message to prevent the user from exceeding the limit. This condition results in the ACE deleting all configured header information. Workaround: None.
•CSCtc36837—When a client sends traffic to a secondary IP on a BVI interface in the standby ACE (peer secondary IP under the BVI), the ACE may not process the traffic correctly if either of the following conditions exist:
–The client knows the standby ACE MAC address, but the ACE has not learned the client MAC address.
–You clear the MAC address table in the Catalyst 6500 series switch or the Cisco 7600 series router and enter the clear arp-cache interface vlan vlan_id command.
Workaround: Enter the clear mac-address-table dynamic vlan vlan_id on the supervisor engine and the clear arp no-refresh command on the standby ACE. Then, ping the client PC from the standby ACE.
Available ACE Licenses
By default, the ACE supports virtualization with one Admin context and five user contexts, 4 gigabits per second (Gbps) module bandwidth, and 1,000 SSL transactions per second (TPS). You can increase the number of default user contexts, module bandwidth, and SSL TPS by purchasing the following licenses:
•ACE-VIRT-020—20 virtual contexts
•ACE-VIRT-050—50 virtual contexts
•ACE-VIRT-100—100 virtual contexts
•ACE-VIRT-250—250 virtual contexts
•ACE-08G-LIC—8 Gbps bandwidth
If you purchase an ACE with a bandwidth of 4 Gbps, you can upgrade the module bandwidth to 8 Gbps by using the ACE-UPG1-LIC license.
•ACE-16G-LIC—16 Gbps bandwidth (ACE20-MOD-K9 module only)
If you purchase an ACE with a bandwidth of 8 Gbps, you can upgrade the module bandwidth to 16 Gbps by using the ACE-UPG2-LIC license (ACE20-MOD-K9 module only).
•ACE-SSL-5K-K9—SSL with 5,000 TPS
•ACE-SSL-10K-K9—SSL with 10,000 TPS
•ACE-SSL-15K-K9—SSL with 15,000 TPS
You can upgrade virtualization in increments, provided that you do not exceed the limits of the ACE (a maximum of 250 contexts), by using the following licenses:
•ACE-VIRT-UP1—Upgrades 20 to 50 contexts
•ACE-VIRT-UP2—Upgrades 50 to 100 contexts
•ACE-VIRT-UP3—Upgrades 100 to 250 contexts
You can upgrade SSL in 5,000 TPS increments up to a maximum of 15,000 TPS by using the following SSL upgrade licenses:
•ACE-SSL-UP1-K9—Upgrades SSL from 5,000 TPS to 10,000 TPS (3.0(0)A1(3) or later)
•ACE-SSL-UP2-K9—Upgrades SSL from 10,000 TPS to 15,000 TPS (3.0(0)A1(3) or later)
You can also obtain an ACE demo license for each type of virtualization, bandwidth, or SSL TPS license, including upgrade increments for contexts. You can get a demo license that is valid between 30 and 90 days. At the end of this period, you will need to update the demo license with a permanent license to continue to use the ACE software. To view the expiration of the demo license, use the show license usage command in Exec mode. If you need to replace the ACE module, you can copy and install the licenses onto the replacement module.
Note You can access the license and show license commands only in the Admin context. You must have the Admin role in the Admin context to perform the tasks of installing, removing, and updating the license.
Ordering an Upgrade License and Generating a License Key
This section describes the process to order an upgrade license and to generate a license key for your ACE. To order an upgrade license, perform the following steps:
Step 1 Order one of the licenses from the list in the "Available ACE Licenses" section using any of the available Cisco ordering tools on Cisco.com.
Step 2 When you receive the Software License Claim Certificate from Cisco, follow the instructions that direct you to the cisco.com website. As a registered user of cisco.com, go to this URL:
http://www.cisco.com/go/license
Step 3 Enter the Product Authorization Key (PAK) number found on the license certificate as your proof of purchase.
Step 4 Provide all the requested information to generate a license key.
Step 5 After the system generates the license key, you will receive a license key e-mail with an attached license file and installation instructions. Save the license key e-mail in a safe place in case you need it in the future (for example, to transfer the license to another ACE).
For information about installing and managing ACE licenses, refer to Chapter 3, Managing ACE Software Licenses, in the Cisco Application Control Engine Module Administration Guide.
Upgrading Your ACE Software
For complete instructions on how to upgrade your ACE software, see the Cisco Application Control Engine Module Administration Guide.
Note To upgrade your ACE software to version A2(1.0) or higher, your ACE must be running software version 3.0(0)A1(5a) or higher.
An incompatibility exists between certain ACE software versions in the 3.0(0)A1.6.3x and A2.1x release trains. In a redundant configuration, the FT ACE pairs will not recognize each other and will report the following status as part of the show ft peer detail command output:
SRG Compatibility: INCOMPATIBLE
The following software version combinations that are indicated with an "x" are incompatible:
A1(6.3x) Release
|
A2(1.0)
|
A2(1.0a)
|
A2(1.1)
|
A2(1.1a)
|
A2(1.2)
|
A2(1.3)
|
A2(2.0)
|
3.0(0)A1(6.3b)
|
x
|
|
x
|
x
|
|
|
|
3.0(0)A1(6.3c)
|
x
|
x
|
x
|
x
|
|
|
|
Before you upgrade your ACE software, be sure that your ACE configurations meet the upgrade prerequisites in the following sections:
•Changing the Admin Password
•Changing the www User Password
•Checking Your Configuration for FT Priority and Preempt
•Creating a Checkpoint
•Updating Your Application Protocol Inspection Configurations
Changing the Admin Password
Before you upgrade to software version A2(1.0) or higher, you must change the default Admin password, if you have not already done so. Otherwise, after you upgrade the ACE software, you will be able to log in to the ACE only through the console port or through the supervisor engine of the Catalyst 6500 series switch or the Cisco 7600 series router. For details about changing the Admin password, see the Cisco Application Control Engine Module Administration Guide.
Changing the www User Password
Before you upgrade to software version A2(1.0) or higher, you must change the default www user password if you have not already done so. Otherwise, after you upgrade the ACE software, the www user will be disabled and you will not be able to use Extensible Markup Language (XML) to remotely configure an ACE until you change the default www user password. For details about changing the www user password, see the Cisco Application Control Engine Module Administration Guide.
Checking Your Configuration for FT Priority and Preempt
If you want the currently active ACE to remain active after the software upgrade, be sure that the active ACE has a higher priority than the standby (peer) ACE and that the preempt command is configured. To check the redundant configuration of your ACEs, use the show running-config ft command. The preempt command is enabled by default and does not appear in the running-config file.
Creating a Checkpoint
We strongly recommend that you create a checkpoint in the running-configuration file of each context in your ACE. A checkpoint creates a snapshot of your configuration that you can later roll back to in case a problem occurs with an upgrade and you want to downgrade the software to a previous release. Use the checkpoint create command in Exec mode in each context for which you want to create a configuration checkpoint and name the checkpoint. For details about creating a checkpoint and rolling back a configuration, see Cisco Application Control Engine Module Administration Guide. For information about downgrading your ACE, see the "Downgrading Your ACE Software from Version A2(1.0) or Higher to 3.0(0)A1(6.x) in a Redundant Configuration" section.
Updating Your Application Protocol Inspection Configurations
Because the ACE version A2(1.0) or higher software has stricter error checks for application protocol inspection configurations than A1(x) software versions, be sure that your inspection configurations meet the guidelines that follow. The error checking process in A2(1.0) or higher software denies misconfigurations in inspection classifications (class maps) and displays error messages. If such misconfigurations exist in your startup- or running-configuration file before you load the A2(1.0) or higher software, the standby ACE in a redundant configuration may boot up to the STANDBY_COLD state. For information about redundancy states, see the Cisco Application Control Engine Module Administration Guide.
If the class map for the inspection traffic is generic (match . . . any or class-default is configured) so that noninspection traffic is also matched, the ACE displays an error message and does not accept the inspection configuration. For example:
switch/Admin(config)# class-map match-all TCP_ANY
switch/Admin(config-cmap)# match port tcp any
switch/Admin(config)# policy-map multi-match FTP_POLICY
switch/Admin(config-pmap)# class TCP_ANY
switch/Admin(config-pmap-c)# inspect ftp
Error: This class doesn't have tcp protocol and a specific port
The following examples show some of the generic class-map match statements and an ACL that are not allowed in A2(1.0) or higher inspection configurations:
•match port tcp any
•match port udp any
•match port tcp range 0 65535
•match port udp range 0 65535
•match virtual-address 192.168.12.15 255.255.255.0 any
•match virtual-address 192.168.12.15 255.255.255.0 tcp any
•access-list acl1 line 10 extended permit ip any any
For application protocol inspection, the class map must have a specific protocol (related to the inspection type) configured and a specific port or range of port numbers.
For HTTP, FTP, RTSP, Skinny, and ILS protocol inspection, the class map must have TCP as the configured protocol and a specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port tcp eq www
For SIP protocol inspection, the class map must have TCP or UDP as the configured protocol and a specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port tcp eq 124
or
host1/Admin(config-cmap)# match port udp eq 135
For DNS inspection, the class map must have UDP as the configured protocol and a specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port udp eq domain
For ICMP protocol inspection, the class map must have ICMP as the configured protocol. For example, enter the following commands:
host1/Admin(config)# access-list ACL1 extended permit icmp 192.168.12.15 255.255.255.0
192.168.16.25 255.255.255.0 echo
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match access-list ACL1
Downgrading Your ACE Software from Version A2(1.0) or Higher to 3.0(0)A1(6.x) in a Redundant Configuration
If you need to downgrade your ACE software from version A2(1.0) or higher to an earlier version, use the procedure that follows. You can downgrade your ACE from software version A2(1.0) or higher to 3.0(0)A1(6.1) or higher. Downgrading your ACE software to a software version below 3.0(0)A1(6.1) is not supported and not recommended. We recommend that you downgrade to the highest 3.0(0)A1(6.x) software version that is available. This procedure assumes that your ACEs are configured as redundant peers to ensure that there is no disruption to existing connections during the downgrade process. In the following procedure, the active ACE is referred to as ACE-1 and the standby ACE is referred to as ACE-2.
This section contains the following topics:
•Before You Begin
•Downgrade Procedure
Before You Begin
Before you downgrade your ACE software, ensure that the following conditions exist:
•Identical versions of 3.0(0)A1(6.x) software images reside in the image: directory of both ACEs.
•The active ACE has a higher priority than the standby ACE and preempt is enabled on the FT group if you want the active ACE to remain active after the downgrade procedure.
Downgrade Procedure
To downgrade your A2(1.0) or higher software in a redundant configuration, perform the following steps:
Step 1 If you have created checkpoints in your 3.0(0)A1(6.x) running-configuration files (highly recommended), roll back the configuration in each context on each ACE to the check-pointed configuration. For example:
host1/Admin# checkpoint rollback CHECKPOINT_ADMIN
host1/C1# checkpoint rollback CHECKPOINT_C1
Do the same on the other ACE. For information about creating checkpoints and rolling back configurations, see Chapter 4, Managing the ACE Software.
Step 2 Configure ACE-1 to automatically boot from the 3.0(0)A1(6.x) image. To set the boot variable and configuration register to 1, use the boot system image: and config-register commands in configuration mode. For example, enter the following command:
host1/Admin(config)# boot system image:c6ace-t1k9-mzg.3.0.0_A1_6_3.bin
host1/Admin(config)# config-register 1
host1/Admin(config)# exit
You can set up to two images through the boot system command. If the first image fails, the ACE tries to boot from the second image.
Note Use the no boot system image: command to remove the configured A2(1.x) or higher boot variable.
Step 3 Verify that the boot variable was synchronized to ACE-2 by entering the following command on ACE-2:
host1/Admin# show bootvar
BOOT variable = "disk0:c6ace-t1k9-mzg.3.0.0_A1_6_3.bin"
Configuration register is 0x1
Step 4 Use the show ft group detail command to verify the state of each module. Upgrade the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload command.When ACE-2 loads the startup-configuration file, you may observe a few errors if you did not roll back the configuration to a checkpoint. These errors are harmless and occur because the 3.0(0)A1(6.x) software does not recognize the A2(1.x) or higher 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 3.0(0)A1(6.x) software version as ACE-2. Again, you may observe a few errors as ACE-1 loads the startup-configuration file.
After ACE-1 boots up, it assumes the role of standby and enters the STANDBY_HOT state (this may take several minutes). You can verify the states of both ACEs by entering the show ft group detail command in Exec mode. Because both ACE-1 and ACE-2 are running the same version of software now, configuration mode is enabled. The configuration is synchronized from ACE 2 (currently active) to ACE-1. If ACE-1 is configured with a higher priority and preempt is configured on the FT group, ACE-1 reasserts mastership after it has received all configuration and state information from ACE-2, making ACE-2 the new standby. ACE-1 becomes the active ACE once again.
Step 7 Perform manual cleanup in the running-configuration files of both ACEs to remove unnecessary version A2(1.0) or higher configuration elements. For example, you may need to remove a service policy from an interface that was part of the version A2(1.x) or higher configuration that is no longer needed in version 3.0(0)A1(6.x).
Step 8 Enter the write memory all command in both ACEs to save the running-configuration files in all configured contexts to their respective startup-configuration files. This action will eliminate future errors when the ACEs reload their startup-configuration files.
ACE Documentation Set
In addition to this document, the ACE documentation set includes the following publications:
Document Title
|
Description
|
Cisco Application Control Engine Module Hardware Installation Note
|
This guide provides information for installing the ACE into the Catalyst 6500 series switch and the Cisco 7600 series router.
|
Cisco Application Control Engine Module Getting Started Guide
|
This guide describes how to perform the initial setup and configuration tasks for the ACE.
|
Cisco Application Control Engine Module Administration Guide
|
This guide describes how to perform administration tasks on the ACE, including initial setup, establish remote access, configure class maps and policy maps, manage the ACE software, configure SNMP, define system message logging, configure redundancy, and upgrade your ACE software.
|
Cisco Application Control Engine Module Virtualization Configuration Guide
|
This guide provides instructions on how to operate your ACE in a single-context or in multiple-contexts. Multiple-contexts use the concept of virtualization to partition your ACE into multiple virtual devices or contexts.
|
Cisco Application Control Engine Module Routing and Bridging Configuration Guide
|
This guide provides instructions for configuring the routing and bridging features of the ACE. This guide provides a routing overview and describes how to perform ACE configuration tasks, including:
•Configuring VLANs
•Configuring routing
•Configuring bridging
•Configuring Address Resolution Protocol (ARP)
•Configuring Dynamic Host Configuration Protocol (DHCP)
|
Cisco Application Control Engine Module Server Load-Balancing Configuration Guide
|
This guide describes how to perform ACE server load-balancing configuration tasks, including:
•Server health monitoring
•Real servers and server farms
•Stickiness
•Class maps and policy maps to load-balance traffic to real servers in server farms
•Firewall load balancing
•TCL scripts
|
Cisco Application Control Engine Module Security Configuration Guide
|
This guide describes how to perform ACE security configuration tasks, including:
•Security access control lists (ACLs)
•User authentication and accounting using a TACACS+, RADIUS, or LDAP server
•Application protocol and HTTP deep packet inspection
•TCP/IP normalization and termination parameters
•Network address translation (NAT)
|
Cisco Application Control Engine Module SSL Configuration Guide
|
This guide describes how to perform ACE SSL configuration tasks, including:
•SSL certificates and keys
•SSL initiation
•SSL termination
•End-to-end SSL
|
Cisco Application Control Engine Module System Message Guide
|
Describes how to configure system message logging on the ACE. This guide lists and describes the system log messages generated by the ACE.
|
Cisco Application Control Engine Module Command Reference
|
This reference provides an alphabetical list of all command line interface (CLI) commands including syntax, options, and related commands.
|
Cisco CSM-to-ACE Conversion Tool User Guide
|
Describes how to use the CSM-to-ACE conversion tool to migrate Cisco Content Switching Module (CSM) running-configuration or startup-configuration files to the ACE.
|
Cisco CSS-to-ACE Conversion Tool User Guide
|
Describes how to use the CSS-to-ACE conversion tool to migrate Cisco Content Services Switches (CSS) running-configuration or startup-configuration files to the ACE.
|
Cisco Application Control Engine (ACE) Module Troubleshooting Guide, Release A2(x)
|
Describes the procedures and methodology in wiki format to troubleshoot the most common problems that you may encounter during the operation of your ACE.
|
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, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Pulse, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, 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, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Fast Step, Follow Me Browsing, FormShare, GainMaker, GigaDrive, HomeLink, iLYNX, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, 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. (0908R)
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.
© 2009 Cisco Systems, Inc. All rights reserved.
