RME 4.2 - not reporting SN of TenGig (XenPak) though SN is listed in ENTITY

Martin Ermel · ‎05-06-2009

Currently in RME 4.2 DDR does not report the serial number of the TenGig modules (XenPak) though the ENTITY-MIB is reporting these values correctly. I attached a show version along with a snmp-walk and the "Detailed Device Report" of a Cat6500.

According to the user guide of RME 4.2 there should be the UDI (which contains the serial number) for all components of a device:

==========

From RME 4.2 User Guide:

http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_resource_manager_essentials/4.2/user/guide/invent.html

The Detailed Device report also displays the Unique Device Identifier (UDI) for all components of a device. UDI is unique to each component of a device. It is a combination of Product Identifier (PID), Version Identifier (VID) and Serial Number (SN).

==========

The ENTITY-MIB does handle the XenPak as a port as well as a FRU (Field Replacable Unit). The fact that it is handled as a FRU should classify it as a component with the potential of a serial number and thus a UDI.

ENTITY-MIB::entPhysicalDescr.4009 = STRING: 10Gbase-ER

ENTITY-MIB::entPhysicalContainedIn.4009 = INTEGER: 4008

ENTITY-MIB::entPhysicalClass.4009 = INTEGER: port(10)

ENTITY-MIB::entPhysicalName.4009 = STRING: Te6/1

ENTITY-MIB::entPhysicalIsFRU.4009 = INTEGER: true(1)

Instead the slot in which the XenPak is inserted has a UDI asigned to it. This slot is handeled as a "Container" but it is not classified as a FRU.

ENTITY-MIB::entPhysicalDescr.4008 = STRING: 10-Gigabit Port Container

ENTITY-MIB::entPhysicalContainedIn.4008 = INTEGER: 4000

ENTITY-MIB::entPhysicalClass.4008 = INTEGER: container(5)

ENTITY-MIB::entPhysicalName.4008 = STRING: 10-Gigabit Port Container 6/1

ENTITY-MIB::entPhysicalIsFRU.4008 = INTEGER: false(2)

With regard to the fact that serial number tracking is a very important issue in todays network management tasks and asset management this should quickly be changed and "Module Port interfaces" should be enhanced with a "SerialNumber" and "UniqueDeviceIdentifier" field!

According to the User Guide I would even count this as a bug because the documentation says it should be their... - or am I wrong with this assumption?

Joe Clarke · ‎05-06-2009

I agree that this could be considered a bug, but admittedly, RME is working as designed. Historically, ports have been fixed entities in chassises, and had no separate serial numbers. With the advent of XenPaks, things really got screwy because not only was a port FRUable, it was actually a container for sensors. This broke RME, and I had to fix the way RME handles ports.

Unfortunately, the RME reports still treat ports as ports. I just filed CSCsz48654 requesting that port serial numbers be reported. I suggest you open a TAC service request so your SR can be linked to this bug. Hopefully this can be addressed in LMS 3.3.

Martin Ermel · ‎05-06-2009

thanks!

how should the SR be handeled? just open it, feed it with the information of my last post let it point to the bug and close it again? Would this be enough to give it some weight?

Joe Clarke · ‎05-06-2009

This should be enough, but it wouldn't hurt to have a PERS filed as well.

Joe Clarke · ‎05-09-2009

The bug has been assigned a developer, so work is starting. That's promising news for getting this into the next release of RME.

Martin Ermel · ‎05-13-2009

thank you for this very helpfull update!

Will a SR still be necessary or does it go its way into the next release alone?

Joe Clarke · ‎05-13-2009

It would still be good to have an SR linked to the request for tracking purposes.