我说老李你说黑有个兄弟在群里问：交换机CPU到底能处理哪些流量？这问题看起来基础，真往深了说，挺多干了几年的运维也答不全。交换机CPU和电脑CPU的最大区别在于，它平时不负责搬数据，但一旦某个流量要它管、而它又管不过来，整台设备就卡给你看。为了讲清这件事，我把控制面、转发面的分工，以及日常排障中遇到过的高CPU案例从头到尾捋了一遍，这篇就当是给同样被“交换机CPU高”折磨过的人一份实操参考。
1. 二层转发不经过CPU：理解交换机CPU处理流量的前提
先纠正一个最常见的误解：交换机转发数据时，帧并不是从CPU里“过一遍”才出去的。如果所有流量都要走CPU，哪怕接入层那台几百块钱的小交换机都扛不住。交换机里真正干转发重活的是交换芯片（有些厂商叫ASIC、转发芯片、NP），数据从一个端口进来，交换芯片直接查表决定从哪个端口出去，整个过程CPU根本不出场，这也就是行业里常说的“线速转发”。
以最常见的二层转发为例。PC-A发一个帧给PC-B，交换机收到帧后，先查MAC地址表。如果目的MAC在表里有对应出端口，交换芯片就直接把帧从那个端口送出去。假设全网几千台终端同时互传文件，CPU占用率可能都不到1%，因为查表、交换、调度全在芯片内部完成，CPU既不用计算路径，也不用参与转发决策。这也是为什么一台交换机的转发性能不看CPU主频，而是看“包转发率”这个指标。
那MAC地址表是谁建的呢？CPU还是要管的，只是它管的不是“每一帧”，而是“第一次学到的MAC”。当一个未知目的MAC的帧到达时，交换芯片发现查不到表项，除了把帧向其他端口泛洪之外，还要把源MAC、入端口这些信息上送给CPU，CPU记下这个对应关系，写进MAC表，再同步给交换芯片。之后的同目的帧交换芯片就能自己处理了。
所以，一句话说清楚：交换机CPU负责的是“建规则”和“处理控制报文”，而不是替交换芯片转发每一个数据包。有点像高速公路收费站——大量车都是自动抬杆直接过的（硬件转发），只有遇到特殊车辆、异常情况，才需要人工到场处理（上送CPU）。CPU被大量报文打满，本质就是“需要人盯着的车太多了”。
那哪些报文必须上送CPU呢？主要有两类：一类是目的MAC地址就是交换机本身的报文，比如发到设备自己的管理流量、路由协议报文；另一类是交换芯片识别不了或处理不了的报文，比如某些携带特殊字段、需要软件协议栈介入的帧。这两类报文统一汇入“上送CPU”的队列，再由CPU里的协议栈逐一处理。
很多人会忽略一个关键差异：交换芯片处理报文的能力是按千万级甚至亿级pps来算的，而CPU即使是很高端的处理器，能处理的pps通常也只有百万级。两者之间差了一两个数量级。所以一旦出现大量本该由芯片转发的流量被错误引导到CPU，设备会瞬间“假死”——表面看端口链路up着，实际协议邻居开始超时、管理面卡顿、ping网关延迟飙升。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CPU必须参与的四类流量：路由协议、控制协议、管理与异常上送
既然CPU只在特殊情况下介入，接下来就要具体分清“哪些特殊流量必须由CPU处理”。经验来看，可以把它们归成四大类，每一类在实际故障里都有典型的爆发场景。
2.1 路由协议报文：CPU是决策者，不是传声筒
只要设备开启了路由功能，动态路由协议报文就必须由CPU处理。OSPF的Hello报文目的地址是组播地址224.0.0.5，BGP走TCP 179端口，IS-IS直接跑在二层。交换芯片没法为这些协议报文“代转”，它们会被上送到CPU的协议栈，CPU解析后更新路由表、计算最短路径、维护邻居状态，再把最终算好的转发表下发到交换芯片。
典型场景是核心交换机同时跑OSPF和BGP，如果某个邻居设备配置错误，导致路由不断震荡，CPU就会反复执行路由计算。此时用命令查看CPU任务，往往会看到“ROUT”或“IP ROUTING”这类任务占用率特别高。路由震荡不像广播风暴那么明显，但危害同样很大——邻居超时后BGP会话会断开重连，重连又触发新一轮路由计算，形成恶性循环。
2.2 二层控制协议与邻居保活协议：日常最容易被忽略的CPU消耗者
二层协议看着不起眼，实际上在CPU占用里占的比例一点不小：
- STP/RS