注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

北边的风

IT 钓鱼 养生

 
 
 

日志

 
 

【转载】cisco4506e交换机CPU占用率高分析过程 (cisco4500交换机CPU高解决方法)  

2016-09-22 21:12:29|  分类: IT心得 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

作者:roy

一、组网图

cisco4506e交换机CPU占用率高排查报告 - 勇敢的心 - 勇敢的心
 组网说明:

为了实现容灾,组网图中的设备都是双机。网络设备型号:cisco 4506-E交换机、Radware 4016负载均衡器、Juniper SRX3400防火墙、H3C F5000防火墙。服务器代表服务器集群,每台服务器做双网卡绑定,每台服务器可以通过SW10-1--SW01与外部通讯,或者通过SW10-2---SW02--SW01与外部通讯,两台cisco4506HSRPHSRP的虚拟路由器是SW01-cisco4506e

二、问题描述

巡检发现,两台cisco 4506-E交换机在忙时和闲时CPU占用率都是99%,但经过主用4506(SW01-cisco4506e)的网络流量大约1Gbps,网络流量不大,所以怀疑cisco 4506不正常,怀疑有网络问题。

三、正确的排查思路

1.查看cisco 4506 cpu占用率

show process cpu

2.查看哪些进程CPU占用率比较高

show process cpu 查看CPU占用率,查看每个进程的CPU占用率

show processes cpu sorted 查看每个进程的CPU利用率,并按照CPU利用率排序输出。

3、查看哪些进程CPU占用率超过基线值

show platform health

此命令会显示Cat4k Mgmt HiPri and Cat4k Mgmt LoPri两个平台下的每个平台进程占用CPU的基线值和实际值,若实际值超过基线值,平台进程异常,再查平台进程的含义,即可知道是何种原因。

4.查看CPU数据包统计信息

show platform cpu packet statistics

通过此命令能查看到经过CPU处理的数据包的统计信息,一般能看到CPU队列异常。

5.查看经过CPU处理的数据包(查看哪些具体数据包导致CPU利用率异常)

个人认为对CPU做镜像并抓包、debug能快速定位原因,只是CPU占有率99%时,建议在业务闲时debug,以免4506宕机。

方法1

镜像CPU数据包,抓包分析经过CPU处理的数据包。

4506(config)#monitor session 1 source cpu

4506(config)#monitor session 1 destination interface gigabitEthernet 1/1

附:镜像CPU的某个队列的方法

Switch(config)#monitor session 1 source cpu queue ?

  <1-32>          SPAN source CPU queue numbers

  acl             Input and output ACL [13-20]

  adj-same-if     Packets routed to the incoming interface [7]

  all             All queues [1-32]

  bridged         L2/bridged packets [29-32]

  control-packet  Layer 2 Control Packets [5]

  mtu-exceeded    Output interface MTU exceeded [9]

  nfl             Packets sent to CPU by netflow (unused) [8]

  routed          L3/routed packets [21-28]

  rpf-failure     Multicast RPF Failures [6]

  span            SPAN to CPU (unused) [11]

  unknown-sa      Packets with missing source address [10]

Switch(config)#monitor session 1 source cpu queue all rx

Switch(config)#monitor session 1 destination interface gigabitethernet 1/3

 

方法2

debug查看CPU处理的数据包。

#debug platform packet all receive buffer

#show  platform cpu packet buffered

cisco官网 cisco4500 交换机CPU利用率高排查思路

cisco4506e交换机CPU占用率高排查报告 - 勇敢的心 - 勇敢的心

四、实际排查过程

4.1 备用4506 CPU利用率高处理过程

根据朋友建议,查看cisco 4506SW10交换机的日志。

查看两台cisco4506e日志:

show logging没发现异常。

查看所有SW10交换机日志:

show logging alarm发现MAC地址漂移。

SW10-Kyj4-7Solt#show logging  alarm

 An alarm 22789 level 6 occurred at 22:55:19 01/21/2003 UTC  sent by MCP %MAC% 

 <MAC 0019.C69A.D29C VLAN 30> From  Port gei_1/18 To  Port smartgroup1

 An alarm 22789 level 6 occurred at 22:55:19 01/21/2003 UTC  sent by MCP %MAC% 

 <MAC 0019.C69A.D29C VLAN 30> From  Port smartgroup1 To  Port gei_1/18

 An alarm 22789 level 6 occurred at 22:55:18 01/21/2003 UTC  sent by MCP %MAC% 

 <MAC 0019.C69A.D29C VLAN 30> From  Port gei_1/18 To  Port smartgroup1

