理解VIP CPU利用率在99％及接收端（Rx-side）缓冲

简介

接收端（Rx-side）缓冲是出局接口发生拥塞且出局接口上的排队战略是先进先出(FIFO)时进行的一种流程。在这种情况下，入局通用接口处理器(VIP)不是立即丢弃数据包，而是将数据包在其数据包存储器中进行缓冲，直到缓冲器可用于出局业务。根据VIP类型的不同，数据包存储器可以是静态RAM(SRAM)或同步动态RAM(SDRAM)的。

Cisco 7500体系结构基础

每台接口处理器(传统 IP或VIP)都有一条到名为CyBus(CyBus)的高速扩展系统总线的连接。路由/交换机处理器(RSP)都与两条CyBuses相连。

[page]
数据包缓冲器的类型

数据包缓冲器有多种不同类型：

• RSP上处理存储器中的系统缓冲器 - 这些缓冲器用于程序交换数据包。它们可通过 show interfaces (输入和输出队列)及 show buffers 命令显示。Cisco 7500不应进行大量程序交换，因此，如果您的系统缓冲器出现问题，就意味着有太多的数据包被发往程序级。这可能是许多不同因素造成的，如：
  • 广播风暴

  • 网络不稳定性导致路由更新

  • “拒绝服务”(DOS)攻击

  • 快速交换路径上不支持的特性(如X.25)

  • 有多个选项的IP数据包

  有关排除过量程序交换故障方面的更详尽信息请参见以下文件：

• RSP(MEMD)缓冲器上的数据包存储器 - 在RSP7000、RSP1、RSP2和RSP4上，MEMD的大小是固定的，为2MB。而在RSP8和RSP16上，MEMD的大小为8MB。MEMD在启动、 在线插拔（OIR）、微码重新加载、最大传输单位（MTU）变化或增加cbus复合体时分配到所有接口上。有关cbus复合体的更详尽信息请参见《 》您可以使用 show controllers cbus 命令来查看MEMD缓冲器的状态。

  在MEMD被分配时会建立以下结构：

  • 本地空闲队列(lfreeq) 被分配给每个接口，用于处理在该接口上接收到的数据包。

  • 同时分配 全局空闲队列(gfreeq) ，一个接口可以在一定限度内返回该队列。

  • 发送队列(txqueue或txq) 被分配给每个接口，用于处理通过该接口发送出去的数据包。

  • 发送 累计器(txacc) 可以显示输出接口发送队列(txqueue)中的单元数量。当发送累计器(txacc)=发送限制(txlimit)时，所有缓冲器都被释放。当发送累计器(txacc)=0时，队列为满，因此不允许有更多队列。

• VIP上的数据包存储器包含用于处理发往或来自某个VIP接口的数据包的数据包缓冲器(粒子)。下图显示了数据包的流动情况：

本部分内容主要讨论启动了分布式交换的VIP接口，因为接收端（Rx-side）缓冲主要发生在数据包传输采用这种交换路径的情况下。可能出现的不同情况有：

出局接口上没有发生拥塞时：

• 数据包在一个端口适配器(PA)上被接收并被发往数据包存储器上的数据包缓冲器。

• 如果VIP不能对数据包进行分布式交换，它就将该数据包转发到RSP，由其作出交换决策。

• 如果VIP可以作出交换决策而且出局接口在同一VIP上，数据包就通过该出局接口发出。我们称数据包在VIP上被"本地交换"，因为它不通过cbus。

• 如果VIP可以作出交换决策但出局接口在另一个插槽中，VIP就会尽力通过cbus将数据包复制到出局接口的txqueue(在MEMD内)中。

• 然后数据包被通过cbus 复制到出局(V)IP中并通过该线路发出。

出局接口被拥塞时会出现以下两种可能的情况：

• 如果出局接口上配置了排队，VIP会将数据包发往MEMD中的txqueue，数据包会通过排队代码 立即 从队列中提出。
  
  
  • 如果配置了基于RSP的排队，数据包就会被复制到RSP上处理存储器的系统缓冲器中。

  • 如果使用了基于VIP的排队，数据包就会被复制到出局VIP的数据包存储器中。

• 如果出局接口的排队战略是先进先出（FIFO）而不是立即丢弃数据包（如果采用FIFO，出局接口发生拥塞时经常会这样），入局VIP就会在其数据包存储器中缓冲数据包，直到有一些缓冲器可重新用于出局接口。这叫作接收端（Rx-side）缓冲。

使用 show controllers vip accumulator 命令来查看接收端（Rx-side）缓冲的状态：

• 路由器中现有接口的数量

• 对这些接口，VIP对多少数据包进行了接收缓冲

• VIP为什么进行接收缓冲

• VIP丢弃了多少数据包，为什么丢弃

[page]
VIP在99%的CPU利用率时的运行
接收端（Rx-side）缓冲的一个结果是VIP可以以99%的CPU利用率运行。VIP连续监控出局接口txqueue的状态，一有空闲的缓冲器，它就将cbus上的数据包复制到txqueue中。

接收端缓冲期间，如果VIP以99%的利用率运行，其本身没有什么可担忧的。这并不意味着VIP过载。如果VIP需要完成更重要的任务(如需要交换另一个数据包)，这不会受到CPU利用率高的影响。

以下是为了说明这一点而在实验室进行的一项简单测试：串行接口2/0/0的时钟速率为128Kbps，而且正在以线速接收业务。这些业务被交换到串行接口10/0，该串行10/0的时钟速率为64Kbps，采用的排队战略是先进先出（FIFO）。在这种情况下，唯一可选择的做法是丢弃数据包。

show controllers cbus 命令显示串行接口10/0的MEMD中的txqueue拥塞：

router#show controller cbus
 
 MEMD at 40000000, 8388608 bytes (unused 697376, recarves 6, lost 0)
 
 RawQ 48000100, ReturnQ 48000108, EventQ 48000110
 
 BufhdrQ 48000130 (21 items), LovltrQ 48000148 (15 items, 2016 bytes)
 
 IpcbufQ 48000158 (24 items, 4096 bytes)
 
 IpcbufQ_classic 48000150 (8 items, 4096 bytes)
 
 3570 buffer headers (48002000 - 4800FF10)
 
 pool0: 8 buffers, 256 bytes, queue 48000138
 
 pool1: 2940 buffers, 1536 bytes, queue 48000140
 
 pool2: 550 buffers, 4512 bytes, queue 48000160
 
 pool3: 4 buffers, 4544 bytes, queue 48000168
 
 slot2: VIP2, hw 2.11, sw 22.20, ccb 5800FF40, cmdq 48000090, vps 8192
 
 software loaded from system
 
 IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
 
 ROM Monitor version 122.0
 
 Mx Serial(4), HW Revision 0x3, FW Revision 1.45
 
 Serial2/0/0, applique is V.35 DCE
 
 received clockrate 2015232
 
 gfreeq 48000140, lfreeq 480001D0 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 16, maxrxcurr 293
 
 txq 48001A00, txacc 48001A02 (value 294), txlimit 294
 
 Serial2/0/1, applique is V.35 DTE
 
 received clockrate 246
 
 gfreeq 48000140, lfreeq 480001D8 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48001A08, txacc 48001A0A (value 6), txlimit 6
 
 Serial2/0/2, applique is Universal (cable unattached)
 
 received clockrate 246
 
 gfreeq 48000140, lfreeq 480001E0 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48001A10, txacc 48001A12 (value 6), txlimit 6
 
 Serial2/0/3, applique is Universal (cable unattached)
 
 received clockrate 246
 
 gfreeq 48000140, lfreeq 480001E8 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48001A18, txacc 48001A1A (value 6), txlimit 6
 
 slot10: FSIP, hw 1.12, sw 20.09, ccb 5800FFC0, cmdq 480000D0, vps 8192
 
 software loaded from system
 
 Serial10/0, applique is V.35 DTE
 
 gfreeq 48000140, lfreeq 48000208 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 1, maxrxcurr 1
 
 txq 48000210, txacc 480000B2 (value 2), txlimit 294
 
 Serial10/1, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000218 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000220, txacc 480000BA (value 6), txlimit 6
 
 Serial10/2, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000228 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000230, txacc 480000C2 (value 6), txlimit 6
 
 Serial10/3, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000238 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000240, txacc 480000CA (value 6), txlimit 6
 
 Serial10/4, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000248 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000250, txacc 480000D2 (value 6), txlimit 6
 
 Serial10/5, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000258 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000260, txacc 480000DA (value 6), txlimit 6
 
 Serial10/6, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000268 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000270, txacc 480000E2 (value 6), txlimit 6
 
 Serial10/7, applique is Universal (cable unattached)
 
 gfreeq 48000140, lfreeq 48000278 (1536 bytes)
 
 rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0
 
 txq 48000280, txacc 480000EA (value 6), txlimit 6
 
 router#

