如果你半夜被一条DEFD/4/CPCAR_DROP_MPU: Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol[STRING])的告警叫醒过大概会经历三个阶段先懵然后怀疑是不是设备要挂了最后才发现——设备其实活得好好的它只是做了一件自我保护的事顺手丢了一批本来要送给 CPU 处理的报文。这条日志属于典型的看着吓人、信息量很大的类型。它跟 CPU、MPU、CPCAR 这三个词绑在一起本质上是设备在告诉你某个协议的上送报文速率超过了我给这个协议预留的管道容量。这篇内容就是围绕这一条日志把这串字符背后的机制、常见触发场景、现场排查的完整链路以及调参前必须想清楚的取舍尽可能掰开揉碎讲一遍。不管你是刚开始接触网络设备运维还是已经处理过几次类似告警都能在这篇里找到可以直接抄走的命令和判断思路。1. 先把那串告警拆开读DEFD/4/CPCAR_DROP_MPU 里每个字段的来历很多人看到这条日志第一反应是去搜关键字搜完发现大家都在说调大 CPCAR于是照着改了一遍过两天又来了。问题的根源往往在于这条日志其实分成了五个信息片段每个片段都在回答不同的问题只盯着最后那个Protocol看很容易漏掉最关键的判断依据。1.1 DEFD 和那个孤零零的数字 4DEFD是设备内部防御 / 流量管理相关模块的标识负责的事情包括上送 CPU 报文的限速、异常源追踪、用户自定义流这类功能。你不需要记住这个缩写的全称但要知道一件事凡是带DEFD前缀的日志基本都属于设备在保护自己的控制平面这个范畴而不是转发面出了故障。斜杠后面的4才是真正决定你要不要从床上爬起来的东西。主流网络设备的日志级别沿用了一套八级划分从 0 到 70 是 Emergency1 是 Alert2 是 Critical3 是 Error4 是 Warning5 是 Notification6 是 Informational7 是 Debugging。也就是说/4/对应的是 Warning 级别。这个级别意味着什么它意味着设备在说我触发了自我保护机制主动丢弃了一部分报文而不是我的某个核心功能已经不可用。如果是 2 或者 3那确实要立刻处理4 的话可以先看清楚是哪个协议、丢了多少、持续了多久再决定要不要半夜开电脑。我见过太多人把 Warning 当成 Critical 来处理结果慌慌张张上去 reset 了一把统计计数把唯一的证据抹掉了——这是新手最容易犯的错后面第 4 节会专门讲。1.2 CPCAR_DROP_MPU 这三个词连起来读CPCAR展开是 Control Plane Committed Access Rate直译是控制平面承诺接入速率。这里有两个词值得单独拎出来。控制平面指的是 CPU 负责处理的那一部分工作协议邻居的建立和维持、表项的学习和老化、管理流量的应答、异常报文的处理等等。它跟转发平面是两回事——转发平面由专用芯片负责处理的是普通数据包能力动辄几百 Gbps 到几 Tbps控制平面由 CPU 负责处理的是需要动脑子的报文能力通常只有几千到几十万 pps。这两个数字差了大概三个数量级这个差距是理解整件事的地基。承诺接入速率是限速机制里的标准说法。承诺的意思是我保证给你这个速率在这个范围内我尽量不丢超过了这个承诺值就别怪我不客气。这里的不客气就是日志里的DROP。MPU是 Main Processing Unit主控板 / 主处理单元。为什么特意点出 MPU因为在框式设备里控制平面通常分布在主控板和业务板两处主控板的 CPU 处理的是全局性的协议和表项下发业务板的 CPU有的叫 LPU 上的 CPU更多处理本地转发相关的上送。日志明确写了 MPU说明这次丢包发生在主控单元的上送路径上排查的时候要优先看主控板的统计口径而不是随手抓一块业务板的计数来对比。1.3 Protocol[STRING] 才是这条日志里最值钱的部分方括号里的[STRING]在真实环境下会被替换成具体协议名比如arp、dhcp、ospf、bgp、stp、lldp、lacp、icmp、snmp、ntp、telnet、bfd、vrrp也可能是unknown-unicast、broadcast、fragment、ttl-expired这类非协议名的分类。这个字段直接决定了排查方向。举个对比例子如果 Protocol 是arp你的第一反应应该是是不是有环路导致的广播泛洪或者有终端在做 ARP 扫描如果是ospf或者bgp那要怀疑的是路由震荡——某个链路频繁 up/down 导致邻居反复重建每次重建都要重新同步大量表项上送量自然暴涨如果是stp八成是二层环路或者拓扑频繁变化如果是snmp那很可能是网管平台的轮询周期被谁偷偷改短了或者有多个网管系统在同时采数据。把这条日志的五个片段做成一张表阅读顺序就清楚了。片段含义排查时的作用DEFD防御 / 流量管理类模块标识确定这类日志归控制平面保护机制管4Syslog 级别 Warning判断紧急程度不致命但要记录CPCAR_DROP_MPU主控板上 CPCAR 限速导致丢弃锁定丢弃发生的位置在上送 CPU 路径Rate of packets to cpu exceeded上送 CPU 的报文速率超限说明是速率问题不是累计总量问题Protocol[STRING]触发限速的具体协议决定排查方向的第一把钥匙提示真实设备上这条日志会按一定周期重复出现而不是每丢一个包打印一条。如果你看到同一协议在短时间内刷了几十条说明该队列长时间处于超限状态这时候就不能只当瞬时突发处理了。2. CPCAR 限速的底层逻辑协议报文为什么要先排队再上 CPU理解了字段含义接下来要回答一个更本质的问题设备为什么要主动丢包好端端的报文直接送给 CPU 处理不行吗答案是不行而且这个不行背后是一套相当朴素的工程取舍。2.1 转发面和 CPU 的处理能力差了三个数量级普通数据包的转发走的是硬件通路报文进端口芯片查表直接从出口出去整个过程不经过 CPU。这个通路的处理能力由芯片决定一台中等规模的盒式设备做到几百 Gbps 很常见折算成小包大概是几千万 pps 的量级。而上送 CPU 的报文路径完全不同报文要先被芯片识别出来靠 ACL、协议类型、目的 MAC 等规则匹配打上标记送进一个专门的队列再由 CPU 逐一取出来处理。CPU 的优势是灵活能跑复杂的协议状态机劣势是慢而且它还要同时干很多别的事情——跑协议、下发表项、响应网管、处理日志。一旦上送路径不设闸门只要有一次广播风暴或者一次扫描上送队列就会被瞬间打满CPU 占用冲到 100%然后所有需要 CPU 参与的事情全部卡住路由邻居超时断开、管理连接无法建立、设备可能对业务查询完全没有响应。这就是所谓控制平面被打瘫。所以 CPCAR 的本质是一道闸门给每一类协议分配一个独立的令牌桶超过配额的报文直接在这里被丢掉让 CPU 始终能维持在一个可工作的负载水平上。它牺牲的是一部分报文的处理机会保住的是整个控制平面不崩。2.2 令牌桶怎么工作CIR 和 CBS 是一对搭档限速机制的核心是令牌桶理解它需要两个参数。CIRCommitted Information Rate是承诺速率单位通常是 pps 或者 kbps。你可以把它想象成水管的粗细每秒往桶里滴多少水滴。如果每秒流出的报文数不超过这个值长期来看是安全的。CBSCommitted Burst Size是承诺突发尺寸相当于桶的容量。桶不能无限大否则就起不到限速作用也不能太小否则正常业务里那些平时没流量、偶尔冒一批的协议就会被误伤。比如 ARP 表项老化的时候可能一瞬间有一批 ARP 请求要处理如果 CBS 太小这批突发就会被判超限虽然平均速率远没到 CIR。这两个参数的配合关系是这样的正常情况下报文消耗桶里的令牌令牌用完报文被丢弃或者降级处理同时令牌按 CIR 速率持续补充。所以评价一个队列是否被限速看的不是总流量而是瞬时速率是否持续超过了 CIR同时突发是否撑爆了 CBS。这也是为什么调参数不能只改 CIR。有些人为了消除告警只把 CIR 从 512 调到 5120CBS 却保持不变结果发现告警确实少了但 CPU 占用上去了遇到真正的洪泛时反而更容易被打满。这两个值要一起看。注意不同产品、不同版本的默认 CIR/CBS 取值差异很大老款设备的默认值往往偏保守因为当年的 CPU 性能有限新款设备的默认值会宽松不少。所以看到别的项目组改个 2048 就好了不要直接照抄先确认你手里的设备和版本。2.3 队列分类一条协议一条车道CPCAR 不是一个总闸门而是一组并联的闸门。设备会把上送 CPU 的报文按协议或者按特征分到不同的队列里每个队列有自己的 CIR/CBS互不影响。这样设计的好处是隔离ARP 被打满了不会影响 BGP 邻居的保活。常见的队列分类大致可以分成几类我做了一张对照表方便你在看到 Protocol 字段之后快速建立联想。队列类别典型协议 / 分类上送的常见原因二层协议STP、LLDP、LACP、MAC 学习类拓扑变化、环路、链路聚合协商邻居发现ARP、ND、DHCP、DHCPv6终端上线、表项老化、地址扫描路由协议OSPF、BGP、ISIS、RIP、PIM邻居重建、路由更新、路由震荡冗余协议VRRP、BFD主备切换、快速故障检测管理协议SNMP、NTP、Telnet、SSH、Syslog网管轮询、时钟同步、远程登录异常流量TTL 超时、分片、IP option、未知单播、广播探测、扫描、环路、表项缺失高精度业务精确时间同步类报文特殊行业对时钟精度的高要求每一条车道独立计费所以你在排查时要做的事情很明确先确认是哪条车道被挤爆了再看是谁往这条车道上灌了这么多车。很多人在这一步就走偏了一上来就去看整机 CPU 利用率发现只有 20%于是判断CPU 没问题然后把告警忽略了。这是典型的误判——单队列被限速并不需要整机 CPU 很高因为限速是在报文到达 CPU 之前就生效了CPU 根本没见到那批被丢掉的报文。3. 谁在把 CPU 打满把丢包现象对应回真实流量来源知道了机制下一步是找到源头。同样是 CPCAR 丢包背后的原因可能完全不同处理方式也差得很远。我把常见的原因分成正常业务突发和异常流量两大类先讲怎么区分再逐类拆解。3.1 第一步是分清正常突发和异常洪泛区分方法其实很朴素看三个维度。第一个维度是时间分布。正常业务突发通常有规律工作日白天多、夜间少或者集中在某个业务高峰期比如每天早上八点半到九点大量终端同时开机上线。异常洪泛往往没有规律半夜也在刷而且持续时间长。第二个维度是协议分布。如果是单一协议反复触发比如永远只有arp一个那大概率是这一类流量出了问题如果是arp、broadcast、unknown-unicast同时告警那基本可以确定是二层广播域出了状况比如环路。第三个维度是数量级。正常业务的瞬时上送量通常是几百到几千 pps 的量级而一次广播风暴能把某个队列推到几十万 pps。如果你看到统计里的丢弃数量在短时间内从几百跳到几百万不用犹豫先按异常处理。3.2 二层协议类环路、STP、LACP 这些老面孔二层问题是最常见的 CPCAR 触发源之一因为二层协议报文天然是广播或者组播一旦广播域出了问题影响面会迅速放大。环路是最典型的场景。一根网线两头插在同一个交换机上、两台接入交换机之间被误接了两根线而没配聚合、无线 AP 的上联串成了一个环形——这些都会导致广播帧在环路里循环放大。反映到 CPCAR 上通常是stp、broadcast、unknown-unicast、arp这几个队列同时告警。这时候你去看接口的广播统计会发现每秒几十万甚至上百万的广播包。LACP 和 LLDP 这类协议平时流量极低一旦告警往往意味着链路聚合成员口状态在不同的聚合组之间抖动或者有人在两端配置不匹配导致协商反复失败。这类问题的特点是丢包量不大但持续不断而且业务侧可能感觉不到明显异常属于温水煮青蛙型。处理二层问题的关键不是调 CPCAR而是找到环路或者配置错误。调参数只会把问题往后拖等到哪天报文量大到连调过的阈值都撑不住就是整网瘫。3.3 三层与管理面ARP、DHCP、路由协议、网管轮询三层相关的触发原因通常更贴近业务本身。ARP 是最活跃的一个队列。终端上线要发 ARP 请求网关要给终端回 ARP 应答表项老化后要重新学习跨网段通信要先解析下一跳 MAC。如果接入网段里终端数量大、上下线频繁ARP 请求量本来就高。如果再叠加一个 ARP 扫描工具或者某台设备中毒后疯狂扫描同网段地址ARP 队列很容易被顶爆。DHCP 的场景集中在终端集中上线时段。一个办公区早上八点半几百台终端同时开机发 DHCP Discover如果中继链路或者服务器响应慢终端会不停重试上送量就会持续偏高。这类问题可以通过延长租期、优化 DHCP 中继、或者在接入层做限速来缓解。路由协议触发 CPCAR 的场景多半是震荡。BGP 邻居因为链路闪断反复重建每次重建都要重新交互大量路由条目OSPF 在拓扑频繁变化时也会产生大量 LSU。这类问题的关键线索是邻居是否稳定你可以先去看邻居的 up/down 记录如果发现有反复那 CPCAR 告警只是表象根因在链路或者对端设备。管理面则是另一类。SNMP 轮询风暴在运维体系不太规范的环境里很常见一台设备被三四个网管系统同时监控每个系统的轮询周期还设得很短几百个 OID 每分钟采一遍SNMP 队列自然扛不住。NTP 如果配置了很短的同步间隔也会产生规律性的上送流量。这类问题相对好解决统一监控入口、拉长轮询周期即可。3.4 容易被忽略的未知单播、TTL 超时、分片、镜像除了上面这些正常协议还有几个特殊的分类经常被忽略。未知单播是指目的 MAC 在当前设备上还没学习到的单播报文。正常情况下这类报文会广播泛洪而某些安全策略下会被上送 CPU 以便学习。如果网络里出现了大量未知单播比如 MAC 表被攻击打满、或者做了 MAC 地址漂移这个队列就会起来。TTL 超时的报文通常来自 traceroute 类的探测。如果有人在网段里做大规模端口扫描或者路径探测会产生大量 TTL 为 1 的报文全部需要 CPU 回应。分片报文fragment和带 IP option 的报文属于需要特殊处理的类型正常业务里占比极低一旦上量基本可以判定是异常。远端镜像和本地抓包也会产生上送流量。有些工程师在排障时会临时启用镜像或者设备自带的抓包功能忘记关掉导致长期有流量被送到 CPU。这类问题排查起来有点绕因为协议字段看起来可能很正常但流量就是降不下来——记得检查一下镜像配置和抓包任务。4. 现场排查链路从日志到命令行再到抓包的完整取证过程认知层面理清了接下来是动手。我把整个排查过程拆成一个顺序执行的动作链每一步都有明确的目的而不是漫无目的地敲命令。4.1 第一步永远是固定现场别急着 reset这是最容易被跳过、也最容易造成损失的一步。发现自己第一反应想去敲reset cpu-defend statistics的时候请停下来。这个命令会把所有上送队列的 Pass / Drop 计数清零而清零之后你手里就再也没有丢了多少、从什么时候开始丢、丢的是哪个队列这三个关键信息了。正确做法是先采集再判断最后才考虑清零。采集的内容包括当前的统计计数、CPU 利用率、接口流量、日志缓冲区、邻居状态。把这些东西截图或者导出来保存好后面复盘和写故障报告都要用。提示如果设备支持把日志缓冲区的内容一起导出。display logbuffer能看到这条 DEFD 日志第一次出现的大致时间配合统计计数可以大致推算出丢包速率。4.2 用几条命令把范围缩到单个队列采集完现场接下来是把范围收窄。我通常按这个顺序走第一步确认整机 CPU 情况看是不是真的被顶满了。这一步是为了区分只是队列超限和CPU 已经不堪重负两种状态。如果 CPU 长期徘徊在 80% 以上说明问题比单纯的一个队列超限更严重可能有多类流量同时在冲击控制平面。第二步查上送统计这一步是核心。命令的作用是列出所有队列的通过和丢弃计数你看一眼哪个队列的 Drop 数在明显增长方向就定了。如果只想知道某个协议的情况也可以指定协议名单独查。第三步查配置确认这个队列的 CIR / CBS 到底是多少是否被人改过是否符合当前业务规模。这一步经常有惊喜——很多现场发现是别人之前为了压某个告警把值调得极低压下去之后一直没人管等到业务量上来了就撑不住。第四步查相关协议的状态比如接口的广播统计、STP 状态、ARP 表项数量、路由邻居状态。这一步是把哪个队列超了翻译成什么业务导致的。把这几步整理成一张命令对照表方便你在现场按图索骥。排查目标典型命令VRP 风格各版本略有差异看什么整机 CPU 负载display cpu-usage、display cpu-usage history是否接近满载、是否有周期性尖峰上送队列统计display cpu-defend statistics all各队列 Pass / Drop 计数单协议统计display cpu-defend statistics packet-type arp all指定队列的丢弃明细队列限速配置display cpu-defend configuration all当前 CIR / CBS 取值接口流量与广播display interface、display interface brief广播占比、有无异常突增二层拓扑display stp brief、display loop-detection是否有环路、拓扑变化次数ARP 情况display arp packet statistics请求 / 应答数量级日志痕迹display logbuffer告警首次出现时间、频率设备板卡display device、display version确认主控与业务板型号版本4.3 分板卡看MPU 和 LPU 的统计不是一个口径框式设备有一个很容易踩的坑上送 CPU 的报文可能来自不同的板卡而不同板卡的统计是分开的。日志里写了 MPU说明这次是主控板上的上送队列超限。但在分布式转发的架构下某些报文会先在业务板上做一次处理如果业务板判断需要送主控才会转发过去。所以你在业务板上看到的统计和主控板上看到的统计含义不同不能直接相加或者互相替代。实际操作中建议这样处理先看主控板也就是日志里点名的位置的统计确认告警来源然后再分别看各业务板的上送统计判断流量是从哪个板卡来的。如果某一块业务板的某队列计数特别高那问题就锁定在这块板卡所连的网段上了。这一步能省掉大量全网乱查的时间。4.4 抓包验证镜像口还是设备自带抓包统计只能告诉你多少个包被丢了不能告诉你这些包长什么样、从哪来、目的地址是什么。要拿到这些信息就得上抓包。两条路。第一条是端口镜像把怀疑的端口流量镜像到一个空闲口接上装了抓包工具的笔记本或者分析仪。这条路的优点是成熟稳定、对设备影响小缺点是只能看你镜像的那个方向如果流量来自多个端口得挨个镜像。第二条是设备自带的抓包功能。主流设备基本都支持在设备上直接定义抓包条件并把报文保存下来。这条路的优势是可以在 CPU 上送路径上直接抓能看到真正被送去处理的那批报文劣势是抓包本身会占用一点资源长时间抓取要谨慎。不管走哪条路抓包的时候都建议先设条件过滤比如只抓某个协议、某个源网段避免抓出一个几百兆的文件里全是无关流量。抓到之后重点看三件事源地址分布是不是集中在某几个终端、目的地址是不是在扫描网关或者扫描整个网段、包大小和间隔有没有明显的规律性规律性往往意味着是脚本或者工具在跑。5. 调 CPCAR 参数之前先想清楚这三件事找到原因之后一部分场景需要调参数比如业务规模确实增长了原来的默认值不够用。但调参不是把数字改大这么简单有几个问题必须先想清楚否则很容易按下葫芦起了瓢。5.1 你调的是阀门还是水源这是我在实际处理中最看重的一个判断。如果流量来源是异常攻击、环路、配置错误那么 CPCAR 就是阀门——你把它调大只是让更多的洪水灌到 CPU 里问题的根本还在而且可能引发更严重的后果。这时候要做的是关掉水源找到环路断掉它、找到攻击源做端口隔离、修掉错误的配置。如果流量来源是正常业务的规模增长比如接入的终端数量从五百涨到两千、新增了一条会频繁同步路由的链路那么 CPCAR 默认值不够用就是合理的这时候调大参数相当于给水管扩容属于正当操作。判断方法回到第 3 节讲的三个维度时间分布是否规律、协议分布是否单一、量级是否合理。这三个问题如果都指向不正常那就先治源头。5.2 调大之后 CPU 会不会直接被顶满这是一个必须在改之前估算的问题。假设你准备把某个队列的 CIR 从默认值提高一倍。那么在最坏情况下也就是这个队列持续满速上送CPU 需要额外承担的报文处理量也接近翻倍。这时候你要回答CPU 还有这么多余量吗评估方法有几个。一是看当前 CPU 利用率如果已经超过 50%那么翻倍之后很可能逼近满载风险较高。二是看这个协议在 CPU 处理中的开销路由协议的处理开销远大于简单的 ARP 应答同样是几万 ppsBGP 更新报文带来的 CPU 压力会大得多。三是看有没有可能分批上调比如先提高 30%观察一段时间再加而不是一步到位。另外一个容易被忽略的点是 CBS。前面讲过CBS 决定了能容纳多少突发。如果只提高 CIR 不改 CBS那么突发容忍能力其实没变只是长期速率上限提高了反过来如果只提 CBS 不提 CIR那么面对持续洪泛时保护效果会变弱。稳妥的做法是两个参数一起评估。5.3 哪些协议的阈值动了会牵连邻居和收敛不是所有队列都可以随便调。有几类协议的阈值改动会直接影响到控制平面的稳定性和网络的收敛速度。路由协议OSPF、BGP、ISIS 这类的队列如果被限速最直接的后果是邻居保活报文或者更新报文被丢轻则路由更新延迟重则邻居关系中断导致业务中断。这类队列的调整一定要在变更窗口做并且提前规划好回退方案。冗余协议VRRP、BFD的报文丢了可能触发主备切换或者让快速检测机制失效。BFD 因为发送间隔很短、报文很小单位时间内报文数量其实不低这是一个经常被低估的队列。二层协议的队列调整要格外小心因为这类协议的报文量本身不大一旦触发限速通常说明网络里已经有了严重问题调大阈值等于把警报器关掉了。STP 的丢包可能导致拓扑计算错误LACP 的丢包可能导致聚合口振荡。我一般建议的做法是先给一个不常用但重要的协议设置一个合理的保底值保证它不管什么情况下都不会因为队列配置过小而被丢对于那些明显是异常触发的队列优先治源头不到万不得已不动阈值。下面这张表总结了常见协议的调整风险和推荐策略。协议类别调整风险推荐处理方式路由协议OSPF / BGP / ISIS高直接影响邻居与收敛变更窗口操作提前准备回退配置冗余协议VRRP / BFD高可能触发主备切换谨慎上调同时确认检测间隔合理二层协议STP / LACP / LLDP高多半意味着已有故障优先定位环路或配置错误不轻易调阈值邻居发现ARP / DHCP / ND中与业务规模直接相关结合终端规模评估可配合接入层限速管理协议SNMP / NTP / Syslog低统一监控入口、优化轮询周期往往比调阈值更有效异常流量广播 / 未知单播 / 分片低但意义不大治源头调阈值只是掩盖现象注意任何 CPCAR 调整都属于控制平面配置变更建议先在测试环境或者单台非核心设备上验证确认没有副作用之后再推广到全网。分布式设备上还要确认配置能在主备主控之间正常同步。6. 从一次告警到长期治理订阅、基线与容量规划处理完一次告警只是解决了当次问题。真正省事的做法是让这类告警从半夜惊喜变成可预期的信号。6.1 建一条属于你自己的 CPCAR 基线所谓基线就是在业务正常的前提下各类上送队列的常态统计值大概是多少。采集方法很简单选一个业务平稳的时间段比如工作日的中午把上送统计采一遍连续采几天记录下来。你会发现某些队列的数值非常稳定比如管理协议可能一直是几十 pps某些队列会随业务波动比如 DHCP 在工作日的早上会有明显峰值。有了基线之后判断就变得很简单某个队列的计数明显偏离基线就值得看一眼如果偏离幅度很大且持续那就直接进入排查流程。这比等着设备发告警再从零开始查要主动得多。基线还有一个用处是做容量评估。比如你发现 ARP 队列的常态值是默认阈值的 70%那说明随着终端数量继续增长早晚会触发限速可以在业务淡季提前把阈值调上去而不是等到告警来了才动手。6.2 把日志变成可订阅的信号设备本身会周期性地打印这类日志但光靠设备上的日志缓冲区是留不住长期数据的重启或者刷屏都会把它冲掉。合理做法是把日志发送到统一的日志收集侧按模块和级别打标签。订阅的时候有几个细节值得注意。一是按模块过滤把这类的日志单独归一类避免混在大量无关日志里。二是区分级别Warning 级别的记录一次就够了不需要每次都触发告警但如果同一个协议在短时间内反复出现那就应该升级为需要关注的信号。三是保留上下文日志里带的协议字段一定要解析出来否则后续做统计时没法按协议分类。还有一种更主动的方式是采集上送队列的统计指标通过网管系统或者遥测的方式定期获取。相比日志统计指标是连续值能看到趋势日志是离散事件只能看到越界了。两者结合效果最好。6.3 变更与回退调参要留退路这一节讲的是操作层面的纪律跟技术关系不大但踩坑的人特别多。任何针对控制平面的调整都要按变更流程走。上线前记录当前的完整配置调整时只动需要动的那几行调整后立刻观察一段时间。观察的内容包括目标队列的丢弃计数是否下降、CPU 利用率是否在可接受范围、相关协议的邻居是否稳定。回退方案要提前想好。如果调大之后 CPU 明显上升或者协议出现异常要能快速恢复到原来的配置。建议的做法是在变更前把涉及的命令行单独整理出来回退时直接执行反向配置而不是临时去想要改哪个值。还有一个细节分布式设备上调整这类配置之后要确认主备主控之间的配置同步正常。我遇到过调整完主用主控之后备用主控上的配置没有同步结果一次主备切换之后配置又回到了旧值问题复现排查了半天才发现是同步的问题。6.4 我踩过的几个坑最后分享几个实际踩过的坑都是那种文档里不会写、但现场特别容易遇到的。第一个坑是只看 CPU 利用率。有一次现场告警响了一整天值班的人看了一眼 CPU 说只有 15%判断没事。结果第二天业务投诉说某片区域的终端上网时断时续回头一查是 ARP 队列的阈值被调得过低正常的上线请求都在被丢。整机 CPU 不高是因为报文压根没到 CPU 就被丢了。这个教训很深刻判断控制平面是否健康不能只看 CPU 利用率。第二个坑是清空统计太快。前面提过但值得再强调一次。有次为了看新的统计直接清空了计数结果事后要写故障报告时连丢了多大量都说不清楚只能凭日志条数估算。第三个坑是照抄别的项目的参数。同样型号的设备在不同业务规模下合理的阈值完全不同。照抄的结果往往是告警没了但隐患留下了。第四个坑是忽略接入层。很多这类问题的最优解并不在核心设备上调参数而是在接入层做广播抑制、端口安全、DHCP 限速。核心设备上的 CPCAR 是最后一道防线把防线修得再高也不如把问题拦在接入层。第五个坑是忘记关抓包和镜像。排障时临时开的抓包任务排完忘了关一直挂着占用资源还时不时产生一些奇怪的上送流量。建议每次排障结束后过一遍当时的临时配置把该清的清掉。处理这类告警的次数多了之后我的体会是它更像一个提醒你控制平面正在承受压力的健康信号而不是一个必须立刻消灭的故障。看到它先按前面说的链路走一遍——固定现场、确认队列、定位协议、判断来源、区分正常异常绝大部分情况都能在半小时内定性。真正需要动参数的场景其实不多而每一次动参数都值得你多花十分钟想清楚这是在扩容还是在关警报器。