FAQs and Troubleshooting Guide for Cisco Security Manager 3.x - Device Management [Cisco Security Manager]

Table Of Contents

Device Management

FAQs About Device Communication

FAQs About Device Management

Changing the Image Version on a Device

Case 1: Image Version Changes That Do Not Change the Feature Set in Security Manager

Case 2: Image Version Changes That Change the Feature Set in Security Manager

Case 3: Security Context and Mode Changes That Change the Feature Set in Security Manager

Case 4: Device Type or Hardware Model Changes

Security Certificate Rejected When Discovering Device

Invalid Certificate Error During Device Discovery

Adding Routers Running 12.1 or 12.2 from the DCR

Deleting Config File When Deleting Security Context

Simultaneous Operations on Same Device

Troubleshooting the Setup of CNS-Managed Devices

Device Management

Before you can manage devices in Security Manager, you must prepare the devices so that communication between Security Manager and the devices is enabled, then add those devices to the Security Manager inventory.

This chapter contains the following topics:

•FAQs About Device Communication

•FAQs About Device Management

•Changing the Image Version on a Device

•Security Certificate Rejected When Discovering Device

•Invalid Certificate Error During Device Discovery

•Adding Routers Running 12.1 or 12.2 from the DCR

•Deleting Config File When Deleting Security Context

•Simultaneous Operations on Same Device

•Troubleshooting the Setup of CNS-Managed Devices

FAQs About Device Communication

This section answers the following questions about device communication:

•How does Security Manager connect to a Cisco IOS router that does not have a K8 or K9 crypto image?

•Why can't Security Manager connect to a Cisco IOS router after configuration rollback?

Q. How does Security Manager connect to a Cisco IOS router that does not have a K8 or K9 crypto image?

A. By default, Security Manager connects to Cisco IOS routers via SSL. However, a device running IOS version 12.3 or later without a K8 or K9 crypto image will not be able to support SSL. Therefore, after you add the device to Security Manager, you must select Tools > Device Properties, then change the default transport protocol to Telnet.

Q. Why can't Security Manager connect to a Cisco IOS router after configuration rollback?

A. This could occur because of one of the following reasons:

–At rollback, the necessary configurations are copied from the TFTP server to startup-config, then the Cisco IOS router is reloaded. This reload causes a temporary loss in device connectivity. To resolve this, we recommend that you wait for the device to be reloaded completely, then try to connect to it again.

–The configuration contains nonexisting or unauthorized username and password.

FAQs About Device Management

This section answers the following questions about device management:

•How do I configure Security Manager to ignore an error message that is generated by the device?

•How do I make a device response not tagged with an "Error" prefix appear as an error message?

Q. How do I configure Security Manager to ignore an error message that is generated by the device?

A. When you try to deploy certain configurations to a device, the message status is "error" even though it is a warning or an informational message. You can choose to ignore such error messages. To ignore error messages, do the following:

1. Select the job with the error message from the Deployment Manager window.

2. Click the Transcript button in the Deployment Details tab to open the transcript.

3. Identify the error text that you want to ignore.

4. Go to ...\CSCOpx\MDC\athena\config.

5. Select DCS.properties file to open the DCS properties file.

6. Locate the appropriate warning expressions property.

For PIX devices, this property is called dev.pix.warningExpressions.

For IOS devices, this property is called dev.ios.warningExpressions.

7. Add the error text you identified in step 3 to the warning expressions list.

Note The warning message should be a generic regular expression string. Except for the last expression, you must limit all expressions with "$\".

8. Restart the CiscoWorks Daemon Manager.

Q. How do I make a device response not tagged with an "Error" prefix appear as an error message?

A. Do the following:

1. Make a generic regular expression string for the device response that you want to treat as an error message.

2. Go to ...\CSCOpx\MDC\athena\config\DCS.properties file to open the DCS properties file.

3. Locate the appropriate error expressions property.

For PIX devices, this property is called, dev.pix.ErrorExpressions.

For IOS devices, this property is called, dev.pix.ErrorExpression.

4. Add the error text you identified in step 1 to the error expressions list.

Note The error message should be a generic regular expression string. Except for the last expression, you must limit all expressions with "$\".

5. Restart the CiscoWorks Daemon Manager.

Changing the Image Version on a Device

You must use caution when changing the image version of a device managed by Security Manager or when modifying the security context or operational mode of FWSM and ASA devices. In certain cases, these changes enable a different set of features for the device. As a result, some of the policies that you configured for the device in Security Manager might no longer apply.

The key device changes, their effect on the policies available in Security Manager, and the procedure you should follow to implement these device changes, are described in the following sections:

•Case 1: Image Version Changes That Do Not Change the Feature Set in Security Manager

•Case 2: Image Version Changes That Change the Feature Set in Security Manager

•Case 3: Security Context and Mode Changes That Change the Feature Set in Security Manager

•Case 4: Device Type or Hardware Model Changes

Case 1: Image Version Changes That Do Not Change the Feature Set in Security Manager

The following image version changes do not affect the types of policies available for that device in Security Manager:

•Upgrading from any Cisco IOS version supported by Security Manager to any other Cisco IOS version supported by Security Manager.

•Upgrading from any PIX 6.x image to another PIX 6.x image.

•Upgrading from any PIX 7.x image to another PIX 7.x image, retaining the same security context and mode configuration.

•Upgrading from any ASA 7.x image to another ASA 7.x image, retaining the same security context and mode configuration

•Upgrading from any FWSM 2.x image to another 2.x FWSM image, retaining the same security context and mode configuration.

•Upgrading a Catalyst 6500/7600 chassis from any IOS 12.x image to another IOS 12.x image.

•Upgrading from IPS 4.x to IPS 5.x or downgrading from IPS 5.x to IPS 4.x.

Note This list applies only to images that are supported by Security Manager. For a list of supported images, see Supported Devices and Software Versions for Cisco Security Manager 3.0.1.

In all of these cases, change the image version as follows:

Procedure

Step 1 Upgrade the image version on the device.

Step 2 Select Tools > Device Properties in Security Manager, then update the target OS version.

Step 3 Click Save.

Related Topics

•Changing the Image Version on a Device

Case 2: Image Version Changes That Change the Feature Set in Security Manager

The following image version changes do affect the types of policies available for that device in Security Manager:

•Upgrading from a PIX 6.x to a PIX 7.x image.

•Downgrading from a PIX 7.x image to a PIX 6.x image.

