I was actually looking for a MIB that can alert my NMS on ports that have gone err-disabled. If I was to look for MIBs that contain certain OID, how do I go about doing so through the pile of MIBs?
Regarding detecting if a port is error disable .... Syslog monitoring will detect this but if I am not mistaken isn't ifoperatus set to 5 (dormant)when a port goes error disable ?
As I was browsing the Cisco MIBs with my MIB Browser, I realized that I may not even need a Cisco MIB to monitor trunk link status. The standard ISO IF-MIB should be enough to do the job.
ifOperStatus will give you the ports up/down status, but it will not tell you if the port is trunking or not. For that you will need the objects in the vlanTrunkPortTable table I mentioned earlier.
You are right about that one. I noticed another thing with the MIB Browser I'm using. It's WS_Ping ProPack, and it is not able to browse beyond the ISO MIBs and into Cisco's proprietary MIBs. Does anyone have any suggestion on any good free MIB Browser/Walker?
I use net-snmp's command line tools (http://net-snmp.sourceforge.net). They're not graphical, but they are feature-complete, and work with v1, v2c, and v3.
Will the Cisco-VTP-MIB inform the NMS if a port goes into err-disable mode? If not, what MIBS would?
There is no trap that alerts one when a port goes into err-disabled, but you can poll the portAdditionalOperStatus object from the CISCO-STACK-MIB on certain switches to see when this happens.
I just tried to get the values of the portAdditionalOperStatus from one of my 3750 switch stacks using Net-SNMP. The reply I received was:
SNMPv2-SMI::enterprises.18.104.22.168.1.1.23 = No Such Object available on this agent at this OID
For the 3750s, there is no object that will tell you this. Besides portAdditionalOperStatus, there is cieIfOperStatusCause from the CISCO-IF-EXTENSION-MIB which can give error-disable status, but the version of that MIB that contains this object is not supported by the 3750s.
I resorted to using ifOperStatus instead. The active SNMP monitor was able to detect that the err-disabled trunk was not up due to the NMS receiving a value of "2"
I, then, did a shut/no shut on the trunk link that was err-disabled which brought the trunk link up to a trunking state. But I still got a value of "2" when I queried the 3750 for the ifOperStatus of that particular trunk link.
Since no one mentioned it yet, let's not forget syslog messages and clog traps as another possible solution mechanism for this.
1. Syslog annunciates err-disable events
under I believe 3 or 4 different syslog
messages. err-disable is usually contained
in the syslog msg field.
2. syslog messages can be received as syslog traps
3. If you have NNM for example, you just need to setup ECS or an action on trap script on syslog traps to check clog traps where applicable messages contains *err-disable*
4. or you could setup DFM to check applicable syslog messages for *err-disable* and trap or email on them too.
5. of if you have Nagios or CIC again
just parse applicable syslog traps or
syslog messages for *err-disable*.
Yes, syslog is a real possibility. However, DFM does not do anything with syslog messages. RME can process the syslog messages, and turn them into emails.
I did find a new MIB that will work on the 3750 provided you are running 12.2(37)SE or later. The MIB is the CISCO-ERR-DISABLE-MIB, and the object is cErrDisableIfStatusTable. Only ports that are in an err-disable status will appear in this table.
The 2 above solutions would are good solutions. There is, however, one lingering question, and that is even though I did a shut/no shut on a trunk link to bring it from its err-disable state to the trunk state, the results of an snmp "get" on the object and variable id is still down.
ifOperStatus.11102 = INTEGER: down(2)
I expected the value to be up(1), but it remained down(2) even after I brought the interface back up to a trunk state from its previous err-disable state. What reason exists for this?
My mistake, I looked at the wrong variable ID.
The ifOperStatus of ports did change when I brought up the trunk link from its previously disabled state.