S12700/S12700E 核心交换机 CPU 飙高怎么查：别急着封 IP，先把证据链走完

适用说明

这篇只对下面这个范围负责，出了这个范围请以对应版本文档为准。

目标读者：负责园区网运维的网络工程师，用过华为 S 系列接入/汇聚，但对框式核心的"两级上送"和本机防攻击机制不熟的同行。

一、先拆掉一个常见前提：CPU 高不等于业务变慢

框式交换机的数据转发走的是硬件通路——报文进业务板，由转发芯片查表转发，必要时经交换网板到另一块业务板出去。主控板上的 CPU 处理的是控制面：协议报文收发、表项计算与下发、设备管理。

这两条路径基本是分离的。所以 MPU 的 CPU 到 87%，正在转发的大象流通常一点感觉都没有；反过来，业务确实慢了，CPU 也完全可能只有 15%。

那 CPU 高什么时候会真的影响业务？据文档能确认的路径有三条：

一是表项计算和下发的节奏被打断。 CPU 忙着处理上送报文，ARP 学习、MAC 老化这些动作被推迟，出现"表里有、实际转不了"的空窗。

二是协议报文被 CPCAR 丢掉，导致协议状态震荡。 文档明确写了多协议并行时，报文可能因超 CIR/CBS、超队列速率或超 CPU 处理总数被丢，表现是协议震荡。这时候业务中断不是因为 CPU 忙，是因为路由撤了、网关切了。

三是管理面卡顿。 SSH 登不上、网管采不到数据。这是运维体验问题，不是业务问题，别混在一起算。

也就是说，"CPU 高"和"业务慢"是两件需要各自取证、然后对上时间轴的事。不做这一步，后面所有排查都缺少立足点——你可能花了三小时抓住一个和本次投诉毫无关系的攻击源。

建立相关性要四类证据

有个坑要提前说：ping 的结果不能直接当业务时延。 ICMP 应答有可能由 CPU 处理，也有设备支持由硬件直接回应（文档在讲报文捕获限制时提到过"Ping 快回"这类特性，说明它存在）。这两种情况下，ping 时延升高代表的东西完全不同——前者说明 CPU 忙，后者说明转发通路有问题。用 ping 下结论之前，先确认这台设备上 ICMP 是怎么被处理的。

四类证据叠到同一根时间轴上，会落到三种结论：

• 重合：故障窗口内 CPU 峰值、协议事件、接口异常同时出现 → 继续往下查控制面
• 不重合：CPU 高但业务指标平稳 → 暂不作为业务中断事件处理，但不能就此收工。87% 的控制面负载离协议报文被丢已经不远了，要持续盯三样：CPU 余量（VIDL 还剩多少）、CPCAR 有没有开始丢包、协议邻居有没有闪断。任意一样恶化，立刻升级为故障处置
• 反向：业务劣化但 CPU 全程低位 → 方向在转发面或链路，立刻离开这篇文章的主题

二、一条时间线：看证据是怎么串起来的

下面是合成的示例，脱敏处理过，用相对时间。它的价值不在于情节，在于展示每一步"看到什么才算数"。

注意这条线最后没有落在"锁定某个攻击者"。现场绝大多数"CPU 被 ARP 打高"的案子都是这个走向：不是有人攻击，是接入侧环路、私接路由器、或者一批设备同时上线把广播放大了。这也是为什么不能一看到 CPCAR_DROP 就去封 IP。

三、原理：三条日志通道、三道闸、四道关口

3.1 同一件事，三条日志

上送 CPU 的报文超过 CPCAR 被丢，这件事在不同单板上写进三条不同的日志：

只按 CPCAR_DROP_MPU 过滤日志，业务板上丢掉的包对你完全不可见。这是框式设备和盒式设备最实际的一个差别。

CIR/CBS 直接写在日志里，意味着你不用翻配置就知道设备当时采用的限速参数——这一点在排查"我明明调过参数"的时候特别有用。但日志记的是逻辑配置值，芯片里真正跑的值可能被粒度离散化和安全上限改过，要确认实际生效值还得用 display cpu-defend applied 核对（见 5.2）。

3.2 CPCAR 是三道闸，取最小值

CPCAR（Control Plane Committed Access Rate）不是一个限速器，是三层叠着：

按协议限速：每种协议报文单独设 CIR 和 CBS，超了丢。目的是让协议之间互不干扰。

