Cisco4506R CPU过高排错
作者：Winford
“生命需要奋斗，乃至挣扎”
版本 V1.0 编写人 日期 备注 Winford 2011-12-2 初稿
1
这两天排查上海电信XXXX Cisco4506R CPU过高的Case，稍微整理一下排错过程。
客户反映，系统本月12号上线，13号发现4506-A的CPU利用率过高，大概在60%左右，偶尔会飙升到90%以上，对网络负担过重，而4506-B的CPU利用率维持在正常10%左右，需要对现象进行分析与排查。客户提供两条线索：1. 之前部署了PBR，是否因为PBR导致CPU过高？
2．在4506上开debug发现，内网有一台双网卡的主机发包比较异常，是否可以 通过禁用网卡来测试。
由于客户网络比较重要，我并没登入权限，所以整理了排错需要的命令，由网管抓取相应信息：
show version show power show module
show environment status show Redundancy show vlan show ip ospf nei show ip bgp sum show memory sho process cpu sho process cpu | ex 0.00 sho platform health
sho platform cpu packet statistics sho platform cpu packet buffered sh int | i protocol|rate|broadcasts show int count errors show ip int br show int show int trunk show run
2
show logging show spanning
show spanning-tree blockedports show spanning-tree root show spanning-tree summary show spanning-tree inconsistentports show errdisable detect show errdisable recovery
排错过程：
（1） 通过sho process cpu | ex 0.00 发现两个进程CPU占用率比较高： 2.71% 3.24% 3.01% 0 Cat4k Mgmt HiPri 27.03% 34.26% 36.14% 0 Cat4k Mgmt LoPri
Cat4k Mgmt HiPri和Cat4k Mgmt LoPri两个进程的原理：当某个进程占用CPU时间没有超过规定的CPU分配时间时，Cat4k Mgmt HiPri进程便会接管这个进程;而当Cat4k平台上某项进程占用CPU超出了应分配的CPU时间时，Cat4k Mgmt LoPri进程会接管这项进程，使其他进程能够得到CPU时间。 （2） 通过show platform health发现两个进程占的CPU比较多： K5L3Unicast Adj Tabl 23.50 K5 L2 Hardware Addre 29.73 再往下，发现PacketBufRaw偏高，
Allocation ceiling Current allocation ------------------ ------------------
kbytes % in use kbytes % in use Linecard 1's Store 2560.00 3% 88.31 100% Linecard 2's Store 2560.00 12% 311.93 100% Linecard 3's Store 2560.00 12% 311.93 100% Linecard 4's Store 2560.00 0% 0.00 0% Linecard 5's Store 2560.00 0% 0.00 0% Linecard 6's Store 2560.00 29% 753.71 100%
3
TSM objects ------------------ ------------------
PacketInfoItem 781.25 0% 0.78 0% VbufNodes2400 80.50 0% 0.00 0% VbufNodes1600 55.50 0% 3.46 0% VbufNodes400 288.00 0% 2.81 80% VbufNodes 60.00 0% 0.46 0% VbufNodes4200 68.37 25% 17.09 100% PacketBufRaw 184.29 100% 184.29 100% PacketBufRaw 5938.31 100% 5938.31 100% RkiosSysPacketBuf 250.00 0% 1.09 0% Packet 2208.98 0% 50.19 0%
（3） 通过sho platform cpu packet statistics发现端口G2/21的Packets
Received at CPU per Input Interface比其他端口都来的大
（4） 通过sh int | i protocol|rate|broadcasts 检查G2/21端口流量正常，但
是收到的广播包和组播包异常，（G2/11和G2/22用二层捆绑在一起，但是G2/22收包很小）：
GigabitEthernet2/21 is up, line protocol is up (connected) Queueing strategy: fifo
5 minute input rate 48000 bits/sec, 1405 packets/sec 5 minute output rate 4940000 bits/sec, 13 packets/sec Received 3059562 broadcasts (2946637 multicasts)
(补充：有2种方法可以查看是哪些数据包导致了cpu利用率过高。
方法1：
#monitor session 1 source cpu
#monitor session 2 destination interface gigabitEthernet x/x 之后拿个笔记本接到gi口上，再开个抓包工具就ok了。 方法2：
#debug platform packet all receive buffer #sho platform cpu packet buffered )
4
（5） 通过show int count errors检查并无发现有错误包
（6） 根据相关信息，描绘出了网络拓扑结构，并进行分析，发现断了
4506-A与SW-B之间的一条链路，生成树block状态发生改变(即正常情况下block的是SW-B和SW-A之间的链路，当断了4506-A与SW-B之间的一条链路，此时block的是4506-A和SW-B之间的链路，因为两条链路捆绑的二层COST和单根链路的二层COST值是不一样的)，CPU也降下来了，进一步发现生成树的根在4506-B，而HSRP的主在4506-A，二层和三层的根没有重叠在一起，有可能有PBR的情况下，导致流量穿越的时候绕了一圈。
（7） 给出建议进行生成树主、备根倒换测试，故障排除。
现网拓扑图：
5