S9306 TC报文导致的CPU利用率过高问题分析

发布时间:  2014-10-15 浏览次数:  1913 下载次数:  0
问题描述
设备:S9306 v200r001c00spc300
现象:93作为核心交换机,下接多台S2700设备串联。出现93 CPU 极高现象,最高时候达86%,其中进程L2占用率很高。


<Quidway>dis cpu-usage
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage            : 63% Max: 97%
CPU Usage Stat. Time : 2013-10-14  12:59:44
CPU utilization for five seconds: 63%: one minute: 70%: five minutes: 76%
Max CPU Usage Stat. Time : 2013-09-03 11:41:51.

TaskName        CPU  Runtime(CPU Tick High/Tick Low)  Task Explanation
BOX                   0%         0/  7dc3e1       BOX Output
_TIL                  0%         0/       0       Infinite loop event task
_EXC                  0%         0/       0       Exception Agent Task
VIDL                 37%         3/a57d5956       DOPRA IDLE
TICK                  0%         0/ 76f2dfe
CLKI                  0%         0/       0       CLKI
DEV                   0%         0/  e01463       DEV  Device
bcmRX                 2%         0/482c58ec       bcmRX
CHAL                  0%         0/       0       CHAL
........
NFPT                  0%         0/  fb771b       NFPTNFP timer task
SOCK                  4%         0/77421bdd       SOCKPacket schedule and
                                                  process
VTRU                  0%         0/       0       VTRUNK
FIB                   0%         0/       0       FIB Forward Information Base
MFIB                  0%         0/   14f80       MFIBMulticast forward info
........
LINK                  0%         0/  567ee7       LINK
STP                   2%         0/398171c5       STP
VRPT                  0%         0/  15c9a1       VRPT
HOTT                  0%         0/       0       HOTT
TNQA                  0%         0/  93d9dc       TNQAC
TTNQ                  0%         0/    4dcf       TTNQAS
TARP                  0%         0/       0       TARPING
TTVP                  0%         0/       0       TTVPLS
L2                   28%         2/d49006f3       L2
VRRP                  0%         0/ 11a845a       VRRP
L2_P                  0%         0/ 228d86e       L2_PR
ARP                   0%         0/       0       ARP
NTPT                  0%         0/  18fda2       NTPT task
SIMC                  0%         0/       0       SIMC
RMON                  0%         0/  183584       RMONRemote monitoring
IFLP                  0%         0/  27e00f       IFLP
bcmD                  0%         0/       0       bcmD
VT                    0%         0/       0       VT
OS                   12%         1/2c684bff       Operation System

告警信息
设备频繁报CPU超过阀值告警,其中L2占用大部分CPU利用率。

Oct 12 2013 11:09:53 Quidway %%01VOSCPU/4/CPU_USAGE_HIGH(l)[401]:The CPU is overloaded(CpuUsage=83%, Threshold=80%), and the tasks with top three CPU occupancy are:
L2  total      : 28%
AGNT  total      : 19%
FTS  total      : 7%
处理过程
1.首先排查占用CPU利用率较多的L2进程,L2 是负责二层业务任务统一调度,推测是由于2层报文转发过多导致此进程占用大量CPU利用率。2层报文转发过多有几种原因,比如网络中有环路或者攻击导致。
2.逐一排查93各个端口接收发送包状态,端口带宽占用率正常,双工,速率也正常,也无异常包或者丢包现象。
3.通过dis cpu-defend stat all 查看各类型包的情况,发现arp-request , stp ,arp-miss包很多,arp-miss并带有丢包现象。推断可能是由于下行网络有arp-miss攻击或者网络中有环路导致STP拓扑频繁变更,上送过多arp-miss报文到CPU处理导致CPU占用率高。

===============display cpu-defend statistics all===============
=====================================================================
Statistics on mainboard:
-------------------------------------------------------------------------------
Packet Type         Pass(Bytes)  Drop(Bytes)   Pass(Packets)   Drop(Packets)
-------------------------------------------------------------------------------
8021x                         0            0               0               0
arp-miss             1315259166     18786028         5604572           37058
arp-reply                     0            0               0               0
arp-request          4674372475            0        72894580               0
........
-------------------------------------------------------------------------------
Statistics on slot 2:
-------------------------------------------------------------------------------
Packet Type         Pass(Bytes)  Drop(Bytes)   Pass(Packets)   Drop(Packets)
-------------------------------------------------------------------------------
arp-miss             1279304525   4085882190         5264433         6232524
arp-reply             280426368            0         4381662               0
arp-request           142522752       204800         2226918            3200
....
Statistics on slot 5:
-------------------------------------------------------------------------------
Packet Type         Pass(Bytes)  Drop(Bytes)   Pass(Packets)   Drop(Packets)
-------------------------------------------------------------------------------
arp-miss               54849601     49766065          377197          371364
arp-reply            2728684764   5087133288        42509587        78922750
arp-request          4926858011   242701534k        76739151      3791991270
dhcp-client                   0            0               0               0
.....

4.查看CPU告警信息,发现并无arp,ip,mac地址方面的告警提示。
5.查看STP状态,发现发现设备其中2个端口 gi5/0/2 和 g5/0/12 收到了大量的TC/TCN(拓扑变更,拓扑变更通知)报文,其他端口此报文数量很少。意味着这两个端口下接的设备或者终端出现了多次拓扑变化,导致arp表不断刷新,占用了CPU大量资源。正常网络在稳定情况下是不会频繁发生拓扑变化的。

----[Port51(GigabitEthernet5/0/2)][FORWARDING]      ---- 端口gi5/0/2
Port Protocol       :Enabled
Port Role           :Designated Port
Port Priority       :128
Port Cost(Dot1T )   :Config=auto / Active=20000
Designated Bridge/Port   :32768.7054-f59b-b9f0 / 128.51
...
TC or TCN send      :286608
TC or TCN received  :275797    ----- TC/TCN 包为275797
BPDU Sent           :1776079          

----[Port61(GigabitEthernet5/0/12)][FORWARDING]----  ---- 端口gi5/0/12
Port Protocol       :Enabled
Port Role           :Root Port
.....
TC or TCN send      :1345
TC or TCN received  :2838   ----- TC/TCN 包为2838
BPDU Sent           :1347          

但是还不确定这个数据是不是历史累计数据,还需观察查看数据是否有增加。

经过在3分钟内多次采集STP状态数据,发现发现设备其中2个端口 gi5/0/2 和 g5/0/12 在3分钟之内分别收到了TC/TCN(拓扑变更,拓扑变更通知)包100多个,意味着这两个端口下接的设备或者终端出现了100多次拓扑变化,导致arp表不断刷新,占用了CPU大量资源。正常网络在稳定情况下是不会频繁发生拓扑变化的。由此判定这两个接口下接的设备可能存在环路或者攻击导致拓扑不断变更并发送TC报文。

----[Port51(GigabitEthernet5/0/2)][FORWARDING]      ---- 端口gi5/0/2
Port Protocol       :Enabled
....
TC or TCN send      :286608
TC or TCN received  :275797    ----- TC/TCN 包为275797
BPDU Sent           :1776079           

----[Port61(GigabitEthernet5/0/12)][FORWARDING]----  ---- 端口gi5/0/12
Port Protocol       :Enabled
Port Role           :Root Port
Port Priority       :128
...
TC or TCN send      :1345
TC or TCN received  :2838   ----- TC/TCN 包为2838 
BPDU Sent           :1347           


----[Port51(GigabitEthernet5/0/2)][FORWARDING]----  ---- 端口gi5/0/2
Port Protocol       :Enabled
Port Role           :Designated Port
...
TC or TCN send      :286722
TC or TCN received  :275914   ----- TC/TCN 包变为275914 
BPDU Sent           :1776196           
          TCN: 0, Config: 1733229, RST: 0, MST: 42967
BPDU Received       :1721081           
          TCN: 3, Config: 1721078, RST: 0, MST: 0

----[Port61(GigabitEthernet5/0/12)][FORWARDING]----  ---- 端口gi5/0/12
Port Protocol       :Enabled
Port Role           :Root Port
Port Priority       :128
Port Cost(Dot1T )   :Config=auto / Active=20000
...
TC or TCN send      :1403
TC or TCN received  :2960   --------- TC/TCN 包变为2960  
BPDU Sent           :1405           
          TCN: 1403, Config: 0, RST: 0, MST: 2
BPDU Received       :2960           
          TCN: 0, Config: 2960, RST: 0, MST: 0   

临时解决方案:
1、配置如下命令:
stp converge normal(交换机默认配置,如之前无配置stp converge fast , 无需配置)
控制arp刷新速率
2、在设备持续10分钟以上连续收到TC报文的场景中,所有版本均需要配置TC保护,从而抑制设备在单位时间(默认2s)内处理的TC报文的数量,配置命令如下:
stp tc-protection命令用来使能MSTP进程对TC类型BPDU报文的保护功能。
stp tc-protection threshold 1命令用来配置MSTP进程在收到TC类型BPDU报文后,单位时间内,处理TC类型BPDU报文并立即刷新转发表项的阈值。
3、设备频繁删除MAC的性能,在S9300 V100R002SPH012补丁、S9300 V100R001SPH018补丁都做了优化,请打上相应的补丁。

根源解决方案:

将下接gi5/0/2 和gi5/0/12的交换机的所有接用户端口(边缘端口),配置上stp edged-port enable 命令,保证用户侧的所有接口都不发送TC/TCN变更报文引起网络变化。
问题也有可能出现在gi5/0/2和gi5/0/12下接的交换机上,需另行排查为什么下接的交换机拓扑老变化,比如有链路不稳定,单通,生成树配置不正确等原因,也有可能是对接的设备配置生成树模式为PVST导致。原因比较多,需要在了解网络拓扑和配置的情况下排查。

首先通过临时解决方案,成功将CPU的利用率较低到了正常范围阀值内,但环路或者攻击依然存在,经过多次物理环路排查和抓包排查,发现下接端口的SourceIP=10.10.52.98这个地址频繁发送arp请求,推测为问题主机,尝试关掉此端口,观察一段时间后TC/TCN报文无大幅度增长现象,拓扑稳定,问题解决。
根因
经过多次物理环路排查和抓包排查,发现下接端口的SourceIP=10.10.52.98这个地址频繁发送arp请求,推测为问题主机,尝试关掉此端口,观察一段时间后TC/TCN报文无大幅度增长现象,拓扑稳定,问题解决。
解决方案
临时解决方案:
1、配置如下命令:
stp converge normal(交换机默认配置,如之前无配置stp converge fast , 无需配置)
控制arp刷新速率
2、在设备持续10分钟以上连续收到TC报文的场景中,所有版本均需要配置TC保护,从而抑制设备在单位时间(默认2s)内处理的TC报文的数量,配置命令如下:
stp tc-protection命令用来使能MSTP进程对TC类型BPDU报文的保护功能。
stp tc-protection threshold 1命令用来配置MSTP进程在收到TC类型BPDU报文后,单位时间内,处理TC类型BPDU报文并立即刷新转发表项的阈值。
3、设备频繁删除MAC的性能,在S9300 V100R002SPH012补丁、S9300 V100R001SPH018补丁都做了优化,请打上相应的补丁。

根源解决方案:

将下接gi5/0/2 和gi5/0/12的交换机的所有接用户端口(边缘端口),配置上stp edged-port enable 命令,保证用户侧的所有接口都不发送TC/TCN变更报文引起网络变化。
问题也有可能出现在gi5/0/2和gi5/0/12下接的交换机上,需另行排查为什么下接的交换机拓扑老变化,比如有链路不稳定,单通,生成树配置不正确等原因,也有可能是对接的设备配置生成树模式为PVST导致。原因比较多,需要在了解网络拓扑和配置的情况下排查。

首先通过临时解决方案,成功将CPU的利用率较低到了正常范围阀值内,但环路或者攻击依然存在,经过多次物理环路排查和抓包排查,发现下接端口的SourceIP=10.10.52.98这个地址频繁发送arp请求,推测为问题主机,尝试关掉此端口,观察一段时间后TC/TCN报文无大幅度增长现象,拓扑稳定,问题解决。
建议与总结
建议与总结: 在应对交换机CPU利用率过高的问题上,首先最好在故障刚发生时采集dis diag信息,其中关键是1,dis cpu-usage关于CPU利用率的信息,从中可以发现哪个进程占用率高,再查看相关进程的说明,找准正确的方向继续定位问题;2,dis cpu-defend stat all 信息,该信息有助于我们快速判断是哪种报文占用过多CPU,由此可对于此报文做相应的CPU防护策略,比如利用cpu car限制报文上送CPU的速率,利用黑名单排查或限制问题IP及问题报文等措施来临时解决问题,将CPU利用率降低到可接受的阀值保证网络的正常运转,特别是在现网环境中,先恢复再排查尤为重要。这样可以为后续的排查获取时间。

一般导致CPU过高的原因大致为2类:环路和攻击。如需彻底根除问题,需在了解整网拓扑的情况下从物理链路上到交换机配置上,再到终端设备上都要逐一排查。此时可以充分利用dis logbuffer查看交换机的告警信息给排查提供线索,一般CPU超过阀值时交换机便会出现很有价值的告警信息,及时关注有助于高效的排查问题。


END