SNMP, OIDs and SCOM don’t seem to a very exciting mix at a first glance. However, when combined in a smart manner, they extend your monitoring solution in an awesome way. This posting is about just that. It will describe at a high level how to go about it and high light some potential pitfalls.
This document provides an introduction to SNMP traps. It shows how SNMP traps are used and the role they play in the management of a data network.SNMP traps enable an agent to notify the management station of significant events by way of an unsolicited SNMP message.In this diagram, the setup on the left shows a network management system that polls information and gets a response.
In our first installment, we covered enough of the basic concepts and terms of SNMP to bring anyone unfamiliar with the technology up to speed on a few common SNMP concepts and terms. If any SNMP-specific terms mentioned here are unfamiliar to you as you read this post, don’t hesitate to refer back to.Part 1 –In this installment, we are going to look at how SNMP-enabled device discovery and availability monitoring work behind the scenes based on some low-level observations I made in the lab. While these are my unofficial findings, I did try to perform and capture the output each test multiple times to ensure accuracy. Specifically, we will discuss:. Discovery – How discovery functions and what precisely is being discovered.
Proxy Agent – Assigning a computer other than the RMS to perform probe-based monitoring functions. Availability Monitoring – How device availability monitoring works and the configuration required to make it fully functional.There are some differences in how Operations Manager (OpsMgr) or Essentials handle discovery and other aspects of SNMP monitoring, which we will only touch on today. I will go into a bit deeper into this process works in Essentials in a future installment. Probe-based versus Trap-based FunctionsI should begin by restating that in SNMP monitoring in OpsMgr and SCE, there are two types of SNMP functionality that will be mentioned repeatedly. There are probe-based functions in SNMP monitoring, in which an OpsMgr or SCE server (or an assigned proxy agent) issues an SNMP GET to retrieve data from the target device.
There are also trap-based functions, in which OpsMgr acts as an SNMP trap receiver, catching SNMP messages (called traps) which contains an SNMP OID / value pair. The information we are focusing on today entirely on probe-based SNMP functions, as you will see shortly. SNMP Device Discovery in OpsMgr and EssentialsSNMP network device discovery in Operations Manager is performed through the same Computer & Device Management Wizard used to discover Windows computers in your environment.
To discover network devices, we simply select “Network Devices” from the Computer & Device Type dropdown box as shown in figure 1. This selection changes the remaining screens in the wizard and the discovery actions performed.
Select the Management Server or Gateway you want to actually perform the device discovery, and click Next. Note that this is not necessarily the device that will perform probe-based monitoring after discovery, but keep reading and we’ll get to that.Figure 1. Selecting Network Device Discovery in the Computer & Device Management Wizard When you click next and move on, you are prompted to enter the range of IP addresses, Community String and SNMP version of your device (as shown in figure 2 below). IP Address Range – OpsMgr will attempt to discover up to 1000 devices in a single run as I understand it, though I would not recommend going anywhere near that figure, as best practice is deployment in manageable batches.
If you want to discover a single device, simply enter the same IP address in each box. Community String – You must know the READ community string of the device, which is like a password for read-only access to the device. SNMP Version – This is essentially the language of the device. If you speak French to a person who only speaks Spanish, you would not have much of a conversation. Same principle here.
![Scom Snmp Varbind Scom Snmp Varbind](/uploads/1/2/5/6/125614317/919734773.png)
Most devices that speak SNMPv1 do not speak SNMPv2c.Figure 2. Specifying SNMP Version, Community String and IP Address RangeFinding the SNMP version supported by your device – If you do not know the SNMP version supported by your device, you can call the device manufacturer, or simply use the tools and techniques described in this article: Once you have entered the information, click the Discover button and you get the little progress bar while you wait. This is where it gets interesting.
What happens behind the scenes in SNMP-based discovery:When you click discover, the Management Server or Gateway you select sends an SNMP GET to the target IP address (or range of addresses). The discovery packet for the device is a simple query for 5 object identifiers (OIDs) from a generic SNMP MIB (originally defined in ).
(Basically, all SNMP-capable devices understand these 5 OIDs and others contained in this generic MIB). Successful device discovery sequence consists of an SMNP get-request sent by the Management Server or Gateway and an SNMP get-response sent by the device, asshown in figure 3.Figure 3 – Successful SNMP device discovery sequence (in packet capture) And inside the SNMP get-response packet, we will see the values for each of these 5 OIDs returned by the device (the varbind), as shown in figure 4. This particular discovery was for a Cisco 2950 network switch.Figure 4 – Contents of the SNMP get-response Packet returned in Successful Device Discovery Selecting a Proxy AgentWhen discovery is complete, we are presented with a list of IP addresses of discovered devices we can select for monitoring, as shown in figure 5. We are also presented with the option to select a Proxy Agent. The Proxy Agent is the device that will perform the SNMP GETs in SNMP probe-based rules and monitors that apply to this device, including SNMP Up/Down device availability monitoring.
This allows us to distribute the load of network device monitoring across multiple systems, and utilize agent-managed computers at remote offices when circumstances allow. You can specify an MS, Gateway or any agent-managed computer as the Proxy Agent.
Click the Change button and select your desired Proxy Agent, and then click the button to finish up and close the wizard. At this point, the SNMP device has been entered into the Operational database with it’s respective proxy.Figure 5 – Discovered Devices and Proxy Agent Settings in the Computer & Device Management WizardAnd in Operations Manager, that looks to be all the discovery that takes place for an SNMP-enabled device. Quite simply, it only discovers the device. No interfaces, power supplies or advanced functions. So without additional work, we will simply know that an SNMP enabled device exists, and whether the device is up or down, which we’ll cover in detail momentarily. SNMP Device Discovery in Essentials 2007– Essentials 2007 contains additional network device monitoring functionality not included in Operations Manager 2007, designed for smaller environments. Essentials discovery does in fact include more detailed discovery, which includes network interfaces.
I’ll go into that process in detail in a separate post in the near future. Availability Monitoring of SNMP-enabled DevicesOnce the device has been discovered, selected for monitoring, and a proxy agent selected, any rules or monitors targeted to the SNMP Network Device object class will be run against the discovered device from the proxy agent. By default, there are no rules, and only 1 monitor targeted at this class, and that is the “Device Status Check” monitor shown in figure 6.Figure 6 – Device Status Check Monitor in for SNMP-enabled Devices in OpsMgr 2007 But what does this monitor do exactly? What happens behind the scenes in SNMP Device Availability Monitoring:Let’s look at what we see on the network.
With SNMP availability monitoring (as performed by the Device Status Check monitor), an SNMP GET is sent from the proxy agent to the managed device every 2 minutes. The query is sent for a single OID – 1.3.6.1.2.1.1.5.0 (SysName) as shown in figure 7.Figure 7 – SNMP GET Issued by the Device Status Check MonitorI also wanted to determine if the setting for “agent proxy” setting needed to be enabled for the Health Service on the computer designated as the proxy agent. To clarify, “agent proxy” is the setting that allows an agent to report data on behalf of another monitored object, while the “proxy agent” is the computer we specified as the node that would perform the SNMP probe-based monitoring on the target network device.Based on what I saw in packet captures in the lab, the answer is “no”. The agent proxy setting does not seem to matter. In fact, I even put the proxy agent into maintenance mode (computer, health service and health service watcher), and the proxy agent still performed the probe-based SNMP monitored for the SNMP device(s) to which it was assigned in discovery. See details of these observations in figure 8. Agent Proxy enabled on Proxy Agent – Proxy agent performs the probe (GET).
Agent Proxy disabled on Proxy Agent – Proxy agent performs the probe (GET). Agent Proxy disabled AND Proxy Agent in maintenance mode – Proxy agent still performs the probe (GET). Stopped Health Service of Proxy Agent – Probe-based monitoring is interruptedFigure 8 – Affect of Agent Proxy Setting on Proxy Agent Monitoring Behavior What does this mean from a security perspective? Well, since the OpsMgr administrator is explicitly discovering and identifying the SNMP-enabled device for which information will the proxy agent will probe and collect data, I think the behavior observed is the best option. Since the device targeted for monitoring was basically “manually approved” as part of the discovery process, there is no risk imposed by this behavior AND it makes configuring network device monitoring an easier task.
Additional Configuration in SNMP Device Availability MonitoringWhile the Device Status Check monitor is present and enabled by default, it is not completely configured to report an interruption in device availability. This is because while the monitor is present and enabled, the overridable parameter “GeneratesAlert” is set to false by default.
The result is the health state of the device is updated to critical in outage situation, but no alert is raised. The workaround for this is to set this parameter to true, as shown in figure 9.Figure 9 – “Generates Alert” Parameter of the Device Status Check Monitor for SNMP Network Devices With an appropriate Notification Subscription, only now do you have fully functional SNMP network device availability monitoring. Improving Upon Default Availability MonitoringWhat you will find with the alerts generated by device monitoring is that they are not very fancy. The alert description is empty and only the device IP address is mentioned. No host name or FQDN is returned, as shown in figure 10. However, there is an easy solution for this, thanks to Marius Sutara from the Operations Manager 2007 Product Team.Figure 10 – Default Alert Generated by the Device Status Check MonitorMarius wrote a custom version of the Device Status Check monitor that can be imported and used to produce an alert with device name and IP address in the description field.
You can read Marius post and download the sample MP by clicking.I think that answers all the objectives for this installment. In the next couple of installments on SNMP, we will drill down into this same information in Essentials and look further into the SNMP probe-based monitoring capabilities of Operations Manager and Essentials.