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:
Troubleshooting Device Communication Failures
If Security Manager fails to communicate with a device, e.g. by failing to log into it, during discovery, deployment, or other actions, look at these areas to identify and resolve the problem.
- Ensure the device is operational.
- Check which transport protocol is selected. You must select a protocol that the device is configured to accept. For most devices, the protocol is selected on the Device Properties General page. For IPS devices, the IPS RDEP mode is selected on the Credentials page.
Some methods of adding devices also allow you to select a non-default transport protocol. To configure the default transport protocols for classes of devices, select Tools > Security Manager Administration > Device Communications.
- On the Device Properties General page, ensure that the hostname, domain name, and IP address are correct. Keep in mind that the Hostname and Accounts and Credentials policies for the device define the actual names and credentials that get configured on the device. However, the policies are not used for device communication. If you make changes to the policies that affect the credentials you are using for device communication, you must also manually update the device properties.
- Make sure DNS names can be resolved from the Security Manager server. You might need to fix the DNS settings on the server.
- Check the credentials for the device in Security Manager and ensure that they are correct and that there is a route between the server and device. Right-click the device, select Device Properties, select the Credentials tab, and click the Test Connectivity button. If the connection fails, check error messages to determine whether the problem is connectivity or credentials. Update the credentials in the device properties if necessary.
When adding new devices the credentials are defined within the New Device wizard if your method of adding the device requires credentials. Keep the following in mind:
– The primary credentials are used for SSH and Telnet connections.
– The HTTP/HTTPS credentials are used for HTTP and SSL connections unless you select Use Primary Credentials, in which case the primary credentials are also used for these connections.
FAQs About Device Communication
This section answers the following questions about device communication:
Q. How does Security Manager connect to a Cisco IOS router that does not have a K8 or K9 crypto image?
By default, Security Manager connects to Cisco IOS routers using 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 cannot Security Manager connect to a Cisco IOS router after configuration rollback?
This could occur because of one of the following reasons:
– At rollback, for some versions of Cisco IOS software and when necessary, the 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. Wait for the device to be reloaded completely, then try to connect to it again.
– The configuration contains a nonexisting or unauthorized username and password.
Security Certificate Rejected When Discovering Device
If an error occurs when you attempt to discover a device, and the error message states that the security certificate received from the device was rejected, you need to update the certificate. You can do this using one of the following methods:
- Manually enter the thumbprint required by the certificate by doing one of the following:
– Select 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 and 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 File options.
- Configure the SSL certificate settings to automatically retrieve the certificate when adding devices. You can select different settings for IPS, router, and ASA/PIX/FWSM devices. To configure these settings, select Tools > Security Manager Administration > Device Communication, and look at the SSL Certificate Parameters group.
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 cannot validate the device certificate as the start time of the validity period is ahead of the Security Manager time setting. Even if the time zones 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 time zone 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 time zone on the device and Security Manager, and modify the time zone after you discover the certificates at a later time, if necessary.
Deleting Configuration File When Deleting Security Context
Problem Deleting a security context from an 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 and is not connected to the behavior of Security Manager. The workaround is to use the CLI to delete the configuration file from the device.
Simultaneous Operations on the 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 because 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 Configuration Engine-Managed Devices
The following topics describe issues that might arise when you set up a device managed by a Cisco Configuration Engine (also known as CNS) and how to solve them:
Q. Why does Configuration Engine deployment fail?
Not all versions of Configuration Engine function in a compatible manner. Because Security Manager does not verify the software version running on a Configuration Engine when you add it to the device inventory, you can add unsupported versions to the inventory. Then, when you try to deploy, you can run into unpredictable errors. Ensure that you are running a supported version of Configuration Engine, such as 3.0. For support information, see the supported devices information at http://www.cisco.com/en/US/products/ps6498/products_device_support_tables_list.html.
Q. Why do I receive an InvalidParameterException when I click on an IOS device on the Configuration Engine web page?
This is the expected behavior. For IOS devices, Security Manager uses deployment jobs to deploy configurations to Configuration Engine instead of associating a configuration to the IOS device in Configuration Engine. Therefore, you do not see an associated configuration when you click the device name on the Configuration Engine web page. For PIX devices, Security Manager associates the configuration to the device in Configuration Engine. 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?
This error indicates that the device has not been added to Configuration Engine. 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 Configuration Engine.
Q. Why am I getting the following error: com.cisco.netmgmt.ce.websvc.config.ConfigServiceException: [002-01003]]Device device id is not connected
The answer depends on the type of setup you are performing:
– Event mode setup—Make sure that the Configuration Engine device ID defined in the Device Properties window in Security Manager matches the device ID configured on the router (using the cns id string command).
– Call home mode setup—The device is not connected to Configuration Engine in this mode; therefore, all Security Manager operations that require the retrieval of the device configuration using Configuration Engine are not supported. This includes discovery, preview configuration, display running configuration, and connectivity tests (and rollback, for IOS devices).
Q. Why is deployment to my Configuration Engine-managed PIX device not working?
There are several possibilities:
– The configuration contains invalid commands. You can test this by copying the configuration associated with the PIX device in Configuration Engine 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 Configuration Engine server for the same PIX device and did not delete the PIX from the Configuration Engine server before you started the current task, it is possible that the PIX device received the previous configuration from the server before you deployed the new configuration to it.
– If none of the suggestions above solves the problem, turn on Configuration Engine debug mode (see How do I debug Configuration Engine 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 Configuration Engine-managed PIX device the first time, but subsequent deployments were unsuccessful?
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 Configuration Engine 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 does not support this command directly. As a result, even though the command was discovered, it does not appear in the full configuration.
Q. How do I debug Configuration Engine on a PIX device?
Enter the following CLI commands:
logging monitor debug
Tip You can also find relevant information in the PIX log on the Configuration Engine server.
Q. How do I debug Configuration Engine on an IOS device?
Enter the following CLI commands:
debug cns all
debug kron exec-cli
Tip When working in event mode, you can also find relevant information in the event log on the Configuration Engine server. When working in call home mode, check the config server log on the Configuration Engine server.
Q. Why did I fail to discover an IOS device and acquire its configuration through Configuration Engine?
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 error-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-hostname cns-ip-address.
Q. Why does not the event mode router appear on the Configuration Engine Discover Device page or appear in green on the Configuration Engine web page?
Check the following:
– Make sure that the router and the Configuration Engine server can ping each other.
– Make sure that the event gateway on the Configuration Engine server is up and running by using one of the following commands:
Status for plain text mode: /etc/init.d/EvtGateway
Status for SSL encrypted mode: /etc/init.d/EvtGatewayCrypto
– Clear the cns event command, then re-enter it without specifying a port number.