SNMP monitoring: Tips to use the Simple Network Management Protocol
This post is also available in : Spanish
What is SNMP monitoring?
In the most general terms, network monitoring means the use of available communication protocols to collect information on the status of communication systems, whether they be routers, land line communications or cell phones. This article will talk about one of the most currently-used protocols, SNMP, and how to exploit it in order to harvest data, covering all that you need to know to begin using SNMP monitoring. SNMP, or Simple Network Management Protocol, belongs to the application layer of a network, and allows information to be exchanged between network devices.
SNMP works in two ways: by polling or by traps. Polling consists of launching remote queries, either actively or on demand, carrying out operation queries synchronously. Traps, meanwhile, are messages sent by SNMP devices asynchronously, according to changes or events, to configured addresses. To get the most out of SNMP monitoring, it’s best to use both modes when setting up a monitoring system. Incidentally, the protocol has three versions; 1 (SNMPv1) and 2 (SNMPv2), most frequently found on professional setups, and SNMPv3, which has extra security features, but has struggled to find a market.
The protocol works by launching a query against an IP address, and requires a specific parameter: the SNMP community string, an alphanumeric chain used to authorize the operation, and which adds an extra layer of security. When an SNMP check is launched against a compatible device, you get a list containing a lot of data that can be difficult to interpret at first:
# snmpwalk –v 1 –c public 192.168.50.14
Each line returned by snmpwalk has an OID (object identifier) and corresponds to a piece of data determined by the device. To better understand what the values returned by the SNMP check are, you can install the system manufacturer’s MIBs (management information base). MIBs are libraries that translate these numeric chains into a legible format allowing us to interpret the data.
Let’s look at some data we’ve got back after executing an SNMP check with the MIBs installed:
There are also web sites where you can consult any of these OIDs in case of doubt. If you know the OIDs you want to monitor, you can carry out the query like this by indicating the alphanumeric code that appears after the IP address in question:
# snmpwalk –v 1 –c public 192.168.1.50 IF-MIB::ifPhysAddress.2
Done like this, only the values of the SNMP object queried will be shown, so if you have a monitoring tool the data will be included in the different checks. In this case, we created a basic SNMP monitoring for a few devices using Pandora FMS, and the result is as follows:
SNMP polling alerts
Once data collection on modules via SNMP polling is being carried out, we can create alerts on Pandora FMS for those modules, executing actions proactively in function of the thresholds we’ve configured, and they work in the same way as any other alerts for any modules on Pandora FMS.
SNMP trap monitoring
First configure your devices to send traps when specific circumstances are met, and secondly set up a tool that can collect the SNMP traps it receives, whether it be a machine with the necessary services, or a piece of monitoring software. How you configure the SNMP devices will depend on the manufacturer’s model and the device itself, and is carried out from a management interface accesible via a browser and its IP address.
Traps can be received in Linux by using the demon snmptrapd, installed as follows, e.g. on CentOS systems:
# yum install net-snmp-utils net-snmp-libs net-snmp
In our example we’re going to use Pandora FMS to receive and process the SNMP traps. If you already have a Pandora FMS server installed you won’t need any new dependencies, but you’ll have to enable it to receive the traps. Search for snmpconsole in the pandora_server.conf file and enable it as follows:
Once the SNMP traps console is enabled Pandora FMS will be able to receive and process them and display them in the corresponding section:
To ensure the incoming traps are arriving correctly, you can consult the corresponding log file, usually at: /var/log/snmptrapd.log.
SNMP trap alerts
Alerts can also be configured via SNMP monitoring for the traps we prepared. In this case they won’t function in the same way as any other module, unlike with SNMP polling, but instead are based on filtering rules. Using these rules we can identify traps belonging to other devices, filter the contents of said trap, OID, etc..
In the next screenshot you can see various alerts created with different filtering options, and actions checking that everything is working fine: