LMS 3.2 - All 7609's showing up as 7606's...

[mssnider]

LMS 3.2 on Solaris 10.

I just realized that our 7609's are listed as 7606's. I just tried updating the device packages and didn't see anything pertaining to 7609's and they are still listed as 7606's.

Is there a device package for the 7609's? They have been around for a long time, I'm surprised there isn't a way to properly manage them with LMS.

Thanks,

[Joe Clarke]

Where are they showing up as 7606s?  What are the sysObjectIDs from these routers?

[chris.mcgarrah]

We have the same issue.  The system object id for the 7609 is .1.3.6.1.4.1.9.1.863

It shows up as 7606.

[Joe Clarke]

Chassis with this sysObjectID are 7606-S routers.  So LMS is correct.  If these are actually nine-slot chassis, then something is wrong on the device side.  The 7609 sysObjectIDs are 1.3.6.1.4.1.9.1.509 and 1.3.6.1.4.1.9.1.864.

[chris.mcgarrah]

These are actually 9-slot chassis.  What could be wrong on the device side ?  Can the sysobjectid be modified ?

[Joe Clarke]

No, the sysObjectID is built into the chassis.  I haven't been able to find a bug that explains this behavior.  Post a "show version" from one of these switches as well as a walk of the entPhysicalTable.

[chris.mcgarrah]

Requested info is attached.

[Joe Clarke · Accepted solution]

The bug for this was hard to find due to a bad headline, but you're seeing CSCsm83948.  This is fixed in 12.2(18)SXF14.

[mssnider]

Great, we need to upgrade IOS to fix LMS...too bad this is on our key devices making outages nearly impossible.

As always, thanks for the information. You've helped me many, many times with my LMS questions!

[Marvin Rhoads]

LMS highlighting this bug is a mixed blessing.

On the other hand, you are running an aging IOS image (12.2(18)SXF17a is the current revision in that train - Release Notes) and the devices haven't been reloaded in over two years. As relatively high end key network devices, does your network design have redundancy built-in? A reload on a 7609 will cause that device and any services it provides to be offline for 1-2 minutes. You may be able to use that as a catalyst for design modification to remove the single point of failure (if such is indeed the case). You would also have the benefit of addressing other bug fixes which may not be so benign as the one Joe highlighted.

[chris.mcgarrah]

I believe you were responding to the original poster while referring to the information I posted, but you raise some valid points.  These are also key devices in our network, and are configured redundantly, so code could be upgrade with little or no outage, potentially, as you suggest.  There are however other considerations such as change windows and testing. With any code upgrade there is always the potential of introducing other problems as well.

With respect to this particular bug, can either you or Joe answer what impact it has on LMS's ability to manage the device ?  Is it just cosmetic, or are there specific technical things that LMS cannot do because the device is seen as a 7606 rather than a 7609 ?

Thanks.

[Joe Clarke]

CiscoView will certainly get confused when it comes to displaying the chassis, but it might still work since the ENTITY objects are correct.  Other modules should work as the instrumentation between the 7606 and 7609 is the same.

[mssnider]

From my experience, it doesn't affect the 'management' of the device. It does affect the reporting and CiscoView. The 7609's show up as 7606's in all device reports and CiscoView shows it as a 7606 with just the 6 slots. However, all RME jobs, Netconfig, etc still function as expected.

[Joe Clarke]

The bug here is with the device.  LMS is reporting what it's told.  If you were to manually change the device type in LMS, that would actually break collection in LMS.  If you do upgrade, you will need to go to Common Services > Device and Credentials > Device Management to correct the device type as RME will most likely start to see this device as conflicting.