NCM - Device Inventory - lack there of

Thanks Bryan,

Good input. This was already on our radar, it's even more so, now that I have increased the votes on this requirement, based on your input (68290).

Can't commit on anything though, as you know.

Feedback on usefulness of the Inventory reports, others?

I'll chime in here as well. I have worked in an "all Cisco shop" where NCM made it really easy to inventory all of the network devices and keep that inventory up to date. I have always read about multi-vendor support in release notes and marketing materials since the day that NCM was introduced (as Cirrus back then).

Now that I am working in an environment with hardware from several vendors, I am finding that the multi-vendor support extends to configuration downloads and management only. It would appear that the inventory piece of NCM has not been designed to handle hardware inventory of devices from mainstream vendors such as Juniper and F5.

I would like to see the inventory component of NCM developed to be more robust in an effort to allow inventory of not only these devices but also more obscure devices as well.

This thread is quite old, could SW update us on improvements related to this subject? I am trying to get inventoy data from NPM and NCM and it is proving to be quite difficult. Does anyone have some scripts/reports available to get inventory from these databases?Servers?

I'll chime in here as well. I have worked in an "all Cisco shop" where NCM made it really easy to inventory all of the network devices and keep that inventory up to date. I have always read about multi-vendor support in release notes and marketing materials since the day that NCM was introduced (as Cirrus back then). Now that I am working in an environment with hardware from several vendors, I am finding that the multi-vendor support extends to configuration downloads and management only. It would appear that the inventory piece of NCM has not been designed to handle hardware inventory of devices from mainstream vendors such as Juniper and F5. I would like to see the inventory component of NCM developed to be more robust in an effort to allow inventory of not only these devices but also more obscure devices as well.

Even the support for "all" cisco devices are limited.  Try a stack of 3750s, LWAPS, etc.
Typically I need to run an elaborate list of extracts to obtain yearly maintenance and support reports.

Eventually I added in a Custom Property "Serial Numbers" for manual input of this critical information.  This goes nicely with a custom property "Maintenance" for the type of Smartnet we acquired for the appliance

Similiar processes for Brocade, F10, DELL, Telco, etc, etc., etc.  devices we manage.

I understand that some of the issues surround snmp and where vendors stick their data.  But there is the universl device poller, so locating where the data is and getting it should be part of the package.

Tks rcahill,

We have opened a new enhancement request to provide more flexibility in the Inventory report, that would help configuring where (i.e. what OID) the interesting info resides, as far as the Inventory is concerned. (108146)

During our investigation, we have noticed that some devices can report more than one S/N per card. Any requirement on what to report in NCM, in such a case? First one? All of them?

Fracois,

Wonderful and thanks for the update.

To your question,

Any requirement on what to report in NCM, in such a case? First one? All of them?

is I simply don't know where you are getting the snmp data.

If you are going through a switch inventory for serial numbers you may obtain serial number overload:

for a chassis this would be due to transceivers, power supplies, clock, fans, etc.  All good information to be certain.  Not data necessary for maintenance and warranty.

for a stack similarly they will have a variety of the same data. Cisco stack devices will also include data for Motherboard, Daughterboard, etc. serial numbers.  Within an inventory SNMP get I don't believe that the "System Serial Number" is always first in order.  For a cisco device this is the interesting warranty data to capture.

Some clients may wish all of that data, we don't at this time.

During SW investigation, do your clients a tremendous favor.

• Record the successful OIDs where Serial Numbers have been found for the devices.  This way the upgrade documents could reference a forum site where readers can obtain or could post their own "Serial Number" OIDS to expand the wide variety of devices.  Even those that are only covered in NPM.  
• Possibly include a Forum posting like NPMs "Tell us your "Unknown" devices" for "Tell us your good Serial Number OIDS" in advance for your testing and information gathering.

Again thanks, 

I'm in agreement with rcahill.  For the forseeable future, the box serial number is the only thing of interest.  Future interest would be in installable parts such as cards in slots, chassis stack serial numbers, memory and flash size, etc.  Right now when I run a Physical Entities (Serial Number) report I get multiple lines for many devices within a box.  If it could be narrowed down to serial number of the chassis or supervisor, it would give me a report I could pass on to asset management people for managing the asset lists and the service contracts.  That may be a custom retrieval for each unique device type.