OpenNMS SNMP陷阱停止工作-如何进一步排除故障

Question

大约5天前，Ubuntu 18.04.1 LTS上的OpenNMS Horizo​​n 22.02停止接受来自网络元素的陷阱。据我所知，没有对配置或底层操作系统进行任何更改。

大约有125个网络元素（均为思科）正在发送陷阱。

到目前为止，我已经检查了以下内容：

• tcpdump显示陷阱进入端口162上的接口
• 为trapd.log打开调试，并且来自网络元素的传入陷阱不会创建任何日志条目
• 从本地主机通过send-trap.pl发送的陷阱创建了一直流向事件的陷阱
• 在本地主机或另一台主机上使用snmptrap发送的陷阱会创建日志条目，这些条目一直流到事件。另一台主机正在使用与网络元素所使用的相同的接口。
• ss -lnpu sport =：162显示打开的UPD“ UNCONN”
• sudo lsof -i：162显示了单个侦听器Java进程
• 启动trapd似乎在日志中未显示任何警告
• 我已验证ufw和iptables已关闭
• 我已将OpenNMS更新为22.04，并毫不费力地更新了Ubunutu
• 多次重新启动OpenNMS ...
• 在基于this的service-configuration.xml中，我在星号之后移动了Trapd启动程序。

所有这些似乎都与this类似。我认为该线程的最后一个评论者询问如何比较Wireshark中成功和不成功的陷阱，我没有做过，但是直到11月6日，所有发送的陷阱都已经工作了数百次（即使不是数千次）。

是否有其他地方可以寻找有关Trapd不接受陷阱的错误？我想我已经排除了网络问题。

我创建了一个新的Ubuntu 18.04 VM，对其进行了更新，然后重新安装了Horizo​​n 23.01。我将陷阱流指向它，并且它的行为完全相同，没有一个陷阱在trapd.log上创建任何日志条目，并且将级别设置为debug。 Tcpdump显示陷阱进入接口。

Answer 1

问题已解决。

基础操作系统丢失了陷阱来自的子网的静态路由。 OpenNMS有一条返回子网的路由，但没有经过陷阱来自的路径。恢复静态路由后，陷阱将再次开始工作，并一直流向事件。