[page]

数值 2 表示只剩下两个缓冲器。在txacc低于“4”时，Rx.buffering不在MEMD中对数据包进行排队。

从VIP发出的 show controllers vip 2 tech-support 命令表明它正在以99%的CPU利用率运行：

router#show controllers vip 2 tech-support
 
 show tech-support from Slot 2:
 
 ------------------ show version ------------------
 
 
 Cisco Internetwork Operating System Software
 
 IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE
 SOFTWARE (fc1)
 
 Copyright (c) 1986-2000 by cisco Systems, Inc.
 
 Compiled Tue 18-Jul-00 22:03 by htseng
 
 Image text-base: 0x600108F0, data-base: 0x602E0000
 
 
 ROM: System Bootstrap, Version 11.1(4934) [pgreenfi 122], INTERIM SOFTWARE
 
 
 VIP-Slot2 uptime is 1 week, 23 hours, 27 minutes
 
 System returned to ROM by power-on
 
 Running default software
 
 
 
 cisco VIP2 (R4700) processor (revision 0x02) with 32768K bytes of memory.
 
 Processor board ID 00000000
 
 R4700 CPU at 100Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache
 
 4 Serial network interface(s)
 
 Configuration register is 0x0
 
 ...
 
 ------------------ show process cpu ------------------
 
 CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69%
即使只接受128Kbps的业务，VIP仍以99%的CPU利用率运行。这意味着CPU利用率与每秒传输的数据包数量无关，因为VIP 2能够交换比这多得多的数据包。这只是接收端缓冲的一个标志。

执行以下操作来检查接收端（Rx-side）缓冲在执行哪些功能：

router#show controllers vip 2 accumulator
 
 show vip accumulator from Slot 2:
 
 Buffered RX packets by accumulator:
 ...
 Serial10/0:
  MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps  
    No MEMD acc: 544980 in     
       Limit drops  : 2644102 normal pak drops, 80 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops  
    No MEMD buf: 0 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
 ...
 Interface x:
 MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps
 No MEMD acc: i in
       Limit drops  : j normal pak drops, k high prec pak drops     
       Buffer drops : l normal pak drops, m high prec pak drops
 No MEMD buf: n in
       Limit drops  : o normal pak drops, p high prec pak drops     
       Buffer drops : q normal pak drops, r high prec pak drops

字符代码	说明
a	MEMD中txacc的地址。系统中每个txacc（最多可有4096个）都有一个接收端（Rx-side）缓冲器。
b	接收端缓冲的数据包数量。
c	VIP丢弃的数据包数量。如果有足够的数据包存储器缓冲器，VIP最多可以在接收端将业务缓冲1秒；然而，如果接口连续拥塞，就可能无法避免数据包丢弃。
d	目前在接收端被缓冲的数据包数量。
e	目前被接收端缓冲的粒子数量。一个数据包可以由多个粒子（particles）组成。
f	软限制：VIP存储容量较低时的最大粒子（particle）数量。
g	硬限制：任何时候都可用的最大粒子（particle）数量。
h	出局接口的速度，单位：kbps。
i	由于MEMD中无txacc可用而被接收端缓冲的数据包数量。这表示输出队列被拥塞(tx.queue中没有更多空闲缓冲器)。解决这一问题的解决方案是增加输出接口带宽(如果可能的话)。
j	IP优先级不是6或7的数据包数量，这些数据包由于没有MEMD帐号而不能被发送，而且会由于达到粒子的软或硬限制而被丢弃。
k	与 j一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。
l	IP优先级不是6或7的数据包数量，VIP希望在接收端缓冲这些数据包，但是由于数据包存储器中没有空闲的缓冲器而被丢弃。从Cisco IOS软件版本12.0(13)S和12.1(4)以后，你还可以使用 show controller vip [all / slot#] packet-memory-drops 命令来查看丢弃的数据包数量。在这种情况下，升级数据包存储器会很有帮助。
m	与 l一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。
n	VIP中由于没有MEMD缓冲器而试图在接收端进行缓冲但由于没有数据包存储器缓冲器而不能这样处理的数据包数量。在这种情况下，升级数据包存储器会很有帮助。从Cisco IOS软件版本12.0(13)S和12.1(4)以后，你还可以使用 show controllers vip [all / slot#] packet-memory-drops 命令来更好地了解这些数据包为何被丢弃。
o	由于没有MEMD缓冲器而在接收端被缓冲的IP优先级不为6或7的数据包数量，这些数据包由于达到粒子的软或硬限制而被丢弃。在这种情况下，使用RSP16会很有帮助，因为它有更大的MEMD存储空间(8MB，而RSP1、RSP2、RSP4和RSP7000为2 MB)。减小某些接口(如ATM、POS或FDDI)的MTU也很有帮助。这些接口的MTU一般为4470个字节，而且可分配的MEMD缓冲器更少，因为这些缓冲器必须比较大。
p	与 o一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。
q	VIP中由于没有MEMD缓冲器而试图在接收端进行缓冲但由于没有数据包存储器缓冲器而不能这样处理的数据包数量。这些数据包的IP优先级不是6或7。在这种情况下，升级数据包存储器会很有帮助。从Cisco IOS软件版本12.0(13)S和12.1(4)以后，你还可以使用 show controllers vip [all / slot#] packet-memory-drops 命令来更好地了解这些数据包为何被丢弃。
r	与 q一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。

如果路由器运行的Cisco IOS软件版本早于12.0(13)ST、12.1(04)DB、12.1(04)DC、12.0(13)S、12.1(4)、12.1(4)AA、12.1(4)T0、12.0(13)或12.0(13)SC，那么 show controllers vip [all / slot#] 累计器的输出就会显示以上信息的简化版本。它不会考虑由于接收端（Rx-side）缓冲而被丢弃的数据包的不同IP优先级。

输出显示如下：

Serial10/0:
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
 No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer
 No MEMD buf: 0 in, 0 limit drops, 0 no buffer
 
 
 Interface x:
 MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps
 No MEMD acc: i in, j+k limit drops, l+m no buffer
 No MEMD buf: n in, o+p limit drops, q+r no buffer

[page]

接收端（Rx-side）缓冲实例
实例1：在该例中，插槽2中的VIP接收到128Kbps的业务并将它路由到串行10/0(64Kbps)。

Serial10/0:
  MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps  
    No MEMD acc: 544980 in     
       Limit drops : 2644102 normal pak drops, 80 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops  
    No MEMD buf: 0 in     
       Limit drops : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
 
544980个数据包成功地在接收端被缓冲，有2644182个被丢弃。被丢弃的2644182个数据包中有80个的IP优先级为6或7。

126个数据包目前正在接收端被缓冲，他们使用378个粒子。

由于MEMD的tx.queue中没有空闲的缓冲器，所以所有数据包都在接收端被缓冲。这意味着输出接口被拥塞。数据包被丢弃是因为达到了接收缓冲数据包的最大数量限制。这种情况下，一般的解决方案是升级出局接口带宽，重新路由一部分业务，从而减轻出局接口上的拥塞或使某些队列可以丢弃不太重要的业务。

实例2： 无数据包丢弃的接收端（Rx-side）缓冲

ATM1/0:
 MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps
 No MEMD acc: 85709 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
 No MEMD buf: 117795 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
 
在该例中，85709个数据包在接收端被缓冲，因为ATM 1/0被拥塞但没有数据包被丢弃。

117795个数据包在接收端被缓冲，因为VIP不能得到MEMD缓冲器。没有数据包被丢弃。一般的解决方案是减小某些MTU的大小以分配更多MEMD缓冲器。使用RSP8将很有帮助。

实例3： 本地交换

SRP0/0/0:
 
  local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps
本地txacc意味着该输出接口与接收数据包的接口位于同一VIP上。这些数据包在本地交换，但出局接口(在该例中为srp 0/0/0)被拥塞。2529个数据包在接收端被缓冲，但是没有数据包被丢弃。

实例4： 前向队列

router#show controllers vip 2 accumulator
 Buffered RX packets by accumulator:
  Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps  
    No MEMD buf: 142041 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 3 normal pak drops, 0 high prec pak drops
  Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps  
    No MEMD buf: 68 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
  Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps  
    No MEMD buf: 414 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
  Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps  
    No MEMD buf: 46 in     
       Limit drops  : 0 normal pak drops, 0 high prec pak drops     
       Buffer drops : 0 normal pak drops, 0 high prec pak drops
某些数据包不能被分配交换。在这种情况下，VIP必须将这些数据包转发到原始的RSP队列中。在数据包不能被立即复制到MEMD的情况下，VIP对它们进行接收缓冲并跟踪每个入局接口上接收缓冲的数据包数量。

前向队列0.7用于第一个端口适配器(PA)，而8.15用于第二个PA。

前向队列编号	...显示...上接收到的被接收缓冲的数据包数量
0	第一个端口适配器(PA)的第一个塞孔（plughole）
8	第二个PA的第一个塞孔（plughole）
9	第二个PA的第二个塞孔（plughole）

[page]
导致VIP上CPU利用率较高的其他原因
当发现接收端（Rx-side）缓冲不再运行但VIP上CPU利用率仍然较高时，应检查以下内容：

由分布式业务整形导致的VIP上CPU利用率高达99%
如果配置了分布式业务整形(dTS)，数据包一进入dTS队列，VIP CPU的利用率就会迅速上升到99%。

这是正常的也是预料之中的行为。配置了dTS时，VIP CPU就会在CPU处于空闲状态（无业务通过）的下一时间间隔(Tc)到来时进行检查。否则，检查就会在发送/接收过程中捎带进行。由于我们只在CPU空闲时对其进行检查，因此不会影响性能。

如想了解何为“下一时间间隔（next time interval）”，请参见《 What Is a Token Bucket?》

注： 整形必须在整形队列中对一个数据包进行排队时进行，换句话说，当业务数量超过整形速率时。这就说明了配置了dTS时为何VIP CPU的利用率始终为99%。有关dTS的更详尽信息可通过以下链接获得：

分布式业务整形
配置分布式业务整形

欺骗性内存访问和校正错误引起的高VIP CPU利用率
校正错误和欺骗性内存访问属于软件故障，可通过Cisco IOS软件纠正而不会导致VIP崩溃。如果这种错误频繁出现，就会导致操作系统进行大量纠正操作，从而使CPU利用率很高。

有关校正错误和欺骗性内存访问的更详尽信息请参见《 排除欺骗性访问、校正错误和欺骗性中断故障》。

使用 show alignment 命令来检查欺骗性内存访问和校正错误。这样的错误举例如下：

VIP-Slot1#show alignment
 No alignment data has been recorded.
 No spurious memory references have been recorded.
导致CPU利用率高的其他原因包括激活的分布式特性的数量和程度。如果您怀疑这是导致利用率高的原因，或不能确定是本文所描述的原因导致CPU利用率较高，我们建议您联系Cisco技术援助中心以进行进一步的故障排除。

如果您在采取上述故障排除步骤后仍需要帮助并希望在 Cisco TAC开立案例(仅限于注册客户)，您必须提供以下信息：

• show controllers vip [all / slot#] accumulator 命令的输出信息

• 相关RSP和VIP上执行 show technical-support 命令的输出

通过使用 ( 注册客户) 进行加载，您可以将信息附在案例后面。如果您不能访问案例更新工具，您可以将信息以电子邮件附件的形式发往 ，在所发信息的主题行标明案例号，从而将相关信息附在案例中发送。

注：?/B>在收集上述信息之前请不要手工重新启动或加电启动路由器（除非恢复网络正常运行需要），因为这可能会导致确定故障根本原因所需重要信息的丢失。