Monitoring network equipment over SNMPv3 in Zabbix

This article discusses the features of monitoring network equipment using the SNMPv3 protocol. We will talk about SNMPv3, I will share my experience in creating full-fledged templates in Zabbix, and show what you can achieve when organizing distributed alerts on a large network. SNMP is the main protocol for monitoring network equipment, and Zabbix is ​​excellent for monitoring a large number of objects and summarizing significant volumes of incoming metrics.

A few words about SNMPv3


Let's start with the appointment of SNMPv3, and the features of its use. SNMP tasks are monitoring network devices, and elementary management, by sending simple commands to them (for example, turning network interfaces on and off, or rebooting the device).

The main difference between the SNMPv3 protocol and its previous versions is the classic security features [1-3], namely:

  • Authentication, which determines that the request is received from a trusted source;
  • Encryption, to prevent disclosure of transmitted data when intercepted by third parties;
  • Integrity, that is, a guarantee that the packet was not tampered with during transmission.

SNMPv3 implies the use of a security model in which an authentication strategy is set for a given user and the group to which he belongs (in previous versions of SNMP, in the request from the server to the monitoring object, only “community” was compared, a text string with a “password” transmitted in clear form (plain text)).

SNMPv3 introduces the concept of security levels - acceptable security levels that determine the configuration of equipment and the behavior of the SNMP agent of the monitoring object. The combination of the security model and the security level determines which security mechanism is used when processing the SNMP packet [4].

The table describes combinations of models and SNMPv3 security levels (I decided to leave the first three columns as in the original):



Accordingly, we will use SNMPv3 in authentication mode using encryption.

Configure SNMPv3


Monitoring network equipment involves the same configuration of the SNMPv3 protocol both on the monitoring server and on the monitored object.

Let's start by configuring a Cisco network device, its minimum required configuration is as follows (for configuration we use CLI, I simplified names and passwords to avoid confusion):

snmp-server group snmpv3group v3 priv read snmpv3name 
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included

The first line of snmp-server group - defines the group of SNMPv3 users (snmpv3group), read mode (read), and the right of access of the snmpv3group group to view certain branches of the monitoring object’s MIB tree (snmpv3name in the configuration below determines which branches of the MIB tree the group snmpv3group will be able to access).

The second line is snmp-server user - defines the user snmpv3user, his membership in the snmpv3group group, as well as the use of authentication md5 (the password for md5 is md5v3v3v3) and encryption des (the password for des is des56v3v3v3). Of course, instead of des it is better to use aes, here I give it just as an example. Also, when defining a user, you can add an access list (ACL) that regulates the IP addresses of monitoring servers that have the right to monitor this device - this is also best practice, but I will not complicate our example.

The third line of snmp-server view defines the code name that sets the branches of the snmpv3name MIB tree so that the snmpv3group user group can request them. ISO, instead of strictly defining a single branch, allows the snmpv3group user group to access all objects of the monitoring object’s MIB tree.

A similar configuration of Huawei equipment (also in the CLI) is as follows:

snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 
            md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56
            des56v3v3v3

After setting up network devices, you need to check access from the monitoring server via SNMPv3 protocol, I will use snmpwalk:

snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252



A more visual tool for requesting specific OID objects using MIB files is snmpget:



Now let's move on to setting up a typical data element for SNMPv3, as part of the Zabbix template. For simplicity and independence from the MIB, I use digital OIDs:



I use custom macros in key fields, because they will be the same for all data elements in the template. You can set them as part of the template if all network devices on your network have the same SNMPv3 parameters, or within the host if the SNMPv3 parameters for different monitoring objects are different:



Please note that the monitoring system only has a username and passwords for authentication and encryption . The user group and the area of ​​MIB objects to which access is allowed is set on the monitoring object.
Now let's move on to filling out the template.

Zabbix survey template


A simple rule when creating any survey templates is to make them as detailed as possible:



I pay great attention to inventory so that it is more convenient to work with a large network. About this a little later, but for now - triggers:



For ease of visualization of triggers, their names contain system macros {HOST.CONN}, so that not only device names, but also IP addresses are displayed on the dashboard in the alert section, although this is more a matter of convenience than necessary. To determine the unavailability of the device, in addition to the usual echo request, I use the SNMP host unavailability check when the object is accessible via ICMP but does not respond to SNMP requests - this situation is possible, for example, when duplicating IP addresses on different devices, due to incorrectly configured firewalls, or incorrect SNMP settings on monitoring objects. If you use host access control only via ICMP, at the time of investigating incidents on the network, monitoring data may not appear, so their receipt must be controlled.

Let's move on to discovering network interfaces - for network equipment, this is the most important monitoring function. Since there can be hundreds of interfaces on a network device, it is necessary to filter out unnecessary ones so as not to clutter up the visualization and clutter up the database.

I use the standard detection function for SNMP, with a large number of detectable parameters, for more flexible filtering:

discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7]



With this detection, you can filter network interfaces by their types, user descriptions “description”, and administrative statuses of ports. Filters and regular expressions for filtering in my case look as follows:





Upon detection, the following interfaces will be excluded:

  • manually disabled (adminstatus <> 1), thanks to IFADMINSTATUS;
  • not having a text description, thanks to IFALIAS;
  • having * in the text description, thanks to IFALIAS;
  • being official or technical thanks to IFDESCR (in my case, in regular expressions IFALIAS and IFDESCR are checked by one alias regular expression).

The SNMPv3 data collection template is almost ready. We will not dwell on prototypes of data elements for network interfaces, we will move on to the results.

Monitoring results


To begin with - an inventory of a small network:



If you prepare templates for each series of network devices - you can achieve a convenient layout for analyzing the summary data on the current software, serial numbers, and notification of the arrival of a cleaning woman in the server (due to the small Uptime). An excerpt from my list of templates is below:



And now - the main dashboard, with triggers distributed by severity level:



Thanks to an integrated approach to the templates for each model of devices in the network, it is possible to achieve the fact that within the framework of one monitoring system a tool will be organized for predicting malfunctions and accidents (if there are appropriate sensors and metrics). Zabbix is ​​well suited for monitoring network, server, service infrastructures, and the task of servicing network equipment clearly demonstrates its capabilities.

List of sources used:
1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. pp. 325-329.
2. RFC 3410. tools.ietf.org/html/rfc3410
3. RFC 3415. tools.ietf.org/html/rfc3415
4. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapter: SNMP Version 3. www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp-snmpv3.html

All Articles