PDF - Complete Book

Cisco Application Control Engine Module
Administration Guide
Software Version A2(3.0)
October 2009
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
Text Part Number: OL-20814-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at
www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1005R)
Cisco Application Control Engine Module Administration Guide
Copyright © 2007-2009 Cisco Systems, Inc. All rights reserved.
CONTENTS
Preface
xi
Audience
xi
How to Use This Guide
xii
Related Documentation
xiii
Symbols and Conventions
xiv
Obtaining Documentation, Obtaining Support, and Security Guidelines
CHAPTER
1
Setting Up the ACE
1-1
Prerequisites for Setting Up the ACE
Default Settings
xvi
1-2
1-2
Setting Up the ACE 1-3
Establishing a Console Connection on the ACE 1-3
Sessioning and Logging In to the ACE 1-4
Changing or Resetting the Administrative Password 1-6
Changing the Administrative Password 1-6
Resetting the Administrator Account Password 1-7
Assigning a Name to the ACE 1-9
Configuring an ACE Inactivity Timeout 1-9
Configuring a Message-of-the-Day Banner 1-10
Configuring the Date and Time 1-12
Configuring the Time Zone 1-12
Adjusting for Daylight Saving Time 1-15
Configuring Terminal Settings 1-17
Configuring Terminal Display Attributes 1-17
Configuring Console Line Settings 1-19
Configuring Virtual Terminal Line Settings 1-20
Modifying the Boot Configuration 1-21
Setting the Boot Method from the Configuration Register 1-21
Setting the BOOT Environment Variable 1-22
Restarting the ACE 1-23
Restarting the ACE from the CLI 1-24
Restarting the ACE from the Catalyst CLI 1-24
Using ROMMON to Specify the System Boot Image During a Restart
Shutting Down the ACE 1-26
1-25
Cisco Application Control Engine Module Administration Guide
OL-20814-01
iii
Contents
Displaying the ACE Setup Configuration
CHAPTER
2
Enabling Remote Access to the ACE
Guidelines and Limitations
Default Settings
1-27
2-1
2-2
2-2
Enabling Remote Access to the ACE 2-3
Task Flow for Enabling Remote Access to the ACE 2-3
Configuring Remote Network Management Traffic Services 2-4
Creating and Configuring a Remote Management Class Map 2-5
Creating a Layer 3 and Layer 4 Remote Access Policy Map 2-8
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
Applying a Service Policy to a Specific VLAN Interface 2-12
Configuring the Maximum Number of Telnet Management Sessions 2-14
Configuring SSH Management Session Parameters 2-15
Configuring Maximum Number of SSH Sessions 2-16
Generating SSH Host Key Pairs 2-16
Terminating an Active User Session 2-19
Enabling ICMP Messages to the ACE 2-19
Directly Accessing a User Context Through SSH 2-20
Displaying Remote Access Session Information 2-22
Displaying Telnet Session Information 2-22
Displaying SSH Session Information 2-22
Displaying Other Remote Access Session Information
2-23
Configuration Example for Enabling Remote Access to the ACE
CHAPTER
3
Managing ACE Software Licenses
Information about ACE Licenses
Guidelines and Limitations
Prerequisites
2-11
2-24
3-1
3-1
3-2
3-2
Default License Feature Capabilities
3-2
Managing ACE Module Software Licenses 3-3
Tasks for Ordering an Upgrade License and Generating a Key
Copying a License File to the ACE 3-3
Installing a New or Upgrade License File 3-4
Replacing a Demo License with a Permanent License 3-6
Removing a License 3-6
Removing a Bandwidth or SSL License 3-7
Removing a Virtual Context License 3-7
3-3
Cisco Application Control Engine Module Administration Guide
iv
OL-20814-01
Contents
Backing Up an ACE License File 3-9
Retrieving an ACE License File 3-10
Displaying ACE License Configurations and Statistics
CHAPTER
4
Managing the ACE Software
3-11
4-1
Saving Configuration Files 4-1
Saving the Configuration File in Flash Memory 4-2
Saving Configuration Files to a Remote Server 4-2
Copying the Configuration File to the disk0: File System 4-3
Merging the Startup-Configuration File with the Running-Configuration File
Displaying Configuration File Content 4-4
Clearing the Startup-Configuration File 4-6
Copying Configuration Files from a Remote Server
4-4
4-7
Displaying the Configuration Download Progress Status
4-8
Using the File System on the ACE 4-9
Copying Files 4-10
Copying Files to Another Directory on the ACE 4-10
Copying Licenses 4-11
Copying a Packet Capture Buffer 4-12
Copying Files to a Remote Server 4-12
Copying Files from a Remote Server 4-14
Copying an ACE Software System Image to a Remote Server
Uncompressing Files in the disk0: File System 4-15
Untarring Files in the disk0: File System 4-16
Creating a New Directory 4-17
Deleting an Existing Directory 4-17
Moving Files 4-17
Deleting Files 4-18
Displaying Files Residing On the ACE 4-19
Saving show Command Output to a File 4-20
4-14
Using Backup and Restore 4-22
Information About the Backup and Restore Features 4-22
Archive File 4-23
Archive Naming Conventions 4-23
Archive Directory Structure and Filenames 4-23
Guidelines and Limitations 4-24
Defaults 4-25
Backing Up the ACE Configuration Files and Dependencies 4-25
Restoring the ACE Configuration Files and Dependencies 4-27
Cisco Application Control Engine Module Administration Guide
OL-20814-01
v
Contents
Copying a Backup Archive to a Server 4-31
Displaying the Status of the Backup Operation 4-32
Displaying the Status of the Restoration 4-33
Displaying Backup and Restore Errors 4-33
Managing Core Dump Files 4-35
Copying Core Dumps 4-35
Clearing the Core Directory 4-36
Deleting a Core Dump File 4-37
Capturing Packet Information 4-37
Enabling the Packet Capture Function 4-38
Copying Packet Capture Buffer Information 4-40
Displaying or Clearing Packet Information 4-41
Displaying Packet Information 4-41
Clearing Capture Buffer Information 4-42
Using the Configuration Checkpoint and Rollback Service
Creating a Configuration Checkpoint 4-42
Deleting a Configuration Checkpoint 4-43
Rolling Back a Running Configuration 4-44
Displaying Checkpoint Information 4-44
Reformatting the Flash Memory
CHAPTER
5
4-42
4-45
Displaying ACE Hardware and Software System Information
5-1
Information About Displaying ACE Hardware and Software Information
Displaying Hardware Information
5-1
5-2
Displaying Installed Software Information
5-3
Displaying System Processes and Memory Resources Limits 5-4
Displaying General System Process Information 5-4
Displaying Detailed Process Status Information and Memory Resource Limits
Displaying System Information
5-9
Displaying or Clearing ICMP Statistics
5-11
Displaying or Collecting Technical Information for Reporting Problems
CHAPTER
6
Configuring Redundant ACEs
5-7
5-12
6-1
Information About Redundancy 6-1
Redundancy Protocol 6-2
Stateful Failover 6-3
FT VLAN 6-4
Configuration Synchronization 6-4
Cisco Application Control Engine Module Administration Guide
vi
OL-20814-01
Contents
Redundancy State for Software Upgrade or Downgrade
Guidelines and Limitations
Default Settings
6-5
6-5
6-6
Configuring Redundant ACEs 6-7
Task Flow for Configuring Redundancy 6-7
Configuring Redundancy 6-8
Configuring an FT VLAN 6-9
Configuring an Alias IP Address 6-10
Configuring an FT Peer 6-11
Configuring an FT Group 6-13
Modifying an FT Group 6-15
Specifying the Peer Hostname 6-16
Specifying the MAC Address Banks for a Shared VLAN 6-16
Forcing a Failover 6-17
Synchronizing Redundant Configurations 6-19
Configuring Tracking and Failure Detection 6-21
Configuring Tracking and Failure Detection for a Host or Gateway 6-22
Configuring Tracking and Failure Detection for an Interface 6-25
Configuring Tracking and Failure Detection for an HSRP Group 6-27
Displaying or Clearing Redundancy Information 6-30
Displaying Redundancy Information 6-30
Displaying Redundancy Configuration Information 6-31
Displaying Bulk Synchronization Command Failures on the Standby ACE
Displaying FT Group Information 6-32
Displaying the Redundancy Internal Software History 6-35
Displaying the IDMAP Table 6-35
Displaying Memory Statistics 6-36
Displaying Peer Information 6-36
Displaying FT Statistics 6-38
Displaying FT Tracking Information 6-40
Clearing Redundancy Statistics 6-42
Clearing Transport-Layer Statistics 6-42
Clearing Heartbeat Statistics 6-43
Clearing Tracking-Related Statistics 6-43
Clearing All Redundancy Statistics 6-44
Clearing the Redundancy History 6-44
Configuration Example of Redundancy
6-31
6-44
Cisco Application Control Engine Module Administration Guide
OL-20814-01
vii
Contents
CHAPTER
7
Configuring SNMP
7-1
Information About SNMP 7-1
Managers and Agents 7-2
SNMP Manager and Agent Communication 7-2
SNMP Traps and Informs 7-3
SNMPv3 CLI User Management and AAA Integration
CLI and SNMP User Synchronization 7-4
Multiple String Index Guidelines 7-4
Supported MIBs and Notifications 7-5
Default Settings for SNMP
7-3
7-30
Configuring SNMP 7-30
Task Flow for Configuring SNMP 7-31
Configuring SNMP Users 7-32
Defining SNMP Communities 7-35
Configuring an SNMP Contact 7-36
Configuring an SNMP Location 7-37
Configuring SNMP Notifications 7-38
Configuring SNMP Notification Hosts 7-38
Enabling SNMP Notifications 7-40
Enabling the IETF Standard for SNMP linkUp and linkDown Traps 7-42
Unmasking the SNMP Community Name and Community Security Name OIDs 7-43
Assigning a Trap-Source Interface for SNMP Traps 7-44
Accessing ACE User Context Data Through the Admin Context IP Address 7-45
Accessing User Context Data When Using SNMPv1/v2 7-45
Accessing User Context Data When Using SNMPv3 7-46
Configuring an SNMPv3 Engine ID for an ACE Context 7-46
Configuring SNMP Management Traffic Services 7-47
Creating and Configuring a Layer 3 and Layer 4 Class Map 7-48
Creating a Layer 3 and Layer 4 Policy Map 7-50
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context 7-52
Applying a Service Policy to a Specific VLAN Interface 7-53
Displaying or Clearing SNMP and Service Policy Statistics
Displaying SNMP and Service Policy Statics 7-55
Displaying SNMP Statistical Information 7-55
Displaying SNMP Service Policy Statistics 7-58
Clearing SNMP Service Policy Statistics 7-59
Example of an SNMP Configuration
7-55
7-59
Cisco Application Control Engine Module Administration Guide
viii
OL-20814-01
Contents
CHAPTER
8
Configuring the XML Interface
8-1
Information About XML 8-1
HTTP and HTTPS Support with the ACE
HTTP Return Codes 8-3
Document Type Definition 8-4
Guidelines and Limitations
Default Settings
8-2
8-6
8-6
Configuring the XML Interface 8-7
Task Flow for Configuring XML 8-7
Configuring HTTP and HTTPS Management Traffic Services 8-8
Creating and Configuring a Class Map 8-8
Creating a Layer 3 and Layer 4 Policy Map 8-10
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context 8-13
Applying a Service Policy to a Specific VLAN Interface 8-14
Enabling the Display of Raw XML Request show Command Output in XML Format 8-15
Accessing the ACE DTD File 8-18
Displaying or Clearing XML Service Policy Statistics
Displaying XML Service Policy Statistics 8-19
Clearing XML Service Policy Statistics 8-19
Example of ACE CLI Command and the XML Equivalent
APPENDIX
A
Upgrading or Downgrading Your ACE Software
Overview of Upgrading ACE Software
8-19
8-20
A-1
A-1
Prerequisites for Upgrading Your ACE A-2
Changing the Admin Password A-2
Changing the www User Password A-2
Checking Your Configuration for FT Priority and Preempt A-2
Creating a Checkpoint A-2
Updating Your Application Protocol Inspection Configurations A-3
Performing Software Upgrades and Downgrades A-4
Task Flow for Upgrading the ACE Software A-4
Task Flow for Downgrading the ACE Software A-7
Copying the Software Upgrade Image to the ACE A-9
Configuring the ACE to Autoboot the Software Image A-10
Setting the Boot Variable A-10
Configuring the Configuration Register to Autoboot the Boot Variable
Reloading the ACE A-11
Recovering the ACE from the ROMMON Utility A-12
A-11
Cisco Application Control Engine Module Administration Guide
OL-20814-01
ix
Contents
Booting the ACE from ROMMON with the Correct Image Name A-12
Booting the ACE from an Image Copied to the Supervisor Engine A-14
Displaying Software Image Information A-15
Displaying the Boot Variable and Configuration Register
Displaying the Software Version A-15
A-15
INDEX
Cisco Application Control Engine Module Administration Guide
x
OL-20814-01
Preface
This guide provides instructions for the administration of the Cisco Application Control Engine (ACE)
module in a Catalyst 6500 series switch or a Cisco 7600 series router, hereinafter referred to as the
switch or router, respectively.
It describes how to perform administration tasks on the ACE, including doing the initial setup,
establishing remote access, managing software licenses, configuring class maps and policy maps,
managing the ACE software, configuring Simple Network Management Protocol (SNMP), configuring
redundancy, configuring the Extensible Markup Language (XML) interface, and upgrading your ACE
software.
This preface contains the following major sections:
•
Audience
•
How to Use This Guide
•
Related Documentation
•
Symbols and Conventions
•
Obtaining Documentation, Obtaining Support, and Security Guidelines
Audience
This guide is intended for the following trained and qualified service personnel who are responsible for
configuring the ACE:
•
System administrator
•
System operator
Cisco Application Control Engine Module Administration Guide
OL-20814-01
xi
Preface
How to Use This Guide
This guide is organized as follows:
Chapter
Description
Chapter 1, “Setting Up the
ACE”
Describes how to configure basic settings on the ACE, including topics
such as how to session and log in to the ACE, change the
administrative username and password, assign a name to the ACE,
configure a message-of-the-day banner, configure the date and time,
configure terminal settings, modify the boot configuration, and restart
the ACE.
Chapter 2, Chapter 2,
“Enabling Remote Access to
the ACE”
Describes how to configure remote access to the Cisco Application
Control Engine (ACE) module by establishing a remote connection
using the Secure Shell (SSH) or Telnet protocols. It also describes how
to configure the ACE to provide direct access to a user context from
SSH. This chapter also covers how to configure the ACE to receive
ICMP messages from a host.
Chapter 3, “Managing ACE
Software Licenses”
Describes how to manage the software licenses for your ACE.
Chapter 4, “Managing the
ACE Software”
Describes how to save and download configuration files, use the file
system, view and copy core dumps, capture and copy packet
information, use the configuration checkpoint and rollback service,
display configuration information, and display technical support
information.
Chapter 5, “Displaying ACE
Hardware and Software
System Information”
Describes how to display ACE hardware and software configuration
and technical support information.
Chapter 6, “Configuring
Redundant ACEs”
Describes how to configure the ACE for redundancy, which provides
fault tolerance for the stateful failover of flows.
Chapter 7, “Configuring
SNMP”
Describes how to configure SNMP to query the ACE for Cisco
Management Information Bases (MIBs) and to send event
notifications to a network management system (NMS).
Chapter 8, “Configuring the
XML Interface”
Describes how to provide a mechanism using XML to transfer,
configure, and monitor objects in the ACE. This XML capability
allows you to easily shape or extend the CLI query and reply data in
XML format to meet different specific business needs.
Appendix A, “Upgrading or
Downgrading Your ACE
Software”
Describes how to upgrade or downgrade the software on your ACE.
Cisco Application Control Engine Module Administration Guide
xii
OL-20814-01
Preface
Related Documentation
In addition to this document, the ACE documentation set includes the following:
Document Title
Description
Release Note for the Cisco
Provides information about operating considerations, caveats,
Application Control Engine Module and command-line interface (CLI) commands for the ACE.
Cisco Application Control Engine
Provides information for installing the ACE into the Catalyst
Module Hardware Installation Note 6500 series switch or a Cisco 7600 series router.
Cisco Application Control Engine
Module Getting Started Guide
Describes how to perform the initial setup and configuration
tasks for the ACE.
Cisco Application Control Engine
Module 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 Application Control Engine
Module Virtualization
Configuration Guide
Describes how to operate your ACE in a single context or in
multiple contexts.
Cisco Application Control Engine
Module Routing and Bridging
Configuration Guide
Describes how to perform the following routing and bridging
tasks on the ACE:
Cisco Application Control Engine
Module Server Load-Balancing
Configuration Guide
•
Configuring VLAN interfaces
•
Configuring routing
•
Configuring bridging
•
Configuring Dynamic Host Configuration Protocol (DHCP)
Describes how to configure the following server load-balancing
features on the ACE:
•
Real servers and server farms
•
Class maps and policy maps to load balance traffic to real
servers in server farms
•
Server health monitoring (probes)
•
Stickiness
•
Firewall load balancing
•
TCL scripts
•
Cisco Application Control Engine Module Administration Guide
OL-20814-01
xiii
Preface
Document Title
Description
Cisco Application Control Engine
Module 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 Application Control Engine
Module SSL Configuration Guide
Describes how to configure the following Secure Sockets Layer
(SSL) features on the ACE:
•
SSL certificates and keys
•
SSL initiation
•
SSL termination
•
End-to-end SSL
Cisco Application Control Engine
Module 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 Application Control Engine
Module Command Reference
Provides an alphabetical list and descriptions of all CLI
commands by mode, including syntax, options, and related
commands.
Cisco CSM-to-ACE Conversion Tool Describes how to use the CSM-to-ACE conversion tool to
User Guide
migrate Cisco Content Switching Module (CSM) running- or
startup-configuration files to the ACE.
Cisco CSS-to-ACE Conversion Tool
User Guide
Describes how to use the CSS-to-ACE conversion tool to
migrate Cisco Content Services Switches (CSS)
running-configuration or startup-configuration files to the ACE.
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.
Symbols and Conventions
This publication uses the following conventions:
Cisco Application Control Engine Module Administration Guide
xiv
OL-20814-01
Preface
Convention
Description
boldface font
Commands, command options, and keywords are in boldface. Bold text also
indicates a command in a paragraph.
italic font
Arguments for which you supply values are in italics. Italic text also indicates
the first occurrence of a new term, book title, emphasized text.
{ }
Encloses required arguments and keywords.
[ ]
Encloses optional arguments and keywords.
{x | y | z}
Required alternative keywords are grouped in braces and separated by vertical
bars.
[x | y | z]
Optional alternative keywords are grouped in brackets and separated by
vertical bars.
string
A nonquoted set of characters. Do not use quotation marks around the string or
the string will include the quotation marks.
screen
font
boldface screen
Terminal sessions and information the system displays are in screen font.
Information you must enter in a command line is in boldface screen font.
font
italic screen font
Arguments for which you supply values are in italic screen font.
^
The symbol ^ represents the key labeled Control—for example, the key
combination ^D in a screen display means hold down the Control key while
you press the D key.
< >
Nonprinting characters, such as passwords are in angle brackets.
1.
A numbered list indicates that the order of the list items is important.
a. An alphabetical list indicates that the order of the secondary list items is important.
•
A bulleted list indicates that the order of the list topics is unimportant.
– An indented list indicates that the order of the list subtopics is unimportant.
Notes use the following conventions:
Note
Means reader take note. Notes contain helpful suggestions or references to material not covered in the
publication.
Cautions use the following conventions:
Caution
Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
For additional information about CLI syntax formatting, refer to the Cisco Application Control Engine
Module Command Reference.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
xv
Preface
Obtaining Documentation, Obtaining Support, and Security
Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback,
security guidelines, and also recommended aliases and general Cisco documents, 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
Cisco Application Control Engine Module Administration Guide
xvi
OL-20814-01
CH A P T E R
1
Setting Up the ACE
This chapter describes how to initially configure basic settings on the Cisco Application Control Engine
(ACE) module in the Catalyst 6500 series switches. It contains the following major sections:
•
Prerequisites for Setting Up the ACE
•
Default Settings
•
Setting Up the ACE
•
Displaying the ACE Setup Configuration
For details on assigning VLANs to the ACE, configuring VLAN interfaces on the ACE, and configuring
a default or static route on the ACE, see the Cisco Application Control Engine Module Routing and
Bridging Configuration Guide.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-1
Chapter 1
Setting Up the ACE
Prerequisites for Setting Up the ACE
Prerequisites for Setting Up the ACE
Setting up the ACE has the following requirements:
•
Terminal—The terminal that you use to communicate with the ACE must contain a terminal
communications application, such as HyperTerminal for Windows, and be configured as follows:
– Asynchronous transmission
– 9600 baud
– 8 data bits
– 1 stop bit
– No parity
•
Cable—The cable that connects the terminal to the ACE must meet the following requirements:
– Serial cable with an RJ-45 connector
– Cable type—Rollover serial cable to connect the ACE to a DTE device
For instructions on connecting a console cable to your ACE, see the Cisco Application Control
Engine Module Hardware Installation Guide.
Default Settings
Table 1-1 lists the default settings for the ACE setup parameters.
Table 1-1
Default Setup Parameters
Parameter
Default
User accounts
Administrator account:
username: admin / password: admin
XML interface account:
username: www: / password: admin
Host name
switch
Inactivity timeout
5 minutes
Console port communication parameters
•
9600 baud
•
8 data bits
•
1 stop bit
•
No parity
Cisco Application Control Engine Module Administration Guide
1-2
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Setting Up the ACE
This section describes the tasks associated with setting up the ACE and includes the following topics:
•
Establishing a Console Connection on the ACE
•
Sessioning and Logging In to the ACE
•
Changing or Resetting the Administrative Password
•
Assigning a Name to the ACE
•
Configuring an ACE Inactivity Timeout
•
Configuring a Message-of-the-Day Banner
•
Configuring the Date and Time
•
Configuring Terminal Settings
•
Modifying the Boot Configuration
•
Restarting the ACE
•
Shutting Down the ACE
Establishing a Console Connection on the ACE
This section describes how to establish a direct serial connection between your terminal and the ACE by
making a serial connection to the console port on the front of the ACE. The console port is an
asynchronous RS-232 serial port with an RJ-45 connector.
Prerequisites
This setup procedure requires a properly configured terminal and cable as described in the “Prerequisites
for Setting Up the ACE” section.
Restrictions
Only the Admin context is accessible through the console port; all other contexts can be reached through
Telnet or SSH sessions.
Detailed Steps
Follow these steps to access the ACE using a direct serial connection:
Step 1
Connect the serial cable between the ACE and the terminal and then use any terminal communications
application to access the ACE CLI. This procedure uses HyperTerminal for Windows.
Step 2
Launch HyperTerminal. The Connection Description window appears.
Step 3
Enter a name for your session in the Name field.
Step 4
Click OK. The Connect To window appears.
Step 5
From the drop-down list, choose the COM port to which the device is connected.
Step 6
Click OK. The Port Properties window appears.
Step 7
Set the following port properties:
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-3
Chapter 1
Setting Up the ACE
Setting Up the ACE
•
Baud Rate = 9600
•
Data Bits = 8
•
Flow Control = none
•
Parity = none
•
Stop Bits = 1
Step 8
Click OK to connect.
Step 9
Press Enter to access the CLI prompt.
switch login:
What to Do Next
When the login prompt displays, proceed with the following tasks:
•
Once a session is created, choose Save As from the File menu to save the connection description.
Saving the connection description has the following two advantages:
– The next time that you launch HyperTerminal, the session is listed as an option under
Start > Programs > Accessories > HyperTerminal > Name_of_session. This option lets you
reach the CLI prompt directly without going through the configuration steps.
– You can connect your cable to a different device without configuring a new HyperTerminal
session. If you use this option, make sure that you connect to the same port on the new device
as was configured in the saved HyperTerminal session. Otherwise, a blank screen appears
without a prompt.
•
See the “Sessioning and Logging In to the ACE” section for details on logging in and entering the
configuration mode to configure the ACE.
Sessioning and Logging In to the ACE
This section describes how to connect (session) to the ACE as the default user from either the ACE
console port or from the Catalyst 6500 series CLI. Once you connect to the ACE as the default user, you
can then log in and enter the configuration mode to configure the ACE.
The ACE creates two default user accounts at startup: admin and www. The admin user is the global
administrator and cannot be deleted. The ACE uses the www user account for the XML interface.
Later, when you configure interfaces and IP addresses on the ACE itself, you can remotely access the
ACE CLI through an ACE interface by using the Catalyst console port or by a Telnet or SSH session. To
configure remote access to the ACE CLI, see Chapter 2, Enabling Remote Access to the ACE. For
details on configuring interfaces on the ACE, see the Cisco Application Control Engine Module Routing
and Bridging Configuration Guide.
You can configure the ACE to provide a higher level of security for users accessing the ACE. For
information about configuring user authentication for login access, see the Cisco Application Control
Engine Module Security Configuration Guide.
Cisco Application Control Engine Module Administration Guide
1-4
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Restrictions
Only the Admin context is accessible through the console port; all other contexts can be reached through
a Telnet or SSH remote access session.
Detailed Steps
Follow these steps to session into the ACE and access configuration mode to perform the initial
configuration:
Step 1
Access the ACE through one of the following methods:
•
If you choose to access the ACE directly by its console port, attach a terminal to the
asynchronous RS-232 serial port on the front of the ACE. Any device connected to this port
must be capable of asynchronous transmission. The connection requires a terminal configured
as 9600 baud, 8 data bits, 1 stop bit, no parity. See the “Establishing a Console Connection on
the ACE” section.
•
If you choose to session into ACE, after the ACE successfully boots enter the session command
from the Catalyst CLI to Telnet to the ACE:
Cat6k-switch# session slot
mod_num processor 0
The mod_num argument identifies the slot number in the Catalyst 6500 series chassis where the
ACE is installed.
Note
Step 2
The default escape character sequence is Ctrl-^, and then x. You can also enter exit at the remote
prompt to end the session.
Log into the ACE by entering the login username and password at the following prompt:
switch login: admin
Password: admin
By default, both the username and password are admin.
The prompt changes to the following:
host1/Admin#
To change the default login username and password, see the “Changing or Resetting the Administrative
Password” section for details.
Caution
Step 3
You must change the default Admin password if you have not already done so. Otherwise, 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. You will not be able
to access the ACE using Telnet or SSH until you change the default Admin password.
To access configuration mode, enter:
host1/Admin# configure
Enter configuration commands, one per line. End with CNTL/Z
The prompt changes to the following:
host1/Admin(config)#
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-5
Chapter 1
Setting Up the ACE
Setting Up the ACE
Changing or Resetting the Administrative Password
This section describes how to change or reset the administrative password and includes the following
topics:
•
Changing the Administrative Password
•
Resetting the Administrator Account Password
Changing the Administrative Password
This section describes how to change the administrative password. During the initial login process to the
ACE, you enter the default user name admin and the default password admin in lowercase text. You
cannot modify or delete the default administrative username; however, for security reasons, you must
change the default administrative password. If you do not change the password, then security on your
ACE can be compromised because the administrative username and password are configured to be the
same for every ACE shipped from Cisco Systems.
The administrative username and password are stored in Flash memory. Each time that you reboot the
ACE, it reads the username and password from Flash memory. Global administrative status is assigned
to the administrative username by default.
Note
Caution
For information about changing a user password, see the Cisco Application Control Engine Module
Virtualization Configuration Guide.
You must change the default Admin password if you have not already done so. Otherwise, you can 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.
Cisco Application Control Engine Module Administration Guide
1-6
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
username name1 [password [0 | 5]
{password}]
Example:
host1/Admin(config)# username admin
password 0 mysecret_801
Changes the default username and password. The keywords,
arguments, and options are as follows:
•
name1—Sets the username that you want to assign or
change. Enter admin.
•
password—(Optional) Keyword that indicates that a
password follows.
•
0—(Optional) Specifies a clear text password.
•
5—(Optional) Specifies an MD5-hashed strong encryption
password.
•
password—The password in clear text, encrypted text, or
MD5 strong encryption, depending on the numbered option
(0 or 5) that you enter. If you do not enter a numbered option,
the password is in clear text by default. Enter a password as
an unquoted text string with a maximum of 64 characters.
Note
If you specify an MD5-hashed strong encryption
password, the ACE considers a password to be weak if it
less than eight characters in length.
The ACE supports the following special characters in a
password:
,./=+-^@!%~#$*()
Note that the ACE encrypts clear text passwords in the
running-config.
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Resetting the Administrator Account Password
This section describes how recover the admin password during the initial bootup sequence of the ACE
if you forget the password for the ACE administrator account and cannot access the ACE. You must have
access to the ACE through the console port to be able to reset the password for the Admin user back to
the factory-default value of admin.
Restrictions
Only the Admin context is accessible through the console port.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-7
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Follow these steps to reset the password that allows the Admin user access to the ACE:
Step 1
Connect to the console port on the Catalyst 6500 series switch.
Step 2
Session in to the ACE through the console port on the front panel.
Step 3
Reboot the ACE from the Catalyst 6500 series CLI. See the “Restarting the ACE” section for details.
Step 4
During the bootup process, output appears on the console terminal. Press ESC when the “Waiting for 3
seconds to enter setup mode...” message appears on the terminal (see the example below). The setup
mode appears. If you miss the time window, wait for the ACE to properly complete booting, reboot the
ACE from the Catalyst 6500 series CLI, and try again to access the setup mode by pressing ESC.
IXP polling timeout interval: 120
map_pci_xram_to_uspace[149] :: mapping 4096 bytes from 0x58800000
map_pci_xram_to_uspace[149] :: mapping 4096 bytes from 0x5a800000
................................................
IXP's are up... <Sec 48 :Status of IXP1 7, IXP2 7>
map_pci_xram_to_uspace[149] :: mapping 102400 bytes from 0x4fd68000
map_pci_xram_to_usenabling intb 57 interrupts
pace[149] :: mapping 102400 bytes from 0x57d68000
Starting lcpfw process...
inserting IPCP klm
Warning: loading /itasca/klm/klm_session.klm will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module klm_session.klm loaded, with warnings
inserting cpu_util klm
create dev node as 'mknod /dev/cpu_util c 236 0'
getting cpu_util dev major num
making new cpu_util dev node
Session Agent waiting for packets.
Waiting for 3 seconds to enter setup mode...
Entering setup sequence...
Reset Admin password [y/n] (default: n): y
Resetting admin password to factory default...
XR Serial driver version 1.0 (2004-11-08) with no serial options enabled
ttyXR major device number: 235
Create a dev file with 'mknod /dev/ttyXR c 235 [0-1]'
cux major device number: 234
Create a dev file with 'mknod /dev/cux c 234 [0-1]'
ttyXR0 at 0x10c00000 (irq = 59) is a 16550A
ttyXR1 at 0x10c00008 (irq = 59) is a 16550A
No licenses installed...
Loading.. Please wait...Done!!!
Step 5
The setup mode prompts if you want to reset the admin password. Enter y. The “Resetting admin
password to factory default” message appears. The ACE deletes the admin user password configuration
from the startup configuration and resets the password back to the factory default value of admin.
The boot process continues as normal and you are able to enter the admin password at the login prompt.
Cisco Application Control Engine Module Administration Guide
1-8
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Assigning a Name to the ACE
This section describes how to specify a hostname for the ACE or for the peer ACE in a redundant
configuration. The hostname is used to identify the ACE and for the command-line prompts. If you
establish sessions to multiple devices, the hostname helps you track where you enter commands. By
default, the hostname for the ACE is “switch.”
Restrictions
Only the Admin context is accessible through the console port.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
hostname
name
Changes the ACE name.
Example:
host1/Admin(config)# hostname ACE_1
ACE_1/Admin(config)#
Step 3
peer hostname
name
Example:
ACE_1/Admin(config)# peer hostname ACE_2
Step 4
do copy running-config startup-config
Example:
ACE_1/Admin(config)# do copy
running-config startup-config
The name argument specifies a new hostname for the ACE. Enter
a case-sensitive text string that contains from 1 to 32
alphanumeric characters.
(Optional) Changes the peer ACE name in a redundant
configuration.
The name argument specifies a new hostname for the peer ACE.
Enter a case-sensitive text string that contains from 1 to 32
alphanumeric characters.
(Optional) Copies the running configuration to the startup
configuration.
Configuring an ACE Inactivity Timeout
This section describes how to modify the length of time that can occur before the ACE automatically
logs off an inactive user by specifying the length of time that a user session can be idle before the ACE
terminates the console, Telnet, or SSH session. By default, the inactivity timeout value is 5 minutes.
Restrictions
The login timeout command setting overrides the terminal session-timeout setting (see the
“Configuring Terminal Display Attributes” section).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-9
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
login timeout
minutes
Configures the inactivity timeout value.
Example:
host1/Admin(config)# login timeout 10
The minutes argument specifies the length of time that a user can
be idle before the ACE terminates the session. Valid entries are
from 0 to 60 minutes. A value of 0 instructs the ACE never to
timeout. The default is 5 minutes.
no login timeout
(Optional) Restores the default timeout value of 5 minutes.
Example:
host1/Admin(config)# no login timeout
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring a Message-of-the-Day Banner
This section describes how to configure a message in configuration mode to display as the
message-of-the-day banner when a user connects to the ACE. Once connected to the ACE, the
message-of-the-day banner appears, followed by the login banner and Exec mode prompt.
Cisco Application Control Engine Module Administration Guide
1-10
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
banner motd
text
Example:
host1/Admin(config)# banner motd #Welcome
to “$(hostname)”...#
Configures the message-of-the-day banner.
The text argument is a line of message text to be displayed as the
message-of-the-day banner. The text string consists of all
characters that follow the first space until the end of the line
(carriage return or line feed).
The pound (#) character functions as the delimiting character for
each line. For the banner text, spaces are allowed but tabs cannot
be entered at the CLI. To instruct the ACE to display multiple
lines in a message-of-the-day banner, enter a new banner motd
command for each line that you want to appear.
The banner message is a maximum of 80 characters per line, up
to a maximum of 3000 characters (3000 bytes) for a
message-of-the-day banner. This maximum value includes all
line feeds and the last delimiting character in the message.
To add multiple lines to an existing a message-of-the-day
banner, precede each line by using the banner motd command.
The ACE appends each line to the end of the existing banner. If
the text is empty, the ACE adds a carriage return (CR) to the
banner.
You can include tokens in the form $(token) in the message text.
Tokens will be replaced with the corresponding configuration
variable. For example, enter:
•
$(hostname)—Displays the hostname for the ACE during
run time.
•
$(line)—Displays the tty (teletypewriter) line or name (for
example, “/dev/console”, “/dev/pts/0”, or “1”).
To use the $(hostname) in a single line banner motd input, you
must include double quotes (“) around the $(hostname) so that
the $ is interpreted as a special character at the beginning of a
variable in the single line (see the Step example).
Do not use the double quote character (“) or the percent sign
character (%) as a delimiting character in a single line message
string.
For multi-line input, double quotes (“) are not required for the
token because the input mode is different from signal-line mode.
When you operate in multi-line mode, the ACE interprets the
double quote character (“) literally.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-11
Chapter 1
Setting Up the ACE
Setting Up the ACE
Command
Purpose
no banner motd
(Optional) Replace a banner or a line in a multi-line banner.
Example:
host1/Admin(config)# do show banner motd
Step 3
do show banner motd
(Optional) Display the configured banner message.
Example:
host1/Admin(config)# no banner motd
Step 4
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Examples
The following example shows how to span multiple lines and use tokens to configure the banner
message:
host1/Admin(config)# banner motd #
Enter TEXT message. End with the character '#'.
================================
Welcome to Admin Context
-------------------------------Hostname: $(hostname)
Tty Line: $(line)
=================================
#
Configuring the Date and Time
This section describes how to configure the time zone and daylight saving time of the ACE for display
purposes. The ACE time and date are synchronized with the clock from the Catalyst 6500 series
supervisor engine. See the Cisco 6500 Series Switch Cisco IOS Software Configuration Guide for details
on setting the system clock on the switch.
This section contains the following topics:
•
Configuring the Time Zone
•
Adjusting for Daylight Saving Time
Configuring the Time Zone
This section describes how to set the time zone of the ACE. The ACE keeps time internally in Universal
Time Coordinated (UTC) offset.
Cisco Application Control Engine Module Administration Guide
1-12
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
clock timezone {zone_name{+ | –} hours
minutes} | {standard timezone}
Configures the time zone of the ACE.
The keywords, arguments, and options are as follows:
Example:
host1/Admin(config)# clock timezone
PST -8 0
•
zone_name—The 8-character name of the time zone (for
example, PDT) to be displayed when the time zone is in effect.
Table 1-1 lists the common time zone acronyms that you can use
for the zone_name argument.
•
hours—Hours offset from UTC. The range is from –23 to +23.
•
minutes—Minutes offset from UTC. The range is from 0 to 59
minutes.
•
standard timezone—Displays a list of well known time zones
that include an applicable UTC hours offset. Available choices in
the list are as follows:
– AKST—Alaska Standard Time, as UTC –9 hours
– AST—Atlantic Standard Time, as UTC –4 hours
– BST—British Summer Time, as UTC + 1 hour
– CEST—Central Europe Summer Time, as UTC + 2 hours
– CET—Central Europe Time, as UTC + 1 hour
– CST—Central Standard Time, as UTC –6 hours
– CST—Central Standard Time, as UTC + 9.5 hours
– EEST—Eastern Europe Summer Time, as UTC + 3 hours
– EET—Eastern Europe Time, as UTC + 2 hours
– EST—Eastern Standard Time, as UTC -5 hours
– GMT—Greenwich Mean Time, as UTC
– HST—Hawaiian Standard Time, as UTC –10 hours
– IST—Irish Summer Time, as UTC + 1 hour
– MSD—Moscow Summer Time, as UTC + 4 hours
– MSK—Moscow Time, as UTC + 3 hours
– MST—Mountain Standard Time, as UTC –7 hours
– PST—Pacific Standard Time, as UTC –8 hours
– WEST—Western Europe Summer Time, as UTC + 1 hour
– WST—Western Standard Time, as UTC + 8 hours
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-13
Chapter 1
Setting Up the ACE
Setting Up the ACE
Command
Purpose
no clock timezone
(Optional) Removes the clock timezone setting.
Example:
host1/Admin(config)# no clock timezone
Step 3
(Optional) Displays the current clock settings.
do show clock
Example:
host1/Admin (config)# do show clock
Fri Aug 7 01:38:30 PST 2009
Step 4
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Table 1-1 lists common time zone acronyms that you use when specifying the zone name using the
command’s zone_name argument.
Table 1-1
Acronym
Common Time Zone Acronyms
Time Zone Name and UTC Offset
Europe
BST
British Summer Time, as UTC + 1 hour
CET
Central Europe Time, as UTC + 1 hour
CEST
Central Europe Summer Time, as UTC + 2 hours
EET
Eastern Europe Time, as UTC + 2 hours
EEST
Eastern Europe Summer Time, as UTC + 3 hours
GMT
Greenwich Mean Time, as UTC
IST
Irish Summer Time, as UTC + 1 hour
MSK
Moscow Time, as UTC + 3 hours
MSD
Moscow Summer Time, as UTC + 4 hours
WET
Western Europe Time, as UTC
WEST
Western Europe Summer Time, as UTC + 1 hour
United States and Canada
AST
Atlantic Standard Time, as UTC – 4 hours
ADT
Atlantic Daylight Time, as UTC – 3 hours
CT
Central Time, either as CST or CDT, depending on the place and time of the year
CST
Central Standard Time, as UTC – 6 hours
CDT
Central Daylight Saving Time, as UTC – 5 hours
ET
Eastern Time, either as EST or EDT, depending on the place and time of the year
EST
Eastern Standard Time, as UTC – 5 hours
EDT
Eastern Daylight Saving Time, as UTC – 4 hours
MT
Mountain Time, either as MST or MDT, depending on the place and time of the year
MDT
Mountain Daylight Saving Time, as UTC – 6 hours
Cisco Application Control Engine Module Administration Guide
1-14
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Table 1-1
Common Time Zone Acronyms (continued)
Acronym
Time Zone Name and UTC Offset
MST
Mountain Standard Time, as UTC – 7 hours
PT
Pacific Time, either as PST or PDT, depending on the place and time of the year
PDT
Pacific Daylight Saving Time, as UTC – 7 hours
PST
Pacific Standard Time, as UTC – 8 hours
AKST
Alaska Standard Time, as UTC – 9 hours
AKDT
Alaska Standard Daylight Saving Time, as UTC – 8 hours
HST
Hawaiian Standard Time, as UTC – 10 hours
Australia
CST
Central Standard Time, as UTC + 9.5 hours
EST
Eastern Standard/Summer Time, as UTC + 10 hours (+11 hours during summer time)
WST
Western Standard Time, as UTC + 8 hours
Adjusting for Daylight Saving Time
This section describes how to configure the ACE to change the time automatically to summer time
(daylight saving time) by specifying when summer time begins and ends. All times are relative to the
local time zone; the start time is relative to standard time and the end time is relative to summer time. If
the starting month is after the ending month, the ACE assumes that you are located in the Southern
Hemisphere.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-15
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
clock summer-time {daylight_timezone_name
start_week start_day start_month
start_time end_week end_day end_month
end_time daylight_offset | standard
timezone}
Configures the ACE to change the time automatically to summer
time (daylight saving time).
The keywords, arguments, and options are as follows:
•
daylight_timezone_name—The eight-character name of the
time zone (for example, PDT) to be displayed when summer
time is in effect. See Table 1-1 for the list the common time
zone acronyms used for the daylight_timezone_name
argument.
•
start_week end_week—The week, ranging from 1 through 5.
•
start_day end_day—The day, ranging from Sunday through
Saturday.
•
start_month end_month—The month, ranging from January
through December.
•
start_time end_time—Time, in military format, specified in
hours and minutes.
•
daylight_offset—Number of minutes to add during the
summer time. Valid entries are 1 to 1440.
•
standard timezone—Displays a list of well known time
zones that include an applicable daylight time start and end
range along with a daylight offset. Available list choices are
as follows:
Example:
host1/Admin(config)# clock summer-time
Pacific 1 Sun Apr 02:00 5 Sun Oct 02:00 60
– ADT—Atlantic Daylight Time: 2 a.m. 1st Sunday April
to 2 a.m. last Sunday Oct, + 60 min
– AKDT—Alaska Standard Daylight Time: 2 a.m. 1st
Sunday April to 2 a.m. last Sunday Oct, + 60 min
– CDT—Central Daylight Time: 2 a.m. 1st Sunday April
to 2 a.m. last Sunday Oct, + 60 min
– EDT—Eastern Daylight Time: 2 a.m. 1st Sunday April
to 2 a.m. last Sunday Oct, + 60 min
– MDT—Mountain Daylight Time: 2 a.m. 1st Sunday
April to 2 a.m. last Sunday Oct, + 60 min
– PDT—Pacific Daylight Time: 2 a.m. 1st Sunday April
to 2 a.m. last Sunday Oct, + 60 min
Cisco Application Control Engine Module Administration Guide
1-16
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Command
Purpose
no clock summer-time
(Optional) Remove the clock summer-time setting.
Example:
host1/Admin(config)# no clock summer-time
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring Terminal Settings
This section describes how to access the ACE CLI by using one of the following methods:
•
Make a direct connection by using a dedicated terminal attached to the console port on the front of
the ACE.
•
Establish a remote connection to the ACE through the Catalyst 6500 series switch using the Secure
Shell (SSH) or Telnet protocols.
This section contains the following topics:
•
Configuring Terminal Display Attributes
•
Configuring Console Line Settings
•
Configuring Virtual Terminal Line Settings
For details on configuring remote access to the ACE CLI using SSH or Telnet, see Chapter 2, Enabling
Remote Access to the ACE.
Restrictions
This configuration topic includes the following restrictions:
•
Only the Admin context is accessible through the console port; all other contexts can be reached
through Telnet or SSH.
•
The login timeout command setting overrides the terminal session-timeout setting (see the
“Configuring an ACE Inactivity Timeout” section).
Configuring Terminal Display Attributes
This section describes how to specify the number of lines and the width for displaying information on a
terminal during a console session.
Restrictions
The maximum number of displayed screen lines is 511 columns.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-17
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
terminal length lines
Specifies the number of lines for displaying information on a terminal
during a console session.
Example:
host1/Admin# terminal lines 50
Step 2
terminal monitor
Example:
host1/Admin# terminal monitor
%ACE-7-111009: User 'admin'
executed cmd: terminal monitor
The lines argument sets the number of lines displayed on the current
terminal screen. This command is specific to only the console port. Telnet
and SSH sessions set the length automatically. Valid entries are from 0 to
511. The default is 24 lines. A value of 0 instructs the ACE to scroll
continuously (no pausing) and overrides the terminal width value. If you
later change the terminal length to any other value, the originally
configured terminal width value takes effect.
Starts the terminal monitor session and displays syslog output on the
terminal. To enable the various levels of syslog messages to the terminal,
use the logging monitor command (see the Cisco Application Control
Engine Module System Message Guide for details).
%ACE-7-111009: User 'admin'
executed cmd: terminal
monitor......
terminal no monitor
(Optional) Stops the current terminal monitoring session.
Example:
host1/Admin# terminal no monitor
Step 3
terminal session-timeout minutes
Example:
host1/Admin# terminal
session-timeout 600
Specifies the inactivity timeout value in minutes to configure the
automatic logout time for the current terminal session on the ACE. When
inactivity exceeds the time limit configured by this command, the ACE
closes the session and exits. The range is from 0 to 525600. The default
value is inherited from the value that is configured for the login timeout
command. If you do not configure a value for the login timeout
command, the default for both commands is 5 minutes. You can set the
terminal session-timeout value to 0 to disable this feature so that the
terminal remains active until you choose to exit the ACE. The ACE does
not save this change in the configuration file.
The minutes argument sets the timeout value in minutes.
Step 4
terminal terminal-type text
Example:
host1/Admin# terminal terminal-type
vt200
Step 5
terminal width characters
Example:
host1/Admin# terminal width 250
Specifies the name and type of the terminal used to access the ACE. If a
Telnet or SSH session specifies an unknown terminal type, the ACE uses
the VT100 terminal by default.
The minutes argument is the terminal type. Specify a text string from 1 to
80 alphanumeric characters.
Specifies the width for displaying information on a terminal during a
console session. This command is specific to the console port only.Telnet
and SSH sessions set the width automatically.
The characters argument sets the number of characters displayed on the
current terminal screen. Valid entries are from 24 to 512. The default is
80 columns.
Cisco Application Control Engine Module Administration Guide
1-18
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Command
Purpose
terminal no width
(Optional) Resets a terminal setting to its default value.
Example:
host1/Admin# terminal no width
Step 6
show terminal
(Optional) Displays the console terminal settings.
Example:
host1/Admin# show terminal
TTY: /dev/pts/0 Type: “vt100”
Length: 25 lines, Width: 80 columns
Session Timeout: 60 minutes
Configuring Console Line Settings
This section describes how to use the ACE console port to directly access the module to perform an
initial configuration. The console port, which is a standard RS-232 port with an RJ-45 connector, is an
asynchronous serial port; therefore, any device connected to this port must be capable of asynchronous
transmission. The connection requires a terminal configured as 9600 baud, 8 data bits, 1 stop bit, no
parity.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
line console
Enters console configuration mode.
Example:
host1/Admin(config)# line console
host1/Admin(config-console)#
Step 3
databits number
Example:
host1/Admin(config-console)# databits 6
no databits
Example:
host1/Admin(config-console)# no databits
Step 4
parity {even | none | odd}
Example:
host1/Admin(config-console)# parity even
no parity
Example:
host1/Admin(config-console)# no parity
Specifies the number of data bits per character. The range is from
5 to 8. The default is 8 data bits.
(Optional) Resets the number of data bits per character to the
default value (8).
Sets the parity for the console connection. The supported choices
are: even (even parity), none (no parity), or odd (odd parity).
The default is none.
(Optional) Resets the parity for the console connection to its
default value (none).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-19
Chapter 1
Setting Up the ACE
Setting Up the ACE
Step 5
Command
Purpose
speed speed
Sets the transmit and receive speeds for the serial console. The
range is between 110 and 115200 baud (110, 150, 300, 600,
1200, 2400, 4800, 9600,19200, 28800, 38400, 57600, or
115200). The default is 9600 baud.
Example:
host1/Admin(config-console)# speed 19200
no speed
Example:
host1/Admin(config-console)# no speed
Step 6
stopbits {1 | 2}
Example:
host1/Admin(config-console)# stopbits 2
no stopbits
(Optional) Resets the transmit and receive speeds for the serial
console to its default value (9600).
Sets the stop bits for the console connection. Valid values are 1
or 2 stop bits. The default is 1 stop bit.
(Optional) Resets the stopbit setting to its default value (1).
Example:
host1/Admin(config-console)# no stopbits
Step 7
do show line console [connected]
(Optional) Displays the line console settings.
Example:
host1/Admin(config-console)# do show line
console
line Console:
Speed:
9600 bauds
Databits:
8 bits per byte
Stopbits:
1 bit(s)
Parity:
none
Step 8
do copy running-config startup-config
Example:
host1/Admin(config-console)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring Virtual Terminal Line Settings
This section describes how to configure the virtual terminal line settings to enable remote access to the
ACE. A virtual terminal line is not associated with the console port; instead, it is a virtual port on the
Catalyst 6500 series switch that allows you to access the ACE.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
line vty
Enters line configuration mode.
Example:
host1/Admin(config)# line vty
host1/Admin(config-line)#
Cisco Application Control Engine Module Administration Guide
1-20
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Step 3
Command
Purpose
session-limit number
Specifies the maximum number of terminal sessions per line. The
range is from 1 to 251.
Example:
host1/Admin(config-line)# session-limit 23
no session-limit number
Example:
host1/Admin(config-line)# no session-limit
23
Step 4
do copy running-config startup-config
Example:
host1/Admin(config-line)# do copy
running-config startup-config
Step 5
(Optional) Disables a setting for the configured virtual terminal
line.
(Optional) Copies the running configuration to the startup
configuration.
(Optional) Returns to the Exec mode prompt.
Ctrl-z
Example:
host1/Admin(config-line)# ctrl-z
host1/Admin#
Step 6
clear line
vty_name
Example:
host1/Admin# clear line vty vty1
(Optional) Closes a specified vty session.
The vty_name argument specifies the name of the VTY session.
Enter a maximum of 64 characters for the name of the virtual
terminal.
Modifying the Boot Configuration
This section describes how to control the way in which the ACE performs its boot process through
ROMMON mode. ROMMON is the ROM-resident code that starts executing as soon as you power up
or reset the ACE. Two user-configurable parameters determine how theACE boots: the boot field in the
configuration register and the BOOT environment variable.
This section describes how to modify the boot configuration of the ACE and contains the following
topics:
•
Setting the Boot Method from the Configuration Register
•
Setting the BOOT Environment Variable
Setting the Boot Method from the Configuration Register
This section describes how to modify the boot method that the ACE uses at the next startup by setting
the boot field in the software configuration register. The configuration register identifies how the ACE
should boot and where the system image is stored. You can modify the boot field to force the ACE to
boot a particular system image at startup instead of using the default system image.
The ROMMON code executes upon power up, reset, or when a fatal exception occurs. The ACE enters
ROMMON mode if it does not find a valid system image, if the Flash memory configuration is corrupted,
or if the configuration register is set to enter ROMMON mode.
Note
You can manually enter ROMMON mode by restarting the ACE and then pressing the Break key during
the first 60 seconds of startup. If you are connected to the ACE through a terminal server, you can escape
to the Telnet prompt and then enter the send break command to enter the ROMMON mode.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-21
Chapter 1
Setting Up the ACE
Setting Up the ACE
Restrictions
The config-register command used to change the configuration register settings affects only the
configuration register bits that control the boot field and leaves the remaining bits unaltered.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
config-register value
Example:
host1/Admin(config)# config-register 1
The value argument represents the configuration register value
that you want to use the next time that you restart the ACE. The
supported value entries are as follows:
•
0—Upon reboot, the ACE boots to the rommon prompt. The
ACE remains in ROMMON mode at startup. From the
ROMMON mode, you select specify the system boot image
to use to boot the ACE For information about using the
ROMMON mode during a reboot, see the “Restarting the
ACE” section.
•
1—Upon reboot, the ACE boots the system image identified
in the BOOT environment variable (see the “Setting the
BOOT Environment Variable” section). The BOOT
environment variable specifies a list of image files on
various devices from which the ACE can boot at startup. If
the ACE encounters an error or if the image is not valid, it
will try the second image (if one is specified). If the second
image also fails to boot, the ACE returns to ROMMON
mode.
See the “Restarting the ACE” section for details on booting
the ACE from the rommon prompt.
•
no config-register 1
(Optional) Resets the config-register setting.
Example:
host1/Admin(config)# no config-register 1
Step 3
do copy running-config startup-config
Copies the running configuration to the startup configuration.
Example:
host1/Admin(config)# do copy
running-config startup-config
Setting the BOOT Environment Variable
This section describes how to add several images to the BOOT environment variable to provide a
fail-safe boot configuration. The BOOT environment variable specifies a list of image files on various
devices from which the ACE can boot at startup. If the first file fails to boot the ACE, subsequent images
Cisco Application Control Engine Module Administration Guide
1-22
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
that are specified in the BOOT environment variable are tried until the ACE boots or there are no
additional images to attempt to boot. If there is no valid image to boot, the ACE enters ROMMON mode
where you can manually specify an image to boot.
The ACE stores and executes images in the order in which you added them to the BOOT environment
variable. If you want to change the order in which images are tried at startup, you can either prepend and
clear images from the BOOT environment variable to attain the desired order or you can clear the entire
BOOT environment variable and then redefine the list in the desired order.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
boot system image:image_name
Example:
host1/Admin(config)# boot system
image:c6ace-t1k9-mzg.A2_2_99_57.bin
Step 3
do show bootvar
Sets the BOOT environment variable.
The image_name argument specifies the name of the system
image file. If the file does not exist (for example, if you entered
the wrong filename), then the filename is appended to the
bootstring, and this message displays, “Warning: File not found
but still added in the bootstring.” If the file does exist, but is not
a valid image, the file is not added to the bootstring, and this
message displays, “Warning: file found but it is not a valid boot
image.”
(Optional) Displays the BOOT environment variable settings.
Example:
host1/Admin(config)# BOOT variable =
“disk0:c6ace-t1k9-mzg.A2_2_99_57.bin
Configuration register is 0x1
Step 4
do copy running-config startup-config
Copies the running configuration to the startup configuration.
Example:
host1/Admin(config)# do copy
running-config startup-config
Restarting the ACE
This section describes how to reload the ACE directly from its CLI or reboot it by using the
Catalyst 6500 series CLI. You may need to reboot the ACE from the Catalyst CLI if you cannot reach
the ACE through its CLI or by using an external Telnet session.
This section contains the following topics:
•
Restarting the ACE from the CLI
•
Restarting the ACE from the Catalyst CLI
•
Using ROMMON to Specify the System Boot Image During a Restart
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-23
Chapter 1
Setting Up the ACE
Setting Up the ACE
Restarting the ACE from the CLI
This section describes how to reboot the ACE directly from its CLI and reload the configuration. When
you reboot the ACE, it performs a full power cycle of both the hardware and software. Any open
connections with the ACE are dropped. The reset process can take several minutes.
Caution
Configuration changes that are not written to the Flash partition are lost after a reload. Before rebooting,
enter the copy running-conf startup-config command in Exec mode to store the current configuration
in Flash memory. If you fail to save your configuration changes, the ACE reverts to its previous settings
upon restart.
Detailed Steps
Step 1
Command
Purpose
copy running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Example:
host1/Admin# copy running-config
startup-config
Step 2
reload
Example:
host1/Admin# reload
This command will reboot the system
Save configurations for all the contexts.
Save? [yes/no]: [yes]
Reboots the ACE and reloads the configuration. When you specify
reload, the ACE prompts you for confirmation and performs a
cold restart of the ACE.
During the reload process, the ACE performs one of the
following actions:
•
If you specified a value of 1 for the config-register command
(see the “Setting the Boot Method from the Configuration
Register” section), the ACE boots the system image
identified in the BOOT environment variable.
•
If you specified a value of 0 for the config-register
command, the ACE enters the ROMMON mode and you
must identify the location of an image file to boot (see the
“Using ROMMON to Specify the System Boot Image During
a Restart” section).
Restarting the ACE from the Catalyst CLI
This section describes how to restart the ACE from the Catalyst 6500 series CLI.
Caution
Configuration changes that are not written to the Flash partition are lost after a reload. Before rebooting,
enter the copy running-conf startup-config command in Exec mode to store the current configuration
in Flash memory. If you fail to save your configuration changes, the ACE reverts to its previous settings
upon restart.
Cisco Application Control Engine Module Administration Guide
1-24
OL-20814-01
Chapter 1
Setting Up the ACE
Setting Up the ACE
Detailed Steps
Step 1
Command
Purpose
copy running-config startup-config
(Optional) Copies the running configuration to the startup
configuration. Enter this command from the ACE CLI.
Example:
host1/Admin# copy running-config
startup-config
Step 2
hw-module module mod_num reset
Example:
Cat6k-switch# hw-module module 3 reset
Proceed with reload of module?[confirm]
% reset issued for module 3
Restarts the ACE from the Catalyst 6500. Enter this command
from the Catalyst 6500 CLI.
The arguments and keywords are as follows:
•
module mod_num—Applies the command to the module in
the specified slot number in the Catalyst 6500 series chassis
where the ACE is installed.
•
reset—Resets the specified module.
During the restart process, the ACE performs one of the
following actions:
•
If you specified a value of 1 for the config-register command
(see the “Setting the Boot Method from the Configuration
Register” section), the ACE boots the system image
identified in the BOOT environment variable.
•
If you specified a value of 0 for the config-register
command, the ACE enters the ROMMON mode and you
must identify the location of an image file to boot (see the
“Using ROMMON to Specify the System Boot Image During
a Restart” section).
Using ROMMON to Specify the System Boot Image During a Restart
This section describes how to specify a value of 0 for the config-register command (see the “Setting the
Boot Method from the Configuration Register” section) to force the ACE to enter the ROMMON mode
upon a reload or power cycle of the ACE. The ACE remains in ROMMON mode until you identify the
location of an image file to boot.
The ACE supports two methods of booting the module from the rommon prompt:
•
To manually change the configuration register setting in ROMMON mode, use the confreg
command followed by a value of 0 or 1.
•
To change the boot characteristics using onscreen prompts, use the confreg command without a
value.
To instruct the ACE to manually boot from a particular system image, use the confreg command and
specify a configuration register value of 1. Identify the name of the system image file that the ACE uses
to boot.
A confreg value of 0 instructs the ACE to boot to the rommon prompt.
For example, to use the confreg command at the rommon prompt to instruct the ACE to boot from the
c6ace-t1k9-mzg.3.0.0_A0_2.48.bin system image, enter:
rommon 11 > confreg 1
rommon 12 > BOOT=disk0:c6ace-t1k9-mzg.A2_2_99_57.bin
rommon 13 > sync
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-25
Chapter 1
Setting Up the ACE
Setting Up the ACE
To instruct the ACE to automatically boot from the image specified in the BOOT variable (see the
“Setting the BOOT Environment Variable” section), use the confreg command without specifying a
configuration register value to launch the Configuration Summary menu-based utility. You can then
instruct the ACE to boot from the system image identified in the BOOT environment variable (see the
“Setting the BOOT Environment Variable” section).
For example, to use the confreg command to display the onscreen prompts for changing the boot
characteristics of the ACE, enter:
rommon 11 > confreg
Configuration Summary
(Virtual Configuration Register: 0x1)
enabled are:
break/abort has effect
console baud: 9600
boot: the ROM monitor
do you wish to change the configuration? y/n [n]: y
disable “break/abort has effect”? y/n [n]:
enable “ignore system config info”? y/n [n]:
change the boot characteristics? y/n [n]: y
enter to boot:
0 = ROM Monitor
1 = boot file specified in BOOT variable
[1]: 1
For example, to use the confreg command to instruct the ACE to boot from the
c6ace-t1k9-mzg.A2_2_99_57.bin system image, enter:
rommon 11 > confreg
Configuration Summary
(Virtual Configuration Register: 0x1)
enabled are:
break/abort has effect
console baud: 9600
boot: the ROM monitor
do you wish to change the configuration? y/n [n]: n
rommon 12 > BOOT=disk0:c6ace-t1k9-mzg.A2_2_99_57.bin
rommon 13 > sync
Shutting Down the ACE
This section describes how to shut down the ACE from the Catalyst 6500 series CLI. To avoid corrupting
the ACE, you must correctly shut down the module before you disconnect the power or remove it from
the Catalyst 6500 series chassis.
Caution
Configuration changes that are not written to the Flash partition are lost after a reload. Before rebooting,
enter the copy running-conf startup-config command in Exec mode to store the current configuration
in Flash memory. If you fail to save your configuration changes, the ACE reverts to its previous settings
upon restart.
Caution
Do not remove the ACE from the Catalyst 6500 series switch until the module has shut down completely
and the Status LED is orange. You can damage the ACE if you remove it from the switch before it
completely shuts down.
Cisco Application Control Engine Module Administration Guide
1-26
OL-20814-01
Chapter 1
Setting Up the ACE
Displaying the ACE Setup Configuration
Detailed Steps
Step 1
Command
Purpose
copy running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Example:
host1/Admin# copy running-config
startup-config
Step 2
no power enable module
Shuts down the ACE.
Example:
host1/Admin# no power enable module
If the ACE fails to respond to this command, shut down the
module by using a small, pointed object (such as a paper clip) to
access the recessed Shutdown button on the front panel of the
ACE. The shutdown procedure may take several minutes. The
Status LED turns off when the ACE shuts down.
Displaying the ACE Setup Configuration
To display the ACE setup configuration information, use the following show commands from Exec
mode:
Command
Purpose
show banner motd
Displays the configured banner message (see the “Configuring a
Message-of-the-Day Banner” section).
show bootvar
Displays the BOOT environment variable settings (see the “Setting the
BOOT Environment Variable” section).
show clock
Displays the current clock settings (see the “Configuring the Time Zone”
section).
show line console [connected]
Displays the line console settings (see the “Configuring Console Line
Settings” section).
show login timeout
Displays the configured login time value (see the “Configuring an ACE
Inactivity Timeout” section).
show terminal
Displays the console terminal settings (see the “Configuring Terminal
Display Attributes” section).
For detailed information about the fields in the output from these commands, refer to the Cisco Application
Control Engine Module Command Reference.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
1-27
Chapter 1
Setting Up the ACE
Displaying the ACE Setup Configuration
Cisco Application Control Engine Module Administration Guide
1-28
OL-20814-01
CH A P T E R
2
Enabling Remote Access to the ACE
This chapter describes how to configure remote access to the Cisco Application Control Engine (ACE)
module by establishing a remote connection by using the Secure Shell (SSH) or Telnet protocols. It also
describes how to configure the ACE to provide direct access to a user context from SSH. This chapter
also covers how to configure the ACE to receive ICMP messages from a host.
This chapter contains the following major sections:
Note
•
Guidelines and Limitations
•
Default Settings
•
Enabling Remote Access to the ACE
•
Displaying Remote Access Session Information
•
Configuration Example for Enabling Remote Access to the ACE
For information about how to make a direct connection using a dedicated terminal attached to the Console
port on the front of the ACE, configure terminal display attributes, and configure terminal line settings
for accessing the ACE by console or virtual terminal connection, see Chapter 1, Setting Up the ACE.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-1
Chapter 2
Enabling Remote Access to the ACE
Guidelines and Limitations
Guidelines and Limitations
This section describes the guidelines and limitations for the remote access function and includes the
following topics:
•
Telnet Management Sessions
•
SSH Management Sessions
•
ICMP Messages
Telnet Management Sessions
The ACE supports a maximum 16 concurrent Telnet management sessions for the Admin context and 4
concurrent Telnet management sessions for each user context. The ACE supports a total maximum of
256 concurrent Telnet sessions.
SSH Management Sessions
The ACE supports a maximum of 16 concurrent SSH management sessions for the Admin context and
4 concurrent SSH management sessions for each user context. The ACE supports a total maximum of
256 concurrent SSH sessions.
The ACE can generate the DSA and RSA keys required to establish an SSH session and encrypt and
decrypt messages. The keys are generated in pairs—one public key and one private key. The global
administrator performs the key generation in the Admin context. All contexts associated with the ACE
share the common key. There is only a single host-key pair.
ICMP Messages
By default, the ACE does not allow ICMP messages to be received by an ACE interface or to pass
through the ACE interface. ICMP is an important tool for testing your network connectivity; however,
network hackers can also use ICMP to attack the ACE or your network. We recommend that you allow
ICMP during your initial testing, but then disallow it during normal operation.
Default Settings
Table 2-1 lists the default settings for the ACE remote access function.
Table 2-1
Default Remote Access Parameters
Parameters
Default
Concurrent Telnet management sessions per context
Concurrent SSH management sessions per context
•
Admin context: 16
•
User context: 4 (each)
•
Admin context: 16
•
User context: 4 (each)
Ability of an ACE interface to receive ICMP messages or allow ICMP messages to pass
through it
Disabled
Status of the following match protocol command protocols: http, https, icmp, kalap-udp,
snmp, ssh, and telnet.
Disabled
Cisco Application Control Engine Module Administration Guide
2-2
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
This section describes the tasks associated with enabling remote access to the ACE and includes the
following topics:
•
Task Flow for Enabling Remote Access to the ACE
•
Configuring Remote Network Management Traffic Services
•
Configuring the Maximum Number of Telnet Management Sessions
•
Configuring SSH Management Session Parameters
•
Terminating an Active User Session
•
Enabling ICMP Messages to the ACE
•
Directly Accessing a User Context Through SSH
Task Flow for Enabling Remote Access to the ACE
Follow these steps to enable remote access to the ACE:
Step 1
If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the
desired context. If necessary, log directly in to, or change to, the correct context.
host1/Admin# changeto C1
host1/C1#
The rest of the examples in this table use the Admin context, unless otherwise specified. For details on
creating contexts, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
Step 2
Enter configuration mode.
host1/Admin# config
Enter configuration commands, one per line. End with CNTL/Z
host1/Admin(config)#
Step 3
Create a class map that permits network management traffic to be received by the ACE based on the
network management protocol (SSH or Telnet) and client source IP address.
host1/Admin(config)# class-map
host1/Admin(config-cmap-mgmt)#
255.255.255.254
host1/Admin(config-cmap-mgmt)#
host1/Admin(config)#
host1/Admin(config)# class-map
host1/Admin(config-cmap-mgmt)#
255.255.255.254
host1/Admin(config-cmap-mgmt)#
host1/Admin(config)#
Step 4
type management match-all SSH-ALLOW_CLASS
match protocol ssh source-address 172.16.10.0
exit
type management match-all TELNET-ALLOW_CLASS
match protocol telnet source-address 172.16.10.0
exit
Configure a policy map that activates the SSH and Telnet management protocol classifications.
host1/Admin(config)# policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY
host1/Admin(config-pmap-mgmt)# class SSH-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# class TELNET-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# exit
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-3
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
host1/Admin(config)#
Step 5
Attach the traffic policy to a single VLAN interface or globally to all VLAN interfaces in the same
context. For example, to specify an interface VLAN and apply the remote management policy map to
the VLAN, enter:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)# ip address 172.16.1.100 255.255.0.0
host1/Admin(config-if)# service-policy input REMOTE_MGMT_ALLOW_POLICY
host1/Admin(config-if)# exit
Step 6
(Optional) Configure the maximum number of Telnet sessions allowed for each context.
host1/Admin(config)# telnet maxsessions 3
Step 7
(Optional) Configure the maximum number of SSH sessions allowed for each context.
host1/Admin(config)# ssh maxsessions 3
Step 8
If you have global administrator privileges, use the ssh key command to generate the SSH private key
and the corresponding public key for use by the SSH server. There is only one host-key pair. For
example, to generate an RSA1 key pair in the Admin context, enter:
host1/Admin(config)# ssh key rsa1 1024
generating rsa1 key
.....
generated rsa1 key
Step 9
(Optional) Save your configuration changes to Flash memory.
host1/Admin(config)# exit
host1/Admin# copy running-config startup-config
Step 10
(Optional) Terminate an active SSH or Telnet session for the active context by using one of the following
commands in Exec mode:
•
clear ssh {session_id | hosts}
•
clear telnet session_id
host1/Admin# clear ssh 345
Configuring Remote Network Management Traffic Services
This section provides an overview on creating a class map, policy map, and service policy for remote
network access to the ACE. The following items summarize the role of each function in configuring
remote network management access to the ACE:
•
Class map—Provides the remote network traffic match criteria to permit traffic based on:
– Remote access network management protocols (SSH, Telnet, or ICMP)
– Client source IP address
•
Policy map—Enables remote network management access for a traffic classification that matches
the criteria listed in the class map.
•
Service policy—Activates the policy map and attaches the traffic policy to an interface or globally
on all interfaces.
Cisco Application Control Engine Module Administration Guide
2-4
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Telnet and SSH remote access sessions are established to the ACE on a per context basis. For details on
creating users and contexts, see the Cisco Application Control Engine Module Virtualization
Configuration Guide.
This section contains the following topics:
•
Creating and Configuring a Remote Management Class Map
•
Creating a Layer 3 and Layer 4 Remote Access Policy Map
•
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
•
Applying a Service Policy to a Specific VLAN Interface
Creating and Configuring a Remote Management Class Map
This section describes how to create a Layer 3 and Layer 4 class map to classify the remote network
management traffic received by the ACE. The class map permits network management traffic to be
received by the ACE by identifying the incoming IP protocols that the ACE can receive as well as the
client source IP address and subnet mask as the matching criteria. You define the allowed network traffic
to manage security for protocols such as SSH, Telnet, and ICMP. You also determine how the ACE
evaluates multiple match statements operations when multiple match criteria exist in a class map.
The class map identifies the remote network access management protocols that can be received by the
ACE. You configure the associated policy map to permit access to the ACE for the specified management
protocols. As part of the network management access traffic classification, you also specify either a
client source host IP address and subnet mask as the matching criteria or instruct the ACE to allow any
client source address for the management traffic classification.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-5
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
class-map type management [match-all |
match-any] map_name
Create a Layer 3 and Layer 4 class map to classify the remote
network management traffic received by the ACE.
Example:
host1/Admin(config)# class-map type
management match-all
SSH-TELNET_ALLOW_CLASS
host1/Admin(config-cmap-mgmt)#
The keywords, arguments, and options are as follows:
•
match-all | match-any—(Optional) Determines how the
ACE evaluates Layer 3 and Layer 4 network management
traffic when multiple match criteria exist in a class map. The
class map is considered a match if the match commands
meet one of the following conditions:
– match-all —(Default) All of the match criteria listed in
the class map are satisfied to match the network traffic
class in the class map, typically match commands of the
same type.
– match-any—Any one of the match criteria listed in the
class map is satisfied to match the network traffic class
in the class map, typically match commands of different
types.
•
map_name—Specifies the name assigned to the class map.
Enter an unquoted text string with no spaces and a maximum
of 64 alphanumeric characters.
The CLI enters the class map management configuration mode.
no class-map type management [match-all |
match-any] map_name
(Optional) Remove a Layer 3 and Layer 4 network management
class map from the ACE.
Example:
host1/Admin(config)# no class-map type
management match-all
SSH-TELNET_ALLOW_CLASS
Cisco Application Control Engine Module Administration Guide
2-6
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Step 3
Command
Purpose
[line_number] match protocol {http | https
| icmp | kalap-udp | snmp | ssh | telnet}
{any | source-address ip_address mask}
Classifies the remote network management traffic received by
the ACE. Include one or more of the match protocol commands
to configure the match criteria for the class map.
Example:
ACE_1/Admin(config-cmap-mgmt)# match
protocol ssh source-address 172.16.10.0
255.255.255.254
ACE_1/Admin(config-cmap-mgmt)# match
protocol telnet source-address 172.16.10.0
255.255.255.254
The keywords and arguments are as follows:
•
line_number—(Optional) Assists you in editing or deleting
individual match commands. Enter an integer from 2 to 255
as the line number. You can enter no line_number to delete
long match commands instead of entering the entire line.
The line numbers do not dictate a priority or sequence for
the match statements.
•
http—Specifies the Hypertext Transfer Protocol (HTTP).
The configuration of the HTTP management protocol is
described in Chapter 8, Configuring the XML Interface.
•
https—Specifies the secure (SSL) Hypertext Transfer
Protocol (HTTP). The configuration of the HTTPS
management protocol is described in Chapter 8,
Configuring the XML Interface.
•
icmp—Specifies Internet Control Message Protocol
messages to the ACE. The configuration of the ICMP
management protocol is described in the “Enabling ICMP
Messages to the ACE” section.
•
kalap-udp—Specifies management access using KAL-AP
over UDP. The configuration of the KAL-AP management
access is described in the “Configuring Health Monitoring”
chapter of the Cisco Application Control Engine Module
Server Load-Balancing Configuration Guide.
•
snmp—Specifies the Simple Network Management
Protocol (SNMP). The configuration of the SNMP
management protocol is described in Chapter 7,
Configuring SNMP.
•
ssh—Specifies a Secure Shell (SSH) remote connection to
the ACE. The ACE supports the SSH remote shell
functionality provided in SSH Version 1 and supports DES
and 3DES ciphers. The configuration of the SSH
management protocol is described in the “Configuring SSH
Management Session Parameters” section.
Note
SSH v1.x and v2 are entirely different protocols and
are not compatible. Make sure that you use an SSH
v1.x client when accessing the ACE.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-7
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Command
Purpose
match protocol
(continued)
no match protocol {http | https | icmp |
kalap-udp | snmp | ssh | telnet} {any |
source-address ip_address mask}
•
telnet—Specifies a Telnet remote connection to the ACE.
The configuration of the Telnet management protocol is
described in the “Configuring the Maximum Number of
Telnet Management Sessions” section.
•
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.
•
mask—Subnet mask of the client in dotted-decimal notation.
(Optional) Deselects the specified network management
protocol match criteria from the class map.
Example:
ACE_1/Admin(config-cmap-mgmt)# no match
protocol ssh source-address 192.168.10.1
255.255.255.0
Step 4
description text
Provides a brief summary about the Layer 3 and Layer 4 remote
management class map.
Example:
host1/Admin(config-cmap-mgmt)# description
Allow Telnet access to the ACE
no description text
(Optional) Removes the description from the class map.
Example:
host1/Admin(config-cmap-mgmt)# no
description
Step 5
do copy running-config startup-config
Example:
ACE_1/Admin(config-cmap-mgmt))# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Creating a Layer 3 and Layer 4 Remote Access Policy Map
This section describes how to create a Layer 3 and Layer 4 policy map for a Layer 3 and Layer 4 traffic
classification with actions to define the network management traffic received by the ACE. The general
steps to configure a Layer 3 and Layer 4 network traffic policy are as follows:
•
Configure a Layer 3 and Layer 4 policy map that defines the different actions that are applied to the
IP management traffic received by the ACE. The ACE executes the specified action only for traffic
that meets the first matching classification with a policy map. The ACE does not execute any
additional actions.
•
Optionally, provide a brief description about the Layer 3 and Layer 4 remote management policy
map.
•
Specify a Layer 3 and Layer 4 traffic class that you created with the class-map command to
associate network traffic with the traffic policy.
Cisco Application Control Engine Module Administration Guide
2-8
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
•
Allow the network management traffic that is listed in the Layer 3 and Layer 4 class map to be
received or rejected by the ACE.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
policy-map type management first-match
map_name
Example:
host1/Admin(config)# policy-map type
management first-match
REMOTE_MGMT_ALLOW_POLICY
host1/Admin(config-pmap-mgmt)#
Configures a Layer 3 and Layer 4 policy map that defines the
different actions that are applied to the IP management traffic
received by the ACE.
The map_name argument specifies the name assigned to the
Layer 3 and Layer 4 network management policy map. Enter an
unquoted text string with no spaces and a maximum of 64
alphanumeric characters.
When you use this command, you will access policy map
management configuration mode.
no policy-map type management first-match
map_name
(Optional) Removes a policy map from the ACE.
Example:
host1/Admin(config)# no policy-map type
management first-match
REMOTE_MGMT_ALLOW_POLICY
Step 3
description text
Example:
host1/Admin(config-pmap-mgmt)# description
Allow Telnet access to the ACE
no description
Provides a brief summary about the Layer 3 and Layer 4 remote
management policy map.
The text argument specifies the description that you want to
provide. Enter an unquoted text string with a maximum of
240 alphanumeric characters.
(Optional) Removes a description from the policy map.
Example:
host1/Admin(config-pmap-mgmt)# no
description
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-9
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Step 4
Command
Purpose
class {name1 [insert-before name2] |
class-default}
Specifies a Layer 3 and Layer 4 traffic class created with the
class-map command to associate network traffic with the traffic
policy.
Example:
host1/Admin(config-pmap-mgmt)# class
L4_REMOTE_ACCESS_CLASS
host1/Admin(config-pmap-mgmt-c)#
The arguments, keywords, and options are as follows:
•
name1—Name of a previously defined Layer 3 and Layer 4
traffic class, configured with the class-map command, to
associate traffic to the traffic policy. Enter an unquoted text
string with no spaces and a maximum of 64 alphanumeric
characters.
•
insert-before name2—(Optional) Places the current class
map ahead of an existing class map or inline match condition
specified by the name2 argument in the policy map
configuration. The ACE does not save the sequence
reordering as part of the configuration. Enter an unquoted
text string with no spaces and a maximum of 64
alphanumeric characters.
•
class-default—Specifies the class-default class map for the
Layer 3 and Layer 4 traffic policy. This class map is a
reserved class map created by the ACE. You cannot delete or
modify this class. All network traffic that fails to meet the
other matching criteria in the named class map belongs to the
default traffic class. If none of the specified classifications
match, the ACE then matches the action specified under the
class class-default command. The class-default class map
has an implicit match any statement in it and is used to
match any traffic classification. The class-default class map
has an implicit match any statement that matches all traffic.
This command enters the policy map management class
configuration mode.
no class {name1 [insert-before name2] |
class-default}
(Optional) Remove a class map from a Layer 3 and Layer 4 policy
map.
Example:
host1/Admin(config-pmap-mgmt)# no class
L4_REMOTE_ACCESS_CLASS
Step 5
permit | deny
Example:
host1/Admin(config-pmap-mgmt-c)# permit
Step 6
do copy running-config startup-config
Example:
host1/Admin(config-pmap-mgmt-c)# do copy
running-config startup-config
Allows the network management traffic listed in the Layer 3 and
Layer 4 class map to be received or rejected by the ACE as
follows:
•
Use the permit command in policy map class configuration
mode to allow the remote management protocols listed in the
class map to be received by the ACE.
•
Use the deny command in policy map class configuration
mode to refuse the remote management protocols listed in
the class map to be received by the ACE.
(Optional) Copies the running configuration to the startup
configuration.
Cisco Application Control Engine Module Administration Guide
2-10
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Examples
The following example shows how to create a Layer 3 and Layer 4 remote network traffic management
policy map that permits SSH, Telnet, and ICMP connections to be received by the ACE:
host1/Admin(config)# policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY
host1/Admin(config-pmap-mgmt)# class SSH-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# class TELNET-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# class ICMP-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
The following example shows how to create a policy map that restricts an ICMP connection by the ACE:
host1/Admin(config)# policy-map type management first-action ICMP_RESTRICT_POLICY
host1/Admin(config-pmap-mgmt)# class ICMP-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# deny
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
This section describes how to apply a previously created policy map globally to all VLAN interfaces in
the same context.
Note the following guidelines when applying a service policy:
•
Policy maps, applied globally in a context, are internally applied on all interfaces existing in the
context.
•
A policy activated on an interface overwrites any specified global policies for overlapping
classification and actions.
You can remove a traffic policy map from a VLAN by using either of the following methods:
•
Individually from the last VLAN interface on which you applied the service policy
•
Globally from all VLAN interfaces in the same context
The ACE automatically resets the associated service policy statistics to provide a new starting point for
the service policy statistics the next time that you attach a traffic policy to a specific VLAN interface or
globally to all VLAN interfaces in the same context.
Note
To apply the policy map to a specific VLAN interface only, see the “Applying a Service Policy to a
Specific VLAN Interface” section.
Restrictions
The ACE allows only one policy of a specific feature type to be activated on a given interface and only
in the input direction.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-11
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
service-policy input policy_name
Example:
host1/Admin(config)# service-policy input
REMOTE_MGMT_ALLOW_POLICY
no service-policy input policy_name
Example:
host1/Admin(config)# no service-policy
input REMOTE_MGMT_ALLOW_POLICY
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
Step 4
do show service-policy [policy_name
[detail]]
Example:
host1/Admin(config)# do show
service-policy REMOTE_MGMT_ALLOW_POLICY
Step 5
Applies the remote access policy map globally to all of the
VLANs associated with a context.
The policy_name argument is the name of a previously defined
policy map, configured with a previously created policy-map
command. The name can be a maximum of 40 alphanumeric
characters.
(Optional) Removes the remote access traffic policy globally
from all VLANs associated with a context.
(Optional) Copies the running configuration to the startup
configuration.
(Optional) Displays service policy statistics for all policy maps or
a specific Layer 3 and Layer 4 remote network traffic
management policy map.
The keywords, options, and arguments are as follows:
•
policy_name—(Optional) Existing policy map that is
currently in service (applied to an interface) as an unquoted
text string with a maximum of 64 alphanumeric characters. If
you do not enter the name of an existing policy map, the ACE
displays information and statistics for all policy maps.
•
detail—(Optional) Displays a more detailed listing of policy
map statistics and status information.
Note
The ACE updates the counters that the show
service-policy command displays after the applicable
connections are closed.
do clear service-policy policy_name
(Optional) Clears the service policy statistics for a policy map.
Example:
host1/Admin(config)# do clear
service-policy REMOTE_MGMT_ALLOW_POLICY
For the policy_name argument, enter the identifier of an existing
policy map that is currently in service (applied to an interface).
Applying a Service Policy to a Specific VLAN Interface
This section describes how to apply a previously created policy map to a specific VLAN interface. A
policy activated on an interface overwrites any specified global policies for overlapping classification
and actions.
Cisco Application Control Engine Module Administration Guide
2-12
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
You can remove a traffic policy map from a VLAN by using either of the following methods:
•
Individually from the last VLAN interface on which you applied the service policy
•
Globally from all VLAN interfaces in the same context (see the “Applying a Service Policy Globally
to All VLAN Interfaces in the Same Context” section).
The ACE automatically resets the associated service policy statistics to provide a new starting point for
the service policy statistics the next time that you attach a traffic policy to a specific VLAN interface or
globally to all VLAN interfaces in the same context.
Note
To apply the policy map globally to all VLAN interfaces in the same context, see the “Applying a Service
Policy Globally to All VLAN Interfaces in the Same Context” section.
Restrictions
The ACE allows only one policy of a specific feature type to be activated on a given interface and only
in the input direction.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
interface vlan number
Example:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)#
Step 3
service-policy input policy_name
Example:
host1/Admin(config-if)# service-policy
input REMOTE_MGMT_ALLOW_POLICY
no service-policy input policy_name
Example:
host1/Admin(config-if)# no service-policy
input REMOTE_MGMT_ALLOW_POLICY
Step 4
do copy running-config startup-config
Example:
host1/Admin(config-if)# do copy
running-config startup-config
(Optional) Specifies the VLAN to which the remote access policy
map is to be applied.
The number argument specifies the VLAN.
This command enters the interface configuration mode.
Attaches the remote access policy map to the specified VLAN
only.
The policy_name argument specifies the policy map name.
To apply the policy map globally to all of the VLANs associated
with a context, see the “Applying a Service Policy Globally to All
VLAN Interfaces in the Same Context” section.
(Optional) Detaches the remote access traffic policy from the
VLAN.
(Optional) Copies the running configuration to the startup
configuration.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-13
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Step 5
Command
Purpose
do show service-policy [policy_name
[detail]]
(Optional) Displays service policy statistics for all policy maps or
a specific Layer 3 and Layer 4 remote network traffic
management policy map.
Example:
host1/Admin(config-if)# do show
service-policy REMOTE_MGMT_ALLOW_POLICY
Step 6
The keywords, options, and arguments are as follows:
•
policy_name—(Optional) Existing policy map that is
currently in service (applied to an interface) as an unquoted
text string with a maximum of 64 alphanumeric characters. If
you do not enter the name of an existing policy map, the ACE
displays information and statistics for all policy maps.
•
detail—(Optional) Displays a more detailed listing of policy
map statistics and status information.
Note
The ACE updates the counters that the show
service-policy command displays after the applicable
connections are closed.
do clear service-policy policy_name
(Optional) Clears the service policy statistics for a policy map.
Example:
host1/Admin(config-if)# do clear
service-policy REMOTE_MGMT_ALLOW_POLICY
For the policy_name argument, enter the identifier of an existing
policy map that is currently in service (applied to an interface).
Examples
The following example shows how to specify an interface VLAN and apply the remote access policy map
to a VLAN:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)# ip address 172.16.1.100 255.255.0.0
host1/Admin(config-if)# service-policy input REMOTE_MGMT_ALLOW_POLICY
The following example shows how to display service policy statistics for the
REMOTE_MGMT_ALLOW_POLICY policy map:
host1/Admin# show service-policy REMOTE_MGMT_ALLOW_POLICY
Status
: ACTIVE
Description: Allow mgmt protocols
----------------------------------------Context Global Policy:
service-policy: REMOTE_MGMT_ALLOW_POLICY
Configuring the Maximum Number of Telnet Management Sessions
This section describes how to control the maximum number of Telnet sessions allowed for each context.
Telnet remote access sessions are established on the ACE per context. You can create a context, assign
an interface and IP address to it, and then log into the ACE by using Telnet to connect to that IP address.
This capability allows you to specify a particular context when accessing the ACE. For details on
creating users and contexts, see the Cisco Application Control Engine Module Virtualization
Configuration Guide.
Cisco Application Control Engine Module Administration Guide
2-14
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Restrictions
The ACE supports a total maximum of 256 concurrent Telnet sessions. The ACE supports a maximum
16 concurrent Telnet management sessions for the Admin context and 4 concurrent Telnet management
sessions for each user context.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
telnet maxsessions max_sessions
Example:
host1/Admin(config)# telnet maxsessions 3
no telnet maxsessions
Example:
host1/Admin(config)# no telnet maxsessions
Step 3
do show telnet maxsessions
[context_name]
Example:
host1/Admin(config)# do show telnet
maxsessions
Maximum Sessions Allowed is 4
Step 4
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Specifies the maximum number of concurrent Telnet
sessions allowed for the associated context.
The max_sessions argument sets the maximum number of
concurrent Telnet sessions allowed. The range is from 1 to 16
Telnet sessions for the Admin context and from 1 to 4 Telnet
sessions for each user context. The defaults are 16 (Admin
context) and 4 (user context).
(Optional) Reverts to the default maximum number of Telnet
sessions for the context.
(Optional) Displays the maximum number of enabled Telnet
sessions. Only context administrators can view Telnet session
information associated with a particular context.
The optional context_name argument specifies the name of the
context for which you want to view the maximum number of
Telnet sessions. The context_name argument is case sensitive.
(Optional) Copies the running configuration to the startup
configuration.
Configuring SSH Management Session Parameters
This section describes how to configure the SSH management session parameters. SSH remote access
sessions are established on the ACE per context. You can create a context, assign an interface and IP
address to it, and then log into the ACE by using SSH to connect to that IP address. This capability allows
you to specify a particular context when accessing the ACE. For details on creating users and contexts,
see the Cisco Application Control Engine Module Virtualization Configuration Guide.
This section contains the following topics:
•
Configuring Maximum Number of SSH Sessions
•
Generating SSH Host Key Pairs
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-15
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Configuring Maximum Number of SSH Sessions
This section describes how to control the maximum number of SSH sessions allowed for each context.
Restrictions
The ACE supports a total maximum of 256 concurrent SSH sessions. The ACE supports a maximum 16
concurrent SSH management sessions for the Admin context and 4 concurrent SSH management
sessions for each user context.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
ssh maxsessions max_sessions
Example:
host1/Admin(config)# ssh maxsessions 3
no ssh maxsessions
Example:
host1/Admin(config)# no ssh maxsessions
Step 3
do show ssh maxsessions [context_name]
Example:
host1/Admin(config)# do show ssh
maxsessions
Maximum Sessions Allowed is 4
Step 4
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Specifies the maximum number of concurrent SSH
sessions allowed for the associated context.
The max_sessions argument sets the maximum number of
concurrent SSH sessions allowed. The range is from 1 to 16 SSH
sessions for the Admin context and from 1 to 4 SSH sessions for
each user context. The defaults are 16 (Admin context) and 4
(user context).
(Optional) Reverts to the default maximum number of SSH
sessions for the context.
(Optional) Displays the maximum number of enabled SSH
sessions. Only context administrators can view SSH session
information associated with a particular context.
The optional context_name argument specifies the name of the
context for which the context administrator wants to view the
maximum number of SSH sessions. The context_name argument
is case sensitive.
(Optional) Copies the running configuration to the startup
configuration.
Generating SSH Host Key Pairs
This section describes how to generate an SSH host key pair. The ACE supports remote login over an
SSH session that uses private and public key pairs to perform authentication for the context. DSA and
RSA keys are generated in pairs—one public key and one private key. With this method of remote
connection, use a generated private and public key pair to participate in a secure communication by
encrypting and decrypting messages.
Cisco Application Control Engine Module Administration Guide
2-16
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
The global administrator performs the key generation in the Admin context. All contexts associated with
the ACE share the common key. There is only a single host-key pair.
Ensure that you have an SSH host-key pair with the appropriate version before enabling the SSH service
(see the “Configuring Remote Network Management Traffic Services” section). The SSH service
accepts three types of key pairs for use by SSH versions 1 and 2. Generate the SSH host key pair
according to the SSH client version used. The number of bits specified for each key pair ranges from 768
to 4096.
Detailed Steps
Step 1
Step 2
Command
Purpose
changeto Admin
(Optional) Changes to the Admin context.
Example:
host1/context3# changeto Admin
host1/Admin#
If you are the administrator or another user authorized in the
Admin context, use this command in Exec mode to move to the
Admin context. An administrator can perform all allowable
functions within the Admin context.
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 3
hostname name
Example:
host1/Admin(config)# hostname host1
host1/Admin(config)#
Sets the hostname. This setting is used in the generation of the
key.
The name argument specifies a new hostname for the ACE. Enter
a case-sensitive text string that contains from 1 to 32
alphanumeric characters.
For more information about setting the host name, see the
“Assigning a Name to the ACE” section on page 1-9.
Step 4
ssh key {dsa | rsa | rsa1} [bits [force]]
Generates the SSH private key and the corresponding public key.
Example:
host1/Admin(config)# ssh key rsa1 1024
The arguments, keywords, and options are as follows:
•
dsa—Generates the DSA key pair for the SSH version 2
protocol.
•
rsa—Generates the RSA key pair for the SSH version 2
protocol.
•
rsa1—Generates the RSA1 key pair for the SSH version 1
protocol.
•
bits—(Optional) Number of bits for the key pair. For DSA,
the range is from 768 to 2048. For RSA and RSA1, the range
is from 768 to 4096. The greater the number of bits that you
specify, the longer it takes to generate the key. The default is
768.
•
force—(Optional) Forces the generation of a DSA or RSA
key even when previous keys exist. If the SSH key pair
option is already generated for the required version, use the
force option to overwrite the previously generated key pair.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-17
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Command
Purpose
no ssh key {dsa | rsa | rsa1}
(Optional) Removes the SSH host key pair.
Example:
host1/Admin(config)# no ssh key rsa1
Step 5
do show ssh key [dsa | rsa | rsa1]
Example:
host1/Admin(config)# do show ssh key rsa
Step 6
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
Step 7
(Optional) Displays the host key pair details for the specified key
or for all keys if you do not specify a key.
(Optional) Copies the running configuration to the startup
configuration.
(Optional) Returns to the Exec mode prompt.
exit
Example:
host1/Admin(config)# exit
host1/Admin#
Step 8
clear ssh hosts
Example:
host1/Admin# clear ssh hosts
(Optional) Clears the public keys of all trusted host. These keys
are either sent to an SSH client by an SSH server or are entered
manually. When a SSH connection is made from the ACE, the
SSH client receives the public key and stores it locally.
Examples
The following example shows the show ssh key command output:
host1/Admin # show ssh key
**************************************
could not retrieve rsa1 key information
**************************************
rsa Keys generated:Tue Mar 7 19:37:17 2006
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA4v4DQ8aNl482qDTRju9G07hEIxCgTWanPm+WOCU1kihZ
QNd5ZwA50CBAJSfIIIB4iED6iQbhOkbXSneCvTb5mVoish2wvJrETpIDIeGxxh/jWVsU/MeBbA/7o5tv
gCeT6p7pGF5oUNYFP0OeZ9BiIWDc4jBmYEQLEqJHPrMhSFE=
bitcount:1024
fingerprint:
f5:55:00:18:bc:af:41:74:b6:bc:aa:8e:46:31:74:4f
**************************************
dsa Keys generated:Tue Dec 20 19:37:17 2005
ssh-dss AAAAB3NzaC1kc3MAAACBAPqDdEqU+0gNtKRXM+DQAXnvcB+H89nq8jA4WgJ7uQcuDCLaG7Lq
jtKTltJjA6aZVywsQWQ6n4kTlkavZy3cj6PUbSyqvmCTsaYyYo4UQ6CKrK9V+NsfgzTSLWTH8iDUvYjL
c3nU51QEKjy7mPsQeX31y1M1rhp8qhkbMKxkc49XAAAAFQCPM0QJrq6+kkaghJpeNxeXhUH9HwAAAIEA
keZ1ZJM6sfKqJDYPLHkTro+lpbV9uR4VyYoZmSoehi/LmSaZDq+Mc8UN1LM+i5vkOgnKcearD9lM4/hK
zZGYx5hJOiYCKj/ny2a5p/8HK152cnsOAg6ebkiTTWAprcWrcHDS/1mcaI5GzLrZCdlXW5gBFZtMTJGs
tICmVWjibewAAACBAJQ66zdZQqYiCWtZfmakridEGDTLV6ixIDjBNgb84qlj+Y1XMzqLL0D4oMSb7idE
L3BmhQYQW7hkTK0oS4kVawI1VmW2kvrqoGQnLNQRMvisAXuJWKk1Ln6vWPGZZe8KoALv0GXxsOv2gk/z
TDk01oCaTVw//bXJtoVRgIlWXLIP
bitcount:1024
fingerprint:
8e:13:5c:3e:1a:9c:7a:ed:d0:84:eb:96:12:db:82:be
**************************************
Cisco Application Control Engine Module Administration Guide
2-18
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Terminating an Active User Session
This section describes how to terminate an active SSH or Telnet session for the active context.
Detailed Steps
Step 1
Command
Purpose
show {ssh session-info | telnet}
(Optional) Displays the session information, including the
session ID, of all current SSH or Telnet sessions.
Example:
host1/Admin# show ssh session-info
Step 2
clear {ssh | telnet} session_id
Example:
host1/Admin# clear ssh 345
The keywords are as follows:
•
ssh session-info—Displays SSH session information.
•
telnet—Displays Telnet session information.
Terminates a current SSH or Telnet session depending on which
command you enter.
The argument and keyword are as follows:
•
ssh—Selects an SSH session type.
•
telnet—Selects a Tenet session type.
•
session_id—Specifies the identifier of the SSH or Telnet
session to disconnect.
Enabling ICMP Messages to the ACE
This section describes how to enable ICMP messages on the ACE. By default, the ACE does not allow
ICMP messages to be received by an ACE interface or to pass through the ACE interface. ICMP is an
important tool for testing your network connectivity; however, network hackers can also use ICMP to
attack the ACE or your network. We recommend that you allow ICMP during your initial testing, but
then disallow it during normal operation.
To permit or deny address(es) to reach an ACE interface with ICMP messages, either from a host to the
ACE, or from the ACE to a host which requires the ICMP reply to be allowed back, configure one of the
following:
•
Class map to provide the ICMP network traffic match criteria for the ACE.
•
Policy map to enable ICMP network management access to and from the ACE.
•
Service policy to activate the policy map, attach the traffic policy to an interface or globally on all
interfaces, and specify the direction in which the policy should be applied.
See the “Configuring Remote Network Management Traffic Services” section for details on configuring
a network management class map, policy map, and service policy for the ACE.
To allow ICMP messages to pass through the ACE, configure an ICMP ACL to permit or deny network
connections based on the ICMP type (for example, echo, echo-reply, or unreachable). See the Cisco
Application Control Engine Module Security Configuration Guide for details.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-19
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Note
If you want only to allow the ACE to ping a host (and allow the echo reply back to the interface), but not
allow hosts to ping the ACE, enable the ICMP application protocol inspection function instead of
defining a class map and policy map. See the Cisco Application Control Engine Module Security
Configuration Guide for details.
Examples
The following example shows how to allow the ACE to receive ICMP pings:
host1/Admin(config)# class-map type management match-all ICMP-ALLOW_CLASS
host1/Admin(config-cmap-mgmt)# description Allow ICMP packets
host1/Admin(config-cmap-mgmt)# match protocol icmp source-address 172.16.10.0
255.255.255.254
host1/Admin(config-cmap-mgmt)# exit
host1/Admin(config)# policy-map type management first-action ICMP_ALLOW_POLICY
host1/Admin(config-pmap-mgmt)# class ICMP-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# exit
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)# ip address 172.16.1.100 255.255.0.0
host1/Admin(config-if)# service-policy input ICMP_ALLOW_POLICY
Directly Accessing a User Context Through SSH
This section describes how to configure a user context and enable direct login access to that user context
from a remote SSH session. To perform this procedure, you must be the global administrator and in the
Admin context.
Task Flow
Follow these steps to first configure the ACE to provide direct access to a user context from SSH and
then access the user context:
Step 1
Create a user context by entering the following command:
host1/Admin(config)# context C1
host1/Admin(config-context)#
See the Cisco Application Control Engine Module Virtualization Configuration Guide.
Step 2
Associate an existing VLAN with the user context so that the context can receive traffic classified for it
by entering the following command:
host1/Admin(config-context)# allocate-interface vlan 100
See the Cisco Application Control Engine Module Routing and Bridging Configuration Guide.
Step 3
Generate the SSH host key pair by entering the following command:
host1/Admin(config-context)# ssh key rsa1 1024
generating rsa1 key
.....
generated rsa1 key
See the “Generating SSH Host Key Pairs” section.
Cisco Application Control Engine Module Administration Guide
2-20
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Enabling Remote Access to the ACE
Step 4
Change to the C1 context that you created in Step 1 and enter configuration mode in that context by
entering the following commands:
host1/Admin(config-context)# do changeto C1
host1/C1(config-context)# exit
host1/C1(config)#
Only users authenticated in the Admin context can use the changeto command.
Step 5
Configure the VLAN interface that you allocated to the user context in Step 2 by entering the following
commands:
host1/C1(config)# interface vlan 50
host1/C1(config-if)# ip address 192.168.1.1 255.255.255.0
host1/C1(config-if)# no shutdown
host1/C1(config-if)# exit
host1/C1(config)#
For example, assign an IP address to the interface and reenable the interface within the context with the
no shutdown command. See the Cisco Application Control Engine Module Routing and Bridging
Configuration Guide.
Step 6
Create an SSH remote management policy and apply the associated service policy to all VLAN
interfaces or just to the VLAN interface allocated to the user context by entering the following
commands:
host1/C1(config)# class-map type management match-all SSH-ALLOW_CLASS
host1/C1(config-cmap-mgmt)# match protocol ssh source-address 172.16.10.0 255.255.255.254
host1/C1(config-cmap-mgmt)# exit
host1/C1(config)#
host1/C1(config)# policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY
host1/C1(config-pmap-mgmt)# class SSH-ALLOW_CLASS
host1/C1(config-pmap-mgmt-c)# permit
host1/C1(config-pmap-mgmt-c)# exit
host1/C1(config-pmap-mgmt)# exit
host1/C1(config)# interface vlan 50
host1/C1(config-if)# ip address 192.168.1.1 255.255.255.0
host1/C1(config-if)# service-policy input REMOTE_MGMT_ALLOW_POLICY
host1/C1(config-if)# exit
host1/C1(config)#
See the “Configuring Remote Network Management Traffic Services” section.
Step 7
Create an IP route by entering the following command:
host1/C1(config)# ip route 0.0.0.0 255.255.255.0 192.168.4.8
See the Cisco Application Control Engine Module Security Configuration Guide.
Step 8
Follow theses steps to directly access the user context from an SSH client:
a.
From the SSH client, establish a remote SSH session to the IP address of the user context VLAN
interface.
b.
Enter the password for the user context VLAN interface. The ACE CLI prompt appears in Exec
mode of the user context.
host1/C1#
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-21
Chapter 2
Enabling Remote Access to the ACE
Displaying Remote Access Session Information
Displaying Remote Access Session Information
This section describes how to display remote access session information and includes the following
topics:
•
Displaying Telnet Session Information
•
Displaying SSH Session Information
•
Displaying Other Remote Access Session Information
Displaying Telnet Session Information
To display a Telnet session, perform the following task:
Command
Purpose
show telnet [context_name]
Display information related to the Telnet session. Only the context administrator can
view Telnet information associated with a particular context.
The optional context_name argument specifies the name of the context for which you
want to view specific Telnet session information. The context_name argument is case
sensitive.
Table 2-2 describes the fields in the show telnet command output.
Table 2-2
Field Descriptions for the show telnet Command
Field
Description
SessionID
Unique session identifier for the Telnet session.
Remote Host
IP address and port of the remote Telnet client.
Active Time
Time since the Telnet connection request was received by the ACE.
Displaying SSH Session Information
To display an SSH session, perform the following task:
Command
Purpose
show ssh session-info
[context_name]
Displays information related to the SSH session. Only context administrators can view
SSH session information associated with a particular context.
The optional context_name argument specifies the name of the context for which you
want to view specific SSH session information. The context_name argument is case
sensitive.
Table 2-3 describes the fields in the show ssh session-info command output.
Cisco Application Control Engine Module Administration Guide
2-22
OL-20814-01
Chapter 2
Enabling Remote Access to the ACE
Displaying Remote Access Session Information
Table 2-3
Field Descriptions for the show ssh session-info Command
Field
Description
SessionID
Unique session identifier for the SSH session.
Remote Host
IP address and port of the remote SSH client.
Active Time
Time since the SSH connection request was received by the ACE.
Displaying Other Remote Access Session Information
To display other remote access configuration information, perform one of the following tasks:
Command
Purpose
show running-config
Displays the running configuration.
show ssh key [dsa | rsa | rsa1]
Displays the host key pair details for the specified key or for all keys if you do not
specify a key.
See the “Generating SSH Host Key Pairs” section.
show ssh maxsessions [context_name]
Displays the maximum number of enabled SSH sessions. Only context
administrators can view SSH session information associated with a particular
context.
See the “Configuring Maximum Number of SSH Sessions” section.
show telnet maxsessions [context_name] Display the maximum number of enabled Telnet sessions. Only context
administrators can view Telnet session information associated with a particular
context.
See the “Configuring the Maximum Number of Telnet Management Sessions”
section.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
2-23
Chapter 2
Enabling Remote Access to the ACE
Configuration Example for Enabling Remote Access to the ACE
Configuration Example for Enabling Remote Access to the ACE
The following CLI example shows how to configure remote access to the ACE through the use of class
maps, policy maps, and service policies.
Step 1
Enter the configuration mode and set the maximum number of Telnet and SSH sessions.
host1/Admin# config
host1/Admin(config)# telnet maxsessions 3
host1/Admin(config)# ssh maxsessions 3
Step 2
Create and configure an access control list. The sample access control list shown in this step allows
network traffic from any source. For details about configuring an access control list, see the Cisco
Application Control Engine Module Security Configuration Guide.
host1/Admin(config)# access-list ACL1 line 10 extended permit ip any any
Step 3
Create and configure a class map for network management traffic.
host1/Admin(config)# class-map
host1/Admin(config-cmap-mgmt)#
host1/Admin(config-cmap-mgmt)#
host1/Admin(config-cmap-mgmt)#
host1/Admin(config-cmap-mgmt)#
host1/Admin(config-cmap-mgmt)#
host1/Admin(config)#
Step 4
type management match-any L4_REMOTE-MGT_CLASS
description Allows Telnet, SSH, and ICMP protocols
2 match protocol telnet any
3 match protocol ssh any
4 match protocol icmp any
exit
Create and configure a policy map that activates the SSH and Telnet management protocol
classifications.
host1/Admin(config)# policy-map type management first-match L4_REMOTE-MGT_POLICY
host1/Admin(config-pmap-mgmt)# class L4_REMOTE-MGT_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# exit
host1/Admin(config)#
Step 5
Apply the traffic policy to a specific VLAN interface or globally to all VLAN interfaces and enable the
interface.
Apply to a specific VLAN interface:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)# ip address 192.168.1.1 255.255.255.0
host1/Admin(config-if)# access-group input ACL1
host1/Admin(config-if)# service-policy input L4_REMOTE-MGT_POLICY
host1/Admin(config-if)# no shutdown
host1/Admin(config-if)# exit
host1/Admin(config)#
Apply globally to all VLAN interface:
host1/Admin(config)# service-policy input REMOTE_MGMT_ALLOW_POLICY
Step 6
Generate the SSH private key and corresponding public key for use by the SSH server.
host1/Admin(config)# ssh key rsa1 1024 force
Step 7
Save the configuration to Flash memory.
host1/Admin(config)# do copy running-config startup-config
Cisco Application Control Engine Module Administration Guide
2-24
OL-20814-01
CH A P T E R
3
Managing ACE Software Licenses
This chapter describes how to manage the software licenses for your Cisco Application Control Engine
(ACE) module. It contains the following major sections:
•
Information about ACE Licenses
•
Guidelines and Limitations
•
Prerequisites
•
Default License Feature Capabilities
•
Managing ACE Module Software Licenses
•
Displaying ACE License Configurations and Statistics
Information about ACE Licenses
Table 3-1 lists the ACE licenses, product IDs (PIDs), and descriptions. You can increase the number of
default user contexts, module bandwidth, and SSL TPS by purchasing upgrade licenses.
Table 3-1
ACE Licenses
Feature (Default)
License PID
Virtualization
ACE-VIRT-020
(default, one Admin ACE-VIRT-050
context and five user
ACE-VIRT-100
contexts)
ACE-VIRT-250
Module bandwidth
(default, 4 Gbps)
Description
20 virtual contexts
50 virtual contexts
100 virtual contexts
250 virtual contexts
ACE-VIRT-UP1
Upgrades 20 to 50 contexts
ACE-VIRT-UP2
Upgrades 50 to 100 contexts
ACE-VIRT-UP3
Upgrades 100 to 250 contexts
ACE-04G-LIC
Default 4-Gbps bandwidth
ACE-08G-LIC
8-Gbps bandwidth
ACE-16G-LIC
16-Gbps bandwidth (ACE20-MOD-K9 module only)
ACE-UPG1-LIC
Upgrades 4-Gbps bandwidth to 8-Gbps bandwidth
ACE-UPG2-LIC
Upgrades 8-Gbps bandwidth to 16-Gbps bandwidth (ACE20-MOD-K9
module only)
Cisco Application Control Engine Module Administration Guide
OL-20814-01
3-1
Chapter 3
Managing ACE Software Licenses
Guidelines and Limitations
Table 3-1
ACE Licenses (continued)
Feature (Default)
License PID
Description
SSL TPS (default,
1000 TPS)
ACE-SSL-05K-K9
SSL with 5000 TPS
ACE-SSL-10K-K9
SSL with 10,000 TPS
ACE-SSL-15K-K9
SSL with 15,000 TPS
Guidelines and Limitations
The ACE license guidelines and limitations are as follows:
•
You can upgrade virtualization in increments if you do not exceed the limits of the ACE (a maximum
of 250 contexts).
•
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, use the show license usage command in Exec mode (see the “Displaying ACE License
Configurations and Statistics” section). ACE demo licenses are available through your Cisco
account representative.
•
If you need to replace the ACE, you can copy and install the license file for the license onto the
replacement module.
Prerequisites
You must have the Admin role in the Admin context to install, remove, and update the license file.
Default License Feature Capabilities
Table 3-2 lists the default feature capabilities of the ACE.
Table 3-2
Default Capabilities Parameters
Parameter
Default
Virtualization
One Admin context, five user contexts
Module bandwidth
4 gigabits per second (Gbps)
Secure Sockets Layer (SSL)
1000 transactions per second (TPS)
Cisco Application Control Engine Module Administration Guide
3-2
OL-20814-01
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Managing ACE Module Software Licenses
This section includes the following topics:
•
Tasks for Ordering an Upgrade License and Generating a Key
•
Copying a License File to the ACE
•
Installing a New or Upgrade License File
•
Replacing a Demo License with a Permanent License
•
Removing a License
•
Backing Up an ACE License File
•
Retrieving an ACE License File
Tasks for 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.
Follow these steps to order an upgrade license:
Step 1
Order one of the licenses from the list in the “Information about 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 Software License Claim Certificate as
your proof of purchase.
Step 4
Provide all the requested information to generate a license key.
After 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 attached license file to a remote server that you can access from the ACE. 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).
What to Do Next
Copy the license file to the ACE (see the “Copying a License File to the ACE” section).
Copying a License File to the ACE
This section describes how to copy an ACE license file from a remote server to the ACE. For detailed
information on copying files from a remote server, see Chapter 4, Managing the ACE Software.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
3-3
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Prerequisites
The license file must reside on a remote server that you can access from the ACE.
You must be in the Admin context to copy the file to disk0: on the ACE.
Detailed Steps
Command
Purpose
copy tftp:[//server[/path/][/filename]]
disk0:[path/]filename
Copies the file to disk0: on the ACE.
The arguments and keywords are as follows:
Example:
host1/Admin# copy
tftp://track/license/ACE-VIRT-020.lic
disk0:
•
[//server[/path/][/filename]]—The path to the network
server. This path is optional because the ACE prompts you
for this information if you omit it.
•
disk0:[path/]filename—Specifies that the file destination is
the disk0: directory of the current context and the filename.
If you do not provide the optional path, the ACE copies the
file to the root directory on the disk0: file system.
What to Do Next
If the license is a demo or permanent license for a new or upgrade installation, see the “Installing a New
or Upgrade License File” section.
If the license is a permanent license replacing a demo license, see the “Replacing a Demo License with
a Permanent License” section.
Installing a New or Upgrade License File
This section describes how to install a license after you copy a demo or permanent license file to the
ACE for a new or upgrade installation (see the “Copying a License File to the ACE” section). All license
installations except two have no adverse impact to an operating ACE as follows:
•
A reboot is required when you upgrade the bandwidth license from 8 Gbps to 16 Gbps in an ACE10
module.
•
In a redundant configuration, mismatched context licenses between the active and the standby ACEs
cause the active ACE to generate a syslog message (if logging is enabled) and to disable
configuration synchronization. After you install the correct matching license on the standby ACE,
the software automatically detects the new license and restores normal operation.
For information about replacing a demo license with a permanent one, see the “Replacing a Demo
License with a Permanent License” section.
Restrictions
This topic includes the following restrictions:
•
You must have the Admin role in the Admin context to install or upgrade the license file.
Cisco Application Control Engine Module Administration Guide
3-4
OL-20814-01
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
•
If you install a context demo license, make sure that you save the Admin running configuration and
all user context running configurations to a remote server. If you allow a context license to expire,
the ACE automatically removes all user contexts from the Admin running configuration and all
configurations for the user contexts.
•
There are multiple virtual context licenses including upgrade licenses. The number of contexts
currently installed on the ACE determines which additional license you can install, as shown in
Table 3-3.
Table 3-3
Allowable VIrtual User Context Installation
Current Number of Contexts Allowable License Installation
5 (default)
ACE-VIRT-020
ACE-VIRT-050
ACE-VIRT-100
ACE-VIRT-250
20
ACE-VIRT-UP1 (to upgrade to 50 contexts)
50
ACE-VIRT-UP2 (to upgrade to 100 contexts)
100
ACE-VIRT-UP3 (to upgrade to 250 contexts)
250
No additional licenses
Detailed Steps
Command
Purpose
license install disk0:[path/]filename
[target_filename]
Installs or upgrades a license on your ACE.
The arguments are as follows:
Example:
host1/Admin# license install
disk0:ACE-UPG1-LIC.lic
show license brief
•
[path/]filename—License stored on the disk0: file system. If
you do not specify the optional path, the ACE looks for the
file in the root directory.
•
target_filename—(Optional) Target filename for the license
file.
(Optional) Displays the installed licenses.
Example:
host1/Admin# show license brief
Examples
To install a license file for an SSL 5000 TPS license, enter:
host1/Admin# license install disk0:ACE-SSL-05K-K9.lic
To install a license file for a 20 context license, enter:
host1/Admin# license install disk0:ACE-VIRT-020.lic
Cisco Application Control Engine Module Administration Guide
OL-20814-01
3-5
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Replacing a Demo License with a Permanent License
This section describes how replace an ACE demo license with a permanent license. If you installed a
demo license, four weeks before the license expires, the ACE generates warning syslog messages once
a day. During the final week, a warning syslog message occurs once an hour. Before this period ends,
you must update the demo license with a permanent license. Otherwise, the ACE will revert to its
previous bandwidth, SSL TPS, or number of contexts.
After you copy the permanent license file to the ACE (see the “Copying a License File to the ACE”
section), you can install it.
Restrictions
This topic includes the following restrictions:
•
You must have the Admin role in the Admin context to update the demo license file with a permanent
file.
•
If you replace the context demo license with a permanent license, you can continue to use the
configured user contexts on the ACE. However, if you allow a context license to expire, the ACE
automatically removes all user contexts from the Admin running configuration and all
configurations for the user contexts. Before a context license expires, save the Admin running
configuration and the user context running configurations to a remote server. To view the expiration
of the demo license, use the show license usage command in Exec mode from the Admin context.
Detailed Steps
Command
Purpose
license update disk0:[path/]permanent_filename
demo_filename
Replaces a demo license with a permanent license.
The arguments are as follows:
Example:
host1/Admin# license update disk0:ACE-VIRT-250.lic
ACE-VIRT-250-DEMO.lic
•
[path/]permanent_filename—Filename for the
permanent license file that you copied onto the
ACE.
•
demo_filename—Filename for the demo license
file that the permanent license file is replacing.
Removing a License
This section describes how to remove an installed license from the ACE and includes the following
topics:
•
Removing a Bandwidth or SSL License
•
Removing a Virtual Context License
Cisco Application Control Engine Module Administration Guide
3-6
OL-20814-01
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Removing a Bandwidth or SSL License
This section describes how to remove a Bandwidth or SSL License.
Note
When you use the clear startup-config or the write erase command, the ACE does not remove license
files from the startup-configuration file.
Restrictions
This topics includes the following restrictions:
•
You must have the Admin role in the Admin context to remove the license file.
•
Bandwidth license removal—When you remove an ACE-08G-LIC or ACE-UPG1-LIC bandwidth
license, it reduces the module bandwidth to the default of 4 Gbps on the ACE. When you remove an
ACE-UPG2-LIC bandwidth license, it reduces the module bandwidth to 8 Gbps on the ACE.
•
SSL license removal—When you uninstall an SSL license, it reduces SSL TPS performance to 1000
TPS on the ACE.
Detailed Steps
Command
Purpose
license uninstall license_filename
Removes a module bandwidth, SSL TPS.
Example:
host1/Admin# license uninstall
disk0:ACE-UPG1-LIC.lic
The license_filename argument specifies the filename of the
license file that you want to remove. Enter the license filename as
an unquoted text string with no spaces.
Removing a Virtual Context License
This section describes how to removes a virtual context license.
Prerequisite
Caution
Before removing any virtual context license, save the Admin running configuration and the user context
running configurations to a remote server. When you remove a demo or permanent virtual context
license, the ACE removes all user contexts from the Admin running configuration. By removing the user
contexts, their running and startup configurations are also removed from the ACE.
Restrictions
This topic includes the following restrictions:
•
You must have the Admin role in the Admin context to remove the license file.
•
The number of virtual contexts and type of licenses currently installed on the ACE determines which
license you can remove. Table 3-4 lists the currently installed contexts, the type of license on the
ACE, and the remaining number of contexts after the license is removed.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
3-7
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Table 3-4
VIrtual Context License Removal
Current Number of Contexts Applicable Licenses
Results of License Removal
5 (default)
Not applicable
—
20
ACE-VIRT-020
5 contexts
50
ACE-VIRT-050
5 contexts
ACE-VIRT-UP1
20 contexts
ACE-VIRT-100
5 contexts
ACE-VIRT-UP2
50 contexts
ACE-VIRT-250
5 contexts
ACE-VIRT-UP3
100 contexts
100
250
Follow these steps to remove a context license:
Step 1
Save the Admin and user context running configurations to a remote server by entering the copy
running-config command in Exec mode in each context. For more information on this command, see
Chapter 4, Managing the ACE Software.
For example, to copy the Admin running configuration to an TFTP server as R-CONFIG-ADM, enter:
host1/Admin# copy running-config tftp://192.168.1.2/R-CONFIG-ADM
To copy the C1 user context running configuration to an TFTP server, access the C1 context and enter:
host1/C1# copy running-config tftp://192.168.1.2/R-CONFIG-C1
Step 2
Remove the license with the license uninstall command. For example, to remove the
ACE-VIRT-250.LIC license, enter:
host1/Admin# license uninstall ACE-VIRT-250.lic
The ACE displays the following messages and prompt:
Clearing license ACE-VIRT-250.lic:
SERVER this_host ANY
VENDOR cisco
INCREMENT ACE-VIRT-250 cisco 1.0 permanent 1 \
VENDOR_STRING=<count>1</count> HOSTID=ANY \
NOTICE=”<LicFileID>20051103151315824</LicFileID><LicLineID>1</LicLineID> \
<PAK></PAK>” SIGN=86A13B1EA2F2
INCREMENT ACE-VIRT-250 cisco 1.0 permanent 1 \
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! WARNING: Uninstalling virtual context license will automatically!!
!!! cleanup all the user context configurations, please backup the !!
!!! configurations before proceeding further with uninstallation
!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Do you want to continue? (y/n)
Step 3
If you have not saved the running configurations for the Admin and user contexts to a remote server,
enter n. Go to Step 1
If you saved the running configurations for the Admin and user contexts to a remote server, enter y.
During the license removal, the ACE removes the user context configurations from the Admin running
configuration, causing the deletion of all user contexts including their running and startup
configurations.
Cisco Application Control Engine Module Administration Guide
3-8
OL-20814-01
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Step 4
Display the current number of supported contexts on the ACE by entering the show license status
command in Exec mode of the Admin context.
Step 5
Determine which contexts you want to keep in the Admin running configuration. Using a text editor,
manually remove the extra context configurations from the Admin running configuration on the remote
server.
If the Admin running configuration contains more contexts than what the ACE supports and you copy
this configuration to the ACE, the ACE rejects contexts that exceed the supported limit. For example, if
the running configuration contains 20 contexts, when you remove the license, the ACE supports five
contexts. If you attempt to copy the configuration with all 20 contexts, the ACE allows the first five
contexts, fails the remaining contexts, and displays error messages on the console.
Note
Step 6
You can also manually recreate the user contexts in the running configuration that is currently
on the ACE. If you do, go to Step7.
Retrieve the modified Admin running configuration from the remote server. For example, to copy the
R-CONFIG-ADM Admin running configuration from the TFTP server, enter:
host1/Admin# copy tftp://192.168.1.2/R-CONFIG-ADM running-config
Step 7
Copy the Admin running configuration to the startup-configuration file. For example, enter:
host1/Admin# copy running-config startup-config
Note
Step 8
If you do not update the startup configuration with the latest running configuration, when the
ACE restarts, it uses the startup configuration with the extra contexts. The ACE allows the
number of contexts that the license supports, but fails the remaining contexts.
Access the user context, and copy its running configurations from the remote server. For example, to
copy the C1 user context running configuration from the TFTP server, access the C1 context and enter:
host1/C1# tftp://192.168.1.2/R-CONFIG-C1 copy running-config
Step 9
Copy the user context running configuration to the startup-configuration file. For example, enter:
host1/Admin# copy running-config startup-config
Step 10
Repeat Steps 8 and 9 until you retrieve the running configurations for all user contexts configured in the
Admin configuration.
Backing Up an ACE License File
This section describes how to back up an ACE license file. To protect your license files, we recommend
that you back up your license files (in .tar format) to the ACE Flash disk.
Restrictions
You must be in the Admin context to back up an ACE license file.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
3-9
Chapter 3
Managing ACE Software Licenses
Managing ACE Module Software Licenses
Detailed Steps
Command
Purpose
copy licenses disk0:[path/]filename.tar
Backs up your license files to the ACE Flash disk as tar files.
Example:
host1/Admin# copy licenses
disk0:mylicenses.tar
The keyword and argument are as follows:
•
disk0:—Specifies that the backup license file is copied to the
disk0: file system.
•
[path/]filename.tar—Destination filename for the backup
licenses. The destination filename must have a .tar file
extension.
Retrieving an ACE License File
This section describes how retrieve an ACE license file. If you accidently remove or lose the license on
the ACE, you can untar your backup license file and then reinstall it.
Restrictions
You must be in the Admin context to retrieve an ACE license file.
Detailed Steps
Command
Purpose
untar disk0:[path/]filename.tar
Untars the backup file should you need to reinstall it because you
accidently removed or lost the license.
Example:
host1/Admin# untar disk0:mylicenses.tar
The [path/]filename.tar argument is the filename of the .tar
backup license file.
For information on installing the license, see the “Installing a
New or Upgrade License File” section.
Cisco Application Control Engine Module Administration Guide
3-10
OL-20814-01
Chapter 3
Managing ACE Software Licenses
Displaying ACE License Configurations and Statistics
Displaying ACE License Configurations and Statistics
To display license information about your ACE, perform one of the following tasks in the Admin context
only:
Command
Purpose
show license [brief | file filename | internal
event-history | status | usage]
Displays all or some of the license information.
Entering this Exec mode command without any options and arguments
displays all installed ACE license files and their contents.
The options and arguments for this command are as follows:
•
brief—Displays a list of the currently installed licenses.
•
file filename—Displays the file contents of the specified license.
•
internal event-history—Displays a history of licensing-related
events.
•
status—Displays the status of licensed features (see Table 3-5).
•
usage—Displays the usage table for all licenses (see Table 3-6).
show version
Displays license information.
show module services
Displays license information. Enter this command on the supervisor
engine. See the license information under the Services field.
Table 3-5 describes the fields in the show license status command output.
Table 3-5
Field
Field Descriptions for the show license status Command Output
Description
Licensed Feature List including the ACE virtualized contexts, the SSL transactions per second, and the module bandwidth
feature.
Count
Number of ACE-supported contexts, SSL transactions per second (TPS), and bandwidth in gigabits per
second (Gbps). This information also provides the default number of contexts, SSL TPS, and module
bandwidth that the ACE supports when a license is not installed.
Table 3-6 describes the fields in the show license usage command output.
Table 3-6
Field Descriptions for the show license usage Command Output
Field
Description
License
Name of the license.
Ins
Whether the license is installed (Yes or No).
Lic Count
Number of licenses for this feature.
Status
Current state of the feature (In use or Unused).
Expiry Date
Date when the demo license expires, as defined in the license file. If the license is permanent, this field
displays Never.
Comments
Licensing errors, if any.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
3-11
Chapter 3
Managing ACE Software Licenses
Displaying ACE License Configurations and Statistics
Cisco Application Control Engine Module Administration Guide
3-12
OL-20814-01
CH A P T E R
4
Managing the ACE Software
This chapter describes how to manage the software running on the Cisco Application Control Engine
(ACE) module and contains the following major sections:
•
Saving Configuration Files
•
Copying Configuration Files from a Remote Server
•
Displaying the Configuration Download Progress Status
•
Using the File System on the ACE
•
Using Backup and Restore
•
Managing Core Dump Files
•
Capturing Packet Information
•
Using the Configuration Checkpoint and Rollback Service
•
Reformatting the Flash Memory
Saving Configuration Files
Upon startup, the ACE loads the startup-configuration file stored in Flash memory (nonvolatile memory)
to the running-configuration file stored in RAM (volatile memory). When you partition your ACE into
multiple contexts, each context contains its own startup-configuration file.
Flash memory stores the startup-configuration files for each existing context. When you create a new
context, the ACE creates a new context directory in Flash memory to store the context-specific
startup-configuration files. When you copy a configuration file from the ACE, you create a copy of the
configuration information of the context from where you executed the command.
When you make configuration changes, the ACE places those changes in a virtual running-configuration
file called the running-config, which is associated with the context that you are working in. When you
enter a CLI command, the change is made only to the running-configuration file in volatile memory.
Before you log out or reboot the ACE, copy the contents of the running-configuration file to the
startup-configuration file (startup-config) to save configuration changes for the current context to Flash
memory. The ACE uses the startup-configuration file on subsequent reboots.
This section contains the following topics:
•
Saving the Configuration File in Flash Memory
•
Saving Configuration Files to a Remote Server
•
Copying the Configuration File to the disk0: File System
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-1
Chapter 4
Managing the ACE Software
Saving Configuration Files
•
Merging the Startup-Configuration File with the Running-Configuration File
•
Clearing the Startup-Configuration File
•
Displaying Configuration File Content
Saving the Configuration File in Flash Memory
This section describes how to save the contents of the running-configuration file in RAM (volatile
memory) to the startup-configuration file for the current context in Flash memory (nonvolatile memory)
on the ACE.
Detailed Steps
Command
Purpose
copy running-config startup-config
Copies the contents of the running-configuration file to the
startup-configuration file.
Example:
host1/Admin# copy running-config
startup-config
write memory [all]
Example:
host1/Admin# write memory all
Copies the contents of the running-configuration file to the
startup-configuration file.
The optional all keyword saves configurations for all existing contexts.
This keyword is available only in the Admin context.
When used without the all keyword, this command copies the contents of
the running-configuration file for the current context to the
startup-configuration file.
Note
After you save the contents of the running-configuration file for
the current user context to the startup-configuration file, you
should also save the changes to the Admin context
startup-configuration file, which contains all configurations that
are used to create each user context.
Saving Configuration Files to a Remote Server
This section describes how to save the running-configuration file or startup-configuration file to a remote
server using File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), or Trivial Transfer
Protocol (TFTP). The copy serves as a backup file for the running-configuration file or
startup-configuration file for the current context. Before installing or migrating to a new software
version, back up the ACE startup-configuration file to a remote server using FTP, SFTP, or TFTP. When
you name the backup file, we recommend that you name it in such a way that you can easily tell the
context source of the file (for example, running-config-ctx1, startup-config-ctx1).
Cisco Application Control Engine Module Administration Guide
4-2
OL-20814-01
Chapter 4
Managing the ACE Software
Saving Configuration Files
Detailed Steps
Command
Purpose
copy {running-config | startup-config}
{ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]}
Saves the running-configuration file or startup-configuration file to a
remote server using FTP, SFTP, or FTP.
Example:
host1/Admin# copy running-config
ftp://192.168.1.2/running-config_Adminctx
Enter username[]? user1
Enter the file transfer mode[bin/ascii]: [bin]
Password: password1
Passive mode on.
Hash mark printing on (1024 bytes/hash mark).
####
The keywords, arguments, and options are as follows:
•
running-config—Specifies the running-configuration file
currently residing on the ACE in volatile memory.
•
startup-config—Specifies the startup-configuration file
currently residing on the ACE in Flash memory.
•
ftp://server/path[/filename]—Specifies the FTP network server
and, optionally, the renamed configuration file.
When using FTP, the bin (binary) file transfer mode is intended
for transferring compiled files (executables). The ascii file
transfer mode is intended for transferring text files, such as config
files. The default selection of bin should be sufficient in all cases
when copying files to a remote FTP server.
•
sftp://[username@]server/path[/filename]—Specifies the SFTP
network server and, optionally, the renamed configuration file.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP
network server and, optionally, the renamed configuration file.
When you select a destination file system using ftp:, sftp:, or tftp:,
the ACE performs the following tasks:
•
Prompts you for your username and password if the destination
file system requires user authentication.
•
Prompts you for the server information if you do not provide the
information with the command.
•
Copies the file to the root directory of the destination file system
if you do not provide the path information.
Copying the Configuration File to the disk0: File System
This section describes how to copy the running-configuration file or the startup-configuration file to the
disk0: file system in Flash memory on the ACE.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-3
Chapter 4
Managing the ACE Software
Saving Configuration Files
Detailed Steps
Command
Purpose
copy {running-config | startup-config}
disk0:[path/]filename
Copies either the running configuration of the startup configuration to a
file on the disk0: file system in Flash memory.
Example:
host1/Admin# copy running-config
disk0:running-config_copy
The keywords and arguments are as follows:
•
running-config—Specifies the running-configuration file currently
residing on the ACE in RAM (volatile memory).
•
startup-config—Specifies the startup-configuration file currently
residing on the ACE in Flash memory (nonvolatile memory).
•
[path/]filename—Path in the disk0: file system. If you do not provide
the optional path, the ACE copies the file to the root directory on the
disk0: file system.
Merging the Startup-Configuration File with the Running-Configuration File
This section describes how to merge the contents of the startup-configuration file into the
running-configuration file. This process copies any additional configurations from the
startup-configuration file into the running-configuration file. If any common commands exist in both
files, the startup-configuration file overwrites the attributes in the running-configuration file.
Detailed Steps
Command
Purpose
copy startup-config running-config
Merges the contents of the startup-configuration file into the
running-configuration file.
Example:
host1/Admin# copy startup-config
running-config
Displaying Configuration File Content
To display the content of the running- and startup-configuration files, perform one of the following tasks:
Cisco Application Control Engine Module Administration Guide
4-4
OL-20814-01
Chapter 4
Managing the ACE Software
Saving Configuration Files
Command
Purpose
show running-config [aaa | access-list |
action-list | class-map | context | dhcp | domain
| ft | interface | object-group | parameter-map |
policy-map | probe | resource-class | role |
rserver | serverfarm | sticky]
Displays the contents of the running configuration associated with the
current context. Configuration entries within each mode appear in the
chronological order in which you configure the ACE. The ACE does not
display default configurations in the ACE running-configuration file.
write terminal
The keywords and options are as follows:
•
aaa—(Optional) Displays AAA information.
•
access-list—(Optional) Displays access control list (ACL)
information.
•
action-list—(Optional) Displays action-list information.
•
class-map—(Optional) Displays all class maps configured for the
current context. The ACE also displays configuration information for
each class map.
•
context—(Optional) Displays the contexts configured on the ACE.
The ACE also displays the resource class (member) assigned to each
context. The context keyword works only from within the Admin
context.
•
dhcp—(Optional) Displays Dynamic Host Configuration Protocol
(DHCP) information.
•
domain—(Optional) Displays the domains configured for the current
context. The ACE also displays configuration information for each
domain listed.
•
ft—(Optional) Displays the redundancy or fault-tolerance (FT)
configurations configured for the current context. The ACE also
displays configuration information for each FT configuration.
•
interface—(Optional) Displays interface information.
•
object-group—(Optional) Displays ACL object-group information.
•
parameter-map—(Optional) Displays parameter map information.
•
policy-map—(Optional) Displays policy map information.
•
probe—(Optional) Displays probe information.
•
resource-class—(Optional) Displays resource class information.
•
role—(Optional) Displays the roles configured for the current
context. The ACE also displays configuration information for each
role.
•
rserver—(Optional) Displays real server information.
•
serverfarm—(Optional) Displays serverfarm information.
•
sticky—(Optional) Displays sticky information.
Displays the contents of the running configuration associated with the
current context. The write terminal command is equivalent to the show
running-config command.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-5
Chapter 4
Managing the ACE Software
Saving Configuration Files
Command
Purpose
invoke context context_name show
running-config
Displays the running-configuration file of a user context from the Admin
context. The context_name argument is the name of the user context.
show startup-config
Displays the contents of the startup configuration associated with the
current context.
Clearing the Startup-Configuration File
This section describes how to clear the contents of the ACE startup-configuration file of the current
context in Flash memory. Both commands reset the startup-configuration file to the default settings and
take effect immediately.
Restrictions
The clear startup-config and write erase commands used to clear the contents of the ACE
startup-configuration file of the current context in Flash memory include the following restrictions:
•
These commands do not affect the following items:
– Running-configuration file
– Boot variables, such as config-register and boot system settings
The commands do not remove the following items from the ACE startup-configuration file:
•
License files—To remove license files, use the license uninstall filename command (see the
“Removing a License” section on page 3-6.).
•
Crypto files—To remove crypto files, use the crypto delete filename or the crypto delete all
command (see the Cisco Application Control Engine Module SSL Configuration Guide).
Detailed Steps
Step 1
Command
Purpose
copy startup-config
{ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]}
(Optional) Creates a backup of your current startup-configuration
file on a remote server.
For details about using this command, see the “Saving
Configuration Files to a Remote Server” section.
Example:
host1/Admin# copy startup-config
ftp://192.168.1.2/startup-config_Adminctx
Step 2
clear startup-config
Example:
host1/Admin# clear startup-config
Clears the contents of the startup-configuration file and resets it
to the default settings.
write erase
Example:
host1/Admin# write erase
Cisco Application Control Engine Module Administration Guide
4-6
OL-20814-01
Chapter 4
Managing the ACE Software
Copying Configuration Files from a Remote Server
Step 3
Command
Purpose
copy running-config startup-config
(Optional) Recovers a copy of an startup configuration by copying
the contents of the existing running-configuration file to the
startup-configuration file.
Example:
host1/Admin# copy running-config
startup-config
copy {ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]}
startup-config
(Optional) Recovers a copy of an existing startup configuration
saved on a remote server.
For details about using this command, see the “Copying
Configuration Files from a Remote Server” section.
Example:
host1/Admin# copy
ftp://192.168.1.2/startup-config_Adminctx
startup-config
Copying Configuration Files from a Remote Server
This section describes how to configure the ACE by downloading a copy of a running-configuration file
or startup-configuration file from a remote server. When you copy the backup configuration file to the
ACE, you copy the configuration information to the context from where you initially executed the copy
command.
Prerequisites
This topics includes the following prerequisites:
•
You know the location of the configuration file to be loaded from the remote server.
•
The configuration file permissions are set to world-read.
•
The ACE has a route to the remote server. The ACE and the remote server must be in the same
subnetwork if you do not have a router or default gateway to route the traffic between subnets. To
check connectivity to the remote server, use the ping or traceroute command in Exec mode. See the
Cisco Application Control Engine Module Routing and Bridging Configuration Guide for details on
how to use the ping and traceroute commands.
•
Ensure that the configuration file is appropriate for use in the current context. For example, you
would copy the backup configuration file startup-config-ctx1 to context 1.
Detailed Steps
Command
Purpose
copy {ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]}
{running-config | startup-config}
Configures the ACE using a running-configuration file or
startup-configuration file downloaded from a remote server.
For details about using this command, see the “Copying
Configuration Files from a Remote Server” section.
Example:
host1/Admin# copy
ftp://192.168.1.2/startup-config_Adminctx
startup-config
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-7
Chapter 4
Managing the ACE Software
Displaying the Configuration Download Progress Status
Displaying the Configuration Download Progress Status
This section describes how to display the progress of a configuration download when a large
configuration file in the ACE has been applied to a context.
When you apply changes to a configuration file, the ACE downloads the configuration to its data plane.
When you perform incremental changes, such as copying and pasting commands in a configuration, the
ACE immediately performs the configuration download and does not display any terminal messages at
the start or end of the download.
However, in the following situations, the ACE defers the configuration download until the entire
configuration is applied to the context:
•
A startup configuration at boot time
•
Copying of the configuration to the running-configuration file
•
A checkpoint rollback
At the start of the deferred download, the ACE displays the following message on all terminals that are
logged into the context including a terminal that you log into for the context before the download is done:
Processing has started for applied config
During the download, the ACE locks the context and denies any configuration changes until the
download is completed.
Note
We recommend that you do not execute any configuration commands during the deferred download. The
ACE does not deny you from entering configuration changes. But the changes will not occur until the
download is completed. If the command times out during the download, the following message appears:
Config application in progress. This command is queued to the system.
The ACE does not queue the command immediately, however, the ACE processes and executes the
command when the download is completed even if the command times out.
You can execute the show download information command to monitor the progress of the download.
You can also execute show commands that do not have interaction with the configuration manager
(cfgmgr). For example, these commands include the show acl-merge, show interface, show context,
show crypto files, and show fifo commands.
The show commands that have interaction with the cfgmgr do not work when the download occurs. For
example, these commands include the show access-list, show conn, show domain, show
running-config, and show service-policy commands. If you execute a cfgmgr show command during
the download, the following error message occurs:
System Busy: Config application in progress
At the end of the deferred download, the ACE displays the follow message on all terminals that are
logged into the context:
Processing has finished for applied config
Cisco Application Control Engine Module Administration Guide
4-8
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
To display the progress status of the configuration download on a context, perform the following task:
Command
Purpose
show download information [all] [summary]}
Displays the state of the configuration download for each interface on the
context. If no option is included with this command, the status information
for all interfaces in the current context is displayed. The options are as
follows:
Example:
host1/Admin# show download information all
•
all —Displays the configuration download status for all interfaces on
all contexts. This option is available in the Admin context.
•
summary—Displays the summary status of the download
information for the context. When you include the all option with the
summary option, the download summary status for all contexts is
displayed.
See Table 4-1 for information on the download states that the
Download-status field displays.
Table 4-1 describes the fields that appear in the show download information command output.
Table 4-1
Field Descriptions for the show download information command
Field
Description
Context
Name of the context.
Interface
Number of the interface on the context. This field is not displayed with the summary option.
Download-Status
State of the configuration download. With no option or the all option, the possible states are as
follows:
•
Pending—The interface has been updated but the update has not been downloaded.
•
In Progress—The interface download is in progress.
•
Completed—The interface download is completed.
•
Pending/Deleted—The interface has been deleted but it has not been downloaded.
•
In progress/Deleted—The interface has been deleted and the download is in progress.
With the summary option, the possible states are as follows:
•
Completed—All of the interfaces have a status of Completed.
•
Pending—One or more of the interfaces are in the Pending state and the rest of the interfaces are
in the Completed state.
•
In Progress—One or more interfaces are in the Progress state and the rest of the interfaces are in
the Completed or Pending state.
Using the File System on the ACE
This section describes how use the ACE file system. Flash memory stores the operating system,
startup-configuration files, software licenses, core dump files, system message log files, SSL certificates
and keys, probe scripts, and other data on the ACE. Flash memory comprises a number of individual file
systems, or partitions, that include this data.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-9
Chapter 4
Managing the ACE Software
Using the File System on the ACE
The ACE contains the following file systems, or partitions:
•
disk0:—Contains all startup-configuration files, software licenses, system message log files, SSL
certificates and keys, and user-generated data for all existing contexts on the ACE.
•
image:—Contains the system software images.
•
core:—Contains the core files generated after each time that the ACE becomes unresponsive.
•
probe:—Contains the Cisco-supplied scripts. For more information about these scripts, see the
Cisco Application Control Engine Module Server Load-Balancing Configuration Guide. Both the
Admin context and user contexts support the probe: directory.
•
volatile:—Contains the files residing in the temporary (volatile:) directory. The volatile: directory
provides temporary storage; files in temporary storage are erased when the ACE reboots.
The Admin context supports all five file systems in the ACE. The user context supports only the disk0:,
probe:, and volatile: file systems.
When you create a new context, the ACE creates a new context directory in Flash memory to store
context-specific data such as startup-configuration files.
The ACE provides a number of useful commands to help you manage software configuration and image
and files.This section contains the following topics that will help you to manage files on the ACE:
•
Copying Files
•
Uncompressing Files in the disk0: File System
•
Untarring Files in the disk0: File System
•
Creating a New Directory
•
Deleting an Existing Directory
•
Moving Files
•
Deleting Files
•
Displaying Files Residing On the ACE
•
Saving show Command Output to a File
Copying Files
This section describes how create copies of a file on the ACE and how to copy files to and from the ACE.
This section contains the following topics:
•
Copying Files to Another Directory on the ACE
•
Copying Licenses
•
Copying a Packet Capture Buffer
•
Copying Files to a Remote Server
•
Copying Files from a Remote Server
•
Copying an ACE Software System Image to a Remote Server
Copying Files to Another Directory on the ACE
This section describes how to copy a file from one directory in the disk0: file system of Flash memory to
another directory in disk0:.
Cisco Application Control Engine Module Administration Guide
4-10
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Detailed Steps
Step 1
Command
Purpose
dir disk0:
(Optional) Displays the contents of the disk0: file system.
Example:
host1/Admin# dir disk0:
Step 2
copy disk0:[path/]filename1
{disk0:[path]filename2}
Copies a file from one directory in the disk0: file system of Flash
memory to another directory in disk0:.
Example:
host1/Admin# copy disk0:samplefile
disk0:MYSTORAGE/SAMPLEFILE
The keywords and arguments are as follows:
•
[path/]filename1—Name of the file to copy. Use the dir
disk0: command to view the files available in the disk0: file
system. If you do not provide the optional path, the ACE
copies the file from the root directory on the disk0: file
system.
•
disk0:[path]filename2—Specifies the file destination in the
disk0: directory of the current context. If you do not provide
the optional path, the ACE copies the file to the root directory
on the disk0: file system.
Copying Licenses
This section describes how to create a backup license for the ACE licenses in .tar format and copy it to
the disk0: file system. To protect your license files, we recommend that you back up your license files
to the ACE Flash memory as tar files.
Detailed Steps
Command
Purpose
copy licenses disk0:[path/]filename.tar
Creates a backup license for the ACE licenses in .tar format and
copies it to the disk0: file system.
Example:
host1/Admin# copy licenses
disk0:mylicenses.tar
untar disk0:[path/]filename.tar
Example:
host1/Admin# copy licenses
disk0:mylicenses.tar
The keyword and argument are as follows:
•
disk0:—Specifies that the backup license file is copied to the
disk0: file system.
•
[path/]filename.tar—Destination filename for the backup
licenses. The destination filename must have a .tar file
extension. If you do not provide the optional path, the ACE
copies the file to the root directory on the disk0: file system.
(Optional) Untars the backup file and reinstalls it if you
accidently remove or lose the license on the ACE (see the
“Untarring Files in the disk0: File System” section).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-11
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Copying a Packet Capture Buffer
This section describes how to copy an existing packet capture buffer to the disk0: file system.
Detailed Steps
Command
Purpose
copy capture capture_name
disk0:[path/]destination_name
Copies an existing packet capture buffer to the disk0: file system.
The keywords, arguments, and options are as follows:
Example:
host1/Admin# copy capture
packet_capture_Jan_17_07
disk0:capture_Jan_17_07
•
capture_name—Name of the packet capture buffer on Flash memory.
Specify a text string from 1 to 64 alphanumeric characters. If
necessary, use the show capture command to view the files available
in the disk0: file system. This list includes the name of existing packet
capture buffers.
•
disk0:—Specifies that the buffer is copied to the disk0: file system.
•
[path/]destination_name—Destination path (optional) and name for
the packet capture buffer. Specify a text string from 1 to
80 alphanumeric characters. If you do not provide the optional path,
the ACE copies the file to the root directory on the disk0: file system.
Copying Files to a Remote Server
This section describes how to copy a file from Flash memory on the ACE to a remote server using FTP,
SFTP, or TFTP. The copy serves as a backup file for such files as the capture buffer file, core dump, ACE
licenses in .tar format, running-configuration file, or startup-configuration file.
Cisco Application Control Engine Module Administration Guide
4-12
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Detailed Steps
Command
Purpose
copy {core:filename | disk0:[path/]filename |
running-config | startup-config}
{ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]}
Copies a file from Flash memory on the ACE to a remote server
using FTP, SFTP, or TFTP.
The keywords, arguments, and options are as follows:
•
core:filename—Specifies a core dump residing on the ACE
in Flash memory (see the “Managing Core Dump Files”
section). The copy core: command is available only in the
Admin context. Use the dir core: command to view the
core dump files available in the core: file system. Copy the
complete filename (for example,
0x401_vsh_log.25256.tar.gz) by using the copy core:
command.
•
disk0:[path/]filename—Specifies a file in the disk0: file
system of Flash memory (for example, a packet capture
buffer file, ACE licenses in .tar format, or a system message
log). Use the dir disk0: command to view the files
available in the disk0: file system.
•
running-config—Specifies the running-configuration file
residing on the ACE in volatile memory.
•
startup-config—Specifies the startup-configuration file
currently residing on the ACE in Flash memory.
•
ftp://server/path[/filename]—Specifies the FTP network
server and, optionally, the renamed file.
Example:
host1/Admin# copy running-config
ftp://192.168.215.124/running-config_Adminctx
Enter username[]? user1
Enter the file transfer mode[bin/ascii]: [bin]
Password: password1
Passive mode on.
Hash mark printing on (1024 bytes/hash mark).
####
When using FTP, the bin (binary) file transfer mode is
intended for transferring compiled files (executables). The
ascii file transfer mode is intended for transferring text
files, such as config files. The default selection of bin mode
should be sufficient in all cases when copying files to a
remote FTP server.
•
sftp://[username@]server/path[/filename]—Specifies the
SFTP network server and, optionally, the renamed file.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP
network server and, optionally, the renamed file.
When you select a destination file system using ftp:, sftp:, or
tftp:, the ACE performs the following tasks:
•
Prompts you for your username and password if the
destination file system requires user authentication.
•
Prompts you for the server information if you do not
provide the information with the command.
•
Copies the file to the root directory of the destination file
system if you do not provide path information.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-13
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Copying Files from a Remote Server
This section describes how to copy a file from a remote server to a location on the ACE using FTP, SFTP,
or TFTP.
Detailed Steps
Command
Purpose
copy {ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]}
{disk0:[path/]filename | image:image_name |
running-config | startup-config}
Copies a file from a remote server to a location on the ACE using FTP,
SFTP, or TFTP.
Example:
host1/Admin# copy ftp://192.168.1.2/
startup-config
Enter source filename[]?
startup_config_Adminctx
File already exists, do you want to
overwrite?[y/n]: [y] y
Enter username[]? user1
Enter the file transfer mode[bin/ascii]: [bin]
Password:
Passive mode on.
Hash mark printing on (1024 bytes/hash mark).
The keywords, arguments, and options are as follows:
•
ftp://server/path[/filename]—Specifies the FTP network server
and, optionally, the filename.
When using FTP, the bin (binary) file transfer mode is intended
for transferring compiled files (executables). The ascii file
transfer mode is intended for transferring text files, such as config
files. The default selection of bin mode should be sufficient in all
cases when copying files to a remote FTP server.
•
sftp://[username@]server/path[/filename]—Specifies the SFTP
network server and, optionally, the filename.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP
network server and, optionally, the filename.
•
disk0:[path/]filename—Specifies a file destination in the disk0:
file system of Flash memory. If you do not provide the optional
path, the ACE copies the file to the root directory on the disk0:
file system.
•
image:image_name—Specifies to copy a system software image
to Flash memory. Use the boot system command as described in
Chapter 1, Setting Up the ACE to specify the BOOT environment
variable. The BOOT environment variable specifies a list of
image files on various devices from which the ACE can boot at
startup.
•
running-config—Specifies to replace the running-configuration
file currently residing on the ACE in RAM (volatile memory).
•
startup-config—Specifies to replace the startup-configuration
file currently residing on the ACE in Flash memory (nonvolatile
memory).
Copying an ACE Software System Image to a Remote Server
This section describes how to copy an ACE software system image from Flash memory to a remote
server using FTP, SFTP, or TFTP.
Restrictions
The copy image: command is available in the Admin context only.
Cisco Application Control Engine Module Administration Guide
4-14
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Detailed Steps
Step 1
Command
Purpose
dir image:
(Optional) Displays the software system images available in
Flash memory.
Example:
host1/Admin# dir image:
Step 2
show version
Example:
host1/Admin# show version
Step 3
copy image:filename
{ftp://server/path[/filename] |
sftp://[username@]server/path[/filename]
| tftp://server[:port]/path[/filename]}
Example:
host1/Admin# copy image:sb-ace.NOV_11
ftp://192.168.1.2
(Optional) Displays the version information of system software
that is loaded in flash memory and currently running on the ACE.
Copies an ACE software system image from Flash memory to a
remote server using FTP, SFTP, or TFTP.
The keywords, arguments, and options are as follows:
•
filename—Name of the ACE system software image.
•
ftp://server/path[/filename]—Specifies the FTP network
server and, optionally, the renamed software system image.
•
sftp://[username@]server/path[/filename]—Specifies the
SFTP network server and, optionally, the renamed software
system image.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP
network server and, optionally, the renamed software system
image.
When you select a destination file system using ftp:, sftp:, or
tftp:, the ACE performs the following tasks:
•
Prompts you for your username and password if the
destination file system requires user authentication.
•
Prompts you for the server information if you do not provide
the information with the command.
•
Copies the file to the root directory of the destination file
system if you do not provide path information.
Uncompressing Files in the disk0: File System
This section describes how to uncompress (unzip) LZ77 coded files in the disk0: file system (for
example, zipped probe script files).
Restrictions
The filename must end with a .gz extension for the file to be uncompressed using the gunzip command.
The .gz extension indicates a file zipped by the gzip (GNU zip) compression utility.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-15
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Detailed Steps
Step 1
Command
Purpose
dir disk0:[directory/][path/][filename]
(Optional) Displays a list of available zipped files on the disk0:
file system.
Example:
host1/Admin# dir disk0:
Step 2
The arguments are as follows:
gunzip disk0:filename
Example:
host1/Admin# gunzip disk0:PROBE_SCRIPTS.gz
•
directory/—(Optional) Contents of the specified directory.
•
path/—(Optional) Path to display the contents of a specific
directory on the disk0: file system.
•
filename—(Optional) Information that relates to the
specified file, such as the file size and the date it was created.
You can use wildcards in the filename. A wildcard character
(*) matches all patterns. Strings after a wildcard are ignored.
Uncompresses (unzips) LZ77 coded files in the disk0: file
system.
The filename argument identifies the name of the compressed file
on the disk0: file system. The filename must end with a .gz
extension.
Untarring Files in the disk0: File System
This section describes how to untar a single file with a .tar extension in the disk0: file system. Use this
process to untar the sample scripts file or to unzip a back-up licenses created with the copy licenses
disk0: command if a license becomes corrupted or lost.
A .tar file keeps related files together and facilitates the transfer of multiple files. A .tar file is a series
of separate files, typically not compressed, added together into a single file by a UNIX TAR program.
The resulting file is known as a tarball, which is similar to a ZIP file but without the compression. The
files in a .tar file must be extracted before they can be used.
Restrictions
To untar a file, the filename must end with a .tar extension.
Detailed Steps
Command
Purpose
untar disk0:[path/]filename
Untars a single file with a .tar extension in the disk0: file system.
Example:
host1/Admin# untar disk0:mylicenses.tar
The filename argument identifies the name of the .tar file in the disk0: file
system. You can optionally provide a path to the .tar file if it exists in
another directory in the disk0: file system.
Cisco Application Control Engine Module Administration Guide
4-16
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Creating a New Directory
This section describes how to create a directory in the disk0: file system of Flash memory.
Detailed Steps
Command
Purpose
mkdir disk0:[path/]directory
Create a directory in the disk0: file system of Flash memory.
Example:
host1/Admin# mkdir disk0:TEST_DIRECTORY
The arguments are as follows:
•
path/—(Optional) Path on the disk0: file system to the new directory.
Specify the optimal path if you want to create a directory within an
existing directory.
•
directory—Name of the directory to create in disk0:. If a directory
with the same name already exists, the ACE does not create the new
directory and the “Directory already exists” message appears.
Deleting an Existing Directory
This section describes how to remove an existing directory from the disk0: file system of Flash memory.
Prerequisites
The directory must be empty before you can delete it. To remove a file from the ACE file system, use
the delete command (see the “Deleting Files” section).
Detailed Steps
Step 1
Command
Purpose
dir disk0:
(Optional) Displays the contents of the disk0: file system.
Example:
host1/Admin# dir disk0:
Step 2
rmdir disk0:[path/]directory
Example:
host1/Admin# rmdir disk0:TEST_DIRECTORY
Removes an existing directory from the disk0: file system of
Flash memory.
The directory argument provides the name of the directory to
delete from the disk0: file system. The directory must be empty
before you can delete it. You can optionally provide a path to a
directory in the disk0: file system.
Moving Files
This section describes how to move a file between directories in the disk0: file system. If a file with the
same name already exists in the destination directory, that file is overwritten by the moved file.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-17
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Detailed Steps
Step 1
Command
Purpose
dir disk0:
(Optional) Displays the files available in the disk0: file system.
Example:
host1/Admin# dir disk0:
Step 2
move disk0:[source_directory/]filename
disk0:[destination_directory/]filename
Moves a file between directories in the disk0: file system.
The keywords and arguments are as follows:
Example:
host1/Admin# move disk0:SAMPLEFILE
disk0:MYSTORAGE/SAMPLEFILE
•
source_directory—(Optional) Name of the source directory
in the disk0: file system.
•
destination_directory—(Optional) Name of the destination
directory in the disk0: file system.
•
filename—Name of the file to move in the disk0: file system.
Deleting Files
This section describes how to delete a file from a specific file system in the ACE. When you delete a file,
the ACE erases the file from the specified file system.
Note
To remove a directory from the ACE file system, use the rmdir command (see the “Deleting an Existing
Directory” section).
Detailed Steps
Step 1
Command
Purpose
dir {core: | disk0: | image: | volatile:}
(Optional) Displays the files available in the specified file
system.
Example:
host1/Admin# dir disk0:
Step 2
delete {core:filename |
disk0:[directory/]filename |
image:filename | volatile:filename}
Example:
host1/Admin# delete
disk0:mystorage/my_running-config1
Delete a file from a specific file system in the ACE.
The keywords and arguments are as follows:
•
core:filename—Deletes the specified file from the core: file
system (see the “Managing Core Dump Files” section). The
delete cores: command is available only in the Admin
context.
•
disk0:[directory/]filename— Deletes the specified file from
the disk0: file system (for example, a packet capture buffer
file or system message log). You can optionally provide a
path to a file in directory in the disk0: file system.
•
image:filename—Deletes the specified file from the image:
file system. The delete image: command is available only in
the Admin context.
•
volatile:filename—Deletes the specified file from the
volatile: file system.
Cisco Application Control Engine Module Administration Guide
4-18
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Displaying Files Residing On the ACE
To display the files in a directory and the contents of a file, perform the following tasks:
Command
Purpose
dir {core: | disk0:[directory/][filename] |
image:[filename] | probe:[filename] |
volatile:[filename]}
Displays a detailed list of directories and files contained within the
specified file system on the ACE, including names, sizes, and time
created.
The keywords and arguments are as follows:
show file {disk0: [path/]filename | volatile:
filename} [cksum | md5sum]
•
core:—Displays the contents of the core: file system.
•
disk0:—Displays the contents of the disk0: file system.
•
image:—Displays the contents of the image: file system.
•
probe:—Displays the contents of the probe: file system. This
directory contains the Cisco-supplied scripts. For more information
about these scripts, see the Cisco Application Control Engine Module
Server Load-Balancing Configuration Guide.
•
volatile:—Displays the contents of the volatile: file system.
•
directory/—(Optional) Contents of the specified directory.
•
filename—(Optional) Information that relates to the specified file,
such as the file size and the date it was created. You can use wildcards
in the filename. A wildcard character (*) matches all patterns. Strings
after a wildcard are ignored.
Displays the contents of a specified file in a directory in Flash memory or
in nonvolatile memory.
The keywords, arguments, and options are as follows:
•
disk0: [path/]filename—Specifies the name of a file residing in the
disk0: file system of Flash memory (for example, a packet capture
buffer file or system message log). You can optionally provide a path
to a file in a directory in the disk0: file system.
•
volatile: filename—Specifies the name of a file in the volatile
memory file system of the ACE.
•
cksum—(Optional) Displays the cyclic redundancy check (CRC)
checksum for the file. The checksum values compute a CRC for each
named file. Use this option to verify that the file is not corrupt. You
compare the checksum output for the received file against the
checksum output for the original file.
•
md5sum—(Optional) Displays the MD5 checksum for the file. MD5
is an electronic fingerprint for the file. MD5 is the latest
implementation of the internet standards described in RFC 1321 and
is useful for data security and integrity.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-19
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Examples
The following example shows the output of the dir disk0: commands:
host1/Admin# dir disk0:
7465
2218
1654692
1024
1024
1024
12
7843
4320
1024
Jan
Mar
Feb
Feb
Jan
Mar
Jan
Mar
Jan
Jan
03
07
27
16
01
13
30
09
05
01
00:13:22
18:38:03
21:42:07
12:47:24
00:02:07
13:53:08
17:54:26
22:19:56
14:37:52
00:02:28
2000
2006
2006
2006
2000
2006
2006
2006
2000
2000
C2_dsb
ECHO_PROBE_SCRIPT4
c6ace-t1k9_dplug-mzg.3.0.0_A0_2.44.bin
core_copies_dsb/
cv/
dsb_dir/
messages
running-config
startup-config
www/
Usage for disk0: filesystem
4254720 bytes total used
6909952 bytes free
11164672 total bytes
For example, to list the core dump files in Flash memory, enter:
host1/Admin# dir core:
253151
262711
250037
Mar 14 21:23:33 2006 0x401_vsh_log.8249.tar.gz
Mar 15 21:22:18 2006 0x401_vsh_log.15592.tar.gz
Mar 15 18:35:27 2006 0x401_vsh_log.16296.tar.gz
Usage for core: filesystem
1847296 bytes total used
64142336 bytes free
65989632 total bytes
Saving show Command Output to a File
This section describes how to save all show screen output to a file by appending > filename to any
command. For example, you can enter show interface > filename at the Exec mode CLI prompt to
redirect the interface configuration command output to a file created at the same directory level.
Cisco Application Control Engine Module Administration Guide
4-20
OL-20814-01
Chapter 4
Managing the ACE Software
Using the File System on the ACE
Detailed Steps
Command
Purpose
show keyword [| {begin pattern | count |
end | exclude pattern | include pattern |
last | more}] [> {filename | {disk0:|
volatile}:[path/][filename] |
{ftp://server/path[/filename] |
sftp://[username@]server/path[/filename]
| tftp://server[:port]/path[/filename]}
Saves a show command output to a file.
Example:
host1/Admin# show running-config >
ftp://192.168.1.2
The arguments, keywords, and options are as follows:
•
|—(Optional) Enables an output modifier that filters the command
output.
•
begin pattern—Begins with the line that matches the pattern that you
specify.
•
count—Counts the number of lines in the output.
•
end pattern—Ends with the line that matches the pattern that you
specify.
•
exclude pattern—Excludes the lines that match the pattern that you
specify.
•
include pattern—Includes the lines that match the pattern that you
specify.
•
last—Displays the last few lines of the output.
•
more—Displays one window page at a time.
•
>—(Optional) Enables an output modifier that redirects the command
output to a file.
•
filename—Name of the file that the ACE saves the output to on the
volatile: file system.
•
disk0:—Specifies that the destination is the disk0: file system on the
ACE Flash memory.
•
volatile:—Specifies that the destination is the volatile: file system on
the ACE.
•
[path/][filename]—(Optional) Path and filename to the disk0: or
volatile: file system.
•
ftp://server/path[/filename]—Specifies the FTP network server and,
optionally, a filename.
•
sftp://[username@]server/path[/filename]—Specifies the SFTP
network server and, optionally, a filename.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP network
server and, optionally, a filename.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-21
Chapter 4
Managing the ACE Software
Using Backup and Restore
Using Backup and Restore
This section describes how to back up and restore your ACE module configuration data and dependent
files. It contains the following subsections:
•
Information About the Backup and Restore Features
•
Guidelines and Limitations
•
Defaults
•
Backing Up the ACE Configuration Files and Dependencies
•
Restoring the ACE Configuration Files and Dependencies
•
Copying a Backup Archive to a Server
•
Displaying the Status of the Backup Operation
•
Displaying the Status of the Restoration
•
Displaying Backup and Restore Errors
Information About the Backup and Restore Features
This section provides information about the backup and restore features. With these features, you can
back up or restore the configuration and dependencies of an entire ACE or of a particular virtual context.
Configuration dependencies are those files that are required to exist on the ACE so that a configuration
can be applied to it. Such files include health-monitoring scripts, SSL certificates, SSL keys, and so on.
Note
The ACE backs up the dependencies that exist at the time when the backup is performed.
This feature allows you to back up and restore the following configuration files and dependencies:
Note
•
Running-configuration files
•
Startup-configuration files
•
Checkpoints
•
SSL certificates
•
SSL keys
•
Health-monitoring scripts
•
Licenses
The backup feature does not back up the sample SSL certificate and key pair files.
Typical uses for this feature are as follows:
•
Back up a configuration for later use
•
Recover a configuration that was lost because of a software failure or user error
•
Restore configuration files to a new ACE when a hardware failure resulted in an RMA of the old
ACE
•
Transfer the configuration files to a different ACE
Cisco Application Control Engine Module Administration Guide
4-22
OL-20814-01
Chapter 4
Managing the ACE Software
Using Backup and Restore
The backup and restore commands are supported in both the Admin and user contexts. If you enter these
commands in the Admin context, you can back up or restore the configuration files for either the Admin
context only or for all contexts in the ACE. If you enter the commands in a user context, you can back
up or restore the configuration files only for that context.
Both the backup and the restore commands run asynchronously (in the background). You can monitor
their progress by entering their corresponding show commands.
Archive File
The backup command runs asynchronously, that is, it runs in the background, which allows you to enter
other commands at the CLI while the ACE processes the backup. When you instruct the ACE to back up
the selected files, the ACE tars and GZIP-compresses them into a .tgz archive file and places the file in
disk0:. For the Admin context, you can store one archive for the Admin context and one archive for the
entire ACE. For a user context, you can store one archive for that context only. You can later use the
archive files to restore the state of the same ACE or a different ACE.
Each time that you create a new backup for the entire ACE or for a particular user context, the ACE
overwrites the previous ACE-wide archive or the context-specific archive, respectively.
Archive Naming Conventions
Archive files for individual contexts have the following naming convention format:
Hostname_ctxname_timestamp.tgz
where timestamp has the following format: yyyy_mm_dd_hh_mm_ss
For example:
ACE-1_ctx1_2009_08_30_15_45_17.tgz
If you back up the entire ACE, the archive filename does not include the ctxname field. So, the format
is as follows:
Hostname_timestamp.tgz
For example:
ACE-1_2009_08_30_15_45_17.tgz
Archive Directory Structure and Filenames
The ACE uses a flat directory structure for the backup archive. The ACE provides file extensions for the
individual files that it backs up so that you can identify the types of files easily when restoring an archive.
All files are stored in a single directory that is tarred and GZIPed as follows:
ACE-1_Ctx1_2009_08_30_15_45_17.tgz
ACE-1_Ctx1_2009_08_30_15_45_17\
context_name-running
context_name-startup
context_name-chkpt_name.chkpt
context_name-cert_name.cert
context_name-key_name.key
context_name-script_name.tcl
context_name-license_name.lic
When you choose to encrypt the key pair files in a backup archive, the ACE appends an .enc extension
to the filename (context_name-key_name.enc).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-23
Chapter 4
Managing the ACE Software
Using Backup and Restore
Guidelines and Limitations
The backup and restore features have the following configuration guidelines and limitations:
•
Use the Admin context for an ACE-wide backup and the corresponding context for a user context
backup.
•
When you back up the running-configuration file, the ACE uses the output of the show
running-configuration command as the basis for the archive file.
•
The ACE backs up only exportable certificates and keys.
•
License files are backed up only when you back up the Admin context.
•
Use a passphrase to back up SSL keys in encrypted form. Remember the passphrase or write it down
and store it in a safe location. When you restore the encrypted keys, you must enter the passphrase
to decrypt the keys. If you use a passphrase when you back up the SSL keys, the ACE encrypts the
keys with AES-256 encryption using OpenSSL software.
•
Only probe scripts that reside in disk0: need to be backed up. The prepackaged probe scripts in the
probe: directory are always available. When you perform a backup, the ACE automatically identifies
and backs up the scripts in disk0: that are required by the configuration.
•
The ACE does not resolve any other dependencies required by the configuration during a backup
except for scripts that reside in disk0:. For example, if you configured SSL certificates in an SSL
proxy in the running-configuration file, but you later deleted the certificates, the backup proceeds
as if the certificates still existed.
•
To perform a backup or a restore operation, you must have the admin RBAC feature in your user role.
•
When you instruct the ACE to restore the archive for the entire ACE in the Admin context, it restores
the Admin context completely first, and then it restores the other contexts. The ACE restores all
dependencies before it restores the running context. The order in which the ACE restores
dependencies is as follows:
– License files
– SSL certificates and key files
– Health-monitoring scripts
– Checkpoints
– Startup-configuration file
– Running-configuration file
•
After you restore license files, previously installed license files are uninstalled and the restored files
are installed in their place.
•
In a redundant configuration, if the archive that you want to restore is different from the peer
configurations in the FT group, redundancy may not operate properly after the restoration.
•
You can restore a single context from an ACE-wide backup archive provided that:
– You enter the restore command in the context that you want to restore
– All files dependencies for the context exist in the ACE-wide backup archive
Cisco Application Control Engine Module Administration Guide
4-24
OL-20814-01
Chapter 4
Managing the ACE Software
Using Backup and Restore
Defaults
Table 4-2 lists the default settings for the backup and restore feature parameters.
Table 4-2
Default Backup and Restore Parameters
Parameter
Default
Backed up files
By default, the ACE backs up the following files in the current context:
SSL key backup encryption
•
Running-configuration file
•
Startup-configuration file
•
Checkpoints
•
SSL certificates
•
SSL keys
•
Health-monitoring scripts
•
Licenses
None
Backing Up the ACE Configuration Files and Dependencies
This section describes the procedure that you perform to back up the ACE configuration files and
dependencies.
Restrictions
To back up all contexts, you must be in the Admin context and you must specify the all keyword.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-25
Chapter 4
Managing the ACE Software
Using Backup and Restore
Detailed Steps
Step 1
Command
Purpose
changeto
Changes to the specified context. Be sure that you are in the
context that you wish to back up. To back up all contexts in the
ACE, you must be in the Admin context.
Example:
host1/Admin# changeto C1
host1/C1#
Step 2
backup [all][pass-phrase
text_string][exclude component]
Backs up configuration files and dependencies in the current
context or in all contexts in the ACE.
Example:
host1/Admin# backup all pass-phrase
my_pass_phrase exclude checkpoints
host1/Admin#
The keywords and arguments of this command are as follows:
•
pass-phrase text_string—(Optional) Passphrase that you
specify to encrypt the backed up SSL keys. Enter the
passphrase as an unquoted text string with no spaces and a
maximum of 40 alphanumeric characters. You must enter the
pass-phrase keyword before the exclude keyword. If you
enter a passphrase and then exclude the SSL files from the
archive, the ACE does not use the passphrase.
•
exclude component—(Optional) Specifies the components
that you do not wish to back up.
You can enter any of the following components in any order
separated by a comma if you enter more than one:
– checkpoints—Excludes all checkpoints
– ssl-files—Excludes SSL certificate files and key files
•
Step 3
show backup status [detail]
Example:
host1/Admin# show backup status detail
Step 4
show backup errors
Example:
host1/Admin# show backup errors
all—(Optional) Specifies that the ACE should back up the
configuration files and dependencies in all contexts. You can
specify this keyword only in the Admin context.
(Optional) Displays the progress of the backup process for each
component in the different ACE contexts. Use the detail option
to view the components or files that have already been backed up
in each context. When the backup is finished, the command
displays the status as SUCCESS.
(Optional) If the backup fails, displays the errors that occurred
during the backup process.
Cisco Application Control Engine Module Administration Guide
4-26
OL-20814-01
Chapter 4
Managing the ACE Software
Using Backup and Restore
Restoring the ACE Configuration Files and Dependencies
This section describes the procedure that you perform to restore the ACE configuration files and
dependencies on the same or a different ACE. Be sure that the backup archive file resides in disk0: prior
to starting the restoration.
Caution
The restore command clears any existing SSL certificate and key-pair files, license files, and
checkpoints in a context before it restores the backup archive file. If your configuration includes SSL
files or checkpoints and you excluded them when you created the backup archive, those files will no
longer exist in the context after you restore the backup archive. To preserve any existing exportable SSL
certificate and key files in the context, before you enter the restore command, export the certificates and
keys that you want to keep to an FTP, SFTP, or TFTP server by using the crypto export command. After
you restore the archive, import the SSL files into the context. For details on exporting and importing SSL
certificate and key pair files, see the Cisco Application Control Engine Module SSL Configuration
Guide.
You can also use the exclude option of the restore command to instruct the ACE not to clear the SSL
files in disk0: and to ignore the SSL files in the backup archive when the ACE restores the backup.
Prerequisites
•
The backup archive must reside in disk0: in the ACE where you want to restore the archive before
you start the restoration.
•
No automatic rollback will be done in case of a restore failure. We recommend that you back up the
ACE before you attempt to restore an archive.
•
If you excluded the SSL files from the backup archive, you must import the certificates and keys
from the FTP, SFTP, or TFTP server before you restore the archive. Then, when you enter the
restore command, enter the exclude ssl-files option.
Restrictions
You must be in the Admin context to restore all contexts.
Detailed Steps for a Nonredundant Configuration
Note
This procedure will cause an interruption in service for the current context or for all contexts, depending
on the type of backup archive that you are restoring. We recommend that you schedule the restoration of
a backup archive on an ACE during a maintenance window.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-27
Chapter 4
Managing the ACE Software
Using Backup and Restore
Step 1
Command
Purpose
changeto
Changes to the specified context. Be sure that you are in the
context in which you wish to restore the backup archive. To
restore an ACE-wide backup archive completely, you must be in
the Admin context.
Example:
host1/Admin# changeto C1
host1/C1#
Step 2
restore {all | disk0:archive_filename}
[exclude ssl-files | pass-phrase
text_string]
Restores configuration files and dependencies in the current
context or in all contexts in the ACE.
The keywords and arguments of this command are as follows:
Example:
host1/Admin# restore
disk0:switch_Admin_07_July_2009_11_08_04_A
M.tgz pass-phrase MY_PASS_PHRASE
•
all—(Optional) Specifies that the ACE should restore the
configuration files and dependencies in all contexts. You can
specify this keyword only in the Admin context.
•
disk0:archive_filename—Name of the archive file that you
want to restore.
•
exclude ssl-files—Excludes SSL certificates and keys from
the restoration. Use this option only if you want to keep the
SSL files already present in your ACE and ignore the SSL
files in the backup archive, if any.
•
pass-phrase text_string—(Optional) Passphrase that you
used to encrypt the backed up SSL keys in the archive. Enter
the passphrase as an unquoted text string with no spaces and
a maximum of 40 alphanumeric characters. If you used a
passphrase when you backed up the SSL keys, the ACE
encrypted the keys with AES-256 encryption using OpenSSL
software. To restore the SSL keys, you must enter that same
passphrase.
Note
Step 3
show restore status [detail]
Example:
host1/Admin# show restore status
Step 4
show restore errors
Example:
host1/Admin# show restore errors
If you forget your passphrase, import the required
SSL files first. Then, use the exclude option of the
restore command to restore e the backup archive.
(Optional) Displays the progress of the restore process by
displaying the context. Use the detail option to view the
components or files that have already been backed up in each
context. When the restore is finished, the command displays the
status as SUCCESS.
(Optional) If the restore fails, displays the errors that occurred
during the restore process.
Cisco Application Control Engine Module Administration Guide
4-28
OL-20814-01
Chapter 4
Managing the ACE Software
Using Backup and Restore
Detailed Steps to Restore a Redundant Configuration
Note
Step 1
Step 2
This procedure will cause an interruption in service for the two redundant contexts. We recommend that
you schedule the restoration of a backup archive on a redundant pair during a maintenance window.
Command
Purpose
changeto
Example:
host1/Admin# changeto C1
host1/C1#
Changes to the specified context. Be sure that you are in the
context in which you wish to restore the backup archive. To
restore an ACE-wide backup archive completely, you must be in
the Admin context.
config
Enters configuration mode on the active member of the FT group.
Example:
host1/Admin# config
host1/Admin(config)#
Step 3
ft group group_id
no inservice
Example:
host1/Admin(config)# ft group 1
host1/Admin(config-ft-group)# no inservice
Disables redundancy for the members of the FT group. You must
take the FT group out of service before you can restore the
archive on the standby ACE. Otherwise, configuration mode is
disabled on the standby ACE and the restoration will fail with the
following error message:
Archive restore not allowed when config mode is
disabled.
Step 4
Ctrl-Z
Returns to Exec mode from any configuration mode.
Example:
host1/Admin(config-ft-group)# Ctrl-Z
host1/Admin#
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-29
Chapter 4
Managing the ACE Software
Using Backup and Restore
Step 5
Command
Purpose
restore {all | disk0:archive_filename}
[exclude ssl-files | pass-phrase
text_string]
Restores configuration files and dependencies in the current
context or in all contexts in the ACE.
The keywords and arguments of this command are as follows:
Example:
host1/Admin# restore
disk0:switch_Admin_07_July_2009_11_08_04_A
M.tgz pass-phrase MY_PASS_PHRASE
•
all—(Optional) Specifies that the ACE should restore the
configuration files and dependencies in all contexts. You can
specify this keyword only in the Admin context.
•
disk0:archive_filename—Name of the archive file that you
want to restore.
•
exclude ssl-files—Excludes SSL certificates and keys from
the restoration. Use this option only if you want to keep the
SSL files already present in your ACE and ignore the SSL
files in the backup archive if any.
•
pass-phrase text_string—(Optional) Passphrase that you
used to encrypt the backed up SSL keys in the archive. Enter
the passphrase as an unquoted text string with no spaces and
a maximum of 40 alphanumeric characters. If you used a
passphrase when you backed up the SSL keys, the ACE
encrypted the keys with AES-256 encryption using OpenSSL
software. To restore the SSL keys, you must enter that same
passphrase.
Note
Step 6
config
If you forget your passphrase, import the required
SSL files first. Then, use the exclude option of the
restore command to restore e the archive.
Enters configuration mode on the active member of the FT group.
Example:
host1/Admin# config
host1/Admin(config)#
Step 7
ft group group_id
inservice
Enables redundancy for both members of the FT group.
Example:
host1/Admin(config)# ft group 1
host1/Admin(config-ft-group)# inservice
Step 8
Ctrl-Z
Returns to Exec mode from any configuration mode.
Example:
host1/Admin(config-ft-group)# Ctrl-Z
host1/Admin#
Step 9
show restore status [detail]
Example:
host1/Admin# show restore status detail
Step 10
show restore errors
Example:
host1/Admin# show restore errors
(Optional) Displays the progress of the restoration. Use the detail
option to view the components or files that have been restored in
each context. When the restoration is finished, the command
displays the status as SUCCESS.
(Optional) If the restoration fails, displays the errors that
occurred during the restore process.
Cisco Application Control Engine Module Administration Guide
4-30
OL-20814-01
Chapter 4
Managing the ACE Software
Using Backup and Restore
Copying a Backup Archive to a Server
This section describes the procedure that you perform to copy a backup archive from the ACE to an FTP
or an SFTP server so that you can then restore the archive on a different ACE.
Restrictions
To use the copy backup command or the copy backup-all command, you must have Admin privileges
in the context where you enter the command.
Detailed Steps
Step 1
Command
Purpose
changeto
Changes to the specified context. Be sure that you are in the
context from which you wish to copy the backup archive.
Example:
host1/Admin# changeto C1
host1/C1#
Step 2
copy {backup | backup-all} {ftp:[//path] |
sftp:[//path}}
Example:
host1/Admin# config
host1/Admin(config)#
Copies a single-context or an ACE-wide backup archive to an
FTP or an SFTP server. The keywords of this command are as
follows:
•
backup—Copies the last successful single-context backup
archive to the specified FTP or SFTP server. This keyword is
available in both the Admin context and user contexts.
•
backup-all—Copies the last successful ACE-wide (all
contexts) backup archive to the specified FTP or SFTP
server. This keyword is available only in the Admin context.
•
ftp:[//path] | sftp:[//path]—Specifies the FTP or SFTP server
where you want to copy the backup archive and, optionally,
the file path or URI.
Note
If you renamed or deleted the backup archive in a context,
the copy backup command fails and the ACE displays an
error message.
Examples
The following example shows how to copy a backup archive file to an SFTP server:
switch/Admin# copy backup sftp:
Enter Address for the sftp server[]? 10.25.25.11
Enter the destination filename[]? [switch_Admin_2009_08_22_02_48_49.tgz]
Enter username[]? root
Connecting to 10.25.25.11...
root@10.25.25.11's password:
sftp> Uploading /TN-HOME/Admin/switch_Admin_2009_08_22_02_48_49.tgz to
/root/switch_Admin_2009_08_22_02_48_49.tgz
/TN-HOME/Admin/switch_Admin_2009_08_22_02_48_ 100% 6737
0.0KB/s
00:00
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-31
Chapter 4
Managing the ACE Software
Using Backup and Restore
Displaying the Status of the Backup Operation
To display the status of the backup operation, perform the following task:
Command
Purpose
show backup status [detail]
Displays the status of the last backup operation. Backup status details are
not stored across reboots.
Possible values in the Status column are as follows:
•
SUCCESS—The component was successfully backed up
•
FAILED—The component failed to be backed up
•
N/A—The component (for example, a checkpoint or probe script)
being backed up contains 0 files
Examples
The following example shows the output of the show backup status command:
hello/Admin# show backup status
Backup Archive: switch_Admin_2009_08_30_15_45_17.tgz
Type
: Context
Start Time
: Wed Aug 30 15:45:16 2009
Finished Time : Wed Aug 30 15:45:17 2009
Status
: In Progress
Current vc
: Admin
Completed
: 1/1
The following example shows the output of the show backup status detail command:
host1/Admin# show backup status detail
Backup Archive: switch_Admin_2009_08_30_15_45_17.tgz
Type
: Context
Start Time
: Wed Aug 30 15:45:16 2009
Finished Time : Wed Aug 30 15:45:17 2009
Status
: SUCCESS
Current vc
: Admin
Completed
: 1/1
------------------------+---------------+--------------------------+-----------Context
component
Time
Status
------------------------+---------------+--------------------------+-----------Admin
Admin
Admin
Admin
Admin
Admin
Running-cfg
Startup-cfg
Checkpoints
Cert/Key
License
Probe script
Wed
Wed
Wed
Wed
Wed
Wed
Aug
Aug
Aug
Aug
Aug
Aug
30
30
30
30
30
30
15:45:17
15:45:17
15:45:17
15:45:17
15:45:17
15:45:17
2009
2009
2009
2009
2009
2009
SUCCESS
SUCCESS
SUCCESS
N/A
SUCCESS
N/A
Cisco Application Control Engine Module Administration Guide
4-32
OL-20814-01
Chapter 4
Managing the ACE Software
Using Backup and Restore
Displaying the Status of the Restoration
To display the status of the restoration, perform the following task:
Command
Purpose
show restore status [detail]
Displays the status of the last restoration. Restoration status details are not
stored across reboots.
Examples
The following example shows the output of the show restore status command:
host1/Admin# show restore status
Backup Archive: switch_2009_08_30_15_45_17.tgz
Type
: Context
Start Time
: Wed Aug 30 16:45:16 2009
Finished Time : Status
: In Progress
Current vc
: Admin
Completed
: 0/1
The following example shows the output of the show restore status detail command:
host1/Admin# show restore status detail
Backup Archive: switch_2009_08_30_15_45_17.tgz
Type
: Context
Start Time
: Wed Aug 30 16:45:16 2009
Finished Time : Status
: In Progress
Current vc
: Admin
Completed
: 0/1
------------------------+---------------+--------------------------+-----------Context
component
Time
Status
------------------------+---------------+--------------------------+-----------Admin
License
Wed Aug 30 16:45:16 2009
SUCCESS
Admin
Cert/Key
Wed Aug 30 16:45:16 2009
SUCCESS
Admin
Probe script
Wed Aug 30 16:45:16 2009
SUCCESS
Admin
Checkpoints
Wed Aug 30 16:45:16 2009
SUCCESS
Admin
Startup-cfg
Wed Aug 30 16:45:17 2009
In Progress
Displaying Backup and Restore Errors
To display the errors that may have occurred during a backup or restore operation that did not succeed,
perform the following tasks:
Command
Purpose
show backup errors
Displays errors that occur during a backup operation. For information
about backup system messages, see the Cisco Application Control Engine
Module System Message Guide.
show restore errors
Displays errors that occur during a restore operation. For information
about restore system messages, see the Cisco Application Control Engine
Module System Message Guide.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-33
Chapter 4
Managing the ACE Software
Using Backup and Restore
Examples
The following example shows the output of the show backup errors command after a backup failed
because of a disk copy failure for checkpoints:
host1/Admin# show backup errors
Context: Admin
Component: Checkpoint
Error Details:
Internal Error, checkpoint copy failed
The following example shows the output of the show restore errors command after a restore failed
because the running-configuration file differences could not be applied:
host1/Admin# show restore errors
Context: Admin
Component: Running-cfg
Error Details:
Error, running config apply failed
-`cert RSA1024.cert`
Internal Error, invalid cert file name
-`key rsakey.pem`
Internal Error, invalid key file name
-`cert servercert.crt`
Internal Error, invalid cert file name
The following example shows the output of the show restore errors command after a restore failed
because a probe was not present in either disk0: or in the probe: directory.
host1/Admin# show backup errors
Context: Admin
Component: Probe scripts
Error Details:
Error, probe PROBE_1 not found in disk0: or probe:
Cisco Application Control Engine Module Administration Guide
4-34
OL-20814-01
Chapter 4
Managing the ACE Software
Managing Core Dump Files
Managing Core Dump Files
This section describes how to manage the ACE core dump files. A core dump occurs when the ACE
experiences a fatal error. The ACE writes information about the fatal error to the core: file system in
Flash memory before a switchover or reboot occurs. The core: file system is the storage location for all
core files generated during a fatal error. Three minutes after the ACE reboots, the saved last core file is
restored from the core: file system back to its original RAM location. This restoration is a background
process and is not visible to the user.
This section contains the following topics:
•
Guidelines and Limitations
•
Copying Core Dumps
•
Clearing the Core Directory
•
Deleting a Core Dump File
Guidelines and Limitations
This topic includes the following restrictions:
•
The core: file system is available from the Admin context only.
•
Core dump information is for Cisco Technical Assistance Center (TAC) use only. If the ACE
becomes unresponsive, you can view the dump information in the core through the show cores
command. We recommend that you contact TAC for assistance in interpreting the information in the
core dump.
•
The time stamp on the restored last core file displays the time when the ACE booted up, not when
the last core was actually dumped. To obtain the exact time of the last core dump, check the
corresponding log file with the same process identifier (PID).
Copying Core Dumps
This section describes how to copy a core dump from the ACE to the disk0: file system or to a remote
server. The ACE copies a single file based on the provided process identifier.
Restrictions
You must perform this task from the Admin context only.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-35
Chapter 4
Managing the ACE Software
Managing Core Dump Files
Detailed Steps
Step 1
Command
Purpose
dir core:
(Optional) Displays the list of available core files. You can copy
the complete filename (for example,
0x401_vsh_log.25256.tar.gz) into the copy core: command.
Example:
host1/Admin# dir core:
Step 2
copy core:filename
{disk0:[path/][filename] |
ftp://server/path[/filename] |
sftp://[username@]server/path[/filename]
| tftp://server[:port]/path[/filename]}
Example:
host1/Admin# copy
core:0x401_vsh_log.8249.tar.gz
ftp://192.168.1.2
Enter the destination filename[]?
[0x401_vsh_log.8249.tar.gz]
Enter username[]? user1
Enter the file transfer mode[bin/ascii]:
[bin]
Password:
Passive mode on.
Hash mark printing on (1024 bytes/hash
mark).
Saves a core dump from the ACE to the disk0: file system or to a
remote server.
The keywords, arguments, and options are as follows:
•
filename—Core dump that resides on the ACE in Flash
memory.
•
disk0:[path/][filename]—Specifies a file location for the
core dump in the disk0: file system and a filename for the
core.
•
ftp://server/path[/filename]—Specifies the FTP network
server and, optionally, the renamed core dump.
When using FTP, the bin (binary) file transfer mode is
intended for transferring compiled files (executables). The
ascii file transfer mode is intended for transferring text files,
such as config files. The default selection of bin mode should
be sufficient in all cases when copying files to a remote FTP
server.
•
sftp://[username@]server/path[/filename]—Specifies the
SFTP network server and, optionally, the renamed core
dump.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP
network server and, optionally, the renamed core dump.
When you select a destination file system using ftp:, sftp:, or
tftp:, the ACE performs the following tasks:
•
Prompts you for your username and password if the
destination file system requires user authentication.
•
Prompts you for the server information if you do not provide
the information with the command.
•
Copies the file to the root directory of the destination file
system if you do not provide path information.
Clearing the Core Directory
This section describes how to clear out all of the core dumps stored in the core: file system.
Restrictions
You must perform this task from the Admin context only.
Cisco Application Control Engine Module Administration Guide
4-36
OL-20814-01
Chapter 4
Managing the ACE Software
Capturing Packet Information
Detailed Steps
Step 1
Command
Purpose
dir core:
(Optional) Displays the list of available core files.
Example:
host1/Admin# dir core:
Step 2
clear cores
Clears out all of the core dumps stored in the core: file system.
Example:
host1/Admin# clear cores
Deleting a Core Dump File
This section describes how to delete a core dump file from the core: file system in Flash memory.
Restrictions
You must perform this task from the Admin context only.
Detailed Steps
Step 1
Command
Purpose
dir core:
(Optional) Displays the list of available core files. You can copy
the complete filename (for example,
0x401_vsh_log.25256.tar.gz) into the delete core: command.
Example:
host1/Admin# dir core:
Step 2
delete core:filename
Example:
host1/Admin# delete
core:0x401_VSH_LOG.25256.TAR.GZ
Deletes a core dump file from the core: file system in Flash
memory.
The filename argument specifies the name of a core dump file
located in the core: file system.
Capturing Packet Information
This section describes how to capture packet information, which is useful for troubleshooting
connectivity problems with the ACE or for monitoring suspicious activity. The ACE can track packet
information for network traffic that passes through the ACE. The attributes of the packet are defined by
an ACL. The ACE buffers the captured packets, and you can copy the buffered contents to a file in Flash
memory on the ACE or to a remote server. You can also display the captured packet information on your
console or terminal.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-37
Chapter 4
Managing the ACE Software
Capturing Packet Information
Caution
The packet capture function uses ACL resources as can be seen with the show np 1 access-list resource
command. If you have a large ACL configuration and you enable packet capturing, the ACE may
oversubscribe the allocated ACL resources. If this happens, you may see one of the following error
messages:
In exec mode,
Error: Device Name:[0x3FF] Instance:[63] Error Type:[(null)] code:[255]
In config mode,
Error: ACL merge add acl to list failed
For information about using the show np 1 access-list resource command to monitor ACL resources
and how to resolve ACL oversubscription problems, see the “Troubleshooting ACLs” section of the ACE
Module Troubleshooting Wiki.
This section contains the following topics:
•
Enabling the Packet Capture Function
•
Copying Packet Capture Buffer Information
•
Displaying or Clearing Packet Information
•
Clearing Capture Buffer Information
Enabling the Packet Capture Function
This section describes how to enable the packet capture function on the ACE for packet sniffing and
network fault isolation. As part of the packet capture process, you specify whether to capture packets
from all input interfaces or an individual VLAN interface. The packet capture feature streams output on
the console as packets are received by the ACE.
Prerequisites
To create a capture based on an access list, the access list must already exist. For information about
creating an access list, see the Cisco Application Control Engine Module Security Configuration Guide.
Restrictions
This topic includes the following restrictions:
•
The packet capture function enables access-control lists (ACLs) to control which packets are
captured by the ACE on the input interface. If the ACLs are selecting an excessive amount of traffic
for the packet capture operation, the ACE will see a heavy load, which can cause a degradation in
performance. We recommend that you avoid using the packet capture function when high network
performance is critical.
In addition, probe traffic will not hit a security ACL so ACLs cannot control the capture of those
packets. In this case, probe traffic cannot be captured by the packet capture function.
Cisco Application Control Engine Module Administration Guide
4-38
OL-20814-01
Chapter 4
Managing the ACE Software
Capturing Packet Information
•
The capture packet function works on an individual context basis. The ACE traces only the packets
that belong to the current context where you execute the capture Exec mode command. The context
ID, which is passed along with the packet, can be used to isolate packets that belong to a specific
context. To trace the packets for a specific context, use the changeto Exec mode command to enter
the specified context and then use the capture command.
•
If you enable packet capture for jumbo packets, the ACE captures only the first 1,860 bytes of data.
•
The ACE does not automatically save the packet capture to a file. To copy the capture buffer
information as a file in Flash memory or to a remote server, use the copy capture command (see the
“Copying Packet Capture Buffer Information” section).
•
When capturing packets based on a specific interface and you delete the interface, the ACE stops
the capture automatically. If you check the status of the packet capture using the show capture
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.
•
When capturing packets based on a specific access list name, ensure that the access list is for an
input interface. If you configure the packet capture on the output interface, the ACE will fail to
match any packets.
•
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.
•
If the ACE stops a packet capture because of an interface or ACL deletion, the following additional
information appears in the output of the show capture buffer_name status command:
Capture forced to stop due to change in [interface | access-list] config.
To restart the capture, remove and add the capture again.
•
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.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-39
Chapter 4
Managing the ACE Software
Capturing Packet Information
Detailed Steps
Command
Purpose
capture buffer_name {{all |
{interface vlan number}}
access-list name [bufsize buf_size
[circular-buffer]]} | remove |
start | stop
Enables the packet capture function on the ACE for packet sniffing and network
fault isolation.
The keywords, arguments, and options are as follows:
•
Example:
host1/Admin# capture capture1
interface vlan50 access-list acl1
host1/Admin# capture capture1 start
buffer_name—Name of the packet capture buffer. This argument associates the
packet capture with a name. Specify a text string from 1 to 80 alphanumeric
characters.
•
all—Specifies capture packets for all input interfaces.
host1/Admin# capture capture1 stop
•
interface—Specifies the interface from which to capture packets.
•
vlan number—Specifies the VLAN identifier associated with the specified
input interface.
•
access-list name—Selects packets based on an existing access list. A packet
must pass the access list filters before the packet is stored in the capture buffer.
Specify a previously created access list identifier. Enter an unquoted text string
with a maximum of 64 alphanumeric characters.
•
bufsize buf_size—(Optional) Specifies the buffer size, in kilobytes (KB), to
store the packet capture. The range is from 1 to 5000 KB. The default is 64 KB.
•
circular-buffer—(Optional) Enables the packet capture buffer to overwrite
itself, starting from the beginning, when the buffer is full.
•
remove—Removes the packet capture configuration.
•
start—Starts the packet capture function and displays the messages on the
session console as the ACE 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.
•
stop—Stops the packet capture process after a brief delay.
Copying Packet Capture Buffer Information
This section describes how to copy an existing packet capture buffer to the disk0: file system.
Cisco Application Control Engine Module Administration Guide
4-40
OL-20814-01
Chapter 4
Managing the ACE Software
Capturing Packet Information
Detailed Steps
Command
Purpose
copy capture capture_name disk0:
[path/]destination_name
Copies an existing packet capture buffer to the disk0: file system
The keywords, arguments, and options are as follows:
Example:
host1/Admin# copy capture
packet_capture_Jan_17_06 disk0: mycapture1
•
capture_name—Name of the packet capture buffer in Flash memory.
Specify a text string from 1 to 80 alphanumeric characters. If
necessary, use the show capture command to view the files available
in Flash memory. This list includes the name of existing packet
capture buffers.
•
disk0:—Specifies that the buffer is copied to the disk0: file system.
Include a space between disk0: and a destination path.
•
[path/]destination_name—Destination path (optional) and name for
the packet capture buffer. Specify a text string from 1 to 80
alphanumeric characters. If you do not provide the optional path, the
ACE copies the file to the root directory on the disk0: file system.
Displaying or Clearing Packet Information
This section describes how to display or clear packet information and contains the following topics:
•
Displaying Packet Information
•
Clearing Capture Buffer Information
Displaying Packet Information
To display packet information, perform the following task:
Command
Purpose
show capture buffer_name [detail [connid
Displays the packet information that the ACE traces as part of the packet
connection_id | range packet_start packet_end] | capture function.
status]
The keywords, arguments, and options are as follows:
•
buffer_name—Name of the packet capture buffer. Specify a text string
from 1 to 80 alphanumeric characters.
•
detail—(Optional) Displays additional protocol information for each
packet.
•
connid connection_id—(Optional) Displays protocol information for
a specified connection identifier.
•
range packet_start packet_end—(Optional) Displays protocol
information for a range of captured packets.
•
status—(Optional) Displays capture status information for each
packet.
For all types of received packets, the console display is in tcpdump format.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-41
Chapter 4
Managing the ACE Software
Using the Configuration Checkpoint and Rollback Service
Clearing Capture Buffer Information
To clear the packet capture buffer, perform the following task:
Command
Purpose
clear capture buffer_name
Clears the capture packet buffer.
The buffer_name argument specifies the name of the existing packet
capture buffer to clear.
Using the Configuration Checkpoint and Rollback Service
This section describes how to make a checkpoint (or snapshot) of a running configuration on your ACE
and how to use the rollback service to revert to the last known stable configuration.
At some point, you may want to modify your running configuration. If you run into a problem with the
modified configuration, you may need to reboot your ACE. To prevent having to reboot your ACE after
unsuccessfully modifying a running configuration, you can create a checkpoint (a snapshot in time) of a
known stable running configuration before you begin to modify it. If you encounter a problem with the
modifications to the running configuration, you can roll back the configuration to the previous stable
configuration checkpoint.
The ACE allows you to make a checkpoint configuration at the context level. The ACE stores the
checkpoint for each context in a hidden directory in Flash memory. If after you enter additional
commands to modify the current running configuration, you enter the rollback command option, the
ACE causes the running configuration to revert to the checkpointed configuration.
This section contains the following topics:
•
Creating a Configuration Checkpoint
•
Deleting a Configuration Checkpoint
•
Rolling Back a Running Configuration
Creating a Configuration Checkpoint
This section describes how to create a configuration checkpoint.
Prerequisites
Be sure that the current running configuration is stable and is the configuration that you want to make a
checkpoint.
Restrictions
This topic includes the following restrictions:
•
The ACE supports a maximum of 10 checkpoints for each context.
•
You must perform this task in the Exec mode of the context for which you want to create a
checkpoint.
Cisco Application Control Engine Module Administration Guide
4-42
OL-20814-01
Chapter 4
Managing the ACE Software
Using the Configuration Checkpoint and Rollback Service
Detailed Steps
Command
Purpose
checkpoint create name
Creates a configuration checkpoint.
Example:
host1/Admin# checkpoint create
MYCHECKPOINT
Generating configuration....
Created checkpoint 'MYCHECKPOINT'
The name argument specifies the unique identifier of the checkpoint. Enter
a text string with no spaces and a maximum of 25 alphanumeric characters.
If the checkpoint already exists, the CLI responds with the following
prompt:
Checkpoint already exists
Do you want to overwrite it? (y/n)
configuration....
Created checkpoint 'MYCHECKPOINT'
[n] y Generating
The default is n. If you do not want to overwrite the existing checkpoint,
press Enter. To overwrite the existing checkpoint, enter y.
Deleting a Configuration Checkpoint
This section describes how to delete a configuration checkpoint.
Prerequisites
Before you use this command, make sure that you want to delete the checkpoint. When you enter this
command, the ACE removes the checkpoint from Flash memory.
Detailed Steps
Command
Purpose
Step 1
show checkpoint all
(Optional) Displays a list of all existing checkpoints.
Step 2
checkpoint delete name
Deletes a configuration checkpoint.
Example:
host1/Admin# checkpoint delete
MYCHECKPOINT
The name argument specifies the unique identifier of the
checkpoint. Enter a text string with no spaces and a maximum of
25 alphanumeric characters.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-43
Chapter 4
Managing the ACE Software
Using the Configuration Checkpoint and Rollback Service
Rolling Back a Running Configuration
This section describes how to roll back the current running configuration to the previously checkpointed
running configuration for the current context.
Detailed Steps
Step 1
Command
Purpose
show checkpoint all
(Optional) Displays a list of all existing checkpoints.
Example:
host1/Admin# show checkpoint all
Step 2
show checkpoint detail name
Example:
host1/Admin# show checkpoint MYCHECKPOINT5
Step 3
checkpoint rollback name
Example:
host1/Admin# checkpoint delete
MYCHECKPOINT5
This operation will rollback the system's
running configuration to the checkpoint's
configuration.
Do you wish to proceed? (y/n) [n] y
Rollback in progress, please wait...
Generating configuration....
Rollback succeeded
host1/Admin#
(Optional) Displays the running configuration of the specified
checkpoint.
Rolls back the current running configuration to the previously
checkpointed running configuration for the current context.
The name argument specifies the unique identifier of the
checkpoint. Enter a text string with no spaces and a maximum of
25 alphanumeric characters.
Displaying Checkpoint Information
To display checkpoint information, perform the following task:
Command
Purpose
show checkpoint {all | detail name} [|] [>]
Displays information relating to the configured checkpoints.
•
all—Displays a list of all existing checkpoints. The show output
includes checkpoint time stamps.
•
detail name—Displays the running configuration of the specified
checkpoint.
Table 4-3 describes the fields that appear in the show checkpoint all command output.
Table 4-3
Field Descriptions for the show checkpoint all Command Output
Field
Description
Checkpoint
Name of the checkpoint
Cisco Application Control Engine Module Administration Guide
4-44
OL-20814-01
Chapter 4
Managing the ACE Software
Reformatting the Flash Memory
Table 4-3
Field Descriptions for the show checkpoint all Command Output (continued)
Field
Description
Size
Size (in bytes) of the checkpoint
Date
Date and time at which the checkpoint was created
Reformatting the Flash Memory
The ACE uses the file allocation table (FAT16) as the base file system. The file system is used to allocate
and organize storage space for various types of storage, such as startup-configuration files, SSL
certificate storage, core files, image storage, and log files. Reformatting Flash memory on the ACE
allows you to erase all data on the Flash memory and reformat it with the FAT16 version of the file
allocation table. All user-defined configuration information is erased.
Caution
We recommend that you reformat the ACE Flash memory only under the guidance and supervision of
Cisco Technical Assistance Center (TAC).
Prerequisites
Before you reformat the Flash memory, we recommend that you copy the following ACE operation and
configuration files or objects to a remote server:
•
ACE software image
•
ACE license
•
Startup-configuration file of each context
•
Running-configuration file of each context
•
Core dump files of each context
•
Packet capture buffers of each context
•
SSL certificate and key pair files of each context
See the “Copying Files” section for details on how to use the copy command to save configuration files
or objects, such as the existing startup-configuration files, running-configuration file, licenses, core
dump files, or packet capture buffers, to a remote FTP, SFTP, or TFTP server.
See the Cisco Application Control Engine Module SSL Configuration Guide for details on how to use
the crypto export command to export SSL certificate and key pair files to a remote FTP, SFTP, or TFTP
server.
Detailed Steps
Command
Purpose
format disk0:
Reformats Flash memory on the ACE and erases
all data.
Example:
host1/Admin# format disk0:
Warning!! This will reboot the system after formatting disk0.
Do you wish to proceed anyway? (y/n) [n] y
Cisco Application Control Engine Module Administration Guide
OL-20814-01
4-45
Chapter 4
Managing the ACE Software
Reformatting the Flash Memory
What to Do Next
After you reformat the Flash memory, perform the following actions:
•
Reinstall the ACE software image by using the copy image: command (see Appendix A, Upgrading
or Downgrading Your ACE Software).
•
Reinstall the ACE license by using the license install command (see Chapter 3, Managing ACE
Software Licenses).
•
Import the startup and running-configuration files into the associated context by using the copy
command (see the “Copying Configuration Files from a Remote Server” section).
•
Import SSL certificate files and key pair files into the associated context using by the crypto import
command (see the Cisco Application Control Engine Module SSL Configuration Guide).
Cisco Application Control Engine Module Administration Guide
4-46
OL-20814-01
CH A P T E R
5
Displaying ACE Hardware and Software System
Information
This chapter describes how to display ACE hardware and software system information.
This chapter does not include information for displaying the running- or startup-configuration files. To
display the contents of these files, see Chapter 4, Managing the ACE Software.
This chapter contains the following major sections:
•
Information About Displaying ACE Hardware and Software Information
•
Displaying Hardware Information
•
Displaying Installed Software Information
•
Displaying System Processes and Memory Resources Limits
•
Displaying System Information
•
Displaying or Clearing ICMP Statistics
•
Displaying or Collecting Technical Information for Reporting Problems
Information About Displaying ACE Hardware and Software
Information
The ACE CLI provides a comprehensive set of show commands in Exec mode that you can use to gather
the following system information:
•
Installed hardware and software information
•
System processes
•
System information
•
Technical support
The show buffer, show cde, show fifo, show hyp, show lcp, show netio, show np, show scp, and show
vnet commands display internal system-level hardware show output for use by trained Cisco personnel
as an aid in debugging and troubleshooting the ACE. For background information about these show
commands, see the Cisco Application Control Engine Module Command Reference.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-1
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying Hardware Information
Displaying Hardware Information
To display ACE hardware information, perform one of the following tasks:
Command
Purpose
show hardware
Displays the ACE hardware inventory details.
show inventory [raw]
Displays the system hardware inventory of the ACE. This command displays information about
the field replaceable units (FRUs) in the ACE, including product identifiers, serial numbers,
and version identifiers.
The optional raw keyword displays information about each temperature sensor in the ACE.
Table 5-1 describes the fields in the show hardware command output.
Table 5-1
Field Descriptions for the show hardware Command
Field
Description
Product Number
Product number of the ACE
Serial Number
Serial number of the ACE
Card Index
Location of the ACE, specified as an index value
Hardware Rev
Hardware revision of the ACE
Feature Bits
Enabled feature bits of the ACE hardware
Slot No.
Slot number in the switch or router chassis where the ACE is installed
Type
Identifies the module type installed in the switch or router chassis as an ACE module
Module Mode
Supported internetworking speeds in Gigabits per second (Gbps)
Table 5-2 describes the fields in the show inventory command output.
Table 5-2
Field Descriptions for the show inventory Command
Field
Description
Name
Name assigned to the ACE in the switch or router chassis.
Note
Descr
Description of the ACE installed in the switch or router chassis.
Note
If you specify the raw keyword, The Descr field also displays information about each
temperature sensor in the ACE.
PID
Product identifier of the ACE.
VID
Version identifier of the ACE.
SN
Serial number of the ACE.
Table 5-3 describes the fields in the show inventory raw command output.
Cisco Application Control Engine Module Administration Guide
5-2
OL-20814-01
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying Installed Software Information
Table 5-3
Field Descriptions for the show inventory raw Command
Field
Description
Name
Name assigned to the temperature sensor in the ACE
Descr
Description of the of temperature sensor
PID
Not applicable
VID
Not applicable
SN
Not applicable
Displaying Installed Software Information
To display the installed software copyright or version information for the ACE, perform one of the
following tasks:
Command
Purpose
show copyright
Displays the software copyright information for the ACE.
show version
Displays the version of system software that is currently running on the ACE in
Flash memory.
You use the show version command to verify the software version on the ACE
before and after an upgrade.
Examples
The following example shows the output for the show copyright command:
host1/Admin# show copyright
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2006, 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.
The following example shows the output for the show version command:
host1/Admin# show version
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2009, 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.
Software
loader:
Version
system:
Version
system image file:
licensed features:
12.2[121]
A2<3.0> [build 3.0(0)A2(2.99.80)]
[LCP] disk0:c6ace-t1k9-mzg.A2_2_99_80.bin
no feature license is installed
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-3
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Processes and Memory Resources Limits
Hardware
Cisco ACE (slot: 3)
cpu info:
number of cpu(s): 2
cpu type: SiByte
cpu: 0, model: SiByte SB1 V0.2, speed: 700 MHz
cpu: 1, model: SiByte SB1 V0.2, speed: 700 MHz
memory info:
total: 957816 kB, free: 374588 kB
shared: 0 kB, buffers: 2572 kB, cached 0 kB
cf info:
filesystem: /dev/cf
total: 500040 kB, used: 449976 kB, available: 50064 kB
last boot reason: reload command by admin
configuration register: 0x1
host kernel uptime is 1 days 10 hours 59 minute(s) 10 second(s)
Displaying System Processes and Memory Resources Limits
This section describes how display system processes and memory resource limits and contains the
following topics:
•
Displaying General System Process Information
•
Displaying Detailed Process Status Information and Memory Resource Limits
Displaying General System Process Information
To display general information about all of the processes running on the ACE, perform the following
task:
Command
Purpose
show processes [cpu | log [details | pid
process_id] | memory]
Displays general information about all of the processes running on the ACE.
This command is available only to users with an Admin role across all
contexts. The displayed system processes information is at the CPU system
level (the total CPU usage) and is not on a per-context level.
The show processes command with no options displays summary CPU
information for the SiByte 1250 Processor.
The keywords, arguments, and options are:
•
cpu—Displays CPU information for the SiByte 1250 Processor, the
BCM1250 dual core MIPS processor
•
log—Displays information about process logs
•
details—Displays process log information for all process identifiers
•
pid process_id—Displays information about a specific process
identifier
•
memory—Displays memory information about the processes
Cisco Application Control Engine Module Administration Guide
5-4
OL-20814-01
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Processes and Memory Resources Limits
Table 5-4 describes the fields in the show processes command output for the summary CPU information.
Table 5-4
Field Descriptions for the show processes Command
Field
Description
PID
Process identifier.
State
Process state. Included below is a summary of the different process state codes that can appear to
describe the state of a process:
•
D—Uninterruptible sleep (usually I/O related)
•
ER—Error while running
•
NR—Not running
•
R—Running or runnable (on run queue)
•
S—Interruptible sleep (waiting for an event to complete)
•
T—Stopped, either by a job control signal or because it is being traced
•
W—Paging
•
X—Process is dead
•
Z—Defunct (“zombie”) process, terminated but not reaped by its parent
PC
Current program counter in hexadecimal format.
Start_cnt
Number of times a process has been started.
TTY
Terminal that controls the process. A “—” usually means a daemon is not running on any particular
tty.
Process
Name of the process.
Table 5-5 describes the fields in the show processes cpu command output.
Table 5-5
Field Descriptions for the show processes cpu Command
Field
Description
CPU Utilization
Lists the percentage of CPU utilization for the ACE for a 5-second interval, 1-minute interval,
and a 5-minute interval
PID
Process identifier
Runtime (ms)
CPU time the process has used, expressed in milliseconds
Invoked
Number of times that the process has been invoked
uSecs
Microseconds of CPU time as an average for each process invocation
1 Sec
CPU utilization as a percentage for the last second
5 Sec
CPU utilization as a percentage for the last 5 seconds
1 Min
CPU utilization as a percentage for the last minute
5 Min
CPU utilization as a percentage for the last 5 minutes
Process
Name of the process
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-5
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Processes and Memory Resources Limits
Table 5-6 describes the fields in the show processes log command output.
Table 5-6
Field Descriptions for the show processes log Command
Field
Description
Process
Name of the process
PID
Process identifier
Normal-exit
Status of whether the process exited normally
Stack
Status of whether a stack trace is in the log
Core
Status of whether a core file exists
Log-create-time
Time when the log file was generated
Table 5-7 describes the fields in the show processes log details | pid command output.
Field Descriptions for the show processes log | pid details Command
Table 5-7
Field
Description
Service
Name of the service.
Description
Brief description of the service.
Started at
Time the process started.
Stopped at
Time the process stopped.
Uptime
Length of time that the process was active.
Start type
System manager option that indicates the process restartability characteristics (that is, whether
it is a stateless restart or stateful restart).
Death reason
Reason that the system manager killed the process (for example, no sysmgr heartbeats).
Exit code
Exit code with which the process exited.
Note
Normally, the Exit code provides the signal number which killed the process.
CWD
Current working directory.
Virtual memory
Virtual memory addresses where the code, data heap, and stack of the process are located.
PID
Process identifier.
SAP
Service access point.
UUID
Universal unique identifier of the CPU.
Table 5-8 describes the fields in the show processes memory command output.
Table 5-8
Field Descriptions for the show processes memory Command
Field
Description
PID
Process identifier
MemAlloc
Total memory allocated by the process
StackBase/Ptr
Process stack base and current stack pointer in hex format
Process
Name of the process
Cisco Application Control Engine Module Administration Guide
5-6
OL-20814-01
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Processes and Memory Resources Limits
Examples
The following example shows the output for the show processes mem command:
host1/Admin# show processes mem
PID
MemAlloc StackBase/Ptr
----- -------- ----------------1
14592 7fff7f40/7fff77d0
2
0
0/0
3
0
0/0
4
0
0/0
5
0
0/0
6
0
0/0
.
.
Process
---------------init
keventd
ksoftirqd_CPU0
ksoftirqd_CPU1
kswapd
bdflush
Displaying Detailed Process Status Information and Memory Resource Limits
To display detailed process status information and memory resource limits, perform the following task:
Command
Purpose
show terminal internal info
Displays detailed process status information and memory resource limits.
Table 5-9 describes the fields in the show terminal internal info command output.
Table 5-9
Field Descriptions for the show terminal internal info Command
Field
Description
Process Information
Name
Name of the executable that started the process.
State
Process state. Included below is a summary of the different process state codes that can appear
to describe the state of a process:
•
D—Uninterruptible sleep (usually I/O related)
•
ER—Error while running
•
NR—Not running
•
R—Running or runnable (on run queue)
•
S—Interruptible sleep (waiting for an event to complete)
•
T—Stopped, either by a job control signal or because it is being traced
•
W—Paging
•
X—Process is dead
•
Z—Defunct (“zombie”) process, terminated but not reaped by its parent
TGID
Terminal group identifier.
PID
Process identifier.
PPID
Parent process identification number.
TracerPID
Tracer process identification number.
UID
Identifier of the user that started the process (four element list).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-7
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Processes and Memory Resources Limits
Table 5-9
Field Descriptions for the show terminal internal info Command (continued)
Field
Description
GID
Identifier of the group that the process belongs to (four element list).
FDSize
Process file descriptor size.
Groups
Total number of groups.
VmSize
Total amount of virtual memory used by the process (in KB).
VmLck
Total locked virtual memory (in KB).
VmRSS
Total amount of physical memory used by the process (in KB).
VmData
Virtual memory data size (in KB).
VmStk
Virtual memory stack size (in KB).
VmExe
Executable virtual memory (in KB).
VmLib
Virtual memory library size (in KB).
SigPnd
Signals pending.
SigBlk
Signals blocked.
SigIgn
Signals ignored.
SigCat
Signals caught.
CapInh
Capability inherited privilege.
CapPrm
Capability privilege (processor resource manager).
CapEff
Capability effective privilege.
Memory Limits
Core file size
Maximum size of core file (in blocks) that may be created.
Data seg size
Maximum size (in KB) of the data segment for a process.
File size
Maximum size (in blocks) of files created by the shell.
Max locked memory
Maximum size (in KB) which a process may lock into memory.
Max memory size
Maximum size (in KB) to which a process resident set size may grow.
Note
This restriction imposes a limit on the amount of physical memory to be given to a
process.
Open files
Maximum number of open files for this process.
Pipe size
Pipe buffer size (in bytes).
Stack size
Maximum size (in KB) of the stack segment for a process.
CPU time
Maximum amount of CPU time (in seconds) to be used by each process.
Max user processes
Maximum number of simultaneous processes for the user identifier.
Virtual memory
Maximum amount (in KB) of available virtual memory available to the process.
Cisco Application Control Engine Module Administration Guide
5-8
OL-20814-01
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Information
Displaying System Information
To display the system information for the ACE, perform the following task:
Command
Purpose
show system {cpuhog | error-id {hex_id | list} | Displays the system information.
internal | kmem | kmemtrack | resources |
The keywords and argument are as follows:
skbtrack | uptime}
• cpuhog—Displays information related to the process watchdog timer
that monitors CPU usage by any currently active processes.
•
error-id—Displays description about errors.
•
hex_id—Error ID in hexadecimal format. The range is from 0x0 to
0xffffffff.
•
list—Specifies all error IDs.
•
internal—Specifies a series of internal system-level commands for
use by trained Cisco personnel only.
•
kmem—Displays the Linux kernel memory usage.
•
kmemtrack—Displays the kernal memory allocations in the kernel
loadable modules.
•
resources—Displays system-related CPU and memory statistics.
•
skbtrack—Displays the socket buffer (network buffer) allocations in
the kernel loadable modules.
•
uptime—Displays how long the ACE has been up and running.
Table 5-10 describes the fields in the show system kmem command output.
Table 5-10
Field
Field Descriptions for the show system kmem Command
Description
Mem
Total
Total usable Linux kernel RAM (physical RAM minus the reserved bits and the kernel binary code)
Used
Total Linux kernel RAM in use.
Free
Available Linux kernel RAM.
Shared
Always zero.
Buffers
Memory in buffer cache.
Cached
RAM used for the page cache (disk cache) minus the RAM used for the swap cache.
Swap
Total
Total amount of physical swap memory.
Used
Total swap memory in use.
Free
Available swap memory.
MemTotal
Total usable Linux kernel RAM (physical RAM minus the reserved bits and the kernel binary code).
MemFree
Available Linux kernel RAM.
MemShared
Always zero.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-9
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying System Information
Table 5-10
Field Descriptions for the show system kmem Command (continued)
Field
Description
Buffers
Memory in buffer cache.
Cached
RAM used for the page cache (disk cache) minus the RAM used for the swap cache.
SwapCached
Memory that once was swapped out, is swapped back in, but is still in the swap file. If this memory
is needed, it does not need to be swapped out again because it is already in the swap file. This saves
I/O.
Active
Memory that has been used recently and usually not reclaimed unless it is absolutely necessary.
Inactive
Memory that is unused or easily freeable.
HighTotal
Total amount of memory in the high memory (highmem) region. Highmem is all memory above
approximately 860 MB of physical RAM. The kernel uses indirect methods to access the high
memory region. Data cache can go in this memory region.
HighFree
Total amount of available memory in the highmem area.
LowTotal
Amount of memory in the low memory region (non-highmem memory).
LowFree
Amount of free memory in the low memory region. The kernel can address low memory directly. All
kernel data structures need to go into low memory.
SwapTotal
Total amount of physical swap memory.
SwapFree
Available swap memory.
Committed_AS
An estimate of how much RAM you would need to make a 99.99% guarantee that there never is an
out-of-memory (OOM) condition for a particular workload. Normally, the kernel overcommits
memory. For example, if you dynamically allocate 1 GB of memory, no demand is placed on that
memory until you actually start using it. The Committed_AS is an estimate of how much RAM or
swap memory you would need in a worst-case scenario.
Table 5-11 describes the fields in the show system resources command output.
Table 5-11
Field Descriptions for the show system resources Command
Field
Description
Load average
Load that is defined as the number of running processes. The average reflects the system load over
the past 1-minute, 5-minute, and 15-minute interval.
Processes
Number of processes in the system, and how many processes are actually running when you enter
the command.
CPU states
CPU usage percentage in user mode, kernel mode, and idle time in the last second.
Memory usage
Total memory, used memory, free memory, memory used for buffers, and memory used for cache
in KB. Buffers and cache are also included in the used memory statistics.
Table 5-12 describes the fields in the show system uptime command output.
Table 5-12
Field Descriptions for the show system uptime Command
Field
Description
System start time
Date and time when the ACE was turned on
Cisco Application Control Engine Module Administration Guide
5-10
OL-20814-01
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying or Clearing ICMP Statistics
Table 5-12
Field Descriptions for the show system uptime Command (continued)
Field
Description
System uptime
Length of time that the ACE hardware and software have been running
Kernel uptime
Length of time that the operating system (OS) has been running
Displaying or Clearing ICMP Statistics
To display or clear the Internet Control Message Protocol (ICMP) statistics, perform one of the following
tasks:
Command
Purpose
show icmp statistics
Displays Internet Control Message Protocol (ICMP) statistics.
clear icmp statistics
Clears the Internet Control Message Protocol (ICMP) statistics.
Table 5-13 describes the fields in the show icmp statistics command output.
Table 5-13
Field Descriptions for the show icmp-statistics Command
Field
Description
Total Messages
Total number of ICMP messages transmitted or received by the ACE
Errors
Number of ICMP error messages transmitted or received by the ACE
Echo Request
Number of ICMP echo request messages transmitted or received by the ACE
Echo Reply
Number of ICMP echo reply messages transmitted or received by the ACE
Unreachable
Number of ICMP unreachable packets transmitted or received by the ACE
TTL Expired
Number of ICMP TTL-expired messages transmitted or received by the ACE
Redirect
Number of ICMP redirect messages transmitted or received by the ACE
Address Mask
Number of ICMP Address Mask Request messages transmitted or received by the ACE
Param problem
Number of ICMP Parameter Problem messages transmitted or received by the ACE
Source Quench
Number of ICMP Source Quench messages transmitted or received by the ACE
Time Stamp
Number of ICMP Time Stamp (request) messages transmitted or received by the ACE
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-11
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying or Collecting Technical Information for Reporting Problems
Displaying or Collecting Technical Information for Reporting
Problems
To display or collect general information about the ACE for use when reporting a problem, perform one
of the following tasks:
Command
Purpose
show tech-support [details]
Displays general information about the ACE for use when you report a problem.
You can use this command to collect a large amount of information about your
ACE and provide the command output to technical support representatives.
This command displays the output of several show commands at once. The
command output varies depending on your configuration.
The optional details keyword provides detailed information for each show
command.
You can choose to have detailed information for each command or even specify
the output for a particular interface or module. Each command output is
separated by the line and the command that precedes the output.
The default output of the show tech-support command includes, for example,
the output of the following commands:
•
show hardware—See the “Displaying Hardware Information” section
•
show interface—See the Cisco Application Control Engine Module Routing
and Bridging Configuration Guide
•
show process—See the “Displaying General System Process Information”
section
•
show running-config—See Chapter 4, Managing the ACE Software
•
show version—See the “Displaying Installed Software Information” section
When using this command, explicitly set the terminal length command to 0
(zero) to disable autoscrolling and enable manual scrolling. Use the show
terminal command to view the configured terminal size. After obtaining the
output of this command, reset your terminal length as required (see the
“Configuring Terminal Display Attributes” section in Chapter 1, Setting Up the
ACE).
You can save the output of this command to a file by appending > filename to
the show tech-support command (see Chapter 4, Managing the ACE
Software). If you save this file, verify that you have sufficient space to do so;
each file may take about 1.8 MB.
Cisco Application Control Engine Module Administration Guide
5-12
OL-20814-01
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying or Collecting Technical Information for Reporting Problems
Command
Purpose
tac-pac {disk0:[path/]filename |
Redirects the same information as the show tech-support command output to a
{ftp://server/path[/filename] |
file on either the ACE disk0: or a remote server.
scp://[username@]server/path[/filename] |
The keywords, arguments, and options are as follows:
sftp://[username@]server/path[/filename]
• disk0:[path/]filename—Specifies that the file destination is the disk0: file
| tftp://server[:port]/path[/filename]}
system of the current context. If you do not provide the optional path, the
ACE copies the file to the root directory on the disk0: file system.
•
ftp://server/path[/filename]—Specifies the FTP network server and,
optionally, the filename.
•
scp://[username@]server/path[/filename]—Specifies the SCP network
server and optional file name.
•
sftp://[username@]server/path[/filename]—Specifies the SFTP network
server and, optionally, the filename.
•
tftp://server[:port]/path[/filename]—Specifies the TFTP network server
and, optionally, the filename.
The output of the show tech-support command is in gzip format. We
recommend that you include the .gz extension in the filename so that it can be
easily unzipped from the destination file system.
Examples
The following example shows the show tech-support command output:
host1/Admin# show tech-support
`show version`
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2006, 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.
Software
loader:
Version 12.2[117]
system:
Version 3.0(0)A1(1) [build 3.0(0)A1(1) _01:26:21-2006/03/13_/auto/a
dbu-rel/ws/REL_3_0_0_A1_1]
system image file: [LCP] disk0:c6ace-t1k9-mzg.3.0.0_A1_1.bin
licensed features: no feature license is installed
Hardware
Cisco ACE (slot: 3)
cpu info:
number of cpu(s): 2
cpu type: SiByte
--More--Generating configuration....
cpu: 0, model: SiByte SB1 V0.2, speed: 700 MHz
cpu: 1, model: SiByte SB1 V0.2, speed: 700 MHz
memory info:
total: 957816 kB, free: 367840 kB
shared: 0 kB, buffers: 2928 kB, cached 0 kB
cf info:
Cisco Application Control Engine Module Administration Guide
OL-20814-01
5-13
Chapter 5
Displaying ACE Hardware and Software System Information
Displaying or Collecting Technical Information for Reporting Problems
filesystem: /dev/cf
total: 500040 kB, used: 449976 kB, available: 50064 kB
last boot reason: reload command by admin
configuration register: 0x1
host kernel uptime is 2 days 16 hours 41 minute(s) 20 second(s)
`show inventory`
NAME: "module 3", DESCR: "Application Control Engine 8G"
PID: WS-SVC-NTS10-1-K9 , VID: V00, SN: SAD0837030D
`show hardware`
Hardware
Product Number:
Serial Number:
Card Index:
Hardware Rev:
Feature Bits:
Slot No. :
Type:
Module mode:
.
.
WS-SVC-NTS10-1-K9
SAD0837030D
207
0.203
0000 0001
3
ACE
8G
Cisco Application Control Engine Module Administration Guide
5-14
OL-20814-01
CH A P T E R
6
Configuring Redundant ACEs
This chapter describes how to configure the Cisco Application Control Engine (ACE) module for
redundancy, which provides fault tolerance for the stateful switchover of flows. It contains the following
major sections:
•
Information About Redundancy
•
Guidelines and Limitations
•
Default Settings
•
Configuring Redundant ACEs
•
Displaying or Clearing Redundancy Information
•
Displaying FT Group Information
•
Clearing Redundancy Statistics
•
Configuration Example of Redundancy
Information About Redundancy
Redundancy (or fault tolerance) uses a maximum of two ACEs in the same Catalyst 6500 series switch
or the Cisco 7600 series router or in separate switches or routers to ensure that your network remains
operational even if one of the modules becomes unresponsive. Redundancy ensures that your network
services and applications are always available.
Redundancy provides seamless switchover of flows in case an ACE becomes unresponsive or a critical
host, interface, or HSRP group fails. Redundancy supports the following network applications that
require fault tolerance:
•
Mission-critical enterprise applications
•
Banking and financial services
•
E-commerce
•
Long-lived flows such as FTP and HTTP file transfers
This section contains the following topics:
•
Redundancy Protocol
•
Stateful Failover
•
FT VLAN
•
Configuration Synchronization
•
Redundancy State for Software Upgrade or Downgrade
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-1
Chapter 6
Configuring Redundant ACEs
Information About Redundancy
Redundancy Protocol
The ACE uses a proprietary protocol to enable redundant configurations of two ACEs (peers). You can
configure a maximum of two ACEs in the same Catalyst 6500 series switch or in different chassis for
redundancy. Each peer module can contain one or more fault-tolerant (FT) groups. Each FT group
consists of two members: one active context and one standby context. For more information about
contexts, see the Cisco Application Control Engine Module Virtualization Configuration Guide. An FT
group has a unique group ID that you assign.
One virtual MAC address (VMAC) is associated with each FT group. The format of the VMAC is:
00-0b-fc-fe-1b-groupID. Because a VMAC does not change upon switchover, the client and server ARP
tables do not require updating. The ACE selects a VMAC from a pool of virtual MACs available to it.
You can specify the pool of MAC addresses that the local ACE and the peer ACE use by configuring the
shared-vlan-hostid command and the peer shared-vlan-hostid command, respectively. To avoid MAC
address conflicts, be sure that the two pools are different on the two ACEs. For more information about
VMACs and MAC address pools, see the Cisco Application Control Engine Module Routing and
Bridging Configuration Guide.
Each FT group acts as an independent redundancy instance. When a switchover occurs, the active
member in the FT group becomes the standby member and the original standby member becomes the
active member. A switchover can occur for the following reasons:
•
The active member becomes unresponsive.
•
A tracked host, interface, or HSRP group fails (see the “Configuring Tracking and Failure
Detection” section).
•
You enter the ft switchover command to force a switchover (see the “Forcing a Failover” section).
Figure 6-1 shows two possible redundancy configurations, where N is the number of ACEs configured
for redundancy. The letters (A, B, C, and D) represent the active contexts in each redundancy group,
while the primed letters (A’, B’, C’, and D’) are the standby contexts. The contexts are evenly distributed
between the two ACEs. You always configure the active and the standby contexts on different ACEs.
Even Distribution of Contexts
N=2
# redundant groups
=2
N=2
# redundant groups
=4
A
B’
B
A’
A
B
C’
D’
C
D
A’
B’
153639
Figure 6-1
Cisco Application Control Engine Module Administration Guide
6-2
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Information About Redundancy
Figure 6-2 shows the uneven distribution of contexts between the two ACEs. As an example, it is
possible that the FT groups A,B, C, and D use only half the resources that E and F require.
Uneven Distribution of Contexts
N=2
# redundant groups
=6
A
B
E
C
E’
D
F
A’
F’
B’
C’
D’
153640
Figure 6-2
To outside nodes (clients and servers), the active and standby FT group members appear as one node
with respect to their IP addresses and associated VMAC. The ACE provides active-active redundancy
with multiple-contexts only when there are multiple FT groups configured on each module and both
modules contain at least one active group member (context). With a single context, the ACE supports
active-backup redundancy and each group member is an Admin context. For details about configuring
contexts, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
The ACE sends and receives all redundancy-related traffic (protocol packets, configuration data,
heartbeats, and state replication packets) on a dedicated FT VLAN. You cannot use this dedicated VLAN
for normal traffic.
To optimize the transmission of heartbeat packets for multiple FT groups and to minimize network
traffic, the ACE sends and receives heartbeat messages using a separate process. The ACE uses the
heartbeat to probe the peer ACE, rather than probe each context. When an ACE does not receive a
heartbeat from the peer ACE, all the contexts in the standby state become active. The ACE sends
heartbeat packets over UDP. You can set the frequency with which the ACE sends heartbeat packets as
part of the FT peer configuration (see the “Configuring an FT Peer” section).
The election of the active member within each FT group is based on a priority scheme. The member
configured with the higher priority is elected as the active member. If a member with a higher priority is
found after the other member becomes active, the new member becomes active because it has a higher
priority. This behavior is known as preemption and is enabled by default. You can override this default
behavior by disabling preemption using the no preempt command. Use the preempt command to enable
preemption after it has been disabled to cause the member with the higher priority always to assert itself
and become active (see the “Configuring an FT Group” section).
If the two members have the same priority, the one with the higher IP address becomes the active
member. We recommend that you always assign a higher priority to the member that you want to be the
active.
Stateful Failover
The ACE replicates flows on the active FT group member to the standby group member per connection
for each context. The replicated flows contain all the flow-state information necessary for the standby
member to take over the flow if the active member becomes unresponsive. If the active member becomes
unresponsive, the replicated flows on the standby member become active when the standby member
assumes mastership of the context. The active flows on the former active member transition to a standby
state to fully back up the active flows on the new active member.
After a switchover occurs, the same connection information is available on the new active member.
Supported end-user applications do not need to reconnect to maintain the same network session.
The state information passed to the standby module includes the following data:
•
Network Address Translation (NAT) table based on information synchronized with the connection
record
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-3
Chapter 6
Configuring Redundant ACEs
Information About Redundancy
•
All Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) connections not
terminated by the ACE
•
HTTP connection states (Optional)
•
Sticky table
To ensure that bridge learning occurs quickly upon a switchover in a Layer 2 configuration in the case
where a VMAC moves to a new location, the new active member sends a gratuitous ARP on every
interface associated with the active context. Also, when there are two VLANs on the same subnet and
servers need to send packets to clients directly, the servers must know the location of the gateway on the
client-side VLAN. The active member acts as the bridge for the two VLANs. In order to initiate learning
of the new location of the gateway, the new active member sends an ARP request to the gateway on the
client VLAN and bridges the ARP response onto the server VLAN.
Note
During failover, the ACE sends failover traffic to destination addresses as Layer 3 unicast and Layer 2
broadcast. As a result, you may encounter high CPU utilization in the interrupt context on the switch that
connects the two ACEs in the failover setup.
FT VLAN
Redundancy uses a dedicated FT VLAN between redundant ACEs to transmit flow-state information and
the redundancy heartbeat. You configure this same VLAN on both peer modules.
The two redundant modules constantly communicate over the FT VLAN to determine the operating
status of each module. The standby member uses the heartbeat packet to monitor the health of the active
member. The active member uses the heartbeat packet to monitor the health of the standby member.
Communications over the switchover link include the following data:
•
Redundancy protocol packets
•
State information replication data
•
Configuration synchronization information
•
Heartbeat packets
For multiple contexts, the FT VLAN resides in the system configuration file. Each FT VLAN on the ACE
has one unique MAC address associated with it. The ACE uses these device MAC addresses as the source
or destination MACs for sending or receiving redundancy protocol state and configuration replication
packets.
Configuration Synchronization
The ACE automatically replicates the active configuration on the standby member using a process called
configuration synchronization (config sync). Config sync automatically replicates any changes made to
the configuration of the active member to the standby member. After the ACE synchronizes the
redundancy configuration from the active member to the standby peer, it disables configuration mode on
the standby.
For information about configuring config sync, see the “Synchronizing Redundant Configurations”
section.
Cisco Application Control Engine Module Administration Guide
6-4
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Guidelines and Limitations
Redundancy State for Software Upgrade or Downgrade
The STANDBY_WARM and WARM_COMPATIBLE redundancy states are used when 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.
When the software versions are different while upgrading or downgrading, the STANDBY_WARM and
WARM_COMPATIBLE states 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. These states allow 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.
Guidelines and Limitations
Configuring redundant ACEs has the following guidelines and limitations:
•
Redundancy is not supported between an ACE module and an ACE appliance operating as peers.
Redundancy must be of the same ACE device type and software release.
•
You can configure a maximum of two ACEs (peers) in the same Catalyst 6500 series switch or in
different chassis for redundancy.
•
Each peer module can contain one or more fault-tolerant (FT) groups. Each FT group consists of
two members: one active context and one standby context. For more information about contexts, see
the Cisco Application Control Engine Module Virtualization Configuration Guide. An FT group has
a unique group ID that you assign.
•
One virtual MAC address (VMAC) is associated with each FT group. The format of the VMAC is:
00-0b-fc-fe-1b-groupID. Because a VMAC does not change upon switchover, the client and server
ARP tables do not require updating. The ACE selects a VMAC from a pool of virtual MACs
available to it. You can specify the pool of MAC addresses that the local ACE and the peer ACE use
by configuring the shared-vlan-hostid command and the peer shared-vlan-hostid command,
respectively. To avoid MAC address conflicts, be sure that the two pools are different on the two
ACEs. For more information about VMACs and MAC address pools, see the Cisco Application
Control Engine Module Routing and Bridging Configuration Guide.
•
In bridged mode (Layer 2), two contexts cannot share the same VLAN.
•
To achieve active-active redundancy, a minimum of two contexts and two FT groups are required on
each ACE.
•
When you configure redundancy, the ACE keeps all interfaces that do not have an IP address in the
Down state. The IP address and the peer IP address that you assign to a VLAN interface should be
in the same subnet, but different IP addresses. For more information about configuring VLAN
interfaces, see the Cisco Application Control Engine Module Routing and Bridging Configuration
Guide.
•
The ACE does not replicate SSL and other terminated (proxied) connections from the active context
to the standby context.
•
The ACE does not support the stateful failover of any connections that are proxied. Such
connections include Layer 7 connections (including SSL), inspection, and HTTP compression.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-5
Chapter 6
Configuring Redundant ACEs
Default Settings
•
In a user context, the ACE allows a switchover only of the FT group that belongs to that context. In
the Admin context, the ACE allows a switchover of all FT groups in all configured contexts in the
module.
•
Do not use this dedicated VLAN for any other network traffic, including HSRP and data.
•
Redundancy uses a dedicated FT VLAN between redundant ACEs to transmit flow-state information
and the redundancy heartbeat. You must configure this same VLAN on both peer modules. You also
must configure a different IP address within the same subnet on each module for the FT VLAN.
•
The IP address and the MAC address of the FT VLAN do not change at switchover.
•
For redundancy to function properly, both members of an FT group must have identical
configurations. Ensure that both ACE modules include the same bandwidth software license (4
Gbps, 8 Gbps, or 16 Gbps) and the same virtual context software license. If there is a mismatch in
a software license between the two ACE modules in an FT group, the following operational behavior
can occur:
– If there is a mismatch in the virtual context software license, synchronization between the active
ACE and standby ACE may not work properly.
– If both the active and the standby ACE modules have the same virtual context software license
but have a different bandwidth software license, synchronization will work properly but the
standby ACE may experience a potential loss of traffic on switchover from, for example, an
8-Gbps ACE module to a 4-Gbps ACE module.
For details about the available ACE software licenses, see Chapter 3, Managing ACE Software
Licenses.
Default Settings
Table 6-1 lists the default settings for the ACE redundancy parameters.
Table 6-1
Default Redundancy Parameters
Parameter
Default
Connection replication
Enabled
Heartbeat interval (frequency in milliseconds (ms) at which the active member of the FT 300 ms
group sends the heartbeat packets to the standby member)
Heartbeat count (number of missed heartbeats that the standby member must detect
before determining that the active member is not available)
10
A member (context) of an FT group becomes the active member through an election
process based on the priority that you configure for the group on each peer. The group
member with the higher priority becomes the active member.
The group member with the higher
priority becomes the active
member.
Priority setting of an FT group on the active member.
100
Priority setting of an FT group on the remote standby member.
100
Automatic synchronization of the startup and running configurations between the active Enabled
and the standby contexts of an FT group.
Priority level for multiple probes on the active member.
0
Preempt
Enabled
Cisco Application Control Engine Module Administration Guide
6-6
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Configuring Redundant ACEs
This section describes how to configure redundant ACEs and includes the following topics:
•
Task Flow for Configuring Redundancy
•
Configuring Redundancy
•
Configuring Tracking and Failure Detection
Task Flow for Configuring Redundancy
Follow these steps to configure redundancy on the ACE:
Step 1
If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the
desired context. If necessary, change to the correct context.
host1/Admin# changeto C1
host1/C1#
The rest of the examples in this table use the Admin context, unless otherwise specified. For details on
creating contexts, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
Step 2
Enter configuration mode.
host1/Admin# config
host1/Admin(config)#
Step 3
Configure a dedicated FT VLAN for communication between the members of the FT group. This FT
VLAN is global and is shared by all contexts. Specify the IP address and netmask of the FT VLAN and
the IP address and netmask of the remote peer.
host1/Admin(config)# ft interface vlan 200
host1/Admin(config-ft-intf)# ip address 192.168.12.1 255.255.255.0
host1/Admin(config-ft-intf)# peer ip address 192.168.12.15 255.255.255.0
host1/Admin(config-ft-intf)# no shutdown
host1/Admin(config-ft-intf)# exit
Step 4
Configure a VLAN with an alias IP address that floats between the active and standby ACEs and serves
as a shared gateway for the two devices.
host1/Admin(config)# interface vlan 100
host1/Admin(config-if)# alias 192.168.1.1 255.255.255.0
host1/Admin(config-if)# exit
Step 5
Configure the local redundancy peer module, associate the FT VLAN with the peer, configure the
heartbeat interval and count, and configure a query interface VLAN.
host1/Admin(config)# ft peer
host1/Admin(config-ft-peer)#
host1/Admin(config-ft-peer)#
host1/Admin(config-ft-peer)#
host1/Admin(config-ft-peer)#
host1/Admin(config-ft-intf)#
Step 6
1
ft-interface vlan 200
heartbeat count 20
heartbeat interval 300
query-interface vlan 400
exit
Create at least one FT group on each ACE.
host1/Admin(config)# ft group 1
host1/Admin(config-ft-group)#
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-7
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Step 7
Associate a context with each FT group. You must associate the local context and the corresponding peer
context with the same FT group.
host1/Admin(config-ft-group)# associate-context C1
Step 8
Associate the peer context with the FT group.
host1/Admin(config-ft-group)# peer 1
Step 9
(Optional) Configure the priority of the FT group on the local module.
host1/Admin(config-ft-group)# priority 100
Step 10
(Optional) Configure the priority of the FT group on the peer module.
host1/Admin(config-ft-group)# peer priority 200
Step 11
Place the FT group in service.
host1/Admin(config-ft-group)# inservice
host1/Admin(config-ft-group)# exit
Step 12
(Optional) Configure one or more critical objects (gateways or hosts, interfaces, or HSRP groups) to
track for switchover. For example, to configure a critical interface for tracking, enter:
host1/Admin(config)# ft track interface VLAN100
host1/Admin(config-ft-track-intf)# track-interface vlan 100
host1/Admin(config-ft-track-intf)# peer track-interface vlan 100
host1/Admin(config-ft-track-intf)# priority 50
host1/Admin(config-ft-track-intf)# peer priority 150
host1/Admin(config-ft-track-intf)# ctrl-z
Step 13
(Optional) Enable autosynchronization of the running- and/or startup-configuration file from the active
to the standby context.
host1/Admin(config)# ft auto-sync running-config
host1/Admin(config)# ft auto-sync startup-config
Step 14
(Optional) Save your configuration changes to Flash memory.
host1/Admin(config)# exit
host1/Admin# copy running-config startup-config
Step 15
(Recommended) Verify your redundancy configuration by using the following commands in Exec mode:
host1/Admin# show running-config ft
host1/Admin# show running-config interface
Configuring Redundancy
This section describes how to configure redundancy on the ACE and contains the following topics:
•
Configuring an FT VLAN
•
Configuring an Alias IP Address
•
Configuring an FT Peer
•
Configuring an FT Group
•
Specifying the Peer Hostname
•
Specifying the MAC Address Banks for a Shared VLAN
Cisco Application Control Engine Module Administration Guide
6-8
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
•
Forcing a Failover
•
Synchronizing Redundant Configurations
Requirements
You must configure the ft interface, ft peer, and ft group commands on all ACEs that participate in the
redundancy configuration.
Configuring an FT VLAN
This section describes how to configure an FT VLAN. Peer ACEs communicate with each other over a
dedicated FT VLAN. These redundant peers use the FT VLAN to transmit and receive heartbeat packets
and state and configuration replication packets. You must configure the same VLAN on each peer
module.
Restrictions
Do not use this dedicated VLAN for any other network traffic, including HSRP and data.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft interface vlan vlan_id
Creates an FT VLAN.
Example:
host1/Admin(config)# ft interface vlan 200
host1/Admin(config-ft-intf)#
The vlan_id argument specifies a unique identifier for the FT
VLAN. Enter an integer from 2 to 4094.
no ft interface vlan vlan_id
(Optional) Removes an FT VLAN from the redundancy
configuration.
Example:
host1/Admin(config)# no ft interface vlan
200
This command enters the FT interface configuration mode.
Note
Step 3
To remove an FT VLAN, first remove it from the FT peer
by using the no ft-interface vlan command in FT peer
configuration mode.
ip address ip_address netmask
Assigns an IP address to the VLAN.
Example:
host1/Admin(config-ft-intf)# ip address
192.168.12.1 255.255.255.0
The keyword and arguments of this command are:
•
address ip_address—Specifies the IP address of the FT
VLAN.
•
netmask—Subnet mask of the FT VLAN. Enter a subnet
mask in dotted-decimal notation.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-9
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Command
Purpose
no ip address ip_address netmask
(Optional) Removes an IP address from an FT VLAN.
Example:
host1/Admin(config-ft-intf)# no ip address
192.168.12.1 255.255.255.0
Step 4
peer ip address ip_address netmask
Allows the local member to communicate with the remote peer.
Example:
host1/Admin(config-ft-intf)# peer ip
address 192.168.12.15 255.255.255.0
The keyword and arguments of this command are as follows:
no peer ip address ip_address netmask
•
address ip_address—Specifies the IP address of the remote
peer.
•
netmask—Subnet mask of the remote peer. Enter a subnet
mask in dotted-decimal notation.
(Optional) Removes an IP address from the remote peer.
Example:
host1/Admin(config-ft-intf)# no peer ip
address 192.168.12.15 255.255.255.0
Step 5
no shutdown
Enables the FT VLAN.
Example:
host1/Admin(config-ft-intf)# no shutdown
(Optional) Disables the FT VLAN after you have enabled it.
shutdown
Example:
host1/Admin(config-ft-intf)# shutdown
Step 6
(Optional) Exits the fault-tolerant interface configuration mode.
exit
Example:
host1/Admin(config-ft-intf)# exit
host1/Admin(config)#
Step 7
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring an Alias IP Address
This section describes how to configure an alias IP address. When you configure redundancy, configure
a VLAN interface that has an alias IP address that floats between the active and standby modules. The
alias IP address serves as a shared gateway for the two ACE modules.
Cisco Application Control Engine Module Administration Guide
6-10
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
Step 3
interface vlan vlan_id
Enters interface configuration mode.
Example:
host1/Admin(config)# interface vlan 100
host1/Admin(config-if)#
The vlan_id argument specifies a unique identifier for the VLAN.
alias ip_address netmask
Configures an alias IP address.
Example:
host1/Admin(config-if)# alias 192.168.1.1
255.255.255.0
The ip_address netmask arguments specify the IP address and
netmask for the VLAN interface. Enter the IP address and subnet
mask in dotted-decimal notation.
no alias ip_address netmask
(Optional) Removes an alias IP address.
This command enters the FT interface configuration mode.
Example:
host1/Admin(config-if)# no alias
192.168.1.1 255.255.255.0
Step 4
do copy running-config startup-config
Example:
host1/Admin(config-if)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring an FT Peer
This section describes how to configure an FT peer definition on both peer ACEs.
Restrictions
This topic includes the following restrictions:
•
You must create FT peers in the admin context only.
•
You can configure a maximum of two ACEs as redundancy peers.
•
Before you can remove an FT peer from the configuration by using the no form of the command,
you must remove the peer from the FT group (see the “Configuring an FT Group” section).
•
You cannot delete a query interface if it is associated with a peer. You must disassociate the interface
from the peer first, and then you can delete the interface.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-11
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft peer peer_id
Creates an FT peer.
Example:
host1/Admin(config)# ft peer 1
host1/Admin(config-ft-peer)
The peer_id argument specifies a unique identifier for the peer.
You can only enter 1.
no ft peer peer_id
(Optional) Removes the FT peer from the configuration.
This command enters the FT peer configuration mode.
Example:
host1/Admin(config)# no ft peer 1
Step 3
ft-interface vlan vlan_id
Associates an FT VLAN with a peer.
Example:
host1/Admin(config-ft-peer) ft-interface
vlan 200
The vlan_id argument specifies the identifier of an existing
VLAN. Enter an integer from 2 to 4094.
no ft-interface vlan vlan_id
(Optional) Removes the FT VLAN from the peer configuration.
Example:
host1/Admin(config-ft-peer) no
ft-interface vlan 200
Step 4
heartbeat {count number | interval
frequency}
Configures the heartbeat interval and count.
The keywords and arguments are:
Example:
host1/Admin(config-ft-peer) heartbeat
interval 500
no heartbeat {count number | interval
frequency}
•
count number—Specifies the number of heartbeat intervals
that must transpire with no heartbeat packet received by the
standby member before the standby member determines that
the active member is not available. Enter an integer from 10
to 50. The default is 10 heartbeat intervals. If the standby
member of the FT group does not receive a heartbeat packet
from the active member, a time period equal to count number
times interval frequency must elapse before a switchover can
occur. For example, in the default case, where the heartbeat
frequency is 300 ms and the heartbeat count is 10, if the
standby member does not receive a heartbeat packet from the
active member for 3000 ms (3 seconds), a switchover occurs.
•
interval frequency—Specifies the interval in milliseconds
(ms) between heartbeats. Enter an integer from 100 to 1000
ms. The default is 300 ms.
(Optional) Resets either the heartbeat count to the default of 10
or the heartbeat interval to the default of 100 ms.
Example:
host1/Admin(config-ft-peer) no heartbeat
interval 500
Cisco Application Control Engine Module Administration Guide
6-12
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Step 5
Command
Purpose
query-interface vlan vlan-id
Configures a query interface to allow the standby member to
determine whether the active member is down or if there is a
connectivity problem with the FT VLAN. A query interface helps
prevent two redundant contexts from becoming active at the same
time for the same FT group. Before triggering a switchover, the
ACE pings the active member to make sure that it is down.
Configuring a query interface allows you to assess the health of
the active member, but it increases switchover time.
Example:
host1/Admin(config-ft-peer)#
query-interface vlan 400
The vlan_id argument specifies the identifier of an existing
VLAN. Enter an integer from 2 to 4094.
no query-interface vlan vlan-id
Example:
host1/Admin(config-ft-peer)# no
query-interface vlan 400
(Optional) Removes a query interface from the peer
configuration.
Note
Step 6
do copy running-config startup-config
Example:
host1/Admin(config-ft-peer)# do copy
running-config startup-config
You cannot delete a query interface if it is associated with
a peer. You must disassociate the interface from the peer
first, and then you can delete the interface.
(Optional) Copies the running configuration to the startup
configuration.
Configuring an FT Group
This section describes how to configure multiple FT groups on each ACE.
Prerequisites
Before you place an FT group in service, be sure that you have associated one context with the FT group
and that you have properly configured the two peers.
Restrictions
This topic includes the following restrictions:
•
You must configure the same group ID on both peer modules.
•
The maximum number of FT groups that you can create is 251 groups (250 user contexts and 1
Admin context).
•
Each FT group consists of a maximum of two members (contexts): one active context on one module
and one standby context on the peer module
•
Before you can remove a context from an FT group, you must first take the group out of service by
using the no inservice command.
•
The ACE does not perform bulk config synchronization (sync) on the peer priority command value
in the FT group associated with the Admin context to the peer. Therefore, you may observe a peer
priority value in the running-configuration file that is different from the actual operating value. For
information on bulk config sync, see the “Synchronizing Redundant Configurations” section.
•
If you disable preemption by using the no preempt command and a member with a higher priority
is found after the other member has become active, the electing member becomes the standby
member even though it has a higher priority.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-13
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft group group_id
Creates an FT group.
Example:
host1/Admin(config) ft group 1
host1/Admin(config-ft-group)#
The group_id argument specifies a unique identifier of the group.
Enter an integer from 1 to 255.
no ft group group_id
(Optional) Removes the FT group from the configuration.
This command enters the FT group configuration mode.
Example:
host1/Admin(config) no ft group 1
Step 3
associate-context name
Associates a context with an FT group.
Example:
host1/Admin(config-ft-group)#
associate-context C1
no associate-context name
(Optional) Removes a context from an FT group.
Example:
host1/Admin(config-ft-group)# no
associate-context C1
Step 4
peer peer_id
Associates a peer ACE with an FT group.
Example:
host1/Admin(config-ft-group)# peer 1
For the peer_id argument, enter 1 as the identifier of an existing
peer module. You can only enter 1.
no peer peer_id
(Optional) Removes the peer association with the FT group.
Example:
host1/Admin(config-ft-group)# no peer 1
Step 5
priority number
Example:
host1/Admin(config-ft-group)# priority 150
Configures the priority of an FT group on the active member.
Configure a higher priority on the FT group member that you
want to be the active member.
The number argument specifies the priority of the FT group on
the local peer. Enter an integer from 1 to 255. The default is 100.
no priority
(Optional) Restores the default priority of 100.
Example:
host1/Admin(config-ft-group)# no priority
Step 6
peer priority number
Example:
host1/Admin(config-ft-group)# peer
priority 150
Configures the priority of an FT group on the remote standby
member. Configure a lower priority on the FT group member that
you want to be the standby member.
The number argument specifies the priority of the FT group on
the standby member. Enter an integer from 1 to 255. The default
is 100.
Cisco Application Control Engine Module Administration Guide
6-14
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Command
Purpose
no peer priority
(Optional) Restores the default priority of 100.
Example:
host1/Admin(config-ft-group)# no priority
Step 7
preempt
Example:
host1/Admin(config-ft-group)# preempt
Configures preemption after it has been disabled. Preemption
ensures that the group member with the higher priority always
asserts itself and becomes the active member. By default,
preemption is enabled.
(Optional) Disables preemption.
no preempt
Example:
host1/Admin(config-ft-group)# no preempt
Step 8
Places an FT group in service.
inservice
Example:
host1/Admin(config-ft-group)# inservice
no inservice
(Optional) Takes the FT group out of service.
Example:
host1/Admin(config-ft-group)# no inservice
Step 9
do copy running-config startup-config
Example:
host1/Admin(config-ft-group)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Modifying an FT Group
This section describes how to modify an FT group.
Note
You can modify the priority, peer priority, and preempt command values without taking the FT group
out of service.
Details
Follow these steps to modify an FT group:
Step 1
Remove the FT group from service by using the no inservice command.
Step 2
Make the necessary modifications to the FT group.
Step 3
Place the FT group back in service by using the inservice command.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-15
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Specifying the Peer Hostname
This section describes how to specify the peer hostname.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
peer hostname name
Example:
host1/Admin(config)# peer hostname ACE_2
Specifies the hostname of a peer ACE. For details about this
command, see the “Assigning a Name to the ACE” section.
Specifying the MAC Address Banks for a Shared VLAN
This section describes how to specify the MAC address banks to be used by the local ACE and the peer
ACE with a shared VLAN (FT VLAN). You configure these commands to prevent MAC address
conflicts between the two peer ACEs. For details about these commands, see the Cisco Application
Control Engine Module Routing and Bridging Configuration Guide.
Restrictions
This topic includes the following restrictions:
•
Perform this task from the Admin context only.
•
Select a bank of MAC addresses for the peer that is different from that used by the local ACE.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
shared-vlan-hostid number
Example:
host1/Admin(config)# shared-vlan-hostid 3
Configures the bank of MAC addresses that the ACE uses. Enter
a number from 1 to 16. Be sure to configure different bank
numbers for multiple ACEs.
The number argument is the bank of MAC addresses that the ACE
uses. Enter a number from 1 to 16. Be sure to configure different
bank numbers for multiple ACEs.
For details about this command, see the Cisco Application
Control Engine Module Routing and Bridging Configuration
Guide.
Cisco Application Control Engine Module Administration Guide
6-16
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Command
Purpose
no shared-vlan-hostid
(Optional) Removes a configured bank of MAC addresses.
Example:
host1/Admin(config)# no shared-vlan-hostid
Step 3
peer shared-vlan-hostid number
Example:
host1/Admin(config)# peer
shared-vlan-hostid 3
Configures a specific bank of MAC addresses for a peer ACE in
a redundant configuration.
The number argument is the bank of MAC addresses that the ACE
uses. Enter a number from 1 to 16. Be sure to configure different
bank numbers for multiple ACEs.
For details about this command, see the Cisco Application
Control Engine Module Routing and Bridging Configuration
Guide.
no peer shared-vlan-hostid
(Optional) Removes the configured bank of MAC addresses.
Example:
host1/Admin(config)# no peer
shared-vlan-hostid
Step 4
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Forcing a Failover
This section describes how to force a failover (switchover). You may need to force a switchover when
you want to make a particular context the standby (for example, for maintenance or a software upgrade
on the currently active context). If the standby group member can statefully becoming the active member
of the FT group, a switchover occurs.
Note
During failover, the ACE sends failover traffic to destination addresses as Layer 3 unicast and Layer 2
broadcast. As a result, you may encounter high CPU utilization in the interrupt context on the switch that
connects the two ACEs in the failover setup.
The switchover process exhibits the following behavior, depending on whether you perform the task
from the Admin context or a user context:
•
Admin context—If you specify an FT group ID, then the FT group specified by the group ID
switches over. If you do not specify a group ID, then the Admin context switches over.
•
User context—Because you cannot specify an FT group ID in a user context, the context in which
you enter the command switches over.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-17
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Note
When you specify the ft switchover command to force a switchover, there may be brief periods of time
when the configuration mode is enabled on the new active group member to allow the administrator to
make configuration changes. However, any configuration changes made during this time are not
synchronized with the standby group member and will exist only on the active group member. We
recommend that you refrain from making any configuration changes after you enter the ft switchover
command until the FT states stabilize to ACTIVE and STANDBY_HOT. Once the FT group reaches the
steady state of ACTIVE and STANDBY_HOT, any configuration changes performed on the active group
member will be incrementally synchronized to the standby group member, assuming that configuration
synchronization is enabled.
Prerequisites
To use the ft switchover command, you must disable preemption by using the no preempt command.
For information on the preempt command, see the “Configuring an FT Group” section.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft group group_id
Enters the FT group configuration mode.
Example:
host1/Admin(config) ft group 1
host1/Admin(config-ft-group)#
Step 3
no preempt
Disables preemption.
Example:
host1/Admin(config-ft-group)# no preempt
Step 4
Ctrl-z
Returns to the Exec mode prompt.
Example:
host1/Admin(config-ft-group)# Ctrl-z
host1/Admin#
Step 5
ft switchover [all [force] | force |
[group_id [force]]]
Causes a switchover.
The keywords, arguments, and options are:
Example:
host1/Admin# ft switchover 1
This command will cause card to switchover
(yes/no)? [no] yes
•
all—(Optional) Causes a switchover of all FT groups
configured in the ACE simultaneously. This keyword is
available in the Admin context only.
•
force—(Optional) Causes a switchover while ignoring the
state of the standby member. Use this option only when the
FT VLAN is down. This keyword is available in the Admin
context only.
•
group_id—(Optional) FT group that you want to switch over.
Enter the ID of an existing FT group as an integer from 1 to
255. This argument is available in the Admin context only.
Cisco Application Control Engine Module Administration Guide
6-18
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Synchronizing Redundant Configurations
This section describes how to synchronize redundant configurations. To ensure that the running
configurations on both the active and the standby contexts of an FT group are identical, the ACE
automatically synchronizes the running configurations between the two contexts. After the active
context has accepted either a new configuration or modifications to an existing configuration, the ACE
automatically applies the new configuration or configuration changes to the standby context and disables
configuration mode in the standby context.
The ACE supports the following two types of configuration synchronizations:
•
Bulk config sync—Synchronizes the entire active context configuration to the standby context when
the peer comes up or when autosynchronization is enabled
•
Dynamic config sync—Synchronizes the configuration applied to the active context to the standby
context if the peer is already up
You can enable automatic synchronization of the running-configuration and the startup-configuration
files after they have been explicitly disabled.
Caution
Toggling ft auto-sync running-config in the Admin context may have undesirable side effects if the
same command is also disabled in an active user context. If ft auto-sync running-config is disabled in
the active Admin context and in an active user context, and you subsequently enable ft auto-sync
running-config in the active Admin context first, the entire configuration of the standby user context
will be lost. Always enable ft auto-sync running-config in the active user context first, and then enable
the command in the active Admin context.
Restrictions
This topic includes the following restrictions:
•
The configurations on both the active context and the standby context must be identical. If there is
a mismatch between configuration objects, then configuration synchronization may fail.
•
If the standby ACE has reached the maximum resource limit for a configuration object even if some
of the configuration objects are not in the redundant context and you configure one more object of
the same type in the redundant context of the active ACE, configuration synchronization will fail.
For example, suppose that you have configured two contexts on each ACE (Admin and C1) and the
C1 context is the only one in the FT group. On the standby ACE, you have configured 8,192 match
source-address statements in the Admin context and in the C1 context for a total of 16,384 match
source-address statements (the ACE limit). When you configure one new match source-address
statement on the active ACE in C1, configuration synchronization will fail, the new match statement
will not be replicated to the standby, and syslog ACE-1-727005 is generated.
•
If you operate the active ACE with config sync disabled for a prolonged period of time, you must
manually duplicate any changes that you make to the active ACE on the standby ACE to ensure that
connection replication works properly.
•
If a license mismatch occurs between the two ACEs in a redundant configuration, the ft auto-sync
command is automatically disabled and a syslog message is generated.
•
If you temporarily disable ft auto-sync running-config on the active ACE (for example, to test
changes to your configuration), when you subsequently reenable config sync, any changes that you
made to the active ACE are duplicated on the standby ACE. Note that the standby ACE remains in
the STANDBY_HOT state even when config sync is disabled on the active ACE.
•
If the configuration synchronization fails, the running-configuration file reverts to the
startup-configuration file.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-19
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
•
The ACE does not copy or write changes in the running-configuration file to the
startup-configuration file unless you enter the copy running-config startup-config command or the
write memory command for the current context. To write the contents of the running-configuration
file to the startup-configuration file for all contexts, use the write memory all command. At this
time, if the ft auto-sync startup-config command is enabled, the ACE synchronizes the
startup-configuration file on the active ACE to the standby ACE.
•
The ACE does not synchronize the SSL certificates and key pairs that are present in the active
context with the standby context of an FT group. If the ACE performs a configuration
synchronization and does not find the necessary certificates and keys in the standby context, config
sync fails and the standby context enters the STANDBY_COLD state.
Caution
Do not enter the no inservice command followed by the inservice command on the active
context of an FT group when the standby context is in the STANDBY_COLD state. Doing so
may cause the standby context running-configuration file to overwrite the active context
running-configuration file.
To copy the certificates and keys to the standby context, you must export the certificates and keys
from the active context to an FTP or TFTP server using the crypto export command, and then
import the certificates and keys to the standby context using the crypto import command. For more
information about importing and exporting certificates and keys, see the Cisco Application Control
Engine Module SSL Configuration Guide.
To return the standby context to the STANDBY_HOT state in this case, ensure that you have
imported the necessary SSL certificates and keys to the standby context, and then perform a bulk
sync of the active context configuration by entering the following commands in configuration mode
in the active context of the FT group:
1.
no ft auto-sync running-config
2.
ft auto-sync running-config
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/C1# config
host1/C1#(config)#
Step 2
ft auto-sync {running-config |
startup-config}
Example:
host1/C1(config) ft auto-sync
running-config
no ft auto-sync {running-config |
startup-config}
Enables automatic synchronization of the running-configuration
and the startup-configuration files after they have been explicitly
disabled.
The keywords are:
•
running-config—Enables autosynchronization of the
running-configuration file. The default is enabled.
•
startup-config—Enables autosynchronization of the
startup-configuration file. The default is enabled.
(Optional) Disables automatic synchronization of the
running-configuration and the startup-configuration files.
Example:
host1/C1(config) no ft auto-sync
running-config
Cisco Application Control Engine Module Administration Guide
6-20
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Configuring Tracking and Failure Detection
This section describes the tracking and failure detection feature of the ACE. This feature allows you to
designate certain network items as critical so that if one or more items fail, the ACE reduces the priority
of the associated active FT group accordingly. If the priority of the active FT group falls below the
priority of the corresponding FT group on the standby, a switchover occurs.
The ACE supports the tracking and failure detection of several network items. You can configure an ACE
to track and detect failures in the following items in the Admin context and any user context:
•
Gateways or hosts
•
Interfaces
•
Hot Standby Router Protocol (HSRP) groups
If one of the items that you configure for tracking and failure detection becomes unresponsive and is
associated with the active member of an FT group, by default, the ACE subtracts a value of 0 from the
configured priority of the active member. If you configure a nonzero value for the tracking priority and
the resulting priority value of the active member is less than that of the standby member, the active
member switches over and the standby member becomes the new active member. All active flows that
exist at the time of the switchover continue uninterrupted on the new active member of the FT group.
When the failed item comes back up, the ACE increments the priority of the associated group member
by a value of 0 by default. If you configure a non-zero value for the tracking priority and the resulting
priority of the standby member is greater than the priority of the active member, a switchover occurs
back to the original active group member.
You can configure the unit priority associated with tracked items to be greater than 0. This option allows
you to fine tune the switchover scenario so that a switchover occurs when either all or any of the tracked
objects fails.
Note
To prevent an unexpected switchover from occurring, we strongly recommend that you disable
preemption while you are configuring tracking. After you configure tracking and before you reenable
preemption, ensure that the tracked network objects are up and operating properly. A switchover may
occur immediately when you reenable preemption. Preemption must be enabled for a tracking
switchover to work. For details about preemption, see the “Configuring an FT Group” section.
For example, suppose that on ACE 1 you configure the active FT group member with a priority of 100
and on ACE 2 you configure the standby FT group member with a priority of 70. Assume that you
configure the FT group to track three critical interfaces, each with a unit priority of 15. To trigger a
switchover, all three interfaces must fail so that the priority of the active member is less than the priority
of the standby member (100 – 45 = 55).
To illustrate the “any” scenario, assume that the active and the standby FT group members have the same
individual priorities as in the previous example (100 and 70, respectively). However, this time you
configure the three tracked interfaces, each with a unit priority of 40. If any one of the interfaces
associated with the active member goes down, then the priority of the active member falls below the
priority of the standby member and a switchover occurs. If that failed interface later returns to service,
the ACE increments the associated group member priority by 40, and a switchover would occur back to
the original active member. To guarantee a switchover if any tracked item goes down, configure the unit
priority on each tracked item equal to the group member’s priority. In this case, you could configure the
unit priority to be 100.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-21
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
This section contains the following topics:
•
Configuring Tracking and Failure Detection for a Host or Gateway
•
Configuring Tracking and Failure Detection for an Interface
•
Configuring Tracking and Failure Detection for an HSRP Group
Configuring Tracking and Failure Detection for a Host or Gateway
This section describes how to configure tracking and failure detection for a gateway or a host.
Restrictions
If you remove a probe from the active FT group member configuration and you have not configured a
tracking priority for the FT group, the ACE increments the net FT group priority by the priority value of
the deleted probe. You cannot delete a probe from the running-configuration file if the ACE is using the
probe for tracking.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft track host name
Example:
host1/Admin(config)# ft track host
TRACK_GATEWAY1
host1/Admin(config-ft-track-host)#
Creates a tracking and failure detection process for a gateway or
host.
For the name argument, enter a unique identifier of the tracking
process as an unquoted text string with no spaces and a maximum
of 64 alphanumeric characters.
This commands enters the FT track host configuration mode.
Step 3
track-host ip_address
Configures the IP address of the gateway or host.
Example:
host1/Admin(config-ft-track-host)#
track-host 192.168.12.101
The ip_address argument specifies the IP address of the gateway
or host that you want the active FT group member to track.
no track-host ip_address
(Optional) Removes the IP address of the gateway or host from
the tracking process on the standby member configuration.
Example:
host1/Admin(config-ft-track-host)# no
track-host 192.168.12.101
This command enters the FT group configuration mode.
Cisco Application Control Engine Module Administration Guide
6-22
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Step 4
Command
Purpose
probe name priority number
Associates an existing probe with a gateway or host for tracking
by the active member. For information about creating probes, see
the Cisco Application Control Engine Module Server Load-Balancing Configuration Guide.
Example:
host1/Admin(config-ft-track-host)# probe
TCP_PROBE1 priority 50
The keyword and arguments are:
no probe name
•
name—Identifier of an existing probe that you want to
associate with a gateway or host for tracking.
•
priority number—Specifies the priority of the probe sent by
the active member. Enter an integer from 0 to 255. The
default is 0. Higher values indicate higher priorities. Assign
a priority value based on the relative importance of the
gateway or host that the probe is tracking. If the probe goes
down, the ACE decrements the priority of the FT group on
the active member by the value of the number argument. If
the resulting priority of the FT group on the active member
is less than the priority of the FT group on the standby
member, a switchover occurs.
(Optional) Removes the tracking probe from the active member.
Example:
host1/Admin(config-ft-track-host)# no
probe TCP_PROBE1
Step 5
priority number
Assigns a priority for multiple probes on the active member.
Example:
host1/Admin(config-ft-track-host)# priority 50
The number argument specifies the priority of the probes on the
active member. Enter a priority value as an integer from 0 to 255.
The default is 0. Higher values indicate higher priorities. Assign
a priority value based on the relative importance of the gateway
or host that the probes are tracking. If all the probes go down, the
ACE decrements the priority of the FT group on the active
member by the value of the number argument. If the resulting
priority of the FT group on the active member is less than the
priority of the FT group on the standby member, a switchover
occurs.
no priority number
(Optional) Resets the priority to the default value of 0.
Example:
host1/Admin(config-ft-track-host)# no priority 50
Step 6
peer track-host ip_address
Configures the IP address of the gateway or host.
Example:
host1/Admin(config-ft-track-host)# peer
track-host 172.16.27.1
The ip_address argument specifies the IP address of the gateway
or host that you want the standby FT group member to track.
no peer track-host ip_address
(Optional) Removes the host tracked by the standby member.
Example:
host1/Admin(config-ft-track-host)# no peer
track-host 172.16.27.1
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-23
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Step 7
Command
Purpose
peer probe name priority number
Associates an existing probe with a gateway or host for tracking
by the standby member.
Example:
host1/Admin(config-ft-track-host)# peer
probe TCP_PROBE1 priority 25
Step 8
•
name—Identifier of an existing probe that you want to
associate with a gateway or host for tracking.
•
priority number—Specifies the priority of the probe sent by
the standby member. Enter an integer from 0 to 255. The
default is 0. Higher values indicate higher priorities. Assign
a priority value based on the relative importance of the
gateway or host that the probe is tracking. If the probe goes
down, the ACE decrements the priority of the FT group on
the standby member by the value of the number argument.
no peer probe name
Example:
host1/Admin(config-ft-track-host)# no peer
probe TCP_PROBE1
(Optional) Removes the tracking probe from the standby
member.
peer priority number
Assigns a priority for multiple probes on the standby member.
Example:
host1/Admin(config-ft-track-host)# peer
priority 25
The number argument specifies the priority of the probes
configured for the gateway or host on the standby member. Enter
a priority value as an integer from 0 to 255. The default is 0.
Higher values indicate higher priorities. Assign a priority value
based on the relative importance of the gateway or host that the
probes are tracking. If all the probes go down, the ACE
decrements the priority of the FT group on the standby member
by the value of the number argument.
no peer priority number
(Optional) Reset the multiple-probe priority to the default value
of 0 on the standby member.
Example:
host1/Admin(config-ft-track-host)# peer
priority 25
Step 9
The keyword and arguments are:
do copy running-config startup-config
Example:
host1/Admin(config-ft-track-host)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Examples
The following example demonstrates a tracking configuration for a gateway on the active member of an
FT group:
ft track host TRACK_GATEWAY
track-host 192.161.100.1
probe GATEWAY_TRACK1 priority 10
probe GATEWAY_TRACK2 priority 20
priority 50
In this configuration example, if the GATEWAY_TRACK1 probe goes down, the ACE reduces the
priority of the FT group on the active member by 10. If the GATEWAY_TRACK2 probe goes down, the
ACE reduces the priority of the FT group on the active member by 20. If both probes go down, the ACE
reduces the priority of the FT group on the active member by 50. If at any time the priority of the FT
group on the active member falls below the priority of the FT group on the standby member, a switchover
occurs.
Cisco Application Control Engine Module Administration Guide
6-24
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Configuring Tracking and Failure Detection for an Interface
This section describes how to configure tracking and failure detection for an interface.
Restrictions
You cannot delete an interface if the ACE is using the interface for tracking. Also, you cannot configure
the FT VLAN for tracking.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft track interface name
Creates a tracking and failure detection process for an interface.
Example:
host1/Admin(config)# ft track interface
TRACK_VLAN100
host1/Admin(config-ft-track-intf)#
For the name argument, enter a unique identifier for the tracking
process as an unquoted text string with no spaces and a maximum
of 64 alphanumeric characters.
This commands enters the FT track interface configuration mode.
Step 3
no ft track interface name
(Optional) Removes the interface-tracking process.
Example:
host1/Admin(config)# ft track interface
TRACK_VLAN100
Step 4
track-interface vlan vlan_id
Example:
host1/Admin(config-ft-track-intf)#
track-interface vlan 100
no track-interface vlan vlan_id
Configures the interface that you want the active member to
track.
For the vlan_id argument, enter the VLAN ID of an existing
VLAN configured on the active member as an integer from 2 to
4094.
(Optional) Removes the VLAN from the tracking process.
Example:
host1/Admin(config-ft-track-intf)# no
track-interface vlan 100
Step 5
priority number
Example:
host1/Admin(config-ft-track-intf)# priority 50
Configures the interface that you want the active member to
track.
The number argument specifies the priority of the interface on the
active member. Enter a priority value as an integer from 0 to 255.
The default is 0. Higher values indicate higher priorities. Assign
a priority value based on the relative importance of the interface
that you are tracking.
If the tracked interface goes down, the ACE decrements the
priority of the FT group on the active member by the value of the
number argument. If the priority of the FT group on the active
member falls below the priority of the FT group on the standby
member, a switchover occurs.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-25
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Command
Purpose
no priority number
(Optional) Resets the interface priority on the active member to
the default value of 0.
Example:
host1/Admin(config-ft-track-intf)# no priority 50
Step 6
peer track-interface vlan vlan_id
Example:
host1/Admin(config-ft-track-intf)# peer
track-interface vlan 200
no peer track-interface vlan vlan_id
Configures the interface that you want the standby member to
track.
The vlan_id argument is a VLAN ID of an existing VLAN configured on the standby member as an integer from 2 to 4094.
(Optional) Removes the VLAN from the tracking process.
Example:
host1/Admin(config-ft-track-intf)# no peer
track-interface vlan 200
Step 7
peer priority number
Example:
host1/Admin(config-ft-track-intf)# peer
priority 25
no peer priority number
Example:
host1/Admin(config-ft-track-intf)# no peer
priority 25
Step 8
do copy running-config startup-config
Example:
host1/Admin(config-ft-track-intf)# do copy
running-config startup-config
Assigns a priority to the tracked interface that the standby
member is tracking.
The number argument specifies the priority of the interface on the
standby member. Enter a priority value as an integer from 0 to
255. The default is 0. Higher values indicate higher priorities.
Assign a priority value based on the relative importance of the
interface that you are tracking.
(Optional) Resets the interface priority on the standby member to
the default value of 0.
(Optional) Copies the running configuration to the startup
configuration.
Examples
The following example demonstrates a tracking configuration for an interface on the active member of
an FT group and configures the interface that you want the standby member to track:
ft track interface TRACK_VLAN100
track-interface vlan 100
priority 50
peer track-interface vlan 200
peer priority 25
In this configuration example, if VLAN 100 goes down, then the ACE reduces the priority of the FT
group on the active member by 50. If at any time the priority of the FT group on the active member falls
below the priority of the FT group on the standby member, a switchover occurs.
Cisco Application Control Engine Module Administration Guide
6-26
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Configuring Tracking and Failure Detection for an HSRP Group
This section describes how to configure a tracking and failure detection process for a Hot Standby Router
Protocol (HSRP) group that you have previously configured on the Catalyst 6500 supervisor engine or
the Cisco 7600 series router.
Prerequisites
This topic includes the following prerequisites:
•
For best results, observe the following configurational requirements before you attempt to configure
HSRP tracking and failure detection on the ACE:
– Before you configure an HSRP tracking and failure detection process on the ACE, you must
configure the HSRP group on the supervisor engine. For example, if the HSRP group (including
the name) is configured on the supervisor engine and it is not in the Active or the Standby state,
you will see the following output when you enter the show ft track detail command on the
ACE:
Track type
HSRP Group Name
State
Priority
Transitions
: TRACK_HSRP
: test
: TRACK_DOWN (HSRP Group does not exist
on the Supervisor or it is in the INIT
State)
: 20
: 1
For example, if the HSRP group is in the Standby state, you will see the following output when
you enter the show ft track detail command on the ACE:
Track type
HSRP Group Name
State
Priority
Transitions
: TRACK_HSRP
: test
: TRACK_DOWN (HSRP Group is Standby on
the Supervisor)
: 20
: 1
For example, if the HSRP group is in the Active state, you will see the following output when
you enter the show ft track detail command on the ACE:
Track type
HSRP Group Name
State
Priority
Transitions
:
:
:
:
:
TRACK_HSRP
test
TRACK_UP
20
2
– If the HSRP group (including the name) is configured on the supervisor engine after the HSRP
tracking process is initially configured on the ACE, you may or may not obtain the expected
results when you enter the show ft track detail command on the ACE.
– If the HSRP group name is changed on the supervisor engine after the HSRP tracking process
is configured on the ACE, further state notifications will not be sent to the ACE. You must delete
the HSRP tracking process on the ACE after the HSRP group name is changed on the supervisor
engine.
•
To obtain the correct HSRP group identifier to use for tracking on the ACE, enter the show standby
vlan command on the Catalyst 6500 series switch or 7600 series router.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-27
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
For example, enter the following command:
sh-ace-6k-1# show standby vlan 120
Vlan120 - Group 120
Local state is Active, priority 200, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.022
Virtual IP address is 192.168.120.254 configured
Active router is local
Standby router is 192.168.120.252 expires in 8.360
Virtual mac address is 0000.0c07.ac78
7 state changes, last state change 21:54:53
IP redundancy name is "hsrp-Vl120-120" (default)
Priority tracking 1 interface or object, 1 up:
Interface or object
Decrement State
GigabitEthernet4/35
110
Up
Use the IP redundancy name (shown in bold in the above output example) as the HSRP group name.
The switch or router automatically assigns this name to the HSRP group.
Restrictions
This topic includes the following restrictions:
•
The ACE allows you to track up to 250 HSRP groups.
•
When you configure HSRP tracking on the FT group member and the HSRP group does not exist on
the supervisor engine, the ACE marks the tracking process as TRACK_DOWN and automatically
decrements the net priority of the FT group by the tracking priority value.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
ft track hsrp tracking_process_name
Creates a tracking and failure detection process for an HSRP group.
Example:
host1/Admin(config)# ft track hsrp
HSRP_TRACK_PROCESS1
host1/Admin(config-ft-track-hsrp)#
For the tracking_process_name argument, enter a unique identifier of
the tracking process as an unquoted text string with no spaces and a
maximum of 64 alphanumeric characters.
This commands enters the FT track hsrp configuration mode.
no ft track hsrp
tracking_process_name
(Optional) Removes the HSRP group-tracking process.
Example:
host1/Admin(config)# no ft track hsrp
HSRP_TRACK_PROCESS1
Cisco Application Control Engine Module Administration Guide
6-28
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuring Redundant ACEs
Step 3
Command
Purpose
track-hsrp name
Tracks an HSRP group on the active member of an FT group.
Example:
host1/Admin(config-ft-track-hsrp)#
track-hsrp hsrp-vl120-120
For the name argument, enter the identifier of an HSRP group previously configured on the Catalyst supervisor that you want to track on
the active member (see the last bullet in the “Prerequisites”section”).
Enter the name as an unquoted text string with no spaces and a
maximum of 64 alphanumeric characters. The ACE allows you to track
up to 250 HSRP groups.
no track-hsrp name
(Optional) Removes the HSRP group from the tracking process.
Example:
host1/Admin(config-ft-track-hsrp)# no
track-hsrp hsrp-vl120-120
Step 4
priority number
Example:
host1/Admin(config-ft-track-hsrp)#
priority 50
no priority number
Assigns a priority to the HSRP group that you are tracking on the
active member of an FT group.
For the number argument, enter the priority of the HSRP group as an
integer from 0 to 255. The default is 0. Higher values indicate higher
priorities. Assign a priority value based on the relative importance of
the HSRP group that you are tracking. If the HSRP group goes down,
the ACE decrements the priority of the FT group on the active member
by the value of the number argument. If the priority of the FT group on
the active member falls below the priority of the FT group on the
standby member, a switchover occurs.
(Optional) Resets the priority to the default value of 0.
Example:
host1/Admin(config-ft-track-hsrp)# no
priority 50
Step 5
peer track-hsrp name
Tracks an HSRP group on the standby member of an FT group.
Example:
host1/Admin(config-ft-track-hsrp)#
peer track-hsrp HSRP_GRP1
For the name argument, enter the identifier of an HSRP group previously configured on the supervisor engine that you want to track on the
standby member of an FT group (see the last bullet in the “Prerequisites”section”). Enter the name as an unquoted text string with no
spaces and a maximum of 64 alphanumeric characters.
no peer track-hsrp name
(Optional) Removes the HSRP group from the tracking process.
Example:
host1/Admin(config-ft-track-hsrp)# no
peer track-hsrp HSRP_GRP1
Step 6
peer priority number
Example:
host1/Admin(config-ft-track-hsrp)#
peer priority 25
Assigns a priority to the HSRP group that you are tracking on the
standby member of an FT group.
For the number argument, enter the priority of the HSRP group as an
integer from 0 to 255. The default is 0. Higher values indicate higher
priorities. Assign a priority value based on the relative importance of
the HSRP group that you are tracking. If the HSRP group goes down,
the ACE decrements the priority of the FT group on the standby
member by the value of the number argument.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-29
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Command
Purpose
no peer priority number
(Optional) Resets the priority to the default value of 0.
Example:
host1/Admin(config-ft-track-hsrp)# no
peer priority 25
Step 7
do copy running-config startup-config
Example:
host1/Admin(config-ft-track-hsrp)# do
copy running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Examples
The following example demonstrates a tracking configuration for an HSRP group on the active member
of an FT group and identifies an HSRP group that you want to track on the standby member of the FT
group:
ft track hsrp TRACK_HSRP_GRP1
track-hsrp HSRP_GRP1
priority 50
peer track-hsrp HSRP_GRP1
peer priority 25
In the configuration example, if the HSRP_GRP1 group goes down, the ACE reduces the priority of the
FT group on the active member by 50. If at any time the priority of the FT group on the active member
falls below the priority of the FT group on the standby member, a switchover occurs.
Displaying or Clearing Redundancy Information
This section describes how to display or clear information about redundancy and contains the following
sections:
•
Displaying Redundancy Information
•
Clearing Redundancy Statistics
Displaying Redundancy Information
This section describes the show commands that display configuration, status, and statistical information
for your redundancy configuration and contains the following sections:
•
Displaying Redundancy Configuration Information
•
Displaying Bulk Synchronization Command Failures on the Standby ACE
•
Displaying FT Group Information
•
Displaying the Redundancy Internal Software History
•
Displaying the IDMAP Table
•
Displaying Memory Statistics
•
Displaying Peer Information
•
Displaying FT Statistics
•
Displaying FT Tracking Information
Cisco Application Control Engine Module Administration Guide
6-30
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Displaying Redundancy Configuration Information
To display the list of redundancy or fault-tolerance (FT) configurations configured for the current
context, perform the following task:
Command
Purpose
show running-config ft
Displays the list of redundancy or fault-tolerance (FT) configurations configured
for the current context. The ACE also displays configuration information for each
ft configuration listed.
Displaying Bulk Synchronization Command Failures on the Standby ACE
To display the configuration commands that fail on the standby ACE module during bulk
synchronization in a redundant configuration per context, perform the following task:
Command
Purpose
show ft config-error [context_name]
Displays the commands that fail on the standby ACE module during bulk
synchronization in a redundant configuration per context. If all commands
succeed on the standby ACE module, the command displays the following
message:
No bulk config apply errors
In the Admin context, the optional context_name argument is the name of a user
context. If you do not enter the argument, the command uses the Admin context.
In a user context, this argument is not available.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-31
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Displaying FT Group Information
To display redundancy statistics per context, perform the following task:
Command
Purpose
show ft group {{[group_id] {detail |
status | summary}} | brief}
Displays redundancy statistics per context.
The keywords, arguments, and options are:
•
group group_id—Displays FT group statistics for the specified FT group.
In the Admin context, this keyword displays statistics for all FT groups in
the ACE. Also, in the Admin context, you can specify an FT group number
to display statistics for an individual group. In a user context, this keyword
displays statistics only for the FT group to which the user context belongs.
•
detail—Displays detailed information for all FT groups or the specified FT
group. The detail keyword includes the status of autosync and whether it is
disabled or enabled for both the running-config and the startup-config.
•
status—Displays the current operating status for all FT groups or the
specified FT group.
•
summary—Displays summary information for all FT groups or the
specified FT group.
•
brief—Displays the group ID, local state, peer state, context name, and
context ID of all the FT groups that are configured in the ACE.
Cisco Application Control Engine Module Administration Guide
6-32
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Table 6-2 describes the fields in the show ft group command output.
Table 6-2
Field Descriptions for the show ft group Command Output
Field
Description
FT Group
FT group identifier.
No. of Contexts
Number of contexts associated with the FT group.
Context Name
Name of the context associated with the FT group.
Context ID
Identifier of the context associated with the FT group.
Configured Status
Configured state of the FT group. Possible states are the in-service or out-of-service states.
Maintenance Mode
Current maintenance mode of the local context in an FT group. Applications can turn on
maintenance mode when there is an inability to communicate with the peer, license mismatches, too
many application errors, and so on. Possible states are:
My State
•
MAINT_MODE_OFF—Maintenance mode is turned off.
•
MAINT_MODE_PARTIAL— All standby contexts transition to the
FSM_FT_STATE_STANDBY_COLD state (see the “My State” field description). The ACE
enters this mode if configuration synchronization fails.
•
MAINT_MODE_FULL—All contexts on the ACE become nonredundant causing their peer
contexts to become active. The ACE enters this mode just before you reboot the module and is
used primarily when you upgrade the ACE software.
State of the FT group member in the local ACE. Possible states are:
•
FSM_FT_STATE_INIT—Configuration for the FT group exists but the group is not in service.
This is the initial state for each member (local and peer) of an FT group.
•
FSM_FT_STATE_ELECT—When you configure the inservice command for an FT group, the
local group member enters this state. Through the election process, the local context negotiates
with its peer context in the FT group to determine their states. One member enters the ACTIVE
state and the other member enters the STANDBY_CONFIG state.
•
FSM_FT_STATE_ACTIVE—Local member of the FT group is active and processing flows.
•
FSM_FT_STATE_STANDBY_COLD—Either the FT VLAN is down, but the peer device is
still alive, or the configuration or application state synchronization failed. When a context is in
this state and a switchover occurs, the transition to the ACTIVE state is stateless.
•
FSM_FT_STATE_STANDBY_CONFIG—Local standby context is waiting to receive
configuration information from its active peer context in the FT group. The active peer context
receives a notification to send a snapshot of its running-configuration file to the local standby
context.
•
FSM_FT_STATE_STANDBY_BULK—Local standby context is waiting to receive state
information from its active peer context. The active peer context receives a notification to send
a snapshot of the current state information for all applications to the standby context.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-33
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Field Descriptions for the show ft group Command Output (continued)
Table 6-2
Field
Description
My State (Cont.)
•
FSM_FT_STATE_STANDBY_HOT—Local standby context has all the state information it
needs to statefully assume the active state if a switchover occurs.
•
FSM_FT_STATE_STANDBY_WARM—State used when 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.
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 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.
My Config Priority
Priority configured on the FT group in the local ACE.
My Net Priority
Priority of the FT group equal to the configured priority minus the priority of the FT tracking
failures if any.
My Preempt
Preemption value of the FT group in the local ACE. Possible values are Enabled or Disabled.
Peer State
State of the FT group in the remote ACE. For possible state values, see the “My State” field
description.
Peer Config Priority
Priority configured for the FT group in the remote ACE.
Peer Net Priority
Priority of the FT group in the remote ACE computed from the configured priority and the priority
of the FT tracking failures.
Peer Preempt
Preemption value of the FT group in the remote ACE. Possible values are Enabled or Disabled.
Peer ID
FT peer identifier.
Last State Change Time Time and date that the peer last changed from the active to standby state, or standby to active state.
Running Cfg Sync
Enabled
Configured state of config sync for the running-config. Possible values are Enabled or Disabled.
Running Cfg Sync
Status
Current status of config sync for the running-config. For example, Running configuration sync has
completed.
Startup Cfg Sync
Enabled
Configured state of config sync for the startup-config. Possible states are Enabled or Disabled.
Startup Cfg Sync Status Current status of config sync for the startup-config. For example, Startup configuration sync is
disabled.
Bulk Sync Done for
ARP
Number of “bulk synchronization done” messages received on the standby ACE during state
synchronization from the ARP module in the control plane.
Bulk Sync Done for LB Number of “bulk synchronization done” messages received on the standby ACE during state
synchronization from the load balancer (LB) module in the data plane.
Bulk Sync Done for
ICM
Number of “bulk synchronization done” messages received on the standby ACE during state
synchronization from the ICM input connection manager module in the data plane.
Cisco Application Control Engine Module Administration Guide
6-34
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Displaying the Redundancy Internal Software History
To display the redundancy internal software history, perform the following task:
Command
Purpose
show ft history {cfg_cntlr | ha_dp_mgr |
ha_mgr}
Displays the redundancy internal software history.
The keywords are:
•
cfg_cntlr—Displays the configuration controller debug log
•
ha_dp_mgr—Displays the high availability (HA) dataplane manager
debug log
•
ha_mgr—Displays the HA manager debug log
Displaying the IDMAP Table
This section describes how to display the IDMAP table. The IDMAP table contains a list of the local
ACE to peer (standby) ACE ID mappings for each of the seven object types in the ACE. The local ID
and the peer ID for each object type may or may not be the same, but the mappings (local ID to peer ID)
should be the same on both the active ACE and the standby ACE. The ACE uses these mappings for
configuration synchronization and state replication.
To display the IDMAP table, perform the following task:
Command
Purpose
show ft idmap
Displays the IDMAP table.
Table 6-3 lists the IDMAP table object types available in the ACE.
Table 6-3
ACE Object Types in the IDMAP Table
Object Type
Object Name
0
REAL ID
1
RSERVER ID
2
SERVERFARM ID
3
POLICY ID
4
STICKY GROUP ID
5
IF ID
6
CONTEXT ID
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-35
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Displaying Memory Statistics
To display redundancy statistics per context, perform the following task:
Command
Purpose
show ft memory [detail]
Displays redundancy statistics per context.
The optional detail keyword displays detailed HA manager memory statistics in the
Admin context only.
Displaying Peer Information
To display peer information, perform the following task:
Command
Purpose
show ft peer peer_id {detail | status |
summary}
Displays redundancy statistics per context.
The keywords and arguments are:
•
peer_id—Unique identifier of the remote peer
•
detail—Displays detailed peer information
•
status—Displays the current operating status of the peer
•
summary—Displays summary peer information
Table 6-4 describes the fields in the show ft peer command output.
Table 6-4
Field Descriptions for the show ft peer Command Output
Field
Description
Peer ID
Identifier of the remote context in the FT group.
State
Current state of the peer. Possible states are:
•
FSM_PEER_STATE_INIT—Initial state of the peer after you configure it.
•
FSM_PEER_STATE_MY_IPADDR—Local ACE IP address is missing. Waiting for the local IP
address to be configured.
•
FSM_PEER_STATE_PEER_IPADDR—Peer IP address is missing. Waiting for the peer IP address to
be configured.
•
FSM_PEER_STATE_START_HB—Peer configuration is complete. Starting the heartbeat to see if
there is a peer device.
Cisco Application Control Engine Module Administration Guide
6-36
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Table 6-4
Field Descriptions for the show ft peer Command Output (continued)
Field
State (continued)
Maintenance
Mode
Description
•
FSM_PEER_STATE_TL_SETUP—Heartbeat has detected the presence of the peer device.
Redundancy is in the process of establishing a TCP connection to the peer. This connection carries
configuration data, application state information, and redundancy protocol packets.
•
FSM_PEER_STATE_SRG_CHECK—Checking for software version compatibility with the peer
device.
•
FSM_PEER_STATE_LIC_CHECK—Checking for license compatibility with the peer device.
•
FSM_PEER_STATE_COMPATIBLE—Version and license checks indicate that the peer is
compatible for redundancy.
•
FSM_PEER_STATE_FT_VLAN_DOWN—FT VLAN is down, but, through the query interface, the
local ACE has determined that the peer is still alive.
•
FSM_PEER_STATE_DOWN—Peer device is down.
•
FSM_PEER_STATE_ERROR—Status of whether an error has occurred with the peer. Possible errors
are version mismatch, license mismatch, or failure to establish a TCP connection to the peer. A syslog
message appears with more detailed information.
Current maintenance mode of the peer context in an FT group. Applications can turn on maintenance mode
when there is an inability to communicate with the peer, license mismatches, too many application errors,
and so on. Possible states are:
•
MAINT_MODE_OFF—Maintenance mode is turned off.
•
MAINT_MODE_PARTIAL— All standby contexts transition to the STANDBY_COLD state. The
ACE enters this mode if configuration synchronization fails.
•
MAINT_MODE_FULL—All contexts on the ACE become nonredundant causing their peer contexts
to become active. The ACE enters this mode just before you reboot the module and is used primarily
when you upgrade the ACE software.
FT VLAN
Identifier of the interface that is configured as the FT VLAN or Not Configured.
FT VLAN IF
State
Current status of the FT VLAN interface. Possible states are UP or DOWN.
My IP Addr
IP address of the local ACE.
Peer IP Addr
IP address of the peer ACE.
Query VLAN
Identifier of the interface that is configured as the query VLAN or Not Configured.
Query VLAN IF
State
Current status of the Query VLAN interface (if configured). Possible states are UP or DOWN.
Peer Query IP
Addr
IP address of the query interface used to obtain the state of the peer’s health when the FT VLAN is down.
Heartbeat
interval
Time in seconds that the ACE waits between sending heartbeat packets.
Heartbeat Count
Number of missed heartbeats that an ACE must detect before declaring the peer down.
Tx Packets
Total number of packets that the local ACE sent to the peer.
Tx Bytes
Total number of bytes that the local ACE sent to the peer.
Rx Packets
Total number of packets that the local ACE received from the peer.
Rx Bytes
Total number of bytes that the local ACE received from the peer.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-37
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Table 6-4
Field Descriptions for the show ft peer Command Output (continued)
Field
Description
Rx Error Bytes
Total number of error bytes that the local ACE received from the peer.
Tx Keepalive
Packets
Total number of keepalive packets that the local ACE sent to the peer.
Rx Keepalive
Packets
Total number of keepalive packets that the local ACE received from the peer.
TL_CLOSE
Count
Number of Transport Layer close events (TL_CLOSE) received on the redundant TCP connection from
the TL driver.
FT_VLAN_
DOWN Count
Number of times that the FT VLAN was unavailable.
PEER_DOWN
Count
Number of times that the remote ACE was unavailable.
SRG
Compatibility
Status of whether the software version of the local ACE and the software version of the peer ACE are
compatible. Possible states are the INIT, COMPATIBLE, or INCOMPATIBLE state.
License
Compatibility
Status of whether the license of the local ACE and the license of the peer ACE are compatible. Possible
states are the INIT, COMPATIBLE, or INCOMPATIBLE state.
FT Groups
Number of FT groups.
Displaying FT Statistics
To display peer information, perform the following task:
Command
Purpose
show ft stats group_id
Displays peer information.
The group_id argument displays additional load-balancing statistics (LB statistics)
for the specified group.
Table 6-5 describes the fields in the show ft stats command output.
Table 6-5
Field Descriptions for the show ft stats Command Output
Field
Description
HA Heartbeat Statistics
Number of Heartbeats Sent
Total number of heartbeat packets sent by the local ACE.
Number of Heartbeats
Received
Total number of heartbeat packets received by the local ACE.
Number of Heartbeats
Missed
Total number of heartbeat intervals that transpired with no heartbeats received.
Number of Unidirectional
HBs Received
Number of heartbeats (HBs) received by the local peer that indicate the remote peer is not
receiving HBs. The remote peer is sending heartbeats, but not receiving any.
Note
Both peer modules send heartbeat packets and each packet indicates whether the other
peer has been receiving heartbeats.
Cisco Application Control Engine Module Administration Guide
6-38
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Table 6-5
Field Descriptions for the show ft stats Command Output (continued)
Field
Description
Number of HB Timeout
Mismatches
Number of times that the local peer received a heartbeat (HB) from the remote peer with a
mismatched heartbeat interval. If the heartbeat intervals do not match, a peer adjusts its
interval to the lower of the two intervals.
Note
The heartbeat interval should be the same on both peer modules. Each heartbeat packet
contains the configured interval in the packet. When a peer receives a heartbeat packet,
it checks to see if the interval in the heartbeat packet matches the interval configured
locally.
Num of Peer Up Events Sent Number of times that the local ACE sent a Peer Up message to the remote ACE.
Num of Peer Down Events
Sent
Number of times that the local ACE sent a Peer Down message to the remote ACE.
Successive HBs Miss
Intervals Counter
Number of successive heartbeat misses detected by the heartbeat module.
Successive Uni HBs Recv
Counter
Number of successive unidirectional heartbeats received by the heartbeat module.
LB Stats for FT Group N
Send-side Stats
Number of Sticky
Entries Shared
Number of sticky database entries that the local ACE sent to the remote ACE.
Number of Replication
Packets Sent
Number of packets that contain replication information that the local ACE sent to the remote
ACE.
Number of Send Failures Number of times that the local ACE attempted to send packets to the remote ACE but failed.
Receive-side Stats
Number of Sticky
Entries Dropped
Number of sticky database entries that the remote ACE sent to the local ACE, but the local
ACE discarded them.
Number of Replication
Packets Received
Number of packets that contain replication information that the local ACE received from the
remote ACE.
Number of Receive
Failures
Number of times that the remote ACE sent packets to the local ACE, but the local ACE failed
to receive them.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-39
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Displaying FT Tracking Information
To display tracking information, perform the following task:
Command
Purpose
show ft track {detail | status |
summary}
Displays tracking information.
The keywords are:
•
detail—Displays detailed tracking information
•
status—Displays the current operating status of the peer plus additional
information
•
summary—Displays summary peer information
Table 6-6 describes the fields in the show ft track command output.
Table 6-6
Field Descriptions for the show ft track Command Output
Field
Description
FT Group
FT group identifier.
Status
Configured state of the FT group. Possible states are the in-service or out-of-service state.
Maintenance Mode
Current maintenance mode of the local context in an FT group. Applications can turn on maintenance
mode when there is an inability to communicate with the peer, license mismatches, too many
application errors, and so on. Possible states are:
•
MAINT_MODE_OFF—Maintenance mode is turned off.
•
MAINT_MODE_PARTIAL— All standby contexts transition to the
FSM_FT_STATE_STANDBY_COLD state (see the “My State” field description). The ACE
enters this mode if configuration synchronization fails.
•
MAINT_MODE_FULL—All contexts on the ACE become nonredundant causing their peer
contexts to become active. The ACE enters this mode just before you reboot the module and is
used primarily when you upgrade the ACE software.
Cisco Application Control Engine Module Administration Guide
6-40
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Table 6-6
Field Descriptions for the show ft track Command Output (continued)
Field
Description
My State
State of the FT group member in the local ACE. Possible states are:
•
FSM_FT_STATE_INIT—Initial state for each member (local and peer) of an FT group. The
configuration for the FT group exists but the group is not yet in service.
•
FSM_FT_STATE_ELECT—State that the local group member enters when you configure the
inservice command for an FT group. Through the election process, the local context negotiates
with its peer context in the FT group to determine their states. One member enters the ACTIVE
state and the other member enters the STANDBY_CONFIG state.
•
FSM_FT_STATE_ACTIVE—State that indicates that the local member of the FT group is active
and processing flows.
•
FSM_FT_STATE_STANDBY_COLD—State that indicates if either the FT VLAN is down but
the peer device is still alive, or the configuration or application state synchronization failed.
When a context is in this state and a switchover occurs, the transition to the ACTIVE state is
stateless.
•
FSM_FT_STATE_STANDBY_CONFIG—State that indicates that the local standby context is
waiting to receive configuration information from its active peer context in the FT group. The
active peer context receives a notification to send a snapshot of its running-configuration file to
the local standby context.
•
FSM_FT_STATE_STANDBY_BULK—State that indicates that the local standby context is
waiting to receive state information from its active peer context. The active peer context receives
a notification to send a snapshot of the current state information for all applications to the
standby context.
•
FSM_FT_STATE_STANDBY_HOT—State that indicates that the local standby context has all
the state information it needs to statefully assume the active state if a switchover occurs.
•
FSM_FT_STATE_STANDBY_WARM—State used when 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.
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 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.
My Config Priority
Priority configured on the FT group in the local ACE.
My Net Priority
Priority of the FT group equal to the configured priority minus the priority of the FT tracking process
failures, if any.
My Preempt
Preemption value of the FT group in the local ACE. Possible values are Enabled or Disabled.
Context Name
Name of the context that is associated with the FT group.
Context ID
Identifier of the context that is associated with the FT group.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-41
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Table 6-6
Field Descriptions for the show ft track Command Output (continued)
Field
Description
Track Type
Type of object being tracked. Possible values are TRACK_HOST, TRACK_HSRP, or
TRACK_INTERFACE.
HSRP Group name
Identifier of the HSRP group that is configured on the Catalyst 6500 series switch that you are
tracking.
State
State of the tracking process. Possible values are TRACK_UP or TRACK_DOWN.
Priority
Priority of the tracking process.
Transitions
Number of times that the active member of the FT group switched over to the standby member.
Probe Count
Number of probes associated with a TRACK_HOST process.
Probes Down
Number of failed probes.
Clearing Redundancy Statistics
To clear redundancy statistics, use the commands described in the following sections. You must enter all
commands in this section in the Admin context unless otherwise indicated.
This section contains the following topics:
•
Clearing Transport-Layer Statistics
•
Clearing Heartbeat Statistics
•
Clearing Tracking-Related Statistics
•
Clearing All Redundancy Statistics
•
Clearing the Redundancy History
Restrictions
If you configure redundancy on the ACE, then you must explicitly clear statistics on both the active and
the standby ACEs. Clearing statistics on the active module only does not clear the statistics on the
standby module.
Clearing Transport-Layer Statistics
To clear all transport layer-related counters that the ACE displays as part of the show ft peer detail
command output, perform the following task:
Cisco Application Control Engine Module Administration Guide
6-42
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Displaying or Clearing Redundancy Information
Command
Purpose
clear ft ha-stats
Clears all transport layer-related counters that the ACE displays as part of the show
ft peer detail command output.
This command clears the following transport-layer counters:
•
Tx Packets
•
Tx Bytes
•
Rx Packets
•
Rx Bytes
•
Rx Error Bytes
For an explanation of these fields, see the “Displaying Peer Information” section.
Clearing Heartbeat Statistics
To clear all heartbeat-related statistics, perform the following task:
Command
Purpose
clear ft hb-stats
Clears all heartbeat-related statistics.
When you enter this command for the first time, the ACE sets the heartbeat
statistics counters to zero and stores a copy of the latest statistics locally. From that
point on, when you enter the show ft hb-stats command, the ACE displays the
difference between the statistics that are stored locally and the current statistics.
Clearing Tracking-Related Statistics
To clear tracking-related statistics for the Admin FT group only, a user context FT group only, or for all
FT groups that are configured in the ACE, perform the following task:
Command
Purpose
clear ft track-stats [all]
Clears tracking-related statistics for the Admin FT group only, a user context FT
group only, or for all FT groups that are configured in the ACE.
Use the optional all keyword in the Admin context only to clear tracking statistics
for all FT groups that are configured in the ACE. If you enter this command in the
Admin context without the all keyword, it clears the tracking statistics only for the
FT group associated with the Admin context. In a user context, you cannot enter
the all keyword, so you can clear the tracking statistics only for the FT group
associated with the user context.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-43
Chapter 6
Configuring Redundant ACEs
Configuration Example of Redundancy
Clearing All Redundancy Statistics
To clear all redundancy statistics, including all TL, heartbeat, and tracking counters, perform the
following task in the Admin context only:
Command
Purpose
clear ft all
Clears all redundancy statistics, including all TL, heartbeat, and tracking
counters.
This command does not affect the redundancy history. To clear the redundancy
history, use the clear ft history command. For details, see the “Clearing the
Redundancy History” section.
Clearing the Redundancy History
To clear the redundancy history, perform the following task in the Admin context only:
Command
Purpose
clear ft history {cfg_cntlr | ha_dp_mgr |
ha_mgr}
The keywords are as follows:
•
cfg_cntlr—Clears the Configuration Controller debug log
•
ha_dp_mgr—Clears the HA (redundancy) dataplane manager debug log
•
ha_mgr—Clears the HA (redundancy) manager debug log
Configuration Example of Redundancy
This section shows an example redundancy configuration and illustrates a running-configuration that
defines fault tolerance (FT) for a single ACE module operating in a redundancy configuration. You must
configure a maximum of two ACE modules (peers) for redundancy to fail over from the active module
to the standby module.
Note
All FT parameters are configured in the Admin context.
This configuration addresses the following redundancy components:
•
A dedicated FT VLAN for communication between the members of an FT group. You must
configure this same VLAN on both peer modules.
•
An FT peer definition.
•
An FT group that is associated with the Admin context.
•
A critical tracking and failure detection process for an interface.
The redundancy configuration appears in bold in the example.
hostname ACE_Module_1
access-list ACL1 line 10 extended permit ip any any
Cisco Application Control Engine Module Administration Guide
6-44
OL-20814-01
Chapter 6
Configuring Redundant ACEs
Configuration Example of Redundancy
class-map
2 match
3 match
4 match
5 match
7 match
8 match
type management match-any L4_REMOTE-MGT_CLASS
protocol telnet any
protocol ssh any
protocol icmp any
protocol http any
protocol snmp any
protocol https any
policy-map type management first-match L4_REMOTE-MGT_POLICY
class L4_REMOTE-MGT_CLASS
permit
interface vlan 100
ip address 192.168.83.219 255.255.255.0
peer ip address 192.168.83.230 255.255.255.0
alias 192.168.83.200 255.255.255.0
access-group input ACL1
service-policy input L4_REMOTE-MGT_POLICY
no shutdown
ft interface vlan 200
ip address 192.168.1.1 255.255.255.0
peer ip address 192.168.1.2 255.255.255.0
no shutdown
ft peer 1
ft-interface vlan 200
heartbeat interval 300
heartbeat count 10
ft group 1
peer 1
priority 200
associate-context Admin
inservice
ft track interface TRACK_VLAN100
track-interface vlan 100
peer track-interface vlan 200
priority 50
peer priority 5
ip route 0.0.0.0 0.0.0.0 192.168.83.1
Cisco Application Control Engine Module Administration Guide
OL-20814-01
6-45
Chapter 6
Configuring Redundant ACEs
Configuration Example of Redundancy
Cisco Application Control Engine Module Administration Guide
6-46
OL-20814-01
CH A P T E R
7
Configuring SNMP
This chapter describes how to configure Simple Network Management Protocol (SNMP) to query the
Cisco Application Control Engine (ACE) module for Cisco Management Information Bases (MIBs) and
to send event notifications to a network management system (NMS).
This chapter contains the following major sections:
•
Information About SNMP
•
Default Settings for SNMP
•
Configuring SNMP
•
Displaying or Clearing SNMP and Service Policy Statistics
•
Example of an SNMP Configuration
Information About SNMP
SNMP is an application-layer protocol that facilitates the exchange of management information between
an NMS, SNMP agents, and managed devices such as the ACE. You can configure the ACE to send traps
(event notifications) to an NMS, or you can use the NMS to browse the MIBs that reside on the ACE.
The ACE contains an SNMP agent that provides support for network monitoring. The ACE supports
SNMP Version 1 (SNMPv1), SNMP Version 2c (SNMPv2c), and SNMP Version 3 (SNMPv3).
SNMPv1 and SNMPv2c use a community string match for authentication. Community strings provide a
weaker form of access control. SNMPv3 utilizes an SNMP user for authentication and provides
improved access control by using strong authentication. SNMPv3 should be utilized instead of SNMPv1
and SNMPv2c wherever possible.
SNMPv3 is an interoperable standards-based protocol for network management. SNMPv3 provides
secure access to devices by using a combination of authenticating and encrypting frames over the
network. The SNMPv3 provides the following security features:
•
Message integrity—Ensures that a packet has not been tampered with in-transit.
•
Authentication—Determines that the message is from a valid source.
•
Encryption—Scrambles the packet contents to prevent it from being seen by unauthorized sources.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-1
Chapter 7
Configuring SNMP
Information About SNMP
This section contains the following topics:
•
Managers and Agents
•
SNMP Manager and Agent Communication
•
SNMP Traps and Informs
•
SNMPv3 CLI User Management and AAA Integration
•
CLI and SNMP User Synchronization
•
Multiple String Index Guidelines
•
Supported MIBs and Notifications
Managers and Agents
SNMP uses software entities called managers and agents to manage network devices:
•
The manager monitors and controls all other SNMP-managed devices (network nodes) in the
network. At least one SNMP manager must be in a managed network. The manager is installed on
a workstation somewhere in the network.
•
An agent resides in a managed device (a network node). An agent is a specialized software module
that receives instructions from the SNMP manager and also sends management information back to
the SNMP manager as events occur. For example, an agent might report such data as the number of
bytes and packets in and out of the device or the number of broadcast messages sent and received.
There are many different SNMP management applications, but they all perform the same basic task.
These applications allow SNMP managers to communicate with agents to monitor, configure, and
receive alerts from the network devices.The ACE supports traps and SNMP get requests but does not
support SNMP set requests to configure values on the device. You can use any SNMP-compatible NMS
to monitor the ACE.
In SNMP, each variable is referred to as a managed object. A managed object is anything that an agent
can access and report back to the NMS. All managed objects are contained in the MIB, which is a
database of the managed objects called MIB objects. Each MIB object controls one specific function,
such as counting how many bytes are transmitted through an agent’s port. The MIB object consists of
MIB variables, which define the MIB object name, description, and default value.The ACE maintains a
database of values for each definition.
Browsing a MIB entails issuing an SNMP get request from the NMS. You can use any SNMPv3, MIB-II
compliant browser to receive SNMP traps and browse MIBs.
SNMP Manager and Agent Communication
The SNMP manager and the agent can communicate in several ways. The Protocol Data Unit (PDU) is
the message format that SNMP managers and agents use to send and receive information.
•
The SNMP manager can perform the following operations:
– Retrieve a value (a get operation) from an agent. The SNMP manager requests information from
the agent, such as the number of users logged on to the agent device, or the status of a critical
process on that device. The agent gets the value of the requested MIB object and sends the value
back to the manager (a get-response operation). The variable binding (varbind) is a list of MIB
objects that allows a request recipient to see what the originator wants to know. Variable
bindings are object identifiers (OID)=value pairs that make it easy for the NMS to identify the
information that it needs when the recipient fills the request and sends back a response.
Cisco Application Control Engine Module Administration Guide
7-2
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
– Retrieve the value immediately after the variable that you name (a get-next operation). A
get-next operation retrieves a group of values from a MIB by issuing a sequence of commands.
By performing a get-next operation, you do not need to know the exact MIB object instance that
you are looking for; the SNMP manager takes the variable that you name and then uses a
sequential search to find the desired variables.
– Retrieve a number of values (a get-bulk operation). The get-bulk operation retrieves large
blocks of data, such as multiple rows in a table, which would otherwise require the transmission
of many small blocks of data.The SNMP manager performs a number of get-next operations
that you specify.
•
An agent can send an unsolicited message to the SNMP manager at any time if a significant,
predetermined event takes place on the agent. This message is called an event notification. SNMP
event notifications (traps or inform requests) are included in many MIBs and help to alleviate the
need for the NMS to frequently poll (gather information through a get operation) the managed
devices. For details on MIB objects and SNMP notifications supported by the ACE, see the
“Supported MIBs and Notifications” section.
SNMP Traps and Informs
You can configure the ACE to send notifications (such as traps or inform requests) to SNMP managers
when particular events occur. In some instances, traps can be unreliable because the receiver does not
send any acknowledgment when it receives a trap and the sender cannot determine if the trap was
received. However, an SNMP manager that receives inform requests acknowledges the message with an
SNMP Response PDU. If the sender never receives a Response, the inform request is usually
retransmitted. Inform requests are more likely to reach their intended destination.
Notifications may contain a list of MIB variable bindings that clarify the status being relayed by the
notification. The list of variable bindings associated with a notification is included in the notification
definition in the MIB. For standard MIBs, Cisco has enhanced some notifications with additional
variable bindings that further clarify the cause of the notification.
Note
The clogOriginID and clogOriginIDType variable bindings appended with each notification can be used
by the NMS application to uniquely identify the device originating the trap. You can configure the values
for clogOriginID and clogOriginIDType varbind to uniquely identify the device by using the logging
device-id configuration mode command. For details on the logging device-id command, see the Cisco
Application Control Engine Module System Message Guide.
Use the SNMP-TARGET-MIB to obtain more information on trap destinations and inform requests.
For details on SNMP notifications supported by the ACE, see the “Supported MIBs and Notifications”
section.
SNMPv3 CLI User Management and AAA Integration
The ACE implements RFC 3414 and RFC 3415, including the SMNPv3 User-based Security Model
(USM) for message security and role-based access control. SNMP v3 user management can be
centralized at the authentication and accounting (AAA) server level (as described in the Cisco
Application Control Engine Module Security Configuration Guide). This centralized user management
allows the ACE SNMP agent to use the user authentication service of an AAA server. After user
authentication is verified, the SNMP protocol data units (PDUs) further processed. The AAA server is
also used to store user group names. SNMP uses the group names to apply the user access and role policy
that is locally available in the ACE.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-3
Chapter 7
Configuring SNMP
Information About SNMP
CLI and SNMP User Synchronization
Any configuration changes to the user group, role, or password, results in the database synchronization
for both SNMP and AAA.
Users are synchronized as follows:
•
If you delete a user by using the no username command, the user is also deleted from both SNMP
and the CLI. However, if you delete a user by using the no snmp-server user command, the user is
deleted only from SNMP and not from the CLI.
•
User-role mapping changes are synchronized in SNMP and the CLI.
Note
When you specify a password in a localized key or encrypted format for security encryption, the
password is not synchronized.
•
The password specified in the username command is synchronized as the auth and priv passwords
for the SNMP user.
•
Existing SNMP users can continue to retain the auth and priv information without any changes.
•
If you create a new user that is not present in the SNMP database by using the username command
without a password, the SNMP user is created with the noAuthNoPriv security level.
For information about creating a CLI user by using the username command, see the Cisco Application
Control Engine Module Virtualization Configuration Guide. To create an SNMP user by using the
snmp-server user command, see the “Configuring SNMP Users” section.
Multiple String Index Guidelines
If any SNMP MIB table has more than one string index that contains more than 48 characters, the index
may not show up in the MIB table when you perform an SNMP walk. According to SNMP standards,
SNMP requests, responses, or traps cannot have more than 128 subidentifiers. The following list
contains object names:
•
Context name
•
Real server name
•
Server farm name
•
Probe name
•
HTTP header name
•
ACL name
•
Class map name
•
Policy map name
•
Resource class name
Table 7-1 identifies a list of tables that have more than one string index.
Cisco Application Control Engine Module Administration Guide
7-4
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-1
SNMP MIB Tables with More Than One String Index
MIB Name
Table
String Indices
CISCO-ENHANCED- SLB-MIB.my
cesRserverProbeTable
cesRserverName,
cesRserverProbeName
CISCO-ENHANCED-SLB-MIB.my
cesServerFarmRserverTable
slbServerFarmName,
cesRserverName
CISCO-SLB-EXT-MIB.my
cslbxServerFarmProbeFarmName
cslbxServerFarmProbeFarmName,
cslbxServerFarmProbeTableName
CISCO-SLB-HEALTH-MON-MIB.my
cslbxProbeHeaderCfgTable
cslbxProbeHeaderProbeName,
cslbxProbeHeaderFieldName
Supported MIBs and Notifications
Table 7-2 identifies the supported MIBs for the ACE.
Table 7-2
SNMP MIB Support
MIB Support
Capability MIB
Description
Supervisor Module MIBs
CISCO-ENTITY-FRUCONTROL-MIB
CISCO-ENTITYFRU-CONTROLCAPABILITY
Acts as an extension to the ENTITY-MIB. It monitors the operational state
of the ACE. The CISCO-ENTITY-FRU-CONTROL-MIB is supported only
in the Admin context.
CISCO-ENTITYVENDORTYPE-OIDMIB
N/A
Defines the object identifiers (OIDs) assigned to various ACE components.
The OIDs in this MIB are used by the entPhysicalTable of the
ENTITY-MIB as values for the entPhysicalVendorType field in the
entPhysicalTable. Each OID uniquely identifies a type of physical entity,
such as a chassis, line cards, or port adapters. The following list contains
the entPhysicalVendorType OID values:
Product Name (PID) entPhysicalVendorType
ACE10-6500-K9
ACE20-MOD-K9
Inlet Temperature
Outlet Temperature
cevCat6kAce10K9
cevCat6kAce10K9
(cevModuleCat6000Type120)
cevSensorModuleInletTemp
(cevSensor 36)
cevSensorModuleOutletTemp
(cevSensor 35)
Other device
temperature sensors cevSensorModuleDeviceTemp
(cevSensor 31)
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-5
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
Description
ENTITY-MIB
CISCO-ENTITYCAPABILITY
Provides basic management and identification of physical and logical
entities within a network device. Software support for the ENTITY-MIB
focuses on the physical entities within the ACE. This MIB provides details
on each module, power supply, and fan tray within a switch chassis. It gives
enough information to correctly map the containment of these entities
within the ACE, creating a chassis view.
The ENTITY-MIB is supported only in the Admin context.
The ENTITY-MIB is described in RFC 4133.
ENTITY-SENSORMIB
CISCO-ENTITYSENSOR-RFCCAPABILITY
Contains a single group called the entitySensorValueGroup, which allows
objects to convey the current value and status of a physical sensor. The
entitySensorValueGroup contains a single table, called the
entPhySensorTable, which provides a few read-only objects that identify
the type of data units, scaling factor, precision, current value, and
operational status of the sensor.
The ENTITY-SENSOR-MIB is supported only in the Admin context.
The ENTITY-SENSOR-MIB is described in RFC 3433.
Cisco Application Control Engine Module Administration Guide
7-6
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
Description
SNMPv3 Agent MIBs
SNMP-COMMUNITY- CISCO-SNMPMIB
COMMUNITYCAPABILITY
Contains objects for mapping between community strings and
version-independent SNMP message parameters. In addition, this MIB
provides a mechanism for performing source address validation on
incoming requests and for selecting community strings based on target
addresses for outgoing notifications.
The SNMP-COMMUNITY-MIB is described in RFC 3584.
Note
SNMP-FRAMEWORK
-MIB
SNMP-MPD-MIB
SNMP communities are applicable only for SNMPv1 and
SNMPv2c. SNMPv3 requires user configuration information such
as specifying the role group that the user belongs to, authentication
parameters for the user, the authentication password, and message
encryption parameters.
CISCO-SNMPFRAMEWORKCAPABILITY
Defines the elements of SNMP Management Frameworks, including an
SNMP engine and Access Control Subsystem.
CISCO-SNMPMPDCAPABILITY
Describes the Message Processing Subsystem and Dispatcher for SNMP.
The Dispatcher in the SNMP engine sends and receives SNMP messages. It
also dispatches SNMP PDUs to SNMP applications. A Message Processing
Model processes an SNMP version-specific message and coordinates the
interaction with the Security Subsystem to ensure that proper security is
applied to the SNMP message being handled.
The SNMP-FRAMEWORK-MIB is described in RFC 3411.
The SNMP-MPD-MIB is described in RFC 3412.
SNMPNOTIFICATION-MIB
SNMP-TARGET-MIB
CISCO-SNMPNOTIFICATIONCAPABILITY
Defines MIB objects that provide a mechanism to remotely configure the
parameters used by an SNMP entity for the generation of notifications.
CISCO-SNMPTARGETCAPABILITY
Contains a table for the destination information and SNMP parameters in
the management target message.Multiple transport end points may be
associated with a particular set of SNMP parameters, or a particular
transport end point may be associated with several sets of SNMP
parameters.
The SNMP-NOTIFICATION-MIB is described in RFC 3413.
The SNMP-TARGET-MIB is described in RFC 3413.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-7
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
MIB Support
SNMP MIB Support (continued)
Capability MIB
Description
SNMP-USER-BASED- CISCO-SNMP-USM- Provides management information definitions for the User-based Security
SM-MIB
Model (USM) for SMNPv3. The SNMPv3 architecture introduces the
CAPABILITY
User-based Security Model (USM) for message security.
The USM module decrypts incoming messages. The module then verifies
the authentication data and creates the PDUs. For outgoing messages, the
USM module encrypts PDUs and generates the authentication data. The
module then passes the PDUs to the message processor, which then invokes
the dispatcher.
The USM module's implementation of the SNMP-USER-BASED-SM-MIB
enables the SNMP manager to issue commands to manage users and
security keys. The MIB also enables the agent to ensure that a requesting
user exists and has the proper authentication information. When
authentication is done, the request is carried out by the agent.
The SNMP-USER-BASED-SM-MIB is described in RFC 3414.
Note
SNMP-VIEW-BASED- CISCO-SNMPACM-MIB
VACMCAPABILITY
User configuration is applicable only for SNMPv3; SNMPv1 and
SNMPv2c use a community string match for user authentication.
Provides the View-based Access Control Model (VACM) for SNMPv3. The
SNMPv3 architecture introduces VACM for access control.
The SNMP-VIEW-BASED-ACM-MIB specifies objects that are needed to
control access to all MIB data that is accessible through the SNMP agent.
Upon initialization, the VACM module registers as the access control
module with the agent infrastructure. The VACM module implements
access control checks according to several parameters that are derived from
the SNMP message.
The SNMP-VIEW-BASED-ACM-MIB is described in RFC 3415.
Other MIBs
CISCO-AAA-SERVER CISCO-AAA-EXT-MIB
SERVER-EXTCAPABILITY
Acts as an extension to CISCO-AAA-SERVER-MIB. It enhances the
casConfigTable of the CISCO-AAA-SERVER-MIB to include other types
of server addresses. The CISCO-AAA-SERVER-EXT-MIB manages the
following configuration functions:
•
Generic configurations as applied on the authentication and accounting
module.
•
Configuration settings (settings for all the AAA servers instrumented
in one instance of this MIB).
•
AAA server group configuration.
•
Application-to-AAA function-to-server group mapping configuration.
Cisco Application Control Engine Module Administration Guide
7-8
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
CISCO-AAA-SERVER CISCO-AAA-MIB
SERVERCAPABILITY
Description
Provides configuration and statistics that reflect the state of an AAA server
operation within the device and AAA communications with external
servers. The CISCO-AAA-SERVER-MIB provides the following
information:
•
A table for configuring AAA servers.
•
Identities of external AAA servers.
•
Statistics for each AAA function.
•
Status of servers that provide AAA functions.
A server is defined as a logical entity that provides any of the AAA
functions. The ACE can use a Remote Access Dial-In User Service
(RADIUS), Terminal Access Controller Access Control System Plus
(TACACS+), or Lightweight Directory Access Protocol (v3) (LDAP)
protocols for remote authentication and designation of access rights.
CISCO-ENHANCEDSLB-MIB
CISCOENHANCED-SLBCAPABILITY
Extends the tables that are defined in CISCO-SLB-MIB and
CISCO-SLB-EXT-MIB and supports the following server load-balancing
functions:
•
A real server configuration with a real server that is identified by a
name.
•
The current state of the real server (for example, OPERATIONAL,
OUT-OF-SERVICE, PROBE-FAILED).
•
A real server configuration in a server farm.
•
A health probe configuration in a real server and server farm.
•
Health probe statistics for each real server.
•
A sticky configuration for an HTTP header, an HTTP cookie and client
IP address, and Secure Socket Layer (SSL). The slbEntity Index used
in the table is the slot number of the ACE.
The cesRserverProbeTable table in the CISCO-ENHANCED-SLB-MIB
provides details about the real server probe statistics available in the show
probe detail command output.
The cesServerFarmRserverTable and cesRserverTable tables in the
CISCO-ENHANCED-SLB-MIB provide details about the data available in
the show rserver command output.
CISCO-IFEXTENSION-MIB
CISCO-IFEXTENSIONCAPABILITY
Provides a table that returns ifName to ifIndex mapping to assign the
ifIndex to interfaces.
The CISCO-IF-EXTENSION-MIB is described in RFC 2863.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-9
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
MIB Support
SNMP MIB Support (continued)
Capability MIB
CISCO-IP-PROTOCOL CISCO-IP-FILTER-MIB
PROTOCOLFILTERCAPABILITY
Description
Manages information to support packet filtering on IP protocols (RFC 791).
The cippfIpProfileTable allows users to create, delete, and get information
about filter profiles. Filter profiles are uniquely identified by the profile
names. Filter profiles can be either simple or extended usage types. The
usage type cannot be changed once it has been created. The
cippfIfIpProfileTable applies the filtering profiles to device interfaces that
run IP. A filter profile can be applied to multiple interfaces.
The cippfIpFilterTable contains ordered lists of IP filters for all filtering
profiles. Filters and profiles are related if they have the same filter profile
name. Filters can be created only if their associated filter profiles already
exist in the cippfIpProfileTable. Filters of the same profile name belong to
a common profile.
The interface-based cippfIfIpProfileTable can be configured with
information that is independent of the other tables. However, if the profile
name in this table matches any profile name in the cippfIpProfileTable and
the profile name of any filter entry in the cippfIpFilterTable, the profile is
active and the filter entry is applied to IP traffic that passes through the
attached device interfaces. Any change to the filters in the
cippfIpFilterTable or the profile in the cippfIpProfileTable affects all the
attached interfaces.
The IP protocol is described in RFC 791.
CISCO-L4L7MODULE CISCO-L4L7
MODULEREDUNDANCY-MIB REDUNDANCYCAPABILITY
Provides configuration information and statistic tables that reflect the
redundancy (or fault tolerance) between an active and a standby ACE
module. Each peer ACE can contain one or more fault-tolerant (FT) groups.
The CISCO-L4L7MODULE-REDUNDANCY-MIB provides redundancy
information such as: FT state, IP address, peer FT state, peer IP address,
software compatibility, license compatibility, number of groups to which a
peer belongs, and the number of heartbeat messages transmitted and
received.
This MIB also supports the following tables:
•
clrRedundancyInfoTable
•
clrPeerInfoTable,
•
clrHAStatsTable
The CISCO-L4L7MODULE-REDUNDANCY-MIB provides details about
the fault tolerance statistics available in the show ft peer, show ft group
detail, and show ft stats command output.
Cisco Application Control Engine Module Administration Guide
7-10
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
Description
CISCOL4L7RESOURCELIMIT-MIB
CISCOL4L7MODULERESOURCELIMITCAPABILITY
Manages resource classes. The resources referenced in this MIB are in
addition to the resource information that is available in other MIBs. This
MIB applies to Layer 4 through 7 modules that support managing resource
limits using a centralized approach.
CISCOMODULEVIRTUALIZATIONCAPABILITY
Provides a way to create and manage ACE user contexts (also referred as
virtual contexts). A user context is a logical partition of a physical device
(the ACE). A user context provides different service types that can be
managed independently. Each user context is an independent entity with its
own configuration. A user-created context supports most of the options that
you can configure in the Admin context (the default ACE context). Each
context can have a separate management IP address that allows you to
establish a remote connection to the ACE with the Secure Shell (SSH) or
Telnet protocols and send other requests (such as SNMP or FTP).
CISCO-MODULEVIRTUALIZATIONMIB
The ciscoL4L7ResourceLimitTable, ciscoL4L7ResourceRateLimitTable,
and ciscoL4L7ResourceUsageSummaryTable in the
CISCO-L4L7RESOURCE-LIMIT-MIB provide details about the Current,
Peak, and Denied statistics available in the show resource usage and show
resource usage summary command output.
This MIB contains tables that allow you to create or delete ACE user
contexts and assign interfaces and interface ranges to user contexts.
CISCO-PROCESSMIB
CISCO-PROCESSCAPABILITY
Displays memory and process CPU utilization on Cisco devices. This
information should be used only as an estimate. The value of
cpmCPUTotalPhysicalIndex will always be 1.
The displayed system processes information is at the CPU system level (the
total CPU usage) and is not on a per-context level.
CISCO-PRODUCTSMIB
N/A
Contains the OIDs that can be reported in the sysObjectID object in the
SNMPv2-MIB. The sysObjectID OID value is listed below:
Product Name (PID) sysObjectID
ACE10-6500-K9/
ACE20-MOD-K9
ciscoACE10K9
(ciscoProducts 730)
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-11
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
CISCO-SLB-EXT-MIB CISCO-SLB-EXTCAPABILITY
Description
Acts as an extension to the Cisco server load-balancing MIB
(CISCO-SLB-MIB). It provides tables for the sticky configuration.
The cslbxServerFarmStatsTable table provides details about the data
available in the show serverfarm command output.
The cslbxServerFarmTable table provides details about the server farm
state. It includes the following MIB objects:
•
cslbxServerFarmState
•
cslbxServerFarmStateChange
The cslbxNotifObjects table contains information about the server farm
state changes.
The following MIB objects for the ACE include non-SLB related
connections as well:
CISCO-SLB-HEALTH- CISCO-SLBMON-MIB
HEALTH-MONCAPABILITY
•
cslbxStatsCurrConnections
•
cslbxStatsTimedOutConnections
Acts as an extension to the Cisco server load-balancing MIB
(CISCO-SLB-MIB). It provides tables for the health probe configuration
and statistics of the ACE.
The cshMonServerfarmRealProbeStatsTable and cslbxProbeCfgTable
tables in the CISCO-SLB-HEALTH-MON-MIB provide details about the
probe data available in the show probe detail command output.
CISCO-SSL-PROXYMIB
CISCO-SSL-PROXY- Manages a Secure Socket Layer (SSL) Proxy device which terminates and
accelerates SSL and Transport Layer Security (TLS) transactions. The
CAPABILITY
proxy device can act as an SSL server or an SSL client depending on the
configuration and the application.
This MIB is used for monitoring the statistics of the proxy services and the
protocols including TCP, SSL, and TLS that are available in the show stats
crypto client command output. It also includes counters related to the
insertion of SSL header information and SSL client certificate information
into HTTP headers that are available in the show stats crypto server
command output. In addition, it includes counters related to a given client
certificate authentication failure type that are available in the show stats
http command output.
Cisco Application Control Engine Module Administration Guide
7-12
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
Description
CISCO-SLB-MIB
CISCO-SLBCAPABILITY
Manages the Server Load-Balancing (SLB) manager. This MIB monitors
the SLB connections statistics, server farms, real servers, VIP status and
statistics, and so on.
The slbVServerInfoTable table in the CISCO-SLB-MIB provides details
about the data available in the show service-policy command output.
The slbEntity Index used in the table is the slot number of the ACE. Because
the slot numbers value is not applicable for the ACE module, the slbEntity
Index will always have a value of one.
The following MIB objects for the ACE include non-SLB related
connections as well:
CISCO-SYSLOG-EXT- CISCO-SYSLOGMIB
EXT-CAPABILITY
•
slbStatsCreatedConnections
•
slbStatsCreatedHCConnections
•
slbStatsEstablishedConnections
•
slbStatsEstablishedHCConnetions
•
slbStatsDestroyedConnections
•
slbStatsDestroyedHCConnections
•
slbStatsReassignedConnections
Extends the CISCO-SLB-MIB, provides additional server farm
configuration parameters (cslbxServerFarmTable), and configures and
monitors system log (syslog) management parameters for the ACE. Use this
MIB to set up syslog servers and set logging severity levels.
The syslog is described by RFC 3164.
CISCO-SYSLOG-MIB
CISCO-SYSLOGCAPABILITY
Describes and stores the system messages (syslog messages) generated by
the ACE. The CISCO-SYSLOG-MIB provides access to the syslog
messages through SNMP. The MIB also contains a history of syslog
messages and objects to enable or disable the transmission of syslog
notifications.
Note
This MIB does not track messages that are generated from debug
commands entered through the CLI.
The syslog is described by RFC 3164.
IF-MIB
IP-MIB
CISCO-IFCAPABILITY
Reports generic information on interfaces (for example, VLANs).
CISCO-IPCAPABILITY
Defines managed objects for managing implementations of the IP and its
associated Internet Control Message Protocol (ICMP), but excludes their
management of IP routes.
The IF-MIB is described in RFC 2863.
The IP-MIB is described in RFC 4293.
SNMPv2-MIB
CISCO-SNMPv2CAPABILITY
Provides the Management Information Base for SNMPv2. The management
protocol, SNMPv2, provides for the exchange of messages that convey
management information between the agents and the management stations.
The SNMPv2-MIB is described in RFC 3418.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-13
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-2
SNMP MIB Support (continued)
MIB Support
Capability MIB
Description
TCP-MIB
CISCO-TCP-STDCAPABILITY
Defines managed objects for managing the implementation of the
Transmission Control Protocol (TCP).
The TCP MIB is described in RFC 4022.
UDP-MIB
CISCO-UDP-STDCAPABILITY
Defines managed objects for managing implementation of the User
Datagram Protocol (UDP).
The UDP MIB is described in RFC 4113.
Cisco Application Control Engine Module Administration Guide
7-14
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3 identifies the supported and unsupported tables and objects for each MIB used by the ACE.
Table 7-3
MIB Table and Object Support
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
SNMPv2-MIB
Scalar Objects:
All tables and objects are supported.
sysDescr
sysName
sysLocation
sysContact
sysObjectID
sysServices
sysORLastChange
snmpInPkts
snmpOutPkts
snmpInBadVersions
snmpInBadCommunityNames
snmpInBadCommunityUses
snmpInASNParseErrs
snmpInTooBigs
snmpInNoSuchNames
snmpInBadValues
snmpInReadOnlys
snmpInGenErrs
snmpInTotalReqVars
snmpInTotalSetVars
snmpInGetRequests
snmpInGetNexts
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-15
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
SNMPv2-MIB
snmpInSetRequests
(continued)
snmpInGetResponses
Unsupported Tables and Objects
snmpInTraps
snmpOutTooBigs
snmpOutNoSuchNames
snmpOutBadValues
snmpOutGenErrs
snmpOutGetRequests
snmpOutGetNexts
snmpOutSetRequests
snmpOutGetResponses
snmpOutTraps
snmpEnableAuthenTraps
snmpSilentDrops
snmpProxyDrops
Tables:
sysORTable
SNMP-COMMUNITYMIB
Tables:
All tables and objects are supported.
snmpCommunityTable
snmpTargetAddrExtTable
SNMP-MPD-MIB
Scalar Objects:
All tables and objects are supported.
snmpUnknownSecurityModels
snmpInvalidMsgs
snmpUnknownPDUHandlers
SNMP-NOTIFICATION-MIB
Tables:
All tables and objects are supported.
snmpNotifyTable
snmpNotifyFilterProfileTable
snmpNotifyFilterTable
SNMP-TARGET-MIB
Scalar Objects:
Scalar Objects:
snmpUnavailableContexts
snmpTargetSpinLock
snmpUnknownContexts
Tables:
snmpTargetAddrTable
snmpTargetParamsTable
Cisco Application Control Engine Module Administration Guide
7-16
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
SNMP-USER-BASEDSM-MIB
Scalar Objects:
Scalar Objects:
usmStatsUnsupportedSecLevels
usmUserSpinLock
usmStatsNotInTimeWindows
usmStatsUnknownUserNames
usmStatsUnknownEngineIDs
usmStatsWrongDigests
usmStatsDecryptionErrors
Tables:
usmUserTable
SNMP-VIEW-BASEDACM-MIB
Tables:
Scalar Objects:
vacmContextTable
vacmViewSpinLock
vacmSecurityToGroupTable
vacmAccessTable
ENTITY-MIB
Tables:
Tables:
entPhysicalTable
entLogicalTable
entLPMappingTable
entAliasMappingTable
entPhysicalContainsTable
Objects:
entPhysicalAlias
entPhysicalAssetID
entPhysicalMfgDate
ENTITY-SENSOR-MIB
entPhySensorTable
All tables and objects are supported.
IF-MIB
Scalar Objects:
Tables:
ifNumber
ifStackTable
ifTableLastChange
ifRcvAddressTable
Tables:
ifTestTable
ifTable
Objects:
ifXTable
ifStackLastChange
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-17
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
IP-MIB
Scalar Objects:
Tables:
icmpInMsgs
ipNetToMediaTable
icmpInErrors
ipv4InterfaceTable
icmpInDestUnreachs
ipv6InterfaceTable
icmpInTimeExcds
ipAddressTable
icmpInParmProbs
ipAddressPrefixTable
icmpInSrcQuenchs
ipNetToPhysicalTable
icmpInRedirects
ipDefaultRouterTable
icmpInEchos
ipv6RouterAdvertTable
icmpInEchoReps
ipv6ScopeZoneIndexTable
icmpInTimestamps
icmpInTimestampReps
Objects:
icmpInAddrMasks
ipSystemStatsInMcastOctets
icmpInAddrMaskRepsicmp
ipSystemStatsHCInMcastOctet
OutMsg
ipSystemStatsOutMcastOctets
icmpOutErrors
ipSystemStatsHCOutMcastOctets
icmpOutDestUnreachs
ipIfStatsInMcastOctets
icmpOutTimeExcds
ipIfStatsHCInMcastOctets
icmpOutParmProbs
ipIfStatsOutMcastOctets
icmpOutSrcQuenchs
ipIfStatsHCOutMcastOctets
icmpOutRedirects
icmpOutEchos
icmpOutEchoReps
icmpOutTimestamps
icmpOutTimestampReps
icmpOutAddrMasks
icmpOutAddrMaskReps
IP-MIB
Tables:
(continued)
ipAddrTable
ipSystemStatsTable
ipIfStatsTable
icmpStatsTable
icmpMsgStatsTable
Cisco Application Control Engine Module Administration Guide
7-18
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
TCP-MIB
Scalar Objects:
Scalar Objects:
tcpRtoAlgorithm
tcpHCInSegs
tcpRtoMin
tcpHCOutSegs
tcpRtoMax
tcpMaxConn
Tables:
tcpActiveOpens
tcpConnTable
tcpPassiveOpens
tcpConnectionTable
tcpAttemptFails
tcpListenerTable
tcpEstabResets
tcpCurrEstab
tcpInSegs
tcpOutSegs
tcpRetransSegs
tcpInErrs
tcpOutRsts
UDP-MIB
Scalar Objects:
Scalar Objects:
udpInDatagrams
udpHCInDatagrams
udpNoPorts
udpHCOutDatagrams
udpInErrors
udpOutDatagrams
Tables:
udpTable
udpEndpointTable
CISCO-PROCESS-MIB
Tables:
Tables:
cpmProcessTable
cpmProcessExtTable
cpmCPUTotalTable
cpmCPUThresholdTable
cpmProcessExtRevTable
cpmCPUHistoryTable
cpmCPUProcessHistoryTable
Scalar Objects:
cpmCPUHistoryThreshold
cpmCPUHistorySize
Objects:
cpmCPUInterruptMonIntervalValue
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-19
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-SYSLOG-EXTMIB
Scalar Objects:
Scalar Objects:
cseSyslogConsoleEnable
cseSyslogLogFileName
cseSyslogConsoleMsgSeverity
cseSyslogLogFileMsgSeverity
cseSyslogServerTableMaxEntries
cseSyslogFileLoggingDisable
cseSyslogTerminalEnable
cseSyslogLinecardEnable
cseSyslogTerminalMsgSeverity
cseSyslogLinecardMsgSeverity
Tables:
Tables:
cseSyslogServerTable
cseSyslogMessageControlTable
Scalar Objects:
Scalar Objects:
clogNotificationsSent
clogMaxservers
CISCO-SYSLOG-MIB
clogNotificationsEnabled
clogMaxSeverity
Tables:
clogMsgIgnores
clogServerConfigTable
clogMsgDrops
clogOriginIDType
clogOriginID
clogHistTableMaxLength
clogHistMsgsFlushed
Tables:
clogHistoryTable
CISCO-SYSTEM-MIB
Scalar Objects:
Scalar Objects:
csyClockDateAndTime
csySummerTimeStatus
csyClockLostOnReboot
csySummerTimeOffset
csyLocationCountry
csySummerTimeRecurringStart
csySummerTimeRecurringEnd
csyScheduledResetTime
csyScheduledResetAction
csyScheduledResetReason
csySnmpAuthFail
csySnmpAuthFailAddressType
csySnmpAuthFailAddress
csyNotificationsEnable
Cisco Application Control Engine Module Administration Guide
7-20
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-SLB-MIB
Scalar Objects:
Scalar Objects:
cSlbVServerStateChangeNotifEnabled
cSlbVirtStateChangeNotifEnabled
cSlbRealStateChangeNotifEnabled
cSlbRealServerStateChangeNotifEnabled
Tables:
slbStatsTable
Tables:
slbServerFarmTable
slbRealTable
slbVServerInfoTable
slbVirtualServerTable
slbVServerTable
slbConnectionTable
slbVirtualClientTable
slbStickyObjectTable
slbDfpPasswordTable
slbDfpAgentTable
slbDfpRealTable
slbSaspTable
slbSaspAgentTable
slbSaspGroupTable
slbSaspMemberTable
slbSaspStatsTable
CISCO-SLB-MIB
Unsupported Objects from slbStatsTable:
(continued)
slbStatsUnassistedSwitchingPkts
slbStatsUnassistedSwitchingHCPks
slbStatsAssistedSwitchingPkts
slbStatsAssistedSwitchingHCPkts
slbStatsZombies
slbStatsHCZombies
Unsupported Objects from slbServerFarmTable:
slbServerFarmPredictor
slbServerFarmNat
slbServerFarmBindId
Unsupported Objects from slbVServerInfoTable:
slbVServerL4Decisions
slbVServerL7Decisions
slbVServerEstablishedConnections
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-21
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-SLB-EXT-MIB
Tables:
Tables:
cslbxStatsTable
cslbxConnTable
cslbxServerFarmTable
cslbxRedirectSvrTable
cslbxServerFarmProbeTable
cslbxSfarmHttpReturnCodeTable
cslbxServerFarmStatsTable
cslbxNatPoolTable
cslbxStickyGroupTable
cslbxStickyObjectTable
cslbxStickyGroupExtTable
cslbxMapTable
cslbxHttpExpressionTable
cslbxHttpReturnCodeTable
cslbxPolicyTable
cslbxVirtualServerTable
cslbxRuleTable
cslbxVlanTable
cslbxAliasAddrTable
cslbxStaticRouteTable
cslbxFtTable
cslbxXmlConfigTable
cslbxOwnerTable
cslbxScriptFileTable
cslbxScriptTaskTable
CISCO-SLB-EXT-MIB
Scalar Objects:
Unsupported Objects from cslbxStatsTable:
(continued)
cslbxServerFarmName
cslbxStatsServerInitConns
cslbxServerFarmState
cslbxStatsServerInitHCConns
cslbxServerFarmStateChangeDescr
cslbxStatsCurrServerInitConns
cslbxServerFarmNumOfTimeFailOvers
cslbxStatsFailedServerInitConns
cslbxServerFarmNumOfTimeBkInServs
cslbxStatsNoActiveServerRejects
Unsupported Objects from cslbxServerFarmTable:
cslbxServerFarmClientNatPool
cslbxServerFarmHttpReturnCodeMap
Cisco Application Control Engine Module Administration Guide
7-22
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-SLB-HEALTHMON-MIB
Tables:
cslbxDnsProbeIpTable
cslbxProbeCfgTable
cslbxProbeSIPCfgTable
cslbxProbeHeaderCfgTable
cslbxProbeTFTPCfgTable
cslbxProbeHTTPCfgTable
cslbxProbeExpectStatusCfgTable
cslbxProbeFTPCfgTable
cshMonProbeTypeStatsTable
cslbxProbeIMAPCfgTable
cshMonServerfarmRealProbe
StatsTable
Unsupported objects from cslbxProbeCfgTable:
cslbxProbePassword
cslbxProbeSocketReuse
cslbxProbeSendDataType
cslbxProbePriority
Unsupported objects from
cslbxProbeHTTPCfgTable:
cslbxProbeHTTPCfgPersistence
Unsupported objects from
cshMonServerfarmRealProbeLastProbeTime:
cshMonServerfarmRealProbeLast ActiveTime
cshMonServerfarmRealProbeLast
FailedTime
cshMonProbeInheritedPortType
CISCO-ENHANCEDSLB-MIB
Scalar Objects:
cesRealServerNotifEnable
Unsupported objects from cesServerFarmRserverTable:
cesServerFarmRserverDroppedConns
Tables:
cesRserverTable
Tables:
cesServerFarmRserverTable
cesRealServerProbeTable
cesRserverProbeTable
CISCO-IFEXTENSION-MIB
Tables:
Tables:
cieIfNameMappingTable
cieIfPacketStatsTable
cieIfInterfaceTable
cieIfStatusListTable
cieIfDot1qCustomEtherTypeTable
cieIfUtilTable
cieIfDot1dBaseMappingTable
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-23
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-IP-PROTOCOL-FILTER-MIB
Tables:
Tables:
cippfIpProfileTable
cippfIfIpProfileTable
cippfIpFilterTable
cippfIpFilterExtTable
cippfIpFilterStatsTable
Unsupported Objects from cippfIpFilterTable:
cippfIpFilterSrcIPGroupName
cippfIpFilterDstIPGroupName
cippfIpFilterProtocolGroupName
cippfIpFilterSrcServiceGroupName
cippfIpFilterDstServiceGroupName
cippfIpFilterICMPGroupName
CISCO-MODULEVIRTUALIZATIONMIB
Scalar Objects:
Unsupported objects from cmVirtualContextTable:
cmVirtContextNotifEnable
cmVirtContextURL
Tables:
cmVirtualContextTable
cmVirtContextIfMapTable
CISCO-L4L7MODULE- Tables:
RESOURCE-LIMITciscoL4L7ResourceClassTable
MIB
ciscoL4L7ResourceLimitTable
Scalar Objects:
clrResourceLimitReachedNotifEnabled
clrResourceRateLimitReachedNotifEnabled
ciscoL4L7ResourceRateLimitTable
ciscoL4L7ResourceUsage
SummaryTable
CISCO-AAA-SERVER-MIB
Tables:
Scalar Objects:
casConfigTable
casServerStateChangeEnable
Tables:
casStatisticsTable
Unsupported Objects from casConfigTable:
casPriority
Cisco Application Control Engine Module Administration Guide
7-24
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-AAA-SERVEREXT-MIB
Scalar Objects:
Scalar Objects:
cAAASvrExtSvrGrpSvrListMaxEnt cAAASvrExtLocalAccLogMaxSize
cAAASvrExtAppToSvrGrpMaxEnt
cAAASvrExtClearAccLog
Unsupported Objects in cAAASvrExtConfigTable:
cAAALoginAuthTypeMSCHAP
cAAAServerDeadTime
cAAAServerIdleTime
Tables:
cAAAServerTestUser
cAAASvrExtConfigTable
cAAAServerTestPassword
cAAASvrExtProtocolParamTable
cAAASvrExtSvrGrpConfigTable
cAAASvrExtSvrGrpLDAPConfig
Table
cAAASvrExtAppSvrGrpConfig
Table
CISCO-LICENSEMGR-MIB
Scalar Objects:
Scalar Objects:
clmNotificationsEnable
clmHostId
clmNoOfLicenseFilesInstalled
clmLicenseConfigSpinLock
clmNoOfLicensedFeatures
clmLicenseFileURI
clmLicenseViolationWarnFlag
clmLicenseFileTargetName
clmLicenseConfigCommand
Tables:
clmLicenseRequestCommandStatus
clmLicenseFileContentsTable
clmLicenseRequestSpinLock
clmLicenseFeatureUsageTable
clmLicenseRequestFeatureName
clmFeatureUsageDetailsTable
clmLicenseRequestAppName
clmLicenseRequestCommand
clmLicenseRequestCommandStatus
Unsupported Objects from clmLicenseFeatureUsageTable:
clmLicenseGracePeriod
clmLicenseEnabled
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-25
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Name
MIB Table and Object Support (continued)
Supported Tables and Objects
CISCO-L4L7MODULE- Tables:
REDUNDANCY-MIB
clrRedundancyInfoTable
Unsupported Tables and Objects
Scalar Objects:
clrStateChangeNotifEnabled
clrPeerInfoTable
clrHAStatsTable
Tables:
clrRedundancyConfigTable
clrPeerConfigTable
clrLBStatsTable
Unsupported Objects from Objects clrRedundancyInfoTable:
clrRedundancyPriority
clrRedundancyStateChangeTime
Unsupported Objects from clrHAStatsTable:
clrHAStatsMissedHeartBeatMsgs
clrHAStatsRxUniDirectionalHeartBeatMsgs
clrHAStatsHeartBeatTimeout
Mismatches
clrHAStatsPeerUpEvents
clrHAStatsPeerDownEvents
Cisco Application Control Engine Module Administration Guide
7-26
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-3
MIB Table and Object Support (continued)
MIB Name
Supported Tables and Objects
Unsupported Tables and Objects
CISCO-SSL-PROXYMIB
Scalar Objects:
All remaining tables and objects are not supported.
cspTlcFullHandShake
cspTlcResumedHandShake
cspS3cFullHandShake
cspS3cResumedHandShake
cspNumOfSslInfoSuccessInserted
cspNumOfSslInfoFailedInserted
cspNumOfSpoofHttpHeaderDeleted
cspNumOfSslSessHeaderInserted
cspNumOfSslSessHeaderFailedInserted
cspNumOfSslServerCertHeaderInserted
cspNumOfSslServerCerHeaderFailedInserted
cspNumOfTimesSslHeaderTruncated
cspNumOfSslClientCertHeaderInserted
cspNumOfSslClientCertHeaderFailedInserted
cspCertNotYetValidRedirect
cspCertExpiredRedirect
cspIssuerCertNotFoundRedirect
cspCertRevokedRedirect
cspNoClientCertSentRedirect
cspNoCrlAvailableRedirect
cspCrlExpiredRedirect
cspCertSignatureFailedRedirect
cspOtherCertErrorRedirect
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-27
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-4 identifies the supported SNMP notifications (traps) for the ACE.
Note
Table 7-4
The clogOrigin ID and clogOriginIDType variable bindings are appended to each notification listed in
Table 7-4 to identify from which chassis, slot, and context combination that the event trap has originated.
SNMP Trap Support
Notification Name
Location of the
Notification
authenticationFailure
SNMPv2-MIB
SNMP request fails because the NMS did not authenticate with
the correct community string.
cesRealServerStateUp
CISCO-ENHANCEDSLB-MIB
State of a real server configured in a server farm is up due to
user intervention.
cesRealServerStateDown
CISCO-ENHANCEDSLB-MIB
State of a real server configured in a server farm is down due to
user intervention.
cesRealServerStateChange
CISCO-ENHANCEDSLB-MIB
State of a real server configured in a server farm changed to a
new state as a result of something other than a user intervention.
This notification is sent for situations such as ARP failures,
probe failures, and so on.
cesRserverStateUp
CISCO-ENHANCEDSLB-MIB
State of a global real server is up due to user intervention.
CISCO-ENHANCEDSLB-MIB
State of a global real server is down due to user intervention.
CISCO-ENHANCEDSLB-MIB
State of a global real server changed to a new state as a result
of something other than a user intervention. This notification is
sent for situations such as ARP failures, probe failures, and so
on.
cesRserverStateDown
cesRserverStateChange
Description
Note
Note
Note
No separate cesRealServerStateUp notifications are
sent for each real server that listens on this rserver.
No separate cesRealServerStateDown notifications are
sent for each real server that listens on this rserver.
No separate cesRealServerStateChange notifications
are sent for each real server that listens on this rserver.
Cisco Application Control Engine Module Administration Guide
7-28
OL-20814-01
Chapter 7
Configuring SNMP
Information About SNMP
Table 7-4
SNMP Trap Support (continued)
Notification Name
ciscoSlbVServerVIPState
Change
Location of the
Notification
CISCO-SLB-MIB.my
Description
State of Vserver changes. This notification is sent with the
following var-binds:
•
slbVServerState
•
slbVServerStateChangeDescr
•
slbVServerClassMap
•
slbVServerPolicyMap
•
slbVServerIpAddressType
•
slbVServerIpAddress
•
slbVServerProtocol
The change in the Vserver state could be due to different
reasons, such as binding to the interface, removing an active
server farm from the policy, and associating the virtual IP
address (VIP) with a class map.
The ciscoSlbVServerVIPStateChange is specified in the
CISCO-SLB-MIB.
ciscoSlbVServerStateChange
CISCO-SLB-MIB.my
Notification that a virtual IP address (VIP) is removed from a
class map. This notification is also sent when the state of a
virtual server has changed. The notification is sent with the
following var-binds: slbVServerState
•
slbVServerStateChangeDescr
•
slbVServerClassMap
•
slbVServerPolicyMap
The ciscoSlbVServerVIPStateChange notification will be sent
when the configuration or association of the VIP address
changes.
The ciscoSlbVServerStateChange is specified in the
CISCO-SLB-MIB.
clogMessageGenerated
CISCO-SYSLOG-MIB
ACE generated one or more syslog messages.
clmLicenseExpiryNotify
CISCO-LICENSEMGR-MIB
Notification that an installed feature license expires.
clmLicenseFileMissing
Notify
CISCO-LICENSEMGR-MIB
Notification that the system detects that one or more installed
license files are missing.
clmLicenseExpiryWarningNotify CISCO-LICENSEMGR-MIB
Notification that the system detects an installed feature license
is about to expire.
clmNoLicenseForFeature
Notify
CISCO-LICENSEMGR-MIB
Notification that the system detects that no license is installed
for a specific feature.
cmVirtContextAdded,
cmVirtContextRemoved
CISCO-MODULEVIRTUALIZATIONMIB
Notification that you created or deleted an ACE user context,
also referred as a virtual context.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-29
Chapter 7
Configuring SNMP
Default Settings for SNMP
Table 7-4
SNMP Trap Support (continued)
Notification Name
Location of the
Notification
cslbxServerFarmStateChange
CISCO-SLB-EXT-MIB
Description
Notification that a transition occurred in the state of a server
farm(ACTIVE to INACTIVE or INACTIVE to ACTIVE). The
varbind contains the following details:
•
cslbxServerFarmName
•
cslbxServerFarmState
•
cslbxServerFarmStateChangeDescr
•
cslbxServerFarmNumOfTimeFailOvers
•
cslbxServerFarmNumOfTimeBkInServs
coldStart
SNMPv2-MIB
SNMP agent started after a cold restart (full power cycle) of the
ACE.
linkUp, linkDown
SNMPv2-MIB
VLAN interface is up or down. A VLAN interface can be down,
for example, if you specified the shut command followed by the
no shut command, or the VLAN was removed from the switch
configuration.
Note
Default Settings for SNMP
Table 7-5 lists the default settings for the SNMP parameters.
Table 7-5
Default SNMP Parameters
Parameter
Default
SNMP notifications
None defined or issued.
Implementation of linkUp and linkDown traps
Cisco implementation of linkUp and linkDown traps to NMS is enabled
(not the Internet Engineering Task Force (IETF) standards-based
implementation).
SNMP engine ID for the Admin context and each The ACE automatically creates the engine ID.
user context
snmpCommunityName and
snmpCommunitySecurityName OIDs of the
SNMP-COMMUNITY-MIB
These OIDs are masked by default.
Configuring SNMP
This section describes how to configure SNMP and includes the following topics:
•
Task Flow for Configuring SNMP
•
Configuring SNMP Users
•
Defining SNMP Communities
Cisco Application Control Engine Module Administration Guide
7-30
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
•
Configuring an SNMP Contact
•
Configuring an SNMP Location
•
Configuring SNMP Notifications
•
Unmasking the SNMP Community Name and Community Security Name OIDs
•
Assigning a Trap-Source Interface for SNMP Traps
•
Accessing ACE User Context Data Through the Admin Context IP Address
•
Configuring an SNMPv3 Engine ID for an ACE Context
•
Configuring SNMP Management Traffic Services
Task Flow for Configuring SNMP
Follow these steps to configure SNMP on the ACE:
Step 1
If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the
desired context. If necessary, log directly in to, or change to, the correct context.
host1/Admin# changeto C1
host1/C1#
The rest of the examples in this procedure use the Admin context, unless otherwise specified. For details
on creating contexts, see the Cisco Application Control Engine Module Virtualization Configuration
Guide.
Step 2
Enter configuration mode.
host1/Admin# config
Enter configuration commands, one per line. End with CNTL/Z
host1/Admin(config)#
Step 3
Configure one or more SNMP users from the ACE CLI.
host1/Admin(config)# snmp-server user joe Network-Monitor auth sha abcd1234
host1/Admin(config)# snmp-server user sam Network-Monitor auth md5 abcdefgh
host1/Admin(config)# snmp-server user Bill Network-Monitor auth sha abcd1234 priv abcdefgh
Step 4
Create an SNMP community and identify access privileges.
host1/Admin(config)# snmp-server community SNMP_Community1 group Network-Monitor
Step 5
Specify the contact name for the SNMP system.
host1/Admin(config)# snmp-server contact “User1 user1@cisco.com”
Step 6
Specify the SNMP system location.
host1/Admin(config)# snmp-server location “Boxborough MA”
Step 7
Specify which host is to receive SNMP notifications.
host1/Admin(config)# snmp-server host 192.168.1.1 traps version 2c SNMP_Community1
udp-port 500
Step 8
Enable the ACE to send SNMP traps and inform requests to the NMS.
host1/Admin(config)# snmp-server enable traps slb
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-31
Chapter 7
Configuring SNMP
Configuring SNMP
Step 9
Create a class map that permits network management traffic to be received by the ACE based on the
SNMP management protocol and client source IP address.
host1/Admin(config)# class-map type management match-all SNMP-ALLOW_CLASS
host1/Admin(config-cmap-mgmt)# match protocol snmp source-address 172.16.10.0
255.255.255.254
host1/Admin(config-cmap-mgmt)# exit
host1/Admin(config)#
Step 10
Configure a policy map that activates the SNMP management protocol classifications.
host1/Admin(config)# policy-map type management first-match SNMP-ALLOW_POLICY
host1/Admin(config-pmap-mgmt)# class SNMP-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)# permit
host1/Admin(config-pmap-mgmt-c)# exit
host1/Admin(config-pmap-mgmt)# exit
host1/Admin(config)#
Step 11
Attach the traffic policy to a single VLAN interface or globally to all VLAN interfaces in the same
context. For example, to specify an interface VLAN and apply the SNMP management policy map to the
VLAN, enter:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)# ip address 172.16.10.0 255.255.255.254
host1/Admin(config-if)# service-policy input SNMP-ALLOW_POLICY
host1/Admin(config-if)# exit
Step 12
(Optional) Save your configuration changes to Flash memory.
host1/Admin(config)# exit
host1/Admin# copy running-config startup-config
Configuring SNMP Users
This section describes how to configure SNMP users from the ACE CLI. User configuration includes
information such as specifying the role group that the user belongs to, authentication parameters for the
user, the authentication password, and message encryption parameters.
The ACE synchronizes the interactions between the user created by the username command and by the
snmp-server user command; updates to a user through the ACE CLI are automatically reflected in the
SNMP server. For example, deleting a user automatically results in the user being deleted for both SNMP
and CLI. In addition, user-role mapping changes are reflected in SNMP.
Caution
If you change the SNMP engine ID for an Admin or user context, all configured SNMP users become
invalid. You must recreate all SNMP users by using the snmp-server user command in configuration
mode. For more information on the SNMPv3 engine ID, see the “Configuring an SNMPv3 Engine ID
for an ACE Context” section.
Restrictions
This topic includes the following restrictions:
•
The ACE supports a maximum of 28 SNMP users for each context.
•
User configuration through the snmp-server user command is applicable for SNMPv3 only;
SNMPv1 and SNMPv2c use a community string match for user authentication (see the “Defining
SNMP Communities” section).
Cisco Application Control Engine Module Administration Guide
7-32
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server user user_name [group_name]
[auth {md5 | sha} password1 [localizedkey
| priv {password2 | aes-128 password2}]]
Example:
host1/Admin(config)# snmp-server user joe
Network-Monitor auth sha abcd1234
Configures SNMP user information.
The keywords, arguments, and options are as follows:
•
user_name—Username. Enter an unquoted text string with
no space and a maximum of 24 alphanumeric characters.
•
group_name—(Optional) User role group to which the user
belongs. Enter Network-Monitor, the default group name
and the only role that is supported.
Note
Only network monitoring operations are supported
through the ACE implementation of SNMP. In this
case, all SNMP users are automatically assigned the
system-defined default group of Network-Monitor.
For details on creating users, see the Cisco
Application Control Engine Module Virtualization
Configuration Guide.
•
auth—(Optional) Sets authentication parameters for the
user. Authentication determines that the message is from a
valid source.
•
md5—Specifies the HMAC Message Digest 5 (MD5)
encryption algorithm for user authentication.
•
sha—Specifies the HMAC Secure Hash Algorithm (SHA)
encryption algorithm for user authentication.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-33
Chapter 7
Configuring SNMP
Configuring SNMP
Command
snmp-server user user_name [group_name]
[auth {md5 | sha} password1 [localizedkey
| priv {password2 | aes-128 password2}]]
Purpose
•
(continued)
password1—User authentication password. Enter an
unquoted text string with no space and a maximum of 130
alphanumeric characters. The ACE automatically
synchronizes the SNMP authentication password as the
password for the CLI user. The ACE supports the following
special characters in a password:
,./=+-^@!%~#$*()
Note that the ACE encrypts clear text passwords in the
running-config.
•
localizedkey—(Optional) Specifies that the password is in a
localized key format for security encryption.
•
priv—(Optional) Specifies encryption parameters for the
user. The priv option and the aes-128 option indicate that
this privacy password is for generating 128-bit AES key.
•
aes-128—Specifies the 128-byte Advanced Encryption
Standard (AES) algorithm for privacy. AES is a symmetric
cipher algorithm and is one of the privacy protocols for
SNMP message encryption. It conforms with RFC 3826.
Note
•
For an SNMPv3 operation using the external AAA
server, user configurations on this server require AES for
SNMP PDU encryption.
password2—Encryption password for the user. The AES
priv password can have a minimum of eight characters. If the
passphrases are specified in clear text, you can specify a
maximum of 64 alphanumeric characters. If you use the
localized key, you can specify a maximum of 130
alphanumeric characters. Spaces are not allowed. The ACE
supports the following special characters in a password:
,./=+-^@!%~#$*()
Note that the ACE encrypts clear text passwords in the
running-config.
no snmp-server user user_name [group_name]
[auth {md5 | sha} password1 [localizedkey
| priv {password2 | aes-128 password2}]]
(Optional) Disables the SNMP user configuration or removes an
SNMP user.
Example:
host1/Admin(config)# no snmp-server user
joe Network-Monitor auth sha abcd1234
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Cisco Application Control Engine Module Administration Guide
7-34
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Examples
The following example shows how to set the SNMP user information:
host1/Admin# config
Enter configuration commands, one per line. End with CNTL/Z
host1/Admin(config)# snmp-server user sam Network-Monitor auth md5 abcdefgh
host1/Admin(config)# snmp-server user Bill Network-Monitor auth sha abcd1234 priv abcdefgh
Defining SNMP Communities
This section describes how to create or modify SNMP community names and access privileges. Each
SNMP device or member is part of a community. An SNMP community determines the access rights for
each SNMP device. SNMP uses communities to establish trust between managers and agents.
You supply a name to the community. After that, all SNMP devices assigned to that community as
members have the same access rights (as described in RFC 2576). The ACE allows read-only access to
the MIB tree for devices included in this community. The read-only community string allows a user to
read data values, but prevents that user from modifying modify the data.
Caution
If you change the SNMP engine ID for an Admin or user context, all configured SNMP communities are
deleted. You must recreate all SNMP communities by using the snmp-server community command in
configuration mode. For more information on the SNMPv3 engine ID, see the “Configuring an SNMPv3
Engine ID for an ACE Context” section.
Restrictions
This topics contains the following restrictions:
•
SNMP communities are applicable for SNMPv1 and SNMPv2c only. SNMPv3 requires user
configuration information such as specifying the role group that the user belongs to, authentication
parameters for the user, authentication password, and message encryption parameters (see the
“Configuring SNMP Users” section).
•
Only network monitoring operations are supported through the ACE implementation of SNMP. In
this case, all SNMP users are automatically assigned the system-defined default group of
Network-Monitor. For details on creating users, see the Cisco Application Control Engine Module
Virtualization Configuration Guide.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-35
Chapter 7
Configuring SNMP
Configuring SNMP
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server community community_name
[group group_name | ro]
Creates or modifies SNMP community names and access
privileges.
Example:
host1/Admin(config)# snmp-server community
SNMP_Community1 group Network-Monitor
The keywords, arguments, and options are as follows:
no snmp-server community community_name
[group group_name | ro]
•
community_name—SNMP community name for this system.
Enter an unquoted text string with no space and a maximum
of 32 alphanumeric characters.
•
group group_name—(Optional) Identifies the role group to
which the user belongs. Enter an unquoted text string with no
space and a maximum of 32 alphanumeric characters.
•
ro—(Optional) Allows read-only access for this community.
(Optional) Removes an SNMP community.
Example:
host1/Admin(config)# no snmp-server
community SNMP_Community1 group
Network-Monitor
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring an SNMP Contact
This section describes how to specify the contact information for the SNMP system.
Restrictions
You can specify information for one contact name only.
Cisco Application Control Engine Module Administration Guide
7-36
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server contact contact_information
Specifies the contact information for the SNMP system.
Example:
host1/Admin(config)# snmp-server contact
“User1 user1@cisco.com”
Enter the contact_information argument as a text string with a
maximum of 240 alphanumeric characters, including spaces. If
the string contains more than one word, enclose the string in
quotation marks (“ ”). You can include information on how to
contact the person; for example, you can provide a phone number
or an e-mail address.
no snmp-server contact
(Optional) Removes the SNMP contact name.
Example:
host1/Admin(config)# snmp-server contact
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring an SNMP Location
This section describes how to specify the SNMP system location.
Restrictions
You can specify one location only.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server location location
Specifies the SNMP system location.
Example:
host1/Admin(config)# snmp-server location
“Boxborough MA”
Enter the location argument as the physical location of the
system. Enter a text string with a maximum of 240 alphanumeric
characters, including spaces. If the string contains more than one
word, enclose the string in quotation marks (“ ”).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-37
Chapter 7
Configuring SNMP
Configuring SNMP
Command
Purpose
no snmp-server location
Removes the SNMP system location information.
Example:
host1/Admin(config)# no snmp-server
location
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring SNMP Notifications
This section describes how to configure the ACE to send traps or inform requests as notifications to an
SNMP manager when a particular event occurs. In some instances, traps are unreliable because the
receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the
trap was received. However, an SNMP manager that receives inform requests acknowledges the message
with an SNMP Response PDU. If the sender never receives a Response, the inform request is normally
retransmitted. Inform requests are more likely to reach their intended destination.
Use the SNMP-TARGET-MIB to obtain more information on the destinations to which notifications are
to be sent either as traps or as SNMP inform requests. See the “Supported MIBs and Notifications”
section for details.
This section contains the following topics:
•
Configuring SNMP Notification Hosts
•
Enabling SNMP Notifications
•
Enabling the IETF Standard for SNMP linkUp and linkDown Traps
Configuring SNMP Notification Hosts
This section describes how to specify which host receives SNMP notifications.
Restrictions
This topic includes the following restrictions:
•
To send notifications, you must specify at least one host to receive SNMP notifications.
•
The ACE supports a maximum of 10 SNMP hosts per context.
Cisco Application Control Engine Module Administration Guide
7-38
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server host host_address
{community-string_username | informs |
traps | version {1{udp-port} | 2c
{udp-port} | 3 [auth | noauth | priv]}}
Example:
host1/Admin(config)# snmp-server host
192.168.1.1 traps version 2c
SNMP_Community1 udp-port 500
Specifies which host receives SNMP notifications.
The keywords, arguments, and options are as follows:
•
host_address—IP address of the host (the targeted recipient).
Enter the address in dotted-decimal IP notation (for example,
192.168.11.1).
•
community-string_username—SNMP community string or
username with the notification operation. Enter an unquoted
text string with no space and a maximum of 32 alphanumeric
characters.
•
informs—Sends SNMP inform requests to the identified
host, which allows for manager-to-manager communication.
Inform requests can be useful when the need arises for more
than one NMS in the network.
•
traps—Sends SNMP traps to the identified host. A trap is the
method for an agent to tell the NMS that a problem has
occurred. The trap originates from the agent and is sent to the
trap destination, as configured within the agent itself.
Typically the trap destination is the IP address of the NMS.
•
version—Specifies the version of SNMP used to send the
traps. SNMPv3 is the most secure model because it allows
packet encryption with the priv keyword.
•
1—Specifies SNMPv1. This option is not available for use
with SNMP inform requests. SNMPv1 has one optional
keyword (udp-port) that specifies the UDP port of the host
to use. The default is 162.
•
2c—Specifies SNMPv2C. SNMPv2C has one optional
keyword (udp-port) that specifies the UDP port of the host
to use. The default is 162.
•
3—Specifies SNMPv3. SNMPv3 has three optional
keywords (auth, no auth, or priv).
•
auth—(Optional) Enables Message Digest 5 (MD5) and
Secure Hash Algorithm (SHA) packet authentication.
•
noauth—(Optional) Specifies the noAuthNoPriv security
level.
•
priv—(Optional) Enables Data Encryption Standard (DES)
packet encryption (privacy).
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-39
Chapter 7
Configuring SNMP
Configuring SNMP
Command
Purpose
no snmp-server host host_address
{community-string_username | informs |
traps | version {1{udp-port} | 2c
{udp-port} | 3 [auth | noauth | priv]}}
Removes the specified host.
Example:
host1/Admin(config)# no snmp-server host
192.168.1.1 traps version 2c
SNMP_Community1 udp-port 500
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Enabling SNMP Notifications
This section describes how to enable the ACE to send SNMP notification traps and inform requests to
the NMS. Notification traps and inform requests are system alerts that the ACE generates when certain
events occur. SNMP notifications can be sent to the NMS as traps or inform requests. By default, no
SNMP notification is defined or issued.
Restrictions
This topic includes the following restrictions:
•
To configure the ACE to send the SNMP notifications, specify at least one snmp-server enable
traps command. To enable multiple types of notifications, you must enter a separate snmp-server
enable traps command for each notification type and notification option. If you enter the command
without any keywords, the ACE enables all notification types and traps.
•
The notification types used in the snmp-server enable traps command all have an associated MIB
object that globally enables or disables them. However, not all of the notification types available in
the snmp-server host command have notificationEnable MIB objects, so some of the notification
types cannot be controlled by using the snmp-server enable command.
Prerequisites
The snmp-server enable traps command is used with the snmp-server host command (see the
“Configuring SNMP Notification Hosts” section). The snmp-server host command specifies which host
receives the SNMP notifications. To send notifications, you must configure at least one SNMP server
host.
Cisco Application Control Engine Module Administration Guide
7-40
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server enable traps
[notification_type] [notification_option]
Enables the ACE to send SNMP traps and informs to the NMS.
The keywords, arguments, and options are as follows:
Example:
host1/Admin(config)# snmp-server enable
traps slb real
•
notification_type—(Optional) Type of notification to enable.
If no type is specified, the ACE sends all notifications.
Specify one of the following keywords as the
notification_type:
– license—Sends SNMP license manager notifications.
This keyword appears only in the Admin context.
– slb—Sends server load-balancing notifications. When
you specify the slb keyword, you can specify a
notification_option value.
– snmp—Sends SNMP notifications. When you specify
the snmp keyword, you can specify a
notification_option value.
– syslog—Sends error message notifications (Cisco
Syslog MIB).
Note
To enable system messages to be sent as traps to the
NMS, you can specify the logging history command.
You specify the level of messages to be sent with the
logging history level command. You must also
enable syslog traps by using the snmp-server enable
traps command. See the Cisco Application Control
Engine Module System Message Guide for details.
– virtual-context—Sends virtual context (ACE user
context) change notifications. This keyword appears
only in the Admin context.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-41
Chapter 7
Configuring SNMP
Configuring SNMP
Command
Purpose
snmp-server enable traps
[notification_type] [notification_option]
•
notification_option—(Optional) Enables the following
SNMP notifications:
– When you specify the snmp keyword, specify the
(continued)
authentication, coldstart, linkdown, or linkup
keyword to enable SNMP notifications. This selection
generates a notification if the community string provided
in the SNMP request is incorrect, or when a VLAN
interface is either up or down. The coldstart keyword
appears only in the Admin context.
– When you specify the slb keyword, specify the real,
serverfarm, or vserver keyword to enable server
load-balancing notifications. This selection generates a
notification if the following state change occurs:
The real server changes state (up or down) due to user
intervention, ARP failures, or probe failures.
The server farm changes state because all real servers in
the server farm are down.
The virtual server changes state (up or down). The
virtual server represents the servers behind the content
switch in the ACE to the outside world and consists of
the following attributes: the destination address (can be
a range of IP addresses), the protocol, the destination
port, or the incoming VLAN.
no snmp-server enable traps
[notification_type] [notification_option]
Disables SNMP server notifications.
Example:
host1/Admin(config)# no snmp-server enable
traps slb real
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Examples
The following example shows how to enable the ACE to send server load-balancing traps to the host at
IP address 192.168.1.1 using a community string:
host1/Admin(config)# snmp-server host 192.168.1.1
host1/Admin(config)# snmp-server community SNMP_Community1 group Network-Monitor
host1/Admin(config)# snmp-server enable traps slb real
Enabling the IETF Standard for SNMP linkUp and linkDown Traps
This section describes how to configure the ACE to send the Internet Engineering Task Force (IETF)
standards-based implementation for linkUp and linkDown traps (as outlined in RFC 2863) rather than
send the Cisco implementation of linkUp and linkDown traps to the NMS. By default, the ACE sends
the Cisco implementation of linkUp and linkDown traps to the NMS. The ACE sends the Cisco Systems
IF-MIB variable bindings, which consists of ifIndex, ifAdminStatus, ifOperStatus, ifName, ifType,
clogOriginID, and clogOriginIDType.
Cisco Application Control Engine Module Administration Guide
7-42
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Note
The Cisco variable bindings are sent by default. To receive RFC 2863-compliant traps, you must specify
the snmp-server trap link ietf command.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server trap link ietf
Example:
host1/Admin(config)# snmp-server trap link
ietf
no snmp-server trap link ietf
Example:
host1/Admin(config)# no snmp-server trap
link ietf
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
Configures the ACE to send the Internet Engineering Task Force
(IETF) standards-based implementation for linkUp and
linkDown traps.
Reverts to the Cisco implementation of linkUp and linkDown
traps.
(Optional) Copies the running configuration to the startup
configuration.
Unmasking the SNMP Community Name and Community Security Name OIDs
This section describes how to unmask the snmpCommunityName and snmpCommunitySecurityName
OIDs of the SNMP-COMMUNITY-MIB. These OIDs are masked by default.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server unmask-community
Example:
host1/host1/Admin(config)# snmp-server
unmask-community
Unmasks the snmpCommunityName and
snmpCommunitySecurityName OIDs of the
SNMP-COMMUNITY-MIB.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-43
Chapter 7
Configuring SNMP
Configuring SNMP
Command
Purpose
no snmp-server unmask-community
(Optional) Masks the snmpCommunityName and
snmpCommunitySecurityName OIDs.
Example:
host1/Admin(config)# no snmp-server
unmask-community
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Assigning a Trap-Source Interface for SNMP Traps
This section describes how to specify the VLAN interface or the Ethernet management port interface
(Admin context only) that is the trap source address contained in the SNMP v1 trap PDU.
Restrictions
This topic includes the following restrictions:
•
If you do not configure the snmp-server trap-source command, the ACE takes the source IP
address from the internal routing table, which is dependant on the destination host address where
the notification is to be sent.
•
If you specify a VLAN number of an interface that does not have a valid IP address, the ACE fails
in sending notifications for SNMP v1 traps.
•
The ACE restricts you from selecting the VLAN number of the FT VLAN interface that has been
specified between redundant ACEs as the trap source address contained in the SNMP v1 trap PDU.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server trap-source vlan number
Example:
host1/Admin(config)# snmp-server
trap-source vlan 50
Specifies the VLAN interface or the Ethernet management port
interface (Admin context only) that is the trap source address
contained in the SNMP v1 trap PDU.
The number argument specifies the number of the VLAN
interface that is the trap source address contained in the SNMP
v1 trap PDU. Enter a value from 2 to 4094 for an existing VLAN
interface.
Cisco Application Control Engine Module Administration Guide
7-44
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Command
Purpose
no snmp-server trap-source vlan number
(Optional) Removes the specified VLAN interface that is trap
source address contained in the SNMP v1 trap PDU.
Example:
host1/Admin(config)# no snmp-server
trap-source vlan 50
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Accessing ACE User Context Data Through the Admin Context IP Address
This section describes how SNMP managers can send requests to a context by using the IP address to
get the data that corresponds to the context.The ACE Admin context and each ACE user context has its
own IP address. The SNMP agent supports a community string for SNMPv1 and SNMPv2 and a
username for SNMPv3 on a per-context basis.
You can also retrieve data for user contexts by using the IP address for the Admin context. The Admin
context credentials also allow access to user context data, such as performance and configuration
information.
This section contains the following topics:
•
Accessing User Context Data When Using SNMPv1/v2
•
Accessing User Context Data When Using SNMPv3
Restrictions
Notifications for user contexts cannot be sent through the Admin context.
Accessing User Context Data When Using SNMPv1/v2
This section describes how with SNMPv1/v2, you can access MIBs available for a user context through
an Admin context IP address by specifying the appropriate SNMP version, the Admin context IP address,
and the Admin context community string embedded with the name of the user context. The format for
the community string is as follows:
admin_community_string@ACE_context_name
The ACE_context_name can be Admin or any ACE user context. If you do not specify a context name,
the request is for the Admin context.
Examples
The following example shows how to return data for user context C1 when the Admin context has a
configured community string of adminCommunity and an IP address of 10.6.252.63:
snmpget -v2c -c adminCommunity@C1 10.6.252.63 udpDatagrams.0
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-45
Chapter 7
Configuring SNMP
Configuring SNMP
Accessing User Context Data When Using SNMPv3
This section describes how with SNMPv3, you can access MIBs for a user context through an Admin
context IP address by using the Admin context IP address, the appropriate SNMP version, the Admin
context username, and the user context name supported by the Admin context in the SNMPv3 packet.
The ACE uses the user context name in the SNMPv3 context field of the request.
Note
The SNMPv3 engine represents a logically separate SNMP agent. The ACE automatically creates an
SNMP engine ID for each context or you can configure it. For more information on configuring an
SNMPv3 engine ID, see the “Configuring an SNMPv3 Engine ID for an ACE Context” section.
Examples
The following example shows how to return data from user context C2 when the Admin context has a
configured SNMP user snmpuser and an IP address of 10.6.252.63:
snmpgetnext -v 3 - a MD5 -A cisco123 -u snmpuser -1 authNoPriv 10.6.252.63 system -n C2
The ACE uses the user context C2 in place of the SNMPv3 context field in the request.
Note
The SNMPv3 request is dropped if the request is sent to the IP address of the user context with a
SNMPv3 context name field set to an empty string (“”).
Configuring an SNMPv3 Engine ID for an ACE Context
This section describes how to configure an SNMP engine ID for the Admin or user context. By default,
the ACE automatically creates an SNMP engine ID for the Admin context and each user context. The
SNMP engine represents a logically separate SNMP agent. The IP address for an ACE context provides
access to only one SNMP engine ID.
Caution
If you change the SNMP engine ID for an Admin or user context, all configured SNMP users become
invalid and all SNMP communities are deleted. You must recreate all SNMP users by using the
snmp-server user command in configuration mode, and recreate all SNMP communities by using the
snmp-server community command in configuration mode (see the “Defining SNMP Communities”
section).
Cisco Application Control Engine Module Administration Guide
7-46
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin(config)#
Step 2
snmp-server engineid number
Configures the SNMP engine ID for an ACE context.
Example:
host1/Admin(config)# snmp-server engineID
88439573498573888843957349857388
The number argument is the SNMPv3 engine ID that you want to
configure. Enter a range of 10 to 64 hexadecimal digits.
no snmp-server engineid number
(Optional) Resets the default engine ID for an ACE context.
Example:
host1/Admin(config)# snmp-server engineID
88439573498573888843957349857388
Step 3
do show snmp engineID
(Optional) Displays the engine ID for a context.
Example:
host1/Admin(config)# do show snmp engineID
Step 4
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Configuring SNMP Management Traffic Services
This section describes how to configure SNMP management traffic to and from the ACE through the use
of class maps, policy maps, and service policies. The following items summarize the role of each
function in configuring remote network management access to the ACE:
•
Class map—Provides the remote network traffic match criteria to permit SNMP management traffic
based on the SNMP management protocol and the client source IP address.
•
Policy map—Enables remote network management access for a traffic classification that matches
the criteria listed the class map.
•
Service policy—Activates the policy map, and attaches the traffic policy to a VLAN interface or
globally on all VLAN interfaces.
This section provides an overview on creating a class map, policy map, and service policy for SNMP
access.
SNMP remote access sessions are established to the ACE per context. For details on creating contexts
and users, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
This section contains the following topics:
•
Creating and Configuring a Layer 3 and Layer 4 Class Map
•
Creating a Layer 3 and Layer 4 Policy Map
•
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
•
Applying a Service Policy to a Specific VLAN Interface
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-47
Chapter 7
Configuring SNMP
Configuring SNMP
Creating and Configuring a Layer 3 and Layer 4 Class Map
This section describes how to create a Layer 3 and Layer 4 class map to classify the SNMP management
traffic that can be received by the ACE. This class map allows the ACE to receive the network
management traffic by identifying the incoming IP protocols that the ACE can receive and the client
source host IP address and subnet mask as the matching criteria. The class map also defines the allowed
network traffic as a form of management security for protocols such as SNMP.
A class map can have multiple match commands. You can configure class maps to define multiple
SNMP management protocol and source IP address commands in a group that you then associate with a
traffic policy. The match-all and match-any keywords determine how the ACE evaluates multiple match
statements operations when multiple match criteria exist in a class map.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
class-map type management [match-all |
match-any] map_name
Example:
host1/Admin(config)# class-map type
management match-all SNMP-ALLOW_CLASS
host1/Admin(config-cmap-mgmt)#
Create a Layer 3 and Layer 4 class map to classify the SNMP
management traffic that can be received by the ACE.
The keywords, arguments, and options are as follows:
•
match-all | match-any—(Optional) Determines how the
ACE evaluates Layer 3 and Layer 4 network traffic when
multiple match criteria exist in a class map. The class map is
considered a match if the match commands meet one of the
following conditions:
– match-all —(Default) All of the match criteria listed in
the class map match the network traffic class in the class
map (typically, match commands of the same type).
– match-any—Only one of the match criteria listed in the
class map matches the network traffic class in the class
map (typically, match commands of different types).
•
map_name—Name assigned to the class map. Enter an
unquoted text string with no spaces and a maximum of 64
alphanumeric characters.
This command enters the class map management configuration
mode.
no class-map type management [match-all |
match-any] map_name
Example:
host1/Admin(config)# no class-map type
management match-all SNMP-ALLOW_CLASS
(Optional) Removes a Layer 3 and Layer 4 SNMP protocol
management class map from the ACE.
Cisco Application Control Engine Module Administration Guide
7-48
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Step 3
Command
Purpose
description text
Provides a brief summary about the Layer 3 and Layer 4 remote
management class map.
Example:
host1/Admin(config-cmap-mgmt)# description
Allow SNMP access
no description
The text argument is the description that you want to provide.
Enter an unquoted text string with a maximum of 240
alphanumeric characters.
(Optional) Remove the description from the class map.
Example:
host1/Admin(config-cmap-mgmt)# no
description
Step 4
[line_number] match protocol snmp {any |
source-address ip_address mask}
Example:
host1/Admin(config-cmap-mgmt)# match
protocol snmp source-address 192.168.10.1
255.255.255.0
Configures the class map to specify that SNMP can be received
by the ACE and an NMS. You configure the associated policy
map to permit SNMP access to the ACE. As part of the network
management access traffic classification, you also specify either
a client source host IP address and subnet mask as the matching
criteria or instruct the ACE to allow any client source address for
the management traffic classification.
The keywords, arguments, and options are as follows:
Step 5
•
line_number—(Optional) Line number to identify individual
match commands to help you edit or delete them. Enter an
integer from 2 to 255. You can enter no line_number to delete
long match commands instead of entering the entire line.
The line numbers do not dictate a priority or sequence for the
match statements.
•
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.
•
mask—Subnet mask of the client in dotted-decimal notation
(for example, 255.255.255.0).
no match protocol snmp
Example:
host1/Admin(config-cmap-mgmt)# no match
protocol snmp
(Optional) Deselects the specified SNMP protocol match criteria
from the class map.
do copy running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Example:
host1/Admin(config-cmap-mgmt)# do copy
running-config startup-config
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-49
Chapter 7
Configuring SNMP
Configuring SNMP
Creating a Layer 3 and Layer 4 Policy Map
This section describes how to create a Layer 3 and Layer 4 policy map that defines the actions executed
on SNMP network management traffic that matches the specified classifications.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
policy-map type management first-match
map_name
Example:
host1/Admin(config)# policy-map type
management first-match SNMP-ALLOW_POLICY
host1/Admin(config-pmap-mgmt)#
Configures a Layer 3 and Layer 4 policy map that permits the
ACE to receive the SNMP management protocol. The ACE
executes the action for the first matching classification. The ACE
does not execute any additional actions.
The map_name argument specifies the name assigned to the
Layer 3 and Layer 4 network management policy map. Enter an
unquoted text string with no spaces and a maximum of 64
alphanumeric characters.
This command enters the policy map management configuration
mode.
no policy-map type management first-match
map_name
(Optional) Removes a network traffic management policy map
from the ACE.
Example:
host1/Admin(config)# no policy-map type
management first-match SNMP-ALLOW_POLICY
Cisco Application Control Engine Module Administration Guide
7-50
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Step 3
Command
Purpose
class {name1 [insert-before name2] |
class-default}
Example:
host1/Admin(config-pmap-mgmt)# class
SNMP-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)#
Specifies a Layer 3 and Layer 4 traffic class created with the
class-map command to associate network traffic with the traffic
policy
The arguments keywords, and options are as follows:
•
name1—Name of a previously defined Layer 3 and Layer 4
traffic class, configured with the class-map command, to
associate traffic to the traffic policy. Enter an unquoted text
string with no spaces and a maximum of 64 alphanumeric
characters.
•
insert-before name2—(Optional) Places the current class
map ahead of an existing class map or inline match condition
specified by the name2 argument in the policy map
configuration. The ACE does not save the sequence
reordering as part of the configuration. Enter an unquoted
text string with no spaces and a maximum of 64
alphanumeric characters.
•
class-default—Specifies the class-default class map for the
Layer 3 and Layer 4 traffic policy. This class map is a
reserved class map created by the ACE. You cannot delete or
modify this class. All network traffic that fails to meet the
other matching criteria in the named class map belongs to the
default traffic class. If none of the specified classifications
match, the ACE then matches the action specified under the
class class-default command. The class-default class map
has an implicit match any statement in it and is used to
match any traffic classification.
This command enters the policy map management class
configuration mode.
no class name1
Example:
host1/Admin(config-cmap-mgmt)# no class
SNMP-ALLOW_CLASS
Step 4
permit
Example:
host1/Admin(config-pmap-mgmt-c)# permit
deny
Example:
host1/Admin(config-pmap-mgmt-c)# deny
Step 5
do copy running-config startup-config
Example:
host1/Admin(config-pmap-mgmt-c)# do copy
running-config startup-config
(Optional) Removes a class map from a Layer 3 and Layer 4
policy map.
Enables the network management traffic listed in the Layer 3 and
Layer 4 class map to be received by the ACE.
(Optional) Enables the network management traffic listed in the
Layer 3 and Layer 4 class map to be rejected by the ACE.
(Optional) Copies the running configuration to the startup
configuration.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-51
Chapter 7
Configuring SNMP
Configuring SNMP
Examples
The following example shows how to use the insert-before command to define the sequential order of
two class maps in the policy map:
host1/Admin(config-pmap-mgmt)# class L4_SSH_CLASS insert-before L4_REMOTE_ACCESS_CLASS
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
This section describes how to apply an existing policy map globally to all VLAN interfaces in the same
context.
Note the following guidelines when applying a service policy:
Note
•
Policy maps, applied globally in a context, are internally applied on all interfaces existing in the
context.
•
A policy activated on an interface overwrites any specified global policies for overlapping
classification and actions.
To apply the policy map to a specific VLAN interface only, see the “Applying a Service Policy to a
Specific VLAN Interface” section.
Restrictions
The ACE allows only one policy of a specific feature type to be activated on a given interface.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
service-policy input policy_name
Example:
host1/Admin(config)# service-policy input
SNMP_MGMT_ALLOW_POLICY
Globally applies the SNMP management policy map to all of the
VLANs associated with a context.
The keywords and arguments are as follows:
•
input—Specifies that the traffic policy is to be attached to
the input direction of an interface. The traffic policy
evaluates all traffic received by that interface.
•
policy_name—Name of a previously defined policy map,
configured with a previously created policy-map command.
The name can be a maximum of 40 alphanumeric characters.
If you are applying the policy map globally to all of the VLANs
associated with a context
Cisco Application Control Engine Module Administration Guide
7-52
OL-20814-01
Chapter 7
Configuring SNMP
Configuring SNMP
Command
Purpose
no service-policy input policy_name
(Optional) Removes the SNMP management policy map from all
of the VLANs associated with a context.
Example:
host1/Admin(config)# no service-policy
input SNMP_MGMT_ALLOW_POLICY
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
When you remove a policy, the ACE automatically resets the
associated service policy statistics to provide a new starting point
for the service policy statistics the next time that you attach a
traffic policy to a specific VLAN interface or globally to all
VLAN interfaces in the same context.
(Optional) Copies the running configuration to the startup
configuration.
Applying a Service Policy to a Specific VLAN Interface
This section describes how to apply an existing policy map to a specific VLAN interface. A policy
activated on an interface overwrites any specified global policies for overlapping classification and
actions.
Note
To apply the policy map globally to all VLAN interfaces in the same context, see the “Applying a Service
Policy Globally to All VLAN Interfaces in the Same Context” section.
Restrictions
The ACE allows only one policy of a specific feature type to be activated on a given interface.
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
Step 3
interface vlan number
Specifies an interface VLAN.
Example:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)#
The number argument is the number for a VLAN assigned to the
ACE
ip address address
Specifies the VLAN IP address.
This commands enters the interface configuration mode
commands for the VLAN.
Example:
host1/Admin(config-if)# ip address
172.20.1.100 255.255.0.0
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-53
Chapter 7
Configuring SNMP
Configuring SNMP
Step 4
Command
Purpose
service-policy input policy_name
Applies the SNMP management policy map to the VLAN.
Example:
host1/Admin(config-if)# service-policy
input SNMP_MGMT_ALLOW_POLICY
The keywords and arguments are as follows:
no service-policy input policy_name
Example:
host1/Admin(config-if)# no service-policy
input SNMP_MGMT_ALLOW_POLICY
Step 5
do copy running-config startup-config
Example:
host1/Admin(config-if)# do copy
running-config startup-config
•
input—Specifies that the traffic policy is to be attached to
the input direction of an interface. The traffic policy
evaluates all traffic received by that interface.
•
policy_name—Name of a previously defined policy map,
configured with a previously created policy-map command.
The name can be a maximum of 40 alphanumeric characters.
(Optional) Removes the SNMP management policy from an
interface VLAN.
When you remove a policy, the ACE automatically resets the
associated service policy statistics to provide a new starting point
for the service policy statistics the next time that you attach a
traffic policy to a specific VLAN interface or globally to all
VLAN interfaces in the same context.
(Optional) Copies the running configuration to the startup
configuration.
Cisco Application Control Engine Module Administration Guide
7-54
OL-20814-01
Chapter 7
Configuring SNMP
Displaying or Clearing SNMP and Service Policy Statistics
Displaying or Clearing SNMP and Service Policy Statistics
This section describes how to display or clear SNMP and service policy statistics. It contains the
following topics:
•
Displaying SNMP and Service Policy Statics
•
Clearing SNMP Service Policy Statistics
Displaying SNMP and Service Policy Statics
This section describes the show commands that display configuration and statistical information relating
to your SNMP configuration and associated service policies. It contains the following topics:
•
Displaying SNMP Statistical Information
•
Displaying SNMP Service Policy Statistics
Displaying SNMP Statistical Information
To display SNMP statistics and configured SNMP information, use the following show commands:
Command
Purpose
show snmp [community | engineID | group | host | sessions Displays SNMP statistics and configured SNMP information.
| user]
By default, this command displays the ACE contact, ACE
location, packet traffic information, community strings, and
user information. You can instruct the ACE to display specific
SNMP information by including the appropriate keyword.
The keywords are as follows:
•
community—(Optional) Displays SNMP community
strings.
•
engineID—(Optional) Displays the identification of the
local SNMP engine and all remote engines that have been
configured on the ACE.
•
group—(Optional) Displays the names of groups on the
ACE, the security model, the status of the different views,
and the storage type of each group.
•
host—(Optional) Displays the configured SNMP
notification recipient host, User Datagram Protocol (UDP)
port number, user, and security model.
•
sessions—(Optional) Displays the IP address of the
targets for which traps or informs have been sent.
•
user—(Optional) Displays SNMPv3 user information.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-55
Chapter 7
Configuring SNMP
Displaying or Clearing SNMP and Service Policy Statistics
Table 7-6 describes the fields in the show snmp community command output.
Table 7-6
Field Descriptions for the show snmp Command Output
Field
Description
Sys contact
Contact name for the SNMP system
Sys location
SNMP system location
SNMP packets input
Total number of SNMP packets received by the ACE
Bad SNMP versions
Number of packets with an invalid SNMP version
Unknown community name
Number of SNMP packets with an unknown community name
Illegal operation for community
name supplied
Number of packets that request an operation not allowed for that community
Encoding errors
Number of SNMP packets that were improperly encoded
Number of requested variables
Number of variables requested by SNMP managers
Number of altered variables
Number of variables altered by SNMP managers
Get-request PDUs
Number of get requests received
Get-next PDUs
Number of get-next requests received
Set-request PDUs
Number of set requests received
SNMP packets output
Total number of SNMP packets sent by the ACE
Too big errors
Number of SNMP packets that were larger than the maximum packet size
No such name errors
Number of SNMP requests that specified a MIB object that does not exist
Bad values errors
Number of SNMP set requests that specified an invalid value for a MIB object
General errors
Number of SNMP set requests that failed due to some other error, such as a noSuchName
error, badValue error, or any of the other specific errors
Community
SNMP community name for the ACE
Group/Access
Access rights for the community, read-only
User
String that identifies the name of the SNMP user
Auth
Authentication of a packet without encryption
Priv
Authentication of a packet with encryption
Group
User role group to which the user belongs
Table 7-7 describes the fields in the show snmp community command output.
Table 7-7
Field Descriptions for the show snmp community Command Output
Field
Description
Community
SNMP community name for the ACE
Group/Access
Access rights for the community, read-only
Cisco Application Control Engine Module Administration Guide
7-56
OL-20814-01
Chapter 7
Configuring SNMP
Displaying or Clearing SNMP and Service Policy Statistics
Table 7-8 describes the fields in the show snmp engineID command output.
Table 7-8
Field Descriptions for the show snmp engineID Command Output
Field
Description
Local SNMP engineID
Identification number of the local SNMP engine on the ACE
Table 7-9 describes the fields in the show snmp group command output.
Table 7-9
Field Descriptions for the show snmp group Command Output
Field
Description
Group name
Name of the SNMP group or collection of users that have a common access policy
Security model
Security model used by the group, either v1, v2c, or v3
Security level
Security level used by the group
Read view
String that identifies the read view of the group
Write view
String that identifies the write view of the group
Notify view
String that identifies the notify view of the group
Storage-type
Status of whether the settings have been set in volatile or temporary memory on the
device or in nonvolatile or persistent memory where settings will remain after the device
has been turned off and on again
Row status
Indicates whether the Row status for the SNMP group is active or inactive
Table 7-10 describes the fields in the show snmp host command output.
Table 7-10
Field Descriptions for the show snmp host Command Output
Field
Description
Host
IP address of the target host
Port
UDP port number to which notifications will be sent
Version
Version of SNMP used to send the trap, either v1, v2c, or v3
Level
Method for authentication and privacy
Type
Type of notification configured
SecName
Security name for scanning the target host
Table 7-11 describes the fields in the show snmp sessions command output.
Table 7-11
Field Descriptions for the show snmp sessions Command Output
Field
Description
Destination
IP address of a target for which traps or informs have been sent
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-57
Chapter 7
Configuring SNMP
Displaying or Clearing SNMP and Service Policy Statistics
Table 7-12 describes the fields in the show snmp user command output.
Table 7-12
Field Descriptions for the show snmp user Command Output
Field
Description
User
String identifying the name of the SNMP user
Auth
Authentication of a packet without encryption
Priv
Authentication of a packet with encryption
Group
User role group to which the user belongs
Displaying SNMP Service Policy Statistics
To display the statistical information of the service policies associated with your SNMP configuration,
use the following show command:
Command
Purpose
show service-policy policy_name [detail]
Displays service policy statistics for a Layer 3 and Layer 4 SNMP
management policy map.
The keywords, options, and arguments are as follows:
•
policy_name—Identifier of an existing policy map that is currently in
service (applied to an interface) as an unquoted text string with a
maximum of 64 alphanumeric characters.
•
detail—(Optional) Displays a more detailed listing of policy map
statistics and status information.
Note
The ACE updates the counters that the show service-policy
command displays after the applicable connections are closed.
Examples
The following examples shows how to display service policy statistics for the
SNMP_MGMT_ALLOW_POLICY policy map:
host1/Admin# show service-policy SNMP_MGMT_ALLOW_POLICY
Status
: ACTIVE
Description: Allow mgmt protocols
----------------------------------------Context Global Policy:
service-policy: SNMP_MGMT_ALLOW_POLICY
Cisco Application Control Engine Module Administration Guide
7-58
OL-20814-01
Chapter 7
Configuring SNMP
Example of an SNMP Configuration
Clearing SNMP Service Policy Statistics
To clear the statistical information of the service policies associated with your SNMP configuration, use
the following clear command:
Command
Purpose
clear service-policy policy_name
Clears the service policy statistics.
For the policy_name argument, enter the identifier of an existing policy map
that is currently in service (applied to an interface).
Example of an SNMP Configuration
The following example illustrates a running-configuration that verifies the current status of a real server
through SNMP and the CLI. It also verifies that SNMP traps are sent when a real server or virtual server
is not operational. This example illustrates that you can restrict the client source host IP address allowed
to connect to the ACE. The policy map is applied to all of the VLAN interfaces associated with the
context. The SNMP configuration appears in bold in the example.
access-list ACL1 line 10 extended permit ip any any
rserver host
ip address
inservice
rserver host
ip address
inservice
rserver host
ip address
inservice
SERVER1
192.168.252.245
SERVER2
192.168.252.246
SERVER3
192.168.252.247
serverfarm host SFARM1
probe HTTP_PROBE
rserver SERVER1
conn-limit max 3 min 2
inservice
serverfarm host SFARM2
probe HTTP
rserver SERVER2
conn-limit max 500 min 2
inservice
rserver SERVER3
conn-limit max 500 min 2
inservice
class-map type http loadbalance match-all L7_INDEX-HTML_CLASS
2 match http url /index.html
class-map match-all L4_MAX-CONN-VIP_105_CLASS
2 match virtual-address 192.168.120.105 any
class-map type management match-any L4_REMOTE-ACCESS-LOCAL_CLASS
description Enables SNMP remote management for local users
1 match protocol snmp source-address 192.168.0.0 255.248.0.0
2 match protocol snmp source-address 172.16.64.0 255.255.252.0
class-map type http loadbalance match-all L7_URL*_CLASS
2 match http url .*
policy-map type management first-match L4_SNMP-REMOTE-MGT_POLICY
class L4_REMOTE-ACCESS-LOCAL_CLASS
permit
Cisco Application Control Engine Module Administration Guide
OL-20814-01
7-59
Chapter 7
Configuring SNMP
Example of an SNMP Configuration
policy-map type loadbalance first-match L7_LB-SF_MAX-CONN_POLICY
class L7_INDEX-HTML_CLASS
serverfarm SFARM1
class L7_URL*_CLASS
serverfarm SFARM2
policy-map multi-match L4_VIP_POLICY
class L4_MAX-CONN-VIP_105_CLASS
loadbalance vip inservice
loadbalance policy L7_LB-SF_MAX-CONN_POLICY
loadbalance vip icmp-reply
appl-parameter http advanced-options PERSIST-REBALANCE
service-policy input L4_REMOTE-MGT_POLICY
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
user user1 Network-Monitor auth sha “adcd1234”
community ACE-public group ro
contact “User1 user1@cisco.com”
location “San Jose CA”
host 192.168.0.236 traps version 2c ACE-public
enable traps slb vserver
enable traps slb real
enable traps syslog
enable traps snmp authentication
enable traps snmp linkup
enable traps snmp linkdown
Cisco Application Control Engine Module Administration Guide
7-60
OL-20814-01
CH A P T E R
8
Configuring the XML Interface
This chapter describes how to use Extensible Markup Language (XML) to remotely configure a Cisco
Application Control Engine (ACE) module from a network management station (NMS). You can
transmit, exchange, and interpret data among the applications.
This chapter contains the following major sections:
•
Information About XML
•
Guidelines and Limitations
•
Default Settings
•
Configuring the XML Interface
•
Displaying or Clearing XML Service Policy Statistics
•
Clearing XML Service Policy Statistics
•
Example of ACE CLI Command and the XML Equivalent
Information About XML
Web services provide network-based software applications that use XML to transmit, exchange, and
interpret data among applications that would otherwise have difficulty interoperating together.
XML provides an application-independent way of sharing data between computer systems. Similar to
HTML, XML consists of text delimited by tags so it is easily conveyed over the Internet. In XML, the
tags define the meaning and structure of the information, enabling computer applications to use the
information directly. Unlike HTML, XML tags identify the data, rather than specifying how to display
it. An XML tag acts like a field name in your program; it puts a label on a piece of data that identifies it
(for example: <message>...</message>).
An XML document that contains configuration commands and output results is easily transformed
between the devices by using standard Internet protocols. A network management station (NMS), such
as the CiscoWorks Hosting Solution Engine (HSE), can connect to the ACE and push new configurations
to it over HTTP or secure HTTP (HTTPS). Any command that you can configure from the ACE CLI can
be configured remotely from a NMS by exchanging XML documents over HTTP or HTTPS.
The XML application programming interface (API) allows you to automate the programmatic
configuration of the ACE by using a Document Type Definition (DTD). The XML format is a translation
of the CLI commands into an equivalent XML syntax. Each ACE CLI command has an equivalent XML
tag, and all of the parameters of the CLI command are attributes of that element. The ACE uses an
Apache HTTP server to provide the XML management interface and to provide HTTP services between
the ACE and the management client. To use the ACE XML API, you must have the Admin user role.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-1
Chapter 8
Configuring the XML Interface
Information About XML
You can use XML to do the following:
•
Provide a mechanism using XML to transfer, configure, and monitor objects in the ACE. This XML
capability allows you to easily shape or extend the CLI query and reply data in XML format to meet
different specific business needs.
•
Transfer show command output from the ACE CLI interface in an XML format for statistics and
status monitoring. This capability allows you to query and extract data from the ACE.
•
Use the ACE XML DTD schema for formatting CLI queries or parsing the XML results from the
ACE to enable third-party software development through XML communications.
•
Provide remote user authentication through AAA.
•
Provide session and context management by the global administrator and other privileged users that
have the Admin user role.
This section contains the following topics:
•
HTTP and HTTPS Support with the ACE
•
HTTP Return Codes
•
Document Type Definition
HTTP and HTTPS Support with the ACE
The ACE and an NMS can easily send and receive an XML document containing configuration
commands or output results by using standard Internet protocols, such as HTTP or secure HTTP
(HTTPS), as the transfer protocol. HTTPS uses Secure Sockets Layer (SSL) to provide encrypted
communication between the management client and the ACE.
The administrator of the system designates a website as the entry point to the API, and all requests and
queries are made through those URLs. This website also provides the DTDs that define the XML for
requests, queries, and responses.
The XML input is submitted through the data portion of an HTTP POST request. A field named “xml”
contains the XML string that defines the request or query. The response to this HTTP POST represents
a pure XML response with either a success or failure indicator for a request or the response to a query.
When you use XML to transfer configuration data and results, the NMS connects to the ACE and sends
a new configuration in an XML document to the ACE over HTTP or HTTPS. The ACE then applies the
new configuration.
The following example shows the HTTP conversation between the client and the server, as related to the
XML implementation on the ACE:
******** Client **************
POST /bin/xml_agent HTTP/1.1
Authorization: Basic VTpQ
Content-Length: 95
xml_cmd=<request_xml>
<interface type=”vlan” number=”80”>
<access-group access-type=”input” name=”acl1”/>
<ip_address address=”60.0.0.145” netmask=”255.255.255.0”/>
<shutdown sense=”no"/>
</interface>
<show_running-config/>
</request_xml>
******** Server **************
HTTP/1.1 200 OK
Content-Length: 21
Cisco Application Control Engine Module Administration Guide
8-2
OL-20814-01
Chapter 8
Configuring the XML Interface
Information About XML
<response_xml>
<config_command>
<command>
interface vlan 80
ip address 60.0.0.145 255.255.255.0
access-group input acl1
no shutdown
</command>
<status code="100" text="XML_CMD_SUCCESS"/>
</config_command>
</response_xml>
******** Client **************
POST /bin/xml_agent HTTP/1.1
Content-Length: 95
xml_cmd=<request_xml>
<show_running-config/>
</request_xml>
******** Server **************
HTTP/1.1 401 Unauthorized
Connection: close
WWW-Authenticate: Basic realm=/xml-config
HTTP Return Codes
HTTP return codes indicate the status of the request and reports errors between the server and the client.
The Apache HTTP server return status codes follow the standards outlined in RFC 2616. Table 8-1 lists
the supported HTTP return codes.
Table 8-1
Supported HTTP Return Codes for XML
Return Code
Description
200
OK
201
Created
202
Accepted
203
Non-Authoritative Information
206
Partial Content
301
Moved Permanently
302
Found
400
Bad Request
401
Unauthorized (credentials required, but not provided)
403
Forbidden (illegal credentials submitted; syslog also generated)
404
Not Found (“/xml-config” not specified)
405
Method Not Allowed
406
Not Acceptable
408
Request Time-out (more than 30 seconds has passed waiting on receive)
411
Missing Content-Length (missing or zero Content-Length field)
500
Internal Server Error
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-3
Chapter 8
Configuring the XML Interface
Information About XML
Table 8-1
Supported HTTP Return Codes for XML (continued)
Return Code
Description
501
Not Implemented (“POST” not specified)
505
HTTP Version Not Supported (“1.0” or “1.1” not specified)
The following HTTP headers are supported:
•
Content-Length (nonzero value required for all POSTs)
•
Connection (close value indicates that a request should not be persistent)
•
WWW-Authenticate (sent to the client when credentials are required and missing)
•
Authorization (sent from the client to specify basic credentials in base 64 encoding)
For example, when an XML error occurs, the HTTP response contains a 200 return code. The portion of
the original XML document with the error is returned with an error element that contains the error type
and description.
The following is a typical example of an XML error response:
<response_xml>
<config_command>
<command>
interface vlan 20
no shut
description xyz
exit
</command>
<status code = ‘200’ text=’XML_CMD_FAILURE’>
<error_command> description xyz </error_command>
<error_message> unrecognized element - description </error_message>
</status>
</config_command>
</response_xml>
The returned error codes correspond to the attributes of the configuration element. The possible returned
XML error can include any of the following:
XML_ERR_WELLFORMEDNESS
XML_ERR_ATTR_INVALID
XML_ERR_ELEM_INVALID
XML_ERR_CDL_NOT_FOUN
XML_ERR_INTERNAL
XML_ERR_COMM_FAILURE
XML_ERR_VSH_PARSER
XML_ERR_VSH_CONF_APPLY
/*
/*
/*
/*
/*
/*
/*
/*
not a well formed xml document */
found invalid value attribute */
found invalid value unrecognized */
parser cdl file not found */
internal memory or coding error */
communication failure */
vsh parse error on the given command */
vsh unable to apply the configuration */
Document Type Definition
A DTD is the basis for XML configuration documents that you create using the ACE. The purpose of a
DTD is to define the legal building blocks of an XML document by defining the document structure with
a list of legal elements.
DTD designates an XML list that specifies precisely which elements can appear in a request, query, or
response document. It also specifies the contents and attributes of the elements. A DTD can be declared
inline in your XML document or as an external reference.
Cisco Application Control Engine Module Administration Guide
8-4
OL-20814-01
Chapter 8
Configuring the XML Interface
Information About XML
The ACE DTD file, cisco_ace.dtd, is included as part of the software image and is accessible from a web
browser using either HTTP or HTTPS. See the “Accessing the ACE DTD File” section for details. You
can use a web browser to either directly access the cisco_ace.dtd file or open the cisco_ace.dtd file from
the Cisco ACE Module Management page.
The following example shows the sequence of ACE CLI commands for creating a real server followed
by the associated DTD XML rserver elements for the commands:
[no] rserver [host | redirect] name
[no] conn-limit max maxconns [min minconns]
[no] description string
[no] inservice
[no] ip address {ip_address}
[no] probe name
[no] weight number
**********************************************************************
Elements, Attributes and Entities required for rserver
**********************************************************************
-->
<!-probe-name is a string of length 1 to 32.
-->
<!ELEMENT probe_rserver EMPTY>
<!ATTLIST probe_rserver
sense
CDATA
#FIXED
"no"
probe-name
CDATA
#REQUIRED
>
<!-relocation-str length is 1 to 127
-->
<!ELEMENT webhost-redirection EMPTY>
<!ATTLIST webhost-redirection
sense
(yes | no)
#IMPLIED
relocation-string
CDATA
#REQUIRED
redirection-code
(301 | 302)
#IMPLIED
>
<!-type is optional for host.
ip, probe and weight are valid only when type = host.
address-type is valid only when type=host.
name length is 1 to 32.
webhost-redirection is valid only if type=redirect.
-->
<!ELEMENT rserver (description, ip_address, conn-limit, probe_rserver,
weight, inservice, webhost-redirection)*>
<!ATTLIST rserver
sense
CDATA
#FIXED
"no"
type
(redirect | host)
#IMPLIED
name
CDATA
#REQUIRED
>
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-5
Chapter 8
Configuring the XML Interface
Guidelines and Limitations
Guidelines and Limitations
To use the ACE XML interface, you must have the Admin user role.
The ACE creates two default user accounts at startup: admin and www. The admin user is the global
administrator and cannot be deleted. The ACE uses the www user account for the XML interface and
www cannot be deleted.
Caution
When you upgrade your ACE software to version A2(1.1) or higher, you must change the default www
user password if you have not already done so. Otherwise, after you upgrade the ACE software, the www
user will be disabled and you will not be able to use XML to remotely configure an ACE until you change
the default www user password. See Chapter 2, Configuring Virtualization, in the Cisco Application
Control Engine Module Virtualization Configuration Guide for details on changing a user account
password. In this case, the user would be www.
Default Settings
XML responses automatically appear in XML format if the corresponding CLI show command output
supports the XML format. However, if you are running commands on the CLI console or you are running
raw XML responses from NMS, the XML responses appear in regular CLI display format. See the
“Enabling the Display of Raw XML Request show Command Output in XML Format” section for
details. For details on the show command output supported in XML format, consult the cisco_ace.dtd
file.
Cisco Application Control Engine Module Administration Guide
8-6
OL-20814-01
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Configuring the XML Interface
This section describes how to configure the XML interface and contains the following topics:
•
Task Flow for Configuring XML
•
Configuring HTTP and HTTPS Management Traffic Services
•
Enabling the Display of Raw XML Request show Command Output in XML Format
•
Accessing the ACE DTD File
Task Flow for Configuring XML
Follow these steps to configure XML usage with the ACE:
Step 1
If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the
desired context. If necessary, log directly in to, or change to, the correct context.
host1/Admin# changeto C1
host1/C1#
The rest of the examples in this table use the Admin context, unless otherwise specified. For details on
creating contexts, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
Step 2
Enter configuration mode.
host1/Admin# config
Enter configuration commands, one per line. End with CNTL/Z.
host1/Admin(config)#
Step 3
Create a Layer 3 and Layer 4 class map to classify the HTTP or HTTPS management traffic that can be
received by the ACE.
host1/Admin(config)# class-map type management match-all HTTPS-ALLOW_CLASS
host1/Admin(config-cmap-mgmt)# match protocol https source-address 192.168.1.1
255.255.255.255
host1/Admin(config-cmap-mgmt)# exit
Step 4
Configure a Layer 3 and Layer 4 HTTP or HTTPS traffic management policy.
host1/Admin(config) # policy-map type management first-match MGMT_HTTPS_POLICY
host1/Admin(config-pmap-mgmt) # class HTTPS-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c) # permit
host1/Admin(config-pmap-mgmt-c) # exit
Step 5
Attach the traffic policy to a single interface or globally on all VLAN interfaces associated with a
context, and specify the direction in which the policy should be applied. For example, to specify an
interface VLAN and apply multiple service policies to the VLAN, enter:
host1/Admin(config)# interface vlan50
host1/Admin(config-if)# ip address 192.168.10.1 255.255.0.0
host1/Admin(config-if)# service-policy input MGMT_HTTPS_POLICY
host1/Admin(config-if)# exit
host1/Admin(config)# exit
Step 6
(Optional) Enable the display of raw XML request show command output in XML format.
Note
True XML responses always automatically appear in XML format.
host1/Admin# xml-show on
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-7
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Step 7
(Optional) Save your configuration changes to Flash memory.
host1/Admin# copy running-config startup-config
Configuring HTTP and HTTPS Management Traffic Services
This section describes how to configure HTTP and HTTPS remote management traffic to the ACE
through class maps, policy maps, and service policies. The ACE provides support for remote
management using XML over either HTTP or HTTPS to configure, monitor, and manage software
objects.
The following items summarize the role of each function in configuring HTTP or HTTPS network
management access to the ACE:
•
Class map—Provides the remote network traffic match criteria to permit HTTP and HTTPS
management traffic based on HTTP or HTTPS network management protocols or host source IP
addresses.
•
Policy map—Enables remote network management access for a traffic classification that matches
the criteria listed the class map.
•
Service policy—Activates the policy map and attaches the traffic policy to an interface or globally
on all interfaces.
HTTP or HTTPS sessions are established to the ACE per context. For details on creating contexts and
users, see the Cisco Application Control Engine Module Virtualization Configuration Guide.
This section contains the following topics:
•
Creating and Configuring a Class Map
•
Creating a Layer 3 and Layer 4 Policy Map
•
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
•
Applying a Service Policy to a Specific VLAN Interface
Creating and Configuring a Class Map
This section describes how to create a Layer 3 and Layer 4 class map to classify the HTTP or HTTPS
management traffic that can be received by the ACE. This process allows network management traffic
by identifying the incoming IP protocols that the ACE can receive and the client source host IP address
and subnet mask as the matching criteria.
A class map of type management defines the allowed network traffic as a form of management security
for protocols such as HTTP or HTTPS. A class map can include multiple match commands. You can
configure class maps to define multiple HTTP or HTTPS management protocol or source IP address
match commands in a group that you then associate with a traffic policy. The match-all and match-any
keywords determine how the ACE evaluates multiple match statements operations when multiple match
criteria exist in a class map.
Cisco Application Control Engine Module Administration Guide
8-8
OL-20814-01
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
class-map type management [match-all
| match-any] map_name
Creates a Layer 3 and Layer 4 class map to classify the HTTP or HTTPS
management traffic that can be received by the ACE.
Example:
host1/Admin(config)# class-map type
management match-all
HTTPS-ALLOW_CLASS
host1/Admin(config-cmap-mgmt)#
The keyword options and argument are as follows:
•
match-all | match-any—(Optional) Determines how the ACE
evaluates Layer 3 and Layer 4 network traffic when multiple match
criteria exist in a class map. The class map is considered a match if
the match commands meet one of the following conditions:
– match-all—(Default) All of the match criteria listed in the
class map match the network traffic class in the class map.
– match-any—Only one of the match criteria listed in the class
map matches the network traffic class in the class map.
•
map_name—Name assigned to the class map. Enter an unquoted
text string with no spaces and a maximum of 64 alphanumeric
characters. The class name is used for both the class map and to
configure a policy for the class in the policy map.
This command enters the class map management configuration mode.
no class-map type management
[match-all | match-any] map_name
(Optional) Removes a Layer 3 and Layer 4 network management class
map from the ACE.
Example:
host1/Admin(config)# no class-map
type management match-all
HTTPS-ALLOW_CLASS
Step 3
description text
Example:
host1/Admin(config-cmap-mgmt)#
description Allow HTTPS access to
the ACE
no description
Provides a brief summary about the Layer 3 and Layer 4 remote
management class map.
The text argument is the description that you want to provide. Enter an
unquoted text string with a maximum of 240 alphanumeric characters.
(Optional) Remove the description from the class map.
Example:
host1/Admin(config-cmap-mgmt)# no
description
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-9
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Step 4
Command
Purpose
[line_number] match protocol {http
| https} {any | source-address
ip_address mask}
Configures the class map to specify that the HTTP or HTTPS remote
network management protocol can be received by the ACE. You
configure the associated policy map to permit access to ACE for the
specified management protocol. For XML support, a class map of type
management allows IP protocols such as HTTP and HTTPS. As part of
the network management access traffic classification, you also specify
either a client source host IP address and subnet mask as the matching
criteria or instruct the ACE to allow any client source address for the
management traffic classification.
Example:
host1/Admin(config-cmap-mgmt)# match
protocol https source-address
192.168.10.1 255.255.0.0
You can include multiple match protocol commands in a class map.
The keywords, arguments, and options are as follows:
no match protocol {http | https}
{any | source-address ip_address
mask}
•
line_number—(Optional) Line number that allows you to edit or
delete individual match commands. Enter an integer from 2 to 255
as the line number. For example, you can enter no line_number to
delete long match commands instead of entering the entire line.
•
http—Configures management access between the ACE HTTP
server and the management client over HTTP.
•
https—Configures management access between the ACE HTTP
server and the management client over secure HTTP.
•
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.
•
mask—Subnet mask of the client in dotted-decimal notation (for
example, 255.255.255.0).
(Optional) Deselects the specified network management protocol match
criteria from the class map.
Example:
host1/Admin(config-cmap-mgmt)# no
match protocol https source-address
192.168.10.1 255.255.0.0
Step 5
do copy running-config
startup-config
(Optional) Copies the running configuration to the startup
configuration.
Example:
host1/Admin(config-cmap-mgmt)# do
copy running-config startup-config
Creating a Layer 3 and Layer 4 Policy Map
This section describes how to create a Layer 3 and Layer 4 policy map, associate a class map with the
policy map, and specify the policy map actions. A Layer 3 and Layer 4 policy map defines the actions
executed on HTTP or HTTPS management traffic that matches the specified classifications.
Cisco Application Control Engine Module Administration Guide
8-10
OL-20814-01
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
policy-map type management first-match
map_name
Example:
host1/Admin(config)# policy-map type
management first-match MGMT_HTTPS_POLICY
host1/Admin(config-pmap-mgmt)#
Configures a Layer 3 and Layer 4 policy map that permits the
management traffic received by the ACE. The ACE executes the
action for the first matching classification. The ACE does not
execute any additional actions.
The map_name argument specifies the name assigned to the
Layer 3 and Layer 4 network management policy map. Enter an
unquoted text string with no spaces and a maximum of
64 alphanumeric characters.
This command enters the policy map management configuration
mode.
no policy-map type management first-match
map_name
(Optional) Removes a network traffic management policy map
from the ACE.
Example:
host1/Admin(config)# no policy-map type
management first-match MGMT_HTTPS_POLICY
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-11
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Step 3
Command
Purpose
class {name1 [insert-before name2] |
class-default}
Associates the HTTP or HTTPS management traffic class map
with the traffic policy.
Example:
host1/Admin(config-pmap-mgmt)# class
HTTPS-ALLOW_CLASS
host1/Admin(config-pmap-mgmt-c)#
The arguments, keywords, and options are as follows:
•
name1—Name of a previously defined Layer 3 and Layer 4
traffic class, configured with the class-map command, to
associate traffic to the traffic policy. Enter an unquoted text
string with no spaces and a maximum of 64 alphanumeric
characters.
•
insert-before name2—(Optional) Places the current class
map ahead of an existing class map or inline match condition
specified by the name2 argument in the policy map
configuration. The ACE does not save the sequence
reordering as part of the configuration. Enter an unquoted
text string with no spaces and a maximum of
64 alphanumeric characters.
•
class-default—Specifies the class-default class map for the
Layer 3 and Layer 4 traffic policy. This class map is a
reserved class map created by the ACE. You cannot delete or
modify this class. All network traffic that fails to meet the
other matching criteria in the named class map belongs to the
default traffic class. If none of the specified classifications
match, the ACE then matches the action specified under the
class class-default command. The class-default class map
has an implicit match any statement in it and is used to
match any traffic classification.
This command enters the policy map management class
configuration mode.
no class name1
Example:
host1/Admin(config-cmap-mgmt)# class
HTTPS-ALLOW_CLASS
Step 4
permit
Example:
host1/Admin(config-pmap-mgmt-c)# permit
no permit
Example:
host1/Admin(config-pmap-mgmt-c)# no permit
deny
Example:
host1/Admin(config-pmap-mgmt-c)# deny
(Optional) Removes a class map from a Layer 3 and Layer 4
policy map.
Allows the HTTP or HTTPS management traffic listed in the
Layer 3 and Layer 4 class map to be received by the ACE.
(Optional) Disallows the HTTP or HTTPS management traffic
listed in the Layer 3 and Layer 4 class map to be received by the
ACE.
Denies the HTTP or HTTPS management traffic listed in the
Layer 3 and Layer 4 class map to be received by the ACE.
Cisco Application Control Engine Module Administration Guide
8-12
OL-20814-01
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Command
Purpose
no deny
Allows the HTTP or HTTPS management traffic listed in the
Layer 3 and Layer 4 class map to be received by the ACE.
Example:
host1/Admin(config-pmap-mgmt-c)# no deny
Step 5
do copy running-config startup-config
Example:
host1/Admin(config-pmap-mgmt-c)# do copy
running-config startup-config
(Optional) Copies the running configuration to the startup
configuration.
Examples
The following example shows how to use the insert-before command to define the sequential order of
two class maps in the policy map:
host1/Admin(config-pmap-mgmt)# class HTTPS-ALLOW_CLASS insert-before
L4_REMOTE_ACCESS_CLASS
The following example shows how to specify the class-default class map for the Layer 3 and Layer 4
traffic policy:
host1/Admin(config-pmap-mgmt)# class class-default
host1/Admin(config-pmap-mgmt-c)#
Applying a Service Policy Globally to All VLAN Interfaces in the Same Context
This section describes how to apply an existing policy map globally to all VLAN interfaces in the same
context.
Note the following guidelines when applying a service policy:
Note
•
Policy maps, applied globally in a context, are internally applied on all interfaces existing in the
context.
•
A policy activated on an interface overwrites any specified global policies for overlapping
classification and actions.
To apply the policy map to a specific VLAN interface only, see the “Applying a Service Policy to a
Specific VLAN Interface” section.
Restrictions
The ACE allows only one policy of a specific feature type to be activated on an interface.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-13
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
service-policy input policy_name
Example:
host1/Admin(config)# service-policy input
MGMT_HTTPS_POLICY
no service-policy input policy_name
Example:
host1/Admin(config)# no service-policy
input MGMT_HTTPS_POLICY
Step 3
do copy running-config startup-config
Example:
host1/Admin(config)# do copy
running-config startup-config
Globally applies the management policy map to all of the VLANs
associated with a context.
The keywords and arguments are as follows:
•
input—Specifies that the traffic policy is to be attached to
the input direction of an interface. The traffic policy
evaluates all traffic received by that interface.
•
policy_name—Name of a previously defined policy map,
configured with a previously created policy-map command.
The name can be a maximum of 40 alphanumeric characters.
(Optional) Removes the management policy map from all of the
VLANs associated with a context.
When you remove a policy, the ACE automatically resets the
associated service policy statistics to provide a new starting point
for the service policy statistics the next time that you attach a
traffic policy to a specific VLAN interface or globally to all
VLAN interfaces in the same context.
(Optional) Copies the running configuration to the startup
configuration.
Applying a Service Policy to a Specific VLAN Interface
This section describes how to apply an existing policy map to a specific VLN interface. A policy
activated on an interface overwrites any specified global policies for overlapping classification and
actions.
Note
To apply the policy map globally to all VLAN interfaces in the same context, see the “Applying a Service
Policy Globally to All VLAN Interfaces in the Same Context” section.
Restrictions
The ACE allows only one policy of a specific feature type to be activated on an interface.
Cisco Application Control Engine Module Administration Guide
8-14
OL-20814-01
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Detailed Steps
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
Step 3
interface vlan number
Specifies an interface VLAN.
Example:
host1/Admin(config)# interface vlan 50
host1/Admin(config-if)#
The number argument is the number for a VLAN assigned to the
ACE
ip address address
Specifies the VLAN IP address.
This commands enters the interface configuration mode
commands for the VLAN.
Example:
host1/Admin(config-if)# ip address
192.168.10.1 255.255.0.0
Step 4
service-policy input policy_name
Applies the management policy map to the VLAN.
Example:
host1/Admin(config-if)# service-policy
input MGMT_HTTPS_POLICY
The keywords and arguments are as follows:
no service-policy input policy_name
Example:
host1/Admin(config-if)# no service-policy
input MGMT_HTTPS_POLICY
Step 5
do copy running-config startup-config
Example:
host1/Admin(config-if)# do copy
running-config startup-config
•
input—Specifies that the traffic policy is to be attached to
the input direction of an interface. The traffic policy
evaluates all traffic received by that interface.
•
policy_name—Name of a previously defined policy map,
configured with a previously created policy-map command.
The name can be a maximum of 40 alphanumeric characters.
(Optional) Removes the management policy from an interface
VLAN.
When you remove a policy, the ACE automatically resets the
associated service policy statistics to provide a new starting point
for the service policy statistics the next time that you attach a
traffic policy to a specific VLAN interface or globally to all
VLAN interfaces in the same context.
(Optional) Copies the running configuration to the startup
configuration.
Enabling the Display of Raw XML Request show Command Output in XML
Format
This section describes how to enable the display of raw XML request show command output in XML
format. By default, XML responses will automatically appear in XML format if the corresponding CLI
show command output supports the XML format. However, if you are running commands on the CLI
console or you are running raw XML responses from NMS, the XML responses appear in regular CLI
display format.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-15
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
You can enable the display of raw XML request show command output in XML format by performing
one of the following actions:
•
Specifying the xml-show on command in Exec mode from the CLI.
•
Including the xml-show on command in the raw XML request itself (CLI commands included in an
XML wrapper).
Selection of the xml-show on command is not required if you are running true XML (as shown in the
example below).
For details on the show command output supported in XML format, consult the ACE DTD file,
cisco_ace.dtd, that is included as part of the software image (see the “Accessing the ACE DTD File”
section). The ACE DTD file contains the information on the XML attributes for those show commands
that have output that supports the XML format.
For example, if you specify the show interface vlan 10 command, the DTD for the show interface
command appears as follows:
<!-interface-number is req for show-type vlan | bvi.
interface-number is between 1 and 4095 for vlan and 8191 for bvi.
-->
<!ENTITY % show-interface
"interface-type
(vlan | bvi | eobc)
#IMPLIED
interface-number
CDATA
#IMPLIED”
>
The XML representation of the show interface command appears as follows:
<show_interface interface-type='vlan' interface-number='10'/>
The following example illustrates the XML representation of the show interface command output:
<response_xml>
<exec_command>
<command>
show interface vlan 10
</command>
<status code="100" text="XML_CMD_SUCCESS"/>
<xml_show_result>
<xml_show_interface>
<xml_interface_entry>
<xml_interface>
<interface_name>vlan10</interface_name>
<interface_status>up</interface_status>
<interface_hardware>VLAN</interface_hardware>
<interface_mac>
<macaddress>00:05:9a:3b:92:b1</macaddress>
</interface_mac>
<interface_mode>routed</interface_mode>
<interface_ip>
<ipaddress>10.20.105.101</ipaddress>
<ipmask>255.255.255.0</ipmask>
</interface_ip>
<interface_ft_status>non-redundant</interface_ft_status>
<interface_description>
<interface_description>not set</interface_description>
</interface_description>
<interface_mtu>1500</interface_mtu>
<interface_last_cleared>never</interface_last_cleared>
<interface_alias>
<ipaddress>not set</ipaddress>
</interface_alias>
Cisco Application Control Engine Module Administration Guide
8-16
OL-20814-01
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
<interface_standby>
<ipaddress>not set</ipaddress>
</interface_standby>
<interface_sup_enabled>Assigned</interface_sup_enabled>
<interface_auto_status>up</interface_auto_status>
</xml_interface>
<interface_stats>
<ifs_input>
<ifs_unicast>50</ifs_unicast>
<ifs_bytes>8963</ifs_bytes>
<ifs_multicast>26</ifs_multicast>
<ifs_broadcast>1</ifs_broadcast>
<ifs_errors>0</ifs_errors>
<ifs_unknown>0</ifs_unknown>
<ifs_ignored>0</ifs_ignored>
<ifs_unicast_rpf>0</ifs_unicast_rpf>
</ifs_input>
<ifs_output>
<ifs_unicast>45</ifs_unicast>
<ifs_bytes>5723</ifs_bytes>
<ifs_multicast>0</ifs_multicast>
<ifs_broadcast>1</ifs_broadcast>
<ifs_errors>0</ifs_errors>
<ifs_ignored>0</ifs_ignored>
</ifs_output>
</interface_stats>
</xml_interface_entry>
</xml_show_interface>
</xml_show_result>
</exec_command>
</response_xml>
Details
Command
Purpose
xml-show {off | on | status}
Enables the display of raw XML request show command
output in XML format.
Example:
host1/Admin# xml-show on
The keywords are as follows:
•
off—Displays CLI show command output in regular CLI
display output, not in XML format.
•
on—Displays CLI show command output in XML format
unless a specific show command is not implemented to
display its output in XML format. For details on the show
command output supported in XML format, consult the
the ACE DTD file, cisco_ace.dtd, that is included as part
of the software image (see the “Accessing the ACE DTD
File” section).
•
status—Displays the results of the xml show command
status: on or off. The status keyword allows you to
determine the status of the xml show command setting.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-17
Chapter 8
Configuring the XML Interface
Configuring the XML Interface
Accessing the ACE DTD File
This section describes how to access the ACE DTD file to perform one of the following tasks:
•
Directly access the cisco_ace.dtd file.
•
Open the cisco_ace.dtd file from the Cisco ACE Module Management page.
The ACE DTD file, cisco_ace.dtd, is included as part of the software image and is accessible from a web
browser using either HTTP or HTTPS.
Details
Perform these steps to access and display the Cisco ACE DTD 3.0 file:
Step 1
If you have not done so, create a Layer 3 and Layer 4 class map and policy map to classify the HTTP or
HTTPS management traffic that can be received by the ACE. See the “Configuring HTTP and HTTPS
Management Traffic Services” section.
Step 2
Open your preferred Internet web browser application, such as Microsoft Internet Explorer or Netscape
Navigator.
Step 3
Access the cisco_ace.dtd file.
To directly access the cisco_ace.dtd file, specify the HTTP or secure HTTP (HTTPS) address of your ACE
in the address field, followed by cisco_ace.dtd. For example, enter:
https://ace_ip_address/cisco_ace.dtd
http://ace_ip_address/cisco_ace.dtd
You can choose to either open the cisco_ace.dtd file or save it to your computer.
To access the cisco_ace.dtd file from the Cisco ACE ModuleManagement page, perform the following
steps:
a.
Specify the HTTP or secure HTTP (HTTPS) address of your ACE in the address field:
https://ace_ip_address
http://ace_ip_address
b.
Click Yes at the prompt to accept (trust) and install the signed certificate from Cisco. To install the
signed certificate, do one of the following:
– If you are using Microsoft Internet Explorer, in the Security Alert dialog box, click View
Certificate, choose the Install Certificate option, and follow the prompts of the Certificate
Manager Import Wizard.
– If you are using Netscape Navigator, in the New Site Certificate dialog box, click Next and
follow the prompts of the New Site Certificate Wizard.
c.
Enter your username and password in the fields provided, and then click OK. The Cisco ACE Module
Management page appears.
d.
Click the CISCO ACE DTD 3.0 link under the Resources column of the Cisco ACE Module
Management page to access the cisco_ace.dtd file. You can choose to either open the cisco_ace.dtd
file or save it to your computer.
Cisco Application Control Engine Module Administration Guide
8-18
OL-20814-01
Chapter 8
Configuring the XML Interface
Displaying or Clearing XML Service Policy Statistics
Displaying or Clearing XML Service Policy Statistics
This section describes how to display or clear XML service policy statistics and contains the following
topics:
•
Displaying XML Service Policy Statistics
•
Clearing XML Service Policy Statistics
Displaying XML Service Policy Statistics
To display the statistical information of the service policies associated with your XML configuration,
perform the following task:
Command
Purpose
show service-policy policy_name [detail]
Displays service policy statistics for a Layer 3 and Layer 4 management
policy map.
The keywords, options, and arguments are as follows:
•
policy_name—Identifier of an existing policy map that is currently in
service (applied to an interface) as an unquoted text string with a
maximum of 64 alphanumeric characters.
•
detail—(Optional) Displays a more detailed listing of policy map
statistics and status information.
Note
The ACE updates the counters that the show service-policy
command displays after the applicable connections are closed.
Examples
The following example shows the output for the MGMT_HTTPS_POLICY policy map by using the
show service-policy command:
host1/Admin# show service-policy MGMT_HTTPS_POLICY
Status
: ACTIVE
Description: Allow mgmt protocols
----------------------------------------Context Global Policy:
service-policy: MGMT_HTTPS_POLICY
Clearing XML Service Policy Statistics
To clear the statistical information of the service policies associated with your XML configuration,
perform the following task:
Command
Purpose
clear service-policy policy_name
Clears the service policy statistics.
For the policy_name argument, enter the identifier of an existing policy map
that is currently in service (applied to an interface) as an unquoted text
string with a maximum of 64 alphanumeric characters.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
8-19
Chapter 8
Configuring the XML Interface
Example of ACE CLI Command and the XML Equivalent
Example of ACE CLI Command and the XML Equivalent
The following example shows a typical VShell (VSH) CLI command configuration and its equivalent
XML configuration commands:
##############################
## TO/FROM CP CONFIGURATION ##
##############################
conf t
access-list acl1 extended permit ip any any
int vlan 80
access-group input acl1
ip address 60.0.0.145 255.255.255.0
no shut
exit
ip route 0.0.0.0 0.0.0.0 60.0.0.1
end
<access-list id="acl1" config-type="extended" perm-value="permit"
protocol-name="ip" src- type="any" dest-type="any"/>
<interface type="vlan" number="80">
<access-group type="input" name="acl1"/>
<ip_address address="60.0.0.145" netmask="255.255.255.0"/>
<shutdown sense="no"/>
</interface>
<ip_route dest-address="0.0.0.0" dest-mask="0.0.0.0"
gateway="60.0.0.1"/>
############################
## BRIDGING CONFIGURATION ##
############################
conf t
access-list acl1 extended permit ip any any
int vlan 80
access-group input acl1
bridge-group 1
no shut
exit
int vlan 90
access-group input acl1
bridge-group 1
no shut
exit
end
<access-list id="acl1" config-type="extended" perm-value="permit"
protocol-name="ip" src-type="any" dest-type="any"/>
<interface type="vlan" number="80">
<access-group type="input" name="acl1"/>
<bridge-group value="1"/>
<shutdown sense="no"/>
</interface>
<interface type="vlan" number="90">
<access-group type="input" name="acl1"/>
<bridge-group value="1"/>
<shutdown sense="no"/>
</interface>
Cisco Application Control Engine Module Administration Guide
8-20
OL-20814-01
A P P E N D I X
A
Upgrading or Downgrading Your ACE Software
This appendix provides information to upgrade your Cisco Application Control Engine (ACE) module.
It contains the following major sections:
•
Overview of Upgrading ACE Software
•
Prerequisites for Upgrading Your ACE
•
Performing Software Upgrades and Downgrades
•
Displaying Software Image Information
Overview of Upgrading ACE Software
Your ACE comes preloaded with the operating system software. To take advantage of new features and
bug fixes, you can upgrade your ACE with a new version of software when it becomes available.
In the Admin context, you will use the copy command in Exec mode to manually install the software on
each ACE. After the software installation is finished, set the boot variable and configuration register to
autoboot the software image. Then, reload the modules to load the new image.
To minimize any disruption to existing network traffic during a software upgrade or downgrade, deploy
your ACE modules in a redundant configuration. For details about redundancy, see Chapter 6,
Configuring Redundant ACEs.
Note
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 or not in the ip address command. If you are using HTTPS probes in your A1(6.x)
configuration with the default SSL version (SSLv3) or without the routed option, you may observe that
your HTTPS probes behave differently with version A2(1.0). For more information about HTTPS
probes, see the Cisco Application Control Engine Module Server Load-Balancing Configuration Guide.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-1
Appendix A
Upgrading or Downgrading Your ACE Software
Prerequisites for Upgrading Your ACE
Prerequisites for Upgrading Your ACE
Before you upgrade your ACE software, please read this appendix in its entirety so that you fully
understand the entire upgrade process. 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
•
Creating a Checkpoint
•
Updating Your Application Protocol Inspection Configurations
Changing the Admin Password
Before you upgrade to software version A2(1.1) or higher, you must change the default Admin password
if you have not already done so. Otherwise, after you upgrade the ACE software, you will be able to log
in to the ACE only through the console port or through the supervisor engine of the Catalyst 6500 series
switch or the Cisco 7600 series router. For details about changing the Admin password, see Chapter 1,
Setting Up the ACE.
Changing the www User Password
Before you upgrade to software version A2(1.1) or higher, you must change the default www user
password if you have not already done so. Otherwise, after you upgrade the ACE software, the www user
will be disabled and you will not be able to use Extensible Markup Language (XML) to remotely
configure an ACE until you change the default www user password. For details about changing the www
user password, see Chapter 2, Configuring Virtualization in the Cisco Application Control Engine
Module Virtualization Configuration Guide. In this case, the username would be www.
Checking Your Configuration for FT Priority and Preempt
If you want the currently active ACE to remain active after the software upgrade, be sure that the active
ACE has a higher priority than the standby (peer) ACE and that the preempt command is configured. To
check the redundant configuration of your ACEs, use the show running-config ft command. Note that
the preempt command is enabled by default and does not appear in the running-config.
Creating a Checkpoint
We strongly recommend that you create a checkpoint in the running-configuration file of each context
in your ACE. A checkpoint creates a snapshot of your configuration that you can later roll back to in
case a problem occurs with an upgrade and you want to downgrade the software to a previous release.
Use the checkpoint create command in Exec mode in each context for which you want to create a
configuration checkpoint and name the checkpoint. For details about creating a checkpoint and rolling
back a configuration, see Chapter 4, Managing the ACE Software. For information about downgrading
your ACE, see the Downgrading Your ACE Software section in the Release Note for the Cisco
Application Control Engine Module.
Cisco Application Control Engine Module Administration Guide
A-2
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Prerequisites for Upgrading Your ACE
Updating Your Application Protocol Inspection Configurations
Because the ACE version A2(1.x) software has stricter error checks for application protocol inspection
configurations than A1(x) software versions, be sure that your inspection configurations meet the
guidelines that follow. The error checking process in A2(1.x) software denies misconfigurations in
inspection classifications (class maps) and displays error messages. If such misconfigurations exist in
your startup- or running-configuration file before you load the A2(1.x) software, the standby ACE in a
redundant configuration may boot up to the STANDBY_COLD state. For information about redundancy
states, see Chapter 6, Configuring Redundant ACEs.
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:
host1/Admin(config)# class-map match-all TCP_ANY
host1/Admin(config-cmap)# match port tcp any
host1/Admin(config)# policy-map multi-match FTP_POLICY
host1/Admin(config-pmap)# class TCP_ANY
host1/Admin(config-pmap-c)# inspect ftp
Error: This class doesn't have tcp protocol and a specific port
The following examples show some of the generic class-map match statements and an ACL that are not
allowed in A2(1.x) inspection configurations:
•
match port tcp any
•
match port udp any
•
match port tcp range 0 65535
•
match port udp range 0 65535
•
match virtual-address 192.168.12.15 255.255.255.0 any
•
match virtual-address 192.168.12.15 255.255.255.0 tcp any
•
access-list acl1 line 10 extended permit ip any any
For application protocol inspection, the class map must have a specific protocol (related to the inspection
type) configured and a specific port or range of port numbers.
For HTTP, FTP, RTSP, Skinny, and ILS protocol inspection, the class map must have TCP as the
configured protocol and a specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port tcp eq www
For SIP protocol inspection, the class map must have TCP or UDP as the configured protocol and a
specific port or range of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port tcp eq 124
or
host1/Admin(config-cmap)# match port udp eq 135
For DNS inspection, the class map must have UDP as the configured protocol and a specific port or range
of ports. For example, enter the following commands:
host1/Admin(config)# class-map match-all L4_CLASS
host1/Admin(config-cmap)# match port udp eq domain
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-3
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
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
Performing Software Upgrades and Downgrades
This section describes how to perform software upgrades and downgrades. It contains the following
topics:
•
Task Flow for Upgrading the ACE Software
•
Task Flow for Downgrading the ACE Software
•
Copying the Software Upgrade Image to the ACE
•
Configuring the ACE to Autoboot the Software Image
•
Reloading the ACE
•
Recovering the ACE from the ROMMON Utility
Task Flow for Upgrading the ACE Software
This section provides a quick overview of the steps required to upgrade the software on each ACE. For
clarity, the original active ACE is referred to as ACE-1 and the original standby ACE is referred to as
ACE-2 in the following quick start.
Follow these steps to upgrade the ACE software:
Step 1
Log in to each ACE. 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 by entering the changeto command.
switch login: admin
Password: xxxxxxxx
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2009, 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.
User 'www' is disabled.Please change the password to enable the user.
ACE-1/Admin#
Step 2
Save the running configurations of every context by entering the write memory all command in Exec
mode in the Admin context of each ACE.
ACE-1/Admin# write memory all
Cisco Application Control Engine Module Administration Guide
A-4
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Step 3
Create a checkpoint in each context of both ACEs by entering the checkpoint create command in Exec
mode.
ACE-1/Admin# checkpoint create ADMIN_CHECKPOINT
ACE-1/Admin# changeto C1
ACE-1/C1# checkpoint create C1_CHECKPOINT
Step 4
Return to the Admin context:
ACE-1/C1# changeto Admin
ACE-1/Admin#
Step 5
Enter either the copy ftp, copy sftp, or the copy tftp command in Exec mode to copy the new software
image to the image: directory of each ACE. For example, to copy the image with the name
c6ace-t1k9_A2_3_0.bin using FTP, enter:
ACE-1/Admin# copy ftp://server1/images/c6ace-t1k9-mz.A2_3_0.bin image:
Enter source filename[/images/c6ace-t1k9-mz.A2_3_0.bin]?
Enter the destination filename[]? [c6ace-t1k9-mz.A2_3_0.bin] File already exists, do you
want to overwrite?[y/n]: [y]
Enter hostname for the ftp server[server1]?
Enter username[]? user1
Enter the file transfer mode[bin/ascii]: [bin]
Enable Passive mode[Yes/No]: [Yes] no
Password:
Step 6
Ensure that the new software image is present on both the active and standby ACEs by entering the dir
command in Exec mode. For example, enter:
ACE-1/Admin# dir image:c6ace-t1k9-mz.A2_3_0.bin
176876624 Aug 08 2009 14:15:31 c6ace-t1k9_A2_3_0.bin
176876624 Jun 9 14:15:31 2008 c4710ace-mz.A2_1_0.bin
Usage for image: filesystem
896978944 bytes total used
11849728 bytes free 908828672 bytes total
Step 7
Check the MD5 checksum of the new software image on both ACEs to ensure that the new image is the
same as the image posted on Cisco.com. For example, enter:
ACE-1/Admin# show file image:c6ace-t1k9-mz.A2_3_0.bin md5sum
Step 8
Configure ACE-1 to automatically boot from the new image. To set the boot variable and configuration
register to 1 (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
ACE-1/Admin(config)# boot system image:c6ace-t1k9-mz.A2_3_0.bin
ACE-1/Admin(config)# config-register 1
ACE-1/Admin(config)# exit
ACE-1/Admin#
You can set up to two images through the boot system command. If the first image fails, the ACE tries
to boot from the second image.
Note
Step 9
Use the no boot system image: command to remove the previously configured boot variable.
Verify that the boot variable was synchronized with ACE-2 by entering the following command on
ACE-2:
ACE-2/Admin# show bootvar
BOOT variable = “disk0:c6ace-t1k9-mz.A2_3_0.bin”
Configuration register is 1
ACE-2/Admin#
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-5
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Step 10
Enter the show ft group detail command in Exec mode 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 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.
During the upgrading and downgrading of the ACE software, the ACE uses the STANDBY_WARM and
WARM_COMPATIBLE redundancy states to handle any CLI incompatibility issue between peers. For
information about redundancy states, see Chapter 6, Configuring Redundant ACEs.
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 ACE-1 configuration may not be
properly synchronized to the ACE-2 configuration.
Note
If you upgrade from software version A2(1.3) or earlier to A2(3.0), you will see that the ACE
enters the STANDBY_HOT state. However, if you upgrade from A2(1.4) or later to A2(3.0), you
will se that the ACE enters the STANDBY_WARM state.
ACE-2/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 11
Disable preemption on ACE-1.
ACE-1/Admin# config
ACE-1/Admin(config)# ft group 1
ACE-1/Admin(config-ft-group)# no preempt
Press Ctrl-z to return to Exec mode.
Step 12
Perform a graceful failover of all contexts from ACE-1 to ACE-2 by entering the ft switchover all
command in Exec mode on ACE-1. ACE-2 becomes the new active ACE and assumes mastership of all
active connections with no interruption to existing connections.
ACE-1/Admin# ft switchover all
Step 13
Upgrade ACE-1 by reloading it and verify that ACE-1 enters the STANDBY_HOT state (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, configuration mode is enabled. The configuration
is synchronized from ACE 2 (currently active) to ACE-1.
ACE-1/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Step 14
Reenable preempt on the FT group on ACE-2. If ACE-1 is configured with a higher priority and
preempt is configured on the FT group, ACE-1 reasserts mastership after it has received all
configuration and state information from ACE-2, making ACE-2 the new standby. ACE-1 becomes the
active ACE once again.
ACE-2/Admin# config
ACE-2/Admin(config)# ft group 1
ACE-2/Admin(config-ft-group)# preempt
Press Ctrl-z to return to Exec mode.
Cisco Application Control Engine Module Administration Guide
A-6
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Step 15
Enter the show ft group detail command to verify that ACE-1 is in the ACTIVE state and ACE-2 is in
the STANDBY_HOT state.
Task Flow for Downgrading the ACE Software
This section provides a quick overview of the steps required to downgrade the software on each ACE.
For clarity, the original active ACE is referred to as ACE-1 and the original standby ACE is referred to
as ACE-2 in the following quick start.
Follow these steps to downgrade the ACE software:
Step 1
Step 2
Before you downgrade your ACE software, ensure that the following conditions exist:
•
Identical versions of the desired downgrade 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 license that was not supported by the previous software version, ensure that you
remove this and reinstall the previous license.
See Chapter 3, Managing ACE Software Licenses, in the Cisco Application Control Engine Module
Administration Guide.
Step 3
Log in to the ACE. 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.
switch login: admin
Password: xxxxxxxx
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2009, 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.
User 'www' is disabled.Please change the password to enable the user.
ACE-1/Admin#
Step 4
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 5
If you had created checkpoints in your previous running-configuration files (highly recommended), roll
back the configuration in each context on each ACE to the check-pointed configuration.
For example:
ACE-1/Admin# checkpoint create ADMIN_CHECKPOINT
ACE-1/Admin# changeto C1
ACE-1/C1# checkpoint create C1_CHECKPOINT
For information about creating checkpoints and rolling back configurations, see the Cisco Application
Control Engine Module Administration Guide.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-7
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Step 6
If necessary, enter the copy ftp, copy sftp, or the copy tftp command in Exec mode to copy the
downgrade software image to the image: directory of each ACE. For example, to copy the image with
the name c6ace-t1k9-mz.A2_3_0.bin using FTP, enter:
ACE-1/Admin# copy ftp://server1/images/c6ace-t1k9-mz.A2_3_0.bin image:
Step 7
Configure ACE-1 to autoboot from the previous image. To set the boot variable and configuration
register to 1 (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
ACE-1/Admin(config)# boot system image:c6ace-t1k9-mz.A2_3_0.bin
ACE-1/Admin(config)# config-register 0x1
ACE-1/Admin(config)# exit
ACE-1/Admin#
You can set up to two images through the boot system command. If the first image fails,
the ACE tries the second image.
Note
Step 8
Use the no boot system image: command to unset the previously configured boot variable.
Verify the boot variable was synchronized to ACE-2 by entering the following command on ACE-2:
ACE-2/Admin# show bootvar
BOOT variable = "disk0:/c6ace-t1k9-mz.A2_1_0.bin;
disk0:/c6ace-t1k9-mz.A2_3_0.bin"
Configuration register is 1
Step 9
Enter the show ft group detail command in Exec mode to verify the state of each module. Downgrade
the ACE that has its Admin context in the STANDBY_HOT state (ACE-2) first by entering the reload
command.
ACE-2/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Note
If you downgrade from software version A2(3.0) to A2(1.3) or earlier, you will see that the ACE
enters the STANDBY-HOT state. However, if you downgrade from A2(3.0) to A2(1.4) or later,
you will see that the ACE enters the STANDBY_WARM state.
When ACE-2 loads the startup-configuration file, you may observe a few errors if you did not roll back
the configuration to a checkpoint. These errors are harmless and occur because the ACE software does
not recognize the A2(x) commands in the startup-configuration file.
Configuration synchronization is still enabled and the connections through ACE-1 are still being
replicated to ACE-2.
Step 10
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 11
Reload ACE-1 with the same downgrade software version as ACE-2. Again, you may observe a few
errors as ACE-1 loads the startup-configuration file.
ACE-1/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes]
Cisco Application Control Engine Module Administration Guide
A-8
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
After ACE-1 boots up, it assumes the role of standby and enters the STANDBY_HOT state (this may
take several minutes).
Step 12
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 13
Perform manual cleanup in the running-configuration files of both ACEs to remove unnecessary version
configuration elements.
Step 14
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.
Copying the Software Upgrade Image to the ACE
This section describes how to copy a software image to the ACE from a variety of sources, including:
•
FTP server
•
SFTP server
•
TFTP server
During the copy process, you can rename the image copied to the ACE.
Details
Command
Purpose
copy {ftp://server/path[/filename] |
sftp://[username@]server/path[/filename] |
tftp://server[:port]/path[/filename]} image:[name]
Copies a software image from the specified source to the ACE.
Example:
host1/Admin# copy
ftp://server1/images/c6ace-t1k9-mz.A2_3_0.bin image:
The keywords, arguments, and options are as follows:
•
ftp://server/path[/filename]—Specifies the URL of the
software image located on an FTP server. This path is
optional because the ACE prompts you for this
information if you omit it.
•
sftp://[username@]server/path[/filename]—Specifies the
URL of a software image on a secure FTP server. This
path is optional because the ACE prompts you for this
information if you omit it.
•
tftp://server[:port]/path[/filename]—Specifies the URL
of a software image on a trivial FTP server. This path is
optional because the ACE prompts you for this
information if you omit it.
•
image:[name]—Specifies the name for the software
image copied to the ACE. If you do not enter the name
argument, the ACE uses the default name of the image.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-9
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
What to Do Next
To set the boot variable and configure the ACE to autoboot this image, see the “Configuring the ACE to
Autoboot the Software Image” section.
Configuring the ACE to Autoboot the Software Image
This section describes how to configure the ACE to autoboot an image that you copy to it by setting the
boot variable and the configuration register. The boot variable specifies the image from which the ACE
boots at startup. The configuration variable can be set to autoboot the image defined by the boot variable.
This section contains the following topics:
•
Setting the Boot Variable
•
Configuring the Configuration Register to Autoboot the Boot Variable
•
Displaying the Boot Variable and Configuration Register
For detailed information on the boot variable and configuration register, see Chapter 1, Setting Up the
ACE.
Setting the Boot Variable
This section describes how to set the boot variable. You can set up to two images so that if the first image
fails, the ACE tries the second image.
Caution
If you set a single image through the boot system image: command, be sure to enter the image name
correctly. Otherwise, when you attempt to reload the ACE, it uses the incorrect image name, fails the
reload, and accesses the ROMMON utility. For information on recovering from this problem, see the
“Recovering the ACE from the ROMMON Utility” section.
Restrictions
You must perform this task from the Admin context in configuration mode only.
Details
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Cisco Application Control Engine Module Administration Guide
A-10
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Step 2
Command
Purpose
boot system image:image_name
Sets the boot variable.
Example:
host1/Admin(config)# boot system
image:c6ace-t1k9-mz.A2_3_0.bin
The image_name argument is the name of the
installed image.
no boot system image:image_name
(Optional) Unsets the previously configured boot
variable.
Example:
host1/Admin(config)# no boot system
image:c6ace-t1k9-mz.A2_3_0.bin
Configuring the Configuration Register to Autoboot the Boot Variable
This section describes how to configure the ACE to autoboot the system image identified in the boot
environment variable.
Restrictions
You must perform this task from the Admin context in configuration mode only.
Details
Step 1
Command
Purpose
config
Enters global configuration mode.
Example:
host1/Admin# config
host1/Admin#(config)#
Step 2
config-register 1
Example:
host1/Admin# config-register 1
Configures the ACE to autoboot the system image
identified in the boot environment variable.
Note
A config-register setting of 0 instructs the
ACE to boot to the rommon prompt upon a
reboot. The ACE remains in ROMMON
mode at startup.
Reloading the ACE
This section describes how to allow the ACE to use the installed software upgrade by reloading the ACE
module.
Restrictions
You must perform this task from the Admin context in Exec mode only.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-11
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Details
Command
Purpose
reload
Reloads the ACE.
Example:
host1/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save?
[yes/no]: [yes]
Note
If you reload the ACE and rommon mode prompt
appears, a problem with the upgrade or the ACE has
occurred. See the “Recovering the ACE from the
ROMMON Utility” section for more information.
Recovering the ACE from the ROMMON Utility
This section describes how to recover the ACE from the ROMMON utility. If you reload the ACE and
the rommon mode prompt appears, one of the following problems may have occurred:
•
You entered the installed image name incorrectly. This problem assumes that you correctly installed
the image on the ACE.
•
The downloaded ACE image is corrupted.
•
The ACE compact Flash had a hardware failure.
If you incorrectly entered the image name, boot the ACE from the rommon prompt and then after the
ACE reboots, correct the image name in the boot variable. For more information, see the “Booting the
ACE from ROMMON with the Correct Image Name” section.
If the downloaded image is corrupted or the compact Flash failed, copy the ACE image on the supervisor
engine and boot the ACE from the supervisor engine. For more information, see the “Booting the ACE
from an Image Copied to the Supervisor Engine” section.
Booting the ACE from ROMMON with the Correct Image Name
This section describes how to boot the ACE from ROMMON with the correct image name. If you set a
single image through the boot system command, you must enter the image name correctly for the ACE
to reload successfully. Otherwise, when you attempt to reload the ACE, it uses the incorrect image name,
fails the reload, and accesses the ROMMON utility as indicated by the ROMMON mode prompt.
After the attempted reload, a boot message (similar to the following) appears in the CLI indicating that
the image could not load:
boot: cannot load “disk0:c6ace-t1k9mz.A2_3_0.bin”
In this example, the image name is incorrect. The c6ace-t1k9mz.A2_3_0.bin image in the message
should be c6ace-t1k9-mz.A2_3_0.bin.
Verify whether the image name is correct. If it is, then the problem could be a corrupted image or a
compact Flash failure. For more information on how to reload the ACE from these conditions, see the
“Booting the ACE from an Image Copied to the Supervisor Engine” section.
Cisco Application Control Engine Module Administration Guide
A-12
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Details
Follow these steps to boot the ACE with the correct image name from ROMMON mode and correct the
image name in the boot variable:
Step 1
Access the disk0: directory to view the correct image name.
rommon 1> dir disk0:
Directory of disk0:
20903
28583947
2
74448896
....
rommon 2>
Step 2
-rw- c6ace-t1k9-mz.A2_3_0.bin
-rw- TN-CONFIG
<correct image
Set the boot image that is on the ACE.
rommon 2> BOOT=disk0:c6ace-t1k9-mz.A2_3_0.bin
Step 3
Verify the boot image in the configuration variables.
rommon 3> set
PS1=rommom!>
RELOAD_REASON=reload command by admin
?=0
BOOT=c6ace-t1k9-mz.A2_3_0.bin
rommon 4>
Step 4
Boot the image on the ACE.
rommon 4> boot
Loading disk0:c6ace-t1k9-mz.A2_3_0.bin. Please wait...
The boot process may take several minutes to finish.
Step 5
When the login prompt appears, log in to the ACE.
host1 login: admin
Password:
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2006, 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.
host1/Admin#
Step 6
Access configuration mode in the Admin context and unset the previously configured boot variable by
using the no boot system image: command.
host1/Admin# config
host1/Admin(config)# no boot system image:c6ace-t1k9mz.A2_3_0.bin
Step 7
Reset the boot variable with the correct image name by using the boot system image: command.
host1/Admin(config)# boot system image:c6ace-t1k9-mz.A2_3_0.bin
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-13
Appendix A
Upgrading or Downgrading Your ACE Software
Performing Software Upgrades and Downgrades
Step 8
To verify that the boot variable has the correct image name, use the show bootvar command in the
Admin context from the Exec mode.
host1/Admin# show bootvar
BOOT variable = “c6ace-t1k9-mz.A2_3_0.bin”
Configuration register is 0x1
host1/Admin#
Booting the ACE from an Image Copied to the Supervisor Engine
This section describes how to boot the ACE from an image copied to the supervisor engine. You may
need to do this if you download a corrupted ACE image or the ACE compact Flash has failed.
Details
Follow these steps to boot the ACE from an image copied to the supervisor engine:
Step 1
From the supervisor engine CLI, perform the following steps:
a.
Copy the ACE image to disk0: on the supervisor engine by using the copy command. For example,
to copy the c6ace-t1k9-mz.A2_3_0.bin image from a TFTP server to disk0:, enter:
Router# copy tftp://192.168.144.14/tftpboot/c6ace-t1k9-mz.A2_1.bin disk0:
Destination filename [c6ace-t1k9-mz.A2_1.bin]?
Accessing tftp://192.168.144.14/tftpboot/c6ace-t1k9-mz.A2_3_0.bin ...
Loading /tftpboot/c6ace-t1k9-mz.A2_1.bin from 192.168.144.14 (via VLAN
12):!!!!!!!!!!!!!!!!!!!!!!!!...
[OK - 29251568 bytes]
29251568 bytes copied in 81.600 secs (358475 bytes/sec)
Router#
b.
After the image is copied to the supervisor engine, access configuration mode and set the boot
variable for the ACE and the image. For example, to access configuration mode and set the boot
variable if the ACE is in slot 3, enter:
Router# config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#boot device module 3 disk0:c6ace-t1k9-mz.A2_1.bin
Device BOOT variable = disk0:c6ace-t1k9-mz.A2_1.bin
Warning: Device list is not verified
Router#
Step 2
From the ACE, perform the following steps:
a.
Boot the ACE from the image on the supervisor engine by using the boot eobc command.
rommon 1> boot eobc:
b.
When the login prompt appears, log in to the ACE.
host1 login: admin
Password:
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2006, 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
Cisco Application Control Engine Module Administration Guide
A-14
OL-20814-01
Appendix A
Upgrading or Downgrading Your ACE Software
Displaying Software Image Information
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
host1/Admin#
c.
If the image on the ACE is corrupted, copy another image onto the ACE as described in the “Copying
the Software Upgrade Image to the ACE” section. Then configure the ACE to autoboot the image as
described in the “Configuring the ACE to Autoboot the Software Image” section.
If the compact Flash on the ACE had a hardware failure, contact Cisco TAC for assistance.
Displaying Software Image Information
This section describes how to display software image information and contains the following topics:
•
Displaying the Boot Variable and Configuration Register
•
Displaying the Software Version
Displaying the Boot Variable and Configuration Register
To display the boot variable and configuration register, perform the following task from the Admin
context in the Exec mode:
Command
Purpose
show bootvar
Verifies the boot variable and configuration register.
Examples
The following examples shows how to display the boot variable and configuration register:
host1/Admin# show bootvar
BOOT variable = “disk0:c6ace-t1k9-mz.A2_1.bin”
Configuration register is 1
host1/Admin#
The 1 indicates that the configuration register is set to 1.
Displaying the Software Version
To display the software image on the ACE, perform the following task:
Command
Purpose
show version
Displays the software image on the ACE.
Cisco Application Control Engine Module Administration Guide
OL-20814-01
A-15
Appendix A
Upgrading or Downgrading Your ACE Software
Displaying Software Image Information
Examples
switch/Admin# show version
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2009, 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.
Software
loader:
Version
system:
Version
system image file:
installed license:
12.2[121]
A2(3.0) [build 3.0(0)A2(2.99.80)]
[LCP] disk0:c6ace-t1k9-mzg.A2_2_99_80.bin
ACE-SSL-05K-K9
Hardware
Cisco ACE (slot: 5)
cpu info:
number of cpu(s): 2
cpu type: SiByte
cpu: 0, model: SiByte SB1 V0.2, speed: 700 MHz
cpu: 1, model: SiByte SB1 V0.2, speed: 700 MHz
memory info:
total: 954268 kB, free: 230688 kB
shared: 0 kB, buffers: 4144 kB, cached 0 kB
cf info:
filesystem: /dev/cf
total: 1000000 kB, used: 541824 kB, available: 458176 kB
last boot reason: reload command by admin
configuration register: 0x1
switch kernel uptime is 39 days 20 hours 23 minute(s) 40 second(s)
switch/Admin#
Cisco Application Control Engine Module Administration Guide
A-16
OL-20814-01
INDEX
A
B
ACE
backup
boot configuration
archive file
1-21
capturing packet information
defaults
4-37
configuration checkpoint and rollback service
configuration files, loading from remote server
configuration files, saving
console connection
logging in
procedure
4-45
uses
5-1
password, changing CLI account
1-6
1-7
recovery from the ROMMON utility
redundant configuration
1-23
setting up
1-1
4-22
6-1
A-12
displaying
1-23
modifying
1-21
upgrading
A-10
A-12
BOOT environment variable, setting
boot method, setting
1-26
C
7-1
capturing packets
terminal settings
1-17
A-1
copying buffer
1-21, A-10
1-22, 4-14
1-21, A-10
4-38
4-40, 4-42
checkpoint, configuration
username, changing
using file system
4-9
1-4, 8-6
alias IP address
1-22, 4-14
1-21, A-10
2-1
shutting down
admin user
4-32
configuration register, setting boot method
1-9
upgrading
4-25
booting from rommon prompt
1-10
password, changing administrative
SNMP
4-22
boot method
restarting
4-23
BOOT environment variable
1-4
remote access
4-24
boot configuration
3-1
7-5
naming
4-23
4-33
status, displaying
1-9
message-of-the-day banner
MIBs
errors, displaying
overview
1-12
Flash memory, reformatting
licenses, managing
directory structure
naming conventions
date and time, configuring
information, displaying
4-7
4-25
guidelines and limitations
4-1
1-3
inactivity timeout
4-42
4-23
6-10
1-6
creating
4-42
deleting
4-43
displaying
4-44
rolling back to
4-44
Cisco Application Control Engine Module Administration Guide
OL-20814-01
IN-1
Index
class map
values
Layer 3 and 4, creating for management traffic
Layer 3 and 4, for SNMP
remote management
6-19, 6-20
console
7-48
connection to ACE
8-8
1-3
console line settings
ICMP statistics
contact, SNMP
5-11
CLI
1-19
7-36
context
account password, changing
restarting ACE from
saving session
directly accessing with SSH
1-7
configuration files
1-4
core dumps
7-3
clock
files
daylight saving time, setting
timezone, setting
4-35
4-10
files to remote server
licenses
7-35
configurational examples
redundancy
4-2, 4-3
files from remote server
1-15
1-12
communities, SNMP
6-44
7-59
configuration checkpoint and rollback service
creating configuration checkpoint
4-42
deleting configuration checkpoint
4-43
displaying checkpoint information
4-44
4-44
4-14
4-12
4-11
packet capture buffer
rolling back configuration
2-20
copying
1-24
user management of SNMP
using
6-4
SSL certs and keys
2-5
clearing
SNMP
configuration synchronization
overview
7-48
SNMP management traffic
XML
8-8
1-22
software image
4-14
upgrade image
A-9
copyright, displaying
core dumps
4-12
5-3
4-35
clearing core directory
copying
4-35
deleting
4-37
4-36
4-42
configuration command failures
displaying bulk synchronization
6-31
configuration files
clearing startup file
date and time
4-6
configuring
copying to disk0 file system
displaying
4-3
4-4
4-7
merging startup with running
4-4
4-1
daylight saving time setting
4-2
saving to remote server
4-2
configuration register
1-15
1-12
daylight saving time setting
1-15
default user
admin
saving in Flash memory
setting boot method
1-12
time zone setting
loading from remote server
saving
D
www
1-4, 8-6
1-4, 8-6
demo license, replacing with permanent license
3-6
directory
1-21, A-10
Cisco Application Control Engine Module Administration Guide
IN-2
OL-20814-01
Index
copying files
4-10
creating in disk0
4-17
deleting from disk0
listing files
stateful
6-3
HSRP group
deleting directory in
moving files in
6-21
host or gateway
4-19
creating new directory in
6-22
6-27
HSRP requirements
4-17
4-17
4-17
interface
6-25
overview
6-21
6-27
fault tolerance
4-10
uncompressing files in
untarring files in
See redundancy
4-15
file system
4-16
display attributes, terminal
copying files from remote server
1-17
displaying
copyright
6-17
failure detection
4-17
disk0
overview
forcing
copying files to directory
4-10
copying files to remote server
5-3
4-12
FT bulk synchronization configuration command
failures 6-31
copying image to remote server
FT group information
copying packet capture buffer
6-32
FT peer information
FT statistics
6-36
hardware information
listing files
overview
6-36
5-9
system processes
4-19
downgrading
using ACE
DTD
A-7
8-18
overview
8-4
4-15
4-16
4-9
file system overview
4-10
4-45
saving configuration files in
4-2
FT group
configuring
accessing
4-20
Flash memory
5-12
reformatting
A-7
4-17
4-10
untarring files in disk0
5-4
technical support information
before you begin
4-17
uncompressing files in disk0
system information
4-17
saving show command output to file
5-7
6-35
4-12
4-18
moving files in disk0
5-1
redundancy history
task flow
deleting files
5-2
information on ACE
process status
6-40
5-11
memory statistics
4-11
deleting directory in disk0
FT tracking information
4-14
creating new directory in disk0
6-38
ICMP statistics
copying licenses
4-14
6-13
displaying information
modifying
6-32
6-15
FT peer
configuring
F
6-11
displaying information
failover
6-36
FT tracking, displaying information
6-40
Cisco Application Control Engine Module Administration Guide
OL-20814-01
IN-3
Index
FT VLAN
IP address
6-4, 6-9
alias
6-10
G
K
gateway failure detection
See failure detection
key
generating for license
pair for SSH host
3-3
2-16
H
hardware information, displaying
5-2
L
host failure detection
See failure detection
Layer 3 and 4 policy map
HSRP group
for management traffic
failure detection
SNMP, creating
6-27
tracking requirements
7-50
Layer 3 and Layer 4 class map
6-27
HTTP
management traffic, creating for
return codes between server and client
SNMP, creating for
8-3
HyperTerminal
launching
8-10
7-48
licenses
backing up
1-3
saving session
8-8
copying
1-4
3-9, 3-10
4-11
copying to ACE
3-3
displaying configuration and statistics
I
generating key
ICMP
installing
clearing statistics
displaying statistics
managing
5-11
enabling messages to the ACE
removing
BOOT environment variable
A-14
3-3
3-6
3-6
7-37
logging
into ACE
4-14
copying upgrade image to ACE
1-4
A-9
software image information, displaying
A-15
A-15
inactivity timeout
3-1
location, SNMP
1-22
copying and booting from the supervisor engine
version
3-1
replacing demo with permanent
A-10
copying to remote server
3-4
ordering upgrade license
2-19
image
autobooting image
3-3
list of available
5-11
3-11
1-9
interface failure detection
See failure detection
M
management access
Layer 3 and 4 traffic
SSH, configuring
8-10
2-15
Cisco Application Control Engine Module Administration Guide
IN-4
OL-20814-01
Index
Telnet
SNMP management traffic
2-14
message-of-the-day banner
MIBs
XML
1-10
7-50
8-10
processes
7-5
monitoring
displaying
See SNMP
5-4
displaying status of
moving files in disk0
5-7
4-17
Q
N
quick start
naming the ACE
remote access
1-9
2-3
notifications
error messages
7-41
IETF standard, enabling
options
SLB
R
7-42
7-42
recovering the ACE from the ROMMON utility
7-41
SNMP
redundancy
7-28, 7-38, 7-41
SNMP, enabling
configuration examples
SNMP host, configuring
7-38
SNMP license manager
types
6-1
configuration command failures, displaying
7-40
configuring
virtual context change
6-5
configuration synchronization overview
7-41
7-41
forcing failover
6-21
6-17
FT group, configuring
6-13
FT group information, displaying
packet buffer
FT peer, configuring
4-37
capturing packets
copying capture buffer
FT statistics, displaying
4-12, 4-40, 4-42
password
changing CLI account
FT VLAN
1-6
6-38
history, displaying
See FT peer
6-9
6-35
memory statistics, displaying
overview
2-19
policy map
protocol
Layer 3 and 4, for management traffic
Layer 3 and 4, for SNMP
8-10
remote access policy map, applying
6-2
software upgrade or downgrade
2-11, 2-12
synchronizing
6-5
6-3
statistics, clearing
2-8
6-36
6-1
stateful failover
7-50
6-40
6-4
FT VLAN, configuring
1-7
peer
remote access
6-36
FT tracking information, displaying
changing administrative
ping, enabling
6-32
6-11
FT peer information, displaying
4-38
6-4
6-8
failure detection and tracking
P
6-31
6-44
configuration requirements
7-41
A-12
6-42
6-19
Cisco Application Control Engine Module Administration Guide
OL-20814-01
IN-5
Index
synchronizing SSL certs and keys
task flow
saving to startup configuration file
6-20
viewing
6-7
reformatting Flash memory
4-2
4-4
4-45
remote access
class map, creating
enabling
S
2-5
2-1
service policy
network management traffic services, configuring
policy map
2-8, 2-11, 2-12
quick start
2-3
2-14
2-16
SSH information, showing
2-22, 2-23
terminating SSH or Telnet
copying files from
copying files to
to ACE
4-14
saving configuration files to
4-7
4-2
1-1
enabling the exchange of output in XML
saving output to file
8-15
4-20
viewing hardware and software configuration
information 5-1
1-23
1-24
from Catalyst CLI
2-19
show command
4-14
loading configuration files from
from ACE CLI
2-22, 2-23
1-4
setting up ACE
4-12
copying image to
shutting down ACE
1-24
1-26
Simple Network Management Protocol
restore
defaults
See SNMP
4-25
errors, displaying
SNMP
4-33
guidelines and limitations
overview
4-24
7-3
agents, overview
4-27
status, displaying
AAA integration
agents, communication
4-22
procedure
7-48
CLI user management
4-22
7-3
7-35
configuration examples
7-59
configuring the engine ID
rollback service
See configuration checkpoint and rollback service
rommon
1-22
recovering the ACE from
A-12
contact
copying to disk0 file system
4-3
4-4
7-46
7-36
IETF standard
7-42
linkDown trap
7-42
linkUp trap
location
running configuration
merging with startup
communities
7-2
7-2
class map, creating
4-33
retrieving user context through the Admin context IP
address when using SNMP 7-45
mode
maximum number for SSH
Telnet information, showing
2-19
remote server
restarting ACE
7-52, 7-53,
8-13, 8-14
2-15
terminating user session
uses
SNMP management policy map, applying
session
SSH, configuring
Telnet
2-4
7-42
7-37
management traffic, configuring
managers, communication
7-47
7-2
Cisco Application Control Engine Module Administration Guide
IN-6
OL-20814-01
Index
managers, overview
MIBs
FT, clearing
7-2
license
7-5
MIB table and object support
notifications
overview
SNMP
7-1
policy map, creating
7-55
task flow
7-31
traps
6-44
7-55
stopping ACE
7-50
retrieving user context through the Admin context IP
address 7-45
statistics
6-36
redundancy history, clearing
7-38
service policy
3-11
memory
7-15
6-43
1-26
synchronizing
configuration
7-52, 7-53, 8-13, 8-14
6-4
SSL certs and keys
6-19
synchronizing redundant configurations
system information, displaying
7-28
6-19
5-9
system processes
traps and informs
7-3
displaying
unmasking community and community security name
OIDs 7-43
users, configuring
5-4
displaying status of
5-7
7-32
VLAN interface, assigning
7-44
T
software licenses
task flow
See licenses
SSH
downgrading
2-15
directly accessing a user context
host key pairs
SNMP
2-16
management access
maximum sessions
RSA key
XML
2-16
A-4
8-7
technical support information, displaying
2-17
terminating session
2-22, 2-23
showing information
2-7
terminating session
certificates and keys, synchronizing
6-20
copying to disk0 file system
merging with running
saving to remote server
viewing
statistics
1-17
4-2
time zone setting
1-20
1-12
tracking
4-4
stateful failover
1-19
virtual terminal line settings
4-2
updating with running configuration
1-17
display attributes
4-4
2-22, 2-23
2-19
console line settings
4-3
2-14
terminal settings
configuring
startup configuration
5-12
Telnet
management access, configuring
2-19
SSL
FT
6-7
7-31
upgrading
2-15
showing session information
version
redundancy
2-20
A-7
6-3
See failure detection
traps, SNMP
7-3, 7-28
6-38
Cisco Application Control Engine Module Administration Guide
OL-20814-01
IN-7
Index
class map, creating
U
uncompressing files in disk0
untarring files in disk0
upgrade license
4-15
DTD, overview
8-4
HTTP return codes
image information
overview
A-9
recovery from the ROMMON utility
A-12
task flow
8-8
8-1
show command output
A-1
reloading ACE
8-3
policy map, creating
A-15
8-20
8-2
management traffic, configuring
A-10
copying image to ACE
task flow
8-18
HTTP and HTTPS support
upgrading
overview
DTD, accessing
example of CLI command and XML equivalent
4-16
3-3
booting image
8-8
8-10
8-15
8-7
A-11
A-4
user
configuring for SNMP
7-32
user context
accessing by SNMP through the Admin context IP
address 7-45
directly accessing with SSH
2-20
username
changing
1-6
V
version, software
A-15
virtual terminal line settings
1-20
VLANs
for SNMP traps
7-44
FT VLAN for redundancy
volatile file system
6-4, 6-9
4-10
W
www user
1-4, 8-6
X
XML
Cisco Application Control Engine Module Administration Guide
IN-8
OL-20814-01