SNMP Agent Protocol MonitoringUse This InfluxDB Integration for Free
SNMP (Simple Network Management Protocol) is an application-layer protocol used to manage and monitor network devices. SNMP provides a common way for devices on your network — such as routers, switches, WiFi access points, printers, and anything connected in an IP network — to share monitoring metrics. An SNMP agent is shipped with practically any network equipment, providing an out-of-the-box way to monitor devices over both local area networks (LANs) and wide area networks (WANs). SNMP has also been adopted by some internet of things (IoT) devices vendors.
SNMP pull vs push model
SNMP monitoring can be implemented in two modes: pull or push (traps).
- In the pull model, a monitoring agent sends SNMP requests to a SNMP agent running on the target device on scheduled regular intervals. The SNMP agent on the device responds with the specific requested metric.
- In push mode, a.k.a. SNMP Trap, communication starts from the opposite end. The monitored device (via SNMP agent) sends status messages (traps) to a trap receiver at the monitoring system. In the case of traps, there is no scheduling, trap messages are sent as they are generated, giving a real-time view of system and network performance issues.
By using SNMP pulling and SNMP traps, customers can balance resource consumption impact (both system and network) caused by short pulling intervals trying to catch subtle changes, when a trap would be a better and more cost-efficient option. For example, when a power supply unit or disk failure occurs, Telegraf would receive the SNMP trap and send it to the output plugins. You could then configure an alert to notify you or your team of the failure.
Network and system monitoring solution with Telegraf SNMP and Telegraf SNMP Trap Input Plugins
Telegraf SNMP and SNMP Trap plugins provide a comprehensive solution for monitoring SNMP data from networked devices. Device metrics resource utilization, load status and health check as well as network performance metrics can be monitored via SNMP monitoring.
Telegraf is the collection agent of InfluxData time series platform (see diagram below). InfluxData time series platform allows for the collection, visualization and analysis of all metrics and events ingested and monitored. InfluxDB — the purpose-built time series database is the platform’s core open source component. Telegraf is InfluxDB’s agent with hundreds of plugins for the most common applications and protocols ready to be activated and to start collecting metrics and events. Telegraf is also open source with its own project in the community.
One of the main use-cases for adopting a time series platform is systems and network monitoring. Gathering the data of interest is a key part of any monitoring solution. This can be done in multiple ways.
To facilitate the process, Telegraf was designed as a lightweight, plugin-driven collection agent that can either run on your hosts (collecting data about your systems and applications) or operate remotely (scraping data via endpoints exposed by your applications).
See below TICK Stack architecture:
SNMP provides a key benefit to any network management setup by allowing the system administrator to centrally manage and monitor multiple devices on the same network. By using SNMP an organized hierarchy of information is provided that can be accessed remotely in order to quickly identify and resolve problems. This hierarchical structure is managed through a series of Managed Objects which are documented in the MIB (Management Information Base).
Compatibility is another benefit of SNMP. SNMP integrates with a variety of devices regardless of manufacturer. This allows system administrators to monitor and configure multiple devices at once, which can greatly reduce both time and cost of setting up network monitoring.
SNMP is also used as an important tool in troubleshooting various aspects of a network environment by allowing administrators to identify bottlenecks and potential problems. As an example, a system administrator can use SNMP to measure bandwidth usage on a device and then identify areas in need of improvement or upgrade. This helps ensure that the network is operating at peak performance and eliminates costly downtime due to system failures.
A final benefit SNMP offers is ease of administration. By providing an organized hierarchy of information, SNMP makes it easier for administrators to manage and monitor large networks. This reduces the amount of time required to troubleshoot problems and increases overall network efficiency. SNMP also allows for automated processes such as device configuration changes which can further reduce the time needed by system administrators.
As with most technologies, there are some drawbacks to SNMP. The primary disadvantage of this technology is the complexity associated with setting up and maintaining an SNMP system. In order for SNMP to be used effectively the administrator must have a thorough understanding of how it works, as well as its underlying protocols.
Potential security vulnerabilities has long been considered a downside of SNMP. SNMP V3 did add some features to alleviate these concerns by allowing for proper encryption and authentication but it can still be an issue in legacy systems.
A final downside to SNMP is related to scalability, mostly due to the primarily polling based nature of the protocol. For networks that require very high granularity for data collection to avoid downtime, SNMP devices can get overloaded by frequent polling requests. In a production environment there are typically multiple SNMP managers polling each device for redundancy purposes, which further complicates things and puts more load on the devices being polled.
As a result many legacy systems have to deal with only polling at minute or longer intervals, which can result in gaps where they have no insight into the system. In the event of an outage not only are they delayed in their response, but they may not have data to identify the root cause of the problem. Many modern monitoring systems have moved towards a push based approach to allow for higher frequency metric collection as a result.
SNMP use cases
One of the most common use cases for SNMP is network management. SNMP can be used to monitor network devices such as routers, switches, and servers in order to ensure that they are operating properly. SNMP can be used to monitor network performance in order to identify potential bottlenecks and any other issues.
SNMP is also used for security monitoring. Network activity monitored with SNMP can be used to detect suspicious activity that may indicate a security breach. SNMP can also be used to monitor the health of security devices such as firewalls and intrusion detection systems.
Another common use case for SNMP is capacity planning. By monitoring devices on the network, it is possible to determine when upgrades or adding more hardware will be necessary in order to maintain adequate performance levels.
SNMP is often used for troubleshooting. By monitoring devices on the network, it is possible to identify potential problems before they cause significant disruptions. SNMP can be used to track down the source of problems that have already occurred.
Data collected via SNMP can be used for reporting purposes. By collecting data from devices on the network, it is possible to generate reports that provide insights into network usage and performance.
Why do you need to monitor SNMP?
Monitoring SNMP is essential for ensuring the performance and availability of a network. SNMP monitoring helps identify potential problems before they become critical, allowing administrators to take corrective action when necessary.
Additionally, it can help diagnose problems and reduce operational costs by providing visibility into the current state of the network infrastructure. Finally, SNMP can provide real-time alerts when performance thresholds are exceeded or traffic patterns change, allowing for a quick response. By monitoring SNMP, administrators can ensure the availability and performance of their network and prevent costly outages.
Telegraf SNMP Plugin configuration
The Telegraf SNMP input plugin uses polling to gather metrics from SNMP agents. The plugin also includes support for gathering individual OIDs as well as complete SNMP tables.
Configuring Telegraf for SNMP collection
The following configuration is used to run the SNMP plugin with Telegraf. Read more about the details to configure Telegraf in our documentation.
[[inputs.snmp]] ## Agent addresses to retrieve values from. ## format: agents = ["<scheme://><hostname>:<port>"] ## scheme: optional, either udp, udp4, udp6, tcp, tcp4, tcp6. ## default is udp ## port: optional ## example: agents = ["udp://127.0.0.1:161"] ## agents = ["tcp://127.0.0.1:161"] ## agents = ["udp4://v4only-snmp-agent"] agents = ["udp://127.0.0.1:161"] ## Timeout for each request. # timeout = "5s" ## SNMP version; can be 1, 2, or 3. # version = 2 ## SNMP community string. # community = "public" ## Agent host tag # agent_host_tag = "agent_host" ## Number of retries to attempt. # retries = 3 ## The GETBULK max-repetitions parameter. # max_repetitions = 10 ## SNMPv3 authentication and encryption options. ## ## Security Name. # sec_name = "myuser" ## Authentication protocol; one of "MD5", "SHA", or "". # auth_protocol = "MD5" ## Authentication password. # auth_password = "pass" ## Security Level; one of "noAuthNoPriv", "authNoPriv", or "authPriv". # sec_level = "authNoPriv" ## Context Name. # context_name = "" ## Privacy protocol used for encrypted messages; one of "DES", "AES", "AES192", "AES192C", "AES256", "AES256C", or "". ### Protocols "AES192", "AES192", "AES256", and "AES256C" require the underlying net-snmp tools ### to be compiled with --enable-blumenthal-aes (http://www.net-snmp.org/docs/INSTALL.html) # priv_protocol = "" ## Privacy password used for encrypted messages. # priv_password = "" ## Add fields and tables defining the variables you wish to collect. This ## example collects the system uptime and interface variables. Reference the ## full plugin documentation for configuration details. [[inputs.snmp.field]] oid = "RFC1213-MIB::sysUpTime.0" name = "uptime" [[inputs.snmp.field]] oid = "RFC1213-MIB::sysName.0" name = "source" is_tag = true [[inputs.snmp.table]] oid = "IF-MIB::ifTable" name = "interface" inherit_tags = ["source"] [[inputs.snmp.table.field]] oid = "IF-MIB::ifDescr" name = "ifDescr" is_tag = true
For more information, please check out the documentation.
Telegraf SNMP Trap configuration
Like most Telegraf plugins, the SNMP Trap Input Plugin does not require much configuration. Some prerequisites to install tools from the net-snmp project are required. In addition, on many operating systems, listening on a privileged port (a port number less than 1024) requires extra permission. Since the default SNMP trap port 162 is in this category, using Telegraf to receive SNMP traps may require elevated permissions.
[[inputs.snmp_trap]] ## Transport, local address, and port to listen on. Transport must ## be "udp://". Omit local address to listen on all interfaces. ## example: "udp://127.0.0.1:1234" ## ## Special permissions may be required to listen on a port less than ## 1024. See README.md for details ## # service_address = "udp://:162" ## Timeout running snmptranslate command # timeout = "5s"
What metrics are collected from Telegraf SNMP Trap plugin?
|IP address of trap source|
|value from SNMPv2-MIB::snmpTrapOID.0 PDU|
|Management Information Base (MIB) from SNMPv2-MIB::snmpTrapOID.0 PDU|
|Object Identifiers (OID) string from SNMPv2-MIB::snmpTrapOID.0 PDU|
|Version “1" or "2c" or "3"|
Fields are mapped from variables in the trap. The field names are the trap variable names after MIB lookup. The field values are trap variable values. (example fields:
SNMP components and architecture
SNMP MIB (Management Information Base)
The SNMP MIB is a hierarchical information structure that can be accessed through SNMP which contains information about the devices and their settings. Contains the object identifier(OID) for the device and additional human readable information.
An SNMP agent(also called SNMP clients) is an application that runs on a device being managed and responds to requests from the SNMP manager. The agent stores information about the device’s status and will pass that information along to the SNMP manager when it is polled.
Common metrics collected by the agent include CPU utilization, bandwidth usage, and disk space usage.
An SNMP manager(also known as an SNMP server) is what polls network devices to collect information. The SNMP manager also processes SNMP Traps which are sent from SNMP agents without having to be polled.
SNMP OID (Object Identifier)
An SNMP OID is a string of numbers that uniquely identifies a specific device being monitored by a MIB.
SNMP Community String
An SNMP community string is part of the configuration for an SNMP agent which acts as a password and allows an SNMP message to be decoded. Agents generally have three different community strings to allow for reads, read and writes, and traps.
SNMP primarily uses UDP port 161 and 162 for message transport. Port 161 is used by the SNMP agent to receive requests and requests are sent back to the SNMP manager. Port 162 is used by the manager to receive SNMP Trap and InformRequests notifications.
When using TLS or DTLS, SNMP usings ports 10161 and 10162 in a similar way as described above for sending and receiving messages.
SNMP Version 1 is the original version of the protocol and was designed in the 1980s. It is a simple protocol that uses clear text passwords for authentication and does not provide any encryption. This makes it insecure and susceptible to eavesdropping.
SNMP Version 2 was developed in the mid-1990s as an improvement over SNMP Version 1. It added support for encryption and increased security by using a community-based authentication system.
SNMP Version 3 was developed in the late 1990s and is the most recent version of the protocol. It adds support for further security enhancements, such as data integrity checks, encryption of messages, and authentication.
SNMP Security Explained
SNMP security is a set of measures taken to protect Simple Network Management Protocol (SNMP) networks from malicious access and other threats. SNMP security includes authentication, authorization, encryption, and access control.
Authentication is the process of verifying that a user or device is legitimate. This can be done using passwords or digital certificates. Authorization is the process of granting a user or device access to certain resources, such as network components and services. Encryption is the process of scrambling data so that it can only be read by authorized users and devices. Finally, access control is the process of allowing or denying specific requests based on various parameters.
SNMP security also includes features such as network access control, authentication traps, and object-level security. Network access control is used to restrict access to certain portions of the SNMP network. Authentication traps are notifications sent by an SNMP device when it detects a malicious user or device attempting to gain access. Finally, object-level security prevents users from changing settings on a given
SNMP version 3 brought additional security features to the protocol, such as user-based security and view-based access control. User-based security adds an extra layer of authentication by requiring users to provide a username and password before they can access the SNMP network. View-based access control allows administrators to restrict what information is visible to certain users and devices on their network.
SNMP Get Command
The SNMP Get command is used to retrieve information from a remote device. This information can include the device’s current configuration, status, and statistics. The Get command can be used to grab a single value or multiple values from the device.
SNMP Set Command
The Set command is used to change the configuration of a remote device. Multiple values can be changed at once and are treated as an atomic operation by the agent. A response with the new values for the changed variables are sent back to the SNMP manager.
SNMP GetNext Command
The GetNext command is used to retrieve information from a remote device in a sequential manner. This means that if you use the GetNext command to retrieve information about an SNMP agent’s password, you will also receive information about the agent’s other parameters in the order they are stored in the MIB of that device by the agent. GetNext can be used to get all available information for a device.
SNMP Walk Command
The SNMP Walk command is similar to the GetNext command, but it allows you to retrieve all of the information for an OID without having to run unique GetNext commands for each one.
SNMP Trap Command
SNMP Trap is a type of message that can be sent asynchronously to an SNMP manager without requiring polling. Traps are typically used to signal an issue like an error or failure.
SNMP Inform Command
The Inform command is an extension of the Trap command. It allows a management station to send information to an SNMP agent and receive confirmation that the message has been received. The Inform command can be used to ensure that an SNMP agent has received critical configuration changes or other important notifications. This allows the SNMP manager to know that a message has been guaranteed to have been delivered to an SNMP agent.
SNMP Response Command
The Response command is used to acknowledge the receipt of an SNMP message. This can be used to ensure that a message has been successfully received by a remote device or management station.
SNMP Traps vs. Informs
Within the context of SNMP, traps are those alert messages that are sent from all of your remote devices to a central collector, known as the manager. This is a slightly different concept from informs or inform requests, which is a feature that allows routers to send informs to SNMP managers when particular events like error conditions occur.
SNMP Polling vs. Traps
In SNMP polling, the Management Information Base (MIB) objects request and receive data from the agents deployed at remote sites, rather than the other way around.
SNMP polling is a pull mechanism ideal to collect monitoring data at regular intervals, while SNMP traps are a push mechanism ideal to notify about events and to avoid flooding the network with monitoring messages.
Frequently asked questions about SNMP
When was SNMP created?
The SNMP protocol was first introduced all the way back in 1988 in an effort to better meet the growing needs for a standard for managing IP devices on a network — something that was exploding in popularity at the time. SNMP was created in part to provide users with a “simple” set of operators that would allow these devices to be effectively managed remotely, thus opening up a whole new world of possibilities as a result.
Which SNMP Version is best?
Since 1988, three major versions of SNMP have been developed and deployed to the public. SNMPv1 was the original version. SNMPv2 included significant improvements with regards to performance, security and manager-to-manager communications. This version is also the one that introduced the option for 64-bit data counters.
SNMPv3 is interesting in that it actually makes no changes to the protocol (with the sole exception of adding cryptographic security) — it just looks very different thanks to a lot of new textual conventions, concepts and terminology. Support for a larger number of security models was added, as this was always one of the major points of criticism present in earlier releases.
Since security was always considered to be a major weakness in the first two versions of SNMP, SNMPv3 would undoubtedly be considered the best among industry professionals. Keep in mind that authentication in the first two versions amounted to little more than a password that was itself sent in a clear text message between a manager and an agent. This is woefully inadequate these days so if you want to keep your network devices safe while also creating a more effective way to manage them, SNMPv3 would undoubtedly be the way to go.
Why is SNMP so important?
Keep in mind that SNMP was created to help people monitor and manage their networks in the easiest way possible. Not only that, but it works with products and services by many manufacturers — all in a way that is straightforward to use and easy to understand.
If you think that network management was difficult in 1988, things have gotten exponentially more complicated in the decades since. Today, there may be countless devices on a network from mobile devices to workstations to printers and more. This is only going to get more problematic as time goes on with the rise of the Internet of Things.
Don’t forget that we are about to enter into a time when literally billions of devices will all be connected to networks around the world creating and sharing information not only with users but with one another. The sheer volume of personal information to be exposed by weak security will soon prove to be catastrophic. Soon, SNMP will become even more valuable than it already is in terms of allowing administrators to understand exactly what is going on with their networks at a given moment, all so that they can take the best steps possible for their protection and maintenance on an ongoing basis.
Having a deployment like SNMP in place today won’t just allow people to meet today’s challenges — it will also better prepare themselves to address the issues of tomorrow.
What is the difference between SMTP and SNMP?
SMTP is an acronym short for “Simple Mail Transfer Protocol.” In other words, it is a protocol used with computer networks for the purposes of email communication. Other than the fact that their acronyms are relatively similar, SMTP and SNMP are two entirely different concepts and should be treated as such.
What is the difference between RMON and SNMP?
The major difference between RMON and SNMP is that the former is used for “flow-based” monitoring while the latter is used for “device-based” monitoring and management. They, too, serve somewhat different purposes.
SNMP can be used to make sure that your network is working at peak efficiency. RMON, on the other hand, can help make sure that this is still true even if a user happens to be offline at the time. They both bring their own unique advantages to the table and both have a home within your network management stack.