按队列调度和限速：管理类协议进一个队列，路由协议进一个队列，队列间按权重或优先级调度，队列本身也能限速。

整机统一限速：兜住 CPU 处理报文的总数。

文档原话：三种限速方式同时生效时，设备以最小限速值进行限速。

这句能解释很多"改了没反应"。你按 OSPF 报文量算完觉得 CIR 配得够，实际生效的也许是队列那层或整机那层更紧的限速。改一个数字没动静，先确认自己改的是不是当前最紧的那道闸。

3.3 上送的判定顺序：依据版本，不要凭记忆

V200R025C00《本机防攻击简介》里写的是这个顺序：

默认 CPCAR 限速 → 黑名单 → 白名单 → 用户自定义流 → 上送 CPU

• 命中黑名单：直接丢
• 命中白名单：再按 ACL 动作，permit 优先上送，deny 丢弃
• 命中用户自定义流：按流里配的 car 限速或 deny 丢弃
• 都不命中：正常上送 CPU

黑名单在 CPCAR 之后，不在之前。 这个顺序有个直接后果：黑名单不会减少 CPCAR_DROP_* 的计数，因为那部分报文在 CAR 那一层就已经被丢了，轮不到查黑名单。黑名单真正降低的是 CPU 侧任务负载——它把"允许通过限速"的那部分攻击报文挡在 CPU 门外。

如果你的目标是让 CPCAR_DROP 归零，调黑名单没用，只能减少流量本身或者调 CAR 值。这个区别在写处置方案时经常被搞混。

统计口径上还有个反直觉的地方。文档说：X 系列单板统计丢弃报文时，黑名单用户的流量不在统计范围内；其他单板因为黑名单流量在统计之后才丢弃，统计信息里包含已丢弃的黑名单流量。也就是说 Drop 这一列，在不同单板上含义不一样——X 系列上是纯 CPCAR 超限，非 X 系列上可能混着黑名单丢弃。看到数字先确认板卡类型，别一上来就归因于限速。

需要提醒：判定顺序属于实现细节，不同产品、不同软件版本可能不一致。动手前请查当前版本对应文档里的处理流程图，不要拿别的版本的顺序套。

3.4 四个功能，三种白名单

CPU 防攻击（CPCAR） 只管限速，超出就丢。分不清好人和坏人。

攻击溯源 解析报文、统计分析、识别攻击源，然后告警或惩罚。维度三种：源 IP、源 MAC、源接口+VLAN，默认开前两种。惩罚默认是关的，也就是默认只告警不动手，要动手得配 auto-defend action。

端口防攻击 基于端口维度，比攻击溯源温和：超阈值后，未超出协议限速值的那部分报文被移进低优先级队列再上送，超出的才丢。文档说它"对设备正常业务造成的影响更小"。这个功能缺省就是使能的，所以你会看到 SECE/4/PORT_ATTACK_OCCUR，哪怕自己没配过。

用户级限速 按源 MAC 哈希分桶，一个人打只限他自己。

三种白名单语义不同，这是最容易配错的地方：

• CPU 防攻击的 whitelist：设备优先处理这些报文
• 攻击溯源的 auto-defend whitelist：不溯源
• 端口防攻击的 auto-port-defend whitelist：不溯源也不限速

前者的意思是"你插队"，后两者是"我不管你了"。

3.5 一个硬约束：应用在哪一级，名单就只管哪一级

文档"应用防攻击策略"一节的注意事项：

如果防攻击策略应用在接口板，黑白名单和用户自定义流只对上送接口板 CPU 的报文有效；如果应用在主控板，黑白名单和用户自定义流只对上送主控板 CPU 的报文有效。

只在主控板应用策略，黑名单就管不到接口板那一级的报文。另外几条约束：一块单板只能应用一个防攻击策略；global 和单槽位应用互斥；阈值和采样比这类数值，主控板要比接口板略大。设备最多支持 33 个策略，其中 default 是系统自带、默认应用到所有单板、不允许删除也不允许改参数；新建策略里你没配的项，会继承 default 的缺省值。

最后这条对回滚很有用：把自定义策略的应用撤掉，设备就回到 default。

四、六步证据链

每一步都有"成立"和"不成立"两个出口。不成立就退回上一步换方向，不要硬往下推。

