知

SNMP管理设备、trap告警故障

2026-03-30发表

0收藏

冯正伟

冯正伟四段

描述

SNMP无法纳管交换机

一、开始

SNMP（Simple Network Management Protocol，简单网络管理协议）是互联网中的一种网络管理标准协议，主要用于实现管理设备对被管理设备的访问和管理。SNMP具有以下优势：①支持网络设备的智能化管理。利用基于SNMP的网络管理平台，网络管理员可以查询网络设备的运行状态和参数，配置参数值，发现故障，完成故障诊断，进行容量规划和制作报告。②支持对不同物理特性的设备进行管理。SNMP只提供最基本的功能集，使得管理任务与被管理设备的物理特性和联网技术相对独立，从而实现对不同厂商设备的管理。

V7框式交换机SNMP异常问题定位故障的思路是：先检查网络连通性，即作为被网管设备的框式交换机与网管设备之间网络是否互通。如果网络连通性正常，则需要确认被网管交换机与网管设备之间使用的SNMP版本是否一致。如果被网管交换机与网管设备之间使用的SNMP版本一致，则需确认：①如果被网管交换机与网管设备之间使用的版本是v1/v2c版本，需确认两侧团体名是否一致；②如果被网管交换机与网管设备之间使用的版本是v3版本，需确认两侧用户名及认证加密密码是否一致。若上述检查项均无问题，则需检查被网管交换机是否配置了SNMP接入权限ACL。如果被网管交换机配置了SNMP接入权限ACL，则需检查对应ACL是否允许网管设备IP访问。如果上述检查项均无问题，则需通过打印上送CPU报文确认SNMP报文是否已经到交换机业务板并上送对应业务板CPU。如果确认SNMP报文已经到交换机业务板并上送对应业务板CPU，则需通过打印驱动报文确认SNMP报文是否已经上送业务板平台。如果确认SNMP报文已经上送业务板平台，则需通过打印UDP报文确认SNMP报文是否已经上送业务板UDP平台层。如果确认SNMP报文已经上送业务板UDP平台层，则需通过打印主控板UDP报文确认UDP报文是否已经上送主控板。如果确认UDP报文已经上送主控板，则需打开SNMP调试开关确认平台SNMP报文收发情况。如果软件平台SNMP报文收发异常，则需确认SNMP进程是否存在异常。如果确认SNMP进程存在异常，则需收集SNMP进程相关信息。上述确认SNMP报文是否进入交换机/是否上送业务板CPU和平台/是否上送主控板CPU和平台的多个环节中，任一环节存在异常情况，则建议收集相关定位操作日志和交换机诊断信息反馈二线处理。

1. 步骤1：检查作为被网管设备的框式交换机与网管设备之间网络是否互通。如果能互通，进入步骤2进行排查；如果不互通，需要排查两设备地址间的路由是否可达、ARP学习是否正常、中间设备是否存在ACL流控策略等。

2. 步骤2：检查被网管交换机与网管设备之间使用的SNMP版本是否一致。如果SNMP版本一致，进入步骤3进行排查；如果不一致，调整两设备SNMP版本为一致即可。

3. 步骤3：检查被网管交换机与网管设备之间使用的SNMP团体名等是否一致。如果使用SNMP v1/v2c版本，确认两侧团体名是否一致；如果使用v3版本，则确认两侧用户名及认证加密密码是否一致。如果上述检查项确认均一致，进入步骤4进行排查；如果不一致，调整两设备SNMP相关属性为一致即可。

4. 步骤4：检查被网管交换机是否配置了SNMP接入权限ACL。如果没有配置SNMP接入权限ACL，进入步骤5进行排查；如果配置了SNMP接入权限ACL，检查对应ACL是否允许网管设备IP访问。若无，在对应ACL中添加对应网管IP地址即可。

5. 步骤5：通过打印上送CPU报文确认SNMP报文是否已经到交换机业务板并上送对应业务板CPU。如果对应报文进入交换机业务板并上送对应业务板CPU，进入步骤6进行排查；如果确认对应报文未上送业务板CPU，需要抓包/流统确认SNMP是否进入交换机业务板，如果确认未进入，则需排查中间设备是否存在针对SNMP报文的过滤策略等；如果确认已进入，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

6. 步骤6：通过打印驱动报文确认SNMP报文是否已经上送业务板平台。如果确认对应报文已经上送对应业务板平台，进入步骤7进行排查；如果确认对应报文未上送对应业务板平台，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

7. 步骤7：通过打印UDP报文确认SNMP报文是否已经上送业务板UDP平台层。如果确认对应报文已经上送对应业务板UDP平台层，进入步骤8进行排查；如果确认对应报文未上送对应业务板UDP平台层，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

8. 步骤8：通过打印主控板UDP报文确认UDP报文是否已经上送主控板。如果确认对应报文已经上送主控板，进入步骤9进行排查；如果确认对应报文未上送主控板，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

9. 步骤9：打开SNMP调试开关确认平台SNMP报文收发情况。如果确认平台SNMP报文收发异常，收集SNMP进程状态、进程相关信息、相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

10. 步骤10：如果按照上述排查步骤不能解决问题，请收集以下信息反馈给H3C售后技术人员处理：收集SNMP进程状态、进程相关信息、相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

二、流程图相关操作说明：

1、检查作为被网管设备的框式交换机与网管设备之间网络是否互通

检查作为被网管设备的框式交换机与网管设备之间网络是否互通。如果能互通，进入步骤2进行排查；如果不能互通，需要排查两设备地址间的路由是否可达、ARP学习是否正常、中间设备是否存在ACL流控策略等，相关步骤可以参考根叔云图《V7框式交换机三层转发丢包排查云图》等。

命令：ping x.x.x.x

例如：通过上述命令，可以检测作为被网管设备的框式交换机与网管设备之间网络的连通性。其中，x.x.x.x为作为被网管设备的框式交换机的接口IP地址或网管设备的网卡IP地址。

<H3C>ping 192.168.2.254

Ping 192.168.2.254 (192.168.2.254): 56 data bytes, press CTRL_C to break

56 bytes from 192.168.2.254: icmp_seq=0 ttl=255 time=0.285 ms

56 bytes from 192.168.2.254: icmp_seq=1 ttl=255 time=0.181 ms

56 bytes from 192.168.2.254: icmp_seq=2 ttl=255 time=0.162 ms

56 bytes from 192.168.2.254: icmp_seq=3 ttl=255 time=0.193 ms

56 bytes from 192.168.2.254: icmp_seq=4 ttl=255 time=0.197 ms

--- Ping statistics for 192.168.2.254 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

2、检查被网管交换机与网管设备之间使用的SNMP版本是否一致

检查被网管交换机与网管设备之间使用的SNMP版本是否一致，即主要确认两侧设备使用的SNMP版本是否同为SNMPv1、SNMPv2c或SNMPv3。如果被网管交换机与网管设备之间使用的SNMP版本一致，进入步骤3进行排查；如果不一致，则需调整两侧设备SNMP版本为一致。

命令：display current-configuration configuration | include snmp

例如：通过上述命令查看，可以确认设备当前运行的SNMP版本。下述示例加粗的“v2c”为设备当前运行的SNMP版本，即SNMPv2版本。网管设备使用的SNMP版本需与此一致，即也为SNMPv2版本。

<H3C> display current-configuration configuration |include snmp

snmp-agent

snmp-agent local-engineid 800063A2033822D6D74AF1

snmp-agent community read public acl 2001

snmp-agent community write private acl 2001

snmp-agent sys-info version v2c

3、检查被网管交换机与网管设备之间使用的SNMP团体名等是否一致

检查被网管交换机与网管设备之间使用的SNMP团体名等是否一致。如果两侧设备使用SNMP v1/v2c版本，需确认两侧团体名是否一致；如果使用SNMPv3版本，则需确认两侧用户名及认证加密密码是否一致。若上述不同SNMP版本所需检查项确认均一致，进入步骤4进行排查；如果不一致，调整两设备SNMP相关属性为一致即可。

命令：display current-configuration configuration | include snmp

例如：以两侧设备使用SNMP v1/v2c版本为例，通过上述命令查看，可以确认设备SNMP读写团体属性名。下述示例加粗的“read”为设备SNMP只读团体属性，“public”为对应只读团体名；加粗的“write”为设备SNMP读写团体属性，“private”为对应读写团体名。网管侧对应团体名需与此一致。

<H3C> display current-configuration configuration |include snmp

snmp-agent

snmp-agent local-engineid 800063A2033822D6D74AF1

snmp-agent community read public acl 2001

snmp-agent community write private acl 2001

snmp-agent sys-info version v2c

4、检查被网管交换机与网管设备之间使用的SNMP团体名等是否一致

检查被网管交换机是否配置了SNMP接入权限ACL。如果没有配置SNMP接入权限ACL，进入步骤5进行排查；如果配置了SNMP接入权限ACL，检查对应ACL是否允许网管设备IP访问。若无，在对应ACL中添加对应网管IP地址即可。

命令：

Ø 查看SNMP相关配置

[H3C] display current-configuration configuration | include snmp

Ø 查看SNMP接入权限ACL情况

[H3C] display acl all

例如：通过上述命令查看，可以确认设备是否配置了SNMP接入权限ACL。下述示例红色加粗的“acl”代表设备配置了SNMP接入权限ACL，“2001”为对应接入权限ACL，且对应ACL策略仅允许设备IP地址属于192.168.2.0/24地址段的网管设备访问。需确保网管设备IP地址属于对应SNMP接入权限ACL放通地址段。

<H3C> display current-configuration configuration |include snmp

snmp-agent

snmp-agent local-engineid 800063A2033822D6D74AF1

snmp-agent community read public acl 2001

snmp-agent community write private acl 2001

snmp-agent sys-info version v2c

<H3C>display acl 2001

Basic ACL 2001, named mib_1, 1 rule,

ACL"s step is 5

rule 1 permit source 192.168.2.0 0.0.0.255

5、确认SNMP报文是否已经到交换机业务板并上送对应业务板CPU

通过打印上送CPU报文确认SNMP报文是否已经到交换机业务板并上送对应业务板CPU。如果对应报文进入交换机业务板并上送对应业务板CPU，进入步骤6进行排查；如果确认对应报文未上送业务板CPU，需要抓包/流统确认SNMP是否进入交换机业务板，如果确认未进入，则需排查中间设备是否存在针对SNMP报文的过滤策略等；

命令：

Ø 设定打印上送业务板CPU报文匹配规则，即业务板RXTX匹配SNMP报文的特征

[H3C-probe]display rxtx sip source_ip_address slot slot_id

[H3C-probe]display rxtx dip destination_ip_address slot slot_id

[H3C-probe]display rxtx switchflag slot slot_id

Ø 打开rxtx模块收发开关

[H3C-probe]debug rxtx pkt slot x

例如：

①通过下述命令，可以设定打印上送业务板CPU的SNMP报文的特征。因为上送业务板CPU的报文可能非常多，如果全部打印的话，可以说意义不大，故而建议只按照报文特征选择性的打印，比如可以按照报文的源目MAC地址、源目IP地址、VLAN、报文类型等特征进行过滤。下述示例则是以报文的源目IP地址为特征进行打印规则设定，红色加粗的“DestIP”为作为被网管设备的交换机的IP地址，“SourceIP”为网管设备的IP地址。

[H3C-probe]display rxtx sip 192.168.2.254 chassis 2 slot 1 //设定打印上送业务板CPU报文特征，即将上送框2槽位1单板CPU的所有报文中源IP地址为192.168.2.254的报文打印出来。192.168.2.254为网管设备IP地址，框2槽位1为网管SNMP报文入设备接口所处的业务板槽位号。

[H3C-probe]display rxtx dip 192.168.2.1 chassis 2 slot 1 //设定打印上送业务板CPU报文特征，规则可同时设定多条。本条是将上送框2槽位1单板CPU的所有报文中目的IP地址为192.168.2.1的报文打印出来。192.168.2.1为被网管交换机的IP地址，框2槽位1为网管SNMP报文入设备接口所处的业务板槽位号。

[H3C-probe]display rxtx switchflag chassis 2 slot 1 //查看设定的打印上送业务板CPU报文匹配规则，即打印源IP地址为192.168.2.254目的IP地址为192.168.2.1的报文。使用完毕后注意恢复选择开关：display rxtx all slot-id

The switchflag of the packet printing

Broadcast : Yes

Multicast : Yes

Unicast : Yes

Receive : Yes

REnable : No

Rcpu : No

Vxlan : No

Send : Yes

Ts : none

Timeout Monitor: none

Vp : No

Bfd Patch : Yes(10,5)

Dest mac : All

Source mac : All

VlanID : All

ChipID : All

PortNumber : All

Ssp : All

Dsp : All

EtherType : All

DestIP : 192.168.2.1(I)

