排除 ASR1000 系列路由器上的高 CPU 使用率问题

简介

本文档介绍如何对ASR1000系列路由器上的高CPU问题进行故障排除。

前提条件

要求

Cisco建议您了解ASR1000架构以解释和利用此文档。 

描述

Cisco路由器上的CPU使用率过高可以定义为路由器上的CPU使用率高于正常使用率的条件。在某些场景中，CPU使用率预计会增加，而在其他场景中，则可能表示存在问题。可以忽略由于网络更改或配置更改而导致的路由器上的CPU使用率暂时偏高，这是预期行为。

但是，如果路由器长时间处于较高的CPU使用率而网络或配置没有任何变化，则该路由器是异常的，需要进行分析。因此，当过度使用时，CPU无法主动为所有其他进程提供服务，从而导致命令行缓慢、控制平面延迟、丢包和服务失败。

高CPU的原因包括：

1. 控制平面CPU接收过多的传送流量
2. 出现异常行为并导致CPU过度使用的进程
3. 数据平面处理器过度使用/超订用
4. 处理器中断过多

CPU使用率高并不一定是ASR1000系列路由器问题，因为路由器CPU使用率与路由器上的负载成正比。 例如，如果发生网络更改，则由于网络将重新收敛，这将导致大量控制平面流量。因此，我们需要确定CPU过度使用的根本原因，以确定它是预期行为还是问题。

下图详细说明了如何解决高CPU问题的逐步过程：

故障排除步骤

步骤1 — 确定CPU使用率较高的模块

ASR1000在不同模块上有多个不同的CPU。因此，我们需要了解哪个模块显示比正常使用率更高。这可以通过空闲值看到，因为空闲值越低，该模块的CPU利用率越高。这些不同的CPU都反映了模块的控制平面。

确定观察设备内哪个模块的CPU使用率较高。是使用以下命令的RP、ESP还是SIP

   show platform software status control-processor brief

请参阅以下输出以查看突出显示的列

如果RP的空闲值较低，则继续执行步骤2第1点

如果ESP的空闲值较低，则继续执行步骤3第2点 

如果SIP的空闲值较低，则继续执行步骤4第3点

   Router#show platform software status control-processor brief

   平均负载
   插槽状态1-Min 5-Min 15-Min
   RP0正常0.00 0.02 0.00
   ESP0正常0.01 0.02 0.00
   SIP0正常0.00 0.01 0.00

   内存(kB)
   已用插槽状态总计(Pct)可用(Pct)已提交(Pct)
   RP0正常1879196率(94%)130180(6%)1432748(71%)
   ESP0正常692100率(34%)1317300(66%)472536(24%)
   SIP0健康284424率(60%)187380(40%)193148(41%)

   CPU 利用率
   插槽CPU用户系统Nice Idle IRQ SIRQ IOwait
   RP0 0 2.59 2.49 0.00 94.80 0.00 0.09 0.00
   ESP0 0 2.30 17.90 0.00 79.80 0.00 0.00 0.00
   SIP0 0 1.29 4.19 0.00 94.41 0.09 0.00 0.00

如果Idle值都相对较高，则可能不是控制平面问题。要排除数据平面故障，需要观察ESP的QFP。由于QFP过度使用，仍然可以观察到“高CPU”的症状，这不会导致控制平面处理器上的高CPU。继续执行步骤 6。

步骤2 — 分析模块

• 路由处理器

在RP内使用下面的命令确认观察到哪个处理器具有高CPU使用率。是Linux进程还是IOS?

   show platform software process slot RP active monitor

如果IOS CPU百分比很高(linux_iosd-imag)，则是RP IOS。继续执行步骤3

如果其他进程的CPU百分比很高，则可能是Linux进程。继续执行步骤4

• 嵌入式服务处理器

在ESP中确认是否观察到控制平面处理器的CPU使用率较高。是FECP吗？

   show platform software process slot FP active monitor

