Table Of Contents
Deployment
FAQs About Deployment
Performing Rollback When Deploying to a File
Mixing Deployment Methods
SSL Handshake Failure When Deploying to PIX/ASA Devices
Deployment Failures to Devices Managed by AUS
Deployment
This chapter contains the following topics:
•
FAQs About Deployment
•Performing Rollback When Deploying to a File
•Mixing Deployment Methods
•SSL Handshake Failure When Deploying to PIX/ASA Devices
•Deployment Failures to Devices Managed by AUS
FAQs About Deployment
This section answers the following questions about deployment:
•How does Security Manager perform deployment?
•Which deployment method should I use?
•How can I control the location used when I deploy to configuration files?
•If I deploy to files, how does Security Manager know that I applied the configuration to the device?
•What happens during configuration rollback?
•After configurations are deployed, which are completely owned by Security Manager, and which are only partially owned, and what does this mean?
•What happens if I make changes to a device configuration outside of Security Manager (an out-of-band change)?
•What happens during deployment if the version of the OS running on the device is not the same version listed for the device in Security Manager?
•Can I use Security Manager and ACL Manager together to manage ACLs?
•Does Security Manager deploy full configurations or only the changes made since the last deployment (delta configurations)?
•What are the default deployment methods for each type of device, and how do I change one for a device or for a deployment job?
•How many devices can Security Manager deploy to simultaneously?
•Deployment to a Cisco IOS router fails and an "Error Writing to Server" or "Http Response Code 500" error message occurs. Why?
•Why does deployment to FWSM fail when the configuration contains a large number of ACLs?
•Why does deployment fail even though the warning expression in the properties files is set to ignore the error?
•How can I deploy configurations to devices using a Token Management Server (TMS)?
•How can I deploy configurations to devices using an Auto Update Server (AUS)?
•How can I deploy configurations to devices using a Cisco Networking Services (CNS) server?
•Why do some platforms require a reload after performing configuration rollback but not others?
Q. How does Security Manager perform deployment?
A. Security Manager performs a three-step process when deploying your configurations to devices, as described in Table 12-1.
Table 12-1 Deployment Process
| |
Deployment Steps
|
Step 1
|
Security Manager obtains the current configuration for the device and compares it to the most recent saved policies for the device in Security Manager. What Security Manager considers the "current configuration" depends on the type of device, the deployment method, and the settings for deployment preferences. These are the possible sources of configurations and the conditions under which they are used:
•Obtain the running configuration from the device.
–Used when deploying to the device unless the deployment method is AUS, TMS, or CNS. You can force Security Manager to use Configuration Archive by selecting When Deploying to Device Get Reference Config from: Config Archive as the deployment preference (select Tools > Security Manager Administration, then select Deployment).
•Obtain the last full configuration from the Security Manager Configuration Archive.
–Used when deploying to file, unless you select When Deploying to File Get Reference Config from: Device as the deployment preference.
–Used when the deployment method is TMS or CNS.
–Used when the device is not managed by Security Manager.
–Used when deploying to a device if uploading the configuration from the device failed. (Configuration Archive is used as a backup to obtaining the configuration from the live device.)
–Used when you preview configurations.
•Obtain the factory default configuration.
–Used with PIX or ASA devices if you use the AUS deployment method.
–Used when previewing PIX or ASA configurations if you use the AUS deployment method.
|
Step 2
|
Security Manager builds a delta configuration that contains the commands needed to update the device configuration to make it consistent with the assigned policies. It also builds a full device configuration.
|
Step 3
|
If you are deploying to the device, Security Manager deploys either the delta configuration or the full configuration, depending on which deployment method you use. If you are deploying to a file, Security Manager creates two files: device_name_delta.cfg for the delta configuration, and device_name_full.cfg for the full configuration. In both cases, the configurations are also added to Configuration Archive. These are the actions based on deployment method:
•SSL or SSH—Security Manager contacts the device directly and sends the delta configuration to it.
•Auto Update Server (standalone or running on Configuration Engine) for PIX and ASA devices—Security Manager sends the full configuration to Auto Update Server, where the device retrieves it. The delta configuration is not sent.
•CNS gateway running on an Auto Update Server (for IOS devices with dynamic IP addresses)—Security Manager contacts the CNS gateway to get the device IP address, then uses SSL to contact the device directly and send it the delta configuration.
•Configuration Engine for IOS devices—Security Manager sends the delta configuration to Configuration Engine, where the device retrieves it.
•TMS—Security Manager sends the delta configuration to the TMS server, from which it can be downloaded to an eToken to be loaded onto the device.
|
Q. Which deployment method should I use?
A. If you are using Configuration Engine (CNS) or Auto Update Server (AUS), use those deployment methods. You must use one of these for devices that use dynamic IP addresses. Otherwise, for devices with static IP addresses, use SSL for IOS, PIX, ASA, and standalone FWSM devices, and SSH for FWSM with Catalyst 6000 and 7600 router devices. If you are using the Token Management Server (TMS) for some devices, you can also use that method with Security Manager.
Q. How can I control the location used when I deploy to configuration files?
A. To set a default directory for file deployments, select Tools > Security Manager Administration, then select Deployment. If you select File for the default deployment method, you also select the default directory. When you create a deployment job, you can change this directory for that job.
Q. If I deploy to files, how does Security Manager know that I applied the configuration to the device?
A. Security Manager assumes that the previously deployed configuration was applied to the device no matter which deployment method you use. Later deployments include only the changes you made since the last deployment (the delta). If for some reason the last change was not applied to the device, the new delta configuration does not bring the device configuration up to the one reflected in Security Manager.
Q. What happens during configuration rollback?
A. When you roll back the configuration on a device, Security Manager redeploys either the last good configuration or the configuration that you selected from the Configuration Archive. In either case, after rollback, the configuration on the device is no longer consistent with the configuration in Security Manager. After rollback, you should rediscover policies on the device to make the device configuration and its configuration in Security Manager consistent. If you roll back configurations on Catalyst or IOS devices, you also need to restart the device.
Q. After configurations are deployed, which are completely owned by Security Manager, and which are only partially owned, and what does this mean?
A. When you manage devices that run the ASA, PIX, or FWSM operating systems, Security Manager controls their configurations; you should make all changes within Security Manager. For devices running IOS software, you have more control. If you do not create policies for a feature in Security Manager, such as routing policies, Security Manager does not control those features on the device. If you do create policies for these features, Security Manager overwrites the settings on the device with the settings you defined in Security Manager. Through administration settings, you can control the types of policies that are available for IOS devices, thereby preventing Security Manager from displaying or changing policies for these features. To see the available features for IOS routers and control whether they are available for management in Security Manager, select Tools > Security Manager Administration, then select Policy Management. For IOS devices, Security Manager does manage VPN-related policies.
Q. What happens if I make changes to a device configuration outside of Security Manager (an out-of-band change)?
A. During deployment, if Security Manager determines that the configuration on the device differs from the last deployed configuration, Security Manager overwrites the changes by default. (You can control this behavior using the deployment preferences; select Tools > Security Manager Administration, then select Deployment, and look for the When Out of Bound Changes Detected setting. You can also control this for a specific deployment job by editing the deployment method for the job.)
Q. How can I get out-of-band changes into Security Manager?
A. If you make changes to the device configuration outside of Security Manager, you have two choices for bringing those changes into Security Manager:
–You can rediscover policies on the device, in which case all policies for the device become local policies, and any assignments of shared policies to the device are removed.
–You can make the required changes in Security Manager and redeploy them to the device. During deployment, do not select the option to force an error if out-of-band changes are found on the device.
Q. What happens during deployment if the version of the OS running on the device is not the same version listed for the device in Security Manager?
A. In some cases, Security Manager deploys the configuration and issues a warning, but in other cases, Security Manager cannot deploy the configuration. Security Manager deploys the configuration when:
–The device has a newer minor version, for example, PIX 6.3(4) instead of the 6.3(1), indicated in Security Manager.
–Security Manager does not support the version running on the device. In this case, Security Manager builds the configuration using the CLI for the closest supported version.
–The device has a down-level minor version, for example, 6.3(1) instead of 6.3(4).
Security Manager does not deploy the configuration when the device is running a new major version of the OS (for example, PIX 7.0 instead of the 6.3 indicated in Security Manager) or if the device is running a down-level major version (6.3 instead of 7.0).
Table 12-2 lists the possible actions Security Manager takes depending on the whether the OS versions match or differ from each other.
Note The PIX Firewall is used as an example; however, the actions apply to all supported device types.
Table 12-2 Deployment Action Based on OS Version Match or Mismatch
Scenario
|
OS Version in Security Manager Database
|
OS Version On Device
|
OS Version Used In Deployment
|
Action
|
Versions match
|
pix 6.3 (1)
|
pix 6.3 (1)
|
pix 6.3 (1)
|
Deployment proceeds with no warnings.
|
Device has newer OS version.
|
pix 6.3 (1)
|
pix 6.3 (4)
|
pix 6.3 (4)
|
Security Manager warns that it has detected a different OS version on the device than the one in the Security Manager database.
Security Manager generates CLI based on the OS version running on the device.
|
Device has newer OS version, which is not supported by Security Manager.
|
pix 6.3 (1)
|
pix 6.3 (6)
|
pix 6.3 (4)
|
Security Manager warns that it has detected a different OS version on the device than the one in the Security Manager database.
Security Manager generates CLI based on the highest OS version that it supports.
|
Device has new major OS version.
|
pix 6.3 (1)
|
pix 7.0
|
pix 7.0
|
Security Manager reports an error indicating that it has detected a different OS version on the device than the one in the Security Manager database.
Security Manager cannot proceed until you correct this mismatch. Remove the device from inventory and create a new device with the correct OS version.
|
Device has older OS version.
|
pix 6.3 (4)
|
pix 6.3 (1)
|
pix 6.3 (1)
|
If the older version is a different major version (6.0 vs. 7.0), Security Manager reports an error and aborts the deployment.
If the older version is within the same major version (6.0 vs. 6.3), Security Manager warns that it has detected a different OS version on the device than the one in the Security Manager database, and it continues with the deployment.
|
Q. How do I fix a version mismatch problem?
A. You must delete the device, add it again, and rediscover policies.
Q. Can I use Security Manager and ACL Manager together to manage ACLs?
A. Do not use Security Manager and ACL Manager (or any other software) to manage the same ACLs. Use Security Manager to manage all firewall- and VPN-related ACLs. You can use ACL Manager to manage ACLs for other features, such as quality of service (QoS).
Q. Does Security Manager deploy full configurations or only the changes made since the last deployment (delta configurations)?
A. In most cases, Security Manager sends only delta configurations to the device. The only exception is if you are using Auto Update Server for PIX and ASA devices, in which case the full configuration is sent to the Auto Update Server.
Q. What are the default deployment methods for each type of device, and how do I change one for a device or for a deployment job?
A. When you add devices to Security Manager, you select the deployment method to be used by that device. This determines the method used for deploying to the device (instead of a file). When you create a deployment job, an additional deployment method default applies to the job as a whole, which determines whether deployment creates configuration files or whether it sends the configuration to the device using the method selected for the device. You control this default in the administration settings (select Tools > Security Manager Administration, then select Deployment). When you create a deployment job, you can also change whether the deployment is to a file or to the device for each device by clicking Edit Deploy Method in the Create Job window
Q. How many devices can Security Manager deploy to simultaneously?
A. Security Manager can deploy to up to 20 devices simultaneously per job, up to 40 devices total. These restrictions enable Security Manager to use system memory efficiently, which ensures that jobs with many devices do not prevent jobs with fewer devices from deployment. There is no restriction to the number of jobs that Security Manager processes simultaneously.
Q. Deployment to a Cisco IOS router fails and an "Error Writing to Server" or "Http Response Code 500" error message occurs. Why?
A. When you use SSL as the transport protocol for deploying configurations to a Cisco IOS router, the configuration is split into multiple configuration bulks. The size of this configuration bulk varies from platform to platform. If Security Manager tries to deploy a configuration bulk that exceeds the size of the SSL chunk configured on that device, the deployment fails and you get an "Error Writing to Server" or "Http Response Code 500" error message.
To resolve this, do the following:
1. Go to ...\CSCOpx\MDC\athena\config.
2. Select DCS.properties file to open the DCS properties file.
3. Locate DCS.IOS.ssl.maxChunkSize=<value of the configuration bulk>.
4. Reduce the value of the configuration bulk.
5. Restart the CiscoWorks Daemon Manager.
Q. Why does deployment to FWSM fail when the configuration contains a large number of ACLs?
A. This could occur because the CPU utilization is high during ACL compilation. To resolve this, reconfigure the CPU utilization threshold limit by doing the following:
1. Go to ...\CSCOpx\MDC\athena\config.
2. Select DCS.properties file to open the DCS properties file.
3. Locate the DCS.FWSM.checkThreshold=False property.
4. Change the value to true: DCS.FWSM.checkThreshold=True.
5. Restart the CiscoWorks Daemon Manager.
6. Deploy the configuration to the device again.
After you set the value to true, discovery and deployment checks the CPU utilization and generates error messages if the CPU utilization is not within the configured value set in the DCS.FWSM.minThresholdLimit property. The default value is 85.
Q. Why does deployment fail even though the warning expression in the properties files is set to ignore the error?
A. Setting the properties file to ignore the error is not sufficient. Deployment fails because the Allow Download on Error check box (located on the Tools > Security Manager Administration > Deployment page) is deselected by default. To resolve this, select the Allow Download on Error check box and deploy again.
The following tables provide further details about how Security Manager behaves when an error occurs during deployment and the Allow Download on Error checkbox is either selected or deselected:
–Table 12-3 describes the behavior when SSL transport protocol is used on PIX Firewall, ASA, and Cisco IOS routers.
–Table 12-4 describes the behavior when SSH transport protocol is used on Cisco IOS routers.
Note On Cisco IOS routers with SSL protocol, deployment on devices stops on command syntax errors. It does not stop when configuration-related errors occur. There is no workaround for this.
Table 12-3 Security Manager Behavior When SSL is Used on PIX Firewall, ASA, and Cisco IOS Routers
Allow Download on Error
|
Error Occurred
|
Error Ignored Using Warning Expression
|
Deployment Status
|
Write Memory Done
|
Selected
|
Yes
|
No
|
Failed
|
Based on Write Memory flag setting.
|
Selected
|
Yes
|
Yes
|
Success
|
Based on Write Memory flag setting.
|
Selected
|
No
|
Not Applicable
|
Success
|
Based on Write Memory flag setting.
|
Deselected
|
Yes
|
No
|
Failed1
|
No
|
Deselected
|
Yes
|
Yes
|
Failed
|
No
|
Deselected
|
No
|
Not Applicable
|
Success
|
Based on Write Memory flag setting.
|
Table 12-4 Security Manager Behavior When SSH is Used on Cisco IOS Routers
Allow Download on Error
|
Error Occurred
|
Error Ignored Using Warning Expression
|
Deployment Status
|
Write Memory Done
|
Selected
|
Yes
|
No
|
Failed
|
Based on Write Memory flag setting.
|
Selected
|
Yes
|
Yes
|
Success
|
Based on Write Memory flag setting.
|
Selected
|
No
|
Not Applicable
|
Success
|
Based on Write Memory flag setting.
|
Deselected
|
Yes
|
No
|
Failed
|
No
|
Deselected
|
Yes
|
Yes
|
Success
|
Based on Write Memory flag setting.
|
Deselected
|
No
|
Not Applicable
|
Success
|
Based on Write Memory flag setting.
|
Q. How can I deploy configurations to devices using a Token Management Server (TMS)?
A. To perform this type of deployment, you need to set up the device, TMS, and Security Manager. The following checklist shows the tasks that you need to perform.
Tip For more information, click Help from any Security Manager dialog box or page.
Table 12-5 TMS Setup Checklist
|
Task
|
|
1. Set up the TMS as an FTP server.
You must set up the TMS as an FTP server because files are transferred from Security Manager to the TMS server using FTP.
|
|
2. Add devices to Security Manager inventory.
Select File > Add Devices.
|
|
3. Specify TMS as the transport protocol to be used for Cisco IOS devices.
You can set this parameter globally for all Cisco IOS devices or for a specific device, as follows:
•Globally—Select Tools > Security Manager Administration > Device Communication.
•Device—Select Device properties > DCS settings > Transport protocols.
|
|
4. Configure TMS parameters on Security Manager.
Specify the TMS name or IP address, username and password, directory where configuration files are to be copied, and public key file information in Security Manager. Select Tools > Security Manager Administration > Token Management.
|
|
5. Set the deployment method to Device either globally or for a specific device.
Do one of the following:
•Globally—Select Tools > Security Manager Administration > Deployment.
•Device—Depends on workflow mode:
–Non-Workflow mode—Select Submit and Deploy Changes > Edit Deploy Method.
–Workflow mode—Select Tools > Deployment Management > Create > Edit Deploy Method.
|
|
6. Deploy the configuration to the device.
Do one of the following:
•Non-Workflow mode—Select Submit and Deploy Changes.
•Workflow mode (if no deployment job exists)—Select Tools > Deployment Management > Create.
•Workflow mode (if a deployment already job exists)—Select Tools > Deployment Management and select the desired deployment job; then click Deploy.
|
|
7. Using TMS, download the configuration to the eToken.
See TMS product documentation.
|
|
8. Download the configuration from the eToken to the router and save the configuration to the device.
Plug the eToken into the router, then enter the following commands to download the configuration to the router:
router# crypto pki token <usb_token_id> login <PIN>
router(config)# crypto pki token default secondary config CCCD
|
Q. How can I deploy configurations to devices using an Auto Update Server (AUS)?
A. To perform this type of deployment, you need to set up AUS, the device, and Security Manager. The following checklist shows the tasks that you need to perform.
Tip For more information, click Help from any Security Manager dialog box or page.
Note If deployment to an AUS fails, see Deployment Failures to Devices Managed by AUS.
Table 12-6 AUS Setup Checklist
|
Task
|
|
1. Set up the AUS.
See the AUS product documentation.
|
|
2. Bootstrap firewall devices for AUS.
Enter the following commands to bootstrap devices:
hostname(config)# auto-update server
https://username:password@AUSserver_IP_address:port/autoupdate/AutoUpdateServlet
hostname(config)# auto-update poll-period poll_period [retry_count] [retry_period]
hostname(config)# auto-update device-id hardware-serial | hostname | ipaddress
[<if_name>] | mac-address [<if_name>] | string<text>
hostname(config)# write memory
|
|
3. Add devices to Security Manager inventory and assign AUS to devices.
Do one of the following:
•If you are adding a new device, from the Device view, select File > New Device > Add New Device. Configure the following fields on the Device Information page:
–Device selector—Select a PIX Firewall or ASA device type.
–IP Type—Select Static or Dynamic.
–Auto Update Server—Click the arrow to display a list of servers. Select the server that is managing the device. If the server does not appear in the list, click the arrow, then select + Add Server... to add the server.
–Device Identity—Enter the string value that uniquely identifies the device in AUS.
•If you are adding a device by importing it from DCR, from the Device view, select File > New Device > Add Device From DCR. The device must have been created as an AUS device in DCR for it to be successfully imported into Security Manager as an AUS device.
For more information, see "Adding Devices from DCR" in the Security Manager online help. For quick results, access the online help and use the search function to find this topic.
|
|
4. Configure AUS settings in Security Manager.
Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > AUS from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > AUS from the Policy Types selector. Right-click AUS and select New AUS Policy to create a policy, or select an existing policy from the Policies selector.
|
|
5. Set the deployment method to Device.
You can set this parameter either globally or for a specific device, as follows:
•Globally—Select Tools > Security Manager Administration > Deployment.
•Device—Depends on workflow mode:
–Non-Workflow mode—Select Submit and Deploy Changes > Edit Deploy Method
–Workflow mode—Select Tools > Deployment Management > Create > Edit Deploy Method.
|
|
6. Deploy the configuration to the device.
Do one of the following:
•Non-Workflow mode—Select Submit and Deploy Changes.
•Workflow mode (if no deployment job exists)—Select Tools > Deployment Management > Create.
•Workflow mode (if a deployment already job exists)—Select Tools > Deployment Management and select the desired deployment job; then click Deploy.
|
Q. How can I deploy configurations to devices using a Cisco Networking Services (CNS) server?
A. To perform this type of deployment, you need to set up the configuration engine (CE), the device, and Security Manager. The following checklist shows the tasks that you need to perform.
Note If PIX Firewall and ASA devices are configured for CNS, they use the AUS protocol. The required steps are identical to the steps that you follow when you configure PIX Firewall and ASA for AUS. See How can I deploy configurations to devices using an Auto Update Server (AUS)?
Note For CNS troubleshooting information, see Troubleshooting the Setup of CNS-Managed Devices, page 5-11.
Table 12-7 CNS Setup Checklist
|
Task
|
|
1. Set up the Configuration Engine.
If you are setting up the Configuration Server on AUS, see the AUS product documentation for more information. If you are setting up the Configuration Server on another server, see the Configuration Server documentation.
|
|
2. Bootstrap devices for CNS.
If PIX Firewall and ASA devices are configured for CNS, they use the AUS protocol. The required steps are identical to the steps that you follow when you configure PIX Firewall and ASA for AUS. See Table 12-6.
For Cisco IOS routers, you can configure CNS in the event-bus mode or the call-home mode.
To configure CNS in event-bus mode, enter the following commands:
hostname(config)# hostname<name>
hostname(config)# ip domain-name <your_domain>
hostname(config)# cns trusted-server all-agents <ip_address>
hostname(config)# cns event <ip_address> [port]
hostname(config)# cns config partial <ip_address>
hostname(config)# cns password <password>
hostname(config)# cns exec
hostname# copy running startup
To configure CNS in call-home mode, enter the following commands:
hostname# config terminal
hostname(config)# ip domain-name <your_domain>
hostname(config)# cns trusted-server all-agents <ip_address>
hostname(config)# kron occurrence occurrence-name [user username] {in
[[numdays:]numhours:]nummin | at hours:min [[month] day-of-month] [day-of-week]}
{oneshot | recurring}
hostname(config-kron-occurrence)# policy-list <list-name>
hostname(config-kron-occurrence)# exit
hostname(config)# kron policy-list <list-name>
hostname(config-kron-policy)# cli cns config retrieve <ip_address> page
/cns/JobbedDynaConfig status http://<ip_address>/cns/PostStatus
hostname(config-kron-policy)# exit
hostname(config)# cns exec
hostname# copy running startup
Note For more information about these commands, see "Setting Up CNS" in the Security Manager online help. For quick results, access the online help and use the search function to find the desired topic.
|
|
3. Add devices to Security Manager inventory.
Do one of the following:
•If you are adding a new device, from the Device view, select File > New Device > Add New Device. Configure the following fields on the Device Information page:
–IP Type—Select Static or Dynamic, as appropriate.
–Device selector—Select a Cisco IOS router (excludes Cisco 7600 series routers).
–CNS-Configuration Engine Server—If the device is using static addressing, select a Configuration Engine from the CNS-Configuration Engine Server field. If the desired Configuration Engine does not appear in the list, you can add it now. Click the arrow, then select + Add Configuration Engine.... The Configuration Engine Properties dialog box appears.
If the device is using dynamic addressing, select the server that is managing the device (Auto Update Server or Configuration Engine). If the desired server does not appear in the list, click the arrow, then select + Add Server.... The Server Properties dialog box appears.
•If you are adding a device that already exists in the network, from the Device view, select File > New Device > Add Device From Network. If the device is using dynamic addressing, you must select the Configuration Engine (CNS Gateway) that is managing the device. If the desired Configuration Engine does not appear in the list, click the arrow, then select + Add Auto Update Server.... The Auto Update Server Properties dialog box appears.
|
|
4. Set the deployment method to Device.
You can set this parameter either globally or for a specific device, as follows:
•Globally—Select Tools > Security Manager Administration > Deployment.
•Device—Depends on workflow mode:
–Non-Workflow mode—Select Submit and Deploy Changes > Edit Deploy Method.
–Workflow mode—Select Tools > Deployment Management > Create > Edit Deploy Method.
|
|
5. Deploy the configuration to the device.
Do one of the following:
•Non-Workflow mode—Select Submit and Deploy Changes.
•Workflow mode (if no deployment job exists)—Select Tools > Deployment Management > Create.
•Workflow mode (if a deployment already job exists)—Select Tools > Deployment Management and select the desired deployment job; then click Deploy.
|
Q. Why do some platforms require a reload after performing configuration rollback but not others?
A. On PIX/ASA/FWSM devices, Security Manager uses the replace config option on the device's SSL interface to perform the equivalent of a reload (xlates are cleared, IPsec tunnels are torn down, and so on).
Routers running IOS 12.3(7)T or later use the configure replace command to replace the running config with the contents of a configuration file. Support for this command is dependent on the IOS version installed on the router:
–On routers running IOS 12.3(7)T or later, Security Manager copies the configuration file to the startup configuration before executing the configure replace command. If the configure replace operation fails, Security Manager issues the reload command to reload the operating system using the contents of the startup configuration. Please note that the reload command restarts the system, which might result in a temporary network outage.
–On routers running a version prior to 12.3(7)T, Security Manager copies the configuration file to the startup configuration and issues the reload command.
Performing Rollback When Deploying to a File
Problem You cannot perform rollback when deploying to a file instead of a device.
Solution To revert to a previously stored configuration, do the following:
Step 1 Select Tools > Configuration Archive.
Step 2 In the Configuration Archive window, select a device, then select the configuration to which you want to revert.
Step 3 Click View.
Step 4 In the Configuration Version Viewer window, make sure the Config Type is set to Full.
Step 5 Click in the left-hand pane, then press Ctrl-A followed by Ctrl-C to copy the selected configuration to the Windows clipboard.
Step 6 Open a text editor, then press Ctrl-V to paste the contents of the clipboard.
Step 7 Save the file. You can then use this file to perform manual rollback.
Mixing Deployment Methods
Problem You receive unpredictable results when you deploy router platform and VPN policies to a live device after previously deploying to a configuration file.
Solution This problem can occur when you use a mix of deployment methods (deploy to device and deploy to file) with router platform policies and VPN policies. Because Security Manager does not manage all the available CLI commands for these policy types, it maintains a snapshot of the commands it has configured and leaves all other commands (which includes unsupported commands as well as supported commands in policies that have not been configured in Security Manager) intact on the device.
After each deployment, Security Manager creates a snapshot of the policies that were deployed to each device. This snapshot is used during the next deployment to generate the list of configuration changes that will be deployed to the device. Only one snapshot is maintained at a time per device.
Mixing deployment methods with router platform policies and VPN policies can lead to unpredictable results, as shown in this example:
1. Configure router platform policy A to a live device. When deployment completes, Security Manager creates a snapshot for that device with policy A.
2. Next, configure policy B to replace policy A, but instead of deploying policy B to the device, deploy it to a file instead. When this deployment completes, Security Manager creates a snapshot with policy B that replaces the previous snapshot with policy A. However, because you did not deploy policy B to the device, the CLI commands that are required to negate policy A have not been deployed. Policy A is still deployed on the device.
3. Deploy again to the device without first copying the changes in the configuration file to the device. Security Manager cannot generate the commands that are required to negate policy A from the device because the snapshot with policy A no longer exists.
Because policy A is a router platform policy, any of the following results might occur:
•The policy in the latest deployment overrides policy A.
•Both policies end up defined on the device.
•Deployment fails because the two policies cannot coexist.
Therefore, if you deploy to a file when working on a live device, we strongly recommend that you copy your configuration changes from the file to the device before performing additional deployments to the device.
SSL Handshake Failure When Deploying to PIX/ASA Devices
Problem You receive SSL handshake failures when deploying to PIX/ASA devices.
Solution Examine the device's running configuration to verify that the device is using 3DES/AES encryption, not DES. VPN-DES encryption is not supported on Common Services 3.0 and later. If the device is using DES encryption, install a VPN-3DES-AED license and retry deployment.
Deployment Failures to Devices Managed by AUS
Problem Deployment fails when deploying to multiple AUS-managed devices after starting the AUS.
Solution This problem can occur if you perform deployment before the Auto Update Server (AUS) is fully operational. The AUS requires time to start up after the following operations:
•New installation or upgrade.
•Manual restart (including after a power outage).
•Manual restart of the Cisco Security Manager Daemon Manager service.
You can verify whether the AUS is fully operational by verifying the status of its Windows services. To do this, select Start > Control Panel > Administrative Services > Services, then check the status of the CiscoWorks AUS Database Engine service. If this service has started, try again to deploy.
Note For more information about deploying to an AUS, see the FAQ entry, How can I deploy configurations to devices using an Auto Update Server (AUS)?.
