Introducing the xSNMP Management Pack Suite


Over the past several weeks, I’ve been hard at work on some new SNMP management packs for Operations Manager 2007 R2, to replace the Cisco SNMP MP and extend similar functionality to a wide range of SNMP-enabled devices.   In the next few posts, I hope to describe some of the design and development considerations related to these Management Packs, which I am calling the xSNMP Management Pack Suite.   For this post, I hope to give a basic overview of the development effort and resulting management packs.

As I was working on some feature enhancements to the Cisco SNMP Management Pack, and following some really great discussions with others on potential improvements,  I concluded that a more efficient and effective design could be realized by aligning the management pack structure along the lines of the SNMP standard itself.   To expound on this point, much of the monitoring in the Cisco MP is not specific to Cisco devices, but rather, mostly common to all SNMP devices.   The SNMP standard defines a hierarchical set of standard MIBs, and a hierarchical implementation of vendor-specific MIBS, with consideration to the elimination of  redundancy.   I tried to loosely adapt this model in the xSNMP MP architecture.   The first of the MP’s, and the one that all of the others depend on, is the root xSNMP Management Pack.   This management pack has a few functions:

  1. It performs the base discovery of SNMP devices (the discovery is targeted to the  SNMP Network Device class)
  2. It implements monitoring of the SNMP v1/v2 objects for discovered devices and interfaces
  3.  It provides a set of standardized and reusable data sources for use in dependent management packs

From there, the remaining management packs implement vendor-specific monitoring.   Devices and/or interfaces are discovered for the vendor-specific management packs as derived objects from the xSNMP MP, and most of the discoveries, monitors, and rules utilize the common data sources from the xSNMP MP, which makes the initial and ongoing development for vendor-specific MP’s much more efficient.

Controlling Interface Monitoring

One of the topics frequently commented on with the Cisco SNMP Management Pack, and a subject of much deliberation, was that of selecting network interfaces for monitoring.   Even determining the optimal default interface monitoring behavior (disabled vs. enabled) isn’t a terribly easy decision.  For example, a core network switch in a datacenter may require that nearly all interfaces are monitored, while a user distribution switch may just require some uplink ports to be monitored.   In the end, I decided on an approach that seems to work quite well.   In the xSNMP Management Pack, all interface monitoring is disabled by default.   A second, unsealed management pack, is also provided and includes groups to control interface monitoring (e.g. Fully Monitored, Not Monitored, Status Only Monitored).  Overrides are pre-configured in this MP to enable/disable the appropriate interface rules and monitors for these groups.   So, to enable interface monitoring for all Ethernet interfaces, a dynamic group membership rule can be configured to include objects based with interface type 6, or if critical interfaces are consistently labeled on switches with an Alias, the Interface Alias can be used in rules for group population.  

Organizing Hosted Objects

For each of the management packs,  I tried to take a standardized approach for hierarchical organization of hosted objects and their relationships.   This organization was facilitated primarily through the use of arbitrary classes to contain child objects.   So, rather than discover all interfaces of a device with a single hosting relationship to the parent, an intermediary logical class (named “Interfaces”) is discovered with parent and child hosting relationships.   This approach has three primary benefits: 1) the graphical Diagram View is easier to navigate, 2) the object hierarchy is more neatly organized for devices that may be monitored by multiple MP’s (e.g. a server monitored by three MP’s for SNMP hardware monitoring, O/S monitoring, and application monitoring), and 3) the organization of hosted objects is consistent, even for devices with multiple entities exposed through a single SNMP agent. 


With loads of invaluable help from some volunteer beta testers, a great deal of time has been spent testing and investigating performance and scalability for these management packs.  While I will save many of these details for a later post, I can offer a few comments on the topic.   In all but the smallest SNMP-monitoring environments, it’s highly advisable to configure SNMP devices to be monitored by a node other than the RMS.  For larger environments, one or more dedicated Management Servers or Agent Proxies (Operations Manager agents configured to proxy requests for SNMP devices) are preferred for optimal performance.    From our testing with these Management Packs, a dedicated agent proxy can be expected to effectively monitor between 1500-3500 objects, depending on the number of monitors/rules, the intervals configured, and the processing power of the agent proxy.   By object, I am referring to any discovered object that is monitored by SNMP modules, such as devices, interfaces, fans, file systems, power supplies, etc.   So, monitoring a switch infrastructure with 4000-6000 monitored network interfaces should be doable with two dedicated agent proxy systems.  

I intend to write in greater detail about these topics in the coming weeks, and hope to post the first public beta version of these management packs soon.


About Kristopher Bash
Kris is a Senior Program Manager at Microsoft, working on UNIX and Linux management features in Microsoft System Center. Prior to joining Microsoft, Kris worked in systems management, server administration, and IT operations for nearly 15 years.

15 Responses to Introducing the xSNMP Management Pack Suite

  1. matsw says:

    sounds great.. Looking forward to the beta..!!!

  2. Owen says:


    Great work!!! I was actually in the process of changing the Cisco SNMP MP to discover and monitor Dell PowerConnect switches.

    The direction that you are taking the MPs sounds great.

    Would you be open to structuring the effort as an open source project so that others can contirbute?


    • Kristopher Bash says:

      Thanks for the comment. As for open sourcing this, I can say the following. Each version (beta and production) will be released under the GNU GPL license, with source code (in the form of unsealed MP’s) provided in each release. I also have plans to create documentation on using the reusable datasources in the core MP to standardize development of additional MP’s.

      So, at any point, anybody will be able to download, extend, modify the MP’s to their requirements. I would like to see the MP’s go through a good public beta period and some code maturation before formalizing as a community-type project. My reasoning for this is that if changes are required in the core MP, they can easily affect compatibility with dependent MP’s. I’d like to try to get to a point of pretty frozen code on the core MP before encouraging community development. I also need to work out a plan to manage the community development process.

      I’m always open to suggestions though.

  3. idflyfish says:

    Great work Kris. I am really looking forward to this.

  4. Gary Hay says:

    Is there any ETA on when the new MP will be available to the wider community to test?

  5. Rene says:

    Hi Kris
    I am also very interestet at a beta Version

    KInd regards


  6. I’m really looking forward to your public beta. I’m currently using SolarWinds to monitor our network and unix elements and would really like to end up at one solution.

    Public Beta Whooo Hooo !!!!

  7. John Bradshaw says:

    This is a GIANT leap forward.
    Thankyou Kris,

    John Bradshaw

  8. Sergey says:

    “The very bestest” russian-like speaking manner.

  9. Richard says:

    Some of the best work I have seen, excellent job!

  10. rao says:

    Man your crazy! Dude, and that I mean in the “GEEAKY” way. Awsome, great job man. Keep up the good work. Some of the best things I have stumbled upon during my IT fly 🙂

  11. Mohamad Damati says:

    Hi Kris,

    great management pack, but i have some problems with Brocade Management Pack i would like to share.

    after adding AS400 devices, some ports are not discovered. and i am not able to monitor. also, it did not discover the Virtual Cards, it is only discovering hardware.

    please advise

  12. Evgeney says:

    Thank you for this MP! Great work!
    But I have one problems: I not understand how I can monitor “tunnel” interfaces on Cisco routers. People, please help me setup MP for monitor tunnel interface.

  13. Hi. Is it possible to get this MP working in OM 2012?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: