锐捷交换机CPU利用率高排查SOP

SE_You

2025-3-13

交换机

一、故障现象

通过show cpu发现，整机cpu利用率异常增高至80%-100%，可能导致设备CLI响应慢、ping设备丢包或延迟大、协议振荡等异常现象。

备注：对于CPU利用率超过日常平均值较多（例如20%-30%），但尚未达到80%以上，尚未对业务造成影响的故障，需要关注是否CPU属于持续增高或非常短暂的增高，通常情况下对于短暂（例如1-2秒）CPU利用率增高的情况建议继续观察即可。

二、可能原因

CPU收到大量某些特殊的异常协议报文（TTL=1、ARP DOS攻击、DHCP报文、IGMP报文等）
路由协议/STP协议/VRRP/BFD等邻居协议频繁震荡，协议重新计算消耗CPU资源
物理环路，在部分设备不支持CPP的情况下，大量报文冲击CPU。
某进程在执行过程中耗费较多CPU资源无法释放。（例如SNMP读取设备相关MIB，设备打印大量Syslog，大量用户瞬间web认证）
CPU收到某些报文触发后，需要发送大量协议报文（例如存在不断扫描某VLAN内不存在的用户地址，导致交换机发送大量ARP请求）。

三、故障处理步骤

步骤1: 检查CPU进程信息是否异常

检查方法：

执行命令show cpu, 连续3次获取CPU利用率信息（间隔5S执行一次）。

检查标准：

检查输出结果中是否存在5Sec内CPU利用率较高的进程，且在连续3次的收集过程中均发现此进程利用率较高。（某进程CPU利用率达到20%及以上时，通常可定义为较高）

对于CPU占用率较高的进程的含义不太清晰的可以联系4008111000获取支持。

解决方法：

由于CPU进程在执行过程中耗费大量CPU资源且无法释放，将导致CPU利用率增高。

可执行的的解决方案包括：

1) 临时关闭某软件功能（前提是关闭此功能不会导致客户正常业务受到影响，且此类动作需征求客户同意方可执行）：例如：在SNMP进程CPU利用率100%导致业务异常时，可尝试关闭SNMP代理，rl_con功能占用CPU利用率较高，通常可关闭console口输出log功能调整。

使用ACL过滤进程相关报文的来源：例如通过ACL关联SSH/SNMP，过滤异常攻击SSH、SNMP报文来源，解决异常SSH/SNMP报文导致CPU高的问题。
对于CPU异常时，同时查看CPP统计是否异常（CPP是保护CPU的功能，CPP异常时通常CPU利用率也异常)，如果CPP统计异常可按照步骤２，检查CPP统计发现异常的优化策略执行。
对于其他通常上述方法均无法恢复CPU利用率的场景，按照步骤２继续分析排查。

常见进程CPU占比高问题解决方法：

常见的CPU利用率较高进程解释说明：（提示：对于CPU占用率较高的进程的含义不太清晰的可以咨询4008-111-000获得更多信息。）

tnet/tnet6：IPv4/IPV6栈接收报文的进程，如果该进程cpu占用率高的话，可能原因是ARP/ND报文或送CPU处理的IPv4/IPV6报文比较多。

处理方法：查看CPP统计信息，根据步骤2检查CPP统计信息发现异常的优化策略执行。

ssp_flow_rx_task：数据报文收包进程，该进程cpu占用率高的话，多数原因是数据报文送CPU过多导致的，通过查看cpp信息可以进一步了解送CPU的报文信息。

处理方法：查看CPP统计信息，根据步骤2 检查CPP统计信息发现异常的优化策略执行。

snmpd ：SNMP进程占用CPU过多，该进程cpu占用率高的话，通常为大量SNMP报文送CPU或SNMP获取设备某MIB节点占用CPU较多。

处理方法：

1）、暂时关闭SNMP代理 no enable service snmp-agent

//关闭SNMP会导致网管暂时无法管理设备，存在802.1x/WEB认证，SNMP作为关键配置删除可能导致用户无法认证，实施前需要得到客户确认。

2）、或SNMP关联ACL只允许合法的SNMP服务器访问，

配置ACL，只允许制定的服务器可以进行SNMP访问：

ip access-list standard trust-snmp