An alarm 22789 level 6 occurred at 22:55:18 01/21/2003 UTC  sent by MCP %MAC% 

 <MAC 0019.C69A.D29C VLAN 30> From  Port smartgroup1 To  Port gei_1/18

 

从上面日志可以看出,MAC地址0019.C69A.D29C gei_1/18smartgroup1(聚合链路口1)这两个端口漂移,即MAC地址漂移。

经进一步确认,MAC地址0019.C69A.D29C10.197.151.73 这台linux服务器的。

查看10.197.151.73的双网卡绑定状态,如下图:

查看双网卡绑定状态,发现eth2/eth3两张网卡都是运行状态,MAC地址在这两个网卡上漂移,这说明双网卡绑定得有问题(正常绑定结果是一主一备),检查双网卡绑定配置并修改为正确配置,修改后,双网卡状态如下:

修改此服务器的双网卡配置并重启网络服务后,备用4506 CPU利用率立即由99%下降到13%,问题排除。

问题总结:MAC地址漂移,导致cisco4506交换机CPU占用率99%

4.2 主用4506  CPU利用率高处理过程

4.2.1查看所有服务器的双网卡绑定是否存在问题

鉴于4.1的故障原因(双网卡绑定不正确可能导致MAC地址漂移进一步导致cisco4506 CPU99%),逐一检查所有服务器的双网卡绑定是否存在问题,经确认,其它服务器双网卡绑定完全正确。

4.2.2.查看cisco 4506 cpu占用率

命令:show process cpu

SW01#show processes cpu

CPU utilization for five seconds: 97%/2%; one minute: 97%; five minutes: 87%

 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

   1      593958 181806901          3  0.00%  0.00%  0.00%   0 Chunk Manager   

   2      227358  18176328         12  0.00%  0.00%  0.00%   0 Load Meter      

   3           0         1          0  0.00%  0.00%  0.00%   0 CEF RP IPC Backg

后续输出省略。。。。。。

查看cisco4506 cpu利用率发现,cisco 4506(SW01) CPU占用率97%

4.2.3查看cisco4506哪些进程CPU占用率比较高

命令:show process cpu

GZGY-PS-WAP-SW01#show processes cpu

CPU utilization for five seconds: 97%/2%; one minute: 97%; five minutes: 84%

 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

  59   472183013 670676807        704  3.91%  3.82%  3.85%   0 Cat4k Mgmt HiPri

  60  15494857531809021628       856  91.35% 91.48% 78.54%   0 Cat4k Mgmt LoPri

发现Cat4k Mgmt LoPri进程CPU占用率非常高(91.48%),说明某些进程占用CPU时间超过了应分配的CPU时间。

Cat4k Mgmt HiPriCat4k Mgmt LoPri进程原理:

当某个进程占用CPU时间没有超过规定的CPU分配时间时,Cat4k Mgmt HiPri进程会接管这个进程;而当Cat4k平台上某项进程占用CPU超出了应分配的CPU时间时,Cat4k Mgmt LoPri进程会接管这项进程,使其他进程能够得到CPU时间。

4.2.4查看cisco4506哪些平台进程CPU占用率超过基线值

命令:show platform health

(此命令会显示Cat4k Mgmt HiPri and Cat4k Mgmt LoPri两个平台下的每个平台进程占用CPU的基线值和实际值,若实际值超过基线值,平台进程异常,再查平台进程的含义,即可知道是何种原因)

使用此命令观察,在Cat4k Mgmt HiPri and Cat4k Mgmt LoPri平台下,平台的具体进程使用CPU的情况。每一个平台进程有一个CPU利用率目标值或者期望值。如果某一个平台进程CPU利用率在期望值内,CPU将以高优先级执行这个进程。如果某一个平台进程CPU利用率超过目标值,此平台进程将在低优先级下运行,且show process cpu将在Cat4k Mgmt LoPri平台下输出额外的CPU利用率。

SW01#   show platform health

                     %CPU   %CPU    RunTimeMax   Priority  Average %CPU  Total

                     Target Actual Target Actual   Fg   Bg 5Sec Min Hour  CPU

其它进程省略。。。。。。

