Zabbix — мониторинг OSPF соседей средствами SNMPv3 TRAPs, боль и отчаяние

Техническое задание

Имеется сеть географически разбросанных дата-центров с вагоном VRF и постоянно изменяющимся списком OSPF соседей. Необходимо отслеживать их:

1. Состояние, делать alarm если состояние соседа не FULL
2. Количество, то есть если сосед пропал, нужно также делать alarm

Система мониторинга уже есть — Zabbix 3.4, желательно использовать именно её, ОС Linux Debian 9.x

Пробуем с наскока

Протокол распространенный, система мониторинга известная, наверняка я не первый кто хочет решить эту задачу и скорее всего она уже решена.

Вколачиваем в поиск «zabbix ospf» и первая же ссылка ведет на шаблон. Счастье то какое — сейчас я его импортирую, причешу под свои нужды и всё будет оки доки.
Проверяем как работает — вроде все хорошо, состояния отслеживаются, но вот когда сосед уходит в состояние DOWN, мы получаем от Zabbix «очень» информативное сообщение

No Such Instance currently exists at this OID

и инфо

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

Что произошло — проблема старая и известная на форумах — когда пропадает OSPF сосед, то все OID, связанные с ним, просто удаляются на сетевом железе.

Да, решение есть — создать триггер nodata, ок создаем:

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

Видим в дашборде:

OSPF neighbor 192.168.192.168 missing data

В принципе… юзабельно

Но из коробки LLD обнаруживает только соседей из default VRF. Конечно, это можно порешать с помощью SNMP context, но как-то совсем не захотелось идти таким путем — это надо по всем железкам пройтись, каждому OSPF процессу или VRF вколотить контекст, потом в шаблоне сделать копии Discovery для каждого контекста свою, в целом многовато возни и при добавлении новых OSPF процессов надо в нескольких местах что-то менять. Можно конечно обложиться скриптами и через Zabbix API всё это менять, но не хотелось особого кастома, а хотелось по максимуму использовать только встроенную в Zabbix функциональность. Есть упоминание о некоем CISCO-CONTEXT-MAPPING-MIB, из которого можно выдернуть все соответствия контекстов и OSPF/VRF, но как эту конструкцию прикрутить к LLD и моему случаю я не сообразил. Если кто-то умеет так круто готовить Zabbix, то добро пожаловать в комментарии, а лучше в полноценную отдельную статью.

Пробуем со второго наскока

После пары часов поисков в интернетах по намекам на форумах и из закромов памяти всплыла тема про SNMP TRAP — это когда не мы опрашиваем железку, а железка сама присылает информацию об изменении чего-либо. Да и походу поддержка этого добра есть в нашей системе мониторинга из коробки, оборудование тоже умеет сразу и как раз для моего случая.

С первых строк документация по мониторилке смутила длинным списком:

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.)

То есть один демон принимает TRAP, передает его другому демону, тот его парсит, кладет в лог с нужным форматом и забикс уже читает лог и принимает решение что делать дальше. Как-то уже выглядит ни разу не проще чем даже руками пройтись и везде нарисовать SNMP context, но да ладно, попробуем. Читаем внимательно доку по мониторилке и понимаем что только с её помощью ничего настроить не получится, вообще есть у Zabbix такой прикол — документация настолько минимально описывает возможности и нюансы системы, что скорее больше запутывает чем учат. Хотя их можно понять — софтина бесплатная, а деньги как-то надо зарабатывать, вот на поддержке и зарабатывают. В интернетах встречаются статьи с описанием как это настроить раз два, но ни по одной статье у меня не получилось настроить от и до, пришлось собирать информацию из разных источников по крупицам. Это всё лирика, погнали делать хардкор.

Настраиваем сетевую железку

Перед тем как что-то крутить на хосте с мониторилкой, настоятельно рекомендую первым делом настроить сетевую железку и убедиться что TRAP реально прилетает от железки на сервер — поначалу я этого не проверил, что выпило много нервов, крови и времени. У меня под рукой вагон Cisco Nexus, так что примеры буду приводить для этой серии. У кого Catalyst, ASR, ASA и прочее — извиняйте, я не солнышко, всех не обогрею, читайте доки как это настроить сами, синтаксис будет похож, но со своими нюансами.

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

Важно в дальнейшем при настройке TRAP в Zabbix, чтобы адрес с которого отправляется TRAP был равен адресу SNMP интерфейса в настройках хоста в Zabbix.

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