•Upgrading from a FWSM 2.x image to a FWSM 3.x image.

•Downgrading from a FWSM 3.x image to a FWSM 2.x image.

•Upgrading from an IOS 12.1 or 12.2 image to an IOS 12.3 or 12.4 image.

•Downgrading from an IOS 12.3 or 12.4 image to an IOS 12.1 or 12.2 image.

Note FWSM 3.x is supported in Security Manager 3.0.1 only. It is not supported in Security Manager 3.0.

Security Manager prevents you from changing the target OS version of a managed device to a version that changes the types of policies that are available for that device. Therefore, you must first delete the device from Security Manager, perform the image change, then add the device back.

Certain types of policies, such as access rules, are not affected by changes in image version or changes in platform type. We recommend, therefore, that you share the policies configured on your device before you remove it from Security Manager. This provides a useful method for reassigning the policies to the device (with any inheritance and policy object references intact) after you add it back to Security Manager.

Procedure

Step 1 Submit and deploy all the changes you configured for the device in Security Manager. This ensures that the desired configuration is on the device before the image upgrade.

Step 2 Share the local policies defined on the device:

a. Right-click the device in the Device selector, then select Share Device Policies. By default, all policies configured on the device (local and shared) are selected for sharing in the Share Policies wizard.

b. Deselect the check box next to each existing shared policy, as indicated by the hand in the policy icon. You should do this because there is no need to create a copy of the shared policies that already exist; you will reassign the existing shared policies after the image version upgrade.

c. Enter a name for the shared policies. We recommend using the device name as a convenient means of identification. For example, if the device name is MyRouter, each shared policy is given the name MyRouter.

d. Click Finish. The selected local policies become shared policies.

Step 3 Delete the device from Security Manager. We recommend that you delete the device from the DCR as well, unless you plan to manage the device in another CiscoWorks application, such as RME.

Step 4 Upgrade the image version on the device.

Step 5 Add the device back to Security Manager and perform policy discovery. If you did not delete the device from the DCR in step 3, use the Add Device from DCR option to bring it back into Security Manager.

Step 6 Reassign the policies to the device:

a. Right-click the first policy type displayed in the Device Policies selector, then select Assign Shared Policy.

b. In the Assign Shared Policy dialog box, do one of the following:

–If a local policy was previously defined on the device, select the shared policy defined in step 2, then click OK. Proceed with step c.

–If a shared policy of this type was previously assigned to the device, select it, then click OK. Proceed with step d.

c. (Local policies only) Right-click the policy type again in the Device Policies selector, then select Unshare Policy.

d. Repeat steps a through c for each policy type that is relevant to the device's configuration. If a shared policy is not available, this indicates that this is a policy type that was not available for the previous image version.

Step 7 (Optional) Delete the policies created in step 2 from Policy view:

a. Select View > Policy View or click the Policy View icon on the toolbar.

b. Starting from the top of the Policy Type selector, select a policy type, then examine the list of policies of that type displayed in the Shared Policy selector. If you see a policy with the name you assigned in step 2, click the Assignments tab in the work area to verify that the policy is not assigned to any devices.

c. Click the Delete Policy button beneath the Shared Policy selector to delete the policy.

d. Repeat steps a through c for each policy type that is relevant to the device's configuration.

Related Topics

•Changing the Image Version on a Device

Case 3: Security Context and Mode Changes That Change the Feature Set in Security Manager

Changes that you make to the security context and operational mode settings on a FWSM or ASA device enable a different set of features on that device. These changes occur if you change the device from:

•Single context to multi-context (or vice-versa).

•Routed mode to transparent mode (or vice-versa).

Security Manager prevents you from changing the security context or operational mode settings of a managed device. Therefore, you must first delete the device from Security Manager, change the context or mode, then add the device back.

Certain policy types (for example, Banner, Clock, Console Timeout, and HTTP) are not affected by changes in operational mode. Other policy types (for example, ICMP, SSH, and TFTP, in addition to Banner and Clock) are not affected by changes in security context settings. We recommend, therefore, that you share the policies configured on your device before you remove it from Security Manager. This provides a useful method for reassigning the policies to the device (with any inheritance and policy object references intact) after you add it back to Security Manager.

Procedure

Step 1 Submit and deploy all the changes you configured for the device in Security Manager. This ensures that the desired configuration is on the device before the image upgrade.

Step 2 Share the local policies defined on the device:

a. Right-click the device in the Device selector, then select Share Device Policies. By default, all policies configured on the device (local and shared) are selected for sharing in the Share Policies wizard.

b. Deselect the check box next to each existing shared policy, as indicated by the hand in the policy icon. You should do this because there is no need to create a copy of the shared policies that already exist; you will reassign the existing shared policies after the image version upgrade.

c. Enter a name for the shared policies. We recommend using the device name as a convenient means of identification. For example, if the device name is MyRouter, each shared policy is given the name MyRouter.

d. Click Finish. The selected local policies become shared policies.

Step 3 Delete the device from Security Manager. We recommend that you delete the device from the DCR also, unless you plan to manage the device in another CiscoWorks application, such as RME.

Step 4 Change the operational mode or the context settings on the device.

Step 5 Add the device back to Security Manager and perform policy discovery. If you did not delete the device from the DCR in step 3, use the Add Device from DCR option to bring it back into Security Manager.

Step 6 Reassign the policies to the device:

a. Right-click the first policy type displayed in the Device Policies selector, then select Assign Shared Policy.

b. In the Assign Shared Policy dialog box, do one of the following:

–If a local policy was previously defined on the device, select the shared policy defined in step 2, then click OK. Proceed with step c.

–If a shared policy of this type was previously assigned to the device, select it, then click OK. Proceed with step d.

c. (Local policies only) Right-click the policy type again in the Device Policies selector, then select Unshare Policy.

d. Repeat steps a through c for each policy type that is relevant to the device's configuration. If a shared policy is not available, this indicates that this is a policy type that was not available for the previous image version.

Step 7 (Optional) Delete the policies created in step 2 from Policy view:

a. Select View > Policy View or click the Policy View icon on the toolbar.

b. Starting from the top of the Policy Type selector, select a policy type, then examine the list of policies of that type displayed in the Shared Policy selector. If you see a policy with the name you assigned in step 2, click the Assignments tab in the work area to verify that the policy is not assigned to any devices.

c. Click the Delete Policy button beneath the Shared Policy selector to delete the policy.

d. Repeat steps a through c for each policy type that is relevant to the device's configuration.

Related Topics

•Changing the Image Version on a Device

Case 4: Device Type or Hardware Model Changes

In some cases, you might replace a particular device but retain the original contact information, for example:

•Replacing a PIX firewall with a Cisco IOS router.

•Replacing a PIX 7.x device with an ASA device.

•Replacing a Cisco IOS router with a firewall device.

In all of these cases, the new device changes the types of policies available for that device in Security Manager. Security Manager prevents you from modifying the hardware model of an existing device. In addition, we do not recommend that you change the device type in the DCR. Therefore, you must first delete the device from Security Manager, change the physical device, then add the device back.

Certain policy types (for example, access rules) are not affected by changes in device type. We recommend, therefore, that you share the policies configured on your device before you remove it from Security Manager. This provides a useful method for reassigning the policies to the device (with any inheritance and policy object references intact) after you add it back to Security Manager.

Procedure

Step 1 Submit and deploy all the changes you configured for the device in Security Manager. This ensures that the desired configuration is on the device before the image upgrade.

Step 2 Share the local policies defined on the device:

a. Right-click the device in the Device selector, then select Share Device Policies. By default, all policies configured on the device (local and shared) are selected for sharing in the Share Policies wizard.

b. Deselect the check box next to each existing shared policy, as indicated by the hand in the policy icon. You should do this because there is no need to create a copy of the shared policies that already exist; you will reassign the existing shared policies after the image version upgrade.

c. Enter a name for the shared policies. We recommend using the device name as a convenient means of identification. For example, if the device name is MyRouter, each shared policy is given the name MyRouter.

d. Click Finish. The selected local policies become shared policies.

Step 3 Delete the device from Security Manager. We recommend that you delete the device from the DCR also, unless you plan to manage the device in another CiscoWorks application, such as RME.

Step 4 Replace the device.

Step 5 Add the device back to Security Manager and perform policy discovery. If you did not delete the device from the DCR in step 3, use the Add Device from DCR option to bring it back into Security Manager.

Step 6 Reassign the policies to the device:

a. Right-click the first policy type displayed in the Device Policies selector, then select Assign Shared Policy.

b. In the Assign Shared Policy dialog box, do one of the following:

–If a local policy was previously defined on the device, select the shared policy defined in step 2, then click OK. Proceed with step c.

–If a shared policy of this type was previously assigned to the device, select it, then click OK. Proceed with step d.

c. (Local policies only) Right-click the policy type again in the Device Policies selector, then select Unshare Policy.

d. Repeat steps a through c for each policy type that is relevant to the device's configuration. If a shared policy is not available, this indicates that this is a policy type that was not available for the previous image version.

Step 7 (Optional) Delete the policies created in step 2 from Policy view:

a. Select View > Policy View or click the Policy View icon on the toolbar.

b. Starting from the top of the Policy Type selector, select a policy type, then examine the list of policies of that type displayed in the Shared Policy selector. If you see a policy with the name you assigned in step 2, click the Assignments tab in the work area to verify that the policy is not assigned to any devices.

c. Click the Delete Policy button beneath the Shared Policy selector to delete the policy.

d. Repeat steps a through c for each policy type that is relevant to the device's configuration.

Related Topics

•Changing the Image Version on a Device

Security Certificate Rejected When Discovering Device

Problem   An error occurs when you attempt to discover a device. The error message states that the security certificate received from the device was rejected.

Solution   Manually enter the thumbprint required by the certificate by doing one of the following:

•Go to Tools > Security Manager Administration > Device Communication. Click Add Certificate, enter the IP address of the device, then copy and paste the thumbprint displayed in the error message into the Certificate Thumbprint field.

•Right-click the device, then select Device Properties > Credentials. Copy and paste the thumbprint displayed in the error message into the Authentication Certificate Thumbprint field.

You must manually enter the thumbprint whenever you add a new device using the Add New Device or Add From Configuration File options and when you perform rediscovery. It is not required when you add a new device using the Add New Device From Network or Add Device From DCR options.

Invalid Certificate Error During Device Discovery

Problem   If the time settings on the device and Security Manager are not in synchronization, an error message is displayed stating that the certificate is not yet valid when you try to discover a device.

Solution   When the time set on the Security Manager server is lagging behind the time set on the device, Security Manager is unable to validate the device certificate as the start time of the validity period is ahead of the Security Manager time setting. Even if the timezones configured on the device and Security Manager are the same, the invalid certificate error occurs if the daylight saving time (summertime) settings are different. To resolve this problem, make sure that the daylight saving time settings are the same on the device and Security Manager, regardless of whether the timezone is the same. After setting the daylight saving time, synchronize the clock on the device with Security Manager so that both of them display the same time.

To obtain best results, we recommend that you set the same timezone on the device and Security Manager, and modify the timezone after you discover the certificates at a later time, if necessary.

Adding Routers Running 12.1 or 12.2 from the DCR

Problem   You cannot add a router running IOS Software Release 12.1 or 12.2 from the DCR.

Solution   Security Manager uses Telnet as the transport protocol for communicating with routers running IOS 12.1 or 12.2. Security Manager uses SSL and SSH as the transport protocol for routers running IOS 12.3 and later. When you add a live device using the Add Device From Network option, you can specify that the device is running IOS 12.1 or 12.2, which enables Security Manager to select the appropriate transport protocol (Telnet). However, when you add a device from the DCR, Security Manager automatically selects the default transport protocol for routers running IOS 12.3 or later. As a result, Security Manager cannot communicate with the device and the operation fails. This behavior is described in bug CSCsg74138.

The workaround requires you to temporarily change the default transport protocol for routers running IOS 12.3 or later, as described in the following procedure.

Procedure

Step 1 Change the default transport protocol:

a. Select Tools > Security Manager Administration > Device Communication.

b. In the Transport Protocol (IOS Routers 12.3 and above) field, change the protocol from HTTPS to Telnet, then click Save.

c. Click Close to return to the main Security Manager window.

Step 2 Add the router that is running IOS 12.1 or 12.2:

a. Click the New Device button above the Device selector. The New Device wizard is displayed.

b. Select Add Device from DCR, then complete the steps outlined in the wizard.

Step 3 Restore the default transport protocol to its original setting:

a. Select Tools > Security Manager Administration > Device Communication.

b. In the Transport Protocol (IOS Routers 12.3 and above) field, change the protocol back from Telnet to HTTPS, then click Save.

c. Click Close to return to the main Security Manager window.

Note For more information about the policies supported on routers running IOS 12.1 or 12.2, see Configuring Routers Running IOS Software Releases 12.1 and 12.2, page 10-1.

Deleting Config File When Deleting Security Context

Problem   Deleting a security context from a FWSM device in Security Manager removes the security context from the running configuration of the device, but it does not delete the associated configuration file. This can create problems if you later add another security context with the same name as the one that you previously deleted.

Solution   This is a known issue for this type of device (as described in CSCsg20999) and is not connected to the behavior of Security Manager. The current workaround is to use the CLI to delete the configuration file from the device.

Simultaneous Operations on Same Device

Problem   Simultaneous operations performed on the same device (that is, devices with the same IP address) produce inconsistent results. For example, deployment to the first device succeeds, but deployment to the second device fails. These simultaneous operations may be a combination of jobs executed by Security Manager, such as a deployment job, and user-initiated operations, such as discovering a live device. Problems can occur whether the operations are contained in the same job or in multiple jobs that are executed at the same time.

Solution   The device locking mechanism in Security Manager is based on the device name, not the IP address. As a result, operations such as discovery and deployment can run into problems if two devices share the same IP address. This is especially true if you attempt one of these operations on both devices at the same time.

For example, if a deployment job contains two devices with the same IP address, deployment will be executed to both devices since the names are different. However, doing so is not recommended, as it might result in an incomplete or failed deployment. To ensure consistent results, we recommend against defining more than one device with the same IP address.

Troubleshooting the Setup of CNS-Managed Devices

The following topics describe issues that might arise when you set up a device managed by a Cisco Networking Services (CNS) server and how to solve them:

•Why do I receive an InvalidParameterException when I click on an IOS device on the CNS web page?

•Why am I getting the following error: com.cisco.netmgmt.ce.websvc.exec.ExecServiceException: [002-01003]]deviceName does not exists?

•Why am I getting the following error: com.cisco.netmgmt.ce.websvc.config.ConfigServiceException: [002-01003]]Device device id is not connected

•Why is deployment to my CNS-managed PIX device not working?

•Why was I able to deploy successfully to a CNS-managed PIX device the first time, but subsequent deployments were unsuccessful?

•How do I debug CNS on a PIX device?

•How do I debug CNS on an IOS device?

•Why did I fail to discover an IOS device and acquire its configuration via CNS?

•Why doesn't the event mode router appear on the CNS Discover Device page or appear in green on the CNS web page?

Q. Why do I receive an InvalidParameterException when I click on an IOS device on the CNS web page?

A. This is the expected behavior. For IOS devices, Security Manager uses deployment jobs to deploy configurations to CNS 1.5 and 2.0, instead of associating a configuration to the IOS device in CNS. Therefore, you do not see an associated configuration when you click the device name on the CNS web page. For PIX devices, Security Manager associates the configuration to the device in CNS. Therefore, clicking the device name displays the associated configuration.

Q. Why am I getting the following error: com.cisco.netmgmt.ce.websvc.exec.ExecServiceException: [002-01003]]deviceName does not exists?

A. This error indicates that the device has not been added to CNS. It appears if you have not performed rollback or deployment in Security Manager (both of which add the device automatically), and have not manually added the device to CNS.

Q. Why am I getting the following error: com.cisco.netmgmt.ce.websvc.config.ConfigServiceException: [002-01003]]Device device id is not connected

A. The answer depends on the type of setup you are performing:

–Event mode setup—Make sure that the CNS device id defined in the Device Properties window in Security Manager matches the CNS device id configured on the router (using the cns id string command).

–Call home mode setup—The device is not connected to CNS in this mode; therefore, all Security Manager operations that require the retrieval of the device configuration via CNS are not supported. This includes discovery, preview configuration, display running config, and connectivity tests (and rollback, for IOS devices).

Q. Why is deployment to my CNS-managed PIX device not working?

A. There are several possibilities:

–The configuration contains invalid commands. You can test this by copying the configuration associated with the PIX device in CNS and pasting it directly into the device.

–The auto-update server command contains an invalid username and password.

–You did not wait long enough for the configuration to be polled into the PIX device. Use the show auto command to verify when the next polling cycle will occur.

–If you previously used the CNS server for the same PIX device and did not delete the PIX from the CNS server before you started the current task, it is possible that the PIX device received the previous configuration from the CNS server before you deployed the new configuration to it.

–If none of the suggestions above solves the problem, turn on CNS debug mode (see How do I debug CNS on a PIX device?) on the PIX device and check the log for errors after the next polling cycle.

Q. Why was I able to deploy successfully to a CNS-managed PIX device the first time, but subsequent deployments were unsuccessful?

A. This can happen if the configuration pushed during the first deployment contains incorrect CLI commands for the auto-update feature. Check the following:

–Make sure the username and password of the CNS server is defined correctly in the auto-update command.

–Make sure that you have defined a FlexConfig that contains the necessary name commands. A FlexConfig is necessary because Security Manager 3.1 does not support this command directly. As a result, even though the command was discovered, it does not appear in the full configuration.

Note For more information, see TAC case CSCsa73337.

Q. How do I debug CNS on a PIX device?

A. Enter the following CLI commands:

logging monitor debug

terminal monitor

logging on

Tip You can also find relevant information in the PIX log on the CNS server.

Q. How do I debug CNS on an IOS device?

A. Enter the following CLI commands:

debug cns all

debug kron exec-cli

terminal monitor

Tip When working in event mode, you can also find relevant information in the event log on the CNS server. When working in call home mode, check the config server log on the CNS server.

Q. Why did I fail to discover an IOS device and acquire its configuration via CNS?

A. If you see the following errors in debug mode:

*Feb 23 21:42:15.677: CNS exec decode: Unknown hostname cnsServer-lnx.cisco.com ... 474F6860: 72726F72 2D6D6573 73616765 3E584D4C rror-message>XML 474F6870: 5F504152 53455F45 52524F52 3C2F6572 _PARSE_ERROR</er

Verify the following:

–The CNS commands use a fully-qualified host name (host name and domain name).

–The device contains "ip domain name <your domain name>".

–The device contains "ip host <fully-qualified cns host name> <cns ip>".

Q. Why doesn't the event mode router appear on the CNS Discover Device page or appear in green on the CNS web page?

A. Check the following:

–Make sure that the router and the CNS server can ping each other.

–Clear the cns event command, then re-enter it without specifying a port number.

	FAQs and Troubleshooting Guide for Cisco Security Manager 3.x
	Device Management
FAQs and Troubleshooting Guide for Cisco Security Manager 3.x Preface Security Manager Server Security Manager Client Security Manager and Cisco Secure ACS Cisco Security Agent Device Management Policy Discovery Firewall Services IPS VPNs Router Platform Policies Catalyst 6500/7600 Devices Deployment Index	Download this chapter Device Management Download the complete book FAQs and Troubleshooting Guide for Cisco Security Manager 3.x (PDF - 1 MB) Table Of Contents Device Management FAQs About Device Communication FAQs About Device Management Changing the Image Version on a Device Case 1: Image Version Changes That Do Not Change the Feature Set in Security Manager Case 2: Image Version Changes That Change the Feature Set in Security Manager Case 3: Security Context and Mode Changes That Change the Feature Set in Security Manager Case 4: Device Type or Hardware Model Changes Security Certificate Rejected When Discovering Device Invalid Certificate Error During Device Discovery Adding Routers Running 12.1 or 12.2 from the DCR Deleting Config File When Deleting Security Context Simultaneous Operations on Same Device Troubleshooting the Setup of CNS-Managed Devices Device Management Before you can manage devices in Security Manager, you must prepare the devices so that communication between Security Manager and the devices is enabled, then add those devices to the Security Manager inventory. This chapter contains the following topics: •FAQs About Device Communication •FAQs About Device Management •Changing the Image Version on a Device •Security Certificate Rejected When Discovering Device •Invalid Certificate Error During Device Discovery •Adding Routers Running 12.1 or 12.2 from the DCR •Deleting Config File When Deleting Security Context •Simultaneous Operations on Same Device •Troubleshooting the Setup of CNS-Managed Devices FAQs About Device Communication This section answers the following questions about device communication: •How does Security Manager connect to a Cisco IOS router that does not have a K8 or K9 crypto image? •Why can't Security Manager connect to a Cisco IOS router after configuration rollback? Q. How does Security Manager connect to a Cisco IOS router that does not have a K8 or K9 crypto image? A. By default, Security Manager connects to Cisco IOS routers via SSL. However, a device running IOS version 12.3 or later without a K8 or K9 crypto image will not be able to support SSL. Therefore, after you add the device to Security Manager, you must select Tools > Device Properties, then change the default transport protocol to Telnet. Q. Why can't Security Manager connect to a Cisco IOS router after configuration rollback? A. This could occur because of one of the following reasons: –At rollback, the necessary configurations are copied from the TFTP server to startup-config, then the Cisco IOS router is reloaded. This reload causes a temporary loss in device connectivity. To resolve this, we recommend that you wait for the device to be reloaded completely, then try to connect to it again. –The configuration contains nonexisting or unauthorized username and password. FAQs About Device Management This section answers the following questions about device management: •How do I configure Security Manager to ignore an error message that is generated by the device? •How do I make a device response not tagged with an "Error" prefix appear as an error message? Q. How do I configure Security Manager to ignore an error message that is generated by the device? A. When you try to deploy certain configurations to a device, the message status is "error" even though it is a warning or an informational message. You can choose to ignore such error messages. To ignore error messages, do the following: 1. Select the job with the error message from the Deployment Manager window. 2. Click the Transcript button in the Deployment Details tab to open the transcript. 3. Identify the error text that you want to ignore. 4. Go to ...\CSCOpx\MDC\athena\config. 5. Select DCS.properties file to open the DCS properties file. 6. Locate the appropriate warning expressions property. For PIX devices, this property is called dev.pix.warningExpressions. For IOS devices, this property is called dev.ios.warningExpressions. 7. Add the error text you identified in step 3 to the warning expressions list. Note The warning message should be a generic regular expression string. Except for the last expression, you must limit all expressions with "$\". 8. Restart the CiscoWorks Daemon Manager. Q. How do I make a device response not tagged with an "Error" prefix appear as an error message? A. Do the following: 1. Make a generic regular expression string for the device response that you want to treat as an error message. 2. Go to ...\CSCOpx\MDC\athena\config\DCS.properties file to open the DCS properties file. 3. Locate the appropriate error expressions property. For PIX devices, this property is called, dev.pix.ErrorExpressions. For IOS devices, this property is called, dev.pix.ErrorExpression. 4. Add the error text you identified in step 1 to the error expressions list. Note The error message should be a generic regular expression string. Except for the last expression, you must limit all expressions with "$\". 5. Restart the CiscoWorks Daemon Manager. Changing the Image Version on a Device You must use caution when changing the image version of a device managed by Security Manager or when modifying the security context or operational mode of FWSM and ASA devices. In certain cases, these changes enable a different set of features for the device. As a result, some of the policies that you configured for the device in Security Manager might no longer apply. The key device changes, their effect on the policies available in Security Manager, and the procedure you should follow to implement these device changes, are described in the following sections: •Case 1: Image Version Changes That Do Not Change the Feature Set in Security Manager •Case 2: Image Version Changes That Change the Feature Set in Security Manager •Case 3: Security Context and Mode Changes That Change the Feature Set in Security Manager •Case 4: Device Type or Hardware Model Changes Case 1: Image Version Changes That Do Not Change the Feature Set in Security Manager The following image version changes do not affect the types of policies available for that device in Security Manager: •Upgrading from any Cisco IOS version supported by Security Manager to any other Cisco IOS version supported by Security Manager. •Upgrading from any PIX 6.x image to another PIX 6.x image. •Upgrading from any PIX 7.x image to another PIX 7.x image, retaining the same security context and mode configuration. •Upgrading from any ASA 7.x image to another ASA 7.x image, retaining the same security context and mode configuration •Upgrading from any FWSM 2.x image to another 2.x FWSM image, retaining the same security context and mode configuration. •Upgrading a Catalyst 6500/7600 chassis from any IOS 12.x image to another IOS 12.x image. •Upgrading from IPS 4.x to IPS 5.x or downgrading from IPS 5.x to IPS 4.x. Note This list applies only to images that are supported by Security Manager. For a list of supported images, see Supported Devices and Software Versions for Cisco Security Manager 3.0.1. In all of these cases, change the image version as follows: Procedure Step 1 Upgrade the image version on the device. Step 2 Select Tools > Device Properties in Security Manager, then update the target OS version. Step 3 Click Save. Related Topics •Changing the Image Version on a Device Case 2: Image Version Changes That Change the Feature Set in Security Manager The following image version changes do affect the types of policies available for that device in Security Manager: •Upgrading from a PIX 6.x to a PIX 7.x image. •Downgrading from a PIX 7.x image to a PIX 6.x image. •Upgrading from a FWSM 2.x image to a FWSM 3.x image. •Downgrading from a FWSM 3.x image to a FWSM 2.x image. •Upgrading from an IOS 12.1 or 12.2 image to an IOS 12.3 or 12.4 image. •Downgrading from an IOS 12.3 or 12.4 image to an IOS 12.1 or 12.2 image. Note FWSM 3.x is supported in Security Manager 3.0.1 only. It is not supported in Security Manager 3.0. Security Manager prevents you from changing the target OS version of a managed device to a version that changes the types of policies that are available for that device. Therefore, you must first delete the device from Security Manager, perform the image change, then add the device back. Certain types of policies, such as access rules, are not affected by changes in image version or changes in platform type. We recommend, therefore, that you share the policies configured on your device before you remove it from Security Manager. This provides a useful method for reassigning the policies to the device (with any inheritance and policy object references intact) after you add it back to Security Manager. Procedure Step 1 Submit and deploy all the changes you configured for the device in Security Manager. This ensures that the desired configuration is on the device before the image upgrade. Step 2 Share the local policies defined on the device: a. Right-click the device in the Device selector, then select Share Device Policies. By default, all policies configured on the device (local and shared) are selected for sharing in the Share Policies wizard. b. Deselect the check box next to each existing shared policy, as indicated by the hand in the policy icon. You should do this because there is no need to create a copy of the shared policies that already exist; you will reassign the existing shared policies after the image version upgrade. c. Enter a name for the shared policies. We recommend using the device name as a convenient means of identification. For example, if the device name is MyRouter, each shared policy is given the name MyRouter. d. Click Finish. The selected local policies become shared policies. Step 3 Delete the device from Security Manager. We recommend that you delete the device from the DCR as well, unless you plan to manage the device in another CiscoWorks application, such as RME. Step 4 Upgrade the image version on the device. Step 5 Add the device back to Security Manager and perform policy discovery. If you did not delete the device from the DCR in step 3, use the Add Device from DCR option to bring it back into Security Manager. Step 6 Reassign the policies to the device: a. Right-click the first policy type displayed in the Device Policies selector, then select Assign Shared Policy. b. In the Assign Shared Policy dialog box, do one of the following: –If a local policy was previously defined on the device, select the shared policy defined in step 2, then click OK. Proceed with step c. –If a shared policy of this type was previously assigned to the device, select it, then click OK. Proceed with step d. c. (Local policies only) Right-click the policy type again in the Device Policies selector, then select Unshare Policy. d. Repeat steps a through c for each policy type that is relevant to the device's configuration. If a shared policy is not available, this indicates that this is a policy type that was not available for the previous image version. Step 7 (Optional) Delete the policies created in step 2 from Policy view: a. Select View > Policy View or click the Policy View icon on the toolbar. b. Starting from the top of the Policy Type selector, select a policy type, then examine the list of policies of that type displayed in the Shared Policy selector. If you see a policy with the name you assigned in step 2, click the Assignments tab in the work area to verify that the policy is not assigned to any devices. c. Click the Delete Policy button beneath the Shared Policy selector to delete the policy. d. Repeat steps a through c for each policy type that is relevant to the device's configuration. Related Topics •Changing the Image Version on a Device Case 3: Security Context and Mode Changes That Change the Feature Set in Security Manager Changes that you make to the security context and operational mode settings on a FWSM or ASA device enable a different set of features on that device. These changes occur if you change the device from: •Single context to multi-context (or vice-versa). •Routed mode to transparent mode (or vice-versa). Security Manager prevents you from changing the security context or operational mode settings of a managed device. Therefore, you must first delete the device from Security Manager, change the context or mode, then add the device back. Certain policy types (for example, Banner, Clock, Console Timeout, and HTTP) are not affected by changes in operational mode. Other policy types (for example, ICMP, SSH, and TFTP, in addition to Banner and Clock) are not affected by changes in security context settings. We recommend, therefore, that you share the policies configured on your device before you remove it from Security Manager. This provides a useful method for reassigning the policies to the device (with any inheritance and policy object references intact) after you add it back to Security Manager. Procedure Step 1 Submit and deploy all the changes you configured for the device in Security Manager. This ensures that the desired configuration is on the device before the image upgrade. Step 2 Share the local policies defined on the device: a. Right-click the device in the Device selector, then select Share Device Policies. By default, all policies configured on the device (local and shared) are selected for sharing in the Share Policies wizard. b. Deselect the check box next to each existing shared policy, as indicated by the hand in the policy icon. You should do this because there is no need to create a copy of the shared policies that already exist; you will reassign the existing shared policies after the image version upgrade. c. Enter a name for the shared policies. We recommend using the device name as a convenient means of identification. For example, if the device name is MyRouter, each shared policy is given the name MyRouter. d. Click Finish. The selected local policies become shared policies. Step 3 Delete the device from Security Manager. We recommend that you delete the device from the DCR also, unless you plan to manage the device in another CiscoWorks application, such as RME. Step 4 Change the operational mode or the context settings on the device. Step 5 Add the device back to Security Manager and perform policy discovery. If you did not delete the device from the DCR in step 3, use the Add Device from DCR option to bring it back into Security Manager. Step 6 Reassign the policies to the device: a. Right-click the first policy type displayed in the Device Policies selector, then select Assign Shared Policy. b. In the Assign Shared Policy dialog box, do one of the following: –If a local policy was previously defined on the device, select the shared policy defined in step 2, then click OK. Proceed with step c. –If a shared policy of this type was previously assigned to the device, select it, then click OK. Proceed with step d. c. (Local policies only) Right-click the policy type again in the Device Policies selector, then select Unshare Policy. d. Repeat steps a through c for each policy type that is relevant to the device's configuration. If a shared policy is not available, this indicates that this is a policy type that was not available for the previous image version. Step 7 (Optional) Delete the policies created in step 2 from Policy view: a. Select View > Policy View or click the Policy View icon on the toolbar. b. Starting from the top of the Policy Type selector, select a policy type, then examine the list of policies of that type displayed in the Shared Policy selector. If you see a policy with the name you assigned in step 2, click the Assignments tab in the work area to verify that the policy is not assigned to any devices. c. Click the Delete Policy button beneath the Shared Policy selector to delete the policy. d. Repeat steps a through c for each policy type that is relevant to the device's configuration. Related Topics •Changing the Image Version on a Device Case 4: Device Type or Hardware Model Changes In some cases, you might replace a particular device but retain the original contact information, for example: •Replacing a PIX firewall with a Cisco IOS router. •Replacing a PIX 7.x device with an ASA device. •Replacing a Cisco IOS router with a firewall device. In all of these cases, the new device changes the types of policies available for that device in Security Manager. Security Manager prevents you from modifying the hardware model of an existing device. In addition, we do not recommend that you change the device type in the DCR. Therefore, you must first delete the device from Security Manager, change the physical device, then add the device back. Certain policy types (for example, access rules) are not affected by changes in device type. We recommend, therefore, that you share the policies configured on your device before you remove it from Security Manager. This provides a useful method for reassigning the policies to the device (with any inheritance and policy object references intact) after you add it back to Security Manager. Procedure Step 1 Submit and deploy all the changes you configured for the device in Security Manager. This ensures that the desired configuration is on the device before the image upgrade. Step 2 Share the local policies defined on the device: a. Right-click the device in the Device selector, then select Share Device Policies. By default, all policies configured on the device (local and shared) are selected for sharing in the Share Policies wizard. b. Deselect the check box next to each existing shared policy, as indicated by the hand in the policy icon. You should do this because there is no need to create a copy of the shared policies that already exist; you will reassign the existing shared policies after the image version upgrade. c. Enter a name for the shared policies. We recommend using the device name as a convenient means of identification. For example, if the device name is MyRouter, each shared policy is given the name MyRouter. d. Click Finish. The selected local policies become shared policies. Step 3 Delete the device from Security Manager. We recommend that you delete the device from the DCR also, unless you plan to manage the device in another CiscoWorks application, such as RME. Step 4 Replace the device. Step 5 Add the device back to Security Manager and perform policy discovery. If you did not delete the device from the DCR in step 3, use the Add Device from DCR option to bring it back into Security Manager. Step 6 Reassign the policies to the device: a. Right-click the first policy type displayed in the Device Policies selector, then select Assign Shared Policy. b. In the Assign Shared Policy dialog box, do one of the following: –If a local policy was previously defined on the device, select the shared policy defined in step 2, then click OK. Proceed with step c. –If a shared policy of this type was previously assigned to the device, select it, then click OK. Proceed with step d. c. (Local policies only) Right-click the policy type again in the Device Policies selector, then select Unshare Policy. d. Repeat steps a through c for each policy type that is relevant to the device's configuration. If a shared policy is not available, this indicates that this is a policy type that was not available for the previous image version. Step 7 (Optional) Delete the policies created in step 2 from Policy view: a. Select View > Policy View or click the Policy View icon on the toolbar. b. Starting from the top of the Policy Type selector, select a policy type, then examine the list of policies of that type displayed in the Shared Policy selector. If you see a policy with the name you assigned in step 2, click the Assignments tab in the work area to verify that the policy is not assigned to any devices. c. Click the Delete Policy button beneath the Shared Policy selector to delete the policy. d. Repeat steps a through c for each policy type that is relevant to the device's configuration. Related Topics •Changing the Image Version on a Device Security Certificate Rejected When Discovering Device Problem An error occurs when you attempt to discover a device. The error message states that the security certificate received from the device was rejected. Solution Manually enter the thumbprint required by the certificate by doing one of the following: •Go to Tools > Security Manager Administration > Device Communication. Click Add Certificate, enter the IP address of the device, then copy and paste the thumbprint displayed in the error message into the Certificate Thumbprint field. •Right-click the device, then select Device Properties > Credentials. Copy and paste the thumbprint displayed in the error message into the Authentication Certificate Thumbprint field. You must manually enter the thumbprint whenever you add a new device using the Add New Device or Add From Configuration File options and when you perform rediscovery. It is not required when you add a new device using the Add New Device From Network or Add Device From DCR options. Invalid Certificate Error During Device Discovery Problem If the time settings on the device and Security Manager are not in synchronization, an error message is displayed stating that the certificate is not yet valid when you try to discover a device. Solution When the time set on the Security Manager server is lagging behind the time set on the device, Security Manager is unable to validate the device certificate as the start time of the validity period is ahead of the Security Manager time setting. Even if the timezones configured on the device and Security Manager are the same, the invalid certificate error occurs if the daylight saving time (summertime) settings are different. To resolve this problem, make sure that the daylight saving time settings are the same on the device and Security Manager, regardless of whether the timezone is the same. After setting the daylight saving time, synchronize the clock on the device with Security Manager so that both of them display the same time. To obtain best results, we recommend that you set the same timezone on the device and Security Manager, and modify the timezone after you discover the certificates at a later time, if necessary. Adding Routers Running 12.1 or 12.2 from the DCR Problem You cannot add a router running IOS Software Release 12.1 or 12.2 from the DCR. Solution Security Manager uses Telnet as the transport protocol for communicating with routers running IOS 12.1 or 12.2. Security Manager uses SSL and SSH as the transport protocol for routers running IOS 12.3 and later. When you add a live device using the Add Device From Network option, you can specify that the device is running IOS 12.1 or 12.2, which enables Security Manager to select the appropriate transport protocol (Telnet). However, when you add a device from the DCR, Security Manager automatically selects the default transport protocol for routers running IOS 12.3 or later. As a result, Security Manager cannot communicate with the device and the operation fails. This behavior is described in bug CSCsg74138. The workaround requires you to temporarily change the default transport protocol for routers running IOS 12.3 or later, as described in the following procedure. Procedure Step 1 Change the default transport protocol: a. Select Tools > Security Manager Administration > Device Communication. b. In the Transport Protocol (IOS Routers 12.3 and above) field, change the protocol from HTTPS to Telnet, then click Save. c. Click Close to return to the main Security Manager window. Step 2 Add the router that is running IOS 12.1 or 12.2: a. Click the New Device button above the Device selector. The New Device wizard is displayed. b. Select Add Device from DCR, then complete the steps outlined in the wizard. Step 3 Restore the default transport protocol to its original setting: a. Select Tools > Security Manager Administration > Device Communication. b. In the Transport Protocol (IOS Routers 12.3 and above) field, change the protocol back from Telnet to HTTPS, then click Save. c. Click Close to return to the main Security Manager window. Note For more information about the policies supported on routers running IOS 12.1 or 12.2, see Configuring Routers Running IOS Software Releases 12.1 and 12.2, page 10-1. Deleting Config File When Deleting Security Context Problem Deleting a security context from a FWSM device in Security Manager removes the security context from the running configuration of the device, but it does not delete the associated configuration file. This can create problems if you later add another security context with the same name as the one that you previously deleted. Solution This is a known issue for this type of device (as described in CSCsg20999) and is not connected to the behavior of Security Manager. The current workaround is to use the CLI to delete the configuration file from the device. Simultaneous Operations on Same Device Problem Simultaneous operations performed on the same device (that is, devices with the same IP address) produce inconsistent results. For example, deployment to the first device succeeds, but deployment to the second device fails. These simultaneous operations may be a combination of jobs executed by Security Manager, such as a deployment job, and user-initiated operations, such as discovering a live device. Problems can occur whether the operations are contained in the same job or in multiple jobs that are executed at the same time. Solution The device locking mechanism in Security Manager is based on the device name, not the IP address. As a result, operations such as discovery and deployment can run into problems if two devices share the same IP address. This is especially true if you attempt one of these operations on both devices at the same time. For example, if a deployment job contains two devices with the same IP address, deployment will be executed to both devices since the names are different. However, doing so is not recommended, as it might result in an incomplete or failed deployment. To ensure consistent results, we recommend against defining more than one device with the same IP address. Troubleshooting the Setup of CNS-Managed Devices The following topics describe issues that might arise when you set up a device managed by a Cisco Networking Services (CNS) server and how to solve them: •Why do I receive an InvalidParameterException when I click on an IOS device on the CNS web page? •Why am I getting the following error: com.cisco.netmgmt.ce.websvc.exec.ExecServiceException: [002-01003]]deviceName does not exists? •Why am I getting the following error: com.cisco.netmgmt.ce.websvc.config.ConfigServiceException: [002-01003]]Device device id is not connected •Why is deployment to my CNS-managed PIX device not working? •Why was I able to deploy successfully to a CNS-managed PIX device the first time, but subsequent deployments were unsuccessful? •How do I debug CNS on a PIX device? •How do I debug CNS on an IOS device? •Why did I fail to discover an IOS device and acquire its configuration via CNS? •Why doesn't the event mode router appear on the CNS Discover Device page or appear in green on the CNS web page? Q. Why do I receive an InvalidParameterException when I click on an IOS device on the CNS web page? A. This is the expected behavior. For IOS devices, Security Manager uses deployment jobs to deploy configurations to CNS 1.5 and 2.0, instead of associating a configuration to the IOS device in CNS. Therefore, you do not see an associated configuration when you click the device name on the CNS web page. For PIX devices, Security Manager associates the configuration to the device in CNS. Therefore, clicking the device name displays the associated configuration. Q. Why am I getting the following error: com.cisco.netmgmt.ce.websvc.exec.ExecServiceException: [002-01003]]deviceName does not exists? A. This error indicates that the device has not been added to CNS. It appears if you have not performed rollback or deployment in Security Manager (both of which add the device automatically), and have not manually added the device to CNS. Q. Why am I getting the following error: com.cisco.netmgmt.ce.websvc.config.ConfigServiceException: [002-01003]]Device device id is not connected A. The answer depends on the type of setup you are performing: –Event mode setup—Make sure that the CNS device id defined in the Device Properties window in Security Manager matches the CNS device id configured on the router (using the cns id string command). –Call home mode setup—The device is not connected to CNS in this mode; therefore, all Security Manager operations that require the retrieval of the device configuration via CNS are not supported. This includes discovery, preview configuration, display running config, and connectivity tests (and rollback, for IOS devices). Q. Why is deployment to my CNS-managed PIX device not working? A. There are several possibilities: –The configuration contains invalid commands. You can test this by copying the configuration associated with the PIX device in CNS and pasting it directly into the device. –The auto-update server command contains an invalid username and password. –You did not wait long enough for the configuration to be polled into the PIX device. Use the show auto command to verify when the next polling cycle will occur. –If you previously used the CNS server for the same PIX device and did not delete the PIX from the CNS server before you started the current task, it is possible that the PIX device received the previous configuration from the CNS server before you deployed the new configuration to it. –If none of the suggestions above solves the problem, turn on CNS debug mode (see How do I debug CNS on a PIX device?) on the PIX device and check the log for errors after the next polling cycle. Q. Why was I able to deploy successfully to a CNS-managed PIX device the first time, but subsequent deployments were unsuccessful? A. This can happen if the configuration pushed during the first deployment contains incorrect CLI commands for the auto-update feature. Check the following: –Make sure the username and password of the CNS server is defined correctly in the auto-update command. –Make sure that you have defined a FlexConfig that contains the necessary name commands. A FlexConfig is necessary because Security Manager 3.1 does not support this command directly. As a result, even though the command was discovered, it does not appear in the full configuration. Note For more information, see TAC case CSCsa73337. Q. How do I debug CNS on a PIX device? A. Enter the following CLI commands: `logging monitor debug` `terminal monitor` `logging on` Tip You can also find relevant information in the PIX log on the CNS server. Q. How do I debug CNS on an IOS device? A. Enter the following CLI commands: `debug cns all` `debug kron exec-cli` `terminal monitor` Tip When working in event mode, you can also find relevant information in the event log on the CNS server. When working in call home mode, check the config server log on the CNS server. Q. Why did I fail to discover an IOS device and acquire its configuration via CNS? A. If you see the following errors in debug mode: Feb 23 21:42:15.677: CNS exec decode: Unknown hostname cnsServer-lnx.cisco.com ... 474F6860: 72726F72 2D6D6573 73616765 3E584D4C rror-message>XML 474F6870: 5F504152 53455F45 52524F52 3C2F6572 _PARSE_ERROR</er Verify the following: –The CNS commands use a fully-qualified host name (host name and domain name). –The device contains "ip domain name <your domain name>". –The device contains "ip host <fully-qualified cns host name> <cns ip>". Q. Why doesn't the event mode router appear on the CNS Discover Device page or appear in green on the CNS web page? A. Check the following: –Make sure that the router and the CNS server can ping each other. –Clear the cns event* command, then re-enter it without specifying a port number.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.