how to get port/interface status of cisco switch via snmp

Question

I am trying to write a simple program that displays the front panel of cisco devices remotely (in this case a 3560 switch). So I need to read the status of each port via snmp and turn on the LED on my GUI accordingly. After some search I came to use the "ifOperStatus" with OID 1.3.6.1.2.1.2.2.1.8.

But the problem is that this OID returns "1:up" as soon as a cable is plugged into the port and does not reflect the different status the port might have including:

Blinking green: Link has activity

Solid amber: Port is faulty

etc,

Any clue or hint on which OIDs I should use?

Answer 1

Have you looked at this OID ?

Specific Object Information 
Object  clsPortLedStatus
OID 1.3.6.1.4.1.9.5.11.1.7.1.1.3
Type    INTEGER
Permission  read-only
Status  current
Values  1 : unknown
2 : on
3 : off
MIB CISCO-RHINO-MIB 
Description "Indicates the status of the LED.
Unknown(1) indicates either the LED status is 
not supported or the status is none of the
defined."

And the related :

Specific Object Information 
Object  clsPortLedType
OID 1.3.6.1.4.1.9.5.11.1.7.1.1.2
Type    INTEGER
Permission  read-only
Status  current
Values  1 : ledTx
2 : ledRx
3 : ledLink
4 : led100Mbps
5 : ledRxLoss
6 : ledRxFullOut
7 : ledRxSync
8 : ledFullDuplex
9 : ledOptDetect

Unfortunately the supported images/platforms are very limited : http://tools.cisco.com/ITDIT/MIBS/AdvancedSearch?MibSel=4682

I would say fake it, for link activity. Poll interface stats (bytes or frames or packets in or out) and make the light in your application blink as long as either is increasing.
(Though I suppose technically some control traffic might or might not cause the physical LED to blink - for example, do BPDUs alone count towards link activity ? I do not know - I can check later, if you'd like.)

I searched and browsed the SNMP Object Navigator (http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en) last night for you, but found nothing suitable (not to say it doesn't exist), and any potentially interesting ones were marked as inaccessible ("Permission not-accessible").

If you're feeling especially crafty, and want the utmost accuracy, you could probably setup an ambient light sensor / "light to frequency converter" in front of each crucial port LED, and code to have that info passed to your application.
But that's not scalable, so it's probably easier to fake it.

EDIT, ROUND 2 !

How about :

"This object is used to indicate the current color of a LED."

Object  c2900PortVisualIndicator
OID 1.3.6.1.4.1.9.9.87.1.4.1.1.24
Type    INTEGER
Permission  read-only
Status  current
Values  1 : notused
2 : black
3 : amber
4 : green
MIB CISCO-C2900-MIB
Description "This object is used to indicate the current color of
a LED. If a LED is flashing, the value of this object will
represent the color of the LED at that instant in time.
The following conventions indicate port status:
Link healthy returns green(4)
Link activity usually green(4), but may return black(2).
Link faulty alternating green(4)/amber(3)
Port disabled returns amber(3)"

"The color of the LED."

Object  ceExtEntityLEDColor
OID 1.3.6.1.4.1.9.9.195.1.3.1.2
Type    INTEGER
Permission  read-only
Status  mandatory
Values  1 : off
2 : green
3 : amber
4 : red
MIB CISCO-ENTITY-EXT-MIB-V1SMI
Description The color of the LED.

"An integer value that describes the color of the display"

Type    CDisplayColor
Status  current
Values  1 : unknown
2 : white
3 : red
4 : green
5 : yellow
6 : amber
7 : blue
8 : greenAndAmber
MIB CISCO-ENTITY-DISPLAY-MIB
Description "An integer value that describes the color of the display.

'greenAndAmber' - Indicates that the display color toggles between green and amber."

As well as,
mrStackUnitBasePortVisualIndicatorGreenMap,
mrStackUnitBasePortVisualIndicatorAmberMap,
mrStackUnitExpansionPortVisualIndicatorGreenMap,
mrStackUnitExpansionPortVisualIndicatorAmberMap, and
mrStackUnitActivityVisualIndicator
all under mrStackUnitEntry.

For ATM :
ciscoAtmIfXmitLed
ciscoAtmIfRecvLed
ciscoAtmIfCdLed

Finally, this nugget, from "CISCO-WIRELESS-EXP-MIB" :
"When the CISCO-LED-MIB.my becomes available and supports the functionality the LED group needs, the LED group will be migrated into that."

Apparently mention of a MIB that never came to be.

Answer 2

This is an older Cisco page that I wished was kept current. Has many of the Cisco products but not always the latest and greatest. http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

One thing to keep in mind that I haven't seen mention is you can go through the entire Cisco mib universe but if the mib you are wanting to use isn't installed in the IOS that the switch running you will only be spinning your wheels.

For example you mention the 3560 model. If you had 12.2.50 train of code this is the supported mibs. ftp://ftp.cisco.com/pub/mibs/supportlists/cat3560/cat3560-supportlist.htm

If you had 15.x code train then the mibs will be a different mix. You have to look up the release notes/data sheets for each code build if you are going to deep dive into off beat mibs. The standards based and Cisco generic mibs are generally always in the vast majority of the code trains.

Been there, done that with scripts trying to extract specific OID's to only later discover that the mib isn't in the switch. Really problematic for DHCP stats and environmental stats.

Also are you wanting the GUI to show blinking lights? snmp queries are snapshots in time depending on the OID queried. If your wanting to keep up with the constant state of the lights then you will be polling non stop which will drive the cpu to 100% and stay there. Not that hard to drive a 3560 cpu into the ground from personal experiences with snmp polling.

Just some things to keep in mind.

Good luck.

Answer 3

IF-MIB and CISCO-IF-EXTENSION-MIB (and OLD-CISCO-INTERFACE-MIB) will contain 99.999% of everything you can get via SNMP. In short, there's no OID to give you the LED state of the switch. However, you can retrieve numerous OIDs to figure it out.

(Fetch dashboard.shtml from one of your switches if you want to see how Cisco's Device Manager does it. You will not be impressed.)