在排查网络问题时，很多人都会遇到一个现象：

设备端口不丢包

转发表看起来也正常

但 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、发给“设备自身”的报文

凡是目标是交换机/路由器本身的流量，都会上 CPU：

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。

一旦控制面被拖垮， 再强的转发能力也救不了网络。