What is SNMP? Our Definition of the Protocol and its Functions

SNMP is, like most strings of capitalized letters in IT, an acronym describing a protocol with a very self-explanatory name meaning Simple Network Management protocol.

“Simple Network Management Protocol” is just that – a communications protocol through which an admin, via manager systems and authorized agents, can monitor and even manipulate some aspects of a networks configuration and traffic.

It originated all the way back in 1988-1990, depending on when you count it as being truly “included” and “standardized” in general protocol. Many different programs and tools, and even hardware devices specifically built for management, revolve heavily around the use of SNMP. The irony of sorts with SNMP is that while the idea and protocol itself are straightforward, the setup can get a bit complex.

Further, it requires SNMP compatibility on any devices to be monitored and managed, or at least an agent configured to middle-man the SNMP data, although that's fairly commonplace in this day and age of IT networking.

There are a slew of SNMP Monitoring Software and Tools in the marketplace that have become extremely popular as of lately and can further cut down your time of configuration and management! SNMP exists in several versions, from the earlier and less secure v1, to the more recent and strongly recommended v3, which offers far superior security configurations. By default SNMP functions over primarily two UDP ports – 161 for general messages and 162 for trap messages.

In regards to SNMP setup you begin with a manager – an authorized system setup specifically to poll SNMP data and gather it from agents. Agent systems obviously are then tasked with gathering and aggregating this data into an MIB – “management information base”. The manager and agent send queries and data back and forth, updating and polling as necessary, ultimately in order to hoard all the information for you to later peruse or run queries on.

It's also worth emphasizing that SNMP agents can sometimes even be configured to report information from devices which themselves cannot handle SNMP traffic, acting as a mediator of sorts and meaning that even SNMP incompatible devices aren't entirely left out in the cold.

One downside of earlier versions of SNMP, v1 and v2, is that security on it was relatively lax – it did have something called ‘community stringers', which are basically passwords of sorts included in the get requests that allowed for some level of authentication.

The problem is that many simply used vendor default strings and, up to v2 of SNMP, the strings were plain text, making them very easy to discern. Thankfully with v3 SNMP now supports a much better standard of security around community strings and obfuscates far more, thus allowing them to perform proper authentication!

The MIB is organized in a hierarchical fashion, which can be a little confusing at first glance without taking some time to understand precisely how the MIB is built and put together so that you better know how to then query and take it apart!

There are two different varieties of MIB – Scalar and Tabular. Scalar MIBs define a single object instance whereas the tabular counterpart define multiple related object instances in MIB tables. OIDs, also known as Object Identifiers, are essentially each smaller building block portion of a MIB. An OID uniquely identifies each object managed within an MIB hierarchy and its design makes it reasonably flexible for even proprietary needs.

The configuration of the server and client aspects of all this can get fairly confusing depending on the specific monitoring needs, and means that software options which help do the job of setup and configuration can really stand out.

The nice thing these days is that countless devices, which go well beyond just networking and routing, support SNMP – printers and even workstations themselves provide SNMP support and can give you an excellent extra angle of tracking and support for devices beyond just those used directly in your network traffic routing.

SNMP can monitor a wide range of Windows-specific services including WINS, DHCP, IIS, Microsoft's LAN Manager, Routing and Remote Access, IAS, and System monitor counters – of these, it can even configure and make adjustments to IAS, LAN Manager, and WINS.

Generally an SNMP agent and manager will utilize an array of relatively simple commands to communicate with one another, most of which are quite self explanatory – Get, GetNext, Set, GetBulk, Response, Trap, and Inform. The majority of those are easy to discern the functionality of just at a glance – Get is sent to request a value, and Response provides it.

GetNext does the same but for the next sequential object after the previous Get, rather than having to continually call Get after Get by proper identification number.

The only less obvious ones include Trap, which provide an unsolicited Response, generally to serve as an alert or heads up of an event or threshold, and Inform, which is essentially a response but specific to Traps to assure agents that it has been received, as they will continue sending Traps otherwise.

As mentioned above, the Trap/Inform pairing is the less ‘simple' aspect of the SNMP, though ultimately there's not a lot of complexity even here. Generally speaking, an agent only communicates to a manager when something is requested of it – generally via Get, GetNext, or GetBulk for the most part.

Sometimes, however, an agent needs to communicate unsolicited to the manager, for example if a manager is handling a large number of devices it may not make sense to force it to do all of the polling and gathering as it becomes downright impractical.

As a result, Traps can be used to essentially trigger polling from the manager to the agent and create a much more smooth SNMP interface setup. For all intents and purposes Trap and Inform work in the same way as Get and Response only that the initiation device is reversed – a manager gets and an agent Response's, while an agent Traps and a manager informs!

This approach can also save a great deal in network traffic bloat and agent resources by cutting back on unnecessary and frivolous excessive SNMP polling. However, the flip side, is that a device experiencing an outage obviously cannot send a Trap, and thus some amount of polling is still wise rather than relying on a complete Trap/Inform based method.

SNMPs flexibility and power comes in the broad reach of each of these commands as well as the relatively few number of them. It's pretty easy to remember most if not all, and even easier yet to quickly discern how to go about querying whatever data you need and, from there, you can go about the process of proper analysis and aggregation of that data for other purposes.

Ultimately SNMP is another facet of the overall task of managing a network and its devices, the key to which is reliable and consistent data. SNMP further builds on that by providing some ability to make configuration adjustments via the protocol itself, letting it double as not only sleuth for your problems but solver as well!

Fortunately there are a wide range of programs out there that build on the SNMP technology which undoubtedly already exists on most, if not all, the hardware devices on your network in an ever-ready state to start monitoring and churning out all the data they can find!

Common SNMP Terminology:

• Manager, a.k.a. Management Station a.k.a. Network Management Station:
  The system and software setup to poll agents and communicate back and forth via SNMP for data gathering.
• Informs:
  A response sent specifically to acknowledge that a Trap was received. Prior to this there was no way to know if a Trap had been received or acknowledged at all! Supported in v2 and up.
• Get Next:
  The same as Get except that it does not require an OID – instead it simply jumps to the Next OID in sequence and saves the hassle of tracking OID numbers in a series of requests.
• Get:
  A command sent from a manager to an agent which causes the agent to respond with the desired Response, normally accompanied by an OID to define what to Get.
• Community Strings:
  These function more or less like a password of sorts – a community string is a read-only string of data sent by the manager with each SNMP-based Get request which, based on whether the string is accepted or not, will allow or deny the polling of the particular agent. Most SNMP equipment comes with a default vendor-based community string, which can of course be changed.
• MIB:
  Management Information Base. See the beginning of this article for more information on MIBs.
• MIB Browser, a.k.a. MIB Walker:
  A tool that can pull data from SNMP enabled devices, helping to identify which objects respond to a query.
• Notification:
  Identical to Trap, just with a more intuitive name. v2c and up use this term in place of Trap to make more clear its purpose and function.
• OID:
  In short, a string of numbers separated by periods which identifies each part of the MIB.
• Object:
  Whatever piece of information the agents are gathering and storing in the MIB.
• Polling:
  The act of the manager reaching out to agent devices and actively requesting data.
• Set:
  An SNMP command which can be used to configure and change certain values.
• Trap:
  This can be considered a “reverse” polling – normally communication for polling is initiated by the manager, but this allows an agent to initiate conversation and prompts an Inform response to assure it was received and acknowledged.
• Variable:
  The contents of an object – i.e. if the object is “CPU Temp” the Variable could be “54c”.
• Version 1:
  The first iteration of SNMP – very little security or flexibility at all.
• Version 2c:
  Developed specifically to address some of the concerns with the initial version of SNMP. One problem came about in that numerous branches of v2 were created, resulting in some fragmenting of standardization, which was counter-intuitive to the initial goal of SNMP. v2c ended up being the most commonly prevalent of these. v2 overall had several improvements in protocol handling, but security still was fairly lax due to community strings being shared in plain text.
• Version 3:
  The newest version of SNMP which supports full authentication and security features and is always strongly recommended, especially on untrusted networks!

SNMP FAQs