This chapter describes how to manage the software running on the Cisco 4700 Series Application Control Engine (ACE) appliance and contains the following major sections:
•Copying Configuration Files from a Remote Server
•Displaying the Configuration Download Progress Status
•Using the File System on the ACE
•Using the Configuration Checkpoint and Rollback Service
•Reformatting the Flash Memory
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
•Merging the Startup-Configuration File with the Running-Configuration File
•Clearing the Startup-Configuration File
•Displaying Configuration File Content
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.
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).
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.
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.
|
|
---|---|
copy startup-config running-config Example:
host1/Admin#
|
Merges the contents of the startup-configuration file into the running-configuration file. |
To display the content of the running- and startup-configuration files, perform one of the following tasks:
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.
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 .).
•Crypto files—To remove crypto files, use the crypto delete filename or the crypto delete all command (see the Cisco 4700 Series Application Control Engine Appliance SSL Configuration Guide).
|
|
|
---|---|---|
Step 1 |
copy startup-config {ftp://server/path[/filename] | sftp://[username@]server/path[/filename] | tftp://server[:port]/path[/filename]} Example:
host1/Admin#
|
(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. |
Step 2 |
clear startup-config
Example:
host1/Admin#
|
Clears the contents of the startup-configuration file and resets it to the default settings. |
write erase
Example:
host1/Admin#
|
||
Step 3 |
copy running-config startup-config Example:
host1/Admin#
|
(Optional) Recovers a copy of an startup configuration by copying the contents of the existing running-configuration file to the startup-configuration file. |
copy {ftp://server/path[/filename] | sftp://[username@]server/path[/filename] | tftp://server[:port]/path[/filename]} startup-config Example:
host1/Admin#
|
(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. |
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.
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 4700 Series Application Control Engine Appliance 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.
|
|
---|---|
copy {ftp://server/path[/filename] | sftp://[username@]server/path[/filename] | tftp://server[:port]/path[/filename]} {running-config | startup-config} Example:
host1/Admin#
|
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. |
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
To display the progress status of the configuration download on a context, perform the following task:
|
|
---|---|
show download information [all] [summary]} Example:
host1/Admin# show download information all |
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: • • 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.
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.
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 4700 Series Application Control Engine Appliance 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:
•Uncompressing Files in the disk0: File System
•Untarring Files in the disk0: File System
•Deleting an Existing Directory
•Displaying Files Residing On the ACE
•Saving show Command Output to a File
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 Between Directories in the disk0: File System on the ACE
•Copying a Packet Capture Buffer
•Copying a Scripted Probe File
•Copying Files to a Remote Server
•Copying Files from a Remote Server
•Copying an ACE Software System Image to a Remote Server
This section describes how to copy a file from one directory in the disk0: file system of Flash memory to another directory in disk0:.
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.
|
|
|
---|---|---|
copy licenses disk0:[path/]filename.tar Example:
host1/Admin#
|
Creates a backup license for the ACE licenses in .tar format and copies it to the disk0: file system. The keyword and argument are as follows: • • |
|
untar disk0:[path/]filename.tar Example:
host1/Admin#
|
(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). |
This section describes how to copy an existing packet capture buffer to the disk0: file system.
This section describes how to copy a scripted probe file from the probe: directory to another directory on the disk0:file system on the ACE or a remote server using FTP, SFTP, or TFTP.
You cannot copy a scripted probe file to the probe: directory on the ACE.
The copy probe: command is available only in the Admin context.
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.
|
|
---|---|
copy {core:filename | disk0:[path/]filename | running-config | startup-config} {ftp://server/path[/filename] | sftp://[username@]server/path[/filename] | tftp://server[:port]/path[/filename]} Example:
host1/Admin#
Enter username[]? user1 Enter the file transfer mode[bin/ascii]: [bin] Password: password1 Passive mode on. Hash mark printing on (1024 bytes/hash mark). #### |
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: • • • • • 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. • • When you select a destination file system using ftp:, sftp:, or tftp:, the ACE performs the following tasks: • • • |
This section describes how to copy a file from a remote server to a location on the ACE using FTP, SFTP, or TFTP.
|
|
---|---|
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} Example:
host1/Admin#
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). |
Copies a file from a remote server to a location on the ACE using FTP, SFTP, or TFTP. The keywords, arguments, and options are as follows: • 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. • • • • • • |
This section describes how to copy an ACE software system image from Flash memory to a remote server using FTP, SFTP, or TFTP.
The copy image: command is available in the Admin context only.
This section describes how to uncompress (unzip) LZ77 coded files in the disk0: file system (for example, zipped probe script files).
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.
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.
To untar a file, the filename must end with a .tar extension.
This section describes how to create a directory in the disk0: file system of Flash memory.
This section describes how to remove an existing directory from the disk0: file system of Flash memory.
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).
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.
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).
|
|
|
---|---|---|
Step 1 |
dir {core: | disk0: | image: | volatile:} Example:
host1/Admin# dir disk0: |
(Optional) Displays the files available in the specified file system. |
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: • • • • |
To display the files in a directory and the contents of a file, perform the following tasks:
The following example shows the output of the dir disk0: commands:
host1/Admin# dir disk0:
7465 Jan 03 00:13:22 2000 C2_dsb
2218 Mar 07 18:38:03 2006 ECHO_PROBE_SCRIPT4
1024 Feb 16 12:47:24 2006 core_copies_dsb/
1024 Jan 01 00:02:07 2000 cv/
1024 Mar 13 13:53:08 2006 dsb_dir/
12 Jan 30 17:54:26 2006 messages
7843 Mar 09 22:19:56 2006 running-config
4320 Jan 05 14:37:52 2000 startup-config
1024 Jan 01 00:02:28 2000 www/
Usage for disk0: filesystem
4254720 bytes total used
6909952 bytes free
11164672 bytes total
For example, to list the core dump files in Flash memory, enter:
host1/Admin# dir core:
2261 Jan 13 18:33:02 2010 SYSTEM_STATS
437478 Apr 15 13:40:36 2010 0x201_vsh_log.29732.tar.gz
504105 Apr 21 20:23:45 2010 0x201_vsh_log.6957.tar.gz
500547 Apr 24 10:58:26 2010 0x201_vsh_log.6959.tar.gz
Usage for core: filesystem
2524160 bytes total used
200572928 bytes free
203097088 bytes total
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.
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
•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
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:
•Running-configuration files
•Startup-configuration files
•Checkpoints
•SSL certificates
•SSL keys
•Health-monitoring scripts
•Licenses
Note 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
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.
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 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
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).
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
Table 4-2 lists the default settings for the backup and restore feature parameters.
This section describes the procedure that you perform to back up the ACE configuration files and dependencies.
To back up all contexts, you must be in the Admin context and you must specify the all keyword.
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.
•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.
You must be in the Admin context to restore all contexts.
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.
Note 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.
This section describes the procdure 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.
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.
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
To display the status of the backup operation, perform the following task:
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 Running-cfg Wed Aug 30 15:45:17 2009 SUCCESS
Admin Startup-cfg Wed Aug 30 15:45:17 2009 SUCCESS
Admin Checkpoints Wed Aug 30 15:45:17 2009 SUCCESS
Admin Cert/Key Wed Aug 30 15:45:17 2009 N/A
Admin License Wed Aug 30 15:45:17 2009 SUCCESS
Admin Probe script Wed Aug 30 15:45:17 2009 N/A
To display the status of the restoration, perform the following task:
|
|
---|---|
show restore status [detail] |
Displays the status of the last restoration. Restoration status details are not stored across reboots. |
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
To display the errors that may have occurred during a backup or restore operation that did not succeed, perform the following tasks:
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
Below diff could not be applied
--
--
ssh key rsa 4096 force
ssh key dsa 2048 force
ssh key rsa1 4096 force
--
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:
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:
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).
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.
You must perform this task from the Admin context only.
This section describes how to clear out all of the core dumps stored in the core: file system.
You must perform this task from the Admin context only.
This section describes how to delete a core dump file from the core: file system in Flash memory.
You must perform this task from the Admin context only.
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.
Error: Device Name:[0x3FF] Instance:[63] Error Type:[(null)] code:[255]
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 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
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.
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 4700 Series Application Control Engine Appliance Security Configuration Guide.
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.
•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.
This section describes how to copy an existing packet capture buffer to the disk0: file system.
This section describes how to display or clear packet information and contains the following topics:
•Displaying Packet Information
•Clearing Capture Buffer Information
To display packet information, perform the following task:
To clear the packet capture buffer, perform the following task:
|
|
---|---|
clear capture buffer_name |
Clears the capture packet buffer. The buffer_name argument specifies the name of the existing packet capture buffer to clear. |
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
This section describes how to create a configuration checkpoint.
Be sure that the current running configuration is stable and is the configuration that you want to make a checkpoint.
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.
•Avoid using opening braces, closing braces, whitespaces, or any of the following symbols: `$&*()\|;'"<>/?
This section describes how to delete a configuration checkpoint.
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.
This section describes how to roll back the current running configuration to the previously checkpointed running configuration for the current context.
If the running-configuration file has the no ft auto-sync command configured and the checkpoint has the ft auto-sync command configured, a checkpoint rollback will fail with the following message:
Warning : 'no ft auto-sync' & 'ft auto-sync' conflict detected - Rollback will fail
Failing Scenario - running config has 'no ft auto-sync' / checkpoint has 'ft auto-sync'
This section desctibes how to copy a checkpoint to one of several destinations.
This section describes how to compare a checkpoint with the running-configuration file.
To display checkpoint information, perform the following task:
Table 4-3 describes the fields that appear in the show checkpoint all command output.
The ACE uses the third extended file system (ext3) 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 the Flash memory erases all data on the Flash memory and reformat it with the ext3 base file system. All user-defined configuration information is erased.
The ACE performs the following verification sequence prior to reformatting Flash memory:
•If the system image (the current loaded image) is present in the GNU GRand Unified Bootloader (GRUB) boot loader, the ACE automatically performs a backup of that image and then performs the reformat of Flash memory.
•If the system image is not present in the Grub boot loader, the ACE prompts you for the location of an available image to backup prior to reformatting the Flash memory.
•If you choose not to backup an available image file, the ACE searches for the ACE-APPLIANCE-RECOVERY-IMAGE.bin image in the Grub partition of Flash memory. ACE-APPLIANCE-RECOVERY-IMAGE.bin is the recovery software image that the ACE uses if the disk partition in Flash memory is corrupted.
–If ACE-APPLIANCE-RECOVERY-IMAGE.bin is present, the ACE continues with the Flash memory reformat. The CLI prompt changes to "switch(RECOVERY-IMAGE)/Admin#" as a means for you to copy the regular ACE software image.
–If ACE-APPLIANCE-RECOVERY-IMAGE.bin is not present, the ACE stops the Flash memory reformat because there is no image to boot after format.
Before you reformat 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 4700 Series Application Control Engine Appliance 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.
After you reformat the Flash memory, perform the following actions:
•Reinstall the ACE software image by using the copy image: command (see the Release Note for the Cisco 4700 Series Application Control Engine Appliance).
•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 4700 Series Application Control Engine Appliance SSL Configuration Guide).