RME 2.x/3.x Inventory: Frequently Asked Questions

Document ID: 13474

Questions

Introduction
What happens when I add new devices?
What happens when I import new devices (locally and remotely)?
What happens when I delete devices?
What happens when I update devices?
What are the most frequent causes of device import failures?
How can I check whether a device is supported by RME Inventory?
How can I verify that the device attributes and credentials configured on the device match those present in the RME Inventory?
What do I need to collect from my Solaris or Windows machine when I troubleshoot RME Inventory?
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

Adding, importing, deleting, and updating are four of the most frequently used procedures in Resource Manager Essentials (RME) Inventory. This document provides answers to the most frequently asked questions related to these procedures.

For more information on document conventions, see the Conventions Used in Cisco Technical Tips.

Q. What happens when I add new devices?

A. When you add new devices, these events occur:

The DIServer performs an inventory collection.

The DIServer sends the Daemon Manager information about the added device, which includes the device ID.

The InvChangeProbe daemon receives the information, translates the message to an Event Distribution Service (EDS) event, and pushes it to the EDS event channel. The translated message includes the device name and event header.

The ChangeAudit daemon receives the message from the EDS event channel and checks to see if the added device is supported by Configuration Management.

If the device is supported, the ChangeAudit daemon calls the Transport module, which retrieves the device configuration, archives it in the NMSROOT/files/archive/config directory for RME 2.x and in the NMSROOT/rigel/rme/config/archive/config for RME 3.x, and labels it as the base version.

If the device is not supported, the ChangeAudit daemon updates the appropriate table in rme.db with the device entry.

If you have selected the Check Device Attributes checkbox, the credentials check is performed.

Q. What happens when I import new devices (locally and remotely)?

A. When you import new devices, these events occur:

The DIServer performs an inventory collection.

The DIServer sends the Daemon Manager information about the imported device, which includes the device ID.

The InvChangeProbe daemon receives the information, translates the message to an Event Distribution Service (EDS) event, and pushes it to the EDS event channel. The translated message includes the device name and event header.

The ChangeAudit daemon receives the message from the EDS event channel and checks to see if the imported device is supported. If the device is supported, the ChangeAudit daemon calls the Transport module, which retrieves the device configuration, it in the NMSROOT/files/archive/config directoryfor RME 2.x and in the NMSROOT/rigel/rme/config/archive/config for RME 3.x, and labels it as the base version.

If the device is not supported, the ChangeAudit daemon updates the appropriate table in rme.db with the device entry.

If you have selected the Check Device Attributes checkbox, the credentials check is performed.

Q. What happens when I delete devices?

A. When you delete devices, these events occur:

The device data is deleted from rme.db.

The delete device script generates a Daemon Manager message that passes the device ID and the type of event (delete).

The InvChangeProbe daemon receives the information, translates the message to an Event Distribution Service (EDS) event, and pushes it to the EDS event channel. The translated message includes the device name and event header.

The ChangeAudit daemon receives the message from the EDS event channel and calls the Transport module to delete the archive data from the NMSROOT/files/archive/config directory for RME 2.x and in the NMSROOT/rigel/rme/config/archive/config for RME 3.x.

Q. What happens when I update devices?

A. When you update devices, these events occur:

The IcServer updates rme.db and generates a Daemon Manager message that passes the device ID and the type of event (update).

The InvChangeProbe daemon receives the information, translates the message to an Event Distribution Service (EDS) event, and pushes it to the EDS event channel. The translated message includes the device name and event header.

The ConfigArchive daemon receives the message from the EDS event channel and compares it with the latest configuration in the NMSROOT/files/archive/config directory for RME 2.x and in the NMSROOT/rigel/rme/config/archive/config for RME 3.x.

The new configuration file is archived as the latest file, and the older configuration is tagged with a version number.

Q. What are the most frequent causes of device import failures?

A. These are the most common causes of device import failures:

Incorrect Simple Network Management Protocol (SNMP) community strings.

SNMP agent is not enabled on the managed device. If SNMP agent is not enabled on the device (SNMP community strings are not configured), refer to How to Configure SNMP Community Strings for details on how to configure and verify them.

Somewhere in the path between the managed device and the management server, there is something that blocks the SNMP traffic; for example, a router with an access control list (ACL) or a firewall. On the managed device, there are ACLs that limit the number of machines that can interact with that device.

