交换机利用率高处理

交换机 CPU 利用率达到 73% 且出现网络掉线，虽然排除了环路和 MAC 漂移，但 forward、syslogd、drvsdkd 这三个进程的高负载指向了问题的关键。forward 负责数据转发，syslogd 管理日志，drvsdkd 通常与特定业务驱动相关，它们的异常升高通常意味着设备正在被海量“必须由 CPU 处理”的报文冲击，或是内部任务异常。

核心排查思路是：从“转发面”和“控制面”双管齐下，定位并隔离异常流量来源，同时检查设备内部任务与配置。

一、先搞懂这三个进程分别是什么
表格
进程名 核心作用 高 CPU 的典型原因
forward 报文转发核心进程（L2/L3 转发、ACL、QoS） 突发大流量、异常报文攻击、硬件转发异常导致软转发激增
syslogd 系统日志进程 日志量暴增（频繁日志 /debug）、日志主机不可达导致队列堆积
drvsdkd 设备驱动 SDK 进程（与硬件芯片交互） 芯片 / 接口异常、大量硬件中断、驱动异常
你现场的掉线 / 重认证问题，和这三个进程的高 CPU 直接相关：CPU 高会导致 ARP / 认证报文处理超时、BPDU/keepalive 丢包，进而引发重认证、业务中断。
二、第一步：紧急降负载（先恢复业务）
1. 立刻停掉 syslog 日志转发
syslogd 高 CPU，大概率是日志主机不可达，导致大量日志堆积在设备队列里反复重试。
plaintext
# 关闭所有日志主机配置（先停掉转发）
undo info-center loghost all
# 降低日志级别，只保留warning及以上
info-center source default channel loghost level warning
info-center source default channel console level error
# 关闭不必要的debug（你说debug关了，再确认一次）
undo terminal debugging
undo debugging all
执行后，syslogd 占用会立刻下降，远程管理卡顿会缓解。
2. 关闭不必要的功能，减轻 forward 进程压力
plaintext
# 关闭未使用的QoS策略
undo qos apply policy all global
# 关闭未使用的ACL统计
undo traffic-statistic all
# 关闭不必要的流量统计
undo port-security traffic-statistic
三、第二步：按进程逐个排查根因
1. 排查 forward 进程（23%+，最高）
（1）确认是否有异常流量 / 攻击
plaintext
# 看接口流量，找异常高的接口
display interface brief
display interface traffic
# 看是否有大量未知单播/广播
display mac-address
display cpu-defend statistics
若某接口流量异常大，或 CPU-defend 里有大量 ARP/ND/ICMP 报文，说明存在ARP 欺骗 / 泛洪攻击。
处理：在该接口配置 anti-arp-spoofing enable，或临时 shutdown 排查。
（2）确认是否硬件转发异常，被迫走软转发
plaintext
display ip forwarding hardware
display ip routing-table hardware
display acl hardware
若提示 “部分表项未下发硬件”，说明 ACL / 路由表项过多，导致 CPU 参与转发，forward 进程暴增。
处理：优化 ACL，删除无用规则，减少表项数量。
（3）排查是否有环路（你说没有，但再确认）
plaintext
display stp brief
display stp abnormal
display mac-address flapping
重点看是否有端口频繁学习 MAC，或 STP 状态频繁变化，这会导致 forward 进程反复处理 BPDU 和 MAC 地址表。
2. 排查 syslogd 进程（15%）
（1）看日志量是否暴增
plaintext
display info-center statistics
display info-center rate-limit
若日志速率远超设备上限（如 > 100 条 / 秒），说明存在频繁触发的日志（如端口 up/down、认证失败）。
处理：找到频繁 up/down 的接口，排查线缆 / PoE 供电问题。
（2）确认日志主机状态
plaintext
ping 日志主机IP
display info-center loghost all
若日志主机不可达，设备会不断重试发送，导致队列堆积，CPU 占用飙升。
处理：要么修复日志主机，要么先删掉日志主机配置。
3. 排查 drvsdkd 进程（18%）
（1）看硬件接口 / 芯片状态
plaintext
display device
display interface transceiver
display fan
display power
看是否有接口报错、光模块异常、风扇 / 电源告警，这些都会导致驱动进程反复处理硬件中断。
（2）看芯片错误统计
plaintext
display interface error
display cpu-defend hardware
若接口有大量 CRC 错误、帧错误，说明物理链路异常，导致驱动进程反复处理错误报文。
处理：更换线缆 / 光模块，排查对端设备。
四、第三步：常见组合场景判断
表格
进程组合 最可能的根因 优先处理动作
forward + syslogd 双高 接口频繁 up/down，同时产生大量日志 先修复链路，再清理日志
forward + drvsdkd 双高 硬件转发异常 / 接口错误报文过多 排查接口错误、光模块，重启芯片 / 接口
三个进程同时高 设备整体资源耗尽（表项过多 + 日志堆积 + 硬件异常） 先停日志转发，再优化表项，最后排查硬件
五、第四步：根治与预防
日志优化：日志主机必须可达，日志级别设为 warning 及以上，避免 debug 日志长期开启。
硬件转发优化：ACL/QoS 策略尽量简化，避免大量表项导致无法下发硬件。
安全加固：开启 ARP 防欺骗、端口安全，防止泛洪攻击。
固件升级：如果是老版本，优先升级到官方推荐稳定版，修复驱动 / 转发进程的已知 CPU 占用 bug