第 1 步：确认 CPU 高与业务劣化是否相关

用第一节那四类证据对齐时间轴。判据：

• 成立：CPU 峰值时间与业务劣化窗口重合，且至少有一类协议侧或接口侧证据同步异常
• 不成立：时间对不上，或业务劣化期间 CPU 全程低位 → 离开本主题，查转发面

这一步不成立还硬查下去，是这类故障最常见的时间黑洞。

第 2 步：定位是哪个任务在吃 CPU

<HUAWEI> display cpu-usage

回显字段结构如下（引自文档示例，时间戳为文档自带）：

CPU Usage Stat. Cycle: 60 (Second)
CPU Usage : 20% Max: 94%
CPU Usage Stat. Time : 2019-10-23 09:47:32
CPU utilization for five seconds: 11%: one minute: 11%: five minutes: 11%
Max CPU Usage Stat. Time : 2019-10-23 08:46:22.
TaskName CPU Runtime(CPU Tick High/Tick Low) Task Explanation
VIDL 80% e/eb7733fe DOPRA IDLE
OS 10% 1/57529fff Operation System
ROUT 8% 0/3ccbf700 ROUTRoute task
STP 1% 0/3e3a2d00 STP
ARP 0% 0/ b71b00 ARP
DEFD 0% 0/ b71b00 DEFD CPU Defend

看四个地方：

三个时间窗。 five seconds 高而 five minutes 不高是瞬时突发；三个都在高位是持续负载。

峰值和峰值时间。 CPU Usage : 20% Max: 94%，前者当前值，后者历史峰值。Max CPU Usage Stat. Time 要和报障时间对齐——现场最常见的情况是"我登上去看时已经不高了"。

任务名。 对照关系：

DEFD 尤其要分清。 它高不一定是被攻击，也可能是防攻击自己太费劲——采样比配太低、防范报文类型太多、策略里挂了一堆 ACL 用户自定义流。

第 3 步：定位是哪块单板在丢

<HUAWEI> display cpu-usage slot 3
<HUAWEI> display cpu-usage slave

这里有个判断很容易写错，需要说清楚：业务板 CPU 高不能推出"与控制面上送无关"。

业务板的 CPU 既处理本地表项（MAC、ARP、ACL），也承担报文上送主控板之前的那一轮防攻击处理。业务板 CPU 高，完全可能正是它在处理、丢弃、或者大批量上送协议报文——CPCAR_DROP_LPU 这条日志本身就是发生在业务板上的。

正确的判据是分情况：

• 业务板 CPU 高、且该槽位的 CAR 统计里有对应的 Drop → 上送路径的问题，就在业务板这一级
• 业务板 CPU 高、CAR 统计干净 → 再看本地表项（MAC/ARP 规格、ACL 命中）、端口流量
• 只有主控板高 → 先看 top 任务是什么。ROUT、STP、OS 这些任务自己出问题也会把 CPU 顶高，与上送无关；只有在 top 任务里看到 DEFD、ARP 这类和处理上送相关的任务，并且 CPCAR_DROP_MPU 或具体报文类型的统计有对应数值，才能把结论落到"上送路径的瓶颈在主控板这一级"。同时也别忘回头确认业务板侧没有先丢过一轮

一句话：三块板都要确认，不是三选一。

第 4 步：定位是哪类报文在丢

<HUAWEI> display cpu-defend statistics all

字段结构：

Statistics on slot 1:
——————————————————————————–
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
——————————————————————————–
8021x 0 0 –
arp-mff 0 0 –
arp-miss 0 0 –
…

Pass 通过，Drop 被 CAR 丢弃，Last-dropping-time 最后一次丢包时间。

Last-dropping-time 只证明"这个时间点发生过丢包"，它不能证明这些丢包就是 CPU 高的原因。时间和机制都对得上，才只是候选原因；要确认因果，还得叠加 top 任务、逐板统计、攻击源、以及处置后是否恢复这四样。

这里必须强调统计口径，否则容易得出假阴性。以下任意一条成立，Drop 全 0 都不能说明"没有上送洪水"：

• 只查了主控板（没加 all，或只看了 mcu），业务板那一级完全没覆盖
• 用了 packet-type 过滤，而本次相关的报文类型不在过滤范围内
• 策略没真正生效：只在主控板应用，或黑白名单/自定义流下发失败
• 计数器被清过：reset cpu-defend statistics 不带 all/slot 时只清主控板，其他单板的计数还在；反之清错了板子也会误导
• 流量走的是管理网口，本机防攻击不覆盖管理网口
• 黑名单流量在 X 系列单板上不计入统计：这类单板上黑名单丢的包看不见；而非 X 系列单板反过来，黑名单流量会混进 Drop 里，让你高估 CPCAR 的作用
• 报文在上游就被丢了：端口防攻击移入低优先级队列、或 ACL deny，这些不体现在 CAR 的 Drop 里

所以正确的判断是：Drop 有值 → 存在机制证据，继续查；Drop 全 0 → 只能说"在这条命令覆盖的范围内没有 CPCAR 超限丢包"，不能直接否定控制面上送异常。

想把范围缩到具体报文类型：

<HUAWEI> display cpu-defend statistics packet-type arp-request slot 1

一个文档里的注意事项：设备使能 MFF、VPLS 或 NAC 功能时，主控板上 ARP-REQUEST 类型的限速和统计里也会包含 ARP-REPLY 报文。开了这些特性的环境里，arp-request 计数高不等于有人在打 ARP Request。

第 5 步：判定是否真的存在攻击源

<HUAWEI> display auto-defend attack-source

三张表（User / Port / IP）分别对应源 MAC、源接口+VLAN、源 IP 三个维度。但别从"哪张表有数据"反推设备启用了哪个维度——同一个攻击源完全可能被多个维度同时记下来，多张表都有数据是常态，不是设备"识别了三次"。要确认启用了哪些维度，看配置：

<HUAWEI> display auto-defend configuration

回显里 auto-defend trace-type : source-mac source-ip 这一行就是当前实际启用的维度。攻击源表的作用是判断流量形态，不是判断配置。

这一步的核心不是"有没有数据"，而是"数据说明了什么形态"。 几种典型组合：

前面那种"端口收敛 + MAC 单一"的情况，就是第二节案例里的形态——不是攻击者，是环路。

三个操作上的坑：

查不到数据，先怀疑功能没开。 攻击溯源要 auto-defend enable，配在策略里，再把策略应用到主控板或槽位，才生效。只配了不应用等于没配。

默认只溯源源 IP 和源 MAC。 变源 MAC 的攻击会让这两张表散成几百条小记录，看不出重点。这种场景要加 source-portvlan。

溯源模式不是所有报文都支持三种。 文档有对照表：802.1X 只支持源 MAC 和源接口+VLAN；ARP、DHCP、IGMP、ND 三种都可以；ICMP、TTL-expired、Telnet、TCP、UDP 只支持源 IP 和源接口+VLAN。配之前对一下表。

第 6 步：处置、验证、回滚

顺序不能反：先抓包留证，再处置。 一旦进了黑名单或被 CAR 丢掉，报文到不了 CPU，capture-packet cpu 就抓不到你要的证据。反过来也要清楚这份证据的边界——它只包含"已经放行"的报文，被 CPCAR 丢掉的量不在里面，具体见 5.3 的对照表。

处置完之后必须验证三件事：CPU 是否回落、Drop 是否归零、业务是否恢复。这三件都成立，才能说"根因是它"。只看到 CPU 回落还不够——CPU 回落也可能是因为攻击自己停了。

具体命令见下一节。

五、配置示例

以下按"备份 → 前置检查 → 抓包留证 → 处置 → 验证 → 撤销"的顺序排。

有两件事先说清楚，否则照着敲会卡在半路：

命令块保留了提示符，粘贴时只复制提示符后面那段。 <HUAWEI> 是用户视图，[HUAWEI] 是系统视图，[HUAWEI-acl-basic-2001] 是 ACL 视图，[HUAWEI-cpu-defend-policy-xxx] 是防攻击策略视图。保留它们是为了让你一眼看清每条命令该在哪个视图下执行——把提示符一起粘进去会直接报错。

有两处会停下来等你确认，不能无人值守跑。 save 会问 Are you sure to continue?[Y/N]；调整 CPCAR 会弹 Warning: Improper parameter settings… Continue? [Y/N]。见 5.1 和 5.8。

5.1 先备份

save 不是备份，这两件事经常被混为一谈。 save 只是把当前运行配置写进设备存储介质，用于重启后生效；它不产生历史版本，也没法用来回滚——改错了配置再 save，存下来的就是改错之后的那一版。

