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.
1-800-693-0351
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 TodayLooking for a quick SNMP explanation? Here we'll discuss some of the SNMP 101 information, such as what the SNMP protocol is used for, its various components and functionalities.
SNMP is an application-layer protocol that is defined by the Internet Architecture Board (IAB) in RFC 1157 for allowing the exchange of data between network devices. It is part of the Transmission Control Protocol/Internet Protocol suite (TCP/IP).
What is SNMP used for? SNMP stands for Simple Network Management Protocol and is a very popular computer protocol used for remotely monitoring and controlling equipment. All sorts of network devices, from industrial telecommunications gear down to simple network switches and printers, can use this protocol to report their current status or receive commands. SNMP is almost always sent over standard IP.
Pre-configured SNMP sensors simplify network monitoring by allowing quick and easy integration with existing network management systems. These sensors come ready to use with minimal setup required, thanks to their built-in web interfaces on the Remote Terminal Units (RTUs). Once connected, they can monitor various parameters. These parameters include voltage, temperature, and internal resistance of devices or environmental conditions.
The data collected by these sensors is then transmitted using SNMP (SNMP stands for Simple Network Management Protocol) to a central management system like T/Mon. This centralized platform combines and displays all the sensor data. This provides network managers with real-time visibility and control over their network infrastructure. Alarms and notifications are automatically generated for any threshold breaches. This automation aids prompt responses to potential issues and increases the reliability and efficiency of network operations.
SNMP sensors from DPS Telecom are designed to be easily configurable. They can be quickly set up using the built-in web interface of the corresponding DPS RTU, such as the NetGuardian G6 series. This ensures that the sensors can be seamlessly integrated and monitored without requiring extensive manual configuration.
The three main components of SNMP are:
SNMP is built on the "manager-agent" architecture, which simply means that any SNMP device is either an agent or a manager. Any managed device or managed system that reports its status (like a switch or printer) is an agent. All of your agents must be configured to report to an SNMP manager, which collects and presents data from SNMP agents to network administrators who monitor your network.
Precisely how you are notified depends on your network management system. You might want a simple list showing all messages you've received. For more complex network traffic with a lot of messages, you'll probably benefit from a managed network that filters out unimportant messages so you can focus on the few that really matter. It's also possible to receive email, text message, or phone notifications of certain messages.
Even though the name is a bit confusing, a "trap" is really just the most popular type of SNMP message. An agent sends a trap message to your manager to indicate a particular problem or status.
Traps, while most common, are fairly limited. They're one-way messages from agents to managers. The manager does not respond to traps in any way, so it's possible for the occasional trap to go missing. Other message types, mostly generated by the manager, solve this problem and allow for remote control of agents.
If a manager wants to gather the current status of a device, it doesn't have to wait for an incoming trap (which may never come if the device has completely failed). SNMP managers can send GET requests to "get" a value from a device.
Depending on the data needed, your manager may send a GET that demands the device's on-board temperature reading, whether it has any alarm conditions to report, or just about any other information. Upon receiving a GET, an agent response with a GET response that contains the requested data.
Your manager has an overarching "bird's eye" view of your network, so it's a great place for monitoring and management of an entire network.
Imagine that your manager is made aware (via traps or GET responses) that several devices in one server room are overheating. Your manager can be configured to make an immediate, automated decision to activate your backup air-conditioning (HVAC) system. To do this, it must send a SET message to "set" a value on the target device (the backup HVAC, in this case). A SET-response (see the pattern?) is sent by the agent to confirm that it has received and followed the SET instructions.
There are a few other SNMP message types, but you understand all the basic concepts if you understand traps, GETs, and SETs.
In this diagram, a manager sends a SET to activate a backup generator.
SNMP provides value through its ability to streamline and enhance network management. Sysadmins can use SNMP to gather crucial data from various devices across the network. This data collection is essential for providing context and tracking network performance. This data collection also helps in identifying issues and making informed decisions to maintain optimal network functionality. With features like data aggregation, issue tracking, and centralized control, SNMP provides great value to your operations.
One of the fundamental inner workings of the SNMP protocol is the MIB. The structure of the Management Information Base (MIB) is a formatted text file that lists all of the data objects used by a particular piece of equipment. When you buy a monitor device that uses SNMP (for example, a managed switch), you'll tell it to send messages to your central manager. But there are tens of thousands of different SNMP products, and your manager doesn't natively understand each one.
That's where the MIB comes in. The manufacturer of your device will supply you with a MIB file (usually a download from their website) that you'll load ("compile") into your manager. Compiling converts the MIB from its raw ASCII format into a binary format the manager can use. If you've ever installed a device driver on a PC, you understand this concept.
Without the MIB object file for SNMP message translation, communication simply won't happen.
In other words, the MIB is a 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. So, as far as many SNMP managers and agents are concerned, if a component of a network device isn't described in the MIB, it doesn't exist.
The elements defined in the MIB syntax can be extremely broad (for example, all objects created by private businesses) or they can be extremely specific (like a particular Trap message generated by a specific alarm point on an RTU.) Each element in the MIB is given an object identifier or OID. An OID is a number that uniquely identifies an element in the SNMP universe. Each OID is associated with a human-readable text label.
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.
SNMPv1, SNMPv2c and SNMPv3 are the three major SNMP versions.
SNMPv1 was the first version of SNMP. Although it accomplished its goal of being an open, standard protocol, it was found to be lacking in key areas for certain applications. Later versions have addressed many of these problems. Smaller RTUs commonly support SNMPv1.
SNMPv2c is a sub-version of SNMPv2. Its key advantage over previous versions is the Inform command. Unlike Traps, which are simply received by a manager, Informs are positively acknowledged with a response message. If a manager does not reply to an Inform, the SNMP agent will resend the Inform.
SNMPv3 is the newest version of SNMP.
The "EngineID" Identifier in SNMPv3 uniquely identifies each SNMP entity. Conflicts can occur if two SNMP entities have duplicate EngineID's. The EngineID is used to generate the key for authenticated messages.
Although v1 and v2c support the community string capability, SNMPv3 provides even better security features. These features are:
Authentication
Authentication is used to ensure that traps are read by only the intended recipient. As messages are created, they are given a special key that is based on the EngineID of the entity. The key is shared with the intended recipient and used to receive the message.
Privacy
Privacy encrypts the payload of the SNMP message to ensure that it cannot be read by unauthorized users. Any intercepted traps will be filled with garbled characters and will be unreadable. Privacy is especially useful in applications where messages must be routed over the Internet.
This protocol uses both port 161 and port 162 for sending commands and messages.
The manager at the top of the system sends commands down to a network device using destination port 161.
When it wants to report something or respond to a command, an agent will send a message to port 162 on the manager.
SNMP uses UDP by Default, but TCP is Possible There are two types of protocols used in the Transport Layer (a sub-division of the IP layer); Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). SNMP can be implemented over both protocols via LAN.
TCP is connection-based, meaning that one program is connected to another program and they send messages across the internet to each other. TCP is relatively heavy, meaning it requires three packets to set up a connection before user data can be sent.
While TCP can be used for SNMP, it was originally designed for UDP transport only. While UDP may not have all the functionality of TCP, this actually makes it better for some applications. UDP is faster than TCP because it does not order packets (which can be done by the application layer), and it is a connectionless protocol. UDP is actually better suited for repetitive, low-priority functions like alarm monitoring.
As discussed above, SNMP uses UDP ports 161 and 162 by default.
Obviously, this hasn't been an exhaustive discussion of SNMP. I've tried to give you a reasonable introduction to the protocol without bombarding you with techno-jargon. There's a lot more information available right here on the DPS website. I recommend:
