NAV 4.8.6
We have a Cisco catalyst switch with a broken power supply. After changing the power supply NAV shows Status "Unknown" in the /#!sensors page.
The ipdevpoll jobs runs without errors. Where shall I look?
--Ingeborg
On 2019-05-08 09:43, Ingeborg Hellemo wrote:
NAV 4.8.6
We have a Cisco catalyst switch with a broken power supply. After changing the power supply NAV shows Status "Unknown" in the /#!sensors page.
The ipdevpoll jobs runs without errors. Where shall I look?
--Ingeborg
We have many 2960S and all of those shows Unknown always it will help me too
Thanks, Mr. Router
On Wed, 8 May 2019 08:43:14 +0200 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
NAV 4.8.6
We have a Cisco catalyst switch with a broken power supply. After changing the power supply NAV shows Status "Unknown" in the /#!sensors page.
The ipdevpoll jobs runs without errors. Where shall I look?
NAV will discover the presence of PSUs using ENTITY-MIB. However, the actual status of discovered PSUs must be polled through proprietary MIBs. For Cisco, this is typically from CISCO-ENTITY-FRU-CONTROL-MIB.
If the representation in CISCO-ENTITY-FRU-CONTROL-MIB cannot be correlated to the representation in ENTITY-MIB, then the status will be unknown to NAV. I've also seen devices report status values in CISCO-ENTITY-FRU-CONTROL-MIB that do not correspond to anything in the published MIB.
Step 1: I would enable debug logging for powersupplywatch (`nav.powersupplywatch=DEBUG` in logging.conf), then run powersupplywatch.py manually to see what the output is.
Step 2: You could query the CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerStatusTable to see what it says (the specifically interesting column is cefcFRUPowerOperStatus, and the index value of each row should correspond to the index from ENTITY-MIB::entPhysicalTable).
morten.brekkevold@uninett.no said:
Step 1: I would enable debug logging for powersupplywatch (`nav.powersupplywat ch=DEBUG` in logging.conf), then run powersupplywatch.py manually to see what the output is.
That did not help much
[2019-05-14 13:03:21,379] [DEBUG] Polling mh-sw.infra.uit.no: Switch 1 - Power Supply B [2019-05-14 13:03:21,384] [DEBUG] Stored state = Up; polled state = Up
[2019-05-14 13:03:21,404] [DEBUG] Polling mh-sw.infra.uit.no: Switch 1 - Power Supply A [2019-05-14 13:03:21,406] [DEBUG] Stored state = Unknown; polled state = Unknown
morten.brekkevold@uninett.no said:
Step 2: You could query the CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerStatusTa ble to see what it says (the specifically interesting column is cefcFRUPowerOperStatus, and the index value of each row should correspond to the index from ENTITY-MIB::entPhysicalTable).
I grouped the results after index:
ENTITY-MIB::entPhysicalDescr.1014 = STRING: Switch 1 - Power Supply A ENTITY-MIB::entPhysicalVendorType.1014 = OID: CISCO-SMI::ciscoModules.3.1.6.388 ENTITY-MIB::entPhysicalContainedIn.1014 = INTEGER: 1006 ENTITY-MIB::entPhysicalClass.1014 = INTEGER: powerSupply(6) ENTITY-MIB::entPhysicalParentRelPos.1014 = INTEGER: 1 ENTITY-MIB::entPhysicalName.1014 = STRING: Switch 1 - Power Supply A ENTITY-MIB::entPhysicalHardwareRev.1014 = STRING: V02 ENTITY-MIB::entPhysicalFirmwareRev.1014 = STRING: ENTITY-MIB::entPhysicalSoftwareRev.1014 = STRING: ENTITY-MIB::entPhysicalSerialNum.1014 = STRING: DCB2044C115 ENTITY-MIB::entPhysicalMfgName.1014 = STRING: ENTITY-MIB::entPhysicalModelName.1014 = STRING: PWR-C2-1025WAC ENTITY-MIB::entPhysicalAlias.1014 = STRING: ENTITY-MIB::entPhysicalAssetID.1014 = STRING: ENTITY-MIB::entPhysicalIsFRU.1014 = INTEGER: true(1) ENTITY-MIB::entPhysicalMfgDate.1014 = STRING: 0-0-0,0:0:0.0 ENTITY-MIB::entPhysicalUris.1014 = ""
ENTITY-MIB::entPhysicalDescr.1015 = STRING: Switch 1 - Power Supply B ENTITY-MIB::entPhysicalVendorType.1015 = OID: CISCO-SMI::ciscoModules.3.1.6.388 ENTITY-MIB::entPhysicalContainedIn.1015 = INTEGER: 1007 ENTITY-MIB::entPhysicalClass.1015 = INTEGER: powerSupply(6) ENTITY-MIB::entPhysicalParentRelPos.1015 = INTEGER: 2 ENTITY-MIB::entPhysicalName.1015 = STRING: Switch 1 - Power Supply B ENTITY-MIB::entPhysicalHardwareRev.1015 = STRING: V02 ENTITY-MIB::entPhysicalFirmwareRev.1015 = STRING: ENTITY-MIB::entPhysicalSoftwareRev.1015 = STRING: ENTITY-MIB::entPhysicalSerialNum.1015 = STRING: DCB2044C11S ENTITY-MIB::entPhysicalMfgName.1015 = STRING: ENTITY-MIB::entPhysicalModelName.1015 = STRING: PWR-C2-1025WAC ENTITY-MIB::entPhysicalAlias.1015 = STRING: ENTITY-MIB::entPhysicalAssetID.1015 = STRING: ENTITY-MIB::entPhysicalIsFRU.1015 = INTEGER: true(1) ENTITY-MIB::entPhysicalMfgDate.1015 = STRING: 0-0-0,0:0:0.0 ENTITY-MIB::entPhysicalUris.1015 = ""
As you suggested the problem is in the CISCO-ENTITY-FRU-CONTROL-MIB. Index 1014 is missing completely.
CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerAdminStatus.1015 = INTEGER: on(1) CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerOperStatus.1015 = INTEGER: on(2) CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUCurrent.1015 = INTEGER: 0
Anything we can do? Kick the box? Curse the manufacturer?
--Ingeborg
On Tue, 14 May 2019 13:22:34 +0200 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
As you suggested the problem is in the CISCO-ENTITY-FRU-CONTROL-MIB. Index 1014 is missing completely.
CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerAdminStatus.1015 = INTEGER: on(1) CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUPowerOperStatus.1015 = INTEGER: on(2) CISCO-ENTITY-FRU-CONTROL-MIB::cefcFRUCurrent.1015 = INTEGER: 0
Anything we can do? Kick the box? Curse the manufacturer?
Cursing the manufacturer would be step one. I might suggest rebooting the device, but I guess that defeats the purpose of having redundant power supplies :-P Can the SNMP-agent be restarted without rebooting?
I think your question should be directed at Cisco at this point (but if you do figure something out, please do share).
-
imrouter＠vivaldi.net -
Ingeborg Hellemo -
Morten Brekkevold