【问题标题】:opennms snmpv3 traps and informsopennms snmpv3 捕获并通知
【发布时间】:2018-04-25 21:53:11
【问题描述】:

我已经通过 docker 镜像部署了 OpenNMS,并且 SNMPv3 轮询工作正常,但无法让 SNMPv3 陷阱或通知正常工作。

trapd-configuration.xml:

<?xml version="1.0"?>
<trapd-configuration snmp-trap-port="162" new-suspect-on-trap="true">
  <snmpv3-user
    security-name="trapuser"
    security-level="3"
    auth-passphrase="authsecret"
    auth-protocol="SHA"
    privacy-passphrase="privsecret"
    privacy-protocol="AES"/>
</trapd-configuration>

如果我从另一台主机运行以下命令,OpenNMS 通过 SNMPv3 轮询该主机:

snmptrap -Dusm -v 3 -l authPriv -u trapuser -a SHA -A authsecret -x AES -X privsecret <opennms-host-ip> 42 coldStart.0

OpenNMS 不生成任何事件。在 trapd.log 中,我可以看到以下警告:

2018-04-26 09:26:33,364 WARN  [DefaultUDPTransportMapping_0.0.0.0/162] o.s.MessageDispatcherImpl: statusInfo=1.3.6.1.6.3.15.1.1.3.0 = 0, status=1404

据我所知,这与未知用户名有关。

同样的通知也不起作用,我在 trapd.log 文件中收到相同的警告,在发件人端也收到类似的警告。如果我运行 tcpdump,我可以看到它从 opennms 检索远程 engineID。

snmpinform -Dusm -v 3 -l authPriv -u trapuser -a SHA -A authsecret -x AES -X privsecret <opennms-host-ip> 42 coldStart.0
registered debug token usm, 1
usm: potentially bootstrapping the USM table from session data
usm: getting user
usm: USM processing has begun (offset 39)
usm: getting user
usm: Failed to find engine data.
usm: USM processing completed.
usm: USM processing begun...
usm: USM processing completed.
usm: potentially bootstrapping the USM table from session data
usm: no flag defined...  continuing
usm: user exists? x=(nil)
usm: Building user trapuser...
usm: USM processing has begun (offset 80)
usm: getting user trapuser
usm: match on user trapuser
usm: Encryption successful.
usm: USM processing completed.
usm: USM processing begun...
usm: match on user trapuser
usm: USM processing completed.
snmpinform: Unknown user name

关于我做错了什么有什么想法吗?

【问题讨论】:

  • 我尝试使用 Horizo​​n 21.1.0 重现您的测试。我遇到了一个问题,我在这里的错误跟踪器中记录了该问题:issues.opennms.org/browse/NMS-10009。您能否尝试将 OpenNMS Trapd 设置为 debug 以查看是否收到相同的错误消息?要将 Trapd 日志记录设置为 DEBUG,请打开 ${OPENNMS_HOME}/etc/log4j2.xml 并搜索行 "&lt;KeyValuePair key="trapd" value="WARN" /&gt;" 并将 WARN 更改为 DEBUG。重新加载配置需要一分钟,无需重新启动。
  • 感谢您的回复。将日志记录级别更改为调试后,我在 trapd.log 文件中得到完全相同的消息。也忘了包括我正在运行 Horizo​​n 21.0.5
  • 我们可以在 Horizo​​n 22.0.0 和 Meridian 2018.1.0 版本中解决此问题,请参阅此处issues.opennms.org/browse/NMS-10009

标签: opennms


【解决方案1】:

请您尝试以下方法:

打开$OPENNMS_HOME/etc/service-configuration.xml 并在AsteriskGatway 服务之后启动Trapd 守护进程。为此,请找到以下 XML 块:

<service enabled="true">
    <name>OpenNMS:Name=Trapd</name>
    <class-name>org.opennms.netmgt.trapd.jmx.Trapd</class-name>
    <invoke method="init" pass="0" at="start"/>
    <invoke method="start" pass="1" at="start"/>
    <invoke method="status" pass="0" at="status"/>
    <invoke method="stop" pass="0" at="stop"/>
</service>

默认情况下,Trapd 在Correlator 之后启动。在AsteriskGateway 服务之后剪切并粘贴整个服务定义块:

<service enabled="false">
    <name>OpenNMS:Name=AsteriskGateway</name>
    <class-name>org.opennms.netmgt.asterisk.agi.jmx.AsteriskGateway</class-name>
    <invoke method="init" pass="0" at="start"/>
    <invoke method="start" pass="1" at="start"/>
    <invoke method="status" pass="0" at="status"/>
    <invoke method="stop" pass="0" at="stop"/>
</service>

您现在可以尝试处理 SNMPv3 陷阱吗?

【讨论】:

  • 感谢您的跟进。我已经完成了上述工作,SNMPv3 陷阱和通知现在正在工作。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-12-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多