凌晨两点被运维电话叫醒登进设备一看日志刷屏的全是DEFD/4/CPCAR_DROP_MPU。这条日志的主体看着挺唬人翻译成人话就一句话上送到主控 CPU 的协议报文速率超过了 CPCAR 设定的上限超出部分被 MPU 直接丢掉了。注意这里的关键词是丢不是慢——被丢掉的报文在网络里就凭空消失了紧跟着来的往往是 OSPF 邻居抖动、ARP 学不全、用户上下线异常这类连锁故障。这条 DEFD 模块的告警属于控制平面防御体系的外在表现本身不是故障而是设备在告诉你我的 CPU 通道快被协议报文塞满了我按策略限流了。真正要查的是背后谁在往里灌报文。CPCAR、MPU、CPU 这三个词在这条日志里各占一个位置MPU 是主控板CPU 跑在 MPU 上CPCAR 是给 CPU 通道设的限速闸门。搞清这三者的关系排查思路就顺了一大半。这篇内容适合跑在机房一线的网络运维、集成实施工程师、IDC 基础设施岗以及正在啃网络认证、想搞懂协议报文为什么要限速的朋友。我会把这条日志拆开揉碎从结构解释、根因归类、六步排查流程、参数调优取舍一直到我自己踩过的坑全部摊开说。命令以主流 VRP 风格设备为例具体命令字会因型号和版本有出入别照抄思路是通用的。1. 拆开这条日志CPCAR、MPU、CPU 各自扮演什么角色很多同学第一次看到这条告警第一反应是CPU 不够用了去加内存方向就跑偏了。这条日志跟硬件性能没关系它是软件层面的流量管控在起作用。1.1 一条日志的完整解剖DEFD/4/CPCAR_DROP_MPU:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol[STRING]这一段拆开来是三块字段片段含义说明DEFD模块名防御Defend相关模块负责控制平面安全4告警级别4 一般对应 Warning 级属于要关注但不致命CPCAR_DROP_MPU事件标识在 MPU 上发生了 CPCAR 丢包Protocol[STRING]协议占位填充具体被丢的协议类型如 ARP、DHCP、STP 等这个Protocol字段是整条日志里最有价值的信息它直接告诉你是哪一类报文超限了。可惜很多现场截图把方括号里的内容裁掉了排查难度直接翻倍。看到这条日志第一件事就是把完整原文捞出来确认协议类型。级别 4 不代表可以不当回事它的意思是设备还活着但我已经在丢包了。如果这个协议是 OSPF 或 BGP那上层业务可能已经在抖了如果是 ARP终端可能已经开始大面积掉线。1.2 报文为什么要上送 CPU一台交换机或路由器内部其实有两套大脑。一套是转发平面由 ASIC 芯片负责干的是看表、匹配、转发这种流水线活速度快到按 Tbps 算。另一套是控制平面跑在主控板的 CPU 上负责算路由、维护邻居、处理协议协商。问题是有些报文 ASIC 处理不了必须交给 CPU。典型的几类需要 CPU 应答的ARP 请求、DHCP Discover、ICMP Echo、SNMP Get、Telnet/SSH 登录需要 CPU 参与计算的OSPF/BGP/IS-IS 的 Hello 与更新报文、STP BPDU、LACP 协商、BFD 探测、VRRP 通告需要 CPU 学习或上报的MAC 地址首次学习、未知单播、TTL 超时、路由表项变化管理类流量NTP、Syslog、AAA 认证报文这些报文统一走一条通道送到 CPU行业内常叫协议上送通道或者 punt path。问题就在这——ASIC 的包转发能力是 CPU 的千倍以上而这条上送通道只有一条还能被任何人往里面灌包。1.3 CPCAR 和 MPU 是怎么配合的CPCAR 全称是 Control Plane Committed Access Rate控制平面承诺访问速率。说白了它就是给上送 CPU 的每一类协议报文各自设了一个令牌桶。桶里有令牌就能过没令牌就丢同时打一条 DEFD 日志。MPU 就是主控板Main Processing UnitCPU、内存、协议栈都在上面。所以on the MPU这句的意思是丢包动作发生在主控板上不是接口板。打个比方CPCAR 像是机场安检通道。平时旅客协议报文不多大家顺畅通过节假日突然涌进来几千人广播风暴或攻击安检口就那么几个队伍瞬间爆掉。这时候安保的选择不是把楼炸了而是拉起隔离带后面的先别进——这就是丢包。1.4 为什么这道闸门必须有有人会问能不能干脆把 CPCAR 阈值调到无限大报文全收不就行了答案是不行这是拿整台设备的安全做赌注。CPU 的处理能力是有天花板的。同一颗 CPU 要跑协议栈、要算路由、要响应管理请求、要处理中断。一旦协议报文把 CPU 打到 100%后果比丢包严重得多协议邻居超时断开BGP 全表重收敛业务中断几分钟到几十分钟管理面失联你连设备都登不进去只能现场重启心跳报文被挤压堆叠或双机热备可能脑裂极端情况下看门狗触发主控复位所以 CPCAR 的本质是一道保险丝。它宁可牺牲一部分协议报文也要保住 CPU 这个核心资源。丢包是可控的降级CPU 打满是不可控的雪崩。场景CPU 无保护CPU 有 CPCAR 保护广播风暴来袭CPU 打满协议全断可能复位超限报文丢弃核心协议保住攻击流量涌入管理面失联攻击流量被限管理面可用正常协议小抖动无影响无影响阈值远高于正常值2. 谁把 CPU 打爆了五类根因逐一对照知道了原理接下来是找真凶。我在现场遇到过的触发原因基本跑不出下面这五类。2.1 二层环路引发的广播风暴这是制造业、园区网、临时办公区最容易翻车的场景。有人把一根网线两头都插在同一台交换机的两个口上或者把两台交换机用两根线对接却没配聚合。生成树如果没开或者被 BPDU 过滤挡住环路立刻成形。环路的杀伤力在于自我放大一个广播帧进了环每绕一圈就复制一份几十毫秒内就能把链路带宽吃满同时大量广播和未知单播要上送 CPU 处理CPCAR 瞬间被打穿。这类现场有个典型特征Protocol字段多半是 ARP 或者显示为广播类报文同时伴随接口指示灯疯狂闪烁、设备风扇突然提速。查到这一步基本可以锁定环路。2.2 协议报文泛洪与路由震荡第二种是协议层面的震荡。典型的表现是某条链路 flappingOSPF 或 BGP 邻居反复建立又断开每次重建都要交互大量协议报文。链路抖动频率越快上送 CPU 的报文量越大。还有一种更隐蔽的场景路由表项变化过于频繁。比如某台设备上的静态路由指向了一个不稳定的下一跳或者路由引入策略存在环路导致设备反复重算路由CPU 被路由计算本身占满连带协议上送通道也受挤压。这类问题的特征是有明显的规律性告警往往在固定时间点集中出现比如每天业务高峰的前十分钟或者某次链路割接之后。2.3 扫描与攻击类流量来自网络内部的扫描是最难缠的一类。一台中毒的 PC 可能每秒发起上万次 ARP 扫描或者端口扫描目标网段横跨整个内网。扫描本身不算攻击但对设备的 CPU 来说就是持续的 DoS。典型的恶意流量包括IP 扫描、端口扫描产生的海量 ICMP 或 TCP SYNARP 欺骗工具产生的伪造 ARP 请求/应答DHCP 地址池耗尽攻击伪造大量不同 MAC 的 DHCP Discover利用分片特性构造的畸形报文强制上送 CPU 重组这类流量的特点是源 IP 或源 MAC 极度分散甚至随机变化用常规的黑名单很难拦。2.4 终端侧异常与地址冲突别小看一台终端的威力。我遇到过一台打印机固件有缺陷每隔几秒发一次 ARP 探测本身不算大事但如果同时有十几台这样的设备再加上几台 IP 冲突的终端在反复做免费 ARP 通告量就上来了。终端侧常见的几个惯犯IP 地址冲突两台设备配了同一个静态 IP双方都在宣称这个地址是我的网卡故障半死状态的网卡持续发出畸形帧虚拟机迁移风暴虚拟化平台上批量迁移瞬间大量 ARP 更新DHCP 租约异常终端拿不到地址疯狂重试终端类问题最难定位因为现象分散、设备数量多。2.5 配置缺失与架构性隐患最后一类是自己挖的坑。常见的有接入层交换机压根没启用生成树、风暴抑制没配、边缘端口没做 BPDU 保护、DHCP Snooping 缺失。还有一种架构性问题所有网关集中在核心设备上接入层又是大二层结构一个 VLAN 跨越几十台设备。这种结构下任何位置的广播都会扩散到整个广播域CPCAR 想不告警都难。3. 定位实操从日志到根因的六步排查法我给团队定的排查流程是六步按顺序走基本能覆盖 95% 的现场。3.1 第一步确认到底丢了哪个协议先看Protocol字段再统计告警频率。display logbuffer | include CPCAR display logbuffer | include DEFD判断依据告警只在某一秒出现一次可能是瞬时毛刺继续观察即可每秒都在刷正在持续超限必须立即处理只涉及某一个协议方向明确直奔该协议多个协议同时告警可能是 CPU 整体被压满问题更严重提示先把完整的日志原文导出到本地别只截图方括号之前的部分。协议类型是这条日志唯一的方向标。3.2 第二步看 CPU 占用率和具体任务display cpu-usage display cpu-usage task display cpu-usage history重点关注三个数字5 秒、1 分钟、5 分钟的平均占用。如果 5 秒值高但 5 分钟值低说明是瞬时冲击如果三个值都在 80% 以上说明 CPU 处于持续高压。display cpu-usage task会列出占用最高的几个任务常见的有任务名含义占用高的可能原因ROUT路由管理路由震荡、表项频繁变化ARPARP 处理地址冲突、扫描、环路STP生成树拓扑频繁变化、环路IPSTKIP 协议栈大量需要上送 CPU 的报文TICK定时器通常是其他任务拖累导致这一步的价值在于把CPCAR 丢包和CPU 到底忙什么对应起来。有时候 CPCAR 告警了但 CPU 占用并不高说明限速阈值本身就设得偏低属于保守策略误伤。3.3 第三步查 CPU 防御统计看是谁在丢display cpu-defend statistics all display cpu-defend statistics packet-type arp-request display cpu-defend statistics packet-type dhcp display cpu-defend configuration all输出里重点看两列Passed通过和Dropped丢弃。如果某个协议 Dropped 数字在快速上涨那就是它了。再对比configuration里的配置值算出超限倍率。举个例子ARP 请求的默认限速如果是 256 pps而统计显示每秒通过 256、丢弃 8000那就有 8000 pps 的 ARP 请求正在涌入超限三十多倍。这个量级绝不可能是正常终端行为一定有别的东西在制造流量。3.4 第四步查接口流量和广播占比把范围缩小到接口层面display interface brief display interface GigabitEthernet0/0/1 display interface GigabitEthernet0/0/1 | include broadcast正常接入端口的广播包占比一般在 1% 以下超过 5% 就要警惕超过 20% 基本可以确认风暴。同时看接口的broadcast计数增长速度连续看两次间隔 10 秒算一下增长速率。聚合口和上联口要重点看因为它们是流量的汇聚点最容易先爆。如果所有接口的广播都在涨说明风暴已经在整个广播域里了。3.5 第五步端口镜像抓包眼见为实命令行统计只能告诉你有多少抓包才能告诉你是什么。observe-port 1 interface GigabitEthernet0/0/24 port-mirroring to observe-port 1 inbound port-mirroring to observe-port 1 outbound抓包时别全抓用过滤条件收窄。重点看ARP 请求的源 IP 分布如果源 IP 是同一个或者高度集中在某个网段说明是扫描ARP 请求的目标 IP如果目标是一个不存在的地址可能是终端配置错误STP BPDU 的源 MAC如果 BPDU 从一个不该发的口出来环路确认DHCP Discover 的源 MAC如果大量随机 MAC 请求地址是地址池攻击抓包工具用 Wireshark 就够过滤器写arp或者stp或者bootp。抓到之后看专家信息里的重复率Wireshark 会直接提示 duplicate ACK 之类的异常。3.6 第六步二分法定位源头端口前五步确认了流量类型和大致方向后最后一步是精准定位。实操手法是先看设备上哪个接口的收包速率最高把该接口下挂的下级设备逐个断开观察告警是否消失如果断开某台设备后告警停止问题就在那台设备下面逐层往下追直到定位到具体的端口或终端这一步虽然笨但最快最准。我一个同事用的更狠的办法是晚上业务低峰期直接关掉一半接入端口看告警是否消失半小时就能锁定区域。排查步骤核心命令判断信号确认协议类型display logbufferProtocol 字段内容看 CPU 压力display cpu-usage task哪个任务占用高看丢弃统计display cpu-defend statistics allDropped 增长最快项看接口广播display interface | include broadcast广播占比与增速抓包分析端口镜像 Wireshark流量构成与特征二分定位逐段断开告警是否消失4. 处置方案与参数调优先止血再治病排查完就是处置。我的原则是先治标保住业务再治本消除根源最后再谈参数优化。顺序反了容易出更大的问题。4.1 应急缓解的三板斧第一板斧是临时收紧风暴抑制。在出问题的接入端口上加上广播、组播、未知单播的抑制超限直接丢弃从源头掐掉一部分流量。interface GigabitEthernet0/0/1 storm-control broadcast min-rate 2000 max-rate 4000 storm-control multicast min-rate 2000 max-rate 4000 storm-control action error-down第二板斧是关掉问题端口。如果已经定位到具体端口直接 shutdown 是最直接的手段。业务影响可控的情况下这一招最有效。第三板斧是临时临时放宽 CPCAR 阈值。这一招要慎重因为它只是把闸门开大一点让更多报文进来并没有减少流量。如果 CPU 已经到 90% 以上放宽阈值只会加速雪崩。只有在 CPU 还有余量、且确认流量是正常业务放大时才考虑。注意临时放宽阈值一定要设一个到期提醒比如 30 分钟后回看。我见过有人为了应急把阈值调到很大结果忘了改回来后来真遇到攻击时设备直接被打挂。4.2 根治从源头消除环路和攻击环路处理的标准动作是全设备启用生成树接入端口开边缘端口 BPDU 保护检查是否有端口被stp disable关掉了启用环路检测功能作为生成树的补充stp mode rstp stp bpdu-protection interface GigabitEthernet0/0/1 stp edged-port enable loop-detection enable攻击源处理的标准动作是定位到终端后先隔离再查杀最后加入准入策略。如果是内部员工 PC让 IT 重装或者杀毒如果是物联网设备考虑划入独立 VLAN 隔离。协议震荡处理要往上层看检查链路质量、光模块收发光功率、误码率排查是否存在物理层故障。4.3 CPCAR 阈值调整的取舍这一节单独讲因为太多人调错。调整阈值前要回答三个问题这类报文的正常峰值是多少当前实际峰值是多少CPU 还有多少余量估算正常峰值的方法是按规模算。举个例子一个接入交换机的端口数按 48 算每台终端平均每 5 分钟发一次 ARP 探测绝大部分设备比这更少那么 ARP 请求的平均速率约等于 48 / 300 0.16 pps即使考虑上线风暴某几秒内集中到 20 台终端同时上线也就 20 pps 量级所以如果你在统计里看到 8000 pps 的 ARP 请求那不是正常业务是异常流量。这时候把阈值从 256 调到 1024 毫无意义治标都算不上。反过来如果统计显示实际峰值 300 pps、阈值 256 pps那确实是阈值偏保守适当上调是合理的。配置示例具体语法以设备为准cpu-defend policy adjust-policy car packet-type arp-request cir 512 car packet-type arp-reply cir 512 car packet-type dhcp cir 512 cpu-defend-policy adjust-policy调整后的验证方式是观察 CPU 占用是否仍然在安全线以下建议留 30% 余量同时display cpu-defend statistics里的 Dropped 归零。如果上调之后 CPU 立刻飙升说明流量本身有问题立即回退。4.4 加固配置清单这一份清单我建议每个园区网都过一遍属于低成本高收益的配置加固项配置要点防御目标生成树保护RSTP 边缘端口 BPDU 保护环路与非法接入风暴抑制接入口广播/组播/未知单播限速广播风暴环路检测loop-detection配合告警生成树失效兜底DHCP Snooping信任口规划 绑定表私接 DHCP 与伪造ARP 限速基于源 IP 的 ARP 速率限制ARP 扫描与欺骗端口安全MAC 数量限制 违规动作私接小路由与 hub未用端口shutdown 划入隔离 VLAN非法接入配置完这份清单CPCAR 告警的出现频率会有量级上的下降。5. 常见问题速查与踩坑记录这一节是最值得反复看的部分。有些坑我踩过有些是同事踩过都记下来了。5.1 高频问题速查表现象可能原因处理动作告警只在凌晨固定时间出现备份任务、批量终端上线错峰处理或适当上调阈值告警伴随用户偶发掉线上行口 CPCAR 丢弃关键协议优先查 ARP/STP 类丢弃CPU 不高但告警频繁阈值设置偏保守核对默认值与业务规模后调整改了阈值告警仍在流量源头未处理回到第 3 章排查流程抓包看到大量同源 ARP终端网卡或软件异常隔离该终端抓包看到随机源 MAC伪造类攻击端口安全 告警联动只有个别端口出现下挂设备或终端问题从端口往下追全设备端口同时告警广播域过大或核心环路查核心互联与 Vlan 划分5.2 几个我亲身踩过的坑第一个坑看到告警直接重启设备。有次应急同事重启了主控告警消失了十分钟然后又回来了。因为重启只是清空了统计源头没动。重启对 CPCAR 类问题几乎没有任何价值还会产生一次全网路由收敛代价很大。第二个坑把 CPCAR 和 QoS 搞混。有同事试图用 QoS 策略限制上送 CPU 的流量配了半天没效果。原因是这两套机制作用的平面不同QoS 管的是转发面CPCAR 管的是控制面上送通道不在一个点上。第三个坑抓包时接口选错。端口镜像要选对方向。只做 inbound 镜像可能抓不到设备自己发出的 ARP 应答只做 outbound抓不到进来的请求。排查风暴时建议双向都抓或者用设备自带的抓包工具直接在 CPU 侧抓。第四个坑改完 CPCAR 阈值没做回退计划。临时上调的阈值如果没有记录、没有到期提醒几个月后变成隐患。我的做法是在配置里加注释同时在自己日历上设提醒超过一周没回看就强制自己复查一遍。第五个坑忽略了光模块和物理层。有一次排查了半天环路的锅最后发现是某个光口误码率飙升导致链路反复 up/down协议报文震荡。所以查协议震荡时别忘了看接口的 CRC 错误计数和光功率。5.3 关于告警等级的一个实践心得级别 4 意味着 Warning但 Warning 的严重程度完全取决于协议类型。我的经验是分三档处置涉及 ARP、DHCP 的告警影响终端接入30 分钟内必须响应涉及 STP、LACP 的告警可能引发环路或链路震荡立即响应涉及 ICMP、SNMP 的告警管理面告警可以排在业务处理之后同样一条日志协议不同紧急程度差出好几倍。所以我一直要求团队看告警必须看完整原文不能只看前后缀。这套流程我用了几年从最初的看到告警就心慌到现在能二十几分钟定位到具体端口。真正的关键在于别急着改参数先把丢的是哪个协议、量级超了多少、源头在哪个方向这三个问题答上来剩下的就是体力活了。另外如果你的网络规模超过两百台设备强烈建议把display cpu-defend statistics的输出接进监控平台做趋势图很多时候你在被告警之前趋势就已经变坏了。