SNMP 端口号：161 与 162 的区别、放行与排查

SNMP 端口号是 UDP 161 和 UDP 162。161 是被监控设备（交换机、路由器、服务器上的 snmpd、UPS 网卡等）上的 SNMP 代理监听的端口，监控服务器向它发送 Get、GetNext、GetBulk、Set 请求；162 是监控服务器上的 Trap 接收程序监听的端口，设备出现端口断开、重启、温度过高等事件时，主动把 Trap 或 Inform 发到这里。一句话记住方向：查询发往设备的 161，告警发往监控服务器的 162。所以被监控设备上不需要开放 162，监控服务器上也不需要开放 161（除非它自己也被别人监控）。

161 和 162 分别是谁在监听

端口	传输	谁在监听	谁发起	承载的报文
161	UDP	被监控设备上的 SNMP 代理	监控服务器	Get、GetNext、GetBulk、Set 请求及对应的响应
162	UDP	监控服务器上的 Trap 接收程序（如 snmptrapd、监控平台）	被监控设备	Trap、Inform，以及 Inform 的确认
10161、10162	TCP 上的 TLS，或 UDP 上的 DTLS	同上两行	同上两行	加密传输的 SNMP（RFC 6353），网络设备很少支持

一次查询和一次告警的报文走向如下，示例中监控服务器为 10.10.0.10，交换机为 10.0.0.2：

轮询（Get / Walk）
  10.10.0.10:随机高位端口  ── 请求 ──▶  10.0.0.2:161
  10.10.0.10:随机高位端口  ◀── 响应 ──  10.0.0.2:161

Trap
  10.0.0.2:随机端口        ── Trap ──▶  10.10.0.10:162

Inform
  10.0.0.2:随机端口        ── Inform ─▶  10.10.0.10:162
  10.0.0.2:随机端口        ◀── 确认 ───  10.10.0.10:162

注意两点：监控服务器发查询时用的是操作系统分配的随机源端口，不是 161；设备发 Trap 的源端口一般也是随机的，少数设备固定使用某个端口，所以防火墙规则只按目的端口写，不要依赖源端口。

SNMP 为什么用 UDP，这意味着什么

SNMP 选择 UDP，是因为它的交互是一问一答、报文很小，一台监控服务器要轮询成百上千台设备，不必为每台维持连接状态；网络拥塞时，管理流量也不会像 TCP 那样被拥塞控制压得发不出去。但 UDP 也带来了几个排查时必须知道的特点：

1. 没有“连接被拒绝”。 TCP 端口不通时你会立刻收到拒绝或超时，能区分；SNMP 不通时几乎只有一种表现：超时。团体名错误、来源不在 ACL 里、版本没启用、端口被防火墙拦截，客户端看到的都是 Timeout: No Response。
2. 丢包靠重试。 net-snmp 的命令行工具默认超时 1 秒、重试 5 次，一个不通的地址要等约 6 秒才报错。批量轮询几百台设备时，用 -t、-r 调整这两个值，避免一台故障设备拖慢整轮采集。
3. Trap 可能丢。 Trap 没有确认机制，链路拥塞或监控服务器正在重启时，告警就丢了。重要设备用 Inform，或者让轮询兜底。
4. 大响应会被分片。 GetBulk 一次返回很多行，响应包超过链路 MTU 时会在 IP 层分片，途中有设备丢弃分片的话，读单个值正常、批量读大表却超时。
5. 端口扫描给不出确定答案。 nmap 扫 UDP 端口，没有回应时只能报 open|filtered，说不清是被过滤了还是服务没回。

防火墙怎么放行 SNMP 端口

按“谁访问谁”逐段写规则：

