交换机cpu负载90%以上（二）【新任帮主】

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