真正的基线是把配置导出来存到设备之外：

<HUAWEI> display current-configuration

把回显完整复制到本地文件（或者用 SecureCRT、Xshell 的日志记录功能自动落盘），文件名带上设备名和日期，比如 S12700-A_20261029_before.txt，放进版本库或配置备份平台。基线要存全量，只截防攻击那一段，回滚时缺上下文对不上。

只取防攻击相关段落用于改动前速查是可以的：

<HUAWEI> display current-configuration | include cpu-defend

save 该做还是要做，但它属于变更收尾，不是变更前的保险。执行时会出现：

The current configuration will be written to the device.
Are you sure to continue?[Y/N]

这里必须人工回 Y。

5.2 前置检查（只读，不改任何东西）

<HUAWEI> display cpu-defend policy
<HUAWEI> display auto-defend configuration
<HUAWEI> display cpu-defend applied packet-type arp-request slot 1

display cpu-defend policy 的回显里有两个字段最关键：

Name : test
Description : defend_arp_attack
Related slot : <2,8>
WhiteList&Blacklist&UserDefineFlow Status :
Slot<2> : Success
Slot<8> : Success

Related slot 告诉你策略实际应用到了哪些槽位；WhiteList&Blacklist&UserDefineFlow Status 告诉你黑白名单和自定义流在各槽位有没有下发成功。这个字段如果不是 Success，后面的统计全是假阴性——你以为在防，其实没生效。

display cpu-defend applied 看的是芯片里实际生效的 CAR 值。它和你配的值可能不一样：CIR 在芯片上是离散的，芯片粒度 64Kbps 时，你配 65 到 128 之间任何值，实际可能落到 64 也可能落到 128；配得太大超过芯片能力或安全警戒值，会被压下来。调完参数不复核这一条，等于对着空气调参。

5.3 先抓包留证

capture-packet cpu 引用的 ACL 必须是已经创建、而且已经有规则的对象，否则命令直接不生效——按文章顺序操作时最容易踩的就是这个坑。所以先建 ACL 2099：

<HUAWEI> system-view
[HUAWEI] acl number 2099
[HUAWEI-acl-basic-2099] rule 5 permit source 10.1.1.0 0.0.0.255
[HUAWEI-acl-basic-2099] quit

这里的 /24 是可以的，和 5.4 的规则不矛盾：抓包只是观察，不封禁，范围放宽一点反而不会漏掉同网段的其他源。封禁用的 ACL 才必须用主机掩码。acl 参数支持 2000～5999（IPv4），或 ipv6 的 2000～3999。

然后开始抓：

[HUAWEI] capture-packet cpu acl 2099 destination file flash:/cpu_attack.cap time-out 60 packet-num 5000

抓完把 flash:/cpu_attack.cap 取回本地用 Wireshark 打开。这条命令不需要 undo——time-out 到点或抓够 packet-num 会自动失效，也不会写进配置文件。

但它抓到什么、抓不到什么，必须说清楚：

所以它的定位是"证明有这类报文到达了 CPU"，不能当"整条上送路径的完整证据"用，更不能拿样本量去反推攻击量级。要凑齐完整图景，得加三个来源：接口侧 display interface 的入方向速率和广播计数（看放大了多少）、display cpu-defend statistics 的 Drop（看被丢了多少）、以及上游交换机的端口镜像（看原始流量长什么样）。

还有个反作用要提前知道：文档明确写了执行抓包命令会导致 CPU 占用率升高，CPU 已经很高时"不建议继续执行该命令"，具体阈值以设备 Warning 为准。所以抓包要限时限量，别指望抓十分钟。

几个具体限制：packet-num 缺省只有 100，上限 10000；time-out 缺省 60 秒；packet-len 缺省 64 字节（未装长报文捕获插件时这也是上限），ARP、ICMP 这类短报文够看，带选项的 IP 报文会被截断；捕获有速率限制（缺省 64kbps），突发超过会丢包，所以包序号不连续是正常的；同一时刻只能有一个抓包实例；文件名必须是 .cap。

5.4 定义 ACL

抓包用了一条（2099），处置这边再建三条，分别对应黑名单、白名单、用户自定义流，全部写全，避免复制后引用到未定义对象。

