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.

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

Example:

host1/Admin# copy running-config
startup-config

Copies the contents of the running-configuration file to the startup-configuration file.

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).

When using FTP, the bin (binary) file transfer mode is intended for transferring compiled files (executables). The asciifile 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.

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.

Detailed Steps

Command

Purpose

copy {running-config | startup-config} disk0:[path/]filename

Example:

host1/Admin# copy running-config
disk0:running-config_copy

Copies either the running configuration of the startup configuration to a file on the disk0: file system in Flash memory.

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

Example:

host1/Admin# copy startup-config
running-config

Merges the contents of the startup-configuration file into the running-configuration file.

Displaying Configuration File Content

To display the content of the running- and startup-configuration files, perform one of the following tasks:

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.

•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.

•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.

write terminal

Displays the contents of the running configuration associated with the current context. The write terminal command is equivalent to the show running-config command.

invoke contextcontext_nameshow 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:

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 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.

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.

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:

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:.

Detailed Steps

Command

Purpose

Step 1

dir disk0:

Example:

host1/Admin# dir disk0:

(Optional) Displays the contents of the disk0: file system.

Step 2

copy disk0:[path/]filename1
{disk0:[path]filename2}

Example:

host1/Admin# copy disk0:samplefile
disk0:MYSTORAGE/SAMPLEFILE

Copies a file from one directory in the disk0: file system of Flash memory to another directory in disk0:.

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

Example:

host1/Admin# copy licenses
disk0:mylicenses.tar

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:

•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.

•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.

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.

When using FTP, the bin (binary) file transfer mode is intended for transferring compiled files (executables). The asciifile 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 using FTP, the bin (binary) file transfer mode is intended for transferring compiled files (executables). The asciifile 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.

•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.

Detailed Steps

Command

Purpose

Step 1

dir image:

Example:

host1/Admin# dir image:

(Optional) Displays the software system images available in Flash memory.

Step 2

show version

Example:

host1/Admin# show version

(Optional) Displays the version information of system software that is loaded in flash memory and currently running on the ACE.

Uncompressing Files in the disk0: File System

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.

Detailed Steps

Command

Purpose

Step 1

dir disk0:[directory/][path/][filename]

Example:

host1/Admin# dir disk0:

(Optional) Displays a list of available zipped files on the disk0: file system.

The arguments are as follows:

•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.

Step 2

gunzip disk0:filename

Example:

host1/Admin# gunzip disk0:PROBE_SCRIPTS.gz

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

Example:

host1/Admin# untar disk0:mylicenses.tar

Untars a single file with a .tar extension in the disk0: file system.

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.

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

Example:

host1/Admin# mkdir disk0:TEST_DIRECTORY

Create a directory in the disk0: file system of Flash memory.

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

Command

Purpose

Step 1

dir disk0:

Example:

host1/Admin# dir disk0:

(Optional) Displays the contents of the disk0: file system.

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.

•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.

Displaying Files Residing On the ACE

To display the files in a directory and the contents of a file, perform the following tasks:

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:

•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 4700 Series Application Control Engine Appliance 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.

Examples

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

For example, to list the core dump files in Flash memory, enter:

host1/Admin# dir core:

253151 Mar 14 21:23:33 2006 0x401_vsh_log.8249.tar.gz

262711 Mar 15 21:22:18 2006 0x401_vsh_log.15592.tar.gz

250037 Mar 15 18:35:27 2006 0x401_vsh_log.16296.tar.gz

Usage for core: filesystem

1847296 bytes total used

64142336 bytes free

65989632 bytes available

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.

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.

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.

Detailed Steps

Command

Purpose

Step 1

dir core:

Example:

host1/Admin# 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.

When using FTP, the bin (binary) file transfer mode is intended for transferring compiled files (executables). The asciifile 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:

•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.

Detailed Steps

Command

Purpose

Step 1

dir core:

Example:

host1/Admin# dir core:

(Optional) Displays the list of available core files.

Step 2

clear cores

Example:

host1/Admin# clear cores

Clears out all of the core dumps stored in the core: file system.

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

Command

Purpose

Step 1

dir core:

Example:

host1/Admin# 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.

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.

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 4700 Series Application Control Engine Appliance 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.

•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 capturebuffer_namestatus 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.

Enables the packet capture function on the ACE for packet sniffing and network fault isolation.

The keywords, arguments, and options are as follows:

•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.

Note To capture application acceleration and optimization traffic bound for the optional Cisco AVS 3180A Management Station interface, use the all keyword. This keyword captures all the traffic on all interfaces. You can then transfer the packet capture file to a remote machine to be scanned for traffic that is specific to the Management Station 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.

•bufsizebuf_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.

Detailed Steps

Command

Purpose

copy capturecapture_namedisk0: [path/]destination_name

Example:

host1/Admin# copy capture
packet_capture_Jan_17_06 disk0: mycapture1

Copies an existing packet capture buffer to the disk0: file system

The keywords, arguments, and options are as follows:

•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:

For all types of received packets, the console display is in tcpdump format.

Clearing Capture Buffer Information

To clear the packet capture buffer, perform the following task:

Command

Purpose

clear capturebuffer_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.

Creating 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.

Detailed Steps

Command

Purpose

checkpointcreatename

Example:

host1/Admin# checkpoint create
MYCHECKPOINT

Generating configuration....

Created checkpoint 'MYCHECKPOINT'

Creates a configuration checkpoint.

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) [n] y Generating
configuration....

Created checkpoint 'MYCHECKPOINT'

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

checkpointdeletename

Example:

host1/Admin# checkpoint delete
MYCHECKPOINT

Deletes a configuration checkpoint.

The name argument specifies the unique identifier of the checkpoint. Enter a text string with no spaces and a maximum of 25 alphanumeric characters.

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

Command

Purpose

Step 1

show checkpoint all

Example:

host1/Admin# show checkpoint all

(Optional) Displays a list of all existing checkpoints.

Step 2

show checkpoint detailname

Example:

host1/Admin# show checkpoint MYCHECKPOINT5

(Optional) Displays the running configuration of the specified checkpoint.

Step 3

checkpoint rollbackname

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#

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 | detailname} [|] [>]

Displays information relating to the configured checkpoints.

•all—Displays a list of all existing checkpoints. The show output includes checkpoint time stamps.

•detailname—Displays the running configuration of the specified checkpoint.

Table 4-1 describes the fields that appear in the show checkpoint all command output.

Table 4-1 Field Descriptions for the show checkpoint all Command Output

Field

Description

Checkpoint

Name of the checkpoint

Size

Size (in bytes) of the checkpoint

Date

Date and time at which the checkpoint was created

Reformatting the Flash Memory

Caution We recommend that you reformat the ACE Flash memory only under the guidance and supervision of Cisco Technical Assistance Center (TAC).

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.

Prerequisites

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.

Detailed Steps

Command

Purpose

format flash:

Example:

host1/Admin# format flash:

Warning!! This will erase everything in the compact flash including
startup configs for all the contexts and reboot
the system!!

Do you wish to proceed anyway? (yes/no) [no] yes

Erases all data on the Flash memory and reformats it with the ext3 base file system.

If the ACE fails to extract a system image from the Grub bootloader, it prompts you to provide the location of an available system image to backup: