Section 4-3. Managing Configuration Files

4-3. Managing Configuration Files

A firewall keeps a "startup" configuration file in Flash memory. These configuration commands are not lost after a reload or power failure.

As soon as a firewall boots up, the startup configuration commands are copied to the "running" configuration file in RAM (volatile) memory. Any command that is entered or copied into the running configuration is also executed at that time.

As you enter configuration commands, be aware that they are present only in the temporary running configuration. After you have verified the operation of the new configuration commands, you should be sure to save the running configuration into Flash memory. This preserves the configuration in case the firewall reloads later.

You can enter configuration commands into the firewall using the following methods:

Command-line interface (CLI), where commands are entered through a console, Telnet, or SSH session on the firewall. The configure terminal command is used for this.
A management application such as PDM or Firewall Management Center (within VMS)
Imported by a TFTP file transfer
Imported by a web server
An automated or forced update from an Auto Update Server

Managing the Startup Configuration

In PIX releases 6.3 and earlier, as well as FWSM releases, a firewall has one startup configuration that is stored in Flash memory. This configuration file is read upon bootup and is copied into the running configuration.

PIX 7.0 introduces the capability to maintain one or more startup configuration files in Flash, provided that there is sufficient space to store them. Only one of these can be used at boot time.

This section discusses the tasks that can be used to maintain and display the startup configuration file.

Selecting a Startup Configuration File

In PIX 7.0 and later, having multiple startup configurations makes configuration rollback easy. The startup configuration contents can be saved in one file during the time that the firewall configuration is stable. If major configuration changes need to be made, the new updated running configuration can be saved to a new startup configuration file. The next time the firewall is booted, it can use this new file.

If you encounter problems with the new configuration, you can make one configuration change to force the firewall to roll back or use a previous version of the startup configuration.

By default, a firewall stores its startup configuration in a hidden partition of Flash memory. That file has no usable name and can be viewed only through the show startup-configuration command.

To force the firewall to use a different startup configuration filename, you can use the following command:

 Firewall(config)# boot config url

url represents the location of the startup configuration file. It can be flash:/path, disk0:/path, or disk1:/path, depending on which Flash file systems the firewall platform supports. PIX models have only a flash:/ file system, whereas the ASA platforms can support Flash or disk Flash file systems.

Be aware that the boot config url command effectively changes an environment variable used only by the running configuration. When you use this command, be sure to save the running configuration with the copy running-config startup-config or write memory command.

At this point, the firewall uses the new url and saves the startup configuration in that file, not in the default location. If the file doesn't exist, a new file is created; if it does exist, the running config-uration is merged with that file's contents. The environment variable is also updated and is used during the next boot cycle to find the new startup configuration file.

You can see the startup configuration environment variable with the show bootvar command. The following example begins with the default location, signified by the empty Current CONFIG FILE variable value. When the boot config command is used, the current value is updated to show the new file location.

However, until the running configuration is saved to the new startup configuration location, the new file is not present in Flash. As well, the startup configuration file used at boot time is still the default (shown by an empty CONFIG FILE variable line). After the configuration is saved, the new file is used during the next firewall boot.

 Firewall# show bootvar BOOT variable = flash:/image.bin Current BOOT variable = flash:/image.bin CONFIG_FILE variable = Current CONFIG_FILE variable = Firewall# configure terminal Firewall(config)# boot config flash:/startup-1.cfg INFO: Converting myconfig.cfg to flash:/startup-1.cfg Firewall(config)# exit Firewall# show bootvar BOOT variable = flash:/image.bin Current BOOT variable = flash:/image.bin CONFIG_FILE variable = Current CONFIG_FILE variable = flash:/startup-1.cfg Firewall# dir flash:/ Directory of flash:/ 6      -rw-  5031936     10:21:11 Dec 21 2004  image.bin 23     -rw-  8596996     10:12:38 Nov 12 2004  asdm.bin 16128000 bytes total (2450944 bytes free) Firewall# Firewall# copy running-config startup-config Source filename [running-config]? Cryptochecksum: a8885ca7 9782e279 c6794487 6480e76a 3861 bytes copied in 0.900 secs Firewall# show bootvar BOOT variable = flash:/image.bin Current BOOT variable = flash:/image.bin CONFIG_FILE variable = flash:/startup-1.cfg Current CONFIG_FILE variable = flash:/startup-1.cfg Firewall# dir flash:/ Directory of flash:/ 6      -rw-  5031936     10:21:11 Dec 21 2004  image.bin 23     -rw-  8596996     10:12:38 Nov 12 2004  asdm.bin 20     -rw-  3861        23:12:20 Dec 30 2004  startup-1.cfg

Finally, notice that even though a new location and a new filename are used for the startup configuration, you don't have to specify those when you save the running configuration later. The firewall continues to work with the startup-config keyword, but it uses the new url to reference the actual file. In other words, copy running-config startup-config always uses the current and correct location.

Displaying the Startup Configuration

You can display the contents of the startup configuration with either of these commands:

 Firewall# show startup-config

 Firewall# show configuration

In PIX 6.x, the latter command is actually show configure.

In the first line of the startup configuration, you can find its time stamp. This shows when the running configuration was saved to Flash the last time and who saved it. For example, the generic user enable_15 (someone in privileged EXEC or enable mode) saved this configuration:

 Firewall# show startup-config : Saved : Written by enable_15 at 17:41:51.013 EST Mon Nov 22 2004 PIX Version 7.0(1) names ! interface Ethernet0  shutdown [output omitted]

Saving a Running Configuration

You can view or save a firewall's running configuration with one of the methods described in the following sections.

Viewing the Running Configuration

You can use the following commands to display the current running configuration:

 Firewall# write terminal

 Firewall# show running-config

The running configuration is displayed to the current terminal session. If the configuration is longer than your current session page length (24 lines by default), you have to press the spacebar to page through it.

However, starting with PIX 6.3, you can filter the output by using one of the following keywords at the end of the command:

 Firewall# show running-config | {begin | include | exclude | grep [-v]} reg-exp

You can start the first line of output at the line where the regular expression reg-exp appears in the configuration with the begin keyword.

If you are looking for lines that contain only the regular expression reg-exp, use the include or grep keyword. You can also display only the lines that don't contain the reg-exp with the exclude or grep -v keyword.

The regular expression can be a simple text fragment or a more complex form containing wildcard and pattern-matching characters. For example, include int finds any line that contains "int" (including words such as "interface") located anywhere in the text.

These options are very handy if you have a firewall with a large configuration. Rather than paging through large amounts of configuration output, you can instantly find what you're looking for.

Saving the Running Configuration to Flash Memory

After you make configuration changes to a firewall and they are satisfactory, you should make them permanent by saving the running configuration to Flash memory. You can use the following command to accomplish this:

 Firewall# write memory

All the current configuration commands are stored in the startup configuration area in Flash memory. You should always run this command after making configuration changes. Otherwise, you might forget to save them later when the firewall is reloaded.

In PIX 7.x, the write memory command is supported for backward compatibility. A new form of the copy command is also provided, using the following syntax:

 Firewall# copy running-config startup-config

The firewall then displays the cryptochecksum, or a message digest 5 (MD5) hash of the configuration file contents. This value serves as a type of fingerprint that can be used to evaluate the configuration file's integrity. The configuration file's size is also shown, as in the following example:

 Firewall# copy running-config startup-config Source filename [running-config]? Cryptochecksum: 71a4cecb 97baf374 10757e38 a320cc43 2909 bytes copied in 0.520 secs Firewall#

TIP

You can use the MD5 cryptochecksum value as a quick check to see if a firewall's configuration has changed since it booted. First, find the MD5 hash that was saved with the startup configuration by looking at the last line of the show startup-config or show config command. Then compare that to the MD5 hash of the current running configuration, shown in the last line of the show running-config command or with the output of the show checksum command. If the two hash values differ, the configuration has changed.

Comparing the two cryptochecksum values in the following example shows that the configuration has been changed:

 Firewall# show startup-config | include checksum Cryptochecksum:3750a83d00922b80ffef78e92865b09a Firewall# show running-config | include checksum Cryptochecksum:a5bdac82909dc8717e494cfabc2d363d Firewall#

