本帖最后由 SPOTO 于 2012-6-20 14:50 编辑
排查上海电信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 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 Cat4kMgmt LoPriCat4k Mgmt HiPri和Cat4kMgmt LoPri两个进程的原理:当某个进程占用CPU时间没有超过规定的CPU分配时间时,Cat4k Mgmt HiPri进程便会接管这个进程;而当Cat4k平台上某项进程占用CPU超出了应分配的CPU时间时,Cat4k Mgmt LoPri进程会接管这项进程,使其他进程能够得到CPU时间。
(2) 通过show platform health发现两个进程占的CPU比较多:K5L3UnicastAdj Tabl 23.50K5L2Hardware Addre 29.73再往下,发现PacketBufRaw偏高, Allocation ceiling Currentallocation ------------------ ------------------ kbytes % in use kbytes % in useLinecard 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%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%VbufNodes64 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 Receivedat CPU per Input Interface比其他端口都来的大
(4) 通过sh int | i protocol|rate|broadcasts 检查G2/21端口流量正常,但是收到的广播包和组播包异常,(G2/11和G2/22用二层捆绑在一起,但是G2/22收包很小):GigabitEthernet2/21is up, line protocol is up (connected) Queueing strategy: fifo5 minute input rate 4648000 bits/sec, 1405packets/sec5 minute output rate 4940000 bits/sec, 1643packets/sec Received 3059562 broadcasts (2946637multicasts)
(补充:有2种方法可以查看是哪些数据包导致了cpu利用率过高。方法1:#monitor session 1 source cpu
#monitor session 2 destination interface gigabitEthernet x/x 之后拿个笔记本接到gi口上,再开个抓包工具就ok了。方法2:#debug platform packetall receive buffer
#sho platform cpu packet buffered )
(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) 给出建议进行生成树主、备根倒换测试,故障排除。
TOP:
后记:1.排错的时候顺藤摸瓜,先定位出故障产生的节点在哪,然后一步步往下排错。
2.描绘出整个TOP很关键,这个项目刚开始是客户给的TOP,根据他的TOP分析的时候遇到很多地方卡住,原理解释不通,后来自己根据设备的配置和状态重新把TOP描绘出来,才发现之前客户TOP环境搞错了……
文章来源:雏鹰部落
更多的视频和分享,请继续关注雏鹰部落 bbs.spoto.net
或者关注SPOTO微博:
新浪微博:http://e.weibo.com/spoto
腾讯微博:http://t.qq.com/spotoer
视频回顾:
SPOTO CCNP教学视频4.0_Switch系列之Introducing Campus Network Design
SPOTO CCNP学习视频之路由OSPF特殊区域及LSA详解
【CCNP视频】路由 第1天(上午)路由选择原理2
|