|
接收端（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）
导致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技术援助中心以进行进一步的故障排除。
在TAC开立案例需要收集的信息
如果您在采取上述故障排除步骤后仍需要帮助并希望在 Cisco TAC开立案例(仅限于注册客户)，您必须提供以下信息：
show controllers vip [all / slot#] accumulator 命令的输出信息
相关RSP和VIP上执行 show technical-support 命令的输出
通过使用 案例更新工具 ( 只适用于 注册客户) 进行加载，您可以将信息附在案例后面。如果您不能访问案例更新工具，您可以将信息以电子邮件附件的形式发往 attach@cisco.com ，在所发信息的主题行标明案例号，从而将相关信息附在案例中发送。注：?/B>在收集上述信息之前请不要手工重新启动或加电启动路由器（除非恢复网络正常运行需要），因为这可能会导致确定故障根本原因所需重要信息的丢失。 上一页 [1] [2] [3] |
