交换机cpu负载90%以上（二）
一.背景介绍：
来到这个公司2个多月，就又遇到了一起“交通事故”，交换机cpu90%以上，公司的人上公网，访问idc数
据总是出现丢包的情况，公司使用的都是cisco的设备 ，接入有2960，2950，3560交换机，core 是4506交换
机，防火墙是juniper， 出口路由器是routeros；
在长寿等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站制作、网站建设 网站设计制作按需定制制作,公司网站建设,企业网站建设,品牌网站建设,营销型网站建设,外贸网站建设,长寿网站建设费用合理。
二.案例赏析
雪飘人间分享案例之cpu负载90%以上（二）
如上是网络的部分拓扑图，由于是办公生产网络，并且有内部server数据，所以整个拓扑图无权限展现出
来，不过这将完全不影响我们展现问题所在；
首先在接到同事反映网速慢时，我就采用分段隔离法，逐级测试外网地址 ，最终确定是我们自己内部到网
关就有问题；这个可不好排查了，因为不是所有人到网关都有问题，其实绝大多数到网关都没有问题
当时的判断是某个接入交换机到核心交换机线路有问题，要是这个问题的话，那就不好搞了 ，因为办公网是从
1996年就开始成立了 ，线路老化也是非常有可能的，要真的是线路的问题，那么换线是非常麻烦的事情
了，但是后来仔细观察发现，丢包同事的pc机器并不都在一台交换机上，而是分布在很多台上，这个就可以排
除是线路老化造成的了，因为线路老化不可能同一时间很多条线路都老化了；问题变得越来越棘手
当时考虑最近有没有上什么新的业务导致办公网流量徒增造成的，但是事实是没有上新业务，和往常一样，
于是我就利用我们的监控Cacti查看这台核心交换机的流量图，发现交换机在和防火墙对接的口流量非常的大
而我们的防火墙又是现上的；看来就是防火墙和交换机之间的连线问题了，在这个之前我们也用wireshark抓
包看过内网流量，发现除了大量的budp，没有其他的异常流量
我看了下防火墙到交换机的两条线路，防火墙本身是个1000兆的接口 ，但是交换机基本上都是百兆的接口
千兆接口少之又少，而且基本上都被占用，并且防火墙和交换机对接的有一个线是千兆，而另一根线是百兆
的，看来是流量阻塞造成的了
过程是这样的，内网网关放在防火墙上，流量经交换机二层到防火墙，然后再由防火墙经由交换机到路由
器，由于进到防火墙是个千兆，所以很多流量都能过去，但是防火墙将流量转发的交换机上的时候，交换机却
用百兆网口去接收，导致交换机接口的利用率达到了100%，然后交换机采用cpu去计算，这样交换机的cpu自
然会升高
后来我是在交换机上找了个千兆口接在防火墙，cpu下去了，丢包现象消失
事情到此任然没有结束，let‘s go ！
当我再次查看cpu的时候，发现cpu利用率还是很高：雪飘人间分享案例之cpu负载90%以上（二）
通过查看其进程发现是Cat4k Mgmt LoPri 非常的高，这里的HiPri代表是处理高优先级的进程，LoPri代
表处理低优先级的进程，LoPri 值比较大原因是因为进程超过了HiPri给定的Target，然后交给了LoPri来处理
最终才带来了LoPri值比较大的问题：雪飘人间分享案例之cpu负载90%以上（二）
我开始再次查看cpu的进程（show platform health）
雪飘人间分享案例之cpu负载90%以上（二）
这条命令是能够查看时哪个进程占用了大量cpu：
intra# sh platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
K2PortMan Review 2.00 2.81 15 11 100 500 2 2 2 8242:09
Gigaport0 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
Gigaport1 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
Gigaport2 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
Gigaport3 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
K2FibPerVlanPuntMan 2.00 0.00 15 2 100 500 0 0 0 0:00
K2FibFlowCache flow 2.00 0.02 10 8 100 500 0 0 0 195:34
K2FibFlowCache flow 2.00 54.00 10 8 100 500 58 65 45 41846:36
K2FibFlowCache adj r 2.00 0.09 10 4 100 500 0 0 0 280:52
可以看到 其他的值Target的值是比Actual大的，但是K2FibFlowCache flow 是不正常的，查看
官网对应的解释：
雪飘人间分享案例之cpu负载90%以上（二）
这个值之所以大是因为，PBR在作怪，我们核心交换机上确实配置了PBR做特别需求处理，当我把
PBR给去掉了时候，再次查看K2FibFlowCache flow雪飘人间分享案例之cpu负载90%以上（二）
发现这个值立刻就下去了，然后在看看CPU 雪飘人间分享案例之cpu负载90%以上（二）
三.总结结论
1.对于交换机的cpu升高有很多种因素造成，排查起来相对困难
2.排查cpu故障时，如果是突然的升高，那么也要从好几个方面排查，主要是看最近业务有没有变动，架构有
没有变动，配置有没有变动等，有可能是误操作导致，当然老的机器还有可能是硬件出现故障
3.一般来说流量徒增，对交换机cpu影响是比较大的，比如交换机接口转发流量，×××流量等等
4.官网也有很多对于cpu升高问题处理解决办法，在解决问题时还要结合其他有用的资源，比如本例中的流量
监控工具Cacti
