1 设备管理类故障处理

1.1  硬件资源管理故障处理

1.1.1  CPU占用率高

1. 故障描述

当出现以下情况时，说明设备的CPU控制核占用率高，需要确认CPU占用率高的具体原因。

·     对设备进行每日巡检时，连续使用display cpu-usage命令查看CPU的占用率，CPU占用率明显比日常平均值高。

# 执行display cpu-usage summary命令显示最近5秒、1分钟、5分钟内CPU占用率的平均值。

<Sysname> display cpu-usage summary

Slot CPU        Last 5 sec        Last 1 min        Last 5 min

1    0          5%                5%                4%

# 执行display cpu-usage history命令以图表的方式显示最近60个采样点的CPU占用率，观察到CPU占用率持续在增长或者明显比日常平均值高。

·     通过Telnet/SSH等方式登录设备，并执行命令行时，设备反应缓慢，出现卡顿现象。

·     设备上打印CPU占用率高的相关日志。

·     SNMP网管上出现CPU占用率高的相关告警。

2. 常见原因

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

·     网络攻击。

·     协议震荡，通常为STP震荡、路由协议震荡等。

·     网络环路。

·     设备上配置了流采样功能，需要处理的流量太大或者设备采样频率太高，导致采样功能占用大量CPU资源。

·     设备产生海量日志，设备生成和管理这些日志需要占用大量CPU资源。

3. 故障分析

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

图1-1 CPU占用率高的故障诊断流程图

‌

4. 处理步骤

(1)     ‍确认设备是否受到网络攻击。

现网中，导致设备CPU占用率高最常见的原因是网络攻击。攻击者发起大量非正常网络交互对设备产生冲击，例如短时间内发送大量TCP连接建立请求报文或者ICMP请求报文，设备忙于处理这些攻击报文，导致CPU占用率高，从而影响设备正常业务的运行。

Probe视图下执行display system internal control-plane statistics命令，查看控制平面报文的统计信息，关注丢弃报文的数量。如果当前CPU占用率高，且Dropped字段取值较大，则设备大概率受到了报文攻击。

<Sysname> display system internal control-plane statistics slot 1

Control plane slot 1

  Protocol: Default

    Bandwidth: 15360 (pps)

    Forwarded: 108926 (Packets), 29780155 (Bytes)

    Dropped  : 0 (Packets), 0 (Bytes)

  Protocol: ARP

    Bandwidth: 512 (pps)

    Forwarded: 1489284 (Packets), 55318920 (Bytes)

    Dropped  : 122114 (Packets), 491421 (Bytes)

...

¡     如果受到了网络攻击，则先解决网络攻击问题。

¡     如果未受到网络攻击，则执行步骤(2)。

(2)     确认设备是否出现协议震荡。

协议震荡会导致设备不断地处理协议报文、计算拓扑、更新表项，引起CPU占用率高。在实际应用中，最常见的协议震荡为STP协议震荡和OSPF协议震荡。

¡     对于STP协议震荡，在系统视图执行stp port-log命令打开端口状态变化日志显示开关，如果命令行界面频繁输出以下日志，则说明出现了STP协议震荡。

STP/6/STP_DETECTED_TC: Instance 0's port GigabitEthernet0/0/1 detected a topology change.

STP/6/STP_DISCARDING: Instance 0's port GigabitEthernet0/0/1 has been set to discarding state.

STP/6/STP_NOTIFIED_TC: Instance 0's port GigabitEthernet0/0/1 was notified a topology change.

-     如果STP协议震荡，请先排除STP协议震荡问题。

-     如果STP协议没有震荡，则继续定位。

¡     对于OSPF协议震荡，执行display ip routing-table命令，查看路由信息。如果路由表项中相同网段的路由条目被频繁反复地创建和删除，则表示路由震荡。

-     如果路由震荡，或者路由一直不存在，则先排除链路问题和IGP路由问题。

-     如果路由没有震荡，则执行步骤(3)。

(3)     确认是否存在网络环路。

当以太网接口工作在二层模式并且链路存在环路时，可能出现广播风暴和网络振荡。大量的协议报文上送CPU处理，从而导致CPU占用率升高。当存在网络环路时，设备很多端口的流量会明显变大，且广播和组播报文占比较大。可通过以下步骤来确认设备是否存在网络环路，设备是否存在广播、组播、未知单播报文风暴。

a.     清除接口的统计信息。

<Sysname> reset counters interface

b.     多次执行display counters rate inbound interface命令查看端口使用率是否明显增大。

<Sysname> display counters rate inbound interface

Usage: Bandwidth utilization in percentage

Interface               Usage(%)     Total(pps) Broadcast(pps) Multicast(pps)

GE0/0/1                     0.01              7            --             --

MGE0/31/0                   0.01              1            --             --

MGE0/32/0                   0.01              5            --             --

VMC1/1/0                    0.05             60            --             --

VMC1/2/0                    0.04             52            --             --

 

 Overflow: More than 14 digits.

       --: Not supported.

c.     如果端口使用率明显增大，可继续多次执行display counters inbound interface命令查看接口收到的总报文数、广播和组播报文的数量，分别对应显示信息中Total(pkt)、Broadcast(pkt)、Multicast(pkt)字段的取值。如果广播和组播报文的增长速度快，广播、组播报文在接口收到的总报文数中占比大，则可能出现广播/组播风暴。如果广播和组播报文数量没有明显增加，但是接口收到的总报文数明显增加，则可能出现未知单播报文风暴。

<Sysname> display counters inbound interface

Interface                            Total(pkt) Broadcast(pkt) Multicast(pkt) Err(pkt)

GE0/0/1                                141             27            111        0

MGE0/31/0                           274866          47696              0       --

MGE0/32/0                          1063034         684808              2       --

VMC1/1/0                          11157797        7274558             50        0

VMC1/2/0                           9653898        5619640             52        0

 

 Overflow: More than 14 digits (7 digits for column "Err").

       --: Not supported.

如链路出现环路，可进行如下处理：

-     排查链路连接，避免物理拓扑出现环路。

-     使用display stp命令检查STP协议是否使能，配置是否正确。如果配置错误，请修改配置。

-     使用display stp brief和display stp abnormal-port命令检查邻接设备STP状态是否正常。请根据display stp abnormal-port命令显示信息中的BlockReason字段的取值，定位并解决STP异常问题。

如STP配置均正确，可能为STP协议计算错误或协议计算正确但端口驱动层没有正常Block阻塞，可以在发生环路的接口上执行shutdown/undo shutdown命令或者拔插网线让STP重新计算来快速恢复STP功能，消除环路。

-     在以太网接口视图下，使用broadcast-suppression命令开启端口广播风暴抑制功能，使用multicast-suppression命令开启端口组播风暴抑制功能，使用unicast-suppression命令开启端口未知单播风暴抑制功能。或者使用flow-control命令配置流量控制功能。

-     使用QoS策略针对组播、广播和未知单播报文进行限速。

¡     如未出现环，请执行步骤(4)。

(4)     确认是否配置了流统计和采样功能，以及配置的参数是否合适。

当设备上配置了NetStream、sFlow等网络流量监控功能后，设备会对网络流量进行统计分析。如果网络流量较高，可能会导致CPU占用率偏高。此时，可进行以下处理：

¡     配置过滤条件来精确匹配流量，仅统计分析用户关心的流量。

¡     配置采样器，调整采样比例，使得NetStream、sFlow收集到的统计信息既能基本反映整个网络的状况，又能避免统计报文过多影响设备转发性能。

(5)     确认设备当前是否正在生成海量日志。

某些异常情况下，例如，设备受到攻击、运行中发生了错误、端口频繁Up/Down等，设备会不停地产生诊断信息或日志信息。此时系统软件要频繁的读写存储器，会造成CPU占用率升高。

可通过以下方式来判断设备是否正在生成海量日志：

¡     Telnet登录到设备，配置terminal monitor命令允许日志信息输出到当前终端。

<Sysname> terminal monitor

The current terminal is enabled to display logs.

配置该命令后，如果有大量异常日志或者重复日志输出到命令行界面，则说明设备正在生成海量日志。

¡     重复执行display logbuffer summary命令，如果日志信息总量有明显的增加，再使用display logbuffer reverse命令查看日志详情，确认是否有大量异常日志或者某一条信息大量重复出现。

<Sysname> display logbuffer summary

  Slot EMERG ALERT  CRIT ERROR  WARN NOTIF  INFO DEBUG

     1     0     0     2     9    24    12   128     0

     5     0     0     0    41    72     8     2     0

    97     0     0    42    11    14     7    40     0

<Sysname> display logbuffer reverse

Log buffer: Enabled

Max buffer size: 1024

Actual buffer size: 512

Dropped messages: 0

Overwritten messages: 0

Current messages: 410

%Jan 15 08:17:24:259 2021 Sysname SHELL/6/SHELL_CMD: -Line=vty0-IPAddr=192.168.2.108-User=**; Command is display logbuffer

%Jan 15 08:17:19:743 2021 Sysname SHELL/4/SHELL_CMD_MATCHFAIL: -User=**-IPAddr=192.168.2.108; Command display logfile in view shell failed to be matched.

...

如果设备正在生成海量日志，可以通过以下方法减少日志的生成：

¡     关闭部分业务模块的日志输出功能。

¡     使用info-center logging suppress命令禁止指定模块日志的输出。

¡     使用info-center logging suppress duplicates命令开启重复日志抑制功能。

如果设备未生成海量日志，则执行步骤(6)。

(6)     收集CPU占用率相关信息，找到CPU占用率高的业务模块。

a.     确定对CPU占用率高的任务。

# 在设备上执行display process cpu命令查看一段时间内占用CPU最多的任务。下面以slot 1上的操作为例。

<Sysname> display process cpu slot 1

CPU utilization in 5 secs: 0.4%; 1 min: 0.2%; 5 mins: 0.2%

    JID      5Sec      1Min      5Min    Name

      1      0.0%      0.0%      0.0%    scmd

      2      5.5%      5.1%      5.0%    [kthreadd]

      3      0.0%      0.0%      0.0%    [ksoftirqd/0]

...

如果某个进程的CPU占用率高于3%（经验值供参考），则需要针对该进程继续定位。

# 在设备上执行monitor process dumbtty命令实时查看进程在指定CPU上的占用率。下面以slot 1 CPU 0为例。

<Sysname> system-view

[Sysname] monitor process dumbtty slot 1 cpu 0

206 processes; 342 threads; 5134 fds

Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie

CPU0: 99.04% idle, 0.00% user, 0.96% kernel, 0.00% interrupt, 0.00% steal

CPU1: 98.06% idle, 0.00% user, 1.94% kernel, 0.00% interrupt, 0.00% steal

CPU2: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal

CPU3: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal

CPU4: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal

Memory: 7940M total, 5273M available, page size 4K

        JID        PID  PRI State  FDs     MEM  HH:MM:SS    CPU   Name

        322        322  115   R     0       0K  01:48:03  20.02%  [kdrvfwdd2]

        323        323  115   R     0       0K  01:48:03  20.02%  [kdrvfwdd3]

        324        324  115   R     0       0K  01:48:03  20.02%  [kdrvfwdd4]

        376        376  120   S    22  159288K  00:00:07   0.37%  diagd

          1          1  120   S    18   30836K  00:00:02   0.18%  scmd

        379        379  120   S    22  173492K  00:00:11   0.18%  devd

          2          2  120   S     0       0K  00:00:00   0.00%  [kthreadd]

          3          3  120   S     0       0K  00:00:02   0.00%  [ksoftirqd/0]

…

在monitor process dumbtty命令显示信息中找到CPU占用率超过3%（经验值供参考）的进程的JID，再对这些进程执行display process job命令，收集进程的详细信息，并确认该进程是否运行在控制核上。

如果display process job命令的显示信息中LAST_CPU字段的取值为控制核的编号（例如0～1），则说明该进程运行在CPU控制核上，则需要进一步定位；如果显示信息中LAST_CPU字段的取值为非控制核的编号，则说明该进程运行在CPU转发核上，无需关注，请执行步骤(7)。下面以pppd进程为例，通过显示信息可以看到，该进程包含多个线程，这些线程都运行在控制核上。

   <Sysname> display process name pppd

                                Job ID: 515

                                   PID: 515

                            Parent JID: 1

                            Parent PID: 1

                       Executable path: /sbin/pppd

                              Instance: 0

                               Respawn: ON

                         Respawn count: 1

                Max. spawns per minute: 12

                          Last started: Wed Nov  3 09:52:00 2021

                         Process state: sleeping

                             Max. core: 1

                                  ARGS: --MaxTotalLimit=2000000 --MaxIfLimit=65534 --CmdOption=0x01047fbf --bSaveRunDb --pppoechastenflag=1 --pppoechastennum=6 --pppoechastenperiod=60 --pppoechastenblocktime=300 --pppchastenflag=1 --pppchastennum=6 --pppchastenperiod=60 --pppchastenblocktime=300 --PppoeKChasten --bSoftRateLimit --RateLimitToken=2048

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

       515      0        136K      115      S     0:0:0:90       pppd

       549      0        136K      115      S     0:0:0:0        ppp_misc

       557      0        136K      115      S     0:0:0:10       ppp_chasten

       610      0        136K      115      S     0:0:0:0        ppp_work0

       611      1        136K      115      S     0:0:0:0        ppp_work1

       612      1        136K      115      S     0:0:0:0        ppp_work2

       613      1        136K      115      S     0:0:0:0        mp_main

       618      1        136K      115      S     0:0:0:110      pppoes_main

       619      1        136K      115      S     0:0:0:100      pppoes_mesh

       620      1        136K      115      S     0:0:0:120      l2tp_mesh

       621      1        136K      115      S     0:0:0:20       l2tp_main

对于运行在控制核、CPU占用率超过5%的进程，查看进程的Name字段的取值来确定该进程是否为用户态进程。

如果Process的Name取值中包含“[ ]”，表示它是内核线程，无需执行monitor thread dumbtty命令；如果Process的Name取值中未包含“[ ]”，表示它是用户态进程，它可能包含多个线程。对于多线程的用户态进程，还需要对该用户态进程执行monitor thread dumbtty命令，如果显示信息中某线程LAST_CPU字段的取值为CPU控制核的编号，且CPU字段取值大于5%，则该线程可能为导致CPU控制核占用率高的线程，需要进一步定位。

   <Sysname> monitor thread dumbtty slot 1 cpu 0

   206 processes; 342 threads; 5134 fds

   Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie

   CPU0: 98.06% idle, 0.97% user, 0.97% kernel, 0.00% interrupt, 0.00% steal

   CPU1: 97.12% idle, 0.96% user, 0.96% kernel, 0.96% interrupt, 0.00% steal

   CPU2: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal

   CPU3: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal

   CPU4: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal

   Memory: 7940M total, 5315M available, page size 4K

           JID      TID  LAST_CPU  PRI  State  HH:MM:SS MAX   CPU     Name

           322       322      2      115    R    00:04:21    0  20.15%   [kdrvfwdd2]

           323       323      3      115    R    00:04:21    0  20.15%   [kdrvfwdd3]

           324       324      4      115    R    00:04:21    0  20.15%   [kdrvfwdd4]

             1         1     1     120    S   00:00:02   21   0.19%   scmd

           376       376     1     120    S   00:00:00    1   0.19%   diagd

             2         2     0     120    S   00:00:00    0   0.00%   [kthreadd]

   ...

b.     确认异常任务的调用栈。

在Probe视图下执行follow job命令确认异常任务的调用栈。下面以Sysname上（slot 1）pppd进程（进程编号为515）的操作为例。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] follow job 515 slot 1

Attaching to process 515 (pppd)

Iteration 1 of 5

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

Thread LWP 515:

Switches: 3205

User stack:

#0  0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e

#1  0x0000000000441745 in ppp_EpollSched+0x35/0x5c

#2  0x0000000000000004 in ??

Kernel stack:

[<ffffffff811f0573>] ep_poll+0x2f3/0x370

[<ffffffff811f06c0>] SyS_epoll_wait+0xd0/0xe0

[<ffffffff814aed79>] system_call_fastpath+0x16/0x1b

[<ffffffffffffffff>] 0xffffffffffffffff

Thread LWP 549:

Switches: 20

User stack:

#0  0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e

#1  0x00000000004435d4 in ppp_misc_EpollSched+0x44/0x6c

Kernel stack:

[<ffffffffffffffff>] 0xffffffffffffffff

...

c.     根据a和b步骤找到任务名称，再根据任务名称找到对应的业务模块，定位并处理业务模块的问题。例如，如果任务snmpd的CPU占用率较高，可能是因为设备受到了SNMP攻击，或者NMS对设备的访问太频繁。需要进一步定位SNMP业务模块的问题；如果任务nqad的CPU占用率较高，可能是因为NQA探测太频繁，需要进一步定位NQA业务模块的问题。

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

·     hh3cEntityExtCpuUsageThresholdNotfication

·     hh3cEntityExtCpuUsageThresholdRecover

·     hh3cCpuUsageSevereNotification

·     hh3cCpuUsageSevereRecoverNotification

·     hh3cCpuUsageMinorNotification

·     hh3cCpuUsageMinorRecoverNotification

相关日志

·     DIAG/5/CPU_MINOR_RECOVERY

·     DIAG/4/CPU_MINOR_THRESHOLD

·     DIAG/5/CPU_SEVERE_RECOVERY

·     DIAG/3/CPU_SEVERE_THRESHOLD