位置	方向	放行内容
被监控设备本机（交换机的 SNMP ACL、服务器防火墙）	入	仅监控服务器 → 本机 UDP 161
中间防火墙，监控网 → 设备网	去程	监控服务器 → 设备网段 UDP 161；有状态防火墙会自动放行响应
中间防火墙，设备网 → 监控网	去程	设备网段 → 监控服务器 UDP 162
监控服务器本机	入	设备网段 → 本机 UDP 162
无状态 ACL（不跟踪会话）	回程	设备的源端口 161 → 监控服务器的高位端口；用 Inform 时还要放行 162 的确认回程

Linux 上用 iptables：

# 被监控的 Linux 服务器：只允许监控服务器读 161
iptables -A INPUT -p udp -s 10.10.0.10 --dport 161 -j ACCEPT
iptables -A INPUT -p udp --dport 161 -j DROP

# 监控服务器：接收设备网段发来的 Trap
iptables -A INPUT -p udp -s 10.0.0.0/16 --dport 162 -j ACCEPT

使用 firewalld 的系统：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.0.10/32" port port="161" protocol="udp" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/16" port port="162" protocol="udp" accept'
firewall-cmd --reload

Windows 上的监控平台接收 Trap：

New-NetFirewallRule -DisplayName "SNMP Trap 162" -Direction Inbound -Protocol UDP -LocalPort 162 -RemoteAddress 10.0.0.0/16 -Action Allow

路由器上用的是不跟踪会话的扩展 ACL 时，回程要单独写。以思科 IOS 为例，snmp 和 snmptrap 分别是 161 和 162 的关键字：

ip access-list extended NMS-TO-DEVICES
 permit udp host 10.10.0.10 10.0.0.0 0.0.255.255 eq snmp
ip access-list extended DEVICES-TO-NMS
 permit udp 10.0.0.0 0.0.255.255 eq snmp host 10.10.0.10 gt 1023
 permit udp 10.0.0.0 0.0.255.255 host 10.10.0.10 eq snmptrap

第一条 ACL 放在朝向设备网的方向，第二条放在反方向：前一行放行查询的响应，后一行放行 Trap。

改用非标准端口怎么写

查询时指定端口，在地址后面加冒号和端口号即可：

snmpget -v2c -c 'Rd-DC1-2026' 10.0.0.2:1161 1.3.6.1.2.1.1.3.0

Linux 上的 snmpd 在 /etc/snmp/snmpd.conf 里用 agentaddress udp:1161 改监听端口；snmptrapd 在 /etc/snmp/snmptrapd.conf 里用 snmpTrapdAddr udp:1162 改接收端口。1024 以下的端口需要 root 权限或 CAP_NET_BIND_SERVICE 能力才能监听，所以容器里运行的 Trap 接收程序常常监听 1162，再由宿主机把 UDP 162 映射过去。

设备侧把 Trap 发往非标准端口，在 Trap 目标里加 udp-port：

# 华为、H3C
snmp-agent target-host trap address udp-domain 10.10.0.10 udp-port 1162 params securityname cipher Rd-DC1-2026 v2c
# 思科
snmp-server host 10.10.0.10 version 2c Rd-DC1-2026 udp-port 1162

H3C 的命令把 cipher 去掉即可。网络设备上 161 的监听端口一般不建议修改，很多型号也不提供修改入口。改端口并不能带来多少安全性，真正起作用的是来源 ACL 和 SNMPv3。

SNMP 端口不通怎么排查

按从近到远的顺序，一段一段确认：

1. 先确认走的是哪条路、用的是哪个源地址。 监控服务器有多块网卡时，ip route get 10.0.0.2 会显示去往设备的出接口和源地址，这个源地址必须在设备的 SNMP ACL 里。

2. 在监控服务器上抓包，同时发一次查询。 用 -t 2 -r 0 把超时设为 2 秒、不重试，抓包结果更干净：

tcpdump -ni any udp port 161 and host 10.0.0.2
# 另开一个终端
snmpget -v2c -c 'Rd-DC1-2026' -t 2 -r 0 10.0.0.2 1.3.6.1.2.1.1.3.0

抓包看到	说明	下一步
只有请求，没有响应	请求没到设备，或者设备收到了但不回（团体名、ACL、版本）	到设备上看 SNMP 收包计数是否随请求增加
请求之后收到 ICMP port unreachable	包到了，但 161 上没有程序在监听	SNMP 代理没开，或者只监听在别的地址、别的 VRF
请求和响应都有，客户端仍报超时	响应被本机防火墙丢弃，或设备用另一个地址回包，有状态防火墙不认为它是这次请求的响应	检查本机 INPUT 规则；看响应包的源地址
读单个值正常，snmpbulkwalk 大表超时	响应超过 MTU 被分片，分片在途中被丢弃	用 snmpbulkwalk -Cr5 减少每次返回的行数

3. 在设备侧确认请求到了没有。 华为、H3C 执行 display snmp-agent statistics，思科执行 show snmp，重复发几次查询，看收到的 SNMP 报文总数是否随之增加：不增加说明包没到设备，问题在网络或中间防火墙；增加了但没有响应，再看错误团体名、版本不符这些分项计数。

4. 被监控的是 Linux 服务器时，确认 snmpd 监听在哪。 执行 ss -ulnp | grep -w 161，如果显示的是 127.0.0.1:161，外面永远连不上。Debian、Ubuntu 的 snmpd 默认配置就只监听本机回环地址，要在 snmpd.conf 里把 agentaddress 改成 udp:161 或指定的管理网地址，再重启服务。

5. 不知道团体名时，也能测端口通不通。 nmap 的 snmp-info 脚本发送的是一个不需要凭据的 SNMPv3 探测，设备支持 v3 时会返回引擎信息：

nmap -sU -p 161 --script snmp-info 10.0.0.2

结果为 open 并带有引擎 ID 等信息，说明 UDP 161 是通的，剩下的问题出在团体名或用户配置上。反过来，没有回应并不能说明 161 不通：设备可能没有启用 v3，或者执行 nmap 的机器不在 SNMP ACL 里。UDP 扫描需要 root 权限。

Trap 收不到时

先把监控平台的 Trap 服务停掉，避免占用 162 端口，再用 snmptrapd 在前台临时接收，收到什么直接打印出来：

printf 'disableAuthorization yes\n' > /tmp/snmptrapd-test.conf
snmptrapd -f -Lo -C -c /tmp/snmptrapd-test.conf udp:162

# 在另一台机器上发一条测试 Trap（coldStart），验证到监控服务器的路径
snmptrap -v2c -c test 10.10.0.10 '' 1.3.6.1.6.3.1.1.5.1

-f 前台运行，-Lo 输出到屏幕，-C -c 表示只读取指定的配置文件，disableAuthorization yes 让它接受任何团体名，仅用于测试。测试 Trap 能收到、设备的 Trap 收不到，问题在设备侧：用 display snmp-agent target-host 或 show snmp host 确认目标地址和端口，再确认 Trap 源接口到监控服务器的路由是通的。snmptrapd 能收到、平台上却看不到，多半是平台按来源地址匹配不到设备，或者团体名与平台配置不一致。用 SNMPv3 发 Trap 时还要注意，接收端必须按发送设备的引擎 ID 建立对应的用户，否则消息会被丢弃；Inform 以接收端自己的引擎 ID 为准，接收端不需要预先知道设备的引擎 ID。

在管理系统里怎么落地

机房管理系统接入交换机时，端口规划要一并考虑配置下发和数据采集两条路径。Toplink DCIM 的交换机管理通过 SSH 或 Telnet 下发端口开关、VLAN 和限速配置，SNMP 只用于只读采集，因此交换机管理地址需要对 DCIM 采集与下发所用的地址放行 UDP 161，以及 TCP 22（使用 Telnet 时是 TCP 23），其余来源一律拒绝。交换机的管理地址建议放在独立的管理网段，并在 IP 地址管理里单独登记为内网类型的地址段，哪台交换机用哪个管理地址、ACL 里该放行哪些来源，查起来都有据可依。