Cisco 300-410: 服务质量和控制平面保护 — 学习指南

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

属于 Cisco CCNP Enterprise 300-410 ENARSI — 学习指南. 使用经过验证的答案练习： Cisco 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

服务质量 (QoS) 和控制平面保护 (CoPP/CPPr) 共同确保业务关键型应用和网络本身在负载和攻击下保持稳定。QoS 区分流量，优先处理延迟敏感流，并管理稀缺链路上的拥塞。CoPP/CPPr 保护路由器 CPU 和管理堆栈免受意外过载和恶意事件的影响。正确的设计取决于一致的端到端标记、严格的信任边界、适当的流量调整 (监管/整形)、大小适宜的队列、主动的拥塞避免、对隧道/加密的谨慎处理，以及使用与应用行为相关的计数器进行持续验证。

分类、信任与端到端标记

流量分类和标记决定了报文在每一跳如何被排队以及可能被丢弃。

• 分类与匹配
  • 基于 access-lists、DSCP/IP precedence、CoS (802.1p)、NBAR 应用签名或隧道内部报头 (使用

undefined

) 进行匹配。

• 保持确定性：尽可能基于第 3/4 层字段进行匹配；仅在必要时才使用 NBAR，因为在某些平台上它会对 CPU 产生影响。

• 信任边界

  • 定义网络在何处接受现有标记。典型做法：不信任终端主机；信任企业电话和到已知 QoS 域的上行链路。
  • 在网络边缘，将不受信任的流量重标记为策略定义的 DSCP 值；仅信任由您管理和认证的设备。
  • 在朝向终端的交换机端口上，移除信任 (no trust dscp/cos)，除非您明确验证了设备类型。

• 标记

  • DSCP (6 位) 是 IP 网络中主要的端到端标记。IP precedence (3 位) 是传统技术，映射到 DSCP 的高位比特。
  • CoS (802.1p, 3 位) 用于标记跨越 VLAN 干道的第 2 层帧；在 L2/L3 边界处要保持 DSCP↔CoS 的一致映射。
  • 在 MPLS 核心网中，3 位的流量等级 (TC, 以前称为 EXP) 承载 QoS 信息；在入口处将 DSCP 映射到 TC，在出口处将 TC 映射回 DSCP，以在 VPN 或 TE 核心中保留其语义。

• 标记一致性

  • 将 EF 保留给语音承载 (低抖动)，CS3/AF31/AF32 用于呼叫信令，AF4x 用于交互式视频，AF2x/AF1x 用于关键数据，CS0/BE 用于尽力而为，CS1 用于清道夫流量。
  • 制定统一的企业 QoS 策略文档；确保广域网提供商按照合同约定遵守和映射这些标记。
  • 避免在路径中途重标记，除非是在不同域之间进行转换；否则可能会导致优先级反转和增加故障排查的复杂性。

示例 (入口边缘标记):

undefined

undefined

undefined

故障模式与权衡:

• 信任错误的边缘设备会导致优先级滥用；低价值流可能会饿死关键队列。
• 不一致的 DSCP↔CoS 映射会在 L2/L3 过渡处破坏 QoS。
• 在软件平台上过度使用 NBAR 可能会导致 CPU 升高；应优先使用静态匹配。

流量调整、排队与拥塞避免

流量调整将流量整形为网络可承受的速率，并在需要硬性限制的地方应用监管策略。

• 监管 (Policing) vs. 整形 (Shaping)

  • 监管使用令牌桶来强制执行一个速率；超出的流量被丢弃或可选地被重标记。它能保留链路容量，但会增加丢包，并可能触发 TCP 退避和应用重试。
  • 整形以目标速率 (通常是运营商的 CIR) 进行缓冲和释放流量，从而平滑突发流量并减少下游的丢包；它会增加延迟和抖动，其大小与队列深度成正比。

• 突发参数

  • 单速率双参数监管器使用承诺信息速率 (CIR)、承诺突发 (Bc) 以及可选的超额突发 (Be)。
  • 相对于 RTT 和 MTU 而言，过小的 Bc 会导致分片级别的丢包和吞吐量低下；对于整形，Bc 的大小应至少为 1-2 倍的带宽时延积；对于监管，则应为几个 MTU 的大小。

• CBWFQ 和 LLQ

  • 基于类的加权公平队列 (Class-Based Weighted Fair Queuing) 保证了各类流量的最小带宽。在整形策略下，以 kbps 或百分比配置带宽。
  • 低延迟队列 (LLQ) 为一个类别 (priority) 增加了严格优先级服务，并按配置的速率进行监管以防止饿死。只有实时语音/视频承载流量才应放入 LLQ。
  • 队列限制 (queue-limit) 设置了每个类别可缓冲的最大报文数；设置过高会增加延迟，过低则会增加丢包。需要根据应用的容忍度进行平衡。

