关于BMC的SNMP Trap告警上报问题

交流互助区
1

BMC的SNMP Trap告警上报无法接收

[测试在验证openUBMC的SNMP Trap告警上报功能时，通过测试功能发送报文，发现SNMP软件无法接收到上报的测试信息。通过wireshark抓包能够找到发送的消息，但是SNMP 软件始终无法收到。后续验证了华为的iBMC版本现象一样。随后测试在鲲鹏大板机型上验证告警上报功能，SNMP软件工具正常收到测试信息]

环境信息

  • 操作系统：openUIBMC2512LTS iBMC

重现步骤

  1. 创建新用户，用于配置SNMP v3用户登录

  2. 打开SNMP Trap使能功能

  3. 在 网络管理系统 中配置服务端IP

  4. 点击测试，验证SNMP Trap功能

期望结果

[SNMP 软件能够接受到SNMP Trap报文]

实际结果

[SNMP软件没有接受到Trap报文，但是使用wireshark工具抓包能够抓到该报文]

尝试过的解决方案

[1.更换SNMP 软件 2.重新配置SNMP v3用户，并测试该用户可用性。]

2

答案内容由AI生成，仅供参考：

问题分析

根据您的描述，在 openUBMC 系统中配置 SNMP Trap 告警上报后，Wireshark 可以抓到发出的报文，但 SNMP 接收软件无法收到。这与提供的 Context 中多份文档（特别是 SNMP Trap 测试环境搭建指南）所描述的配置要点和常见问题一致。以下结合上下文信息，列出可能的原因及对应的解决建议。

可能原因及建议

1. SNMP 版本不匹配（最常见）

  • 现象：您配置了 SNMPv3 用户 并发送测试报文，Wireshark 能抓到 SNMPv3 报文，但接收软件无法解析。
  • 依据：在 SNMP Trap 上报测试环境搭建指南 中明确指出：

    注：免费版本仅支持 SNMPv1 和 SNMPv2c 协议，不支持 SNMPv3 协议

    • 如果使用的 Mib Browser 或其他 SNMP 接收工具是免费版，则无法接收 SNMPv3 的 Trap 报文。
  • 建议：
    • 确认所用 SNMP 接收软件是否支持 SNMPv3。若不支持，可改用支持 v3 的完整版工具（如 MG-SOFT 企业版、SolarWinds、PRTG 等）。
    • 或者将 Trap 版本切换为 SNMPv1 或 SNMPv2c（需在 BMC Web 界面中修改 Trap 版本配置）。

2. 接收端端口未正确配置或端口被占用

  • 现象：Wireshark 抓到报文，但接收端程序没有反应，可能因端口冲突导致程序无法绑定监听端口。
  • 依据：同一份指南强调：

    “配置端口时，尽量选择不常用的端口，以免端口占用导致 trap 上报失败”

    • 并且测试环境搭建中明确指明了接收端监听端口（如 5100）应与 BMC 配置的“网络管理系统端口”一致。
  • 建议：
    • 在 BMC 的 维护诊断 → 告警上报 → SNMP 报文通知 界面，确认“网络管理系统”的 IP 和端口与接收端工具监听端口一致。
    • 检查该端口是否被其他程序占用（可在 Windows 使用 netstat -ano | findstr :<port> 排查）。
    • 更换一个不常用的端口（如 5100、6200 等）重新配置。

3. SNMPv3 鉴权密码与加密算法未同步配置

  • 现象：BMC 配置了 SNMPv3 用户并设置了加密密码和算法，但接收端工具未进行对应的 V3 配置。
  • 依据：在 SNMPv3 配置部分说明：

    “打开 Mib Browser，进行网络管理系统接收端 SNMP V3 配置，其中鉴权密码即为该 V3 用户的登录密码”

    • 接收端必须与 BMC 使用相同的 鉴权密码（Authentication Passphrase）、隐私密码（Privacy Passphrase） 以及 协议（MD5/SHA、DES/AES）。
  • 建议：
    • 在 BMC Web 界面（用户&安全 → 本地用户）编辑 V3 用户，记录设置的 SNMPv3 加密密码和算法。
    • 在接收端工具的 SNMPv3 配置中，输入相同的鉴权密码（即该用户的登录密码）、隐私密码，并选择同样的鉴权协议和加密协议。

4. NMS 目标地址配置错误

  • 现象：Wireshark 抓到报文，但报文的目标地址可能是本地回环或错误 IP，导致并未真正发往接收端。
  • 依据：知识图谱关系明确指出：

    “SNMP Trap 需要正确配置 Trap Target Address 才能发送成功”

    • BMC Web 界面中的“网络管理系统 IP”必须是接收端工具的 实际监听 IP（若本机测试，通常是本地 IP 或 VPN IP，而非 127.0.0.1）。
  • 建议：
    • 在 BMC 上确认配置的 IP 与接收端工具所在机器的 IP 一致。
    • 如果在 Windows 本机测试，使用 ipconfig 获取本地 IP（或 VPN 分配的 IP）。

5. 接收端防火墙/安全策略拦截

  • 虽然 Context 未直接提及，但测试环境搭建指南中要求“网络管理系统和 BMC 网络互通”，而 Wireshark 能抓到报文说明网络层可到达，但 Windows 防火墙可能阻止应用程序接收特定 UDP 端口。
  • 建议：检查接收端所在系统的防火墙，确保允许入站 UDP 端口（与配置的 Trap 接收端口一致）。

6. 测试报文与正式告警的差异

  • Context 中的“使用 ipmi 命令查询 snmp trap 日发送量异常问题分析”提及：

    “调用 web 页面那些模拟上报的话，不会记录到日发送量里面”

    • 但测试按钮发送的是明确的测试 Trap 报文，与正式告警机制略有不同，但理论上两者都应可达。可尝试通过触发实际告警（如模拟传感器事件）来验证接收端是否能收到真实事件。

总结排查步骤

  1. 确认接收端软件版本：检查是否支持所用的 SNMP Trap 版本（v1、v2c、v3）。若不支持 v3，改用 v1/v2c 或升级工具。
  2. 核对端口配置：BMC 配置的端口与接收端监听端口完全一致，且端口未被占用。
  3. 同步 SNMPv3 安全参数：若使用 v3，确保接收端配置的鉴权/隐私密码及算法与 BMC 上设定的一致。
  4. 验证 IP 可达性：在接收端使用 ping 测试 BMC IP，在 BMC 上确认目标 IP 接收端工具所绑定的 IP（本地 IP 而非回环地址）。
  5. 尝试真实告警：通过传感器触发告警（而非仅发送测试报文），观察 T rap Ringer Console 或接收工具是否收到。

以上分析和建议均来源于您提供的 Context 中的文档内容。如果仍未解决，请提供更详细的配置截图（如 BMC 界面、接收端配置、Wireshark 报文内容），以便进一步定位。

3

麻烦确认下snmpv3 trap告警报文的msgAuthoritativeEngineTime字段是否恒为零，如果是的话，这个问题是由于客户端校验该字段存在误差超过150s后拒收snmp trap报文

4

抓包后确认了，msgAuthoritativeEngineTime不为0，会一直变化，几百到几千中间变化。msgAuthoritativeEngineBoots一直为0。同时还对比了一下设备与服务端时间，相差不到1分钟

5

对比了一下V2版本的天池设备，该设备能够正常接收到SNMP Trap的测试数据。通过抓包后发现V2设备的报文中msgAuthoritativeEngineBoots不为0。后续测试发现，能够软件端能够接受的设备，在触发告警后，上报的报警中msgAuthoritativeEngineBoots会增加，没触发或者一次告警，该值都会增加。但是在当前openUBMC中发现，告警无论如何触发或者解除，该字段msgAuthoritativeEngineBoots始终为0。

有点怀疑是不是该问题导致的，现在需要了解该字段如何在openUBMC中修改？

6

msgAuthoritativeEngineBoots这个是代表snmp服务重启次数，这个可以在openUBMC上查看/var/net-snmp/snmpd.conf确认，该文件中的engineBoots次数就对应着报文里msgAuthoritativeEngineBoots的值，只要执行killall snmpd重启snmp服务这个值就会加一

7

现在转对比这样这个有区别，没看到其他区别。服务端始终收不到openUBMC的Trap报文 :sob:

8

重启openUBMC的snmp服务之后msgAuthoritativeEngineBoots的值应该就不为0了，接收端仍无法接收v3 trap报文么？ 使用的是什么snmp接收端？

9

使用的是manageengine工具。用MG-SOFT MIB Browser验证过，都无法收到Trap数据

10

验证了一下，好像所有V3版本的BMC，包括iBMC，openuBMC都收不到

11

是否可能是因为SNMPv3加密密码和SNMPv3算法的配置与接收端不一致的问题，snmp v3 trap上报功能目前内部测试是正常上报的

12

用户配置的加密密码和工具端是对的上的，工具使用V3用户能够正常连接设备并获取信息。我不确定你说的加密密码是不是值得是用户配置的密码？V3和V2的加密方式不一样吗？这个加密方式可以改动吗？

13

后续换了一个工具，换成最新的 iReasoning MIB Browser个人版，通过log发现无法解析。原来正常接收的V2版本现在也解析失败了，日志打印显示Received packet could not be decoded。确实是有点像工具版本问题

14

在本地用户 =》编辑用户中可以SNMPv3加密密码和SNMPv3算法的配置，鉴权算法和加密算法可以试下进行修改，接收端也同步进行修改保持一致
如果你使用的mib browser是在Windows系统上的话，也可以试下在系统搜索栏中搜“服务”，然后找到MG-SOFT SNMP Trap Sevice服务，然后选择重新启动按钮重启服务试下是否可以接收到报文

15

确认了，是工具问题。使用的工具版本太老了，更新到新版本后正常接收