一、CPU 干的四件事

① 协议计算：生成树、路由协议、链路聚合协商。 ② 管理与配置：CLI、SNMP、SSH、Web 界面、固件升级。 ③ 异常上送：广播、未知单播、ARP、协议报文（如 BPDU、LLDP）。 ④ 慢路径：芯片处理不了的包（复杂 ACL、隧道、分片重组）交给 CPU。

前两件是「必须」，后两件是「兜底」。兜底那条最容易出事——一旦流量里有大量需要上送的包， CPU 就成瓶颈。

二、上送路径为什么危险

正常转发走芯片，不经过 CPU；但有一类包必须上送。 这些包的共同点是「芯片不知道该怎么办」：目的 MAC 没见过、是广播、是协议报文。

于是出现一个死循环式的风险：网络一出问题（环路、广播风暴），上送的包暴涨，CPU 打满， 管理面失联，人再也进不去修。

所以所有正经设备都有「CPU 保护」：给上送流量分类限速，超了直接丢。 配置时经常看到 control-plane policing 之类的命令，就是这个。

三、看 CPU 利用率要看什么

① 一分钟与五分钟平均值：瞬时 100% 可能只是收敛，持续高就是问题。 ② 哪个进程高：是协议进程、还是上送处理、还是管理面。 ③ 上送包的分类统计：常见的是 ARP、广播、未知单播。

经验值：稳态下 CPU 在 20% 以下算健康，30% 到 50% 要查原因， 长期 70% 以上迟早出事——因为它的峰值往往在故障时才来。

四、动手 Demo：管理面 CPU 的上送能力有多小，算一遍就明白

这段按「每包几千个周期」估算 CPU 一秒钟能处理多少个上送包。

ghz = 1.2
cyc = 3000
pps = ghz * 1e9 / cyc
print(pps / 1e3)

实跑输出：

--------------------------------------------------------------------
CPU 在交换机里到底干什么，主频能换多少包
--------------------------------------------------------------------
**交换机里的 CPU 不管转发，它管「思考」。**转发交给 ASIC，CPU 只处理：
路由协议计算、生成树、SNMP 轮询、CLI 命令、日志、告警。

**但这不意味着 CPU 性能不重要。**下面这几种情况，CPU 会顶到 100%：

**① 广播风暴**：每个广播包都要上送 CPU，风暴时 CPU 直接打满。
**② 大量 ARP／ND**：地址解析请求也是上送 CPU 的。
**③ 管理面被刷**：SNMP 轮询过密、日志外发过频。
**④ 软件转发路径**：配置了复杂 ACL、NAT、隧道，部分流量会走慢路径。

  项                  值
  ---------------------------------
  管理面 CPU 主频     1.2 GHz
  每个上送包开销      3000 周期
  理论上送能力        400 kpps

**几十万 pps 的上送能力，听起来很多，其实很少。**一次广播风暴能轻松打出一百万 pps。
**所以工程上必须有「CPU 保护」**：对上送流量限速、按协议分类限速，
超了就丢——**宁可丢广播，也不能让管理面挂掉**，因为管理面挂了就再也进不去了。

四十万 pps 听起来不少，实际很少。一次广播风暴轻松上百万 pps，而且故障时还要叠加协议重算。

这就是为什么「CPU 保护」必须开着。它的逻辑不是「保证所有包都处理」， 而是「保证管理面活着」——宁可丢广播，也不能丢管理通道。

反过来一条经验：如果一台设备频繁 CPU 高，先查拓扑有没有环，而不是先换设备。 八成的问题在环路上。

30 秒实验

1. 在你手上任意一台交换机上查 CPU 利用率与上送包统计。
2. 找一条 control-plane 限速配置，看它的阈值是多少 pps。
3. 想想为什么「广播风暴时会连不上设备」。

常见误区

1. 以为 CPU 性能决定转发能力。转发靠芯片，CPU 只管管理与兜底。
2. 以为 CPU 100% 一定是流量大。多数是环路、ARP 风暴、轮询过密。
3. 关掉 CPU 保护求「不丢包」。结果是一故障就失联。

下一节：CPU 之外，设备里还装着存储——固件、配置、日志各占多少。

• ☐ （本节完，下一节 01.04.04 存储设备）

相关笔记

• 存储器
• 第二章 02.08.03 生成树功能（后章）
• 🖥️ 服务器工作原理
• 📡 图解网络硬件 · 索引