黑名单用单主机掩码，不要用网段——确认的攻击源就是确认的那一个地址，写 /24 会误伤整个网段：

<HUAWEI> system-view
[HUAWEI] acl number 2001
[HUAWEI-acl-basic-2001] rule 5 permit source 10.1.1.100 0
[HUAWEI-acl-basic-2001] quit

白名单放确认合法的网段（比如周边服务器、网管、互联端口所在网段）：

[HUAWEI] acl number 2002
[HUAWEI-acl-basic-2002] rule 5 permit source 10.2.2.0 0.0.0.255
[HUAWEI-acl-basic-2002] quit

用户自定义流放"来源不确定但需要限速"的网段：

[HUAWEI] acl number 2003
[HUAWEI-acl-basic-2003] rule 5 permit source 10.3.3.0 0.0.0.255
[HUAWEI-acl-basic-2003] quit

5.5 建策略并应用

[HUAWEI] cpu-defend policy anti_cpu_flood
[HUAWEI-cpu-defend-policy-anti_cpu_flood] blacklist 1 acl 2001
[HUAWEI-cpu-defend-policy-anti_cpu_flood] whitelist 1 acl 2002
[HUAWEI-cpu-defend-policy-anti_cpu_flood] user-defined-flow 1 acl 2003
[HUAWEI-cpu-defend-policy-anti_cpu_flood] car user-defined-flow 1 cir 4000
[HUAWEI-cpu-defend-policy-anti_cpu_flood] quit

blacklist 后面的 1 是索引，不能省。一个策略最多 8 条黑名单（IPv4 与 IPv6 合计），索引范围 1 到 8。配黑名单时设备会提示 Info: This configuration may cause packet loss.，这是正常提示，不是报错。

应用有三种方式。系统视图下不带 global 是应用到主控板：

[HUAWEI] cpu-defend-policy anti_cpu_flood

槽位视图是应用到单块业务板：

[HUAWEI] slot 1
[HUAWEI-slot-1] cpu-defend-policy anti_cpu_flood
[HUAWEI-slot-1] quit

想一次应用到所有业务板，用系统视图加 global。注意 global 和单槽位应用互斥，不能同时用。

前面反复强调的那条约束在这里落地：只在主控板应用，黑名单管不到业务板那一级。所以要么两处都配，要么用 global。

5.6 验证

<HUAWEI> display cpu-defend policy anti_cpu_flood
<HUAWEI> display cpu-defend statistics all
<HUAWEI> display cpu-defend applied packet-type arp-request slot 1

逐项对：Related slot 是否包含预期槽位，Status 是否 Success，关注报文类型的 Drop 是否下降，display cpu-defend applied 的实际 CIR 是否符合预期。

5.7 撤销与回滚

按"先撤应用，再删配置"的逆序走，否则策略还被引用着，删不掉。

撤应用这一步要看你当初怎么应用的，三种方式对应三条不同的命令，别混：

当初用 global 应用到所有业务板：

[HUAWEI] undo cpu-defend-policy anti_cpu_flood global

当初在系统视图不带 global、只应用主控板：

[HUAWEI] undo cpu-defend-policy anti_cpu_flood

当初在槽位视图逐块应用：

[HUAWEI] slot 1
[HUAWEI-slot-1] undo cpu-defend-policy
[HUAWEI-slot-1] quit

命令参考里的完整格式是 undo cpu-defend-policy [ policy-name ] [ global ]，两个参数都可省略。省掉 global 撤的是主控板上的应用，带上 global 撤的是所有接口板上的应用——撤主控板不会连带撤掉业务板的，这是现场最容易漏的一处：你以为撤干净了，业务板上那套策略还在拦包。

撤完必须回查，不然撤了等于没撤：

<HUAWEI> display cpu-defend policy

Related slot 里不该再有你打算撤掉的那个槽位。想单独看某个策略，用 display cpu-defend policy anti_cpu_flood 看同一个字段。

撤掉应用后，对应单板回到 default 策略——这就是最直接的应急恢复手段：一旦发现误伤业务，先撤应用，别在那里逐条改 ACL。 default 是系统自带策略，不允许删除也不允许改参数，不会因为你的操作被破坏。

要连配置一起清掉：

