在排查网络问题时，很多人都会遇到一个现象：
- 设备端口不丢包
- 转发表看起来也正常
- 但 CPU 占用突然很高，网络开始抖
这时常见的一个疑问是：
不是说交换机、路由器都是“硬件转发”吗？为什么还会把报文送到 CPU？
答案是：并不是所有报文都适合、也不可能交给硬件处理。
一、先给一个总原则
可以先记住这样一条判断：
能被提前“算好规则”的报文，走硬件；
需要判断、学习或参与控制逻辑的报文，会上 CPU。
下面具体展开。
二、直接由硬件转发的报文
这类报文的共同特征是：
- 规则明确
- 行为可预测
- 不需要额外决策
1、普通数据转发流量
包括：
- 二层交换中的已学习 MAC 流量
- 三层转发中已命中的路由表、ARP 表流量
例如：
- 主机 A → 主机 B
- 路由表、MAC 表都已存在
这种情况下，交换芯片只需要：
- 查表
- 改头
- 转发
不需要 CPU 参与。
2、已建立会话的转发表项
在支持三层转发、NAT、ACL 的设备上：
- 首包可能会上 CPU
- 后续命中硬件转发表（FIB、TCAM）
这也是为什么常说：
“首包慢一点，后面的都很快”。
3、硬件可识别的策略转发
例如：
- 静态 ACL
- QoS 匹配规则
- VLAN 转发规则
只要规则能被下发到芯片表项中， 转发过程就完全在硬件完成。
三、一定会上 CPU 的报文
这部分是理解设备行为的关键。
1、控制平面报文
包括但不限于：
- ARP 请求与应答
- ICMP（部分类型）
- OSPF、BGP、RIP 等路由协议
- STP、LLDP
这些报文的目的不是“转发数据”， 而是让设备自己参与网络决策。
所以，它们必须交给 CPU 处理。
2、发给“设备自身”的报文
- Ping 管理 IP
- SSH / Telnet 登录
- SNMP 查询
- Web 管理
哪怕端口速率很低，CPU 被打满，设备也会失去管理响应。
3、无法匹配硬件表项的报文
例如：
- 未知 MAC
- 没有命中路由表
- 特殊封装、异常报文
这些报文需要 CPU 决定：
- 丢弃
- 学习
- 下发新表项
4、异常或攻击类报文
典型包括：
- ARP 洪泛
- 广播风暴
- 畸形报文
如果没有防护机制， 这些报文会被大量送往 CPU， 造成CPU 飙高 → 全网异常。
四、为什么“CPU 高”会影响转发？
这里容易有个误解：
CPU 高 = 转发慢
实际上：
- 硬件转发仍然能跑
- 但控制平面开始失效
结果表现为：
- 路由邻居断开
- 管理登录不上
- 表项无法更新
- 新连接失败
所以你会看到一种现象：
老连接还能通，新连接开始异常。
五、工程中几个非常实用的判断思路
你可以用下面这些问题快速定位方向：
- 问题只影响新连接吗？
- 是 → 怀疑 CPU 或控制平面
2.Ping 管理 IP 卡，但数据还能跑？
- 是 → CPU 压力大
3.CPU 高时伴随大量 ARP / 广播？
- 是 → 优先查二层问题
4.是否开启了风暴抑制、CPU 防护？
- 没开 → 风险很大
六、为什么工业设备更强调“CPU 防护”？
在工业网络中：
- 设备长期在线
- 拓扑固定
- 广播异常影响更大
因此工业交换机通常会：
- 限制上送 CPU 的速率
- 对 ARP、广播做硬件丢弃或抑制
- 避免控制平面被冲垮
这也是工业设备“看起来配置不多，但很稳”的原因之一。
最后
交换机和路由器并不是“所有报文都走硬件”， 而是：
数据面走硬件，控制面走 CPU。
一旦控制面被拖垮， 再强的转发能力也救不了网络。
热门跟贴