Este artículo está dedicado a las características del monitoreo del equipo de red utilizando el protocolo SNMPv3. Hablaremos sobre SNMPv3, compartiré mis experiencias en la creación de plantillas completas en Zabbix, y mostraré lo que se puede lograr al organizar alertas distribuidas en una gran red. El protocolo SNMP es fundamental para el monitoreo del equipo de red, y Zabbix es excelente para monitorear una gran cantidad de objetos y recopilar grandes volúmenes de métricas entrantes.
Algunas palabras sobre SNMPv3
Comencemos con el propósito del protocolo SNMPv3 y las características de su uso. Las tareas de SNMP incluyen la supervisión de dispositivos de red y la gestión básica a través del envío de simples comandos (por ejemplo, encender y apagar interfaces de red, o reiniciar el dispositivo).
La principal diferencia del protocolo SNMPv3 respecto a sus versiones anteriores son las clásicas funciones de seguridad [1-3], a saber:
- autenticación (Authentication), que determina que la solicitud proviene de una fuente confiable;
- encriptación (Encryption), para evitar la divulgación de datos transmitidos en caso de interceptación por terceros;
- integridad (Integrity), es decir, la garantía de que el paquete no fue alterado durante la transmisión.
SNMPv3 implica el uso de un modelo de seguridad, donde la estrategia de autenticación se establece para un usuario y el grupo al que pertenece (en versiones anteriores de SNMP, la comparación en la solicitud del servidor al objeto monitoreado se realizaba solo con la 'community', una cadena de texto con una 'contraseña' transmitida en texto claro).
SNMPv3 introduce el concepto de niveles de seguridad, los niveles permitidos que definen la configuración del equipo y el comportamiento del agente SNMP del objeto de monitoreo. La combinación del modelo de seguridad y el nivel de seguridad determina qué mecanismo de seguridad se utiliza al procesar el paquete SNMP [4].
En la tabla se describen las combinaciones de modelos y niveles de seguridad de SNMPv3 (decidí dejar las tres primeras columnas como en el original):

Por lo tanto, utilizaremos SNMPv3 en modo de autenticación con encriptación.
Configuración de SNMPv3
El monitoreo del equipo de red implica la configuración idéntica del protocolo SNMPv3 tanto en el servidor de monitoreo como en el objeto observado.
Comencemos con la configuración del dispositivo de red Cisco; su configuración mínima necesaria es la siguiente (utilizaremos la CLI para configurar, he simplificado los nombres y contraseñas para evitar confusiones):
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 includedLa primera línea del snmp-server group define el grupo de usuarios SNMPv3 (snmpv3group), el modo de lectura (read), y el derecho de acceso del grupo snmpv3group para ver ciertas ramas del árbol MIB del objeto de monitoreo (snmpv3name define más adelante en la configuración a qué ramas del árbol MIB podrá acceder el grupo snmpv3group).
La segunda línea snmp-server user define al usuario snmpv3user, su pertenencia al grupo snmpv3group, así como la aplicación de la autenticación md5 (la contraseña para md5 es md5v3v3v3) y el cifrado des (la contraseña para des es des56v3v3v3). Por supuesto, en lugar de des, es preferible utilizar aes; aquí lo menciono solo como ejemplo. También al definir al usuario se puede agregar una lista de acceso (ACL) que regula las direcciones IP de los servidores de monitoreo que tienen derecho a monitorear este dispositivo; esto también es una mejor práctica, pero no complicaré nuestro ejemplo.
La tercera línea snmp-server view define el nombre de código que establece las ramas del árbol MIB snmpv3name, para que puedan ser consultadas por el grupo de usuarios snmpv3group. ISO, en lugar de definir estrictamente una sola rama, permite que el grupo de usuarios snmpv3group acceda a todos los objetos del árbol MIB del objeto de monitoreo.
La configuración equivalente del equipo Huawei (también en CLI) es la siguiente:
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
des56v3v3v3Después de configurar los dispositivos de red, es necesario verificar el acceso desde el servidor de monitoreo a través del protocolo SNMPv3; utilizaré snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 
Una herramienta más visual para consultar objetos OID específicos, utilizando archivos MIB, es snmpget:
![]()
Ahora pasemos a la configuración de un elemento de datos típico para SNMPv3, en el marco de la plantilla de Zabbix. Para simplificar y independizarme de MIB, usaré OID numéricos:

Utilizo macros personalizados en los campos clave, ya que serán iguales para todos los elementos de datos en la plantilla. Se pueden establecer dentro de la plantilla, si en su red todos los dispositivos de red tienen configuraciones SNMPv3 idénticas, o en el nivel del nodo de red, si las configuraciones SNMPv3 para diferentes objetos de monitoreo son distintas:

Tenga en cuenta que el sistema de monitoreo solo tiene el nombre de usuario y las contraseñas para la autenticación y el cifrado. El grupo de usuarios y el ámbito de los objetos MIB a los que se permite el acceso se definen en el objeto de monitoreo.
Ahora pasemos a llenar la plantilla.
Plantilla de encuesta en Zabbix
Una regla simple al crear cualquier plantilla de encuesta es hacerlas lo más detalladas posible:

Presto mucha atención al inventario para que trabajar con una red grande sea más fácil. Hablaremos de esto un poco más tarde, por ahora, los disparadores:

Para facilitar la visualización de los disparadores, he integrado macros del sistema en sus nombres {HOST.CONN}, para que en el panel de control en la sección de alertas se muestren no solo los nombres de los dispositivos, sino también las direcciones IP, aunque esto es más una cuestión de conveniencia que de necesidad. Para determinar la inaccesibilidad de un dispositivo, además de la solicitud echo habitual, utilizo la verificación de inaccesibilidad del nodo a través del protocolo SNMP, cuando el objeto está accesible a través de ICMP, pero no responde a las solicitudes SNMP. Esta situación puede ocurrir, por ejemplo, en caso de duplicación de direcciones IP en diferentes dispositivos, debido a configuraciones incorrectas de cortafuegos o configuraciones SNMP incorrectas en los objetos de monitoreo. Si solo se utiliza la verificación de disponibilidad de nodos a través de ICMP, en el momento de investigar incidentes en la red, puede que no haya datos de monitoreo disponibles, por lo que su llegada debe ser controlada.
Pasemos al descubrimiento de interfaces de red, que es la función de monitoreo más importante para el equipo de red. Dado que un dispositivo de red puede tener cientos de interfaces, es necesario filtrar las innecesarias para no saturar la visualización ni sobrecargar la base de datos.
Utilizo la función estándar de descubrimiento para SNMP, con una gran cantidad de parámetros detectables, para un filtrado más flexible:
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] 
Con tal detección, se pueden filtrar las interfaces de red por sus tipos, descripciones de usuario "description" y estados administrativos de los puertos. Los filtros y expresiones regulares para la filtración en mi caso son los siguientes:


Se excluirán las siguientes interfaces al detectarlas:
- apagadas manualmente (adminstatus<>1), gracias a IFADMINSTATUS;
- sin descripción textual, gracias a IFALIAS;
- que contienen el carácter *, gracias a IFALIAS;
- que son administrativas o técnicas, gracias a IFDESCR (en mi caso, en las expresiones regulares IFALIAS e IFDESCR se verifican con una sola expresión regular alias).
El patrón para la recolección de datos a través del protocolo SNMPv3 está casi listo. No profundizaremos en los prototipos de los elementos de datos para las interfaces de red, pasemos a los resultados.
Resultados de la monitorización
Primero, un inventario de una pequeña red:

Si se preparan plantillas para cada serie de dispositivos de red, se puede lograr una disposición conveniente para analizar los datos resumidos sobre el software actual, números de serie y la notificación de la llegada del personal de limpieza al servidor (debido a la baja disponibilidad). Mi lista de plantillas se presenta a continuación:

Y ahora, el panel principal de monitorización, con disparadores distribuidos por nivel de importancia:

Gracias a un enfoque integral a las plantillas para cada modelo de dispositivo en la red, se puede lograr que dentro de un único sistema de monitorización se organice una herramienta para predecir fallos y emergencias (con la presencia de sensores y métricas adecuadas). Zabbix es muy adecuado para la monitorización de infraestructuras de red, servidores y servicios, y la tarea de mantenimiento del equipo de red demuestra claramente sus capacidades.
Lista de fuentes utilizadas: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. Capítulo: SNMP Versión 3.
Fuente: habr.com