[HUAWEI] cpu-defend policy anti_cpu_flood
[HUAWEI-cpu-defend-policy-anti_cpu_flood] undo blacklist 1
[HUAWEI-cpu-defend-policy-anti_cpu_flood] undo whitelist 1
[HUAWEI-cpu-defend-policy-anti_cpu_flood] undo user-defined-flow 1
[HUAWEI-cpu-defend-policy-anti_cpu_flood] quit
[HUAWEI] undo cpu-defend policy anti_cpu_flood

ACL 也要一并清，否则留着是隐患——四条都要清，包括抓包用的 2099：

[HUAWEI] undo acl number 2001
[HUAWEI] undo acl number 2002
[HUAWEI] undo acl number 2003
[HUAWEI] undo acl number 2099

最后对着 5.1 存的全量基线逐段比一遍：

<HUAWEI> display current-configuration | include cpu-defend

确认没有残留的 cpu-defend policy、blacklist、user-defined-flow 之后再 save。顺序反了，回滚需要的信息就被覆盖掉了。

5.8 关于调 CPCAR 值

这是最后手段，不是首选。DEFD/6/CPCAR_DROP_* 的处理步骤本身给的就是这个顺序：先开溯源确认有没有真实攻击源，有就黑名单或惩罚，没有才考虑调值。

[HUAWEI] cpu-defend policy anti_cpu_flood
[HUAWEI-cpu-defend-policy-anti_cpu_flood] car packet-type arp-request cir 120

单位是 kbit/s。敲下去会出现：

Warning: Improper parameter settings may affect stable operating of the system.
Use this command under assistance of Huawei engineers. Continue? [Y/N]:

这个 Warning 不是走过场。同一份文档在处理步骤里也写了"调整 CPCAR 不当将会影响网络业务，如果需要调整 CPCAR，建议联系技术支持人员处理"。生产环境里，我建议这项改动走变更流程，别在故障现场顺手改。

六、版本相关的事实清单

文中若干结论依赖具体版本，逐个标出来，方便换版本时逐条核对。用的是 CHM 离线文档，没有可稳定引用的 URL，所以按"手册名 + 一级章节 + 小节名"定位；在线版在 support.huawei.com 对应版本的产品文档里搜同名章节即可。

换版本之后，最省事的做法是在设备上直接敲 display cpu-defend policy 和对应命令的 ? 帮助，以回显为准。文档是参考，回显是事实。

七、五个坑

坑一：直接把 CAR 值调大。 CPCAR 是保护 CPU 的最后一米，不是性能参数。闸门开大，洪水直接灌进 CPU，本来只是"网慢"，会变成"全网瘫"。而且调了未必生效，见坑三。

坑二：只查主控板。 接口板丢了一堆、主控板一条没丢，mcu 干干净净，结论就变成"没有攻击"。用 all，日志里 CPCAR_DROP_MPU 和 CPCAR_DROP_LPU 分开过滤。反过来的错误也一样常见：看到业务板 CPU 高就断定"跟控制面无关"，把最该查的一条线跳过去了。

坑三：以为配了个数就生效了。 真正跑的是 display cpu-defend applied 那个值。CIR 受芯片粒度离散化，超出安全警戒值会被压。还有 WhiteList&Blacklist&UserDefineFlow Status 那一栏，不是 Success 就等于没配。

坑四：把采样比调成 1 求精度。 默认 5，调小精度更高但每包都要解析计算，CPU 跟着涨。排障时本来就 CPU 高，再调到 1，等于自己给自己加负载。

坑五：以为管理网口也在保护范围内。 文档写得很短：以上所有 CPU 防攻击功能对设备的管理网口不起作用。从管理网口方向来的攻击，CPCAR 管不了，严重时连登录都进不去。这种场景只能靠上游设备或管理网 ACL。

八、判据小结

