This article is devoted to 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 can be achieved when organizing distributed alerting in a large network. SNMP is the main protocol for monitoring network equipment, and Zabbix is ββgreat for monitoring a large number of objects and summarizing large amounts of incoming metrics.
A few words about SNMPv3
Let's start with the purpose of the SNMPv3 protocol, and the features of its use. SNMP tasks - monitoring network devices, and elementary management by sending simple commands to them (for example, enabling and disabling network interfaces, or rebooting the device).
The main difference between the SNMPv3 protocol and its previous versions is the classic security features [1-3], namely:
- authentication (Authentication), which determines that the request was received from a trusted source;
- encryption (Encryption), to prevent disclosure of transmitted data when intercepted by third parties;
- integrity (Integrity), that is, a guarantee that the packet was not tampered with in transit.
SNMPv3 implies the use of a security model in which the authentication strategy is set for a given user and the group to which he belongs (in previous versions of SNMP, only "community" was compared in a request from the server to the monitoring object, a text string with a "password" transmitted in clear text (plaintext)).
SNMPv3 introduces the concept of security levels - acceptable security levels that determine the hardware configuration and behavior of the monitored object's SNMP agent. The combination of security model and security level determines which security mechanism is used when processing an SNMP packet [4].
The table describes the 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 encrypted authentication mode.
SNMPv3 configuration
Monitoring of network equipment assumes the same configuration of the SNMPv3 protocol on both the monitoring server and the monitored object.
Let's start by configuring the Cisco network device, its minimum required configuration is as follows (we use the CLI for configuration, I simplified the 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 includedThe first line snmp-server group defines the group of SNMPv3 users (snmpv3group), the read mode (read), and the access right of the snmpv3group group to view certain branches of the MIB tree of the monitoring object (snmpv3name further in the configuration specifies which branches of the MIB tree the group belongs to snmpv3group will be able to access).
The second line snmp-server user defines the snmpv3user user, his membership in the snmpv3group group, as well as the use of md5 authentication (the password for md5 is md5v3v3v3) and des encryption (the password for des is des56v3v3v3). Of course, instead of des it is better to use aes, here I give it just for 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 snmp-server view defines a codename that defines branches of the snmpv3name MIB tree so that they can be queried by the snmpv3group user group. ISO, instead of strictly defining a single branch, allows the snmpv3group user group to access all objects in the MIB tree of the monitoring object.
A similar Huawei hardware setup (also in the CLI) looks like this:
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
des56v3v3v3After configuring network devices, you need to check for access from the monitoring server via the 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 descriptive tool for querying specific OIDs using MIB files is snmpget:
Now let's move on to setting up a typical item for SNMPv3, within the framework of the Zabbix template. For simplicity and MIB independence, I use numeric OIDs:
I use custom macros in the key fields as they will be the same for all data elements in the template. You can set them within a template, if all network devices in your network have the same SNMPv3 settings, or within a host, if the SNMPv3 settings for different monitoring objects are different:
Please note that the monitoring system only has a username and passwords for authentication and encryption. The group of users and the area of ββMIB objects to which access is allowed is set on the monitoring object.
Now let's move on to filling the template.
Poll template in Zabbix
A simple rule when creating any survey templates is to make them as detailed as possible:
I pay a lot of attention to inventory, so that it is more convenient to work with a large network. More on that later, but for now, triggers:
For the convenience of visualizing triggers, their names contain {HOST.CONN} system macros so that the dashboard in the alerting section displays not only device names, but also IP addresses, although this is more a matter of convenience than necessity. To determine if a device is inaccessible, in addition to the usual echo request, I use checking for host inaccessibility via SNMP protocol, when the object is accessible via ICMP, but does not respond to SNMP requests - this situation is possible, for example, when IP addresses are duplicated on different devices, due to incorrectly configured firewalls, or incorrect SNMP settings on monitored objects. If you use checking the availability of nodes only via ICMP, at the time of investigating incidents in the network, monitoring data may not be available, 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 SNMP discovery function, with more discoverable options, 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 discovery, you can filter network interfaces by their types, user "descriptions", and administrative port statuses. Filters and regular expressions for filtering in my case look like this:
When detected, the following interfaces will be excluded:
- disabled manually (adminstatus<>1), thanks to IFADMINSTATUS;
- having no textual description, thanks to IFALIAS;
- having the symbol * in the text description, thanks to IFALIAS;
- which are service or technical, thanks to IFDESCR (in my case, in regular expressions IFALIAS and IFDESCR are checked by one regular expression alias).
The SNMPv3 data collection template is almost ready. Let's not dwell on the prototypes of data elements for network interfaces, let's move on to the results.
Results of monitoring
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 summary data on current software, serial numbers, and notifications about the arrival of a server cleaner (due to low Uptime). An excerpt from my list of templates is below:
And now - the main dashboard, with triggers distributed by importance levels:
Thanks to an integrated approach to templates for each model of devices in the network, it is possible to ensure that within the framework of one monitoring system a tool for predicting faults and accidents will be organized (if appropriate sensors and metrics are available). Zabbix is ββwell suited for monitoring network, server, service infrastructures, and the task of maintaining 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.
3. RFC 3415.
4. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapter: SNMP Version 3.
Source: habr.com