思科接口和模块 : 思科通用接口处理器

了解 CPU 使用率达 99% 的 VIP 与接收端缓冲

2016 年 10 月 24 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 8 月 22 日) | 反馈


目录


简介

本文解释多用途接口处理器CPU为什么运行在99%,并且什么是接收端缓冲区。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

背景信息

接收端缓冲是发生的进程,当出站接口:

  • 拥塞。

  • 使用先入先出(FIFO)排队策略。

入站多用途接口处理器不立即丢弃数据包。反而,它缓冲在其数据包内存的数据包,直到缓冲区为流出接口是可用的。基于VIP种类,数据包内存可以是静态RAM (SRAM)或同步动态RAM (SDRAM)。

Cisco 7500系列结构基础

每个接口处理器(传统IP或VIP)有对呼叫CyBus的一个高速的延长的系统总线的一连接。路由/交换处理器(RSPs)连接对两CyBuses (请参见图1)

图1 – Cisco 7500系列体系结构

buffering_rx1.gif

buffering_rx2.gif

数据包缓冲的类型

此部分描述数据包缓冲的多种类型。

  • 在处理器内存的系统缓冲在RSP

    这些缓冲区使用程序交换数据包。您在show interfaces (输入和输出输入队列)和show buffer命令的输出中能看到这些缓冲区。Cisco 7500系列路由器不能执行process-switching。所以,如果有问题系统缓冲,意味着过多的数据包被发送对进程层面。这可以归结于许多要素,例如:

    • 广播风暴

    • 在该的网络的不稳定性原因路由更新

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

    • 快速交换路径不支持例如的功能(X.25)

    • 有选项的IP信息包。

    关于如何排除故障交换额外的进程的信息,参考这些文档:

  • 在RSP (MEMD)缓冲区的数据包内存

    MEMD大小修复在RSP7000、RSP1、RSP2和RSP4的2 MB。而在RSP8和RSP16上,MEMD的大小为8MB。MEMD被分配在所有接口之间在启动时,当有在线插拔时,微码重载入、最大传输单元(MTU)更改或者CBUS复合体。关于CBUS复合体的更多信息,参考什么原因"%RSP-3-RESTART :cbus complex”的原因中详细讨论了此错误消息。您能使用show controllers cbus命令检查MEMD缓冲区状况。

    当分配时MEMD,这些结构创建:

    • local free queue (lfreeq) —它分配到每个接口和使用在此接口接收的数据包。

    • global free queue (gfreeq) —也分配它,并且接口在一些限额内能落回到该队列。

    • 传输队列(txqueue或txq) —它分配到每个接口和使用通过此接口出去的数据包。

    • 发送累计器(txacc) —它代表元素数量在输出接口传输队列(txqueue)的。当发送累计器(txacc)等于发送限制(txlimit),所有缓冲区被释放。当txacc是0时,队列满,并且没有其他队列没有允许。

  • 数据包内存

    在VIP,数据包内存包含用于数据包(微粒)的数据包缓冲接收从或被发送对VIP接口。图2代表数据包流。

    图2 –数据包流

    buffering_rx3.gif

    此部分着重分布式交换启用的VIP,因为接收端缓冲通常发生,当数据包跟随此种交换路径。不同的方案是可能的,解释此处:

    情形 1:当没有在出站接口的拥塞。

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

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

    • 如果VIP可以作出交换决策而且流出接口在同一VIP上,数据包就通过该出站接口发出。因为不交叉cbus,数据包在VIP被认为“本地交换”。

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

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

    方案 2:当出站接口被堵塞。

    有两个可能性:

    • 如果传出接口上配置了排队,VIP会将数据包发往MEMD中的txqueue,数据包会通过排队代码立即从队列中提出。

      • 如果配置了基于RSP的排队,数据包就会被复制到RSP上处理内存的系统缓冲器中。

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

    • 如果出站接口的排队策略是FIFO,接口不立即丢弃数据包(这是什么通常发生与FIFO,当出站接口被堵塞)时。反而,入站VIP缓冲在其数据包内存的数据包,直到一些缓冲区为流出接口再是可用的。这叫作接收端(Rx-side)缓冲。

请使用show controllers vip accumulator命令检查接收端缓冲状态。状态指示:

  • 输出接口数量在路由器提交。

  • 多少数据包VIP有这些接口的被接收端缓冲的。

  • VIP为什么有被接收端缓冲的。

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

在99% CPU利用率的VIP运行

接收端(Rx-side)缓冲的一个结果是VIP可以以99%的CPU利用率运行。VIP不断地监控出站接口的txqueue的状态,并且,当有空闲缓存,复制在cbus的数据包到txqueue。

本身警报的没什么,当VIP运行在99%时,当Rx缓冲发生时。这并不意味着VIP过载。如果VIP需要完成更重要的任务(如需要交换另一个数据包),这不会受到CPU利用率高的影响。

这是您能在实验室里进行说明此的简单测试:

序列2/0/0有128 Kbps时钟频率,并且收到流量以线路速率。流量交换对序列10/0时钟频率是64 Kbps的地方,并且排队策略是FIFO。唯一的选择就是丢弃数据包。

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# 

值2意味着仅两缓冲区被留下。当txacc少于4.时,是Rx缓冲不排队在MEMD的数据包。

show controllers vip 2 tech-support命令从VIP显示运行在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% 

VIP运行在99% CPU利用率,即使只接收128 Kbps。这显示CPU利用率与数据包数量没有连接每秒。这是因为VIP 2比此能转换许多数据包。这只是接收端缓冲的一个标志。

为了检查什么接收端缓冲执行,请执行这些命令:

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 txacc的地址在MEMD的。系统中每个txacc(最多可有4096个)都有一个接收端(Rx-side)缓冲器。
b 是被接收端缓冲的数据包的编号。
c VIP丢弃数据包的编号。如果有足够的信息包内存缓冲区, VIP能RX缓冲区一秒钟流量。然而,如果接口不断地被堵塞,避免丢包是不可能的。
d 目前在接收端被缓冲的数据包数量。
e 目前被接收端缓冲的粒子数量。一个数据包可以由多个微粒(particles)组成。
f 软的限制,是微粒最大,当VIP内存低。
g 硬限制,是微粒最大能在任何时间使用。
h 流出接口的速度在Kbps。
由于MEMD中无txacc可用而被接收端缓冲的数据包数量。这意味着输出队列拥塞(没有其他空闲缓存不是可用的在tx队列)。对此问题的解决方案将增加输出接口带宽(若可能)。
j 数据包数量有IP优先级的除不可能发送的6或7之外,因为没有MEMD acc,和丢弃,因为微粒软奇或硬限制达到了。
k 与 j一样,但适用于IP优先级为6或7(互联网络和网络)的数据包。
l 数据包数量有IP优先级的除VIP想要对RX缓冲区的6或7之外,但是丢包由于缺乏空闲缓存在数据包内存。从Cisco IOS软件版本12.0(13)S和12.1(4)向前,您能也使用show controller vip [all/slot-] packet-memory-drops命令发现被丢弃的数据包编号。在这种情况下,升级数据包存储器会很有帮助。
m 与 l一样,但适用于IP优先级为6或7(互联网络和网络)的数据包。
n VIP尝试对RX缓冲区数据包的数量,因为没有MEMD缓冲器,但是不能执行,很由于缺乏信息包存储器缓冲区。在这种情况下升级数据包内存。从Cisco IOS软件版本12.0(13)S和12.1(4)向前,您能也使用show controllers vip [all/slot-] packet-memory-drops命令知道数据包为什么丢弃了。
o Rx缓冲的信息包数量有IP优先级的除丢弃的6或7之外没有MEMD缓冲器,因为软的(f)或硬(g)限制达到了。在这种情况下,使用RSP16会很有帮助,因为它有更大的MEMD存储空间(8MB,而RSP1、RSP2、RSP4和RSP7000为2 MB)。您可以在这种情况下也减少一些接口MTU (例如ATM、POS或者FDDI)。这些接口通常有一个4470字节MTU,并且可以分配少量MEMD缓冲区,因为缓冲区必须更加大。
p 与 o一样,但适用于IP优先级为6或7(互联网络和网络)的数据包。
q 数据包数量有IP优先级的除VIP尝试对RX缓冲区的6或7之外,因为没有MEMD缓冲器,但是不能执行,很由于缺乏信息包存储器缓冲区。数据包内存的升级在这种情况下帮助。从Cisco IOS软件版本12.0(13)S和12.1(4)向前,您能也使用show controllers vip [all/slot-] packet-memory-drops命令改善知道数据包为什么丢弃了。
r 与 q一样,但适用于IP优先级为6或7(互联网络和网络)的数据包。

如果路由器早于12.0(13)ST运行Cisco IOS软件版本, 12.1(04)DB、12.1(04)DC、12.0(13)S、12.1(4) 12.1(4)AA 12.1(4)T 012.0(13)或者12.0(13)SC, show controllers vip [all/slot-]累加器输出提供简化版本在上面。它不考虑到丢弃的数据包的不同的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 

缓冲区示例在接收端的

示例 1:在slot 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个微粒。

  • 所有数据包是被接收端缓冲的由于缺乏在tx队列的空闲缓存在MEMD。这意味着输出接口被拥塞。因为Rx缓冲的信息包最大被到达,丢包发生。典型的解决方案将升级出站接口带宽,重路由若干流量,以便出站接口被堵塞,或者使某队列下降较少关键流量。

示例 2:没有丢包的接收端缓冲区。

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数据包是被接收端缓冲的,因为ATM1/0拥塞,但是数据包没有丢弃。

  • 因为VIP不能获得MEMD缓冲器, 117795数据包是被接收端缓冲的。数据包没有丢弃。一典型的解决方案将减小某些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 Rx-buffers他们和记录多少数据包是被接收端缓冲的每入站接口上。

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

前向队列编号 …显示的Rx缓冲的信息包数量在接收…
0 第一个端口适配器(PA)的第一个塞孔(plughole)
8 第二个PA的第一个塞孔(plughole)
9 第二个PA的第二个塞孔(plughole)

导致VIP上CPU利用率较高的其他原因

当发现接收端缓冲非激活的时,这些要素之一能导致在VIP的高CPU利用率:

  • 由分布式流量整形导致的VIP上CPU利用率高达99%

    如果配置了分布式流量整形(DTS),数据包一进入dTS队列,VIP CPU的利用率就会迅速上升到99%。

    这是正常的也是预料之中的行为。当dTS配置时, VIP CPU是否空转检查,当下次间隔(Tc)到达,当CPU不忙碌(即,当没有流量)时。否则,验证在tx/rx中断惯例被搭载。只有当不忙碌时,您空转CPU。所以,性能不受影响。

    如想了解何为“下一时间间隔(next time interval)”,请参见什么是令牌桶?

    注意: 只有当必须排列在整形队列时的一数据包流量整形变得激活。换句话说,当流量总量超出整形速率。这就说明了配置了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技术支持中心(TAC)的一服务请求。

建立 TAC 服务请求时应收集的信息

如果还需要援助,在您遵从上面故障排除步骤并且要打开一服务请求(仅限注册用户)后与Cisco TAC,请务必包括此信息:
  • show controllers vip [all / slot#] accumulator 命令的输出信息
  • 相关RSP和VIP上执行 show technical-support 命令的输出
请将收集到的数据以未压缩的纯文本格式 (.txt) 附加到服务请求中。要在您的服务请求中附加信息,请通过 TAC 服务请求工具仅限注册用户)上载它。如果不能访问服务请求工具,您在您的消息标题栏能附上相关信息到您的服务请求,并且发送它对attach@cisco.com同您的服务请求编号。

注意: 请勿手工重新加载也请勿重新启动路由器,在您收集上述信息(前除非要求恢复网络操作),因为这能造成是需要的确定问题的根本原因的重要信息丢失。


相关信息


Document ID: 12810