Saving the Running Configuration to a TFTP Server

You can use the following steps to save the current running configuration to an external file server:

(Optional) Identify the TFTP server:

 Firewall(config)# tftp-server [interface] ip-address path

The TFTP server can be found on the firewall's interface at IP address ip-address. By default, the inside interface is assumed. The running configuration file is stored in the path directory on the TFTP server. This path is relative only to the TFTP process itself. For example, if the file is stored in the topmost TFTP directory (/tftpboot, for instance), the path would be /, or the root of the TFTP directory tree.

TIP

The tftp-server command is not necessary, because all the TFTP parameters can be given with the write net EXEC command when the configuration is saved. However, the firewall always assumes the inside interface will be used for TFTP. The only way to override this assumption is by specifying a firewall interface (inside or outside, for example) in the tftp-server command. This interface is always used whenever files are copied to and from a TFTP server, even if the server address is different.

Save the configuration:

 Firewall# write net [[server-ip-address]:[filename]]

The TFTP server can be identified by giving its IP address here as server-ip-address. The configuration is saved in a file named filename in the TFTP root directory on the server.

If the server is not specified here, the values configured by the tftp-server command are used. You can also override the server address configured with the tftp-server command by specifying an address here.

PIX 7.x also offers the copy command, which can be used to copy the running configuration to a TFTP server. You can use the following command:

 Firewall# copy running-config   tftp://[user[:password]@]server[:port]/[path/]filename

Here, the running configuration is copied as a file with the filename filename. You can provide a path to specify where the file should be stored on the server. The path is relative to the TFTP server's root directory. If the server requires user authentication, the user ID and password can be given in the form user:password@.

For example, the running configuration is to be saved as the file mypix.confg on the TFTP server at 192.168.208.40, located on the firewall's dmz interface. The following commands can be used to accomplish this:

 Firewall(config)# tftp-server dmz 192.168.208.40 / Firewall(config)# exit Firewall# write net 192.168.208.40:mypix.confg

 Firewall# copy running-config tftp://192.168.208.40/mypix.confg

Forcing the Running Configuration to Be Copied Across a Failover Pair

During the bootup sequence, the active firewall copies its complete running configuration to the standby firewall. The active unit also copies any configuration commands to the standby unit as they are entered and executed.

Under normal conditions, the standby unit can keep its running configuration up to date and synchronized with the active unit. Sometimes it is possible for the two units to become unsynchronized. This can occur when configuration changes are made while the failover cable is disconnected, while the LAN-based failover connection is broken, or while the two units are running different OS releases. In these cases, you might see some of the logging messages in Table 4-7 generated when stateful failover cannot synchronize the two firewall units.

Table 4-7. Logging Messages Resulting from Stateful Failover Synchronization Errors
Message ID	Description
%PIX-1-105020	(Primary) Incomplete/slow configuration replication.
%PIX-3-210006	Stateful failover is unable to locate a NAT group for the IP address on the standby unit.
%PIX-3-210008	Unable to find a translation slot (xlate) record for a stateful failover connection.
%PIX-3-210020	Stateful failover is unable to allocate a specific PAT address that is in use.
%PIX-3-210021	Stateful failover is unable to create a translation slot (xlate).

If you make configuration changes on the standby firewall unit, those changes are not replicated back toward the active unit. Instead, you see the following message:

 *** WARNING ***       Configuration Replication is NOT performed from Standby unit to Active unit.       Configurations are no longer synchronized.

If you find that the running configurations are no longer identical and synchronized between the active and standby units, you can use the following command on the active unit to force a complete copy to be sent to the standby unit:

 Firewall# write standby

Forcing the Startup (Nonvolatile) Configuration to Be Cleared

Sometimes you might need to begin with an empty configuration on a firewall. This might happen if you reuse an existing firewall in a different scenario or if you inherit a firewall from someone else.

The following command erases all configuration commands from the startup configuration in Flash memory:

 Firewall# write erase

This command does not disturb or erase the current running configuration. After the startup configuration is erased, you can use the reload EXEC command to reboot the firewall with the new, empty startup configuration.

Importing a Configuration

You can copy configuration commands into a firewall's running configuration with one of the methods documented in the following sections.

Entering Configuration Commands Manually

You can begin entering configuration commands in a terminal session (console, Telnet, or SSH) after you use the following command:

 Firewall# configure terminal

Commands are entered into the running configuration in RAM and are executed as they are entered. To end configuration mode, press Ctrl-z or enter exit.

TIP

In a failover pair of firewalls, configuration commands should be entered only on the active unit. As you enter configuration commands into the active unit, they are copied to the standby unit. Therefore, the failover configurations are automatically synchronized.

If you enter configuration commands on the standby unit, they are not replicated to the active unit. Therefore, the firewall configurations become different and are unsynchronized.

Merging Configuration Commands from Flash Memory

The commands stored in the startup configuration in Flash memory can be copied over and merged into the running configuration after you issue the following command:

 Firewall# configure memory

This is useful when the running configuration has been mistakenly cleared or the wrong configuration has been imported.

In PIX 7.x, you can achieve the same results with the following command:

 Firewall# copy startup-config running-config

TIP

Remember that configuration commands are merged from Flash into RAM. This means that commands in the running configuration are preserved, and the commands stored in Flash are copied into RAM.

If similar commands are stored in both the startup and running configurations, the startup commands overwrite the others. In effect, this can result in a running configuration that is a mixture of startup and running configurations. It is a common misconception that the running configuration is erased before the startup configuration is copied onto it.

To erase the running configuration before the merge, use the clear configure all configuration command first. However, be aware that any existing configuration commands that provide IP addressing, routing, and administrative access are removed immediately. Unless you are connected to the firewall console, you could find that you become cut off from the newly cleared firewall.

Merging Configuration Commands from a TFTP Server

You can use the following steps to merge configuration commands from a file contained on an external TFTP server:

(Optional) Identify the TFTP server:

 Firewall(config)# tftp-server [interface] ip-address path

The TFTP server can be found on the firewall's interface at IP address ip-address. By default, the inside interface is assumed. The configuration file is copied from the path directory on the TFTP server. This path is relative only to the TFTP process itself. For example, if the file is stored in the topmost TFTP directory (/tftpboot, for instance), the path would be simply a forward slash, as /, denoting the root of the TFTP directory tree.

Fetch and merge the configuration:

 Firewall(config)# configure net [[server-ip-address]:[filename]]

The TFTP server can be identified by giving its IP address here as server-ip-address. The configuration is retrieved from the file named filename in the TFTP root directory on the server.

If the server is not specified here, the values configured by the tftp-server command are used. You can also override the server address configured with the tftp-server command by specifying an address here.

Although PIX 7.x supports the legacy configure net command, it also offers the following new form of the copy command to achieve similar results:

 Firewall# copy tftp://[user[:password]@]server[:port]/[path/]filename   running-config

Here, the file named filename is found at path on the TFTP server at IP address server. If the server requires user authentication, you can give the user ID and password using the user:password@ format.

Merging Configuration Commands from a Web Server

If you have a configuration file stored on an external web server, you can use the following command to merge its contents with the running configuration:

 Firewall(config)# configure http[s]://[user:password@]location[:port]/   http-pathname

You can use either the http (HTTP, port 80) or https (HTTPS or SSL, port 443) protocol to transfer the configuration file, depending on how the web server is configured.

If user authentication is required, it can be given as user:password@. The web server has a name or IP address given by location. (If a host name is used, it must also be defined in the firewall with the name command.) By default, the port number is either 80 or 443, according to the http or https keyword. You can override the port number by giving it as port.

The configuration file can be found on the server at the path http-pathname. The directory hierarchy is relative to the web server's file structure.

PIX 7.x also offers the following form of the copy command that achieves similar results:

 Firewall# copy http[s]://[user[:password]@]server[:port]/[path/]filename   running-config

