3

I'm working on creating a monitor script for some access layer switches. I've gotten it to work with some Cisco 3750s, but when I try it on a Cisco 3560, it says the OID object not found. After looking at Cisco's MIB locator, it is the same for both platforms. Am I missing something here?

montorbox# snmpget -v1 -c public 10.x.x.x 1.3.6.1.4.1.9.9.13.1.3.1.3
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.

I've added my monitor server to the SNMP server host group. Do I have to load something additional onto the switch?

  • It looks like you may be missing the instance subidentifier. You can find what your missing by performing an snmpwalk on that OID 1.3.6.1.4.1.9.9.13.1.3.1.3. If there are multiple 3560s in a stack then you'll have more than one instance subidentifier for the ciscoEnvMonTemperatureStatusValue object. – one.time Jun 23 '15 at 19:40
  • Thanks, still getting no such object at this OID. They are not stacked in this case. – Jim Jun 23 '15 at 20:17
  • Have you tried changing your SNMP version to 2? snmpwalk -v2c -c public 10.x.x.x 1.3.6.1.4.1.9.9.13.1.3.1.3 to get your instance subidentifier and then snmpget -v2c -c public 10.x.x.x 1.3.6.1.4.1.9.9.13.1.3.1.3.isid. – one.time Jun 23 '15 at 21:11
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 7 '17 at 20:13
2

1.3.6.1.4.1.9.9.13.1.3.1.3 is an OID for ciscoEnvMonTemperatureStatusTablein CISCO-ENVMON-MIB, and it is marked as MAX-ACCESS not-accessible in mib. So, snmpget will always fail on it:

snmpget -v1 -c public abn21 .1.3.6.1.4.1.9.9.13.1.3 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: SNMPv2-SMI::enterprises.9.9.13.1.3

But snmpwalk will succeed:

snmpwalk -v1 -c public abn21 .1.3.6.1.4.1.9.9.13.1.3 SNMPv2-SMI::enterprises.9.9.13.1.3.1.2.1005 = STRING: "SW#1, Sensor#1, GREEN " SNMPv2-SMI::enterprises.9.9.13.1.3.1.3.1005 = Gauge32: 29 SNMPv2-SMI::enterprises.9.9.13.1.3.1.4.1005 = INTEGER: 59 SNMPv2-SMI::enterprises.9.9.13.1.3.1.5.1005 = INTEGER: 0 SNMPv2-SMI::enterprises.9.9.13.1.3.1.6.1005 = INTEGER: 1

The same with cisco mibs in /usr/share/snmp/CISCO:

snmpwalk -v1 -c public -M /usr/share/snmp/CISCO -m CISCO-ENVMON-MIB -IR abn21 ciscoEnvMonTemperatureStatusTable CISCO-ENVMON-MIB::ciscoEnvMonTemperatureStatusDescr.1005 = STRING: SW#1, Sensor#1, GREEN CISCO-ENVMON-MIB::ciscoEnvMonTemperatureStatusValue.1005 = Gauge32: 29 degrees Celsius CISCO-ENVMON-MIB::ciscoEnvMonTemperatureThreshold.1005 = INTEGER: 59 degrees Celsius CISCO-ENVMON-MIB::ciscoEnvMonTemperatureLastShutdown.1005 = INTEGER: 0 degrees Celsius CISCO-ENVMON-MIB::ciscoEnvMonTemperatureState.1005 = INTEGER: normal(1)

Note snmp entries ids like 1.2, 1.3 ... and sensor instance 1005 (may vary in your case) in snmpwalk output - using such complete OID you can access table entries directly with snmpget:

snmpget -v1 -c public abn21 .1.3.6.1.4.1.9.9.13.1.3.1.2.1005 SNMPv2-SMI::enterprises.9.9.13.1.3.1.2.1005 = STRING: "SW#1, Sensor#1, GREEN "

PS: snmp version (1 or 2c) doesn't matter here.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.