Cisco 300-410: 服務品質與控制層保護 — 學習指南

By Laurynas Brazys · 18 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 和管理堆疊，使其免於意外過載和惡意事件的影響。正確的設計取決於一致的端到端標記、嚴謹的信任邊界、適當的調節 (policing/shaping)、大小適當的佇列、主動的壅塞避免、對隧道/加密的謹慎處理，以及使用與應用程式行為相關聯的計數器進行持續驗證。

分類、信任與端到端標記

流量分類與標記決定了封包在每一跳 (hop) 將如何被排入佇列以及可能被丟棄。

• 分類與比對

  • 根據存取清單 (access-lists)、DSCP/IP 優先順序 (precedence)、CoS (802.1p)、NBAR 應用程式簽章或隧道內部標頭 (搭配 qos pre-classify) 進行比對。
  • 保持確定性：盡可能根據第 3/4 層欄位進行比對；僅在必要時才使用 NBAR，因為它在某些平台上會對 CPU 造成影響。

• 信任邊界

  • 定義網路在何處接受現有的標記。典型作法：不信任終端主機；信任企業電話和連到已知 QoS 網域的上行鏈路。
  • 在邊緣，將不受信任的流量重新標記為策略定義的 DSCP 值；僅信任您管理和驗證的設備。
  • 在連接到端點的交換器連接埠上，除非您明確驗證設備類型，否則移除信任 (no trust dscp/cos)。

• 標記

  • DSCP (6 位元) 是 IP 網路中主要的端到端標記。IP 優先順序 (precedence) (3 位元) 是舊有技術，會對應到 DSCP 的高位元。
  • CoS (802.1p，3 位元) 用於標記跨 VLAN trunk 的第 2 層訊框；在 L2/L3 邊界處要確保 DSCP↔CoS 的對應一致。
  • 在 MPLS 核心中，3 位元的流量類別 (TC，舊稱 EXP) 承載 QoS；在入口 (ingress) 將 DSCP 對應到 TC，在出口 (egress) 將 TC 對應回 DSCP，以在 VPN 或 TE 核心中保持語義。

• 標記一致性

  • 保留 EF 給語音承載 (voice bearer) (低抖動)、CS3/AF31/AF32 給通話信令 (call signaling)、AF4x 給互動式視訊、AF2x/AF1x 給關鍵資料、CS0/BE 給盡力而為 (best effort)，以及 CS1 給清道夫 (scavenger)。
  • 文件化單一的企業 QoS 政策；確保 WAN 供應商遵守並按合約進行對應。
  • 避免在路徑中途重新標記，除非是在不同網域之間進行轉換；否則您將面臨優先權反轉和故障排除複雜化的風險。

範例 (入口邊緣標記)：

undefined

失敗模式與權衡：

• 信任錯誤的邊緣會導致優先權濫用；低價值流量可能會餓死 (starve) 關鍵佇列。
• 不一致的 DSCP↔CoS 對應會在 L2/L3 轉換處破壞 QoS。
• 在軟體平台上過度使用 NBAR 可能會提高 CPU 使用率；應優先使用靜態比對。

調節、佇列與壅塞避免

流量調節將流量整形 (shape) 至網路可持續的速率，並在需要硬性限制的地方應用監管 (policing)。

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

  • 監管使用權杖桶 (token buckets) 來強制執行一個速率；超出的部分會被丟棄或選擇性地重新標記。它保留了鏈路容量，但會增加封包遺失，並可能觸發 TCP 退避 (backoff) 和應用程式重試。
  • 整形會緩衝封包並以目標速率 (通常是電信商的 CIR) 釋出，從而平滑突發流量並減少下游的丟棄；它會增加與佇列深度成正比的延遲和抖動。

• 突發參數

  • 單速率雙參數監管器使用承諾資訊速率 (CIR) 搭配承諾突發 (Bc)，並可選擇性地使用超額突發 (Be)。
  • 相對於 RTT 和 MTU 而言，過小的 Bc 會導致碎片等級的丟棄和無效的吞吐量；對於整形，Bc 的大小應至少為 1-2 倍的頻寬延遲乘積；對於監管，則應為數個 MTU 的大小。

