交换机CPU到底处理哪些流量？控制面与转发面分工及排障指南

有个兄弟在群里问：交换机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网关延迟飙升。

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/RSTP/MSTP的BPDU：目的MAC是01-80-c2-00-00-00这类协议组播地址，交换机必须把这些帧交给CPU的生成树模块处理，用来计算端口角色和状态。如果接入层存在环路，BPDU会大量上送，CPU需要不断重新计算，端口状态就可能反复切换，形成广播风暴加STP计算的叠加故障。
• LLDP/CDP：用来发现邻居设备信息，每隔一段时间发一次，单看报文量不大，但如果全网设备默认全开，管理面压力还是会慢慢累积。
• LACP：链路聚合的协商报文，端口加入聚合组、成员链路切换都需要CPU参与。
• IGMP：如果二层开启了IGMP Snooping，交换机要侦听主机和组播路由器之间的IGMP报文，CPU需要维护组播组和成员端口的关系。会议室视频系统大批量加入组播组时，IGMP报文会突增。

这一类的共同点是：它们不会像数据流量那样按秒GB级地增长，但都属于“控制面必须响应”的报文。任何一个协议报文处理慢了，都会直接影响业务。比如STP计算慢会导致环路长时间没被阻断，LACP协商超时会导致聚合链路失效。

2.3 管理面流量：SSH、SNMP、NTP和日志的隐形叠加

运维人员天天在用的远程管理功能，对CPU来说并不是零成本的。

先说明一个反常识的点：SSH终端手工敲命令产生的报文量很小，平时可以忽略不计，但如果有人拿工具对设备SSH端口做暴力破解尝试，每一次TCP握手、每一次认证失败，都实打实由CPU去处理，累计到一定程度就会让管理面响应变慢。所以我在生产设备上一定会做管理源ACL，只允许运维网段的IP访问管理地址。

再就是SNMP。很多监控系统默认5分钟轮询一次设备，每次walk一整棵MIB树，会查询大量OID，设备CPU需要逐一应答。如果网络环境里有三四套监控平台同时轮询同一台核心设备，管理CPU的占用很容易达到20%以上，这就是一种典型的管理流量型高CPU，也是平时排障时最容易被漏掉的一个点。

NTP对时、Syslog日志上报、FTP备份配置文件，都有类似的叠加效应。一台设备单个管理协议占用都不高，但全部叠加在一起，CPU日常占用就可能比只跑业务的设备高出不少。尤其是老型号接入交换机，CPU频率低，几个任务叠加后，管理面就会开始卡。

2.4 异常流量、广播、未知单播和特殊回报：CPU被打满的元凶

如果把前几类比作“正常业务”，第四类就是故障现场的主角了。

最典型的是ARP异常。网关的VLANIF接口要响应所有网段内主机发来的ARP请求，不管这个请求是不是合法的。如果局域网里有一台终端中了恶意程序，或者某块网卡驱动异常，就会不停地向全网发送大量ARP请求。CPU为了维护ARP表项，需要逐条解析、学习、刷新，一旦超过CPU处理能力，新的合法ARP请求也会被丢弃，表现出来的症状就是“部分终端突然ping不通网关，过一阵又自己恢复”。

还有个容易被忽视的CPU消耗点是ICMP不可达。当用户ping一个内网不存在的IP地址时，网关设备会代替回应“目的不可达”。单看一条没什么，但如果有扫描器对整个网段做存活探测，每秒几千上万个不存在的IP的探测包到达设备，CPU就要回应几千条ICMP不可达。这类回包消耗纯粹是防御方在“替攻击者买单”，生产环境我甚至见过因为内网扫描导致核心交换机CPU直接飙到90%的。

广播和未知单播本身有交换芯片转发，但如果广播帧携带了需要上送CPU的协议信息，或者未知单播被配置成上送CPU进行软件处理，也会成为压垮CPU的帮凶。链路环路时广播帧会被反复复制、反复泛洪，交换机会同时受到“转发面风暴”和“控制面上送”的双重打击，这也是为什么环路故障里CPU基本都会先爆掉的原因。

为了便于快速记忆，我把上面几类流量盘成了这张表：

3. 盒式、框式与堆叠形态：CPU能力和分担模式比你想的更不一样

讲完流量分类，还有一个绕不开的现实问题：不同形态的设备，CPU承担工作的方式差异很大。很多人拿接入层交换机的CPU使用率去套核心交换机，结果误判方向，浪费了不少排查时间。

3.1 盒式接入交换机：单CPU全包，管好“门口一亩三分地”

常见的24口、48口盒式交换机，往往是一颗CPU加上一颗交换芯片。所有需要上送CPU处理的报文，目标都是这一颗CPU。这类设备CPU主频普遍不高，内存也有限，典型能力就是处理几百条路由、几千条MAC、几十个协议邻居。所以在接入层设备上，一个大VLAN里如果广播域太大，比如几百台PC直接二层互通的场景，ARP请求和协议报文会把CPU打得很满。

遇到这类设备CPU高，优先检查的不是路由协议，而是接入层是否广播过多、是否有人私接小交换机形成环路、是否有终端在持续发异常报文。对症处理后，CPU通常能很快降下来。如果接入层既要当网关又要跑OSPF，还要处理大量组播，我一般建议换更高规格的设备或者做架构调整，而不是硬扛。

3.2 框式核心交换机：主控CPU与线卡CPU各管一段

中高端框式交换机（比如插了主控板加多张业务板的设备）的CPU结构和盒式机完全不一样。主控板上有独立的CPU，负责跑路由协议、管理整机；每张业务板上也有自己的CPU，负责处理本板上送的协议报文和控制信令。所以当你看到“CPU使用率”时，先要确认看的是主控板的CPU还是某一块业务板的CPU。

主控CPU高，问题通常出在路由震荡、整机管理流量过大上；单块业务板CPU高，往往是该板卡对应端口的报文异常上送造成的。举个例子：一台核心交换机上，某张板卡连接着有环路的接入区域，大量BPDU和未知单播通过这张板卡的端口上送到板卡CPU，这张板卡的CPU就会异常升高，但主控CPU可能一切正常。如果只盯着主控看，你可能会漏掉真正的问题源头。

3.3 堆叠和集群：多个CPU有主有备，别只查一台设备

现在很多网络用堆叠（华为的CSS、锐捷的VSU、H3C的IRF，思科的StackWise）把多台设备虚拟成一台来管理，控制面一般由主设备统一负责，路由协议在主设备上跑，业务板或成员设备负责各自端口的数据转发和控制报文预处理。

堆叠环境里排障要特别注意：你通过主设备登录，看到的CPU使用率可能只是主设备的，某个成员设备的CPU可能已经爆了但从主设备上看不出来。所以我遇到堆叠设备告警，第一件事就是一条条成员设备单独查看CPU状态，再结合日志判断到底是主控压力大还是某个成员设备的接口板压力大。否则很容易出现“整机看着正常，业务却一直在抖”的诡异故障。

4. 一次CPU打满的真实排障：从“ping网关时通时不通”说起

前面讲了很多理论，下面用一个完整案例把排查链路串起来。这个案例源自一次真实的办公网故障，现象还有代表性：有业务服务器弹出了类似网络异常流量的提示，同时用户反馈访问办公系统时快时慢，跨网段ping数据库服务器时通时不通。

4.1 先看现象，再说“CPU高”到底高在哪

我到现场后没有急着抓包，先登录核心交换机查看整体状态。华为设备用display cpu-usage，能看到实时CPU占用率，也可以加参数查看不同槽位的CPU。显示核心交换机CPU在92%左右波动，明显不正常。但我没有直接断定“核心设备被攻击”，而是先看是哪个CPU任务在消耗资源：

