文章总结： 本文针对交换机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 高，其实是“显示误导”。
你要先确认三件事：
- 是瞬时峰值，还是持续高
- 是单核高，还是所有核心高
- 是用户态高，还是中断/系统态高
常见命令（不同厂商名字不同，逻辑一致）：
- ◉查看 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 学习变慢
- ◉路由收敛延迟
- ◉管理登录卡死
最后的结果就是：
不是某个业务断，而是“全都不稳定”
- 永远别把“重启”当结论
- CPU 高，一定先看进程
- 控制平面问题，本质都是流量问题
- 接入层防护，比核心性能更重要
决定权，永远在你手里。
喜欢就分享
认同就点赞
支持就在看
一键四连，你的技术也四连
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网络技术联盟站 wljslmz瑞哥《交换机 CPU 飙到 100%？别急着重启，5 个排查步骤+3 个隐藏命令》