10 permit 172.18.252.0 0.0.0.255

20 permit 172.18.126.0 0.0.0.255

将ACL应用到SNMP：

Ruijie(config)#snmp-server community ruijie rw trust-snmp

rl_con：控制台进程，用于处理console口输出的进程，该进程cpu占用率高的话，通常为log信息输出过多。

处理方法：可尝试关闭console口的日志输出功能，Ruijie(config)#no logging console

或限制日志的输出速率， Ruijie(config)# logging rate-limit all 10 except emergencies

pimd/pim6d ：组播进程，用于igmp/pim协议报文，该进程cpu占用率高的话，通常为大量未知组播报文送CPU。

处理方法：调整CPP协议类型的限速值，部署防组播源欺骗组播优化。

对于S26E，S29E，S3250E，S3760E，S5750，S7600，S8600，S12000系列交换机（简称A类交换机）A类交换机：

Ruijie(config)#cpu-protect type unknown-ipmc pps 30

Ruijie(config)#cpu-protect type unknown-ipmcv6 pps 30

对于S26I，S29XS-P，S5750E, S6000，S78系列交换机，（简称B类交换机）B类交换机：

Ruijie(config)#cpu-protect type unknown-v4mc bandwidth 30

Ruijie(config)#cpu-protect type unknown-v6mc bandwidth 30

防组播源欺骗ACL（可过滤PC端发生的非法组播报文）

组播缺省没有任何安全策略，当前PC安装的众多软件都会发出组播报文，极易造成组播报文的全网泛洪，同时消耗设备组播资源表项及CPU资源，凡部署组播的网络均需要部署组播优化策略

使用特定ACL，只允许合法的组播源及组播目标的报文通过（部署在下联用户的Trunk口上或SVI上），无论PIM-DM模式或PIM-SM模式均需整网部署

优化方法（IPV4示例）：

Ruijie(config)#ip access-list extended deny_mc_source

Ruijie(config-ext-nacl)#10 permit igmp any any //允许所有IGMP

Ruijie(config-ext-nacl)#20 permit ip 219.229.134.0 0.0.0.255 239.202.0.0 0.0.255.255

//允许合法的组播源及组播目标（需要依据客户网络中所允许的合法组播源及目标更新此条目)

Ruijie(config-ext-nacl)#30 deny ip any 224.0.0.0 15.255.255.255

//拒绝所有组播流

Ruijie(config-ext-nacl)#40 permit ip any any

//允许所有IPV4报文

若需要和原有应用在端口或SVI上的ACL整合，只需要将上述防组播欺骗ACL中ACE 40及之前的内容替换为原有ACL中的ACE即可。

如果对接口上原有ACL和防组播欺骗ACL的整合不确认，请致电4008-111-000获取帮助。

ef_res：邻居解析进程，该进程占用率高，通常为存在IP扫描或频繁的ARP老化和删除（多为STP收到TC引起）。

处理方法：针对扫描行为，可以部署交换机防扫描功能来进行改善。

· 支持NFPP的交换机：（IP-guard功能默认开启，在部分场景中此功能被关闭的可以尝试重新开启）

Step 1 Ruijie(config)#nfpp 进入NFPP 配置模式。

Step 2 Ruijie(config-nfpp)#ip-guard enable 全局打开IP 防扫描功能，缺省情况下打开。

Step 3 Ruijie#show nfpp ip-guard hosts 查看已被检测到攻击的主机

对于NFPP的硬件隔离功能（默认不开启）如需开启，需要跟客户沟通明确在IP扫描的情况下，开启硬件隔离，判断为攻击的PC端会导致无法通讯（默认隔离10分钟）

· 不支持NFPP的交换机，一般均支持system-guard功能（和NFPP中的IP-Guard功能一致）

Step 1 Ruijie(config)#interface interface-id（路由口）

Step 2 Ruijie(config-interface)#system-guard enable 打开IP 防扫描功能，缺省情况下未开启。

Step 3 Ruijie#show system-guard isolated-ip 查看已被检测到攻击的主机

对于攻击的源头如果需要找到并解决，则需要定位攻击源端口（通过IP、ARP、MAC、端口的对应关系或端口镜像捉包确认）

寻找异常报文来源的方法：

