文章总结： 本文针对交换机CPU飙升问题提供排查方案，指出主因是流量绕过ASIC直冲CPU。建议按确认负载、锁定进程、排查ARP或广播攻击、接口反推、审视配置五步进行。特别介绍了查看Punt流量、CPU中断统计及CoPP命中的三个关键命令。强调避免盲目重启，需定位进程与流量根源解决故障，并加强接入层防护与配置管理以保障网络稳定。 综合评分： 92 文章分类： 网络安全,实战经验,应急响应,解决方案

---

交换机 CPU 飙到 100%？别急着重启，5 个排查步骤+3 个隐藏命令

原创

wljslmz瑞哥

网络技术联盟站

2025年12月25日 09:20 江苏

公众号：网络技术联盟站

在很多人的认知里，交换机=转发芯片干活，CPU基本是摆设。

但现实是——

一旦交换机 CPU 飙高，往往不是“小毛病”，而是整张网络即将“雪崩”的前奏。

我见过太多现场是这样结束的：

• ◉CPU 100%
• ◉登录卡顿
• ◉ARP 表不更新
• ◉STP 反复收敛
• ◉最后一句话：

“先重启试试吧……”

重启当然“有用”，但你心里也清楚——问题没消失，只是被延迟爆发了。

这篇文章，我们不讲虚的，

就按真实排障顺序来聊：

• ◉交换机 CPU 到底在忙什么
• ◉什么流量会“绕过 ASIC，直冲 CPU”
• ◉怎么一步步定位，而不是靠感觉
• ◉那 3 个很多人从没用过、但极其关键的命令

先纠正一个误区：

交换机 CPU 高 ≠ 转发能力不足

99% 的情况下，CPU 高，和“带宽不够”没关系。

交换机的数据转发，主要靠的是：

• ◉ASIC / NP（专用芯片）
• ◉TCAM
• ◉硬件转发表

而 CPU 负责的是这些事：

• ◉控制平面（Control Plane）
• ◉协议计算（STP / OSPF / VRRP / LACP）
• ◉管理流量（SSH / SNMP / Telnet）
• ◉异常报文（ARP、未知单播、广播）
• ◉被 punt（上送）到 CPU 的特殊流量

所以记住一句话：

“

CPU 高，说明“有大量流量不走硬件通道”。

排查总原则：

先定位“谁在吃 CPU”，再追“为什么”

不要一上来就：

• ◉查日志
• ◉查拓扑
• ◉查配置

顺序错了，效率会非常低。

正确的大方向只有一个：

到底是“哪个进程 / 哪类报文”在占用 CPU？

5 个排查步骤

第一步：确认是不是“假高”

先别急着深入， 有些 CPU 高，其实是“显示误导”。

你要先确认三件事：

1. 是瞬时峰值，还是持续高
2. 是单核高，还是所有核心高
3. 是用户态高，还是中断/系统态高

常见命令（不同厂商名字不同，逻辑一致）：

• ◉查看 CPU 使用率历史
• ◉查看 CPU 各核占比
• ◉查看中断占比（interrupt）

如果发现：

• ◉瞬间 90%，几秒又掉下来

→ 多半是协议收敛、链路 flap

• ◉持续 70% 以上

→ 可以确定：真有问题

---

第二步：锁定 CPU Top 进程

这是最关键的一步，但很多人跳过了。

你需要的不是“CPU 很高”， 而是这句话：

“

“CPU 主要被谁吃掉了？”

典型你会看到的几类进程：

• ◉STP / MSTP
• ◉ARP
• ◉IP Routing
• ◉SNMP
• ◉Management
• ◉Unknown / Packet Receive

经验判断：

| 占用进程 | 高概率问题 | | — | — | | STP | 二层环路 / 端口抖动 | | ARP | ARP 风暴 / IP 冲突 | | Packet Receive | 广播、未知单播 | | SNMP | 被监控系统“打爆” | | Routing | 路由震荡 |

如果你这一步没做， 后面 90% 都是在猜。

---

第三步：判断是不是“控制平面被攻击”

有些流量，天生就会被 punt 到 CPU：

• ◉ARP Request
• ◉DHCP
• ◉ICMP to local
• ◉STP BPDU
• ◉LLDP
• ◉未命中硬件表项的报文

你要开始怀疑三件事：

广播 / 未知单播是否异常

重点看：

• ◉广播包 PPS
• ◉Unknown Unicast
• ◉Multicast（尤其是没开 IGMP Snooping 的）

一个常见坑：

“

下联接了一台“傻设备” 或者一台 Linux 服务器开了桥接 → 未知单播被泛洪 → 全部送 CPU

---

ARP 表是否异常增长

症状非常典型：

• ◉CPU 高
• ◉网络时好时坏
• ◉ping 偶尔超时
• ◉ARP 表条目暴涨

常见原因：

• ◉IP 冲突
• ◉大量虚拟机频繁上线/下线
• ◉扫描器 / 病毒 / ARP 欺骗

---

是否存在二层环路“未完全被 STP 挡住”

注意一句话：

“

STP 能挡环路，但挡不住“抖动的边缘”。

比如：

• ◉接入层端口反复 up/down
• ◉非法交换机接入
• ◉私接小交换机

这些都会导致：

• ◉STP 反复计算
• ◉BPDU 风暴
• ◉CPU 持续高位

---

第四步：从“接口维度”反推源头

这一步是从“系统视角”切到“端口视角”。

你要重点看：

• ◉哪些接口有异常 PPS
• ◉哪些接口广播比例极高
• ◉哪些接口错误包激增

一个非常实用的经验：

“

CPU 高 + 某个接入口 PPS 异常高 80% 问题就在那根线后面

很多现场， 就是一台接入设备“抽风”， 拖垮了整台核心/汇聚。

---

第五步：最后才看配置 & 拓扑

到这一步，你再去看：

• ◉是否缺少 storm-control
• ◉是否没做 BPDU Guard
• ◉是否管理 VLAN 与业务 VLAN 混用
• ◉是否 SNMP 轮询过于频繁

这时候看配置，是为了“解释问题”，而不是“猜问题”。

3 个“很少人用，但极其有用”的隐藏命令

下面这 3 个命令， 很多工程师 听说过，但没真正用过。

隐藏命令 1：查看 Punt 流量类型

作用一句话：

告诉你：哪些报文被送进了 CPU

你会看到类似：

• ◉ARP punt
• ◉BPDU punt
• ◉Unknown unicast punt
• ◉ICMP to CPU

如果你看到某一类数量异常：

• ◉ARP 每秒几万
• ◉Unknown unicast 持续增长

那就是铁证，不是猜测。

---

隐藏命令 2：CPU 队列 / 中断统计

这一步可以回答一个问题：

“

CPU 忙，是“算不过来”，还是“被中断打爆”？

如果：

• ◉中断占比极高

→ 大概率是报文风暴

• ◉用户态进程高

→ 协议计算、管理平面问题

这一步能帮你精准区分“网络问题”和“系统问题”。

---

隐藏命令 3：控制平面策略 / CoPP 命中统计

很多设备其实已经配置了 CoPP， 但没人看它有没有在生效。

你需要确认：

• ◉哪类报文被限速
• ◉哪类报文被丢弃
• ◉是否有规则长期 hit 100%

如果 CoPP 在疯狂命中：

“

那说明——不是 CPU 抗不住，是网络已经不健康了。

为什么“CPU 高”，经常一断就全断？

因为交换机 CPU 有一个特点：

它是“共享资源”

一旦被打满：

• ◉STP 不能及时处理
• ◉ARP 学习变慢
• ◉路由收敛延迟
• ◉管理登录卡死

最后的结果就是：

不是某个业务断，而是“全都不稳定”

---

1. 永远别把“重启”当结论
2. CPU 高，一定先看进程
3. 控制平面问题，本质都是流量问题
4. 接入层防护，比核心性能更重要

决定权，永远在你手里。

喜欢就分享

认同就点赞

支持就在看

一键四连，你的技术也四连

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：网络技术联盟站 wljslmz瑞哥《交换机 CPU 飙到 100%？别急着重启，5 个排查步骤+3 个隐藏命令》