text复制<Core-Switch> display cpu-usage
CPU Usage: 92%  Max: 95%

进一步用带任务明细的命令查看的时候，发现占用最高的任务名不是路由计算，而是ARP相关任务。这条信息很关键：它意味着当前CPU资源消耗的核心来自ARP报文处理，而不是数据转发或路由震荡。

4.2 缩窄范围：哪个VLAN、哪个端口在灌ARP

知道了是ARP任务炸了，还需要找出是哪个网络区域灌进来的。我在核心交换机上检查了ARP表项数量和对应接口的报文统计，也查看了logbuffer日志，发现某个接入侧VLAN的ARP报文计数涨得特别快，而且这个VLAN里的某个端口收包速率异常偏高：

text复制<Core-Switch> display interface GigabitEthernet 1/0/24
  Input:  total packets: 82348341
         broadcast packets: 62322800

一个二层端口的收包里广播包占了七成以上，基本可以判断这个口的下联区域有问题。我先找到这个端口对应的接入交换机，再逐级向下查看端口流量，最终锁定在一台终端上。

4.3 锁定源头后的处理与验证

把那台终端的网线拔掉以后，核心交换机的CPU使用率在几分钟内就降到了20%以内，ARP表项的刷新频率也恢复了正常，用户反馈的“时通时不通”现象消失。后来查那台终端，确认是网卡驱动故障加上后台程序异常，持续发送大量伪造ARP请求，把整个广播域都拖下水了。那台业务服务器弹出的异常流量提示，其实就是被这阵ARP风暴波及后的连锁反应。

这个案例的排查思路可以整理成一条通用链路，各厂商命令版本有差异，但方向完全一致：

提示：在生产设备上做逐端口断开验证，最好先跟业务方确认窗口，并在断端口前观察端口计数器变化。不要一上来就抓包——在大流量场景下抓包容易把自己和设备的CPU一起搞垮，先用计数器定位到小范围再抓包才是正路。

5. 从源头给CPU减负：可落地的防护与优化手段

光会排障还不够，生产网络里CPU被异常流量打满这种事，几乎每个运维都会遇到。真正有价值的做法是从架构、策略、日常监控三个层面提前布防，让CPU少接触不该它处理的流量。

5.1 控制面限速：给CPU装一道“门卫”

现在主流网络设备都提供了类似“CPU保护策略”的能力，思路是在报文进入CPU之前做一次速率限制和优先级调度，只放行合理速率以内的协议报文，超速的直接丢弃。这个机制类似机场安检——不是不让所有人进候机厅，而是不允许短时间内涌入超出处理能力的人群。

思科设备上常见的做法是CoPP（Control Plane Policing），用MQC模板把ICMP、SNMP、SSH等协议流量分别匹配出来，再对每个类别设置一个允许的速率。比如限制发往设备自身的ICMP为每秒不超过一定流量，超出的丢掉：

text复制class-map match-all CoPP-ICMP
 match access-group name CoPP-ICMP
!
policy-map CoPP-Policy
 class CoPP-ICMP
  police 32000 conform transmit exceed drop
!
control-plane
 service-policy input CoPP-Policy

华为、锐捷、H3C设备各有各的CPU保护命令，不同版本命令差异很大，但思路相同。刚接触时不要急着调参数，先在设备上观察正常运行时的协议报文速率，再把保护阈值设在“正常速率的2到3倍”左右。设置太松起不到保护作用，设置太紧又会误伤合法的BPDU、OSPF Hello等关键协议，属于需要长期迭代优化的配置。

5.2 在接入层治理异常源头：ARP、DHCP、广播一个都不能漏

CPU保护的局限在于它只“拦”，不“治本”。真正要解决的是让异常流量根本不产生，或者不扩散。

