📚 课程目录第4章 Catalyst控制面保护（CoPP）

4. Catalyst控制面保护（CoPP）

控制面保护（Control Plane Policing，CoPP）是 Catalyst 交换机上用于保护 CPU 的关键机制。数据面转发芯片通常拥有独立的硬件转发表和缓存，即使流量过载，转发仍可维持；但控制面协议报文（路由协议、ARP、STP、SSH、SNMP、ICMP 等）必须上送 CPU 处理，一旦 CPU 被异常流量占满，协议邻居会抖动、管理会话会中断，甚至整机失去可管理性。CoPP 的本质，是在“上送 CPU 的流量”进入 CPU 之前，用 QoS 策略对分类后的流量分别限速，从而保证关键协议始终有处理资源。

一、CoPP 的定位与处理链

理解 CoPP 需要先明确它在设备内的位置。控制面流量从线卡进入后，一部分由硬件直接转发，另一部分被标记为“需上送 CPU”，这些报文会经过 CoPP 策略的分类与限速，再进入 CPU 的协议队列。CoPP 使用模块化 QoS CLI（MQC）实现，由 class-map 定义“哪些流量”、policy-map 定义“对这些流量做什么”、service-policy 将其应用到 control-plane 接口。其核心逻辑可概括为：分类 → 限速（policing）→ 超限动作（丢弃或降级）。

二、策略设计与分类

CoPP 策略设计的第一步是分类。分类的依据通常是 ACL，匹配源/目的地址、协议号、端口号、DSCP 或报文长度。Catalyst 上常见的控制面流量可分为几类：路由协议（OSPF、EIGRP、BGP）、二层协议（STP BPDU、CDP、LLDP）、地址解析（ARP、DHCP）、管理访问（SSH、Telnet、SNMP、TACACS+）、网络诊断（ICMP、TTL 超时）以及异常流量（分片、TTL=0/1、非法源地址）。分类时要注意 ACL 的匹配顺序和隐含 deny，避免把关键协议漏掉。

限速参数的核心是 CIR（承诺信息速率）和 burst（突发量）。CIR 决定长期平均上送速率，burst 决定允许的瞬时突发。对于 OSPF Hello 这类周期性小报文，CIR 可以设得较低（如 64 kbps），但 burst 要足够容纳邻居建立时的突发；对于 BGP 更新，CIR 需要更高（如 512 kbps～1 Mbps），否则路由收敛会变慢。管理流量建议单独限速，例如 SSH 设为 128 kbps、SNMP 设为 64 kbps，防止扫描或轮询风暴占满 CPU。

! 示例：CoPP 分类与策略（参数为教学示例，非实测值）
class-map match-any CM-ROUTING
 match access-group name ACL-OSPF
 match access-group name ACL-BGP
class-map match-any CM-MGMT
 match access-group name ACL-SSH
 match access-group name ACL-SNMP
class-map match-any CM-ICMP
 match access-group name ACL-ICMP
class-map match-any CM-DEFAULT
 match any

policy-map PM-COPP
 class CM-ROUTING
  police 512000 64000 conform-action transmit exceed-action drop
 class CM-MGMT
  police 128000 16000 conform-action transmit exceed-action drop
 class CM-ICMP
  police 64000 8000 conform-action transmit exceed-action drop
 class CM-DEFAULT
  police 32000 4000 conform-action transmit exceed-action drop

interface control-plane
 service-policy input PM-COPP

三、验证方法

CoPP 配置完成后，必须验证策略是否生效、分类是否命中、限速是否合理。常用命令包括 show policy-map control-plane 查看各 class 的匹配与丢弃计数，show policy-map interface control-plane 查看具体接口上的应用情况，show class-map 确认分类定义。重点观察 exceed-action 的丢弃计数：如果关键协议类出现大量丢弃，说明 CIR 或 burst 设置过小；如果 default 类丢弃很多，说明有异常流量或分类遗漏。

验证时还应结合 CPU 利用率。使用 show processes cpu sorted 查看 CPU 占用最高的进程，使用 show processes cpu history 观察历史趋势。若 CoPP 生效后 CPU 仍高，需检查是否有未分类流量绕过策略，或是否存在硬件上送路径未经过 CoPP。此外，可通过 show platform qos 或 show platform hardware qos 查看硬件层面的队列和限速状态，确认策略是否真正下发到转发芯片。

四、常见攻击缓解与调优

CoPP 最常见的防护对象是 ICMP 洪泛、ARP 欺骗/洪泛、STP BPDU 风暴、DHCP 耗尽以及管理面扫描。针对 ICMP 洪泛，可将 ICMP 单独分类并限速到 64 kbps 以下，同时丢弃分片 ICMP；针对 ARP 洪泛，可限制 ARP 上送速率并启用 Dynamic ARP Inspection；针对 STP BPDU 风暴，可启用 BPDU Guard 和 Root Guard，并在 CoPP 中限制 BPDU 上送速率；针对管理面扫描，可对 SSH/SNMP 单独限速，并配合 ACL 限制源地址。

调优的核心是“观察—调整—再观察”。建议先以较宽松的参数上线，观察各 class 的匹配速率和丢弃计数，再逐步收紧。对于关键协议，宁可保留一定余量，也不要为了降低 CPU 而过度限速，否则协议邻居抖动带来的影响可能比 CPU 升高更严重。调优时还要注意 CoPP 与 QoS 其他策略的交互：CoPP 只作用于上送 CPU 的流量，不影响数据面转发；但如果数据面 QoS 已经对控制协议报文做了标记或限速，需确认两者不冲突。

调优建议：每次只调整一个 class 的 CIR 或 burst，调整后至少观察 5～10 分钟，确认协议邻居稳定、CPU 利用率下降且无异常丢弃，再进入下一轮调整。保留调整前后的 show policy-map control-plane 输出作为对比依据。

注意：CoPP 策略中的 default class 必须存在，否则未分类流量可能不受控。同时，ACL 的隐含 deny 可能导致某些协议未被匹配而落入 default 类，设计时需逐条确认匹配范围。

总体而言，CoPP 是 Catalyst 控制面保护的第一道防线。合理的分类、恰当的限速、持续的验证与调优，能够在攻击或异常流量发生时，保证路由协议、二层协议和管理访问始终可用，从而维持网络的稳定性和可管理性。