如果进程较高，则它是FECP，然后继续执行步骤5

如果不是FECP，则它不是ESP中的控制平面进程相关问题。如果仍然观察到网络延迟或队列丢弃等症状，则可能需要检查数据平面是否存在过度使用。继续执行步骤6

• SPA接口处理器

如果观察到SIP的CPU使用率较高，则会发现IOCP的CPU使用率较高。确定IOCP中观察到的CPU使用率较高的进程。

执行数据包捕获，并确定哪些流量高于平常，以及哪些进程与此类型的流量相关联。继续执行步骤7

第3步 — IOS进程

请参阅以下输出，第一个百分比是总CPU使用率，第二个百分比是中断CPU使用率，它是用于处理传出数据包的CPU使用率。

如果中断百分比很高，则表示有大量流量被传送到RP，（这可以通过命令show platform software infrastructure punt确认）

如果中断百分比低，但总CPU使用率较高，则会观察到一个或多个进程在较长时间内使用CPU。

在IOS中，使用下面的命令确认观察到哪些进程的CPU使用率较高。

   show processes cpu sorted

确定哪个百分比较高（总CPU或中断CPU），然后根据需要确定各个进程/进程。继续执行步骤7

   Router#show processes cpu sorted

   CPU使用率为五秒：0%/0%;one minute:1%;five minutes:1%

   PID运行时(ms)调用的uSecs 5Sec 1Min 5Min TTY进程

   PID运行时(ms)调用的uSecs 5Sec 1Min 5Min TTY进程

   188 8143 434758 18 0.15% 0.18% 0.19% 0以太网多工秒

   515 380 7050 53 0.07% 0.00% 0.00% 0 SBC主流程

     3 2154 215 10018 0.07% 0.00% 0.19% 0 Exec            

   380 1783 55002 32 0.07% 0.06% 0.06% 0 MMA DB计时器    

    63 3132 11143 281 0.07% 0.07% 0.07% 0 IOSD ipc任务   

     5 1 2 500 0.00% 0.00% 0.00% 0.00% 0 IPC ISSU部署

     6 19 12 1583 0.00% 0.00% 0.00% 0 RF从主Th

     8 0 1 0 0.00% 0.00% 0.00% 0.00% 0 RO通知计时器

     7 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN      

    10 6 75 80 0.00% 0.00% 0.00% 0池管理器    

     9 5671 538 10540 0.00% 0.14% 0.12% 0检查堆     

第4步 — Linux进程

如果发现IOS过度使用了CPU，则需要观察单个linux进程的CPU利用率。这些进程是从show platform software process slot RP active monitor中列出的其他进程。确定观察到哪个或哪些进程的CPU使用率较高，然后继续执行步骤7。

第5步 — FECP流程

如果一个或多个进程较高，则很可能是FECP中导致CPU使用率较高的进程，请继续执行步骤7

第6步 — QFP利用率

量子流处理器是转发ASIC。要确定转发引擎的负载，可以监控QFP。以下命令以数据包/秒和比特/秒为单位列出输入和输出数据包（优先级和非优先级）。最后一行显示由于数据包转发而导致的CPU负载总量（百分比）。

   show platform hardware qfp active datapath utilization

确定输入或输出是否较高，查看流程负载，然后继续执行步骤7

   Router#show platform hardware qfp active datapath utilization

     CPP 0:子设备0 5秒1分钟5分钟60分钟

    输入: 优先级(pps)0 0 0

                     (bps)208 176 176 176

        非优先级(pps)0 2 2 2

                     (bps)64 784 784 784

               总计(pps)0 2 2 2

                     (bps)272 960 960 960

    输出：优先级(pps)0 0 0

                     (bps)192 160 160 160

        非优先级(pps)0 1 1 1

                     (bps)0 6488 6496 6488

              总计(pps)0 1 1

                     (bps)192 6648 6656 6648

    正在处理：加载(pct)0 0 0

第7步 — 确定根本原因并确定修复方案

通过识别已发现过度使用CPU的一个或多个进程，可以更清楚地了解为何发生CPU使用率过高。要继续，请研究由确定的流程执行的功能。这将有助于确定如何解决该问题的行动计划。例如 — 如果进程负责特定协议，则您可能想要查看与此协议相关的配置。

如果您仍然遇到与CPU相关的问题，建议联系TAC，以便让工程师帮助您进一步排除故障。上述故障排除步骤可帮助工程师更有效地隔离问题。

故障排除示例

在本例中，我们将执行故障排除过程，并尝试找出路由器高CPU的可能根本原因。首先，确定观察到哪个模块出现CPU使用率较高的情况，我们得到以下输出：  

   Router#show platform software status control-processor brief
   平均负载
   插槽状态1-Min 5-Min 15-Min
   RP0正常0.66 0.15 0.05
   ESP0正常0.00 0.00 0.00
   SIP0正常0.00 0.00 0.00

   内存(kB)
   已用插槽状态总计(Pct)可用(Pct)已提交(Pct)
   RP0正常1879196率(94%)130180(6%)1432756(71%)
   ESP0正常692472率(34%)1316928(66%)472668(24%)
   SIP0健康284556率(60%)187248(40%)193148(41%)

   CPU 利用率
   插槽CPU用户系统Nice Idle IRQ SIRQ IOwait
   RP0 0 57.11 14.42 0.00 0.00 28.25 0.19 0.00
   ESP0 0 2.10 17.91 0.00 79.97 0.00 0.00 0.00
   SIP0 0 1.20 6.00 0.00 92.80 0.00 0.00 0.00

由于RP0内的空闲量非常低，这表明路由处理器内的CPU使用率较高。因此，为了进一步排除故障，我们将确定RP中观察到的CPU使用率较高的处理器。

   Router#show processes cpu sorted
   五秒的CPU使用率：84%/36%;one minute:34%;five minutes:9%
   PID运行时(ms)调用的uSecs 5Sec 1Min 5Min TTY进程
   107 303230 50749 5975 46.69% 18.12% 4.45% 0 IOSXE-RP推送服务器
    63 105617 540091 195 0.23% 0.10% 0.08% 0 IOSD ipc任务
   159 74792 2645991 28 0.15% 0.06% 0.06% 0 VRR主线程
   116 53685 169683 316 0.15% 0.05% 0.01% 0次工作
     9 305547 26511 11525 0.15% 0.28% 0.16% 0检查堆
   188 362507 20979154 17 0.15% 0.15% 0.19% 0以太网毫秒钛
     3 147 186 790 0.07% 0.08% 0.02% 0 Exec
     2 32126 33935 946 0.07% 0.03% 0.00% 0负载表
   446 416 33932 12 0.07% 0.00% 0.00% 0 VDC流程
   164 59945 5261819 11 0.07% 0.04% 0.02% 0 IP ARP重试时间
    43 1703 16969 100 0.07% 0.00% 0.00% 0 IPC保持连接M  

从输出中可以看到，总CPU百分比和中断百分比高于预期。使用CPU的顶层进程是“IOSXE-RP Punt Se”，这是处理RP CPU流量的进程，因此我们可以进一步查看此流量被传送到RP。

   Router#show platform software infrastructure punt
   LSMPI接口内部统计信息：
   enabled=0, disabled=0, throttled=0, unthrottled=0, state is ready
   输入缓冲区= 90100722
   输出缓冲区= 100439
   rxdone计数= 90100722
   txdone计数= 100436
   Rx no particletype count = 0
   Tx no particletype count = 0
   来自卷影计数的TXBUF = 0
   没有数据包的开始= 0
   数据包末端= 0
   弃用丢弃统计信息：
   错误的版本0
   错误的类型0
   具有功能报头0
   平台标题为0
   功能报头缺少0
   通用报头不匹配0
   错误的总长度0
   错误数据包长度0
   错误的网络偏移量0
   不投掷报头0
   未知的链路类型0
   无swidb 1
   错误的ESS功能报头0
   无ESS功能0
   无SSLVPN功能0
   Punt For Us type unknown 0
   打线原因超出范围0
   IOSXE-RP传送数据包的原因：
       62210226第2层控制和传统数据包
            147个ARP请求或响应数据包
       27801234 For-us数据包
          84426 RP<->QFP keepalive数据包
              6收集邻接数据包
           1647 For-us控制数据包

       FOR_US控制IPv4协议统计信息：
              1647 OSPF数据包
   数据包直方图（500字节/bin），在92中的平均大小，输出56:
    Pak大小入计数出计数
         0+:    90097805 98790
       超过500个：           0 7

从此输出中，我们可以看到“For-us data packets”中有大量数据包，这些数据包表示流向路由器的流量，此计数器确认在几分钟内多次观察命令后增加。这证实CPU被大量突发流量（通常是控制平面流量）过度利用。控制平面流量可以包括ARP、SSH、SNMP、路由更新(BGP、EIGRP、OSPF)等。根据此信息，我们能够确定高CPU的潜在原因，这有助于排除根本原因的故障。例如，可以实施数据包捕获或不同流量的监控来查看传送到RP的确切流量，这样就可以确定并解决根本原因，防止将来出现类似问题。

完成数据包捕获后，潜在转发流量的一些示例包括：

• ARP:这可能是因为ARP请求过多，如果多个IP地址通过配置IP路由向广播接口发送ARP请求，就会出现这种情况。这也可能是由于ARP表中的刷新条目造成的，并且必须根据过期的MAC地址条目重新获取，或者根据接口打开/关闭重新获取。

• SSH：这可能导致CPU使用率过高，原因可能是大量show命令(show tech-support)或启用了大量debug命令，这会强制通过SSH会话发送大量CLI。

• SNMP ：这可能是由于SNMP代理处理请求需要较长时间，从而导致CPU使用率较高。通常有两个可能的原因：轮询的MIB，或由NMS轮询的路由和/或ARP表。

• 路由更新：路由更新的大量涌入通常是由于网络重新收敛或链路抖动。这可能表示网络中断开的路由，或者整个设备断开，这会强制网络收敛并重新计算最佳路由，这取决于使用的路由协议。

这突出表明，当进入单个进程级别时，如何通过识别高CPU的原因来隔离根本原因。在这里，可以单独分析各个进程或协议，以确定它是配置问题、软件问题、网络设计还是预期实践。

其它命令

下面列出了要使用的其他有用命令，并按它们所在的处理器进行排序：

路由处理器

• <show process cpu history>
  • 提供过去60秒、分钟和72小时的CPU历史记录图表
• <show process process_ID>
  • 有关单个进程内存和CPU分配的详细信息
• <show platform software infrastructure punt>
  • 提供有关转发到RP的所有流量的信息
• <show platform software status control-processor brief>
  • 详细介绍CPU的负载和“运行状况”，以及内存和模块统计信息
• <show platform software process slot r0|r1 monitor>
  • 详细介绍所选模块上的不同进程及其CPU和内存分配
• <monitor platform software process r0|r1>
  • 提供实时源，在进程使用CPU时对其进行更新
  • 要求首先在全局配置模式下输入“terminal terminal-type”命令才能正常工作

嵌入式服务处理器

• <show platform software process list fp active summary>
  • 详细列出在CPU上运行的所有进程以及平均负载
• <show platform software process slot f0|f1 monitor>
  • 详细介绍所选模块上的不同进程及其CPU和内存分配
• <monitor platform software process f0|f1>
  • 提供实时源，可以在进程使用CPU时更新进程
  • 要求首先在全局配置模式下输入“terminal terminal-type”命令才能正常工作