K5CpuMan Review       30.00  93.64     30     15  100  500  162 144  107  287329:06

其它进程省略。。。。。。

show platform health发现K5CpuMan Review进程基线值是30%,实际值是93.64%。查询cisco官网资料发现如下解释:

K5CpuMan Review平台进程描述

The process that performs software packet forwarding. This job also en-queues and extracts packets from CPU packet queues.If you see high CPU utilization due to this process, this typically indicates that the high CPU is caused by traffic.

翻译:

K5CpuMan Review进程处理软件转发数据包。。。。。。。如果你看到由于这个平台进程导致CPU利用率高,则表明CPU利用率高是流量引起的。

4.2.5.查看cisco4506 CPU数据包统计信息

show platform cpu packet statistics

通过此命令能查看到经过CPU处理的数据包的统计信息,一般能看到哪种队列的流量异常。

SW01#    show platform cpu packet statistics

RkiosSysPacketMan:

Packet allocation failures: 0

Packet Buffer(Software Common) allocation failures: 0

Packet Buffer(Software ESMP) allocation failures: 0

Packet Buffer(Software EOBC) allocation failures: 0

Packet Buffer(Software SupToSup) allocation failures: 0

IOS Packet Buffer Wrapper allocation failures: 0

 

Packets Dropped In Processing Overall

Total                5 sec avg 1 min avg 5 min avg 1 hour avg

-------------------- --------- --------- --------- ----------

        236745431788     26818     29513     20215      28026

 

Packets Dropped In Processing by CPU event

Event             Total                5 sec avg 1 min avg 5 min avg 1 hour avg

----------------- -------------------- --------- --------- --------- ----------

Sa Miss                   236745431754     26818     29513     20215      28026

L3 Receive                           1         0         0         0          0

Input Acl Fwd                        5         0         0         0          0

Sw Packet for Bridge                   28         0         0         0          0

 

Packets Dropped In Processing by Priority

Priority          Total                5 sec avg 1 min avg 5 min avg 1 hour avg

----------------- -------------------- --------- --------- --------- ----------

Normal                               6         0         0         0          0

Medium                    236745431782     26818     29513     20215      28026

 

Packets Dropped In Processing by Reason

Reason             Total                5 sec avg 1 min avg 5 min avg 1 hour avg

------------------ -------------------- --------- --------- --------- ----------

STPDrop                          143016         0         0        33         12

NoDstPorts                           28         0         0         0          0

Tx Mode Drop               236745288744     26818     29510     20176      28013

Total packet queues 64

         

Packets Received by Packet Queue

 

Queue                  Total           5 sec avg 1 min avg 5 min avg 1 hour avg

---------------------- --------------- --------- --------- --------- ----------

Input ACL fwd(snooping)            1852         0         0         0          0

Host Learning             235043348386     26382     29284     20023      27558

L2 Control                   283551890         0         0         0          0

Ttl Expired                  108483289         1         0         0          0

Adj SameIf Fail             7643561581         0         0         0          0

L2 router to CPU, 7          672973416         5         0         3          4

L3 Glean, 7                   49574057         0         0         0          0

L3 Fwd, 7                  32458057327         5         2         4          8

L3 Receive, 7                 21091960         3         0         0          0

 

Packets Dropped by Packet Queue

Queue                  Total           5 sec avg 1 min avg 5 min avg 1 hour avg

---------------------- --------------- --------- --------- --------- ----------

Host Learning               1029792472         0         0         6       2104

L2 Control                         152         0         0         0          0

Ttl Expired                        209         0         0         0          0

Adj SameIf Fail             3105169164         0         0         0          0

L2 router to CPU, 7            1067795         0         0         0          0

L3 Glean, 7                     172609         0         0         0          0

L3 Fwd, 7                      1196132         0         0         0          0

GZGY-PS-WAP-SW01#

show platform health发现CPU队列(Packets Received by Packet Queue )中Host Learning 队列数据异常。经查询cisco官网文档,Host Learning队列含义:为了建立L2(二层)转发表(即MAC地址表),将包含未知源MAC地址的数据帧被复制给CPU。这就说明cisco4506在不断地学习源MAC地址。

4.2.6查看经过CPU处理的数据包(查看哪些数据包导致CPU利用率异常)

个人认为抓包和debug能快速定位原因,只是CPU占有率99%时,建议在业务闲时debug,以免4506宕机。

方法1

镜像CPU的数据,抓包分析经过CPU处理的数据包。

4506(config)#monitor session 1 source cpu

4506(config)#monitor session 1 destination interface gigabitEthernet x/1

方法2

debug查看CPU处理的数据包。

#debug platform packet all receive buffer

#show  platform cpu packet buffered

 

方法1镜像CPU的数据并抓包,进行数据包分析

cisco4506e交换机CPU占用率高排查报告 - 勇敢的心 - 勇敢的心
 抓包分析结论

抓包分析发现,经过cisco 4506的数据包,绝大部分数据包特征如下:

目的地址都是10.197.151.20,源MAC00:10db:ff:10:01,目的MAC:00:00:5e:00:01:65

方法2 debug数据包分析

SW01#show platform cpu packet buffered

Total Received Packets Buffered: 1024

-------------------------------------

Index 0:

1048 days 6:53:31:968625 - RxVlan: 10, RxPort: Gi6/29

Priority: Medium, Tag: No Tag, Event: Sa Miss, Flags: 0x40, Size: 64

Eth: Src 00:10:DB:FF:10:01 Dst 00:00:5E:00:01:65 Type/Len 0x0800

Ip: ver:IpVersion4 len:20 tos:0 totLen:40 id:39415 fragOffset:0 ttl:61 proto:tcp

    src: 10.164.42.6 dst: 10.197.151.20 firstFragment lastFragment

Remaining data:

 0: 0xCB 0xF1 0x0  0x50 0x11 0xCC 0xF  0x4  0xF6 0x65

10: 0xA4 0xA3 0x50 0x10 0x18 0x15 0x39 0x21 0x0  0x0 

20: 0x0  0x0  0xCD 0x55 0xA  0x94 0xC4 0x24 0x27 0xDC

Index 1:

1048 days 6:53:31:968701 - RxVlan: 10, RxPort: Gi6/29

Priority: Medium, Tag: No Tag, Event: Sa Miss, Flags: 0x40, Size: 64

Eth: Src 00:10:DB:FF:10:01 Dst 00:00:5E:00:01:65 Type/Len 0x0800

Ip: ver:IpVersion4 len:20 tos:0 totLen:40 id:49510 fragOffset:0 ttl:62 proto:tcp

    src: 10.227.52.190 dst: 10.197.151.20 firstFragment lastFragment

Remaining data:

 0: 0xC3 0x8F 0x0  0x50 0x74 0x8  0x7E 0x56 0x9F 0xF9

10: 0x98 0xB1 0x50 0x10 0x23 0xD7 0xBB 0x99 0x0  0x0 

20: 0x0  0x0  0x99 0xEF 0xA  0x93 0xC7 0xED 0x7C 0x11 

Index 2:

1048 days 6:53:31:969186 - RxVlan: 10, RxPort: Gi6/30

Priority: Medium, Tag: No Tag, Event: Sa Miss, Flags: 0x40, Size: 583

Eth: Src 00:10:DB:FF:10:01 Dst 00:00:5E:00:01:65 Type/Len 0x0800

Ip: ver:IpVersion4 len:20 tos:0 totLen:565 id:46322 fragOffset:0 ttl:61 proto:tcp

    src: 10.164.182.134 dst: 10.197.151.20 firstFragment lastFragment

Remaining data:

 0: 0xCB 0xBE 0x0  0x50 0xF5 0x2B 0xB1 0xBD 0x57 0x46

10: 0x55 0x13 0x50 0x18 0x35 0xE8 0x3E 0x2F 0x0  0x0 

20: 0x6D 0x65 0x74 0x68 0x6F 0x64 0x3D 0x74 0x6F 0x6B

Index 3:

1048 days 6:53:31:969274 - RxVlan: 10, RxPort: Gi6/30

Priority: Medium, Tag: No Tag, Event: Sa Miss, Flags: 0x40, Size: 78

Eth: Src 00:10:DB:FF:10:01 Dst 00:00:5E:00:01:65 Type/Len 0x0800

Ip: ver:IpVersion4 len:20 tos:0 totLen:60 id:1323 fragOffset:0 ttl:62 proto:tcp

    src: 10.231.255.126 dst: 10.197.151.20 firstFragment lastFragment

Remaining data:

 0: 0xDF 0xFC 0x0  0x50 0xC3 0xA3 0x8B 0x7F 0x0  0x0 

10: 0x0  0x0  0xA0 0x2  0x6B 0x8  0x73 0x46 0x0  0x0 

20: 0x2  0x4  0x5  0x5A 0x4  0x2  0x8  0xA  0x0  0xB 

 后续输出省略。。。。。。

debug分析:

1、从源地址00:10:DB:FF:10:01到目的地址00:00:5E:00:01:65数据包,被gei_6/29gei_6/30两个端口随机接收到。而cisco 4506gei_6/29gei_6/30 SW01-cisco4506 FW01-JuniperSRX3400的两条物理链路,且同属于vlan 10

2、在cisco 4506上查看00:10:DB:FF:10:01 MAC学习情况

1分钟之内反复执行show mac address-table address 0010.dbff.1001命令,发现SRX3400MAC(0010.dbff.1001)gei6/30gei6/29间反复切换,即MAC地址漂移。

SW01#show mac address-table address 0010.dbff.1001

Unicast Entries

 vlan   mac address     type        protocols               port

-------+---------------+--------+---------------------+--------------------

  10    0010.dbff.1001   dynamic ip                    GigabitEthernet6/30  

SW01#show mac address-table address 0010.dbff.1001

Unicast Entries

 vlan   mac address     type        protocols               port

-------+---------------+--------+---------------------+--------------------

  10    0010.dbff.1001   dynamic ip                    GigabitEthernet6/30  

SW01#show mac address-table address 0010.dbff.1001

Unicast Entries

 vlan   mac address     type        protocols               port

-------+---------------+--------+---------------------+--------------------

  10    0010.dbff.1001   dynamic ip                    GigabitEthernet6/29  

SW01#show mac address-table address 0010.dbff.1001

Unicast Entries

 vlan   mac address     type        protocols               port

-------+---------------+--------+---------------------+--------------------

  10    0010.dbff.1001   dynamic ip                    GigabitEthernet6/30  

3、检查cisco4506 gei6/29gei6/30配置

cisco 4506 gei6/29gei6/30配置:

interface GigabitEthernet6/29

 description #SRX_FE_3#

 switchport access vlan 10

interface GigabitEthernet6/30

 description #SRX_FE_4#

 switchport access vlan 10

 

备用cisco4506CPU利用率99%问题 分析总结

根据debug信息、CPU抓包信息、MAC地址漂移现象和cisco 4506gei_6/29gei_6/30配置,确定要么是sw01-cisco 4506FW01-JuniperSRX3400间存在网络环路,要么是MAC地址漂移导致导致cisco 4506交换机CPU利用率99%。经查看FW01-SRX3400配置,FW01-SRX3400上是三层接口且启用链路聚合,而cisco 4506gei6/29gei6/30端口没有启动链路聚合,所以cisco 4506交换机CPU利用率99%的问题原因是:cisco 4506不断地学习源MAC,导致CPU利用率高。

解决办法:

gei6/29gei6/30端口做链路聚合(链路捆绑),捆绑后cisco CPU利用率由99%下降到10%左右。

五、问题回顾

两台cisco 4506-E交换机CPU占有率99%,都是由于MAC地址漂移,导致数据帧被复制给CPU,导致CPU 占用率99%。那为什么cisco 4506交换机上有MAC地址漂移,为什么show logging日志中没有相关记录?

六、导致交换机CPU利用率高的可能原因

1MAC地址漂移

2、启用生成树时,HSRP/VRRP的主用和生成树的主根不在同一台设备上,导致流量绕了一圈,导致CPU利用高

3、双网卡绑定异常

4、网络环路,导致广播风暴或者帧复制

5、策略路由

七、参考文章

1、 基于IOS平台的cisco4500 交换机 CPU利用率高案例分析

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/65591-cat4500-high-cpu.html

此文章详细讲解了cisco IOS平台交换机CPU利用率高问题排查思路、CPU架构原理、CPU队列原理,强烈建议根据此文章思路排查cisco 4500系列交换机CPU利用率高问题。

2VDI核心交换机CPU利用率高分析报告

http://blog.sina.com.cn/s/blog_4ca83f8301015357.html

3、百度文库cisco_4500__high_CPU

4Cisco4506R_CPU过高排错.pdf

作者: Winford,文章来源:百度文库

  评论这张
 
阅读(29)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016