Используйте 3 версию протокола везде где только можно, в режиме authPriv (шифрование и аутентификация), это не так сложно настроить как кажется. Забудьте про 1 и 2 версии протокола — когда вам прилетит нежданчик по причине отсутствия шифрования и по сути аутентификации в этих версиях протокола — просто вопрос времени (community строка в них передается в открытом виде, более того регулярно вижу что это настроено public/private). Параметр network-operator позволяет дать права юзеру только на чтение.

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

Я специально отключил все TRAP кроме OSPF, чтобы при диагностике почему что-то не работает, мне не пришлось вычитывать из дебага много лишней информации.

Как проверить работают ли TRAP — очень просто — надо что-нибудь сломать. Стартуем снифер на хосте с мониторингом:

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

Находим на железке живых соседей:

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 

И уроним кого-нибудь

interface vlan 1643
  shutdown

Видим в снифере:

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

Если вы в снифере ничего не увидели, диагностируйте, потому что иначе смысла продолжать дальше никакого не будет, вы просто не поймете на каком из этапов у вас что-то не работает.
Если под рукой нет железки или нельзя трогать продакшен, то TRAP можно сгенерировать с любой другой тачки, например вот так:

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

Настройка SNMPd, SNMPTRAPd, SNMPTT

Нам понадобятся в системе пакеты:

apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt

Я не стал ориентироваться на Perl trap receiver, а выбрал SNMPTT по личным и субъективным причинам. Итак, в доке написано:

1. snmptrapd receives a trap

Начинать надо именно с его настройки, а не лезть сразу создавать Item в морде Zabbix. Почему так — нужно подниматься по тем же ступенькам, что идёт TRAP. В предыдущем разделе мы убедились что TRAP в принципе прилетает с железки, теперь мы будем добиваться того, чтобы он хотя бы был принят первым демоном — snmptrapd. <лирика> Помнится давно настраивал postfix+dovecot+еще чего-то там. И промудохался я недели две — там тоже один демон принимает коннект, другой парсит письмо, третий кладет его в очередь, четвертый в папку к юзеру и так далее, и у меня ничего не получалось. А всё потому, что настраивал то с середины, то с конца, то с начала, а надо было начать с телнета на 25 порт и просмотра дебага лисенера</лирика>

Лезем в /etc/snmp/snmptrapd.conf и удаляем, а лучше комментируем там всё что нам не понятно и не интересно, оставляем одну строку

disableAuthorization yes

Стопаем сервис

systemctl stop snmptrapd.service

Запускаем в ручном режиме

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

Снова пробуем сломать OSPF как в примере выше и видим:

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)

Если не видим, то ищем причину почему. Если вы хотите, чтобы у вас были такие же красивые записи, а не набор OID вида 1.3.6.1.2.1.14.10.1.6, то в /etc/snmp/snmp.conf добавьте следующее:

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

И передерните SNMPd

systemctl restart snmpd.service 

Более подробно как с наименьшей болью скачать MIB файлы и скормить их вашему SNMPd можно прочитать [тут](https://wiki.debian.org/SNMP).

Теперь прикрутим аутентификацию, лезем снова в /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 — это engineID, его можно посмотреть на сетевой железке:

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

Снова повторяем эксперимент, но теперь еще ловим дебаг касательно 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)

Если на этом этапе вы видите ошибки авторизации в дебаге, внимательно проверяйте engineID и что созданные на железке пользователи совпадают с теми, что мы нарисовали в конфиге /etc/snmp/snmptrapd.conf. Кстати да, для каждой железки придется создавать своего пользователя со своим engineID, или руками сделать его одинаковым на всех железках, если железки такое позволят сделать.

У меня в дебаге видно строчку:

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

Почему так я не понял, хотя при всем этом TRAP принимается и попадает на дальнейшую обработку. Если знаете что я сделал не так, прошу в комментарии.

Теперь беремся за SNMPTT — у него два конфига ini и conf. В первом определяем параметры работы самого демона, во втором определяем параметры получения и обработки каждого определённого трапа.

Лезем в файл /etc/snmp/snmptt.ini и рисуем следующие вещи:

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

Формат даты и времени дело хозяйское, главное используйте везде одинаковый.

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

Почему лог не такой как во многих статьях в интернетах? Потому что в доке было сказано «If systemd parameter PrivateTmp is used, this file is unlikely to work in /tmp.», не хочу лишний раз вставать на грабли, если об этом заранее предупреждают, так что меняю сразу на нормальный путь до файла.

Далее идем в /etc/snmp/snmptt.conf, убираем всё что нам не нужно и/или не понятно, оставляем только это:

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

В таком виде потому, что Zabbix будет ожидать в логе именно такой формат. Откуда берутся $2 и $5 можно узнать если посмотреть формат TRAP сообщения, глядим:

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

