Cisco 300-415: QoS とマルチキャストサービス — 学習ガイド

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

こちらの一部です： Cisco SD-WAN 300-415 ENSDWI — 学習ガイド. 検証済みの解答で練習： Cisco試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Cisco SD-WAN におけるサービス品質 (QoS) とマルチキャストサービスは、多様なトランスポートにわたってアプリケーションエクスペリエンスを維持しつつ、リアルタイムトラフィックおよびグループトラフィックのスケーラブルでポリシー駆動の配信を可能にするように設計されています。QoS は、アプリケーションごとおよびオーバーレイトンネルごとに、優先順位付け、シェーピング、帯域幅の公平な使用を保証します。マルチキャストは、サイトをまたがる受信者に対して、ポリシーで制御された効率的なストリームの複製を可能にします。これらが連携することで、(音声/ビデオは損失やジッターから保護されなければならない、ビジネスクリティカルなアプリは SLA を満たさなければならないといった) 意図を、SD-WAN コントロールプレーン (vSmart) によって調整され、WAN Edge デバイスで強制される一貫したデータプレーンの動作に変換します。

QoS アーキテクチャ、キュー、スケジューリング、シェーピング、ポリシング、帯域幅割り当て

Cisco SD-WAN の QoS は階層的かつトランスポートを意識した構成になっています。

• 分類: フィールド (L3/L4)、DSCP、アプリケーションシグネチャ (IOS XE SD-WAN 上の NBAR2)、または VPN とプレフィックスのコンテキストによってフローを識別します。
• マーキング: サービス側からの DSCP を設定または維持し、WAN の制約に応じて必要に応じて書き換え、QoS マップを介して出力キューにマッピングします。
• キューイングとスケジューリング: 出力インターフェースは、リアルタイムトラフィック用の厳密優先の低遅延キュー (LLQ) と、他のクラス用の重み付けスケジューラ (WFQ/WRR/CBWFQ) を備えた複数のハードウェア/ソフトウェアキューを実装します。
• シェーピング: プロバイダーのポリサーを回避し、バーストを吸収するために、設定されたレート (インターフェースごと、サブインターフェースごと、またはトンネルごと) に出力トラフィックを平滑化します。
• ポリシング: 入力または出力で非準拠トラフィックをレート制限し、オプションで再マーキングまたはドロップします。アプリケーションのブラウンアウトを避けるために控えめに使用されます。
• 帯域幅割り当て: クラスごとに最小帯域幅 (保証) を予約し、適切な場合には最大値を設定します。他のキューの枯渇を防ぐために、LLQ には厳密で明示的な上限を設けることを保証します。

設計ガイダンスとトレードオフ:

• ISP の実効ポリサーを下回る安全なレートにシェーピングします。変動のあるインターネット回線の場合、公称帯域幅の 90～95% が実用的な開始点です。負荷時のドロップと遅延を観測して調整します。
• キューの深さ (バッファリング) は、遅延と損失のバランスを取る必要があります。帯域幅遅延積の数分の一程度にサイズ設定します。小さすぎるとテールドロップを誘発し、大きすぎると下位クラスの遅延を増大させます。
• LLQ は、短時間で一定レートの音声/ビデオ制御フローにのみ使用します。高ビットレートのビデオストリームを LLQ に配置せず、明確な帯域幅上限を持つ高優先度の重み付けキューに割り当てます。
• 出力ではポリシングよりもシェーピングを優先します。明示的なレート契約や信頼できない入力に対してはポリサーを適用します。
• 複数のオーバーレイを伝送する共有物理リンクでは、トンネルごとの QoS (PTQ) を有効にして、各 BFD ベースのセキュアトンネルが独自のスケジューラ/シェーパーを受け取るようにします。これにより、単一のビジーなオーバーレイがリンクを独占するのを防ぎます。
• トランスポート固有のポリシー (color/TLOC-aware) により、アンダーレイごとに異なる QoS マップ、シェーパー、クラス保証が可能になります (例: インターネット上ではより厳格なシェーピングと削減された DSCP セット、MPLS 上ではより豊富なクラス)。

トンネルごとの QoS とトランスポート固有の仕様:

• PTQ は、IPsec/DTLS/TLS トンネルごとに出力スケジューリングを仮想化するため、保証と上限がインターフェースごとだけでなく、パスごとに適用されます。これは、Edge が同じインターフェース上で複数のトンネルを形成する場合 (例: デュアル vSmart/vBond リージョンや複数のリモートピア) に不可欠です。
• プロバイダーの DSCP ホワイトリストを尊重し、予期しない再マーキング (例: ブロードバンド上で AF クラスをデフォルトに集約する) を防ぐために、color (biz-internet, mpls, lte) ごとに異なる QoS マップを割り当てます。

DSCP、QoS マップ、輻輳管理による分類とマーキング

信頼できる分類は、サービス VPN エッジから始まります。

• 信頼境界: LAN アクセスドメインが QoS に対応していない場合、WAN Edge で L7 アプリケーション ID または L3/L4 タプルを使用して分類とマーキングを行います。LAN が QoS 対応の場合は、DSCP を監査および維持しつつ、WAN QoS マップに正規化します。
• DSCP 戦略: インタラクティブ音声には EF、ビデオには AF41/42、クリティカルデータには AF31/AF21、シグナリングには CS3/AF クラス、ベストエフォートには CS0/DF、スカベンジャーには CS1 (または LE) を使用します。プロバイダーが受け入れる値と整合させます。
• QoS マップ: DSCP をキューにマッピングし、オプションで出力時に書き換えます。アンダーレイの制限を尊重する 1 対 1 または多対 1 のマッピングを維持します。

運用上役立つチェックの短い例:

show sdwan app-route stats sla-class VOICE
show policy qos-queue   (vEdge)
show policy-map interface <wan-intf>  (IOS XE SD-WAN)

輻輳管理とキューのサイジング:

• EF 用に小さく上限付きの LLQ (例: シェーピングレートの 10%) から始め、LLQ 内でポリシングを強制して、誤ってマーキングされたフローによるオーバーランを防ぎます。
• 残りの帯域幅は、ビジネスの優先順位に合わせて WRR/CBWFQ の重みを使用して割り当てます (例: クリティカルデータ 30%、ビデオ 20%、ベストエフォート 35%、スカベンジャー 5%)。
• グローバル同期を避けるため、プラットフォームでサポートされている場合は、バルククラスに対して早期廃棄 (WRED) を有効にすることを検討します。LLQ や小さな制御キューでは早期廃棄を有効にしないでください。

注意すべき障害モード:

• キャリアによる再マーキングが DSCP を集約し、リアルタイムトラフィックがベストエフォートに分類されてしまいます。結果として、ピーク時にジッターとパケット損失が発生します。パケットキャプチャとプロバイダーの QoS プロファイルで確認します。
• シェーパーのサイズが不適切だと、継続的なテールドロップにつながります。LLQ が上限なしの場合や、ビデオが LLQ に殺到した場合に LLQ の枯渇が発生します。
• 共有インターフェースで PTQ が設定されていないと、「ノイジーネイバー」のオーバーレイが帯域幅を消費し、クリティカルなトンネルの品質を低下させます。

アプリケーションの優先順位付け、ビジネス意図、SLAの強制

Cisco SD-WANは、vSmartコントローラー上の中央集権型ポリシーを介してアプリケーションの意図を表現します。vSmartコントローラーは、オーバーレイのコントロールプレーンを管理し、ポリシーをWAN Edgeに配布します。Application-Aware Routing (AAR)は、BFDを使用してトランスポートごと、トンネルごとに測定された損失、遅延、ジッターに基づいてトラフィックを誘導します。SaaSの最適化のために、Cloud OnRampはゲートウェイサイトへのBFDメトリクスに加えて、アプリケーションへのHTTPベースの損失と遅延を組み込むことができます。

ベストプラクティス:

• ビジネス上の重要度に応じてアプリケーションリストとSLAクラスを定義します:
  • VOICE: EF、目標は片道150ms未満、ジッター30ms未満、損失1%未満。これらのしきい値を満たすパスのみを経由して誘導します。
  • VIDEO: AF4x、音声よりもわずかに緩いジッター/損失。広帯域で低損失のパスを優先します。
  • CRITICAL DATA: AF3x/AF2x、アプリケーションの要件に応じて損失と遅延を制限します。
• クラスごとにSLAを満たすパスを優先するために、application-aware routing (AAR)に中央集権型ポリシーを使用します。劣化が発生した場合は、セカンダリパスにフォールバックします。
• AARをトランスポートごとのQoSと組み合わせます。選択されたパスには、そのクラス用にリソースが予約されている必要があります。そうでない場合、トラフィックはパスのSLAを満たしていても、出口でキューイングされたりドロップされたりする可能性があります。
• ゲートウェイサイト経由のSaaSについては、次の両方を検証します:
  • SaaSエンドポイントへのHTTPの損失/遅延。
  • ゲートウェイサイトへのBFDの損失/遅延。
• エンドツーエンドでDSCPの維持を強制します。出口では、アンダーレイが必要とする場合にのみ書き換え、対向側がマーキングを信頼する場合は復元します。

運用上のチェック:

show sdwan app-route statistics
show sdwan bfd sessions
show application traffic-flow   (vManage analytics)

よくある落とし穴:

• 厳しすぎるSLAしきい値はパスのフラッピングを引き起こします。ヒステリシスとホールドタイマーを導入してください。
• 選択されたパスにクラス帯域幅が不足していると、自己誘発性の輻輳が発生します。AARの選択をトランスポートごとのQoSキャパシティと整合させてください。
• 暗号化されたペイロードやNBARシグネチャの欠落による誤分類（例：音声がベストエフォートとして検出される）。フォールバックとしてDSCPの信頼または明示的なL4マッチを使用してください。

マルチキャストの基礎とオーバーレイマルチキャストの設計

SD-WAN上のマルチキャストは、LANのマルチキャストコントロールプレーンをアンダーレイの制約から切り離します。

• 基礎:
  • 受信者はIGMPv2/v3を使用して、最初のホップのLANルーター（サービスVPN内のWAN Edge）に対して参加を通知します。
  • サービスVPN内ではPIM Sparse Modeが推奨されます。ランデブーポイント（RP）が初期の参加を調整します。
• オーバーレイコントロールプレーン:
  • WAN Edgeルーターは、OMPを介してvSmartコントローラーにマルチキャストサービスルートを生成します。
  • vSmartコントローラーは、マルチキャストレプリケータ/RPアドバタイズメントの役割を担い、オーバーレイを介してRP情報を伝播させ、元のPIM joinメッセージで指定されたソースまたはPIM-RPに向けて、要求されたグループへの参加要求を転送します。
  • vSmartは、1つ以上のWAN Edgeをデータプレーンレプリケータとして選択します。ソース側のEdgeはレプリケータに単一のコピーを送信し、レプリケータがそれを受信者側のEdgeに複製することで、帯域幅が限られたリンクでの帯域使用量を最小限に抑えます。
• データプレーン:
  • レプリケーションは、オーバーレイトンネルを介してユニキャストの暗号化パケットとして行われます。サービスVPNの境界は維持されます（マルチキャストはVPN/VRFごと）。
  • VPN間のマルチキャストは自動的には行われません。必要な場合は、明示的なサービスチェイニングまたはアプリケーション層ゲートウェイを使用する必要があります。

設計上の考慮事項とトレードオフ:

• RPは、ソースまたは中央のデータセンターに論理的に近い場所に配置します。SD-WANオーバーレイでは、vSmartにRPをアドバタイズさせて、受信者へ一貫した参加を保証します。
• マルチキャストは必要なVPNでのみ有効にします。CPUを保護するために、受信者の制御トラフィック（IGMP）はレート制限します。
• 低帯域幅のリンクでは、アクセス回線でのN×ストリームのレプリケーションを回避するため、十分なキャパシティを持つハブ/レプリケータでレプリケーションを集中化します。
• 高ビットレートストリームのフラグメンテーションを避けるためにMTUを検証します。コントロールプレーンのキューとは独立してビデオクラスをシェーピングすることを検討します。

障害モード:

• LAN上でのIGMPクエリアの不在は、グループのエージングとストリームの損失につながります。WAN EdgeまたはLANスイッチがクエリアとして機能することを確認してください。
• RPの不一致または集中型ポリシーでのフィルタリングは、参加を妨げます。オーバーレイ全体でRPへの到達可能性を確認してください。
• 過剰な小パケットのマルチキャスト制御トラフィックは、DDoSと誤認される可能性があります。制御キューをレート制限し、監視してください。
• サービスVPNの境界の指定ミスは、配信不能の原因となります。マルチキャストは、明示的に設計されない限りVPNを越えません。

トラブルシューティングの要点:

show ip igmp groups
show ip pim neighbor / rp mapping
show sdwan omp services
show sdwan multicast status
show interface | include drops

キューのドロップをアプリケーションのKPIと関連付けます。マルチキャストについては、EdgeでIGMP joinが確認できること、OMPサービスルートが存在すること、選択されたレプリケータが正常なトンネル経由で到達可能であることを確認します。

実践的な問題シナリオ

NorthRiver Healthは、デュアルトランスポート（MPLSとインターネット）を持つ120のクリニックを運営しています。苦情として、途切れがちな音声、ピクセル化された遠隔医療ビデオ、および待合室での断続的なIPTVマルチキャストが挙げられています。

アプローチ:

1. 信頼境界を確立し、トラフィックを分類する

• 理由: 正確な分類は、優先順位付けの前提条件です。準拠したLANドメインからのDSCPを維持します。存在しない場合は、アプリケーション（NBAR2）とL4タプルで分類し、音声をEF、ビデオをAF41、重要なEMRをAF31にマッピングします。

2. トランスポート固有のQoSマップとシェーパーを作成する

• 理由: MPLSはAF/EFを尊重しますが、インターネットはそうでないことが多いです。カラーごとのQoSマップを設定します。MPLSには完全なクラスセットを、インターネットにはEFとAF4を維持しつつ集約されたクラスを設定します。プロバイダーのポリサーを回避するため、MPLSをCIRの95%に、インターネットを測定された持続可能なスループットにシェーピングします。

3. 共有WANインターフェースでPer-Tunnel QoSを有効にする

• 理由: 複数のオーバーレイが同じ物理リンクを共有します。PTQは、トンネルごとのスケジューラと最小値を割り当てることによって、ビジーなサイト-クラウド間のトンネルが、サイト-データセンター間の音声/ビデオトンネルを枯渇させるのを防ぎます。

4. 音声用にLLQを予約および上限設定し、ビデオと重要なデータに重み付けを行う

• 理由: 音声には有界の遅延/ジッターが必要です。枯渇を防ぐためにLLQの上限を10%に設定します。AF4ビデオに25〜30%を割り当て、厳密な最大値を設定します。AF3のEMRトラフィックに25%を割り当て、残りをベストエフォートとスカベンジャーに割り当てます。

5. SLAクラスを使用してvSmartに集中型AARポリシーを実装する

• 理由: vSmartは、BFDの損失/遅延/ジッターを使用してSLAターゲットを満たすパスに音声/ビデオ/EMRを配置する集中型ポリシーを配布します。フラップを防ぐためにヒステリシスを追加します。ゲートウェイ経由のSaaS EHRモジュールの場合、SaaSへのHTTP損失/遅延と、ゲートウェイサイトへのBFDを含めます。

6. vSmartのレプリケータ選択機能を使用してオーバーレイマルチキャストを展開する

• 理由: 効率的なIPTV配信には、制御されたレプリケーションが必要です。IPTV VPNでマルチキャストを有効にし、PIM-SMとRPを設定し、vSmartにRPをアドバタイズさせ、データセンターのEdgeをレプリケータとして選択させることで、低速なクリニックの回線をNウェイのレプリケーションから保護します。

7. テレメトリを使用して検証と改善を繰り返す

• 理由: 負荷時の動作を確認します。以下を使用します:
  • show sdwan app-route statistics でSLAパス選択を検証します。
  • show policy qos-queue / show policy-map interface でキューの使用率とドロップを評価します。
  • show ip igmp groups と show sdwan omp services でマルチキャストの参加とサービスルートを確認します。 重要なデータの許容可能な遅延を維持しつつ、音声/ビデオでのテールドロップを排除するために、シェーパーレートとキューの重みを調整します。

8. ガードレールと異常処理

• 理由: 再発を防止し、リグレッションを検出します。信頼できないLANセグメントにイングレスポリサーを適用して誤ってマークされたトラフィックを抑制し、IGMPをレート制限してコントロールプレーンCPUを保護し、AARのSLA違反やキュードロップカウンターにアラートを設定してプロアクティブな修復をトリガーします。

この一連の手順により、NorthRiver Healthはビジネス要件を、一貫性のあるトランスポートを意識したQoSと信頼性の高いマルチキャスト配信に変換できます。音声は厳密で有界の処理を受け、ビデオとEMRは優先順位付けされ、重み付けされた帯域幅を受け取ります。パスはライブのSLA測定によって選択され、マルチキャストはブランチのリンクに過負荷をかけることなく効率的に複製されます。

← セキュリティ、セグメンテーション、サービスチェイニング · すべてのドメイン · クラウド、SaaS、マルチクラウド統合 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →