交换机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