For example, suppose a configuration file named pixtemplate.cfg is stored on the web server at 172.30.22.17. User authentication is required, using user ID pixadmin and password myadminpw. You can use the following commands to merge the file with the running configuration:

 Firewall# configure https://pixadmin/myadminpw@172.30.22.17/pixtemplate.cfg

 Firewall# copy https://pixadmin/myadminpw@172.30.22.17/pixtemplate.cfg   running-config

Merging Configuration Commands from an Auto Update Server

You can use an Auto Update Server (AUS) as a platform to automatically merge a stored configuration file with the running configuration. Having the firewall pick up a new configuration file update is easier than a manual method if there are many firewalls to maintain.

TIP

Auto Update Server is supported only with PIX and ASA Security appliance models. It is not yet supported on the FWSM as of FWSM OS release 2.3.

1.	Make sure an Auto Update Server is available. AUS can be installed as a part of the Cisco VMS package. The firewall should also be defined in AUS, and the new image file should be assigned to or associated with it. TIP Be aware that as soon as you assign a configuration file to a firewall in AUS, the firewall can download and begin using it the very next time it polls AUS. The firewall checks to see if the configuration file is different from the one it is currently running. If so, it automatically downloads that file. Similarly, the AUS operator can force AUS to send the firewall a request to download the configuration immediatelyregardless of the AUS update times. As soon as a new configuration file is retrieved from AUS, the firewall executes a clear xlate command automatically. This clears the translation table in preparation for a changed configuration but might temporarily disrupt active connections through the firewall.
2.	Make sure the AUS can be reached: Firewall# ping [interface] ip-address Here, the AUS has IP address ip-address. The firewall should already have the necessary routing information to reach the AUS device. You can specify a firewall interface ("outside," for example) where the AUS can be found if the firewall can't determine that directly.
3.	Identify the firewall by one of its interfaces: Firewall(config)# auto-update device-id {hardware-serial \| hostname \| ipaddress [if_name] \| mac-address [if_name] \| string text} The AUS must assign or associate files with specific firewalls that it manages. You can choose how the firewall is identified to AUS: - Firewall serial number (hardware-serial) The number shown in the show version EXEC command is used. - Host name (hostname) The name set by the hostname configuration command is used. - Interface IP address (ipaddress) The address of the interface named if_name is used. - Interface MAC address (mac-address) The address of the interface named if_name is used. - Text string (string) The alphanumeric string text is used. When a firewall device is configured in the VMS Firewall Management Center application (which defines devices for AUS), it is uniquely identified with one of these methods. Make sure that the device ID (device-id) matches in both locations, or no files will be automatically updated.
4.	(Optional) Adjust the AUS polling period: Firewall(config)# auto-update poll-period poll-period [retry-count [retry-period]] The firewall polls the AUS every poll-period minutes (the default is 720 minutes, or 12 hours). If an update connection fails, the firewall retries the connection retry-count times (the default is 0no retries). If the retry-count is nonzero, the AUS connections are retried every retry-period minutes (1 to 35791 minutes; the default is 5 minutes).
5.	Identify the AUS URL: Firewall(config)# auto-update server http[s]://[username:password@] AUSserver-IP-address[:port]/autoupdate/AutoUpdateServlet [verify-certificate] The firewall can use http (HTTP, port 80) or https (HTTPS or SSL, port 443) to communicate with the AUS. The firewall can optionally authenticate itself using a valid AUS (VMS) username and password. This isn't normally required, because AUS identifies the firewall by the device ID that is configured in Step 3. The IP address of the AUS is given as AUSserver-IP-address. The port used can be determined by the http or https keyword (80 or 443, respectively) or by an explicit port value. The path name shown (/autoupdate/AutoUpdateServlet) is the standard value for AUS. You can optionally make the firewall verify the SSL certificate from the AUS as an added security feature. This prevents the firewall from downloading files from a rogue AUS machine. The AUS acts as its own root certificate authority (CA), so it uses a self-signed SSL certificate by default. Therefore, no independent third party can be used to verify the AUS identity. Instead, the first time the firewall successfully polls the AUS, the server certificate is accepted and trusted. The firewall then verifies that certificate with the SSL public key information provided by the AUS at each successive poll.