通过查看LOG，查看syslog中的日志提示信息是否包含异常报文源（IP、MAC地址）。
通过镜像可疑端口的报文，获取异常报文源（IP、MAC地址），当端口报文量过大时，可采取基于流的镜像或使用Wireshark的过滤功能进行过滤。
通过查看交换机ARP表、MAC表找出异常报文对应的来源交换机端口。

针对STP拓扑频繁震荡的问题，可以尝试在收到TC报文的端口上临时部署TC-Guard功能/TC ignore功能，再寻找TC报文的来源进行彻底解决，网络恢复后需删除临时优化方案。

tc-guard:（10.4(3)之前版本可使用）

Ruijie(config-if)# spanning-tree tc-guard

tc ignore:（10.4（3）及以上版本支持，tc-guard功能的优化） ---推荐使用

Ruijie(config-if)# spanning-tree ignore tc （10.4（3）及以上版本支持）

步骤2: 检查CPP统计信息是否异常

检查方法：

对于S26E，S29E，S3250E，S3760E，S5750，S7600，S8600，S12000系列交换机（简称A类交换机）

查看CPP命令如下：show cpu-protect mb，需连续3-5次收集（间隔5S收集一次）

对于S26I，S29XS-P，S5750E, S6000，S78系列交换机，（简称B类交换机）

查看CPP命令如下: show cpu-protect，需连续3-5次收集（间隔5S收集一次）

对于不支持查看具体CPP各种类型协议的实时统计的产品（例如S21，S23，S29，S3760，S5760）可跳过此排查步骤。

检查标准：

检查协议报文是否存在大量DROP且持续递增的情况。例如某历史故障案例中TTL=1的报文持续递增。

· 如果存在众多协议报文出现快速增长的DROP，且报文实时速率（PPS）非常大，通常为网络中出现了环路，可以转入步骤4进行分析和排查。

· 如果存在部分这样的协议报文，代表网络中出现了异常的协议报文且报文量非常大，可以按照下文解决方案中的优化策略进行优化并观察效果。

检查是否存在某类协议报文虽然没有存在大量DROP，但报文实时速率（PPS）较大，且此类报文按照网络正常的预期并不会达到此速率。

为了适应不同规模大小的网络，在设备CPU性能能够处理的压力下，默认报文速率限制都有一定余量的设计，例如unknow-ipmc未知组播默认限速128pps

但如果在一个健康的网络中，未知组播报文的速率应非常小（例如3pps）。如果客户现场达到30-100PPS，虽然没有实时的丢弃（DROP），通常也会导致CPU利用率增高。

· 如果存在部分这样的协议报文，代表网络中出现了异常的协议报文且报文量较大，可以按照下文解决方案中的优化策略进行优化并观察效果。

· 如果CPU某进程异常时，CPP相关的报文统计方面也不存在明显异常（或无法独立分析），转入步骤4.3进一步分析和排查

备注：

如何查看设备默认的报文限速值（A类交换机：show cpu-protect summay B类交换机：show cpu-protect )

解决方法：

根据协议报文的类型“适当”调整报文的限速值，适当的判定标准为预估正常网络环境中，此类报文的速率。

为了避免报文调整过小，导致正常的协议报文交互受到限制，建议调整的原则为：

1）先减少50%，例如原默认限速为128pps，可修订为64pps，观察是否有改善，CPU降低到50%以下时，通常无需再行调整CPP限速值，而应该寻找异常报文的根源彻底问题。CPP的限速仅是出现问题后的规避策略，根源办法是寻找出异常报文源。

2）对于网络中可能大量存在且重要的报文：ARP报文，BPDU报文，OSPF报文不做修订限速标准，一旦修订过小，将可能导致正常的协议报文被丢弃。

调整CPP限速具体方法：

对于S26E，S29E，S3250E，S3760E，S5750，S7600，S8600，S12000系列交换机（简称A类交换机）

Ruijie(config)#cpu-protect type ip4-packet-local pps 50

对于S5750E, S6000，S78系列交换机，（简称B类交换机）， S26I，S29XS-P 10.4（3b16）及以上版本支持。

Ruijie(config)#cpu-protect type local-other bandwidth 50

当以上解决方法均无法解决问题时，请参照步骤3继续进行排查。

