Catalyst 2960XR and SNMP

[rmothers]

Hi

I have two identical Catalyst 2960XR switches (or so I thought) and both have dual power supplies being monitored by SNMP (v2).  However, one is showing RPS-B is down whilst the other shows RPS-A and RPS-B healthy.  On the first switch both power supplies are healthy (I can disconnect the power from RPS-A and the switch remains up).  Using a MIB Browser I have found that both switches have different MIB strings for the second power supply.

Switch one has a MIB of 1.3.6.1.4.1.9.9.13.1.5.1.3.1037 for its second power supply whereas Switch two has a MIB of 1.3.6.1.4.1.9.9.13.1.5.1.3.1042 for its second power supply .

Below is the output from Switch 1 sh ver and sh inventory commands

Cisco IOS Software, C2960X Software (C2960X-UNIVERSALK9-M), Version 15.2(2)E6, RELEASE SOFTWARE (fc1)

BOOTLDR: C2960X Boot Loader (C2960X-HBOOT-M) Version 15.2(3r)E1, RELEASE SOFTWARE (fc1)

System image file is"flash:/c2960x-universalk9-mz.152-2.E6/c2960x-universalk9-mz.152-2.E6.bin"

Model number  : WS-C2960XR-24TS-I

NAME: "1", DESCR: "WS-C2960XR-24TS-I"
PID: WS-C2960XR-24TS-I , VID: V06  , SN: FDO2112B128
NAME: "Switch 1 - Power Supply 1", DESCR: "FRU Power Supply"
PID: PWR-C2-250WAC     , VID: V03L , SN: LIT21092HSR
NAME: "Switch 1 - Power Supply 2", DESCR: "FRU Power Supply"
PID: PWR-C2-250WAC     , VID: V03D , SN: DCB2110DE78

Below is the output from Switch 2 for its sh ver and sh inventory commands

Cisco IOS Software, C2960X Software (C2960X-UNIVERSALK9-M), Version 15.2(2)E6, RELEASE SOFTWARE (fc1)

BOOTLDR: C2960X Boot Loader (C2960X-HBOOT-M) Version 15.2(3r)E1, RELEASE SOFTWARE (fc1)

System image file is "flash:/c2960x-universalk9-mz.152-2.E6/c2960x-universalk9-mz.152-2.E6.bin"

Model number : WS-C2960XR-24TS-I

NAME: "1", DESCR: "WS-C2960XR-24TS-I"
PID: WS-C2960XR-24TS-I , VID: V06  , SN: FDO2112B121
NAME: "Switch 1 - Power Supply 1", DESCR: "FRU Power Supply"
PID: PWR-C2-250WAC     , VID: V03D , SN: DCB2110D28G
NAME: "Switch 1 - Power Supply 2", DESCR: "FRU Power Supply"
PID: PWR-C2-250WAC     , VID: V03L , SN: LIT21092KUU

As you can see from these outputs the switches are identical, however, they have different MIB strings for the same device.  Has anybody seen anything similar - and if so is there a way to have the MIB string the same?  Is there some minor difference elsewhere that I should be looking at to explain this behavioural difference?

Thanks

Robert

[Flavio Miranda]

Hi @rmothers

 As you have the same switch model then the MIB file is the same. If you go to Cisco download page, you can see that.

 The OID 1.3.6.1.4.1.9.9.13.1.5.1.3.1042 

can be used to switch 1 and 2. You can test that using a linux server and running the command snmpwalk -v 2c -c "community" "switch ip address"

This should work in both switches.

 Then you need to change your NMS to pass this OID to both switches.

-If I helped you somehow, please, rate it as useful.-

[rmothers]

Flavio

Thank you for the response.  However, snmp walk confirmed different MIB strings - see photo.

Thanks

Robert

snmp walk

[Rolf Fischer]

Hello Robert,

this is normal behavior.

You're polling objects of the CISCO-ENVMON-MIB, for instance ciscoEnvMonSupplyState (1.3.6.1.4.1.9.9.13.1.5.1.3). The last number of the variable (1042 vs. 1037) is an index ("ciscoEnvMonSupplyStatusIndex"), which identifies the power supply. From the MIB definition:

ciscoEnvMonSupplyStatusIndex

DESCRIPTION:

"Unique index for the power supply being instrumented. This index is for SNMP purposes only, and has no intrinsic meaning."

We don't know the internal logic how a device assigns these indices, but you always need to expect that indices vary among different devices. The safer way is to do a walk over an object first to identify the index used by the device for a particular entity.

HTH

Rolf

[rmothers]

Hi Rolf

Thanks for the reply. 

The issue that confuses me here is these are not different devices they are the same switch model number.  I'd expect this behaviour between different switch model numbers but not the same.  However, it does appear this is happening.

In the meantime I'll look at monitoring the status using a different MIB string.

Thanks again

Robert