The device is very busy or is slow to respond, so you time out before you collect all the data needed to import the device. To verify this through the device CLI, issue the debug snmp pack command and look for snmp-timeout messages. If the number of timeout messages is high, then you can check whether the IP-SNMP process has taken up all CPU utilization. Issue the sh proc cpu command to check that. Try to spread or size down the SNMP requests on that device. Refer to IP Simple Network Management Protocol (SNMP) Causes High CPU Utilization for more information.

The communication path between the managed device and the server is congested, and hence results in a timeout.

Q. How can I check whether a device is supported by RME Inventory?

A. The procedure differs by the version of RME.

RME 2.x

Refer to the Supported Device List for RME 2.x.

RME 3.x

First, refer to the Supported Device List to see whether or not an RME upgrade is required. Also, verify that the device in question meets the minimum software requirements stated in the list.

Second, if the device in question is listed in the Supported Device List, but RME does not recognize it, log in to RME as Administrator. Choose Server Configuration > About the Server > Applications and Versions from the menu. Under the Applications Installed section, click the Inventory Manager link. A list of devices supported by RME Inventory Manager along with the sysObjectID values is shown.

Q. How can I verify that the device attributes and credentials configured on the device match those present in the RME Inventory?

A. The procedure differs by the version of RME.

RME 2.x

Log in to RME as Administrator. Choose RME > Administration > Inventory > Export to File from the menu, and then click the CSV format button. This file is saved on the server. The default location is $NMSROOT/CSCOpx. Check the file manually to see that the device attributes match what is configured on the device itself.

RME 3.x

Complete these steps:
Log in to RME as Administrator. Choose RME > Administration > Inventory > Export to file from the menu and select CSV format, which exports the device attributes to /var/adm/CSCOpx/files/inventory (default location for UNIX) or C:/Program Files/CSCOpx/files/inventory (default location for Windows) on the file system of the server. Check this file manually to see that the device attributes match those configured on the device itself. Choose RME > Administration > Inventory > Check Device Attributes from the menu to ensure that the device attributes are correct .

Q. What do I need to collect from my Solaris or Windows machine when I troubleshoot RME Inventory?

A. The procedure differs by the version of RME.

RME 2.x

Log in to RME as Administrator. Choose RME > Administration > Troubleshooting > Collect Server Info from the menu. Click Create. The new report appears in the Reports history list.

Note: It might take up to five minutes to collect the information. Select the report from the Reports history list, and then click Display. Use the File > Save As option in your web browser to save this as an .html file.

RME 3.x

Log in to RME as Administrator. Choose Server Configuration > Diagnostics > Collect Server Info from the menu. Click Create. Creation may take up to five minutes. The newly created report name is in the format, "Server Information at mm-dd-yyyy hr-min-sec." Click the report name. This opens the report in a new browser window. Use the File > Save As function of your browser to save it as an .html file.

Additional Information

A command line script is also available at /opt/CSCOpx/bin/collect.info. The command script outputs data to STDOUT. If you collect server information through the GUI, data is stored in /opt/CSCOpx/htdocs/collect. In Windows, the script collect.info.cmd is located in the $NMSROOT/CSCOpx/bin directory. To execute this and redirect the output to a file, issue the C:\Program Files\CSCOpx\bin\collect.info.cmd > file_name command, where file_name is the name of the file in which you want to save the output.

For both Windows and Solaris, turn on the debug for IcServer and DIServer from CLI as described here, where ADB is Application Debug level and LDB is Low level Debug level:

Note: In order to turn on debugging, you must be root (UNIX) or Administrator (Windows).

$NMSROOT/bin/pdmsg 'IcServer: ADB:=0xFFFFFFFF LDB:=0xFFFFFFF'

$NMSROOT/bin/pdmsg 'DIServer: ADB:=0xFFFFFFFF LDB:=0xFFFFFFF'

These commands give you all of the debug output.

Note: This turns on the debugging for DIServer only.

In Windows, all the debug messages are saved in the DIServer.log and IcServer.log files. In Unix, these messages are saved in the /var/adm/CSCOpx/log/daemon.log file. Do not forget to turn off the debug output once you are done. The easiest way to do this is to stop the daemon manager and restart it by the appropriate method listed here (this requires that the user be logged in as root):

Solaris Windows HP-UX AIX

/etc/init.d/dmgtd stop C:\net stop crmdmgtd /sbin/init.d/dmgtd stop /etc/rc.dmgtd stop

/etc/init.d/dmgtd start C:\net start crmdmgtd /sbin/init.d/dmgtd start /etc/rc.dmgtd start

These debug log files, along with the Collect Server Info output, can then be e-mailed to Cisco Technical Support.