• WRED vs. 尾丢弃

  • 尾丢弃 (Tail drop) 仅在队列满时才丢弃报文；这可能导致全局 TCP 同步和大幅度的网络振荡。
  • 加权随机早期检测 (WRED) 在队列满之前就开始进行概率性丢包；基于 DSCP 的 WRED 允许较高优先级的类别容忍更深的队列，并具有更低的早期丢包概率。
  • WRED 对 TCP 流有益；但对于主要是 UDP 的流量 (如语音)，它只会增加丢包而不会触发退避机制。不要在 LLQ 中启用 WRED。

示例 (带有子 CBWFQ/LLQ 和 WRED 的父整形策略):

undefined

undefined

undefined

关键设计要点:

• 始终根据您所控制的最低下游瓶颈速率进行整形；让您自己的排队机制做决定，而不是让提供商的丢包机制做决定。
• 根据编解码器和呼叫量来确定 LLQ 的大小；为报头和 VAD (语音活动检测) 的可变性包含 5-10% 的开销。
• 仅在多路复用的 TCP 流占主导地位的地方启用 WRED；保守地调整权重以防止过早丢包。

隧道和广域网链路上的 QoS

隧道和加密会隐藏内部报头并改变 MTU，从而影响分类和分片。

• GRE/DMVPN 和 IPsec

  • 若无特殊处理，分类功能只能看到外部报头。在隧道接口上使用 qos pre-classify，以便设备在封装/加密前，根据内部的五元组和 DSCP 进行分类。
  • 将 DSCP 保留或复制到外部报头，以在整个传输过程中维持网络 QoS 行为。
  • 调整 MTU 和 MSS 以避免分片和 PMTUD 失败；对于 IPsec，某些平台和运营商可能要求在加密后进行分片（fragmentation after-encryption）。

• 单隧道 QoS 和分层设计

  • 在 mGRE/DMVPN 上，应用分层 QoS（先按隧道进行整形，再按类别进行 LLQ/CBWFQ）以确保分支（spoke）之间的公平共享。
  • 当提供商线路通过严格的策略（policer）强制执行 CIR 时，应将整形速率设置在 CIR 或略低于 CIR，以避免提供商的尾部丢包（tail drop）。

示例（DMVPN 中心/分支隧道上的 QoS）： interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! 平台相关： crypto ipsec fragmentation after-encryption

常见陷阱与缓解措施：

• 缺少 qos pre-classify 会导致所有流量在加密后都落入 class-default，从而饿死实时流。
• 不正确的 MTU/MSS 会导致大数据段被黑洞以及应用程序性能不稳定；需端到端验证路径 MTU。
• 在软件隧道上以线速应用复杂策略会耗尽 CPU；在可用时应首选硬件卸载。

控制平面保护 (CoPP/CPPr) 与操作验证

CoPP 通过对控制平面路径中的控制和管理流量进行分类和速率限制来保护路由器 CPU。CPPr 使用 host、transit 和 CEF-exception 子接口增加了更精细的粒度。

• CoPP 基础

  • 将策略附加到控制平面，而不是数据接口。
  • 通常支持的匹配类型是 ip dscp、ip precedence 和 access-group。不要在 CoPP 引用的 ACL 条目上使用 log 关键字。
  • 将关键路由协议（BGP、OSPF、RSVP/LDP，如适用）与尽力而为的管理流量（HTTP）和批量控制流量（例如，在异常情况下导出到 CPU 的 NetFlow）分开。为关键协议提供充足的 CIR。

• CPPr 详解

  • control-plane host 管理在路由器上终止的流量（例如 SSH、SNMP、路由会话）。
  • control-plane transit 处理从硬件上送 (punt) 的异常流量（例如 TTL 超时、MTU 超出）。
  • control-plane cef-exception 管理与 CEF 相关的上送流量。
  • 为每个子接口应用不同的策略，以避免当某个类别的流量行为异常时造成连带影响。

• 带有排除项和正确附加方式的 CoPP 示例： ip access-list extended ACL-TELNET-EXEMPT deny tcp host 10.1.1.1 any eq 23 deny tcp host 172.16.1.1 any eq 23 permit ip any any ip access-list extended ACL-BGP permit tcp any any eq 179 permit tcp any eq 179 any ip access-list extended ACL-HTTP permit tcp any any eq 80 permit tcp any any eq 443 ! class-map match-any CM-BGP match access-group name ACL-BGP class-map match-any CM-HTTP match access-group name ACL-HTTP class-map match-any CM-TELNET match access-group name ACL-TELNET-EXEMPT ! policy-map PM-COPP class CM-BGP police cir 256000 conform-action transmit exceed-action transmit class CM-HTTP police cir 64000 conform-action transmit exceed-action drop class CM-TELNET police cir 100000 conform-action transmit exceed-action drop class class-default police cir 32000 conform-action transmit exceed-action drop ! ! 确保策略应用于控制平面，而非数据接口： no interface GigabitEthernet0/0 service-policy input PM-COPP control-plane service-policy input PM-COPP

注意：

• 对 BGP 进行过于激进的速率限制可能导致 keepalive 丢失、会话重置和路由抖动。如果必须进行策略限制 (police)，请设置足够的 CIR，并考虑将 exceed-action 设置为 transmit，以避免流量突增时丢包。

• 通过在 permit 语句前使用 ACL deny 语句来豁免特定的受信任管理源；将该 ACL 作为相关类别下的匹配条件应用。