常见问题解决方法：

对于CPP统计中，较常见的几种报文速率增高原因及解决方法如下：

1.nd-snp-ns-na：IPV6主机发出的路由/邻居解析报文，在主机发生软件中毒等异常时，经常会发现存在大量异常报文冲击导致CPU利用率增高。

处理方法：减少以上报文的限速值，并查找报文的来源（方法见下文描述）

例如：

A类交换机：

S86、12000默认限速10000pps，可尝试按照50%递减的方法，建议最小值限速约为在线IPV6用户数的1/2。

Ruijie(config)#cpu-protect type nd-snp-ns-na pps 1000

S5750及其他，建议最小值限速约为在线IPV6用户数的1/2。

Ruijie(config)#cpu-protect type nd-snp-ns-na pps 100

B类交换机：

Ruijie(config)#cpu-protect type nd bandwidth 200

寻找异常报文来源方法：

通过查看LOG，查看syslog中的日志提示信息是否包含异常报文源（IP、MAC地址）。
通过镜像可疑端口的报文，获取异常报文源（IP、MAC地址），当端口报文量过大时，可采取基于流的镜像或使用Wireshark的过滤功能进行过滤。
通过查看交换机ARP表、MAC表找出异常报文对应的来源交换机端口。

2.unknown-ipmc、unknown-ipmcv6： 未知组播报文送CPU，在开启组播的情况下，PC端发出的异常组播报文经常会导致设备CPU利用率增高。

处理建议：减少以上报文的限速值，并部署防组播源欺骗ACL。

A类交换机：

Ruijie(config)#cpu-protect type unknown-ipmc pps 30

Ruijie(config)#cpu-protect type unknown-ipmcv6 pps 30

B类交换机：

Ruijie(config)#cpu-protect type unknown-v4mc bandwidth 30

Ruijie(config)#cpu-protect type unknown-v6mc bandwidth 30

防组播源欺骗ACL（可过滤PC端发生的非法组播报文）

防组播源欺骗（原理）：使用特定ACL，只允许合法的组播源及组播目标的报文通过（部署在下联用户的Trunk口上或SVI上（端口下如果原有ACL应用，需合并ACE），无论PIM-DM模式或PIM-SM模式均需整网部署

优化方法：

Ruijie(config)#ip access-list extended deny_mc_source

Ruijie(config-ext-nacl)#10 permit igmp any any //允许所有IGMP

Ruijie(config-ext-nacl)#20 permit ip 219.229.134.0 0.0.0.255 239.202.0.0 0.0.255.255

//允许合法的组播源及组播目标（需要依据客户网络中所允许的合法组播源及目标更新此条目)

Ruijie(config-ext-nacl)#30 deny ip any 224.0.0.0 15.255.255.255

//拒绝所有组播流

Ruijie(config-ext-nacl)#40 permit ip any any

//允许所有IPV4报文

若需要和原有应用在端口或SVI上的ACL整合，只需要将上述防组播欺骗ACL中ACE 40及之后的内容替换为原有ACL中的ACE即可。

如果对接口上原有ACL和防组播欺骗ACL的整合不确认，请联系4008111000协助处理。

3.ip4-packet-other，ip6-packet-other （S86、S12000较常见）：其他送CPU的IPV4报文，属于CPP里面已经定义之外的特定报文，通常为扫描报文。

处理建议：减少以上报文的限速值，并查找报文的来源（查找报文的来源方法已在上文中描述，不再赘述）。

Ruijie(config)#cpu-protect type ip4-packet-other pps 50

Ruijie(config)#cpu-protect type ip6-packet-other pps 50

对于缺省没有防IPV6扫描的S5750、S3760E设备，如果存在IPV6的应用且存在IPV6扫描的情况

建议部署自定义NFPP IPV6防护策略：（10.4（3）及以上版本支持自定义NFPP策略）

配置方法如下：

Ruijie(config)#nfpp

Ruijie(config-nfpp)#define ipv6_guard

Ruijie(config-nfpp)#match etype 0x86dd

Ruijie(config-nfpp)#global-policy per-src-ip 10 20

Ruijie(config-nfpp)#define ipv6_guard enable

步骤3: 检查是否存在IP扫描

检查方法：

执行show arp ，show arp counter

Ruijie#sh arp

Internet 125.39.113.32 <---> <Incomplete> arpa GigabitEthernet 0/22

Internet 125.39.113.35 <---> <Incomplete> arpa GigabitEthernet 0/22

Internet 125.39.113.37 <---> <Incomplete> arpa GigabitEthernet 0/22

Internet 125.39.113.38 <---> <Incomplete> arpa GigabitEthernet 0/22

Internet 125.39.113.34 <---> <Incomplete> arpa GigabitEthernet 0/22

Ruijie#sh arp counter

Count of static entries: 1

Count of dynamic entries: 3486 (complete: 3607 incomplete: 221)

Total: 3487

检查标准：

查看ARP表项及ARP统计中是否存在大量未解析(incomplete)的IP，且地址连续。

如果发现网络中存在如上现象，证明网络中存在IP扫描的行为,并可以在1个TRUNK口连接PC捉包确认是否捉到交换机发出的请求不同用户ARP的大量报文。

解决方法：

针对扫描行为，可以部署交换机防扫描功能来进行改善。

· 支持NFPP的交换机：（IP-guard功能默认开启，在部分场景中此功能被关闭的可以尝试重新开启）

Step 1 Ruijie(config)#nfpp 进入NFPP 配置模式。

Step 2 Ruijie(config-nfpp)#ip-guard enable 全局打开IP 防扫描功能，缺省情况下打开。

Step 3 Ruijie#show nfpp ip-guard hosts 查看已被检测到攻击的主机

· 不支持NFPP的交换机，一般均支持system-guard功能（和NFPP中的IP-Guard功能一致）

Step 1 Ruijie(config)#interface interface-id（路由口）

Step 2 Ruijie(config-interface)#system-guard enable 打开IP 防扫描功能，缺省情况下未开启。

Step 3 Ruijie#show system-guard isolated-ip 查看已被检测到攻击的主机对于攻击的源头如果需要找到并解决，则需要定位攻击源端口（通过IP、ARP、MAC、端口的对应关系或端口镜像捉包确认）

通过查看LOG，查看syslog中的日志提示信息是否包含异常报文源（IP、MAC地址）。
通过镜像可疑端口的报文，获取异常报文源（IP、MAC地址），当端口报文量过大时，可采取基于流的镜像或使用Wireshark的过滤功能进行过滤。
通过查看交换机ARP表、MAC表找出异常报文对应的来源交换机端口。

当以上解决方法均无法解决问题时，请参照步骤4继续进行排查。

步骤4: 检查是否存在环路

检查方法：

根据以下特征观察确定是否存在环路：

观察交换机端口大量指示灯同时快速闪烁。
将PC链接trunk口到交换机，PC会收到大量重复报文。
执行show interfaces counters rate 接口（trunk）流量较大且都比较一致。
show mac-address-table 连续3次，MAC地址可能漂移到不同的端口。

检查标准：

1.外观指示灯的闪烁频率和接口的传输速率相关，如果环路会导致二层端口大量收发包，接口指示灯频率一致的快速闪烁。

2.环路的产生是广播报文在VLAN内泛洪，PC接入trunk口会受到环路的报文，捕捉到大量重复的报文，证明环路发生。

查看端口流量，广播流量是否存在明显异常，广播瞬间会引起流量增大，远远超过单播报文，则证明网络中发生了环路。
查看是否存在mac地址频繁变化端口，若存在则可能环路发生。

解决方法：

在发生环路的网络环境中，通过协议自动阻塞环路端口或手动关闭端口去掉环路结构。具体方法如下：

· 通过在接入层交换机防环功能可选方案1：部署RLDP防环功能，观察端口是否被自动errdisable并shutdown。

Ruijie(config)#rldp enable //全局开启RLDP功能

Ruijie(config-if-range)#rldp port loop-detect block //接入用户端口部署RLDP防环。

Ruijie(config-if-range)#spanning-tree bpdufilter enable //配置接口的bpdufilter特性,过滤STP报文带来的影响。

可选方案2：部署portfast+bpduguard方案。

Ruijie(config-if-range)#spanning-tree portfast //接入用户端口部署STP防环

Ruijie(config-if-range)#spanning-tree bpduguard enable //接入用户端口部署STP防环

· 接入层交换机接入用户端口部署广播风暴（storm-control broadcast）,减少环路广播风暴带来的影响。（上联口不用配置）

Ruijie(config-if-range)#storm-control broadcast

· 通过将疑似环路的端口逐一shutdown/插拔，观察现象是否得到缓解。

当以上解决方法均无法解决问题时，请参照步骤5继续进行排查。

步骤5：检查是否存在协议震荡

检查方法：

执行show log /show ip ospf nei，观察OSPF/BFD邻居关系是否频繁中断
执行show spanning-tree summary，（连续3次，每次间隔5S）观察是否存在频繁的拓扑变更

检查标准：

1 判断路由协议(OSPF/BFD）邻居关系是否频繁up/down，可以观察是否存在如下类似的日志信息

OSPF日志

*Aug 9 10:26:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet 0/24, changed state to up.

*Aug 9 10:26:20: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1-GigabitEthernet 0/24 from Down to Init, HelloReceived.

*Aug 9 10:26:50: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1-GigabitEthernet 0/24 from Exchange to Full, ExchangeDone.

*Aug 9 10:27:44: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1-GigabitEthernet 0/24 from Full to Init, 1-WayReceived.

*Aug 9 10:27:55: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1-GigabitEthernet 0/24 from Exchange to Full, ExchangeDone.

BFD日志

140092: *Sep 29 19:21:23: %BFD-6-SESSION_STATE_UP: BFD session to neighbor 10.242.237.82 on interface TenGigabitEthernet 0/21 is up

140093: *Sep 29 19:21:35: %BFD-6-SESSION_STATE_DOWN: BFD session to neighbor 10.242.237.82 on interface TenGigabitEthernet 0/21 has gone down. Reason: Control Detection Time Expired

以上LOG如果非常多，且up/down发生频繁，证明协议存在频繁UP/DOWN.

2 STP是否频繁收到拓扑变更，关注TopologyChanges的次数和时间（红色标记部分）。

Ruijie#show spanning-tree

StpVersion : MSTP <---当前配置的生成树模式

SysStpStatus : ENABLED

MaxAge : 20

HelloTime : 2

ForwardDelay : 15

BridgeMaxAge : 20

BridgeHelloTime : 2

BridgeForwardDelay : 15

MaxHops: 20

TxHoldCount : 3

mst 0 vlans map : ALL <---所有vlan关联在instance0上

BridgeAddr : 001a.a915.5984 <---本机的mac地址

Priority: 4096

TimeSinceTopologyChange : 0d:0h:0m:12s //重点关注上次拓扑变更的时间是否很短

TopologyChanges : 1182 //重点关注拓扑变更的总次数是否持续快速递增

DesignatedRoot : 1000.001a.a915.5984 <---所有域的根桥的mac地址

RootCost : 0

RootPort : 0 <---本机在instance0中选择的根口，如果根桥是本机，则该值为0

CistRegionRoot : 1000.001a.a915.5984 <---instance0在本域内的根桥的mac地址

如果发现拓扑变更的次数快速递增，且上次变更的时间很短，则证明证明网络中存在TC报文产生（生成树拓扑变化），参考协议故障中生成树故障进行分析和定位。

解决方法：

由于接口链路问题导致邻居协议频繁UP/Down的，可以临时将物理接口关闭（shutdown）或关闭动态路由协议观察问题是否解决，或继续深入排查接口链路问题（参考硬件类故障的接口无法Link的故障处理指导）
若发现拓扑存在频繁变更，可以尝试在收到TC报文的端口上临时部署TC-Guard功能/TC ignore功能，再寻找TC报文的来源[方法已在4.1中进行描述]进行彻底解决，网络恢复后需删除临时优化方案。

tc-guard:（10.4(3)之前版本可使用）

Ruijie(config-if)# spanning-tree tc-protection tc-guard //下联接入/汇聚交换机的端口

tc ignore:（10.4（3）及以上版本支持，tc-guard功能的优化） ---推荐使用

Ruijie(config-if)# spanning-tree ignore tc （10.4（3）及以上版本支持，tc-guard功能的优化） //下联接入/汇聚交换机的端口