数值 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 ------------------
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希望在接收端缓冲这些数据包，但是由于数据包存储器中没有空闲的缓冲器而被丢弃。从 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
接收端（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个数据包在接收端被缓冲，但是没有数据包被丢弃。
【责编:admin】
--------------------next---------------------
