SCOM: SP1 Edition of the Cisco Management Pack , v1.0.2.6
September 26, 2009 19 Comments
I have completed the first version of the Cisco Management Pack for SP1 compatibility. The monitoring in the management pack is identical to the R2 version of the MP, described most recently here. Due to the dependence on the WMI SNMP provider for object discovery, there are inevitably some scalability limitations intrinsic to the SP1 edition of this MP, but I haven’t done enough full-scale testing to ascertain those limitations as of yet. Additionally, deployment of this management pack requires some additional steps. These steps are detailed below (taken from the MP documentation):
Prerequisites
This management pack utilizes the WMI SNMP provider to perform discovery of SNMP objects. In order to use this management pack, the following steps must be completed on each server that will function as a proxy agent for SNMP-monitored Cisco devices.
Install the SNMP protocol and WMI SNMP provider
- To install these components, access Add/Remove Programs in the Control Panel, and select Add/Remove Windows Components. Under Management and Monitoring select: Simple Network Management Protocol and WMI SNMP Provider
The following MIBs must be exported to MOF files with smi2smir.exe and imported with MOFComp.exe: CISCO-ENVMON-MIB and CISCO-MEMORY-POOL-MIB.
- The MIBs and a batch file to perform these steps can be found in the /Setup directory included with this MP distribution. Run the RegCiscoMibs.cmd file and check the output log: register.log to confirm that the mibs were successfully compiled and imported.
Recommended Proxy Agent Configuration
If WMI receives too many requests in a short time, it may suspend processing of requests for a period of time. This can impact the ability of this management pack to discover Cisco SNMP objects in a timely fashion (WMI SNMP is only used by this MP for discovery, and not object monitoring). In order to minimize the chances of this situation occurring, the object discoveries in this MP should not be scheduled too aggressively. Additionally, it is recommended that if a large number of Cisco SNMP devices are to be monitored, they should be distributed across multiple proxy agents for load-balancing of the WMI SNMP requests.
It is highly recommended that all agents that will function as proxy agents for SNMP devices have the Windows Script Host version 5.7 installed. Version 5.7 is far more efficient than previous versions and reduces the resource utilization by the cscript.exe process dramatically.
It is also highly recommended that all agents that will function as proxy agents for SNMP devices have the hotfix: KB96163 applied. This hotfix resolves instability with SNMP monitoring in Operations Manager 2007 SP1. http://support.microsoft.com/default.aspx/kb/961363
I’m interested to hear how this SP1 edition of the Cisco Management Pack functions in different environments, so any feedback is most certainl welcome. I will continue to post updates to this site so be sure to check back regularly. For more information about the scripts utilized in discoveries in this edition of the MP, this post should sum it up.
About Kristopher Bash
Operating-Quadrant 
Thanks Krish.
Hi Krish.
First thanks for this great management pack. I was able to get it working on a couple of our devices and it looks great.
One of the issues that i have is we have some interfaces that are multi gig port-channel’s and when i look at the Pct in / out Utilization graphs they show a negative % utilization. So it looks like the 32 bit counters are rolling over. Is it possible to detect the speed of the interface and then check if the 32 bit counters or 64 bit counters should be used.
As i don’t think this will handle a 10 Gig Port channel 🙂
Contact me off list and i can send you screen shots.
Hi Kris
Awesome mp, detected all of the Cisco devices I have added so far. I guess I really need to update to R2 to get the full benefit of this mp.
would you reccomend upgrading first before rolling this MP out?
thanks again
Thanks! Well, there are a lot of benefits to R2 all around. I’m working on a new suite of R2-only SNMP management packs that will be more robust, scalable, and extensible (in my opinion at least), and I probably won’t be doing much more development on SP1 MP’s for SNMP monitoring. In my opinion, I would check back here in a week or so (hopefully) to see what the improvements in the new version will be before making a decision about deploying pre or post upgrade. I may be very biased, but I think the new R2-only version will be worth a look.
Thanks for your quick response kris, and I look forward to seeing the new mp.
Hi,
I have imported the MP in our SCOM 2007.
It is a great management pack and it works very well with some of our devices.
But I saw, that SNMP v3 is not supported..
Is this possible with the next update?
Because the most cisco devices we have are with SNMP v3..
Thanks. The lack of support of SNMP v3 is a limitation of OpsMgr. There’s not really anything that can be done at this point within the context of a Management Pack to work around this, short of using all script probes that engage a third-party SNMP utility.
OK, thanks for the quick answer!
Is this limitation also in OpsMgr 2007 R2?
Yes, R2 only supports v1 and v2 SNM currently
First off great work. I’m looking to reuse some of the logic within this MP to monitor an Isilon cluster. This has lead me to ask the following… I’m stuck in the 2007 SP1 world for a while so I cannot move to your NET-SNMP MP so I have to make due with the limitations within SP1. Given your work with CentOS, have you ran into a SNMP Proxy requirement? The Isilon cluster is FreeBSD based and I only have 1 network interface into the cluster. This proves to be an issue when attempting to discover and probe the cluster. To proxy to the other nodes within the cluster you can issue a community name of (clustercommunityname_node_#) with the OID query for return results of the “inaccessible” node. I run into a issue on how to pass said community name within discovery. I can query a OID to find the number of nodes or configured nodes within the cluster (returns node count or node numbers 1, 2, 3, etc), it’s passing that information into a community name string. Any thoughts?
Seems to be an interesting challenge. So, I assume that the SNMP agent is using com2sec directives to proxy via community strings? The only experience I have with proxying SNMP with Net-SNMP is some basic configuration with proxying SNMP sub-agents listening on a different port (e.g. the SunFire agent). You could proxy to localhost with a different community string and mount the SNMP objects for each subagent under a different OID path, but that would get pretty complex from an MP development perspective. How many subagents/cluster nodes are involved? A dirty way to do it would be to assign multiple IP’s to the interface, and discover them one at a time with a unique community string. Would something like that be viable?
I’ll let you know how they are going about passing SNMP information around as soon as Isilon escalation support returns my call. I wish to avoid any significant changes to the internal workings of the cluster since I do not know the how they go about replicating configuration information between the nodes and a code upgrade could remove all my customization so mounting OID strings to the various sub-agents isn’t a practical solution at this time.
There is an 8 node production cluster with a 3 node lab. Multiple IP addresses… I toyed with that idea and set that as plan C. Plan A is just limited discovery with individually created monitors for each node, etc (almost complete). Plan B was to reuse some of the logic, bind it into classes for discovery and monitor population. I still learning that bit, trying to translate MRTG, RRD, Cacti, Nagios, MOM, Etc into SCOM has been a bit of a leap. Any good reference url’s for further learning?
The more I think about it, it does seem that the easiest way would be Plan C but that brings another issue I was going to address later but might as well toss it on the table as well.. As noted above I have an open issue with Isilon on SNMP trap routing within the cluster. Seems they are attempting to send the trap out a floating “master” SNMP agent that could be on any node using any IP address bound to the node and not routing said packet over the infiniband bus to the attached node with access to the management subnet. Once that issue is resolved I’m going to have to address the data within the packet. They are using an internally created SNMP community string to send the packet (isialert@FQDN-(Node #) example – isialert@cluster-1.domain.int) and the only way to determine what node is having an issue is to look in the pack itself for yet another string. This means I may need to create a “master” SCOM network device to accept all the traps, (ie 8 monitors, 1 for each of the community names that the trap could be coming from per monitored trap def.) do a expression search within the data of the packet to determine the severity of the alert, do another expression search to determine the node having the issue and force all the traps to come from only 1 IP address from the Isilon.
Out of curiousity, I’d be interested in hearing what you determine after talking to the vendor support.
I’ll think about this over the next day or two in case something comes to mind, but OpsMgr is certainly oriented towards a one to one relationship between IP Address/Comm. string combinations and SNMP agents. As the IP address is the key property of an OpsMgr SNMP Network device, servicing multiple “agents” with a single IP address (with polls or traps) is going to be a challenge. Does the device support Syslog? Perhaps that would be an easier approach if it can be an alternative to SNMP traps (at least by eliminating the community string and including a severity in every message).
As for OpsMgr SNMP resources, there’s a bit of a scarcity of resources, in my opinion. The blogs listed on the blogroll of my site are my typical go to resources for all things OpsMgr, along with the online Authoring Guide, and social.technet.microsoft.com forums. To be honest, in my experience at least, a lot of working with SNMP in OpsMgr sometimes comes down to trial and error. In that regard, I’ve probably tried more than my share of SNMP monitoring approaches with OpsMgr and certainly seen enough errors resulting from those trials, so if you have specific questions about the authoring, I’d be glad to try to assist.
The official documentation is a bit sparse on the topic, but I get the impression that there is a lot of effort going into improving the SNMP capabilities (and documentation of such) of OpsMgr. I spent a lot of time with NetView and more recently have worked with SolarWinds quite a bit. I really appreciate the simplicity and effectiveness of SolarWinds, but the object-oriented architecture of OpsMgr, dynamic discovery capabilities, and incredible flexibility causes me to be a big advocate of using it for SNMP monitoring, particularly in R2 – even if it has a ways to go in the scalability area.
Here’s the update to my device… Seems that they are using com2sec with the built in proxy of snmpd. Look at the Net-SNMP wiki for more details.
So here’s my question: I can poll the device during discovery to find out how many nodes the cluster has, is there a way to use this data and pass it along to a script as a var?
$MPElement[Name=”IsilonSNMP.Class.IsilonCluster”]/configurednodes$
Any attempt gives me an invalid namespace error.
Ignore my last… I figured it out. Used an XML editor over the authoring console.
As I already mentioned regarding the R2 version: Great work!
Can you add the ifalias to it like you did for that one?
It seems to be missing from the SP1 version.
Hi Kristopher!
Thanks for the management pack! It’s great!
But I have a question: why only 45 items (Interfaces) can be discovered in a single discovery workflow? Why exactly 45?
I’m not sure why the limitation is there, it is something that I have discovered working with script discoveries in both the cscript and powershell (r2) script discovery modules. From my testing, it was more like 46 objects, but I rounded it down to 45. Wish I had a better explanation.
Am I supposed to be seeing this in the mof creation log? CISCO-ENVMON.MOF does not contain #PRAGMA AUTORECOVER.
If the WMI repository is rebuilt in the future, the contents of this MOF file will not be included in the new WMI repository.
To include this MOF file when the WMI Repository is automatically reconstructed, place the #PRAGMA AUTORECOVER statement on the first line of the MOF file.
Done!