SourceIP : 192.168.2.254(I)

DIPV6 : All

SIPV6 : All

IPType : All

Reason : All

Cos : All

Match rule : All

②通过下述命令打印出来的上送业务板CPU报文，可以确认SNMP报文是否已经到交换机业务板并上送对应业务板CPU。下述示例可以说明SNMP的请求报文已经到了本业务板CPU。加粗的“sys_port”为被网管交换机接收SNMP请求报文的接口，对应信息显示的接口为设备内部接口号，可结合debug port mapping Slot_ID信息确认对应外部接口号，即mod和port对应即可。加粗的“0000-0050”对应的内容为SNMP请求报文内容。

[H3C-probe]debug rxtx pkt chassis 2 slot 1

Debug RxTx packet is on!

<leaf-88.2>t d

The current terminal is enabled to display debugging logs.

<leaf-88.2>t m

The current terminal is enabled to display logs.

*Jul 29 13:49:23:857 2019 leaf-88.2 DRVPLAT/7/RxTxDebug: -MDC=1-Chassis=2-Slot=1;

DPP Rx: unit=0, rcpu=N, fwd_type=trap, trap=Y[code=231(user_defined_4)/qualifier=0], snoop=N[cmd=-], sys_port=0x08ff(mod=144/port=16), hdr_size=28, pkt_size=85, tc=2, cos=1, fwd_code=7, rif=20, ac=0

-----------------------------------------------------

0000 01 bd 04 7f 80 02 00 00 08 3a 09 20 00 02 17 24

0010 00 00 50 00 00 00 00 2e 00 00 00 00

-----------------------------------------------------

0000 74 ea c8 30 50 01 30 8d 99 c2 2c a4 81 00 00 14

0010 08 00 45 00 00 43 03 13 00 00 80 11 b1 47 c0 a8

0020 02 fe c0 a8 02 01 d1 06 00 a1 00 2f 76 5c 30 25

0030 02 01 01 04 06 70 75 62 6c 69 63 a1 18 02 01 02

0040 02 01 00 02 01 00 30 0d 30 0b 06 07 2b 06 01 02

0050 01 01 03 05 00

-----------------------------------------------------

注释：上送CPU的报文打印出来的内容是以十六进制表示的，如果对报文结构不够熟悉，那么就需要进一步通过报文解析软件对这些报文内容进行解析。这里以著名的Wireshark为例进行说明。报文解析有两种方式：

第一种：通过CMD调用Wireshark安装目录下自带的工具软件text2pcap.exe将捕获到的报文转化为抓包文件，然后就可以直接通过Wireshark打开。

C:\>cd C:\Program Files\Wireshark

C:\Program Files\Wireshark>text2pcap.exe captureCPU.txt captureCPU.cap

Input from: captureCPU.txt

Output to: captureCPU.cap

Output format: PCAP

Wrote packet of 68 bytes.

Read 10 potential packets, wrote 5 packets (444 bytes).

C:\Program Files\Wireshark>

第二种：有些时候会遇到text2pcap无法正常转换报文的情况，这时就需要手工处理原始的报文打印信息，将报文内容以外的信息去除，处理完成后格式如下：

0000 74 ea c8 30 50 01 30 8d 99 c2 2c a4 81 00 00 14

0010 08 00 45 00 00 43 03 13 00 00 80 11 b1 47 c0 a8

0020 02 fe c0 a8 02 01 d1 06 00 a1 00 2f 76 5c 30 25

0030 02 01 01 04 06 70 75 62 6c 69 63 a1 18 02 01 02

0040 02 01 00 02 01 00 30 0d 30 0b 06 07 2b 06 01 02

0050 01 01 03 05 00

然后将处理完成的文本文件导入Wireshark即可；

6、确认SNMP报文是否已经上送业务板平台

通过打印驱动报文确认SNMP报文是否已经上送业务板平台。如果确认对应报文已经上送对应业务板平台，进入步骤7进行排查；如果确认对应报文未上送对应业务板平台，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助；

命令：

Ø 打开rxtx模块的调试开关

[H3C-probe] debugging driver rxtx notice slot slot_id

Ø 打开rxtx模块的收发开关

[H3C-probe]debug rxtx pkt slot slot_id

例如：通过下述命令打印出来的驱动报文，可以确认SNMP报文是否已经上送业务板平台。下述示例加粗的“0000-0050”对应的内容为SNMP请求报文内容，结合加粗的“drv_rxtx_rx_to_platform()”字段，说明对应SNMP报文已经上送业务板平台。

[H3C-probe]debugging driver rxtx notice chassis 2 slot 1

[H3C-probe]debug rxtx pkt chassis 2 slot 1

Debug RxTx packet is on!

<leaf-88.2>t d

The current terminal is enabled to display debugging logs.

<leaf-88.2>t m

The current terminal is enabled to display logs.

*Jul 29 13:51:22:344 2019 leaf-88.2 DRVPLAT/7/RxTxDebug: -MDC=1-Chassis=2-Slot=1;

DPP Rx: unit=0, rcpu=N, fwd_type=trap, trap=Y[code=231(user_defined_4)/qualifier=0], snoop=N[cmd=-], sys_port=0x08ff(mod=144/port=16), hdr_size=28, pkt_size=85, tc=2, cos=1, fwd_code=7, rif=20, ac=0

-----------------------------------------------------

0000 01 bd 04 7f 80 02 00 00 08 a7 09 20 00 02 17 24

0010 00 00 50 00 00 00 00 2e 00 00 00 00

-----------------------------------------------------

0000 74 ea c8 30 50 01 30 8d 99 c2 2c a4 81 00 00 14

0010 08 00 45 00 00 43 03 16 00 00 80 11 b1 44 c0 a8

0020 02 fe c0 a8 02 01 f8 2f 00 a1 00 2f 4f 30 30 25

0030 02 01 01 04 06 70 75 62 6c 69 63 a1 18 02 01 05

0040 02 01 00 02 01 00 30 0d 30 0b 06 07 2b 06 01 02

0050 01 01 03 05 00

-----------------------------------------------------

*Jul 29 13:51:22:344 2019 leaf-88.2 DRVPLAT/7/RxTxDebug: -MDC=1-Chassis=2-Slot=1;

rx parse info: mdcid=1,userport=15,tagnum=1,outervlan=20,vlan=20,srcslot=25,srcunit=0,srcphyport=16,rxflags=0x1c,pktype=51,acltype=63,ifindex=0x1799,cos=1,SrcTgid=-1

*Jul 29 13:51:22:344 2019 leaf-88.2 DRVPLAT/7/RxTxDebug: -MDC=1-Chassis=2-Slot=1;

drv_rxtx_rx_to_platform():unit=0,ifindex=6041,drvrxflags=0x1c,length=85,pri=1,mbufflag2=0x800

7、确认SNMP报文是否已经上送业务板UDP平台层

通过打印UDP报文确认SNMP报文是否已经上送业务板UDP平台层。如果确认对应报文已经上送对应业务板UDP平台层，进入步骤8进行排查；如果确认对应报文未上送对应业务板UDP平台层，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

命令：debugging udp packet slot slot_id

例如：通过下述命令打印出来的报文，可以确认SNMP报文已经上送业务板UDP平台层。下述示例加粗的“src”为业务板UDP平台层收到的UDP报文的源IP地址和UDP源端口号，“dst”为UDP报文的目的IP地址和UDP目的端口号，UDP目的端口号161代表SNMP协议，即说明业务板UDP平台层收到的对应UDP报文为SNMP报文。

<H3C>debugging udp packet chassis 2 slot 1 //若上送UDP报文较多，可通过下发ACL进行过滤

<H3C>t d

The current terminal is enabled to display debugging logs.

<H3C>t m

The current terminal is enabled to display logs.

*Jul 29 13:52:32:130 2019 leaf-88.2 SOCKET/7/UDP: -MDC=1-Chassis=2-Slot=1;

UDP Input:

UDP Packet: vrf = 0, src = 192.168.2.254/60819, dst = 192.168.2.1/161

8、确认UDP报文是否已经上送主控板

通过打印主控板UDP报文确认UDP报文是否已经上送主控板。若SNMP报文已经上送到接口板平台的UDP层，按照处理流程，接下来就是把已经封装好的报文传给主控板。如果确认对应报文已经上送主控板，进入步骤9进行排查；如果确认对应报文未上送主控板，收集相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

命令：debugging udp packet

例如：通过下述命令打印出来的报文，可以确认SNMP报文已经上送主控板。下述示例红色加粗的“src”为主控板收到的UDP报文的源IP地址和UDP源端口号，“dst”为UDP报文的目的IP地址和UDP目的端口号，UDP目的端口号161代表SNMP协议，即说明主控板收到的对应UDP报文为SNMP报文。

<H3C>debugging udp packet //若上送UDP报文较多，可通过下发ACL进行过滤

<H3C>t d

The current terminal is enabled to display debugging logs.

<H3C>t m

The current terminal is enabled to display logs.

*Jul 29 13:54:10:404 2019 leaf-88.2 SOCKET/7/UDP: -MDC=1;

UDP Input:

UDP Packet: vrf = 0, src = 192.168.2.254/54847, dst = 192.168.2.1/161

len = 47, checksum = 0x7117

9、确认SNMP报文是否上送软件平台

打开SNMP调试开关，确认平台SNMP报文收发情况，即SNMP报文是否上送软件平台，且平台是否有回应。如果确认平台SNMP报文收发异常，收集SNMP进程状态、进程相关信息、相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

命令：

Ø 打开SNMP模块的调试开关

<H3C>debugging snmp agent process all

<H3C>debugging snmp agent packet header

<H3C>debugging snmp agent packet receive

<H3C>debugging snmp agent packet send

例如：通过下述命令打印出来的报文，可以确认平台SNMP报文收发正常。下述示例加粗的“Packet received from..”说明平台已收到对应SNMP请求报文，“Send response to NMS”说明平台已回复对应SNMP请求。

<H3C>debugging snmp agent process all

<H3C>debugging snmp agent packet header

<H3C>debugging snmp agent packet receive

<H3C>debugging snmp agent packet send

<H3C>t d

The current terminal is enabled to display debugging logs.

<H3C>t m

The current terminal is enabled to display logs.

*Jul 29 13:55:37:212 2019 H3C SNMP/7/PACKET_SRC: -MDC=1;

Packet received from 192.168.2.254 via UDP

*Jul 29 13:55:37:212 2019 H3C SNMP/7/PACKET: -MDC=1;

Get-next request

Request ID: 20

Error status: 0

Error index: 0

*Jul 29 13:55:37:212 2019 H3C SNMP/7/VBLIST: -MDC=1;

sysUpTime:

*Jul 29 13:55:37:212 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Process request

*Jul 29 13:55:37:212 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Create MOR message for get-next-request and parse MOR message for response

*Jul 29 13:55:37:212 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Make request

*Jul 29 13:55:37:212 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Create MOR message

*Jul 29 13:55:37:213 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Parse MOR message and fill variable-bindings

*Jul 29 13:55:37:213 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Fill variable-bindings

*Jul 29 13:55:37:213 2019 H3C SNMP/7/STACK_INFO: -MDC=1;

Send response to NMS (error status: 0, error index: 0)

*Jul 29 13:55:37:213 2019 H3C SNMP/7/TXRX_INFO: -MDC=1;

Send PDU through IPv4 socket(PDU size: 44)

*Jul 29 13:55:37:213 2019 H3C SNMP/7/PACKET: -MDC=1;

Response

Request ID: 20

Error status: 0

Error index: 0

*Jul 29 13:55:37:214 2019 H3C SNMP/7/VBLIST: -MDC=1;

sysUpTime.0: 162290303

*Jul 29 13:55:37:214 2019 H3C SNMP/7/PACKET_DES: -MDC=1;

Packet sent to 192.168.2.254 via UDP

…

10、收集信息

如果按照上述排查步骤不能解决问题，请收集以下信息反馈给H3C售后技术人员处理：收集SNMP进程状态、进程相关信息、相关定位操作日志和交换机诊断信息，然后拨打H3C热线4008100504求助。

命令：

Ø 查看SNMP任务状态

<H3C> display process name snmpd

Ø 查看SNMP任务栈信息

[H3C-probe]follow process PID

例如：通过下述命令，可以确认平台SNMP进程任务状态是否正常。下述示例红色加粗的“snmpd”为SNMP的任务名称；正常情况下SNMP状态是S状态，如果某个任务一直为R状态，则说明SNMP任务处于繁忙状态。如果SNMP进程异常，可通过follow对应SNMP的PID号，收集对应SNMP进程任务栈信息返回研发分析。

<leaf-88.2>display process name snmpd

Job ID: 506

PID: 1542

Parent JID: 1

Parent PID: 1

Executable path: /sbin/snmpd

Instance: 0

Respawn: ON

Respawn count: 2

Max. spawns per minute: 12

Last started: Wed Jul 10 19:31:34 2019

Process state: sleeping

Max. core: 1

ARGS: --periodicaltrap=1

TID LAST_CPU Stack PRI State HH:MM:SS:MSEC Name

1542 8 336K 120 S 0:0:16:620 snmpd

1543 5 336K 120 S 0:2:10:520 snmpd

1544 2 336K 120 S 0:12:42:730 snmpd

[H3C-probe]follow process 1542 //需通过display process name snmpd确认对应进程的PID号

Attaching to process 1542 (snmpd)

Iteration 1 of 5

------------------------------

Thread (LWP 1542):

Switch counts: 164934

User stack:

#0 0x000000ffedbdede4 in epoll_wait+0x1c/0x4c

#1 0x000000012003938c in SNMP_MainEpollProcess+0x4c/0x88

Kernel stack:

[<ffffffff804ad8c0>] schedule+0x710/0x1050

[<ffffffff804ae4a8>] schedule_timeout+0x98/0xe0

[<ffffffff803173b4>] sys_epoll_wait+0x4d4/0x5a0

[<ffffffff80202f44>] stack_done_ra+0x0/0x1c

Thread (LWP 1543):

Switch counts: 1655275

User stack:

#0 0x000000ffedbdede4 in epoll_wait+0x1c/0x4c

#1 0x00000001200471a4 in ??

Kernel stack:

[<ffffffff804ad8c0>] schedule+0x710/0x1050

[<ffffffff804ae4a8>] schedule_timeout+0x98/0xe0

[<ffffffff803173b4>] sys_epoll_wait+0x4d4/0x5a0

[<ffffffff80202f44>] stack_done_ra+0x0/0x1c

交换机SNMP不发送接口UP\DOWN 的TRAP告警排查方法案例：

问题描述

某网管平台维护人员，反馈网管平台接收不到我司S5560X-54C-EI交换机发送的接口UP\DOWN 的TRAP告警，怀疑交换机配置出现问题。

过程分析

1、配置检查

<H3C>dis cu | in snmp

snmp-agent

snmp-agent local-engineid xxxxxxxxxxxxxxxxxxxxx

snmp-agent community write xxxx

snmp-agent community read xxxx

snmp-agent sys-info version v2c

snmp-agent target-host trap address udp-domain 172.20.200.253 params securityname gwwrite123 V2C

snmp-agent trap enable arp

snmp-agent trap enable radius

snmp-agent trap enable stp

snmp-agent trap enable syslog

配置检查中未发现问题，官网资料中也确认接口UP\DOWN告警默认是开启状态。

2、现场人员此时依旧表示需要看到确切证据才肯相信交换机确实已经发送了TRAP告警。

在设备debug确认设备是否已经产生TRAP以及是否发送？

<H3C>debugging snmp trap packet

<H3C>t m

<H3C>t d

*Apr 2 18:14:35:390 2019 H3C SNMP/7/TRAP_PACKET: -MDC=1;

linkDown trap<v2> send to: 172.20.200.253

Request ID: 503378083

Error status: 0

Error index: 0

UDP port: 162

Trap successfully sent

测试结果表明设备确实已经产生了TRAP，可是网管平台人员此时还是有点犹豫，认为设备只是生成了TRAP但是没有发送到网管平台。

2、在网管平台上抓包确认

以17端口DOWN事件为例：

Syslog日志报出端口down后，SNMP TRAP紧跟着输出。

通过端口UP\DOWN OID参考表，发现网管平台确实已经收到了TRAP告警。

节点名称：

ifOperStatus

节点OID值：

1.3.6.1.2.1.2.2.1.8

参考节点ifDescr，1.3.6.1.2.1.2.2.1.2，来获取端口名称与端口索引之间的对应关系，比如Ten-GigabitEthernet2/0/1的端口索引为3，根据ifOperStatus知道索引为3的端口运行状态是DOWN的，就可以知道Ten-GigabitEthernet2/0/1的端口运行状态是DOWN的，比如端口没有接线。

获取端口运行状态：

1: ifOperStatus.1 (integer) down(2)

2: ifOperStatus.2 (integer) up(1)

3: ifOperStatus.3 (integer) down(2)

4: ifOperStatus.4 (integer) down(2)

注：索引值down(2)、up(1)

再以15端口UP事件为例：