|
从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
上一页 [1] [2] [3] 下一页 |
