🗂️ 🏂🏿 👨🏿‍🤝‍👨🏼 Zabbix-使用SNMPv3 TRAP，痛苦和绝望来监视OSPF邻居 👩🏾‍🤝‍👨🏼 🙌 ✌🏾

职权范围

有一个分布在不同地理位置的数据中心网络，其中有一个VRF汽车和一个不断变化的OSPF邻居列表。您需要跟踪它们：

状态，如果邻居状态不是FULL，则发出警报
数量，即如果邻居不见了，您还必须发出警报

一个监控系统已经存在-Zabbix 3.4，最好使用它，Linux OS 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都会在网络硬件上被删除。

是的，有一个解决方案-创建一个无数据触发器，确定：

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

我们在仪表板中看到：

 OSPF neighbor 192.168.192.168 missing data

基本上...可用

但是开箱即用，LLD仅检测默认VRF中的邻居。当然，可以使用SNMP上下文解决此问题，但是我完全不希望采用这种方式-我们需要遍历所有腺体，将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，将其传递给另一个守护程序，然后对其进行解析，并以所需的格式将其放入日志中，并且zabix已经读取该日志并决定下一步要做什么。某种程度上，它看起来比用手走路并在任何地方绘制SNMP上下文都容易得多，但是，让我们尝试一下。我们仔细阅读了监视文档，并了解到只有借助其帮助，才能进行任何配置，通常Zabbix会开玩笑-该文档仅描述了系统的功能和细微差别，以致于比讲授的更加混乱。尽管可以理解-该软件是免费的，但是您需要以某种方式赚钱，但是他们会在支持方面赚钱。互联网上有几篇文章介绍了一次或两次设置的方法，但是我无法从一篇文章改写到下一篇文章，我不得不从各种来源收集信息。这是所有的歌词，他们开车去做硬核。

我们配置铁网

在使用监控程序扭曲主机上的内容之前，我强烈建议您首先配置网络硬件，并确保TRAP确实从硬件到达服务器-最初，我没有检查它是否消耗了很多神经，精力和时间。我手上有一辆Cisco Nexus汽车，因此我将举例说明该系列。拥有Catalyst，ASR，ASA等产品的人-抱歉，我不是太阳，我不会加热所有人，请阅读有关如何自行配置的扩展坞，语法将相似，但有其细微差别。

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

将来很重要，在Zabbix中配置TRAP时，发送TRAP的地址必须等于Zabbix主机设置中接口的SNMP地址。

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

在authPriv模式（加密和身份验证）下，尽可能使用协议的版本3，配置起来似乎并不困难。忘记协议的版本1和版本2 –当由于这些协议版本中缺乏加密和本质上的身份验证而导致意外的人到达时，这只是时间问题（社区字符串以清晰的形式传输，而且，我经常看到它配置为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

我专门禁用了除OSPF以外的所有TRAP，因此，在诊断为什么某些功能不起作用时，我不必从调试中读取很多不必要的信息。

如何检查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陷阱接收器，而是出于个人和主观原因选择了SNMPTT。因此，码头说：

 1. snmptrapd receives a trap

必须从其配置开始，而不是立即爬升以在Zabbix面上创建Item。为什么这样做-您需要遵循TRAP的相同步骤。在上一节中，我们确保TRAP基本上来自一块铁，现在我们将确保至少它被第一个守护程序snmptrapd接受。 <lyric>我记得很久以前就设置了postfix + dovecot +其他功能。我闷闷了两周-在那儿，一个恶魔也接受了连接，另一个恶魔解析了这封信，第三个恶魔把它放在了队列中，第四个把它放到了用户的文件夹中，依此类推。所有这些都是因为我从中间开始，从头开始，从头开始进行调优，但是我必须从telnet到端口25并查看foxer的调试器</ lyric>

我们进入/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)

如果看不到，那么我们正在寻找原因。如果要具有相同的优美记录，而不是格式为1.3.6.1.2.1.14.10.1.6的一组OID，请在/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

有关更详细的信息，请阅读[here]（https://wiki.debian.org/SNMP），以最轻松的方式下载MIB文件并将其提供给SNMPd。

现在，我们加强身份验证，我们再次进入/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

为什么日志与Internet上许多文章中的日志不同？因为扩展坞说：“如果使用systemd参数PrivateTmp，则该文件不太可能在/ tmp中工作。”，如果事先警告，我不想再次进入rake，因此，我将立即更改为该文件的常规路径。

接下来，转到/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

这些陷阱组件是可以按$ 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

我们未在/etc/snmp/snmptt.conf配置中配置的那些TRAP将转到/var/log/snmptt/snmpttunknown.log日志，但只会从在同一配置中为其配置了正确用户和engineID的硬件进入。也就是说，TRAP将从左腺体默默地掉落，如果您想进行口头汇报和汇报，那么您在net-snmp上有一个异常健壮的基座，TRAP和INFORM之间的区别在那里仍然很好地描述了，展望未来，最好使用INFORM等。 k。那里有某种传递控制，但是它通过UDP而不是UDP起作用。

而且只有现在，我们才开始配置显示器。

Zabbix设定

首先，确保在/etc/zabbix/zabbix_server.conf配置中，将监视设置为正确的SNMPTT日志，并且Zabbix本身启动至少一个SNMP陷阱程序：

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

首先，我直接在主机上创建了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

我在上面写的内容-使用对您方便的任何格式，主要是要在正确的位置进行匹配。

创建触发器

邻居可能有几种状态：

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

邻居所处的状态完全不重要，如果此状态不是FULL，因为要进行诊断，您仍然必须动手，阅读日志，输入一些命令。因此，触发器将是一个触发器，并且仅当在TRAP中邻居的状态不是FULL时才会被激发。

在将模板挂在特定主机上之前，请确保为主机配置了具有正确IP地址的正确SNMP接口，否则梯形图将位于/var/log/snmptt/snmptt.log日志中，但是Zabbix不会将它们“绑定”到主机上。在这种情况下，在服务器/var/log/zabbix/zabbix_server.log的Zabbix日志中，将出现以下形式的消息：

 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

转到最新数据，请参见

扳机也起作用

现在放两个邻居

在仪表板中，我们看到发生了两个问题，这很好，甚至在配置了通知的情况下，即使有两个字母也会到达此主题。

一切都很棒，一切正常，这是最后的蛋糕。

绝望

现在，我们要抚养一个邻居。同时，这两个问题将立即在仪表板上消失。这不是错误，而是功能。测试模板时，我不小心注意到了这种细微差别。结果，如果几个邻居掉下来，然后其中一个邻居升起，或者即使一个邻居升起了（以前根本不存在），则监视将变为绿色。
当然，您可以用手配置Item来跟踪特定的邻居，仍然可以编写一些脚本，还可以从本文的开头返回SNMP上下文。还有一种想法是绘制一个脚本，该脚本将通过SSH / API传递到网络腺体，收集有关所有邻居的信息，进行“有效”转换，分析检查之间的差异，并在日志中写错什么，然后将日志馈送到监视器……这很困难。我想要最少的拐杖和习俗。如果您知道解决此问题的明智方法，或者认为我做错了所有事情，请再次在评论中询问，而在响应文章中询问。

UPD：我们的同事建议我们进行排序，并尝试使用SNMP上下文实施我们的计划。有需求，就会有供应。展望未来，我可以说-魔鬼并不那么可怕，我们走吧。
在一块铁网上，我们绘制了一条神奇的命令：

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

参数名称需要澄清
{snmp上下文名称}-将在请求中使用的SNMP上下文的名称。
我们从已配置的OSPF进程的配置中获取{protocol instance}和{vrf name}：

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

有人担心在进行了这样的设置后，我们将使用空上下文通过SNMP破坏已经配置的项，但是我检查了该设置仅影响通过OSPF-MIB的数据输出，而例如从IF-MIB部分中，所有内容都像以前一样使用空上下文继续返回。如果您没有Nexus，建议您再次检查这一点-行为可能会有所不同。

现在在Zabbix中扭曲模板。
您必须使用上下文创建新的发现规则：

新项目原型也具有上下文

还有两个触发器（第一个触发器），用于在邻居处于除FULL之外的任何状态时发出的警报：

第二个-如果邻居不见了：