Zabbix: monitoreo de vecinos de OSPF utilizando TRAMP SNMPv3, dolor y desesperación

Términos de referencia

Hay una red de centros de datos dispersos geográficamente con un automóvil VRF y una lista siempre cambiante de vecinos OSPF. Necesitas rastrearlos:

1. Estado, alarma si el estado vecino no está LLENO
2. Cantidad, es decir, si falta el vecino, también debe hacer una alarma

Ya existe un sistema de monitoreo: Zabbix 3.4, es deseable usarlo, Linux OS Debian 9.x

Intentamos con un chasquido

El protocolo está muy extendido, el sistema de monitoreo es conocido, probablemente no soy el primero que quiere resolver este problema, y ​​lo más probable es que ya haya sido resuelto.

Entramos en la búsqueda de "zabbix ospf" y el primer enlace lleva a la plantilla . La felicidad es lo que ahora: lo estoy importando, combinándolo según mis necesidades y todo estará bien.
Verificamos cómo funciona: todo parece estar bien, los estados son monitoreados, pero cuando el vecino entra en estado ABAJO, recibimos un mensaje informativo "muy" de Zabbix

No Such Instance currently exists at this OID 

e información

 The item is not discovered anymore and will be deleted in 29d 23h 57m (on 2018-08-19 at 08:52) 

Lo que sucedió, el problema es antiguo y conocido en los foros , cuando el vecino OSPF desaparece, entonces todos los OID asociados con él simplemente se eliminan en el hardware de la red.

Sí, hay una solución: crear un activador de nodata, ok crear:

 {Template - SNMPv3 - OSPF Discovery:ospfNbrState[{#SNMPVALUE}].nodata(120)}=0 

Vemos en el tablero de instrumentos:

 OSPF neighbor 192.168.192.168 missing data 

Básicamente ... utilizable

Pero fuera de la caja, LLD solo detecta vecinos del VRF predeterminado. Por supuesto, esto se puede resolver usando el contexto SNMP , pero de alguna manera no quería seguir este camino: tuvimos que pasar por todos los elementos de hierro, inyectar un contexto en cada proceso OSPF o VRF, luego hacer copias de Discovery para cada contexto en nuestra plantilla, en general es un poco demasiado alboroto y al agregar nuevos procesos OSPF, debe cambiar algo en varios lugares. Por supuesto, puede estar rodeado de scripts y, a través de la API de Zabbix, todo esto se puede cambiar, pero no quería una costumbre especial, pero quería usar solo la funcionalidad integrada en Zabbix al máximo. Hay una mención de cierto CISCO-CONTEXT-MAPPING-MIB, del cual puede extraer toda la correspondencia entre contextos y OSPF / VRF, pero no descubrí cómo sujetar este diseño a LLD. Si alguien sabe cocinar Zabbix tan bien, entonces bienvenido a los comentarios, y preferiblemente a un artículo separado completo.

Intentamos desde el segundo ataque

Después de un par de horas de búsqueda en Internet de pistas en foros y contenedores de memoria, surgió un tema sobre SNMP TRAP: es cuando no interrogamos al trozo de hierro, pero el trozo de hierro envía información sobre cómo cambiar algo. Sí, y el soporte de la campaña para estas cosas está en nuestro sistema de monitoreo listo para usar , el equipo también puede de inmediato y solo para mi caso.

Desde las primeras líneas, la documentación de monitoreo fue confundida por una larga lista:

 The workflow of receiving a trap: 1. snmptrapd receives a trap 2. snmptrapd passes the trap to SNMPTT or calls Perl trap receiver 3. SNMPTT or Perl trap receiver parses, formats and writes the trap to a file 4. Zabbix SNMP trapper reads and parses the trap file 5. For each trap Zabbix finds all “SNMP trapper” items with host interfaces matching the received trap address. Note that only the selected “IP” or “DNS” in host interface is used during the matching. 6. For each found item, the trap is compared to regexp in “snmptrap[regexp]”. The trap is set as the value of all matched items. If no matching item is found and there is an “snmptrap.fallback” item, the trap is set as the value of that. 7. If the trap was not set as the value of any item, Zabbix by default logs the unmatched trap. (This is configured by “Log unmatched SNMP traps” in Administration → General → Other.) 

Es decir, un demonio acepta TRAP, lo pasa a otro demonio, lo analiza, lo coloca en el registro con el formato deseado, y el zabix ya lee el registro y decide qué hacer a continuación. De alguna manera, parece nunca más fácil que incluso caminar con las manos y dibujar un contexto SNMP en todas partes, pero bueno, intentemos. Leemos cuidadosamente el documento de monitoreo y entendemos que solo con su ayuda no se puede configurar nada, en general Zabbix tiene una broma de este tipo: la documentación describe las capacidades y los matices del sistema de manera tan mínima que es más confuso de lo que se enseña. Aunque pueden entenderse, el software es gratuito, pero de alguna manera necesita ganar dinero, pero ellos ganan dinero en soporte. Hay artículos en Internet con una descripción de cómo configurar esto una o dos veces , pero no pude configurarlo de un artículo a otro, tuve que recopilar información de varias fuentes poco a poco. Esta es toda la letra, condujeron a hacer hardcore.

Configuramos una red de hierro

Antes de girar algo en el host con el monitoreo, le recomiendo que primero configure el hardware de la red y se asegure de que TRAP realmente llegue del hardware al servidor; al principio, no verifiqué que bebiera muchos nervios, sangre y tiempo. Tengo un automóvil Cisco Nexus a mano, así que daré ejemplos para esta serie. Quien tenga Catalyst, ASR, ASA, etc., lo siento, no soy el sol, no calentaré a todos, lea los muelles sobre cómo configurar esto usted mismo, la sintaxis será similar, pero con sus propios matices.

 snmp-server contact noc@example.com snmp-server location Room1 snmp-server source-interface traps loopback1 

Es importante en el futuro, al configurar TRAP en Zabbix, que la dirección desde la cual se envía TRAP sea igual a la dirección SNMP de la interfaz en la configuración del host en Zabbix.

 snmp-server user Zabbix network-operator auth sha string priv aes-128 string 

Utilice la versión 3 del protocolo siempre que sea posible, en modo authPriv (cifrado y autenticación), no es tan difícil de configurar como parece. Olvídate de la versión 1 y la versión 2 del protocolo: cuando llega una persona inesperada debido a la falta de cifrado y esencialmente de autenticación en estas versiones del protocolo, es solo cuestión de tiempo (la cadena de la comunidad se transmite en forma clara, además, regularmente veo que está configurada pública / privada). El parámetro operador de red le permite otorgar al usuario permisos de solo lectura.

 snmp-server host 192.168.192.168 traps version 3 priv Zabbix snmp-server host 192.168.192.168 use-vrf default snmp-server host 192.168.192.168 source-interface loopback1 no snmp-server enable traps ospf lsa snmp-server enable traps ospf no snmp-server enable traps entity entity_mib_change no snmp-server enable traps entity entity_module_status_change no snmp-server enable traps entity entity_power_status_change no snmp-server enable traps entity entity_module_inserted no snmp-server enable traps entity entity_module_removed no snmp-server enable traps entity entity_unrecognised_module no snmp-server enable traps entity entity_fan_status_change no snmp-server enable traps entity entity_power_out_change no snmp-server enable traps link linkDown no snmp-server enable traps link linkUp no snmp-server enable traps link extended-linkDown no snmp-server enable traps link extended-linkUp no snmp-server enable traps link cieLinkDown no snmp-server enable traps link cieLinkUp no snmp-server enable traps link connUnitPortStatusChange no snmp-server enable traps bfd session-up no snmp-server enable traps link delayed-link-state-change no snmp-server enable traps bfd session-down no snmp-server enable traps rf redundancy_framework no snmp-server enable traps license notify-license-expiry no snmp-server enable traps license notify-no-license-for-feature no snmp-server enable traps license notify-licensefile-missing no snmp-server enable traps license notify-license-expiry-warning no snmp-server enable traps upgrade UpgradeOpNotifyOnCompletion no snmp-server enable traps upgrade UpgradeJobStatusNotify no snmp-server enable traps rmon risingAlarm no snmp-server enable traps rmon fallingAlarm no snmp-server enable traps rmon hcRisingAlarm no snmp-server enable traps rmon hcFallingAlarm no snmp-server enable traps entity entity_sensor no snmp-server enable traps generic coldStart no snmp-server enable traps generic warmStart 

Inhabilité específicamente todo TRAP excepto OSPF, de modo que al diagnosticar por qué algo no funciona, no tuve que leer mucha información innecesaria de la depuración.

Cómo verificar si TRAP funciona es muy simple: debe romper algo. Iniciamos el sniffer en el host con monitoreo:

 root@dc-zbx:~# tcpdump -i bond0 udp port 162 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes 

Encontramos en una pieza de hierro vecinos vivos:

 SW# show ip ospf neighbors vrf all OSPF Process ID 10 VRF default Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.0.242 1 FULL/ - 01:47:17 172.17.0.10 Vlan1427 192.168.0.222 1 FULL/ - 18w1d 172.17.0.6 Vlan1426 192.168.1.149 1 FULL/ - 5w0d 172.17.0.30 Vlan1473 192.168.1.146 1 FULL/ - 3d00h 172.17.0.58 Vlan1404 OSPF Process ID 100 VRF OSPF100 Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.1.149 1 FULL/ - 5w0d 172.17.0.34 Vlan1474 192.168.0.220 1 FULL/ - 13w3d 172.17.0.54 Vlan1479 192.168.0.240 1 FULL/ - 13w3d 172.17.0.46 Vlan1477 192.168.1.146 1 FULL/ - 3d00h 172.17.0.62 Vlan1405 OSPF Process ID 200 VRF Dia Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.65.0.252 1 FULL/ - 17w2d 172.17.0.18 Vlan1450 172.17.0.26 1 FULL/ - 17w0d 172.17.0.26 Vlan1452 OSPF Process ID 216 VRF Dev Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.255.255.94 1 FULL/ - 18:59:59 10.216.0.73 Vlan1641 10.216.0.82 1 FULL/ - 18:59:54 10.216.0.82 Vlan1643 

Y dejar caer a alguien

 interface vlan 1643 shutdown 

Vemos en el sniffer:

 11:08:20.001942 IP 192.168.192.169.22095 > dc-zbx.example.com.snmp-trap: F=ap U="Zabbix" [!scoped PDU]39_d1_7c_19_b3_d9_f8_31_32_8e_c9_39_c2_3a_db_d8_28_26_c6_0b_01_55_b6_fa_5e_f5_38_66_f9_6f_3f_c0_98_cb_57_93_5a_50_8e_50_90_79_f3_9b_ec_ec_d7_9f_e8_ac_f6_fd_79_ac_95_ff_71_73_32_70_52_66_a5_7d_b3_c4_39_d0_1c_7f_a6_38_ea_d7_61_c0_2f_12_ee_db_d9_07_40_8c_a8_48_57_e9_e5_56_12_3f_ec_f9_34_65_09_96_86_f6_d2_93_06_45_fa_95_ea_36_5a_82_2f_30_8f_02_03_59_07_5f_d8_a6_1c_f2_5a_be_7d_09_15_ef_05_00_83_fd_ea_ac_2a_3b_86_0f_86_e5_3b_93_3a_68_6d_33_99_e2_46_2b_9d_6a_1e_5d_9e_d9_93_56_51_5e_ff_9e_77_4c_cb 

Si no vio nada en el sniffer, diagnostíquelo, porque de lo contrario no hay razón para continuar, simplemente no entenderá en qué etapa algo no funciona para usted.
Si no hay una pieza de hierro a mano o la producción no se puede tocar, entonces se puede generar TRAP desde cualquier otro automóvil, por ejemplo, así:

 snmptrap -v 1 -c neveruseme 127.0.0.1 '.1.3.6.1.6.3.1.1.5.3' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.3 s "teststring000" snmptrap -v3 -l authPriv -u Zabbix -a SHA -A abyrvalg -x AES -X pechka -e 0x8000000001020305 192.168.192.168 0 linkUp.0 

Configurar SNMPd, SNMPTRAPd, SNMPTT

Necesitaremos paquetes en el sistema:

 apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt 

No me concentré en el receptor de trampa Perl, pero elegí SNMPTT por razones personales y subjetivas. Entonces, el muelle dice:

 1. snmptrapd receives a trap 

Es necesario comenzar con su configuración, y no subir de inmediato para crear un objeto en la cara de Zabbix. ¿Por qué? Necesitas subir los mismos pasos que TRAP. En la sección anterior, nos aseguramos de que TRAP básicamente llegue de una pieza de hierro, ahora nos aseguraremos de que al menos sea aceptado por el primer demonio: snmptrapd. <lyric> Recuerdo haber configurado postfix + dovecot + algo más allí hace mucho tiempo. Y me enfurruñé durante unas dos semanas; allí también, un demonio acepta la conexión, el otro analiza la carta, el tercero la pone en la cola, el cuarto en la carpeta para el usuario, y así sucesivamente, y no tuve éxito. Y todo porque sintonicé desde el medio, desde el final, desde el principio, pero tuve que comenzar con telnet hasta el puerto 25 y ver el depurador del foxer </ lyric>

Subimos a /etc/snmp/snmptrapd.conf y lo eliminamos, pero más bien comentamos todo lo que no entendemos y no nos interesa, dejamos una línea

 disableAuthorization yes 

Detener el servicio

 systemctl stop snmptrapd.service 

Ejecutar en modo manual

 root@dc-zbx:~# snmptrapd -f -Lo NET-SNMP version 5.7.3 AgentX subagent connected NET-SNMP version 5.7.3 

Nuevamente, intente romper OSPF como en el ejemplo anterior y vea:

 2018-07-20 11:38:38 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355817272) 156 days, 22:09:32.72 SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74 OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0 OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrState = INTEGER: down(1) 

Si no vemos, entonces estamos buscando la razón. Si desea tener los mismos hermosos registros, y no un conjunto de OID de la forma 1.3.6.1.2.1.14.10.1.6, agregue lo siguiente a /etc/snmp/snmp.conf:

 mibs +OSPF-MIB mibs +OSPF-TRAP-MIB mibs +OSPFV3-MIB mibdirs +/usr/share/snmp/mibs/ietf/ 

Y distorsionar SNMPd

 systemctl restart snmpd.service 

En más detalle, puede leer cómo descargar archivos MIB con el menor dolor y alimentarlos a su SNMPd [aquí] (https://wiki.debian.org/SNMP).

Ahora ajustamos la autenticación, volvemos a subir en /etc/snmp/snmptrapd.conf

 traphandle default snmptthandler #disableAuthorization yes # 192.168.192.169 createUser -e 0x80000009038d604a6a82a3 Zabbix SHA string AES authuser log,execute,net Zabbix 

-e 0x80000009038d604a6a82a3 es el ID del motor, se puede ver en el hardware de la red:

 SW# sh snmp engineID Local SNMP engineID: [Hex] 80000009038F604D6A82A1 [Dec] 128:040:000:109:003:140:096:079:106:131:160 

Estamos repitiendo el experimento nuevamente, pero ahora todavía estamos captando una depuración sobre USM:

 root@dc-zbx:~# snmptrapd -f -Lo -Dusm registered debug token usm, 1 usmUser: created a new user Zabbix at 80 00 00 09 03 8F 60 4F 6B 82 A5 NET-SNMP version 5.7.3 AgentX subagent connected NET-SNMP version 5.7.3 usm: USM processing begun... usm: match on user Zabbix usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 ) usm: match on user Zabbix usm: Verification succeeded. usm: USM processing completed. 2018-07-20 11:50:07 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355886163) 156 days, 22:21:01.63 SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74 OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0 OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrState = INTEGER: down(1) 

Si en esta etapa ve errores de autorización en la depuración, verifique cuidadosamente el ID del motor y que los usuarios creados en el hardware coincidan con los que dibujamos en la configuración /etc/snmp/snmptrapd.conf. Por cierto, sí, para cada pieza de hierro tendrá que crear su propio usuario con su ID de motor, o hacer lo mismo en todas las piezas de hierro con sus manos, si las piezas de hierro permiten que esto se haga.

Puedo ver la línea en la depuración:

 usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 ) 

¿Por qué no lo entendí, aunque con todo esto se acepta TRAP y se procesa más adelante? Si sabes lo que hice mal, por favor comenta.

Ahora tomamos SNMPTT: tiene dos ini y conf config. En el primero determinamos los parámetros del demonio en sí, en el segundo determinamos los parámetros para recibir y procesar cada escalera específica.

Subimos al archivo /etc/snmp/snmptt.ini y dibujamos lo siguiente:

 mode = daemon net_snmp_perl_enable = 1 date_time_format = %Y %m %d %H:%M:%S 

El formato de la fecha y la hora es una cuestión de negocios; lo más importante, use el mismo en todas partes.

 log_file = /var/log/snmptt/snmptt.log log_system_file = /var/log/snmptt/snmpttsystem.log unknown_trap_log_enable = 1 unknown_trap_log_file = /var/log/snmptt/snmpttunknown.log 

¿Por qué el registro no es el mismo que en muchos artículos en Internet? Debido a que el dock decía: "Si se usa el parámetro systemd PrivateTmp, es poco probable que este archivo funcione en / tmp", no quiero volver al rastrillo una vez más si se me advierte de antemano, por lo que cambiaré inmediatamente a la ruta normal del archivo.

Luego, vaya a /etc/snmp/snmptt.conf, elimine todo lo que no necesitamos y / o no entendemos, solo dejamos esto:

 EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5 

De esta forma, porque Zabbix esperará tal formato en el registro. De dónde provienen $ 2 y $ 5, puede averiguar si mira el formato de mensaje TRAP , busque:

 Object ospfNbrStateChange OID 1.3.6.1.2.1.14.16.2.2 MIB OSPF-TRAP-MIB ; Trap Components ospfRouterId ospfNbrIpAddr ospfNbrAddressLessIndex ospfNbrRtrId ospfNbrState 

Estos componentes de trampa son los parámetros que se pueden insertar en el formato de registro en el orden de $ 1, $ 2 ...

Durante el enfrentamiento con todo esto, noté que después de cambiar la configuración de SNMPTT, es como si los cambios no se aplicaran. Resultó que después de su cambio era necesario reiniciar no snmptt.serivce, sino snmpd.service: este matiz decente bebió mi sangre y mis nervios durante la depuración.

Comprueba que tienes todos los demonios ejecutándose:

 systemctl status snmpd snmptrapd snmptt 

Si todo está bien, intente nuevamente romper OSPF y vaya al registro /var/log/snmptt/snmptt.log, se verá así:

 2018 07 19 15:10:52 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down 2018 07 19 15:12:28 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart 2018 07 19 15:12:34 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to full 2018 07 19 15:22:41 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down 2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart 

Esos TRAPs que no configuramos en la configuración /etc/snmp/snmptt.conf irán al registro /var/log/snmptt/snmpttunknown.log, pero solo desde el hardware para el cual el usuario correcto y el ID de motor están configurados en la misma configuración. Es decir, desde las glándulas izquierdas, las TRAP se dejarán caer silenciosamente, si desea matan y un informe, entonces aquí tiene un muelle inusualmente sano en net-snmp, la diferencia entre TRAP e INFORM todavía está bien descrita allí, mirando hacia el futuro, es mejor usar INFORM, etc. k. hay algún tipo de control de entrega allí, pero funciona a través de UDP sobre UDP.

Y solo ahora subimos para configurar nuestro monitor.

Configuración de Zabbix

En primer lugar, asegúrese de que en la configuración /etc/zabbix/zabbix_server.conf la supervisión esté configurada en el registro SNMPTT correcto y que Zabbix inicie al menos un capturador SNMP:

SNMPTrapperFile=/var/log/snmptt/snmptt.log
StartSNMPTrapper=1

Para empezar, creé un elemento directamente en el host, para que sea más rápido y fácil capturar efectos especiales, aquí escribiré de inmediato cómo crear una plantilla, porque son las plantillas las que deben usarse siempre que sea posible. Te mostraré las imágenes, el regalo gratuito de copiar y pegar ha terminado, pero pintaré los lugares a los que debes prestar atención.

Crea una plantilla:



Aquí solo damos un nombre cuerdo

Crear artículo



Importante: la clave debería ser así, lo que se indica entre corchetes es lo que Zabbix buscará en el registro, configuramos el formato de registro en /etc/snmp/snmptt.conf y escribimos allí:

 EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5 

En realidad en el registro, esta es la palabra mágica "OSPF" y aparece:

 2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart 

El formato de fecha que definimos en la configuración /etc/snmp/snmptt.ini:

 date_time_format = %Y %m %d %H:%M:%S 

Lo que escribí anteriormente: use cualquier formato que sea conveniente para usted, lo principal es que coincida en los lugares correctos.

Crear un disparador



Un vecino puede tener varios estados :

 1 : down 2 : attempt 3 : init 4 : twoWay 5 : exchangeStart 6 : exchange 7 : loading 8 : full 

No importa en absoluto en qué tipo de estado se encuentre el vecino, si este estado no es COMPLETO, porque para diagnosticar esto, aún debe ir al trozo de hierro, leer los registros e ingresar algunos comandos. Por lo tanto, el disparador será uno y se excitará solo cuando en TRAP el estado del vecino no sea FULL.

Antes de colgar la plantilla en un host específico, asegúrese de que el host esté configurado con la interfaz SNMP correcta con la dirección IP correcta; de lo contrario, las escaleras estarán en el registro /var/log/snmptt/snmptt.log, pero Zabbix no las vinculará al host. En este caso, en el registro de Zabbix del servidor /var/log/zabbix/zabbix_server.log habrá un mensaje de la forma:

 19972:20180720:091722.896 unmatched trap received from "192.168.192.169": 2018 07 20 09:17:21 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - OSPF neighbor with IP addr 10.64.0.10 changed state to exchangeStart 

Vaya a Últimos datos, vea



Trigger también funcionó



Ahora pon dos vecinos



En el panel, vemos que ocurrieron dos problemas, esto es bueno, e incluso llegarán dos cartas sobre este tema con la notificación configurada.

Todo es genial, todo funciona, y aquí está la guinda del pastel al final.



UPD: nuestros colegas nos aconsejaron resolverlo e intentar implementar nuestros planes utilizando contextos SNMP . Hay demanda, habrá oferta. Mirando hacia el futuro, puedo decir: el diablo no es tan terrible, vámonos.
En una pieza de red de hierro dibujamos un comando mágico:

snmp-server context {snmp context name} instance {protocol instance} vrf {vrf name}

Los nombres de los parámetros necesitan aclaración
{nombre de contexto snmp}: el nombre del contexto SNMP que se utilizará en las solicitudes.
{instancia de protocolo} y {nombre de vrf} tomamos de la configuración del proceso OSPF configurado:

router ospf {protocol instance}
..
vrf {vrf name}
..

Existía el temor de que después de tales configuraciones rompamos el Elemento ya configurado a través de SNMP con un contexto vacío, pero verifiqué que la configuración afecta solo a la salida de datos a través de OSPF-MIB, mientras que, por ejemplo, desde la sección IF-MIB, todo se devuelve como antes con un contexto vacío. Si no tiene Nexus, le recomiendo revisar este punto una vez más; es probable que el comportamiento sea diferente.

Ahora tuerza la plantilla en Zabbix.
Debe crear una nueva regla de descubrimiento con el contexto:



Nuevo prototipo de artículo también con contexto



Y dos disparadores, el primero, para la alarma si el vecino está en cualquier estado, excepto COMPLETO:



y el segundo, si falta el vecino: