交换机CPU 100%实战排查：5步法定位故障源头与3个关键命令

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

但现实是，一旦交换机CPU使用率飙升，往往不是小毛病，而是整张网络即将“雪崩”的前奏。常见的故障现场往往以这种方式结束：

• CPU 100%
• 登录卡顿
• ARP表不更新
• STP反复收敛
• 最后一句话：“先重启试试吧……”

重启当然能暂时解决问题，但你也清楚——问题并未消失，只是被延迟爆发了。

图：交换机CPU负责控制与管理平面，转发主要由专用芯片处理

这篇文章将按照真实的排障顺序，解析以下核心问题：

• 交换机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”，再追查“为什么”

不要一开始就盲目地查日志、看拓扑或翻配置，顺序错了效率会非常低。
正确的方向只有一个：到底是“哪个进程”或“哪类报文”在大量占用CPU资源？

5步排查法定位故障源头

第一步：确认是否为“假性飙高”

先别急于深入，有些CPU飙高其实是显示或瞬时现象造成的误导。你需要先确认三件事：

1. 是瞬时峰值，还是持续高位？
2. 是单个核心高，还是所有核心都高？
3. 是用户态进程高，还是系统中断（interrupt）占比高？

常见检查命令（不同厂商命令不同，但逻辑一致）：

• 查看CPU使用率历史趋势
• 查看各CPU核心的占比分布
• 查看中断（IRQ）占比

快速判断：

• 如果CPU瞬间冲到90%，几秒后又恢复正常 → 多半是协议收敛、链路闪断（flap）引起的短暂冲击。
• 如果CPU持续在70%以上高位运行 → 基本可以确定存在真实问题，需要进一步排查。

第二步：锁定消耗CPU资源的Top进程

这是最关键的一步，但很多人会跳过。你需要知道的不是“CPU很高”，而是“CPU主要被谁吃掉了？”

在系统进程列表中，你通常会看到以下几类：

• STP / MSTP （生成树协议进程）
• ARP （地址解析协议处理）
• IP Routing （路由协议进程）
• SNMP （简单网络管理协议代理）
• Management （管理平面进程）
• Unknown / Packet Receive （未知或报文接收进程）

经验判断表：

占用CPU的主要进程	高概率对应的问题
STP	二层环路 / 物理端口频繁Up/Down抖动
ARP	ARP风暴 / IP地址冲突
Packet Receive	广播风暴、未知单播泛洪
SNMP	被网管系统频繁轮询“打爆”
Routing	路由协议震荡（如OSPF邻居反复建立）

如果跳过这一步，后续90%的排查都像是在猜测。

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

有些类型的网络流量，天生就会被交换机上送（punt）到CPU进行处理：

• ARP Request（请求）
• DHCP（动态主机配置协议）报文
• 目的地址为设备自身的ICMP报文（如Ping管理地址）
• STP BPDU（桥协议数据单元）
• LLDP（链路层发现协议）报文
• 未命中硬件转发表（FIB/ MAC表）的任何报文

此时，你需要怀疑以下三种情况：

1. 广播/未知单播流量是否异常？

重点关注以下计数器：

• 广播包每秒数量（PPS）
• 未知单播（Unknown Unicast）计数
• 组播流量（尤其是未开启IGMP Snooping的环境）

一个常见陷阱： 接入层连接了一台“傻”HUB或开启了网桥（Bridge）模式的Linux服务器，导致未知单播报文被泛洪，最终全部上送CPU处理。

2. ARP表项是否异常增长？

症状非常典型：

• CPU使用率高
• 网络时通时断
• Ping测试偶尔超时
• ARP表条目数量暴涨

常见原因包括IP地址冲突、大量虚拟机频繁迁移或上线/下线、网络扫描工具或病毒引发的ARP欺骗攻击。

3. 是否存在未被STP完全阻挡的二层环路？

注意：STP能阻挡成型的环路，但无法完全消除由“边缘端口抖动”带来的控制平面压力。
例如：

• 接入层端口因线路问题反复Up/Down
• 非法交换机或私接小交换机接入网络

这些情况都会导致STP协议反复计算拓扑变更、BPDU报文风暴，从而使得CPU持续处于高负载状态。

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

这一步是将视角从“系统整体”切换到“具体物理端口”。你需要重点关注：

• 哪些接口的报文转发率（PPS）异常高？
• 哪些接口的广播流量比例极高？
• 哪些接口的错误包（Error）计数激增？

一个非常实用的经验法则：

CPU高 + 某个接入端口PPS异常高 ≈ 80%的问题根源就在那条线缆连接的设备上。

很多故障现场，往往就是一台接入层的服务器或交换机“抽风”，拖垮了整台核心或汇聚交换机。

图：通过端口流量监控，快速定位异常流量的入口

第五步：最后才核查配置与拓扑

走到这一步，你的排查已经有了明确方向。此时查看配置，是为了“解释和验证”你发现的问题，而不是漫无目的地“猜测问题”。应重点检查：

• 是否在接入端口配置了风暴控制（storm-control）？
• 是否启用了BPDU Guard等端口安全特性？
• 管理VLAN是否与业务VLAN混用，导致管理流量受业务风暴影响？
• SNMP等网管协议的轮询间隔是否过于频繁？

3个“极少使用但极其关键”的隐藏命令

下面这三个命令，很多工程师听说过但从未在实际排障中使用过，它们能提供决定性的证据。

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

作用： 明确告诉你，具体是哪些类型的报文被送进了CPU。
你会看到类似“ARP punt”、“BPDU punt”、“Unknown unicast punt”等分类计数。如果发现某一类报文的punt数量异常（例如ARP请求每秒数万），那就是存在问题的铁证，而非推测。

隐藏命令 2：查看CPU队列与中断（IRQ）统计

作用： 回答一个关键问题——CPU忙，是“任务处理不过来”（用户态高），还是“被报文到达的中断打爆了”（系统中断占比高）？

• 如果中断占比极高 → 大概率是底层报文风暴（广播、泛洪）。
• 如果用户态进程占比高 → 可能是上层协议（如STP、OSPF）计算或管理平面问题。
  这一步能帮你精准区分是“网络流量异常”还是“系统协议故障”。

隐藏命令 3：检查控制平面策略（CoPP）命中统计

很多设备默认或已配置了控制平面保护策略（CoPP），但没人去查看它是否正在生效以及如何生效。
你需要确认：

• 哪类报文被策略限速了？
• 哪类报文被丢弃了？
• 是否有某条规则的命中率长期处于100%？

如果CoPP策略在持续地、大量地命中并丢弃报文，那说明一个问题：不是CPU性能不足，而是网络本身已经处于极不健康的状态，CPU正在被海量的异常流量攻击。

为什么CPU一高，经常导致全网中断？

因为交换机的CPU是一个共享的公共资源。一旦它被异常流量打满，将导致所有依赖CPU的进程都得不到及时处理：

• STP无法及时计算拓扑变更
• ARP学习缓慢，表项无法更新
• 路由协议收敛延迟
• 管理登录（SSH/Telnet）卡死或无响应

最终结果就是：并非某一个业务中断，而是整个网络变得极不稳定，所有业务都受影响。

核心总结

1. 永远别把“重启”当作故障排查的结论，它只是临时恢复手段。
2. CPU高，排查第一步永远是看进程，确定消耗资源的主体。
3. 控制平面问题，本质上都是流量问题，追根溯源能找到异常流量的入口。
4. 做好接入层的安全防护（如风暴控制、BPDU Guard），比提升核心交换机性能更重要。

掌握科学的排障思路，远比记住几条命令更有价值。希望这篇关于网络运维中交换机控制平面故障排查的干货，能为你下次面对类似问题时提供清晰的路径。欢迎在云栈社区分享你的排障经验与见解。