1 网络管理和监控类故障处理

1.1  SNMP故障处理

1.1.1  SNMP连接失败

1. 故障描述

网管（NMS）通过SNMP协议无法成功连接设备。

2. 常见原因

本类故障的常见原因主要包括：

·     网络异常导致报文不可达。

·     配置错误导致认证失败。

·     设备受到SNMP报文攻击，进入SNMP静默模式。

·     网管被列入了SNMP黑名单。

3. 故障分析

本类故障的诊断流程如图1所示。

图1 SNMP无法连接的故障诊断流程图

 

 

4. 处理步骤

(1)     执行ping命令，检查设备和网管之间是否路由可达。

¡     如果可以Ping通，说明设备和网管之间路由可达，请执行步骤（2）。

¡     如果无法Ping通，请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。待设备和网管之间可以Ping通后，重新建立SNMP连接。如果重新建立SNMP连接后，SNMP连接仍不能成功建立，请执行步骤（2）。

(2)     检查SNMP配置是否正确。

a.     执行display snmp-agent sys-info version命令，查看设备当前使用的SNMP版本号。设备和网管使用的SNMP版本号必须相同。如果不同，需使用snmp-agent sys-info version命令修改配置。

b.     如果当前使用的是SNMPv1或SNMPv2c版本，则执行display snmp-agent community命令查看设备上配置的团体信息（包括团体名和使用的ACL等信息）。设备和网管使用的团体名必须相同，且设备上配置的ACL必须允许网管访问设备。否则，需使用snmp-agent community和acl命令修改配置。

c.     如果当前使用的是SNMPv3版本，则执行display snmp-agent usm-user命令查看SNMPv3用户信息（包括用户名和使用的ACL等信息），并执行display snmp-agent group命令查看SNMP组信息（包括认证/加密模式和使用的ACL等信息）。设备和网管使用的用户名必须相同，认证/加密参数必须一致，且设备上配置的ACL必须允许网管访问设备。否则，需使用snmp-agent group、snmp-agent usm-user v3和acl命令修改配置。

(3)     检查设备是否进入SNMP静默状态。

如果1个统计周期内（时长为1分钟）设备收到的SNMP认证失败报文的个数大于等于100，则设备认为受到了SNMP攻击，SNMP模块会进入静默状态（设备会打印日志SNMP agent is now silent），设备将在4～5分钟内不再响应收到的任何SNMP报文。可使用以下方式来解决静默状态下无法建立SNMP连接的问题：

¡     请等待SNMP静默状态解除后，重新建立SNMP连接。

¡     暂时关闭SNMP静默功能，重新建立SNMP连接。连接建立后，再开启SNMP静默功能。

如果1个统计周期内（时长为1分钟）设备收到的SNMP认证失败报文的个数大于等于100，则设备认为受到了SNMP攻击，SNMP模块会进入静默状态（设备会打印日志SNMP agent is now silent），设备将在4～5分钟内不再响应收到的任何SNMP报文。请等待SNMP静默状态解除后，重新建立SNMP连接。

(4)     检查网管是否被列入SNMP黑名单。

设备上开启SNMP黑名单功能后，如果网管和设备建立SNMP连接失败，则设备会将网管加入SNMP黑名单，第一次、第二次、第三次、第四次连接连续建立失败，网管会依次被锁定8秒、16秒、32秒和5分钟，黑名单中的网管在锁定期内不允许和设备建立SNMP连接。可使用以下方式来解决网管被锁定状态下无法建立SNMP连接的问题：

¡     请等待网管被解锁后，重新建立SNMP连接。

¡     暂时关闭SNMP黑名单功能，重新建立SNMP连接。连接建立后，再开启SNMP黑名单功能。

 

(5)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名：SNMPv2-MIB

·     authenticationFailure (1.3.6.1.6.3.1.1.5.5)

相关日志

·     SNMP/3/SNMP_ACL_RESTRICTION

·     SNMP/4/SNMP_AUTHENTICATION_FAILURE

·     SNMP/4/SNMP_IPLOCK

·     SNMP/4/SNMP_IPLOCKSTAT

·     SNMP/4/SNMP_SILENT

·     SNMP/5/SNMP_IPUNLOCK

·     SNMP/5/SNMP_IPUNLOCKSTAT

1.1.2  SNMP操作超时

1. 故障描述

网管（NMS）对设备执行SNMP Get和Set操作，网管侧提示操作超时，导致操作失败。

2. 常见原因

本类故障的常见原因主要包括：

·     SNMP连接中断，导致网管无法访问设备。

·     网络丢包，导致设备没有收到SNMP请求。

·     设备存储介质上的存储空间不足，导致设备无法处理SNMP请求。

·     设备繁忙，正在处理其它业务，导致无法处理SNMP请求。

·     SNMP（作为SNMP agent）进程忙，正在处理其它SNMP请求，导致无法对当前SNMP请求做出应答。

·     SNMP进程处理当前SNMP请求时发生异常。

3. 故障分析

本类故障的诊断流程如图2所示。

图2 SNMP操作超时的故障诊断流程图

 

4. 处理步骤

(1)     定位并处理SNMP连接问题。

在网管上查看SNMP连接，如果显示连接超时或者失败，请参照“SNMP连接失败”故障处理章节先定位并处理SNMP连接问题。

(2)     检查网络是否存在丢包。

在网管设备上使用ping –c count host命令，例如将conut参数设置为100，host参数取值为设备的IP地址，查看ping命令执行结果中的packet loss字段取值，判断网络是否存在丢包。

¡     如果无丢包，请参照步骤（3）继续定位；

¡     如果有丢包，请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。

 

(3)     定位并处理设备存储介质上的存储空间不足问题。

在任意视图下执行display memory-threshold命令，如果显示信息中的“Current free-memory state”字段取值中包含Normal字样，表示设备存储介质上的存储空间充足，否则，表示设备存储介质上的存储空间不足，请使用以下方法清理内存。

¡     使用reset recycle-bin命令清除回收站中的文件。（回收站中的文件也会占用存储介质上的存储空间。）

¡     使用delete /unreserved file命令一次性彻底删除文件。如果未使用/unreserved参数，删除的文件会保存在回收站中。

 

(4)     定位并处理设备繁忙问题。

a.     在任意视图下多次重复执行display cpu-usage命令，查看设备CPU利用率是否持续在较高水平。

b.     在任意视图下执行monitor process命令，检查是否存在占用较多CPU的进程。如果某个业务进程占用CPU较多，可以根据业务需要以及设备支持情况，通过重启服务来降低CPU利用率。

(5)     定位SNMP进程问题。

在系统视图下执行probe命令，进入Probe视图，然后多次重复执行display system internal snmp-agent operation in-progress命令查看设备正在处理的SNMP操作的相关信息。

¡     如果显示信息中的Request ID取值一直在变化，则说明SNMP进程一直在处理不同的请求，当前SNMP进程业务较忙。请降低网管对设备的SNMP操作频率。

¡     如果显示信息中的Request ID取值一直不变，则说明SNMP进程一直在处理同一请求，SNMP进程处理该请求时超时。可通过以下方法排除故障：

-     依次执行undo snmp-agent命令和snmp-agent命令重启SNMP进程，来尝试排除故障。

-     执行display system internal snmp-agent operation timed-out和display system internal snmp-agent packet timed-out命令确认耗时较多的SNMP操作以及该操作涉及的MIB节点，减少或不要执行类似操作。

(6)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

无

相关日志

无

1.1.3  网管无法管理设备

1. 故障描述

网管对设备执行SNMP Set或Get等操作，设备无响应或者提示操作失败。

2. 常见原因

本类故障的常见原因主要包括：

·     网管通过SNMP协议无法成功连接设备。

·     网管使用的SNMP版本和MIB节点不匹配。

·     网管没有访问设备的权限。

·     设备上的SNMP进程忙，无法对当前SNMP请求做出应答。

3. 故障分析

本类故障的诊断流程如图3所示。

图3 网管无法管理设备的故障诊断流程图

 

4. 处理步骤

(1)     检查网管是否可以通过SNMP协议连接设备。

如果网管通过SNMP协议无法成功连接设备，请参照SNMP连接失败故障处理流程进行处理。

(2)     检查网管当前使用的SNMP协议版本是否支持访问该MIB节点。

例如snmpUsmMIB只支持通过SNMPv3协议访问；Integer32、Unsigned32和Counter64数据类型仅SNMPv2c和SNMPv3版本支持。如果网管使用SNMPv1版本和设备相连，网管将无法访问Integer32、Unsigned32和Counter64数据类型的MIB节点。MIB节点的数据类型可通过MIB文件中节点的SYNTAX字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

    SYNTAX      Counter64

    MAX-ACCESS  read-only

    STATUS      current

    DESCRIPTION

        "The total number of the bad packets received."

    ::= { hh3cDhcpServer2StatGroup 1 }

如果因为版本原因导致网管无法访问MIB节点，请将网管切换到SNMPv2c或SNMPv3版本后，与设备重新建立连接，再执行Get和Set操作。

(3)     检查MIB节点是否支持当前的访问操作。

请根据MIB节点支持的操作类型来访问设备。MIB节点支持的操作类型可通过MIB文件中节点的MAX-ACCESS字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

    SYNTAX      Counter64

    MAX-ACCESS  read-only

    STATUS      current

    DESCRIPTION

        "The total number of the bad packets received."

    ::= { hh3cDhcpServer2StatGroup 1 }

(4)     检查网管的访问权限。如果访问权限不够，请在设备上修改对应配置，给网管授权。

SNMP支持的访问控制方式包括：

¡     VACM（View-based Access Control Model，基于视图的访问控制模型）：将团体名/用户名与指定的MIB视图进行绑定，可以限制NMS能够访问哪些MIB对象，以及对MIB对象不同的操作权限。通过display current-configuration | include view命令可查看MIB视图相关配置，通过display snmp-agent mib-view命令可查看MIB视图的详细信息。如果配置错误，请修改MIB的相关配置。

¡     设备支持三种MIB视图：

-     Read-view：网管只能读取该视图中节点的值。

-     Write-view：网管可读和写该视图中节点的值。

-     Notify-view：当该视图中包含的Trap节点到达触发条件，网管会收到对应的Trap/Inform报文。

¡     RBAC（Role Based Access Control，基于角色的访问控制）：我司设备通过RBAC进行用户访问权限控制。RBAC的基本思想就是给用户指定角色，这些角色中定义了允许用户操作哪些系统功能以及资源对象。创建SNMPv3用户名时，可以绑定对应的用户角色，通过用户角色下制定的规则，来限制NMS能够访问哪些MIB对象，以及对MIB对象不同的操作权限。如果RBAC权限配置错误，可以通过role name命令进入用户角色视图修改用户角色的规则。

-     拥有network-admin或level-15用户角色的SNMP团体/用户，可以对所有的MIB对象进行读写操作；

-     拥有network-operator用户角色的SNMP团体/用户，可以对所有的MIB对象进行读操作；

-     拥有自定义用户角色的SNMP团体/用户，可以对角色规则中指定的MIB对象进行操作。

 

(5)     检查SNMP进程是否繁忙。

网管对设备执行SNMP Set或Get等操作，设备无响应或者提示操作失败，还可能因为SNMP进程忙，无法对当前SNMP请求做出应答，请参照SNMP操作超时故障处理流程进行处理。

(6)     其它建议

建议网管通过业务接口访问设备，因为业务接口的报文处理能力优于网管口，以便SNMP报文能尽快得到处理。

当有多个NMS同时访问设备，且设备反应缓慢时，建议降低访问频率来减轻设备分担，例如将访问频率设置成大于等于5分钟。

(7)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名：SNMPv2-MIB

·     authenticationFailure (1.3.6.1.6.3.1.1.5.5)

相关日志

·     SNMP/3/SNMP_ACL_RESTRICTION

·     SNMP/4/SNMP_AUTHENTICATION_FAILURE

·     SNMP/4/SNMP_IPLOCK

·     SNMP/4/SNMP_IPLOCKSTAT

·     SNMP/4/SNMP_SILENT

·     SNMP/5/SNMP_IPUNLOCK

·     SNMP/5/SNMP_IPUNLOCKSTAT

1.1.4  SNMP获取数据失败故障

1. 故障描述

网管系统无法通过SNMP协议获取设备数据，具体表现通常包括：

·     现象一：设备开局版本或设备配置变更后，读取不到数据。

·     现象二：设备正常运行了一段时间后，读取不到数据。

·     现象三：设备间歇性读取数据失败。

2. 常见原因

本类故障的常见原因主要包括：

·     SNMP配置错误（例如ACL限制、参数不一致等）。

·     硬件故障导致读取慢，超过了网管设置的超时时间。

·     软件层面：SNMP get-bulk操作要求实际获取到足够数量的有效数据才返回结果。当连续出现大量无效或空的数据项时，系统会持续向后查找，直至满足请求数量，这一过程会消耗额外的时间和系统资源。若始终未找到足够的有效数据，最终可能导致操作超时。

·     网络攻击导致SNMP服务异常。

3. 故障分析

SNMP采用“设备+网管”架构模式。网管平台通过周期性轮询机制（通常30秒到5分钟间隔）主动采集设备运行数据，主要监控内容包括：

·     接口流量统计（ifTable/ifXTable）：端口速率、吞吐量、错包数等。

·     硬件状态信息（entPhysicalTable）：板卡状态、温度、电源等。

·     光模块参数（hh3cTransceiver）：收发光功率、偏置电流等。

其他MIB节点根据厂商实现差异可能采用按需查询模式。

本类故障的诊断流程如图4所示。

图4 SNMP获取数据失败故障处理流程

 

4. 处理步骤

(1)     排查SNMP配置错误

a.     检查设备侧和网管侧使用的SNMP版本是否一致。

在设备侧任意视图执行display snmp-agent sys-info命令，显示信息中The SNMP version of the agent参数的取值必须和网管侧使用的SNMP版本号一致。如果不一致，可在设备侧系统视图下执行snmp-agent sys-info version命令修改，或者在网管侧修改。

b.     检查设备侧和网管侧使用的认证参数是否一致。

SNMPv1和SNMPv2c版本使用团体名进行身份认证，团体名分为只读团体名和读写团体名，设备侧和网管侧的团体名的名称和读写属性必须一致。

-     在设备侧任意视图执行display snmp-agent community命令可查看设备支持的团体名名称和读写属性。

-     如果不一致，可在设备侧系统视图下执行snmp-agent community命令修改，或者在网管侧修改。

SNMPv3版本使用用户名进行身份认证，设备侧和网管侧的用户名的名称和认证加密参数必须一致。设备和网管使用的用户名必须相同，认证/加密参数必须一致，且设备上配置的ACL必须允许网管访问设备。

-     在设备侧任意视图执行display snmp-agent usm-user命令查看SNMPv3用户信息（包括用户名和使用的ACL等信息），并执行display snmp-agent group命令查看SNMP组信息（包括认证/加密模式和使用的ACL等信息）。

-     如果不一致，需使用snmp-agent group、snmp-agent usm-user v3和acl命令修改配置。

c.     检查ACL与VPN关联性。

-     在设备侧任意视图执行display snmp-agent community和display snmp-agent usm-user命令确认SNMP是否引用了ACL（如acl 2998）。如果引用了ACL限制只有指定的网管可以访问设备，则网管所属的VPN必须和ACL规则下关联的VPN一致。

-     在设备侧任意视图执行display acl命令，检查ACL规则是否关联VPN实例。若需要关联VPN实例，请在ACL视图下，执行rule [ rule-id ] permit vpn-instance vpn-instance-name命令添加。

d.     检查SNMPv3配置一致性。

如果使用SNMPv3进行通信，且配置了snmp-agent mib-view、snmp-agent group、snmp-agent target-host等命令，则要求各命令对应参数的取值必须一致。

-     snmp-agent usm-user命令中指定的组名和snmp-agent group命令中指定的组名必须相同，且采用的认证加密模式必须相同（例如均采用无认证无加密、有认证无加密或有认证有加密）。

-     snmp-agent group命令中指定的MIB view必须是已经存在的，否则，请通过snmp-agent mib-view命令创建。

-     snmp-agent usm-user命令中指定的用户名和snmp-agent target-host命令中指定的securityname必须相同，且采用的认证加密模式必须相同（例如均采用无认证无加密、有认证无加密或有认证有加密）。

e.     检查EngineID变更影响。

SNMP协议使用EngineID唯一标识一台被管理设备。如果网络中存在两台设备的EngineID相同，则网管只能管理其中一台设备，无法管理另外一台设备。

-     使用display snmp-agent local-engineid命令用来显示本设备的EngineID。

-     使用snmp-agent local-engineid命令可修改设备的EngineID。

-     修改EngineID后，SNMPv3用户的配置将失效，需要执行snmp-agent usm-user命令重新配置。

(2)     检查SNMP报文处理是否正常。

a.     确认SNMP服务状态及报文处理情况。在任意视图执行display udp verbose | begin 161命令，查看显示信息中的Receiving buffer字段的drop计数是否为0。若检测到SNMP的drop计数非0且持续增长，表明处理请求的线程可能阻塞或响应缓慢。SNMP线程卡顿会导致UDP缓冲区堆积请求报文，缓冲区满载后丢弃后续报文（drop值上升）。网管因超时未收到响应判定数据获取失败，请立即检查SNMP服务状态及系统资源负载。

<Sysname> display udp verbose | begin 161

Info: It will take a long time if the content you search is too much or the stri

ng you input is too long, you can press CTRL_C to break.

 Connection info: Src = 0.0.0.0:161, Dst = 0.0.0.0:0

 Location: slot 1 cpu 0

 Creator: snmpd[1162]

 Type: 2

 State: N/A

 Options: SO_REUSEPORT

 Error: 0

 Receiving buffer(cc/hiwat/lowat/drop/state): 0 / 42240 / 1 / 0 / N/A

 Sending buffer(cc/hiwat/lowat/state): 0 / 9216 / 512 / N/A

...

b.     检查SNMP服务状态。多次执行display process name snmpd命令确认是否有线程长期处于R（运行中）或D（不可中断）状态，可能为线程阻塞。

<Sysname> display process name snmpd

                             Job ID: 13727

                                PID: 13727

                         Parent JID: 1

                         Parent PID: 1

                    Executable path: /sbin/snmpd

...

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

  13727      1        136K      120      S     0:0:6:450      snmpd

  13728      1        136K      120      S     0:0:0:0        snmpd

  13729      1        136K      120      S     0:9:41:670     snmpd

  13730      0        136K      120      S     0:0:0:850      snmpd

c.     收集超时报文信息，大致判断出获取信息失败的节点。

-     在Probe视图下执行display system internal snmp-agent packet timed-out命令，记录超时的MIB节点（如ifTable、hh3cTransceiver等）。

-     执行display clock命令查看当前系统时间。如果当前系统时间和display system internal snmp-agent packet timed-out命令中显示的时间差较大，可以执行reset system internal snmp-agent packet timed-out操作，重新收集超时报文信息。

-     收集网管侧采集信息。如有多少台网管同时监控设备，每台网管的轮询时间、超时时间、所属VPN，以及主要采集的MIB节点有哪些（重点关注接口流量统计数据、光模块数据、硬件信息数据）。

d.     如果接口流量统计节点（ifTable/ifXTable）响应慢，处理建议如下：

-     确认设备软件版本。早期软件版本需通过驱动实时获取流量数据，节点过多可能导致采集延迟，请联系技术支持确认是否存在优化软件版本，如果存在，请升级软件版本。

-     减少网管监控的接口数量，可在设备侧通过关联MIB视图将不关注的接口排除。

-     适当延长网管侧SNMP超时时间参数。

e.     如果光模块节点（hh3cTransceiver）异常，处理建议如下：

执行display transceiver命令被卡住，或者执行display transceiver alarm命令，显示信息中存在Transceiver info I/O error，则说明光模块可能故障，请更换光模块。

f.     如果硬件信息相关节点（entEntity）异常，处理建议如下：

执行display device manuinfo命令被卡住，则说明硬件可能故障，需要更换硬件。

(3)     排查安全威胁。

在Probe视图多次执行display system internal snmp-agent packet receive命令，如果显示信息中出现很多未知IP地址相关记录，或者显示信息中出现名称包含std的节点，则大概率设备受到了公网SNMP攻击，处理建议如下：

¡     配置ACL，并让SNMP关联ACL，仅允许指定IP的网管访问设备。

¡     在系统视图执行snmp-agent silence enable命令，开启SNMP静默功能。（本功能的支持情况与设备型号有关，请以设备实际情况为准）

¡     在系统视图执行snmp-agent blacklist ip-block enable命令，开启SNMP IP地址黑名单功能。（本功能的支持情况与设备型号有关，请以设备实际情况为准）

¡     在系统视图执行snmp-agent denylist user命令，配置SNMPv3用户黑名单功能。（本功能的支持情况与设备型号有关，请以设备实际情况为准）

(4)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     在用户视图执行以下命令，收集一段时间的SNMP调试信息：

-     terminal monitor

-     terminal debugging

-     debugging snmp agent process all

-     debugging snmp agent packet header

-     debugging snmp agent packet receive

-     debugging snmp agent packet send

¡     在Probe视图执行以下命令，收集显示信息：

-     display system internal snmp-agent packet receive

-     display system internal snmp-agent packet send

-     display system internal snmp-agent packet timed-out

-     display system internal snmp-agent operation timed-out

-     display system internal version

5. 告警与日志

相关告警

模块名：SNMPv2-MIB

·     authenticationFailure (1.3.6.1.6.3.1.1.5.5)

相关日志

·     SNMP/3/SNMP_ACL_RESTRICTION

·     SNMP/4/SNMP_AUTHENTICATION_FAILURE

·     SNMP/4/SNMP_IPLOCK

·     SNMP/4/SNMP_IPLOCKSTAT

·     SNMP/4/SNMP_SILENT

·     SNMP/5/SNMP_IPUNLOCK

·     SNMP/5/SNMP_IPUNLOCKSTAT

 

1.1.5  网管无法收到设备发送的Trap

1. 故障描述

网管无法收到设备发送的Trap报文。

2. 常见原因

本类故障的常见原因主要包括：

·     设备和网管之间路由不可达，或者SNMP功能异常，导致无法建立SNMP连接。

·     设备侧和网管侧配置错误，导致网管无法收到设备发送的告警。

·     设备侧业务模块没有产生告警。

·     告警报文丢失，导致网管未收到设备发送的告警。

·     SNMP Trap报文过大，超过SNMP模块对Trap报文大小的限制。

3. 故障分析

本类故障的诊断流程如图5所示。

图5 网管无法收到设备发送的Trap的故障诊断流程图

 

4. 处理步骤

(1)     在系统视图下通过snmp-agent trap log命令开启SNMP告警日志功能。当设备向网管发送告警时，会同时在设备上生成一条日志来记录该Trap。

(2)     通过display logbuffer | include SNMP_NOTIFY命令可以查看设备上是否生成Trap以及生成的Trap详情。

¡     如果有显示信息，说明设备有Trap生成。请执行步骤(3)。

¡     如果没有显示信息，说明SNMP模块未向外发送Trap。请执行步骤(4)。

(3)     如果设备生成了Trap，但网管未收到Trap，请参照以下步骤定位。

a.     检查设备是否可以和网管建立SNMP连接。如果连接建立失败，请参见“SNMP连接失败”解决SNMP连接建立失败问题。

b.     通过display current-configuration | include snmp命令查看snmp-agent target-host trap命令配置是否正确。如果不正确，请修改配置，保证指定的IP地址（VPN参数）和端口号与网管用来接收Trap报文的IP地址（网管所属VPN）和端口号一致，以及设备和网管使用的SNMP协议、安全字一致。

-     如果使用SNMPv1或SNMPv2c版本，则安全字为团体名，请在设备上使用snmp-agent community命令创建SNMP团体。

-     如果使用SNMPv3版本，则安全字为用户名，且设备和网管使用的认证和加密级别必须相同。您需要在设备上使用snmp-agent group和snmp-agent usm-user v3命令创建SNMPv3用户，创建用户时配置的认证和加密模式、认证密码和加密密码（如果用到）必须和网管侧一致，且创建用户时配置的认证和加密级别必须比snmp-agent target-host trap命令中指定的认证和加密级别高。安全级别分为：不认证不加密、认证不加密和认证加密，安全级别依次升高。

-     团体名和用户名可访问的MIB view必须包含对应的MIB告警节点，否则，会因为权限问题导致备不会将Trap报文发送给网管。

c.     执行debugging udp packet命令打开UDP报文的调试信息开关，查看设备发送的Trap报文是否过大。如果业务模块封装的数据较多，可能会导致Trap报文大于设备能发送的SNMP报文的最大长度，这样的Trap报文会被丢弃。此时可结合网络的MTU值以及是否支持分片情况，通过snmp-agent packet max-size命令修改设备能发送的SNMP报文的最大长度。

*Dec 27 22:35:41:203 2021 Sysname SOCKET/7/UDP: -MDC=1;

UDP Output:

 UDP Packet: vrf = 0, src = 192.168.56.121/30912, dst = 192.168.56.1/162

             len = 79, checksum = 0xd98f

d.     检查网络中是否存在防火墙过滤Trap报文。

如果网络中设置了防火墙，可采用以下措施来解决问题：

-     如果防火墙对报文的源IP进行了过滤，可使用snmp-agent trap source命令修改Trap报文的源IP地址。

-     修改防火墙的规则，放行Trap报文。

e.     检查网络是否不稳定，存在丢包。

如果网络中存在丢包，可采用以下措施来解决问题：

-     检查网络，解决网络丢包问题。

-     配置使用Inform报文发送告警信息。Inform有确认机制，比Trap更可靠。Inform仅SNMPv2c和SNMPv3支持。

(4)     SNMP模块未向外发送Trap，请参照以下步骤定位。

a.     通过display snmp-agent trap-list查看业务模块的告警功能是否开启。如未开启，可通过snmp-agent trap enable命令开启。

b.     检查是否达到告警条件。例如接口状态告警会在接口状态发生变化时产生，CPU和内存告警会在CPU、内存的利用率超过阈值时产生等。

-     如未达到告警条件，未产生Trap，属正常现象，无需处理。

-     如果达到告警条件，设备未向外发送Trap，请执行步骤(c)。

c.     使用display snmp-agent trap queue命令查看Trap缓冲区是否被占满。如果Message number大于Queue size，表示Trap缓冲区可能被占满，新生成的Trap报文可能被丢弃。此时，可在系统视图下使用snmp-agent trap queue-size和snmp-agent trap life命令来调整Trap缓冲区性能参数。

(5)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

无

相关日志

·     SNMP/6/SNMP_NOTIFY

·     SNMP/3/SNMP_INFORM_LOST