• CBWFQ 與 LLQ

  • 基於類別的加權公平佇列 (Class-Based Weighted Fair Queuing) 保證各類別的最小頻寬。在整形 (shape) 設定下，以 kbps 或百分比設定頻寬。
  • 低延遲佇列 (Low-Latency Queue, LLQ) 為一個類別增加嚴格優先權服務 (priority)，並以設定的速率進行監管，以防止餓死。只有即時的語音/視訊承載流量應放入 LLQ。
  • 佇列限制 (queue-limit) 設定每個類別可緩衝的最大封包數；設定太高會增加延遲，太低則會增加丟棄。需與應用程式的容忍度取得平衡。

• WRED vs. 尾端丟棄 (Tail Drop)

  • 尾端丟棄僅在佇列滿時才丟棄封包；這可能導致全域 TCP 同步和劇烈震盪。
  • 加權隨機早期偵測 (WRED) 在佇列滿之前就開始機率性地丟棄封包；基於 DSCP 的 WRED 讓較高優先權的類別能容忍更深的佇列，並有較低的早期丟棄機率。
  • WRED 對 TCP 流量有益；對於以 UDP 為主 (如語音) 的流量，它只會增加封包遺失而不會觸發退避。不要在 LLQ 中啟用 WRED。

範例 (父層整形搭配子層 CBWFQ/LLQ 與 WRED)：

undefined

關鍵設計要點：

• 永遠根據您能控制的最低下游瓶頸進行整形；讓您的佇列機制來決定，而不是供應商的丟棄機制。
• 根據轉碼器 (codec) 和通話量來決定 LLQ 的大小；為標頭和 VAD 的變動性包含 5-10% 的額外開銷。
• 僅在多工的 TCP 流量佔主導地位的地方啟用 WRED；保守地調整權重以防止過早丟棄。

通道與 WAN 鏈路上的 QoS

通道與加密會遮蔽內層標頭並改變 MTU，進而影響分類與分片。

• GRE/DMVPN 與 IPsec

  • 若無特殊處理，分類機制只會看到外層標頭。請在通道介面上使用 qos pre-classify，讓設備能在封裝/加密之前，根據內層的 5-tuple 與 DSCP 進行分類。
  • 將 DSCP 保留或複製到外層標頭，以便在傳輸過程中維持網路的 QoS 行為。
  • 調整 MTU 與 MSS 以避免分片和 PMTUD 失敗；對於 IPsec，在某些平台和電信商環境下，可能需要執行加密後分片 (fragmentation after-encryption)。

• 逐通道 QoS 與階層式設計

  • 在 mGRE/DMVPN 上，應用階層式 QoS (先對每個通道進行流量整形 (shape)，然後再對每個類別套用 LLQ/CBWFQ)，以確保 spoke 之間能公平分享頻寬。
  • 當供應商的線路以嚴格的 policer 強制執行 CIR 時，應將流量整形 (shape) 設定在等於或略低於 CIR 的速率，以避免被供應商執行 tail drop (丟棄封包)。