Вот эти Trap Components и есть параметры которые можно пихать в формат лога по порядку $1, $2…

В ходе разборок со всем этим добром я заметил что после изменения настроек SNMPTT, как будто изменения не применяются. Оказалось что после их изменения надо рестартовать не snmptt.serivce, а snmpd.service — этот нюанс прилично попил моей крови и попилил нервов во время дебага.

Проверьте что у вас все демоны запущены:

systemctl status snmpd snmptrapd snmptt

Если всё ок, пробуем снова сломать OSPF и идем в лог /var/log/snmptt/snmptt.log, будет подобное:

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

Те TRAP, которые мы не настроили в конфиге /etc/snmp/snmptt.conf попадут в лог /var/log/snmptt/snmpttunknown.log, но только от той железки, для которой настроен правильный юзер и engineID в этом же конфиге. То есть от левых железок TRAP будут просто silently dropped, если хочется матана и разбора полетов, то вам сюда — на редкость вменяемая дока по net-snmp, там еще неплохо описано различие между TRAP и INFORM, забегая вперед, лучше использовать INFORM, т. к. там какой-никакой контроль доставки есть, а SNMP он же по UDP работает.

И только теперь лезем настраивать нашу мониторилку.

Настройка Zabbix

Первым делом убедитесь, что в конфиге /etc/zabbix/zabbix_server.conf мониторилка натравлена на правильны лог SNMPTT и сам Zabbix запускает хотя бы один SNMP Trapper:

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

Для начала я создавал Item прямо на хосте, чтобы быстрее и проще ловить спецэффекты, сюда же напишу сразу как создать Template, потому что именно шаблонами надо пользоваться всегда когда это возможно. Покажу картинками, халява копи-пастинга закончилась, но покрашу места на которые нужно обратить внимание.

Создаем шаблон:



Тут просто даем вменяемое имя

Создаем Item



Важно — ключ должен быть таким, то, что указано в квадратных скобках это то, что будет искать Zabbix в логе, формат лога мы настраивали в /etc/snmp/snmptt.conf и писали там:

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

Собственно в логе это волшебное слово «OSPF» и появляется:

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

Формат даты мы определяли в конфиге /etc/snmp/snmptt.ini:

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

О чем я и писал выше — используйте любой удобный вам формат, главное чтобы он совпадал в нужных местах.

Создаем Trigger



Состояний у соседа может быть несколько:

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

Вообще не принципиально в каком именно состоянии находится сосед, если это состояние не FULL, т. к. чтобы это продиагностировать, придется всё-равно идти на железку, читать логи, вводить какие-то команды. Так что триггер будет один и будет возбуждаться только когда в TRAP состояние соседа не FULL.

Прежде чем повесить шаблон на конкретный хост, убедитесь, что у хоста настроен корректный SNMP интерфейс с правильным IP адресом, иначе трапы будут в логе /var/log/snmptt/snmptt.log, но Zabbix их «не привяжет» к хосту. В этом случае в логе Zabbix сервера /var/log/zabbix/zabbix_server.log будет сообщение вида:

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

Идем в Latest data, видим



Триггер тоже сработал



Теперь положим двух соседей



В дашборде видим что случилось две проблемы, это хорошо, и даже два письма прилетит на эту тему при настроенном оповещении.

Всё здорово, всё работает, а вот и вишенка на торте в завершении.



UPD: коллеги по цеху посоветовали таки разобраться и попробовать реализовать задуманное с использованием SNMP contexts. Есть спрос, будет и предложение. Забегая вперед могу сказать — не так страшен черт, поехали.
На сетевой железке рисуем волшебную команду:

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

Имена параметров требуют пояснений
{snmp context name} — имя SNMP контекста, который будем использовать в запросах.
{protocol instance} и {vrf name} берем из конфига настроенного OSPF процесса:

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

Было опасение, что после таких настроек у нас сломаются уже настроенные Item по SNMP с пустым контекстом, однако проверил — настройка затрагивает только отдачу данных по OSPF-MIB, при этом например из раздела IF-MIB всё продолжает отдаваться как и раньше с пустым контекстом. Если у вас не Nexus, рекомендую проверить этот момент лишний раз — вполне вероятно что поведение будет отличаться.

Теперь подкрутим шаблон в Zabbix.
Необходимо создать новое правило Discovery с указанием контекста:



Новый Item prototype тоже с указанием контекста



И два триггера — первый — для алярма в случае если сосед в любом состоянии кроме FULL:



и второй — если сосед пропал: