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

1.1  SNMP故障处理

1.1.1  SNMP连接失败

1. 故障描述

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

2. 常见原因

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

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

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

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

3. 故障分析

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

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

4. 处理步骤

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

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

¡     如果无法Ping通，请参见“网络管理和监控类故障处理”中的“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连接。

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

¡     上述步骤的执行结果。

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

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_SILENT

1.1.2  SNMP操作超时

1. 故障描述

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

2. 常见原因

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

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

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

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

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

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

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

3. 故障分析

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

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

4. 处理步骤

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

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

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

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

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

¡     如果有丢包，请参见“网络管理和监控类故障处理”中的“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进程问题。

对于支持display system internal snmp-agent operation in-progress命令的设备，在系统视图下执行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节点，减少或不要执行类似操作。

对于不支持display system internal snmp-agent operation in-progress命令的设备，可通过以下方法排除故障：

¡     执行debugging snmp agent命令打开SNMP调试信息开关，再次执行SNMP Get或Set操作来复现问题，然后根据调试信息进一步定位。

¡     如果SNMP进程挂死，无法继续执行SNMP操作来复现问题，可在Probe视图下执行follow命令查看SNMP进程挂死的原因。然后依次执行undo snmp-agent命令和snmp-agent命令重启SNMP进程，来尝试排除故障。

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无

相关日志

无

1.1.3  网管无法管理设备

1. 故障描述

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

2. 常见原因

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

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

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

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

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

3. 故障分析

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

图1-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_SILENT

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

1. 故障描述

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

2. 常见原因

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

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

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

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

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

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

3. 故障分析

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

图1-4 网管无法收到设备发送的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