步骤1、检查CPU进程信息，查看是否存在特殊进程占用导致CPU利用率增高。
检查方法：
执行命令show cpu, 连续3次获取CPU利用率信息（间隔5S执行一次）。
检查标准：
1. 检查输出结果中是否存在5Sec内CPU利用率较高的进程，且在连续3次的收集过程中均发现此进程利用率较高。（某进程CPU利用率达到20%及以上时，通常可定义为较高）
对于CPU占用率较高的进程的含义不太清晰的可以联系4008111000获取支持。
解决方法：
由于CPU进程在执行过程中耗费大量CPU资源且无法释放，将导致CPU利用率增高。
可执行的的解决方案包括：
1) 临时关闭某软件功能（前提是关闭此功能不会导致客户正常业务受到影响，且此类动作需征求客户同意方可执行）：例如：在SNMP进程CPU利用率100%导致业务异常时，可尝试关闭SNMP代理，rl_con功能占用CPU利用率较高，通常可关闭console口输出log功能调整。
2) 使用ACL过滤进程相关报文的来源：例如通过ACL关联SSH/SNMP，过滤异常攻击SSH、SNMP报文来源，解决异常SSH/SNMP报文导致CPU高的问题。
3) 对于CPU异常时，同时查看CPP统计是否异常（CPP是保护CPU的功能，CPP异常时通常CPU利用率也异常)，如果CPP统计异常可按照步骤２，检查CPP统计发现异常的优化策略执行。
4) 对于其他通常上述方法均无法恢复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、端口的对应关系或端口镜像捉包确认）
寻找异常报文来源的方法：
1) 通过查看LOG，查看syslog中的日志提示信息是否包含异常报文源（IP、MAC地址）。
2) 通过镜像可疑端口的报文，获取异常报文源（IP、MAC地址），当端口报文量过大时，可采取基于流的镜像或使用Wireshark的过滤功能进行过滤。
3) 通过查看交换机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）及以上版本支持）