• 管理平面的补充措施

  • IPv6 RA Guard 可在 L2 端口上阻止恶意的路由器通告 (Router Advertisement)，但当 RA 流量被隧道封装时无法提供保护；此时应在隧道端点强制执行策略或尽可能使用身份验证。
  • IPv6 Source Guard 使用绑定表仅允许有效的源地址；它会丢弃来自接入端口上未知/未分配 IPv6 源的流量，从而减少上送到 CPU 的异常流量。
  • 设备加固（禁用未使用的服务、在 vty 上使用 ACL、限制 SNMP community）可减少控制平面的暴露风险。

• 验证与计数器

  • 使用 show policy-map interface <int> 和 show policy-map control-plane 来验证数据包计数、丢包和策略限制 (police) 操作。当出现 CPU 负载过高的症状（例如 SSH 响应缓慢、SNMP 时断时续）时，首先运行 show policy-map control-plane。
  • 在硬件转发平台上，将结果与 show platform hardware qfp active statistics drop 或等效的 ASIC 计数器关联分析，以检查 WRED/尾部丢弃。
  • 对于队列，使用 show policy-map interface 和 show queueing interface 检查队列深度、尾部/WRED 丢弃以及优先队列的策略限制。
  • 关注应用层面的症状：
    • 语音抖动、丢包或音频断续表明 LLQ 太小或信任边界设置错误。
    • SSH 缓慢/断开但 ping 正常，可能表示 CoPP 正在对管理流量进行策略限制。
    • SNMP 时断时续与管理类流量的丢包或 CEF 异常上送流量超出限制有关。
    • 在负载下，随着 WRED 丢包的增加，TCP 吞吐量下降是正常现象；如果只有尾部丢弃，请注意是否存在同步的锯齿状流量模式。

实际问题场景

Acme Engineering 公司在互联网宽带上运行一个采用 IPsec+mGRE 的单中心 DMVPN 网络。用户报告在高峰时段，到总部的 VoIP 通话断续，对分支路由器的 SNMP 轮询时断时续，以及到中心路由器的 SSH 连接缓慢或断开。

1. 在边缘建立信任边界并重标记

• 原理：只允许电话和受信任的上行链路设备设置 EF/CS3；所有其他接入流量都被重标记为 BE。这可以防止优先级滥用，避免实时类流量饿死。

2. 在 DMVPN 隧道上实施分层 QoS

• 原理：在隧道上应用一个父整形器 (parent shaper)，速率设置为实测的运营商速率（例如 20 Mbps），以避免上游运营商进行策略限制。在父策略下，为 EF 语音使用 LLQ，为视频和关键数据使用带宽保证类，为以 TCP 为主的类别使用 WRED，为默认类别使用 fair-queue。这可以在运营商丢弃数据包之前，在本地进行拥塞管理。

3. 启用 qos pre-classify 并调整 MTU/MSS

• 原理：qos pre-classify 确保 QoS 策略在 GRE/IPsec 封装前匹配内部 IP/端口/DSCP。ip mtu 1400 和 ip tcp adjust-mss 1360 可防止因封装开销导致的分片/黑洞问题。配置加密后分片 (after-encryption fragmentation) 以适应运营商的行为。

4. 移除接口上应用的 CoPP 并将其附加到控制平面

• 原理：CoPP 必须保护 CPU，无论流量从哪个接口进入。从物理接口上分离所有 input service-policy，并将 PM-COPP 应用于 control-plane，以集中管理上送 (punted) 和发往主机 (host-terminated) 的流量。

5. 创建具有安全 CIR 的独立 CoPP 类别；豁免受信任的源

• 原理：将 BGP 放入其自己的类别，并配置足以满足 keepalive 和突发流量的 CIR；将 conform/exceed 动作配置为 transmit 以避免会话重置。以较低的速率对 HTTP/HTTPS 进行策略限制，以限制发往 CPU 的 Web 管理流量。对于 Telnet/SSH 的例外情况，在 ACL 中 deny 受信任的管理 IP，这样策略就不会对它们进行速率限制，同时仍然能控制所有其他来源的流量。

6. 基于计数器和症状进行验证和迭代

• 原理：使用 show policy-map control-plane 确认管理流量的丢包与观察到的 SSH/SNMP 问题相符；调整 CIR 直到丢包停止。使用 show policy-map interface Tunnel30 验证 LLQ 利用率，并确保在正常通话量下没有发生优先队列溢出导致的策略限制。监控关键类别的 WRED 和尾部丢弃；如果语音质量仍然很差但没有 LLQ 丢包，则略微增加 LLQ 百分比；如果发生丢包，则根据编解码器和带宽更精确地调整 LLQ 和父整形器的大小。

通过强制执行正确的信任边界、在瓶颈点前进行流量整形、在封装前进行分类，并使用范围适当的 CoPP/CPPr 策略保护控制平面，Acme Engineering 公司恢复了语音质量并稳定了管理访问，同时没有牺牲整体吞吐量。

← 组播路由和分发 · 所有领域 · VPN、隧道技术和远程连接 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →