SNMP trap 告警通道
BMC 发告警有两条常见路径：把事件写进 SEL 等运维人员来读，或者主动以 SNMP trap 推送出去。trap 是推送模型，服务器侧只配置目标地址与团体字，接收端在 162/udp 上监听并落库告警系统。它的优势是实时性，代价是「配置了不等于通了」——接收端没监听、团体字不匹配、中间防火墙拦掉 UDP，服务器侧都不会报错，告警静默丢失。
基本信息
| 接收端口 | 162/udp（接收侧监听） |
|---|---|
| 常见版本 | v2c 配置简单，v3 支持认证与加密 |
| 团体字 | 等同口令，需按敏感凭据管理并定期轮换 |
| 发送侧配置 | BMC 界面或命令行填写目标地址与团体字 |
| 验证工具 | snmptrapd 接收、snmptrap 主动发测试包 |
| 常见故障 | 接收端未监听、团体字不符、防火墙丢弃 UDP |
典型使用场景
- 把硬件告警接入统一监控平台，避免只靠人工翻 SEL
- 机房无人值守时，实现硬件事件的实时推送与工单联动
- 新旧监控平台切换期间，双通道并行验证告警不丢
- 安全整改：评估把 v2c 升级为 v3 认证加密的可行性
- 告警误报排查：确认是设备侧发送异常还是接收侧解析问题
接收端验证
接收端验证
# 接收端监听 trap（前台模式，便于观察；生产环境配日志落盘）
snmptrapd -f -Lo -p 162
# 从其他主机发送测试 trap，验证链路与解析是否正常
snmptrap -v 2c -c <团体字> 10.0.0.50 '' 1.3.6.1.4.1.8072.9999 1.3.6.1.4.1.8072.9999 s 'test'
# 确认 UDP 162 是否被本机防火墙拦下
ss -lunp | grep 162
# BMC 侧核对告警目标与团体字配置是否一致告警不通的排查顺序
| 检查点 | 方法 | 典型结论 |
|---|---|---|
| 接收端进程 | 查看 162/udp 是否被监听 | 未监听则所有 trap 被静默丢弃 |
| 团体字一致 | 比对两侧配置 | 不一致时接收端直接忽略 |
| 网络可达 | 从设备侧确认到目标地址的连通性 | 跨网段时 ACL 常拦 UDP |
| 版本匹配 | 确认双方使用 v2c 或 v3 | 版本不匹配无法解析 |
| 解析规则 | 查看接收端日志与 MIB 文件 | 告警收到但显示为未知 OID |
验证顺序建议从接收端开始：先用 snmptrap 手工发一条测试包，确认接收链路正常，再去排查设备侧配置，能快速排除一半可能性。
v2c 团体字以明文传输：跨不可信网络转发时应改用 v3 或走管理 VPN，同时避免把团体字写进聊天记录与工单。