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

交换机cpu负载90%以上(二)
一.背景介绍:
来到这个公司2个多月,就又遇到了一起“交通事故”,交换机cpu90%以上,公司的人上公网,访问idc数
据总是出现丢包的情况,公司使用的都是cisco的设备 ,接入有2960,2950,3560交换机,core 是4506交换
机,防火墙是juniper, 出口路由器是routeros;

在长寿等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供网站制作、网站建设 网站设计制作按需定制制作,公司网站建设,企业网站建设,品牌网站建设,营销型网站建设,外贸网站建设,长寿网站建设费用合理。

二.案例赏析
交换机cpu负载90%以上(二)【新任帮主】
雪飘人间分享案例之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


当前名称:交换机cpu负载90%以上(二)【新任帮主】
链接URL:http://scyanting.com/article/jghdcc.html