电脑计算机论坛

 找回密码
 注册

QQ登录

只需一步,快速开始

查看: 252|回复: 0

华为S5700 TC报文导致CPU占用率高排查案例

[复制链接]
admin 发表于 2024-7-14 15:34:02 | 显示全部楼层 |阅读模式
问题描述:
某客户反馈企业网络中有一台S5700交换机CPU异常,PU占用率达到百分之90以上,出现告警信息。


告警信息:
执行命令display cpu-usage,查询S5700的CPU信息,S5700最近曾出现CPU升高的记录,CPU占用率最高达到了97%。
<S5700> display cpu-usage
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage            : 18% Max: 97%
CPU Usage Stat. Time : 2014-10-07  11:19:29
CPU utilization for five seconds: 18%: one minute: 18%: five minutes: 18%
Max CPU Usage Stat. Time : 2014-09-11 16:37:54.

查询设备日志,有大量TC报文日志产生:
Oct  7 2014 11:06:20-05:13 S5700 %%01INFO/4/SUPPRESS_LOG(l)[15]Last message repeated 1 times.(InfoID=1092489232, ModuleName=MSTP, InfoAlias=RECEIVE_MSTITC)
Oct  7 2014 11:05:19-05:13 S5700 %%01INFO/4/SUPPRESS_LOG(l)[16]Last message repeated 3 times.(InfoID=1092489232, ModuleName=MSTP, InfoAlias=RECEIVE_MSTITC)
Oct  7 2014 11:04:12-05:13 S5700 %%01INFO/4/SUPPRESS_LOG(l)[17]Last message repeated 3 times.(InfoID=1092489232, ModuleName=MSTP, InfoAlias=RECEIVE_MSTITC)

处理过程:
因未在故障时采集信息,无法知道具体哪些进程引起CPU升高,设备一直产生TC报文日志,首先确定此TC报文是本设备产生的,还是从其它设备收到的。
使用display stp tc-bpdu statistics命令查询TC报文是在S5700设备产生的,还是从其它设备收到的。经查询S5700与SwitchA互连的端口GigabitEthernet0/0/52收到的TC报文一直增长,且同时转发至其它接入层交换机。由此可以判断该TC报文不是S5700设备产生的。
<S5700> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port                        TC(Send/Receive)      TCN(Send/Receive)
0     GigabitEthernet0/0/51       29272/63              0/0
0     GigabitEthernet0/0/52       3/18363               0/0

使用display stp tc-bpdu statistics命令逐层排查TC报文入方向设备,确认此TC报文是在网络中的哪一台设备上产生的。
查询核心设备SwitchA,发现Eth-Trunk1收到大量的TC报文,而Eth-Trunk1是与核心设备SwicthB互联的,由此可以判断该TC报文不是SwitchA产生的。
<SwitchA> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port                        TC(Send/Receive)      TCN(Send/Receive)
0     GigabitEthernet0/0/1        16754/7               0/0
0     GigabitEthernet0/0/2        17112/1               0/0
0     GigabitEthernet0/0/3        17462/11              0/0
0     GigabitEthernet0/0/4        17793/4               0/0
0     GigabitEthernet0/0/5        18118/5               0/0
0     GigabitEthernet0/0/6        18415/3               0/0
0     GigabitEthernet0/0/14       17791/3               0/0
0     GigabitEthernet0/0/15       18113/6               0/0
0     GigabitEthernet0/0/16       18435/4               0/0
0     Eth-Trunk1                  4/11010               0/0
继续查询核心设备SwitchB,发现GigabitEthernet0/0/2端口收到大量的TC报文,而GigabitEthernet0/0/2端口是与S4设备的GigabitEthernet0/0/52互联,由此可以判断该TC报文不是SwitchB产生的。
<SwitchB> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port                        TC(Send/Receive)      TCN(Send/Receive)
0     GigabitEthernet0/0/1        12495/13               0/0
0     GigabitEthernet0/0/2        135/8349               0/0
0     GigabitEthernet0/0/3        13430/19               0/0
0     GigabitEthernet0/0/4        13784/14               0/0
0     GigabitEthernet0/0/5        14200/17               0/0
0     GigabitEthernet0/0/6        14687/10               0/0
0     GigabitEthernet0/0/14       14164/16               0/0
0     GigabitEthernet0/0/15       14164/16               0/0
0     GigabitEthernet0/0/16       14625/12               0/0
0     Eth-Trunk1                  11012/4               0/0

继续查询S4设备,发现GigabitEthernet0/0/51、GigabitEthernet0/0/52端口Send方向大量的TC报文计数增涨,初步判断TC报文由应由此设备产生。
<S4> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port                        TC(Send/Receive)      TCN(Send/Receive)
0     GigabitEthernet0/0/51       8196/1123             0/0  
0     GigabitEthernet0/0/52       8343/136              0/0

当查询到S4设备时,发现其TC报文只有在出方向上不断有增长计数,由此可判断该TC报文为S4设备产生。此时执行命令display stp topology-change查询该TC报文的信息。从以下回显可以看出,该设备GigabitEthernet0/0/51端口不断由阻塞变为放开后,由于状态变为detected而触发拓扑变化。
<S4> display stp topology-change
CIST topology change information
   Number of topology changes             :8233
   Time since last topology change        :0 days 0h:0m:26s
   Topology change initiator(detected)    :GigabitEthernet0/0/51
   Number of generated topologychange traps :   9852
   Number of suppressed topologychange traps:   13

执行命令display interface brief查询该接入设备端口信息,发现该设备GigabitEthernet0/0/51端口入方向有大量错包,隔一段时间后,再次查询该设备的端口信息,GigabitEthernet0/0/51端口入方向还是有大量错包。由此说明此接口入方向光纤线缆有问题,排查线缆故障后问题解决。
<S4> display interface brief
PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(E): E-Trunk down
(b): BFD down
(e): ETHOAM down
(dl): DLDP down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface                   PHY   Protocol InUti OutUti   inErrors  outErrors   
........
GigabitEthernet0/0/51       up    up       0.01%  0.02%   38068638          0

问题根原:
STP组网中,与STP计算的设备互连端口因链路质量不好,导致设备STP频繁收敛,产生大量TC报文,导致收到此TC报文的设备部分CPU升高,影响业务正常运行。
解决方案:
排查S3设备与S4设备之间的链路故障原因。
建议与总结:
在参与STP计算的核心设备上,全局配置stp tc-protection命令,配置后可以保证设备频繁收到TC报文时,每2秒周期内最多只处理1次表项刷新。从而减少MAC、ARP表项频繁刷新对设备造成的负担。

您需要登录后才可以回帖 登录 | 注册

本版积分规则


QQ|手机版|小黑屋|电脑计算机论坛 ( 京ICP备2022023538号-1 )

GMT+8, 2024-11-23 12:54 , Processed in 0.094716 second(s), 22 queries .

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表