What is SNMP?
SNMP ("Simple Network Management Protocol") is nothing more than a standard language that computers use to control each other and report important information. Its advantage today is that a very large number of devices support it, enabling them to work together.
How long has it been around?
SNMP was created in 1988. At the time, it was simply a short-term way to manage computers on the Internet and in private networks. It replaced the earlier "SGMP" ("G" stood for for "Gateway").
Now, of course, SNMP is just about everywhere. You'll find it in corporate office buildings, remote industrial telecom sites, and even home offices.
|SNMP is based on the manager/agent model of a network management architecture.|
How do the pieces fit together?
SNMP architecture is, in principal, very similar to the internet technology you're using right now to read this web page. Your computer (or tablet, or smartphone) sends a standardized request to our web server. So do other computers around the world. Our web server responds by sending each of you the information you want. There are many computers in various locations, and our single server sends web pages to all of them.
In SNMP, "agents" are remote devices out in the network. What exacty the agents are depend on the kind of network you have (ex. Are you a small office, a national telephone company, or a power utility?). They can be printers, managed switches, alarm remotes, generators, servers, and lots of other things. These agents report problems and receive commands from a central "manager". This is known, oddly enough, as the "manager-agent model".
Can managers and agents instantly communicate with each other? Do I need to set something up first?
When you add a new agent to your network, there are a few simple setup steps:
Step 2: Compile the agent's MIB into your manager If you've ever connected a printer or a digital camera to your computer, you know about installing drivers. A "driver" is a file that tells you computer how to communicate with the other device. In SNMP, although the basic protocol is always the same, every agent has different things that it can report. Generators report fuel levels, for example, while printers report toner and paper levels. A "MIB" (Management Information Base) is simply a file that tells your manager what information this particular agent can report and what commands it can accept. You'll receive a MIB from your agent manufacturer, and you load ("compile") it into your manager as part of setting up the new agent.
How are SNMP messages structured?
Each element in the SNMP world is addressed with an Object Identifier (OID). These are long strings of dot-separated numbers. They look something like extra-long IP addresses (ex. "126.96.36.199.4.1.26188.8.131.52"). And just like an IP address, each additional number adds detail. The first several numbers are always the same for SNMP devices. In the example above, "184.108.40.206.4.1..." means only "enterprise SNMP equipment". That's going to be the same for every agent you use. The last few numbers mean "DPS Telecom" (the manufacturer of this agent), "Alarm Monitoring Equipment", "RTU", and (finally) "Alarm Point 2". This OID represents a single discrete alarm input on a remote monitoring device. If your manager received an SNMP message with that OID, it would alert you about an equipment failure (or whatever you decided to wire into Alarm Point 2). Other OIDs can represent a generator turning on, a door opening, an empty diesel tank, or just about anything else you can imagine.
SNMP uses five basic messages (TRAP, GET, GET-NEXT, GET-RESPONSE, and SET) to communicate between the SNMP manager and the SNMP agent.
The vast majority of messages are traps (it's a weird name, but just think "alert message" whenever you see "trap"). These are messages sent to the manager by an agent when something needs to be reported. An industrial refrigerator, for example, might send a trap to the manager when it loses power or when temperatures rise too high. A RTU like a NetGuardian sends traps when the equipment and sensors it's monitoring report a problem. Traps are the lifeblood of SNMP, giving your manager the data required to give you a "big picture" understanding of your network-wide status.
But managers don't have to sit around waiting for agents to send a message. Sometimes, they prefer to ask for data proactively. This enables managers to build reports by having all agents send a status report at regular intervals. It also ensures that devices are still active, because you don't otherwise know if a quiet device is offline or simply doesn't have anything to report.
A manager asks an agent for data with a "get" message, the agent will send back a "get-response". The manager might only need that one piece of data, or it can then send a "get-next" message (and then another, and then another) to request a full status update.
Finally, an SNMP manager sometimes has to tell an agent to take action. Some agents have control relay outputs that can be toggled. Others have beacon lights, backup systems, thermostats, and other things that can be changed with a "set" command. A set command targets a specific OID and specifies a desired value. Translated to plain English, a set message might read something like "Set thermostat to 21 degrees Celsius" or "Activate backup generator".
|The branch of the MIB object identifier tree.|
What are some SNMP best practices?
When an agent sends a trap message, it can include OID and a data payload (called "variable bindings") to clarify the event. Quality agents like DPS NetGuardian RTUs send a comprehensive set of plain-English variable bindings within each trap to maintain traditional telemetry event visibility. Well-designed SNMP managers can use the bindings to correlate and manage the events. Managers will also generally display the readable labels to facilitate user understanding and decisionmaking.
Is SNMP byte-oriented or packet-oriented? What's the difference?
This article in our series on the Simple Network Management Protocol (SNMP) examines the communication between managers and agents. Basic serial telemetry protocols, like TBOS, are byte-oriented (a single byte is exchanged to communicate). Expanded serial telemetry protocols, like TABS, are packet-oriented with packets of bytes exchanged to communicate. The packets contain header, data and checksum bytes. This offers vastly more detail without requiring a companion database, but bandwidth requirements are obviously many times higher for packet-oriented protocols. As time marches on, however, bandwidth availability continues to increase rapidly.
SNMP is packet-oriented with the following SNMP v1 packets (Protocol Data Units or PDUs) used to communicate:
The manager sends a Get or GetNext to read a variable or variables and the agent's response contains the requested information if managed. The manager sends a Set to change a variable or variables and the agent's response confirms the change if allowed. The agent sends a Trap when a specific event occurs.
The image below shows the packet formats. Each variable binding contains an identifier, a type and a value (if a Set or response). The agent checks each identifier against its MIB to determine whether the object is managed and changeable (if processing a Set). The manager uses its MIB to display the readable name of the variable and sometimes interpret its value.
|SNMP Packet Formats|
Do you have any specific SNMP examples I can review?
Absolutely. Here are two:
As a remote-monitoring-equipment manufacturer, SNMP isn't the only protocol we work with (we have to support lots of legacy and proprietary protocols if that's what our clients need), but it is certainly the most common.
In our environment, SNMP RTUs are a great example of SNMP agents. These are remote boxes that sit out at remote, unmanned locations and monitor the equipment and conditions there. One NetGuardian 832A, for example, might be monitoring temperature sensors, humidity sensors, doors, motion, water leakage, fuel levels, and power voltages using external sensors. It could also be tracking contact-closure alarms from various equipment like generators, rectifiers, switches, SONET/optical ring gear, UPS batteries, and other important equipment.
Any deviation from ideal conditions would, in this example, trigger an SNMP trap from the NetGuardian 832A. The beauty of an open protocol like SNMP is that the trap could be directed at any standard SNMP manager from any manufacturer (you could also use the DPS Telecom T/Mon manager, of course). Your SNMP manager could direct a response from the NetGuardian, such as turning on a backup generator to handle a commercial power failure.
Another great example is a power distribution unit (PDU). These are more focused on remote control than remote monitoring. They're basically industrial grade power strips with the ability to toggle power on/off to individual devices. This provides a last-resort remote-reboot capability if you have a server get stuck or something similar go wrong. Some devices just need to be power cycled.
An SNMP-capable PDU will toggle outputs in response to an SNMP set command from your SNMP manager. This type of device brings remote power control under your SNMP monitoring umbrella. That's significant, because it's silly to have one system for remote monitoring and a completely separate system for remote control. A large SNMP infrastructure in your network allows you to see what's happening AND react from your SNMP management interface.
The image below shows the SNMP packet formats. Each variable binding contains an identifier, a type and a value (if a Set or response). The agent checks each identifier against its MIB to determine whether the object is managed and changeable (if processing a Set). The manager uses its MIB to display the readable name of the variable and sometimes interpret its value.
Now that we've look at the structure of SNMP messages, we need to focus on the layered communication model used to exchange information. SNMP messages aren't sent alone. They're wrapped in UDP ("User Datagram Protocol"), which itself is wrapped in IP ("Internet Protocol"). This "wrapping" - which is used in many more contexts than just SNMP - is generally called "layers" (the original model was developed by the US DoD).
Understanding this layered model makes it easier to troubleshoot communication problems. When there is a problem, you can simply trace it down...
SNMP Resides on Application Layer
SNMP resides in what is called the Application layer, UDP resides in the Transport layer and IP resides in the Internet layer (somewhat obvious). The fourth layer is the Network Interface layer where the assembled packet is actually put on some kind of physical transport media (i.e., twisted pair copper, RG58 co-axial or fiber). These layers can seem a bit confusing, but they will help you talk about one part at a time when you're building a network of any kind.
To illustrate the function of this layered model, let's look at a single SNMP GET request from the agent's perspective. The manager wants to know what the Agent's System Name is and prepares a GET message for the appropriate OID. It then passes the message to the UDP layer. The UDP layer adds a data block that identifies virtual ports to be used. The packet thus formed is then passed to the IP layer. Here a data block containing the IP address of the manager and the agent is added. Then, the entire assembled packet gets passed to the Network Interface layer. The Network Interface layed places the packet on the media for transport.
Agents Pull SNMP Traps from the Network Interface Layer
After working its way through the network, the packet finally arrives at the SNMP agent. Here, it passes through the same four layers in exactly the opposite order as it did at the SNMP manager. The package that was "wrapped up" by the agent is now being "unwrapped by the manager after delivery. If the listening application is the SNMP agent, the GET request is processed as we have discussed in previous articles. The agent response then follows the identical path in reverse to reach the manager.
Understanding this layered model of SNMP communications makes it easier to troubleshoot network problems. When there is a problem, you can simply trace it down, out one end, into, and up the other. LAN/WAN link and activity status indicators (blinking LEDs) gives you clues about the Network Interface layer. ICMP Pings provide some information regarding the proper functioning of the IP layer. SNMP processing indicators (in analysis software) tell you about the UDP layer and the functioning of the Application layer. You can verify each step independently until all steps are working correctly for end-to-end communication.
SNMP is a standard protocol that has wide acceptance in the industry and is flexible enough to describe almost anything. Because of these advantages, many network managers have come to believe that it should be used for all network monitoring applications.
Not All SNMP Managers Can Provide Network Visbility and Control
SNMP certainly has its place in an effective telecom network management solution, but this doesn't mean that any off-the-shelf manager can provide adequate visibility and control of your network.
Off-The-Shelf Solutions Cannot Meet Real-Word Needs
The typical off-the-shelf SNMP manager is not designed for displaying and processing telemetry data for effective network monitoring, especially for the kind of real-world monitoring tasks network managers most need performed. These capabilities can be added to a manager, but it usually requires substantial custom software development.
More real-world SNMP examples:
One DPS client named Jim called in earlier this year to ask about a more permanent solution for remote monitoring. At the time, he had some RTU equipment and an SNMP manager, but it was "held together by shoestrings" and he didn't really see it functioning long-term. He called DPS to discuss equipment that would turn older contact closure alarms into SNMP. We asked some follow-up questions, and eventually settled on a good course of action: a fleet of NetGuardian RTUs and a T/Mon manager. This project has now gone in for budget approval by his management team.
Another client, as Phase 1 of their project, needed SNMP Get collection and multi-analog "widget" display (7 per screen) with the capability of accessing another "widget group" by clicking an icon. The solution here was to use T/Mon's Web 3.0 interface and T/GFX software as the sysmtem for accessing other windows where alarms and analog sensor measurements would be listed. Each alarm/analog would have right-click menu option providing access to other windows to which this item is assigned. Phase 2 would add batch-processing capability via Linux shell scripts.
This is an excellent example of perfect-fit customization. This client wanted specialized functionality. With in-house engineers, we were able to help, but it's not as if we'd make the client wait for a complete design from scratch. We already had software that could be tweaked to match this client's requirements.
Relying on off-the-shelf systems (no matter the protocol) for mission-critical telemetry is a major mistake. If you're switching from traditional telemetry or integrating other monitoring with an SNMP-based system, an off-the-shelf manager will not provide the detailed alarm data you expect. Before you commit to a monitoring solution, you need to make sure it supports essential network alarm monitoring functions.
There are seven common mistakes network managers typically make when integrating SNMP and other monitoring. Your implementation will be successfully only if you can avoid them.
It is true that many, but not all, of these functions can be added to standard managers, but implementing network alarm monitoring in a basic SNMP manager usually involves a substantial amount of custom software module development. Even when pre-built software modules are available, they usually require custom tweaking to perform exactly as you want them to.
The need for extensive customization eliminates the advantage of using a simple open standard, and it is difficult to justify significant development costs after purchasing an already-expensive manager. Why take the time, trouble, and expense to recreate capabilities that are already present in a high-quality, SNMP-capable network alarm management system?
Relying on an SNMP manager for critical network monitoring just doesn't take into account the tons of legacy and non-SNMP equipment that is functioning perfectly fine out in networks all over the world. The role of an SNMP manager is best used for inventorying network devices and drilling down into equipment details after your network monitoring system notifies you of a problem.
SNMP can be an effective tool, but it's only one item in your network alarm monitoring toolkit, and it can be used more effectively when it is part of a total network monitoring solution.
If you are looking to avoid these 7 mistakes, then the T/Mon network alarm monitoring system is for you. It is specifically designed to avoid them. Network managers who rely on T/Mon for their network alarm monitoring, notification, and control comment, "Looking at one map and knowing it represents every piece of equipment you're monitoring in the field… that's pretty good peace of mind."See the T/Mon network alarm monitoring system...
Before you make a decision about your monitoring, there's a lot more you need to know. There are dangers you want to avoid - and there are also opportunities to improve your remote site maintenance that you don't want to miss.DPS Telecom Guarantees Your Success - or Your Money Back
When you're choosing a network monitoring vendor, don't take chances. Be skeptical. Ask the hard questions. Above all, look for experience. Don't take a sales rep's word that his company can do custom development. Ask how many systems they've worked with, how many protocols they can integrate with DNP3, and check for client testimonials. DPS Telecom has created hundreds of successful monitoring implementations for telecoms, utilities, and transportation companies. (Check out http://www.dpstelecom.com/dpsnews/success_stories for some examples.) DPS Telecom monitoring solutions are proven performers under real-world conditions. You're never taking any risk when you work with DPS Telecom. Your SNMP monitoring solution is backed by a 30-day, no-risk, money-back guarantee. Test your DPS monitoring solution at your site for 30 days. If you're dissatisfied for any reason, just send it back for a full refund.
Get the information you need. Send an e-mail to firstname.lastname@example.org for "A Practical, Step-by-Step Guide" on how to implement SNMP monitoring in your network. You can also call us today at 1-800-622-3314 to schedule your free Web demo of SNMP monitoring solutions, or register on the Web at www.dpstelecom.com/tmon-webdemo.