• 缩小二层广播域：办公网终端较多的场景，尽量把大VLAN拆小，或者用三层接口做网关终结，把广播域控制在合理范围内。几百台终端放在一个VLAN里，本身就是给CPU埋雷。
• DHCP Snooping加DAI：在接入交换机上开启DHCP Snooping，建立可信端口和DHCP绑定表，再配合DAI动态ARP检测，对非法的ARP报文直接丢弃。这一套组合对“伪造网关、ARP欺骗”特别有效，属于治本手段。
• 风暴控制：对广播、组播、未知单播分别设置阈值，超过阈值后设备可以丢弃超限部分或者关闭端口。环路发生时，风暴控制能在协议收敛之前就先把影响压住。
• BPDU保护与根保护：面向终端的端口开启BPDU保护，一旦端口收到BPDU就直接err-disable，防止有人私接交换机导致生成树结构被破坏。

这些功能不是选装，而是接入层基线配置。设备型号不同命令有差异，但华为、H3C、锐捷、思科都支持，照着厂商配置手册做一遍并不复杂，最怕的是嫌麻烦不开。

5.3 设计上的减负：管理流量与业务流量分离

如果条件允许，设备管理建议走带外管理网络。也就是说，用单独的管理网段/VLAN管理所有网络设备，管理流量和业务流量物理或逻辑隔离，网管系统、SSH登录、日志上报都走管理面，不跟业务报文抢CPU资源。做不到带外管理时，至少要把NMS轮询周期拉长一些，比如把SNMP轮询从5分钟改成10分钟，对日常监控影响很小，却能为设备CPU明显减负。

另一个容易被忽略的设计是管理源ACL。只允许运维网段的IP访问设备的SSH、SNMP、Telnet等管理服务，不仅可以防暴力破解，也能挡住扫描器对设备管理地址的大量探测流量。很多时候CPU被管理面打高，不是业务出问题，而是设备管理地址暴露在了一个过大的访问范围里。

5.4 用“会话思维”看异常流量提示

前面案例中提到业务服务器弹“网络中存在异常流量”的提示，这种提示现在很多安全软件都会给，但它往往只说明服务器自身看到了异常连接，并不代表源头就在这台服务器上。我处理过不少类似反馈，最终定位到的源头分布各异：有接入层终端中了挖矿木马在向外疯狂发包的，有办公网某台PC中了蠕虫在扫描内网整个网段的，也有业务服务器自己配置错误导致跨网段重传风暴的。

所以收到这类提示时，我的建议是先别急着在服务器上封禁IP，而是借助交换机侧的CPU任务统计、端口流量计数、会话表项增长趋势来定位真正的源和目的。设备CPU高只是“结果”，谁在持续产生异常流量才是要解决的“原因”。把两个层面结合起来看，才能快速找到问题根因，而不是反复处理受害者的“报警”。

最后再分享一点个人习惯

如果你问我日常怎么判断交换机CPU是否健康，我会说：先别纠结那串绝对数字，先建立自己网络的“CPU日常基线”。每台设备在低峰期、高峰期、备份时段分别是什么占用率，会跑哪些任务，日志里每周出现多少条异常记录——这些底数清楚了，CPU只要偏离基线，你就能第一时间判断是“正常业务波动”还是“故障前兆”。

我在实际处理中还发现一个规律：很多CPU高的问题都不是单一原因造成的，而是几个小问题叠加的结果。可能是某个VLAN广播本来就偏大，这时有人又改了一条路由策略，触发了一段不必要的路由震荡，再加上SNMP轮询频率设置不合理，三个因素一叠加，CPU就被推到了临界点。单个看每一样都“好像没问题”，结果合在一起就把设备压垮了。所以排障时多问一句“最近改过什么”，往往比对着抓包文件苦思冥想更高效。排查完之后，把CPU保护阈值、风暴抑制参数、管理ACL这些基线配置沉淀成模板，下一次再遇到同类问题，至少能少熬一个通宵。