SCOM: Advanced SNMP Monitoring Part IV: Making the Cisco MP SP1 Compatible

As previously mentioned, the Cisco Management Pack that I have been describing in the past several posts is specific to OpsMgr R2, due to its reliance on the capability of the System.SnmpProbe’s function to return multiple items in an SNMP walk, which is a feature introduced in R2.   My intention was to design the management pack so that it could easily be made SP1 compatible by substituting the discovery methodology, but keeping the classes and monitoring objects intact.   I am still doing more testing to finalize the SP1 version, but in this post, I am going to introduce the discovery methods that I have implemented for SP1 compatibility.

In general, when dealing with SNMP objects stored in tables, options in SCOM 2007 SP1 are a bit limited.  If the table objects are static, rules could be configured targeting specific OID’s, but this is unlikely to be a common scenario.   Another option (and a quite good one) would be to segregate monitoring duties between SCOM (for servers and applications) and a task-specific SNMP monitoring tool like SolarWinds or JalaSoft for SNMP device monitoring.   But for the purposes of this management pack, the option I pursued involves wrapping an external SNMP provider in WSH scripts to perform the discovery.   I chose to use the WMI provider because of its easy use in VBscripts and object-oriented capabilities, but something like the Net-SNMP binaries could be called with ShellExec methods in a vbs script to accomplish the same goal.  

Before I get into the use of the WMI SNMP provider in this MP, there is some background information that should be discussed.  Firstly, when the WMI SNMP provider is installed, it includes support only for the RFC-1213 MIB.   In order to use the WMI SNMP provider for OID’s not in the RFC-1213 MIB, the MIB files must be converted to MOF files with smi2smir.exe and then imported with mofcomp.exe.    This can get a bit tricky, largely depending on how well constructed the vendor’s MIB is and the dependencies of the MIB.   Once these steps are completed, the WMI SNMP provider exposes SNMP objects as collections that can be accessed natively in VBscripts.   However, the WMI provider is not terribly scalable and when overloaded with requests, WMI will cease to function in a timely fashion.   I had done some testing with using the WMI SNMP provider for rules and monitors, but decided against this approach due to the ease with which the provider can be overloaded when monitoring a handful of objects with reasonably aggressive frequencies.   On the other hand, discoveries are not as time-sensitive as monitors/rules and don’t need to run as frequently, so by using the WMI SNMP provider for discoveries, and the System.SnmpProbe provider for monitors and rules, this hybrid approach should remain pretty scalable. 

Implementation Overview

Read more of this post

SCOM: Updates to the Cisco Management Pack

I have uploaded version 1.01.27 of the Cisco Management Pack.   This minor update includes a few fixes and some new features added in response to some helpful comments from readers who have tried this MP out.  The changes in this version are:

1. Group Population rules have been fixed so that they can be edited in the GUI
2. Performance data collection has been modified to not collect data when the interface is in a partially discovered state.  This should prevent duplication of performance counters for interfaces going forward.   Because the Interface discovery occurs in two parts: 1) discovering the interfaces and 2) discovering the interface properties, I added a property to the Interface class named: Discovered.  When the Interface discovery runs (which just discovers the index), the discovered property will be set to False.  Once the Interface Property discovery runs, this property will be set to True.   The performance collection rules have been modified to only collect data if this property is set to true. 
3. Index discovery can now be filtered with a RegEx expression for a device via an override (create the override on the Discover Cisco Interfaces discovery).   By default, the RegEx expression:  (.|..|…) will be used to discover interfaces, which will discover all interfaces with indexes with 1, 2, or 3 digits in length.  To filter by interface index, the expression can be modified to:  (1|2|3|10|15) where the numbers are the index values for the interfaces to be discovered, separated by pipe characters.   The override for this filter can be targeted at all Cisco devices, a group, or specific devices.
4. I have added a new property to the Interface class named:  “Speed – Override.”  This property allows for manually defining a speed value for the interface to be used in utilization calculations.  There are two scenarios where this is useful: 1) sometimes the value reported in the RFC-1213 ifTable for an interface’s speed isn’t accurate, and 2) if an Ethernet port is the last monitored hop before a lower bandwidth wide-area connection (i.e. the vendor equipment is not monitored), it can be useful to monitor the Ethernet port as if its speed were equivalent to the wide-area connection bandwidth.   For example, if a switch is the last monitored device before connecting to a vendor-managed MetroE connection with a maximum bandwidth of 500Mbit, monitoring utilization on the gigabit switch port will be more accurate if the speed were overridden to 500Mbit.  This property can be set with an override on the Discover Cisco Interface Properties object discovery, by setting the OverrideIFSpeed value to the desired speed, in bits per second.