#mermaid-svg-TYFwNBa0oPkWI9dd{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-TYFwNBa0oPkWI9dd .error-icon{fill:#552222;}#mermaid-svg-TYFwNBa0oPkWI9dd .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-TYFwNBa0oPkWI9dd .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-TYFwNBa0oPkWI9dd .marker{fill:#333333;stroke:#333333;}#mermaid-svg-TYFwNBa0oPkWI9dd .marker.cross{stroke:#333333;}#mermaid-svg-TYFwNBa0oPkWI9dd svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-TYFwNBa0oPkWI9dd p{margin:0;}#mermaid-svg-TYFwNBa0oPkWI9dd .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd .cluster-label text{fill:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd .cluster-label span{color:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd .cluster-label span p{background-color:transparent;}#mermaid-svg-TYFwNBa0oPkWI9dd .label text,#mermaid-svg-TYFwNBa0oPkWI9dd span{fill:#333;color:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd .node rect,#mermaid-svg-TYFwNBa0oPkWI9dd .node circle,#mermaid-svg-TYFwNBa0oPkWI9dd .node ellipse,#mermaid-svg-TYFwNBa0oPkWI9dd .node polygon,#mermaid-svg-TYFwNBa0oPkWI9dd .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-TYFwNBa0oPkWI9dd .rough-node .label text,#mermaid-svg-TYFwNBa0oPkWI9dd .node .label text,#mermaid-svg-TYFwNBa0oPkWI9dd .image-shape .label,#mermaid-svg-TYFwNBa0oPkWI9dd .icon-shape .label{text-anchor:middle;}#mermaid-svg-TYFwNBa0oPkWI9dd .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-TYFwNBa0oPkWI9dd .rough-node .label,#mermaid-svg-TYFwNBa0oPkWI9dd .node .label,#mermaid-svg-TYFwNBa0oPkWI9dd .image-shape .label,#mermaid-svg-TYFwNBa0oPkWI9dd .icon-shape .label{text-align:center;}#mermaid-svg-TYFwNBa0oPkWI9dd .node.clickable{cursor:pointer;}#mermaid-svg-TYFwNBa0oPkWI9dd .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-TYFwNBa0oPkWI9dd .arrowheadPath{fill:#333333;}#mermaid-svg-TYFwNBa0oPkWI9dd .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-TYFwNBa0oPkWI9dd .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-TYFwNBa0oPkWI9dd .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-TYFwNBa0oPkWI9dd .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-TYFwNBa0oPkWI9dd .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-TYFwNBa0oPkWI9dd .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-TYFwNBa0oPkWI9dd .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-TYFwNBa0oPkWI9dd .cluster text{fill:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd .cluster span{color:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-TYFwNBa0oPkWI9dd .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-TYFwNBa0oPkWI9dd rect.text{fill:none;stroke-width:0;}#mermaid-svg-TYFwNBa0oPkWI9dd .icon-shape,#mermaid-svg-TYFwNBa0oPkWI9dd .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-TYFwNBa0oPkWI9dd .icon-shape p,#mermaid-svg-TYFwNBa0oPkWI9dd .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-TYFwNBa0oPkWI9dd .icon-shape .label rect,#mermaid-svg-TYFwNBa0oPkWI9dd .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-TYFwNBa0oPkWI9dd .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-TYFwNBa0oPkWI9dd .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-TYFwNBa0oPkWI9dd :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

不重合

重合

全 0

有值

端口收敛 + MAC 单一

源 IP 集中

否

是

业务劣化投诉

CPU 峰值与故障窗口是否重合

离开本主题查转发面 / 链路 / 终端

看 top 任务ARP / ROUT / STP / DEFD / OS

哪块板在丢

MPU / LPU / SLAVE 分别看 CAR 统计

哪类报文 Drop 有值

先排除假阴性范围 / 生效状态 / 计数器 / 管理口

攻击源形态

查接入侧环路 / 私接 / 批量上线

抓包留证 → 黑名单 / 自定义流

接入侧处置

应用策略 → 验证 CPU / Drop / 业务

三项是否全部恢复

回滚预案就位记录根因与复发条件

三个判据我通常优先看，按这个顺序：

一是 Last-dropping-time 与故障时间对不对得上。对得上说明机制在这个时间窗里发生过，是候选原因；对不上，先当历史噪声放一边。

二是 Drop 为空时先查假阴性，再下结论。查范围（all）、查生效（Status）、查计数器是否被清过、查是否走管理口。这四项过完还是空，才轮到"不是上送洪水"这个结论。

三是 三块板的 CPU 和 CAR 统计一起看。只高一个，问题范围立刻缩小；但这不等于可以跳过另外两个。

最后落一句。CPU 占用率高是症状，不是故障本身。真正要回答的是"CPU 忙在什么事上、这件事和业务劣化有没有关系、处置之后有没有恢复"。这三问都答上了，才算排完。只答上第一问就动手封 IP，是这类故障里最常见的过度处置。