範例 (在通道上的 DMVPN hub/spoke 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 ! ! Platform-dependent: crypto ipsec fragmentation after-encryption

常見陷阱與緩解措施：

• 遺漏 qos pre-classify 會導致所有流量在加密後都落入 class-default，造成即時流量餓死。
• 不正確的 MTU/MSS 設定會導致大型封包區段被黑洞 (blackholing)，以及應用程式效能不穩定；請務必從頭到尾驗證路徑 MTU (path MTU)。
• 在軟體通道上以線速 (line rate) 套用複雜的策略可能會耗盡 CPU 資源；在可用時，應優先選用硬體卸載 (hardware offload)。

控制平面保護 (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-exceeded、MTU exceeded）。
  • control-plane cef-exception 管理與 CEF 相關的 punt。
  • 為每個子介面套用不同的策略，以避免當某一類別行為異常時造成連帶損害。

• 包含排除項目與正確附加方式的 CoPP 範例：

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

! ! 確保策略位於控制平面，而非資料介面上：

undefined

undefined

undefined

注意事項：

• 對 BGP 進行過於激進的速率限制，可能導致 keepalive 遺失、會話重置和路由抖動。若必須進行 police，請設定足夠的 CIR，並考慮使用 exceed-action transmit 以避免在流量突增時丟棄封包。

• 透過在 permit 之前使用 ACL deny 來豁免特定的受信任管理來源；將該 ACL 作為相關 class 下的比對條件來套用。

• 管理平面的補充措施

  • IPv6 RA Guard 可在 L2 埠口上阻擋惡意的路由器廣告（Router Advertisements），但當 RA 透過隧道傳輸時則無法提供保護；請在隧道端點強制執行，或在可能的情況下使用身份驗證。
  • IPv6 Source Guard 使用繫結表（binding table）僅允許有效的來源位址；它會丟棄來自存取埠口上未知／未分配 IPv6 來源的流量，從而減少送往 CPU 的例外流量。
  • 設備強化（停用未使用的服務、在 vty 上使用 ACL、限制 SNMP communities）可減少控制平面的曝險。

• 驗證與計數器

  • 使用 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/tail drops。
  • 對於佇列，可使用 show policy-map interface 和 show queueing interface 檢查佇列深度、tail/WRED drops 以及優先佇列的 policing 情況。
  • 尋找應用程式的症狀：
    • 語音抖動、封包遺失或聲音斷斷續續，暗示 LLQ 太小或信任邊界設定錯誤。
    • SSH 緩慢／斷線但 ping 正常，可能表示 CoPP 正在對管理流量進行 policing。
    • SNMP 間歇性中斷，與管理類別的丟棄或 CEF 例外 punt 超出限制有關。
    • 在負載下，隨著 WRED 丟棄增加，TCP 吞吐量下降是預期行為；若僅有 tail drop，則需注意是否有同步的鋸齒狀流量模式。

實務問題情境

Acme Engineering 公司透過網際網路寬頻，運行一個採用 IPsec+mGRE 的 DMVPN 單一中心（single-hub）網路。使用者回報在尖峰時段，連線至總部的 VoIP 語音斷斷續續、對分支路由器的 SNMP 輪詢時好時壞，以及連線至中心路由器的 SSH 緩慢或斷線。

1. 在邊界建立信任邊界並重新標記（remark）

• 理由：只有電話和受信任的上行鏈路設備被允許設定 EF/CS3；所有其他存取流量都被重新標記為 BE。這可以防止濫用優先級，從而導致即時類別的流量餓死。

2. 在 DMVPN 隧道上實作階層式 QoS

• 理由：在隧道上套用一個父層的 shaper，速率設定為實測的供應商速率（例如 20 Mbps），以避免上游的 policing。在父層策略下，為 EF 語音使用 LLQ，為視訊和關鍵數據使用頻寬類別，為 TCP 為主的類別使用 WRED，並為預設類別使用 fair-queue。這能在電信商丟棄封包前，將壅塞管理本地化。

3. 啟用 qos pre-classify 並調整 MTU/MSS

• 理由：qos pre-classify 確保策略在 GRE/IPsec 封裝前，比對內層的 IP/port/DSCP。ip mtu 1400 和 ip tcp adjust-mss 1360 可防止因封裝額外負擔而導致的碎片化／黑洞。設定加密後分片（after-encryption fragmentation）以適應供應商的行為。

4. 移除介面套用的 CoPP 並將其附加到控制平面

• 理由：CoPP 必須保護 CPU，無論流量從哪個入口介面進入。從實體介面上卸離任何 input service-policy，並將 PM-COPP 套用到 control-plane，以集中管理 punt 上來的和終止於本機的流量。

5. 建立具有安全 CIR 的獨立 CoPP 類別；豁免受信任的來源

• 理由：將 BGP 放在其專屬的類別中，並提供足夠的 CIR 以應對 keepalive 和流量突增；設定 conform/exceed 為 transmit 以避免會話重置。將 HTTP/HTTPS police 到較低的速率，以限制送往 CPU 的網頁管理流量。對於 Telnet/SSH 的例外，在 ACL 中 deny 受信任的管理 IP，這樣策略就不會對它們進行速率限制，同時仍能控制所有其他來源。

6. 根據計數器和症狀進行驗證與迭代

• 理由：使用 show policy-map control-plane 來確認管理流量的丟棄情況是否與觀察到的 SSH/SNMP 問題一致；調整 CIR 直到丟棄停止。使用 show policy-map interface Tunnel30 來驗證 LLQ 使用率，並確保在正常通話量下沒有發生優先級溢出的 policing。監控關鍵類別中的 WRED 和 tail drops；如果沒有 LLQ 丟棄但語音品質仍然很差，可稍微增加 LLQ 的百分比；如果發生丟棄，則需根據編解碼器和頻寬更精確地調整 LLQ 和父層 shaper 的大小。

透過強制執行正確的信任邊界、在瓶頸前進行 shaping、在封裝前進行分類，並使用範圍適當的 CoPP/CPPr 策略保護控制平面，Acme Engineering 公司恢復了語音品質並穩定化了管理存取，同時沒有犧牲整體吞吐量。

← 多點傳播路由與分發 · 所有領域 · VPN、隧道技術與遠端連線 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →