Simple Network Management Protocol (SNMP) is an internet protocol defined by the Internet Engineering Task Force (IETF).
SNMP is nothing more than a standard language that computers use to control each other and report important information. Its advantage today is that, since it's an open protocol, a very large number of devices support it, enabling them to work together.
SNMP protocol has become one of the most commonly used protocols in monitoring applications. Its main function is to manage and monitor network devices for alarms that require corrective action and/or human intervention.
In a typical SNMP network, there are several components that are linked together to give the company complete visibility of all their gear and sites.
The agent is typically the device joined to the managed devices being monitored. In other words, an agent is the remote device out in the network. What exactly the agent is depends on the kind of network you have.
For example, in a remote site you might be monitoring the temperature. If the temperature gets too high or too low, it could damage your gear. The temperature sensor (the managed object) is joined to an RTU, which acts as an agent in the managed system.
The agent takes readings from the sensor and relays the values to the manager. If the sensor or other gear is not SNMP compatible, the agent must mediate the protocol to SNMP for the manager.
The job of the manager is to receive the values from the agent and display them in meaningful terms to the network administrator or appropriate person for corrective action.
There are several ways the agent and manager talk. SNMP Trap messages are ones that are sent by the agent and signal a change-of-state (COS) alarm. If the temperature at a site rises above a predetermined level, the agent sends a Trap message to the manager for human intervention.
Traps are the essence of SNMP, since they provide your manager with the info required to give you an overall understanding of your network status.
The Inform, sometimes supported in v2c or v3 implementations, is like a trap that also requires a confirmation response from the SNMP manager.
GET alarms are sent by the manager, usually at regular, programmed intervals. They request status information from the agent. There are three types of GET alarms; GET, GET-NEXT, and GET-RESPONSE. Each message requires a slightly different response from the agent, but the basic function is the same.
When a manager asks an agent for information with a GET message, the agent replies with a GET-RESPONSE. The manager might only need that once piece of data, or it can then send a GET-NEXT message (repeated as many times as necessary) to ask for a full status update.
Lastly, SET alarms are sent from the manager to the agent to initiate a change. For instance a SET alarm could tell the agent to open a door, set the temperature or other controlled inputs.
Management Information Base (MIB) is an ASCII text file that describes SNMP network elements (any device in the network) as a list of data objects. It is essentially a dictionary of the SNMP language, where every object referred to in an SNMP message must be listed in the MIB.
The primary reason for the MIB network is to translate numerical strings into readable text for humans. When an SNMP device sends a Trap or other message, it identifies each data object in the message with a number string called an object identifier. The MIB provides a text label called for each OID. Your SNMP manager uses the MIB as a codebook for translating the OID numbers into a human-readable display.
How the MIB works in 3 steps:
The manufacturer of your device will supply you with a MIB file.
You'll load the MIB into your SNMP manager.
Your SNMP manager will use the MIB to interpret the incoming messages from your new device.
If an object does not have an OID listed within an MIB, the SNMP Manager cannot identify it. Even if that object has a sensor and can transmit data, the SNMP Manager is blind without the MIB. For a condition or device to be monitored, it must have a corresponding MIB definition.
Object identifiers (OIDs) are an address used to identify devices and their statuses. Want to know the temperature reading coming from a sensor at your mountaintop remote facility? There's an OID for that.
OIDs are used to describe SNMP network elements by using a number string. Each segment in the number string denotes a different level in the order, starting with one of the two companies that assign OIDs, all the way down to every single, company-unique, numbers. An OID may look like this:126.96.36.199.4.1.2682.1 as shown in the image below.
In telecom, SNMP OIDs describe specific locations in the network. The OID allows the MIB to translate the location of the event into a status description for your network technicians.
The following keywords are used to define an OID in the MIB, also called a MIB object:
Defines the abstract data structure matching to the object type. It can take the form of binary numbers for discrete inputs (ON/OFF applications) or integers for analog inputs, which are more detailed than discretes.
Defines whether the object value may only be retrieved but not modified (read-only) or whether it may also be modified (read-write). When a device notifies the RTU that there is an alarm, it is read only. Read-write describes values that also may be changed, such as a door is closed but the device can remotely open it.
Contains a textual definition of the object type. The definition provides all semantic definitions needed for interpretation; it typically contains information of the sort that would be communicated in any commentary annotations associated with the object.
Individual vendors create their own MIBs that only include the OIDs associated specifically with their device. They commonly reference other industry-standard MIBs (called "RFC MIBs"). This structure is what makes an SNMP MIB object-oriented, a maximally efficient way of storing information.
Since MIB files are composed of ASCII text, they can be viewed using any word processor or text editor, even Microsoft Notepad.
When reading the MIB, you don't need to read every single line of text. However, it's important for you to know some of the concepts embedded in the MIB. Including:
What characteristics of the device can be controlled remotely using the SNMP manager
What event reports the device can send to the SNMP manager
What information the SNMP manager can request from the device, and what other RFC MIBs you need to support a device
Additional information about SNMP fundamentals is beyond the scope of this article. If you're new to SNMP and would like a more detailed introduction, please read How to Implement SNMP Monitoring in Your Network: A Practical, Step-By-Step Guide. This is another white paper available at no cost from DPS Telecom.
Every DPS Telecom white paper provides detailed guidance on a single protocol or topic.
You need to see DPS gear in action. Get a live demo with our engineers.
Download our free SNMP White Paper. Featuring SNMP Expert Marshall DenHartog.
This guidebook has been created to give you the information you need to successfully implement SNMP-based alarm monitoring in your network.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.Reserve Your Seat Today