SNMP 流量与端口
SNMP 用 UDP 161 承载网管轮询请求与响应，设备主动上报的 Trap 与需要确认的 Inform 走 UDP 162。轮询失败、Trap 没收到这类问题，先在网管侧与设备侧同时抓包，确认方向上到底有没有请求与响应，比反复重启采集器或改配置有效得多。
基本信息
| 适用平台 | Linux / macOS 的 tcpdump，过滤表达式与设备品牌无关 |
|---|---|
| 轮询端口 | UDP 161（网管到设备） |
| 上报端口 | UDP 162（设备到网管） |
| 版本差异 | v1/v2c 明文传输，社区字符串在抓包里可读；v3 支持认证与加密 |
典型使用场景
- 轮询采集失败：确认设备是否回包，还是只有请求没有响应
- Trap 未上报：过滤 162 判断是设备没发，还是网管侧没收到
- ACL 策略验证：不少设备只允许指定网管源地址访问 161
- 社区字符串泄露排查：v2c 明文传输，抓包可直接读出凭据
- 批量采集超时定位：区分设备响应慢与链路丢包
常用示例
常用示例
sudo tcpdump -i eth0 -nn 'udp and (port 161 or port 162)' -c 20 # 轮询与上报一起看
sudo tcpdump -i eth0 -nn 'udp port 162' -A -c 5 # 打印 Trap 报文文本内容
sudo tcpdump -i eth0 -nn 'udp port 161 and host 10.0.0.20' -w snmp.pcap # 限定网管侧并存盘
# Wireshark 里 snmp.community 非空即说明报文是 v1/v2c 明文方向与端口
| 方向 | 端口 | 典型流量 |
|---|---|---|
| 网管 → 设备 | 161 | get / getnext / getbulk 请求 |
| 设备 → 网管 | 161 | 查询响应（源端口仍为 161） |
| 设备 → 网管 | 162 | Trap 与 Inform 主动上报 |
| 网管 → 设备 | 162 | Inform 的确认应答 |
SNMPv3 的 authPriv 模式对报文做了认证与加密，抓包只能看到版本、长度与时间，OID 与取值都不可读。要核对取值应从设备侧导出，或临时切到 v2c 排障并注意随后的凭据轮换。
多数设备响应的源端口同样是 161，按 port 161 过滤双向都能命中；如果只写 dst port 161，会漏掉设备的回包，容易误判成「设备没响应」。
采集器超时后会重试，抓包里出现同一批 OID 的重复请求属于正常重试行为。判断设备到底有没有响应，要看同一时间窗内是否存在响应方向的报文，而不是数请求条数。