1,948
回編集
差分
ナビゲーションに移動
検索に移動
1行目:
1行目: + + + + − + + + − + 17行目:
23行目: − + + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Cisco Catalyst 9000 スイッチング プラットフォーム QoS and キューイング ホワイトペーパー (ソースを閲覧)
2023年11月17日 (金) 11:20時点における版
、 2023年11月17日 (金) 11:20→ポリシング
このドキュメントは、hkatou Lab が [https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9000/white-paper-c11-742388.html#AppendixBUADPASICscale Cisco Catalyst 9000 Switching Platforms: QoS and Queuing White Paper] を非公式に翻訳したものです。
原文・画像の著作権は Cisco Systems にあります。
===イントロダクション===
===イントロダクション===
このドキュメントは、Cisco Catalyst 9000 ファミリ スイッチのクオリティ・オブ・サービス (QoS) とキューイング アーキテクチャについて記載します。バッファ、スケジューリング、ポリシング、リマーキングの機能についての説明です。それは複数のポート間でどのようにバッファを共有するか、オート QoS が簡潔に構築できるか、そしてアプリケーションの要求に応じて、カスタム QoS ポリシーをどのように設定するか、詳細を提供します。
このドキュメントは、Cisco Catalyst 9000 ファミリ スイッチのクオリティ・オブ・サービス (QoS) とキューイング アーキテクチャについて記載します。バッファ、スケジューリング、ポリシング、リマーキングの機能についての説明です。それは複数のポート間でどのようにバッファを共有するか、オート QoS が簡潔に構築できるか、そしてアプリケーションの要求に応じて、カスタム QoS ポリシーをどのように設定するか、詳細を提供します。
==== QoS の事例 ====
==== QoS の事例 ====
エンタープライズ ネットワークは、様々なプラットフォームを横断してネットワークに広がり、エンド・ツー・エンドで QoS ソリューションを提供する必要があります。多様なプラットフォームにソリューションを提供するには、多くの場合それぞれの技術において、異なる QoS コンフィギュレーション アプローチを採る必要があります。エンタープライズ ネットワークは、より複雑で、ミッション クリティカル アプリケーションや、日々増大するウェブのマルチメディア アプリケーション トラフィックを運んでおり、QoS はこれらのトラフィックを優先づけすることで、それぞれのアプリケーションが求めるサービス レベルを確実なものにします。
エンタープライズ ネットワークは、様々なプラットフォームを横断してネットワークに広がり、エンド・ツー・エンドで QoS ソリューションを提供する必要があります。多様なプラットフォームにソリューションを提供するには、多くの場合それぞれの技術において、異なる QoS コンフィギュレーション アプローチを採る必要があります。
エンタープライズ ネットワークは、より複雑で、ミッション クリティカル アプリケーションや、日々増大するウェブのマルチメディア アプリケーション トラフィックを運んでおり、QoS はこれらのトラフィックを優先づけすることで、それぞれのアプリケーションが求めるサービス レベルを確実なものにします。
ネットワークは、複雑さが増大するビジネス アプリケーションを扱えなくてはなりません。QoS によりネットワークは差別化という難しいタスクを扱うことができ、ビジネス アプリケーションについて、最も効率的に機器間のリンクを使用します。
ネットワークは、複雑さが増大するビジネス アプリケーションを扱えなくてはなりません。QoS によりネットワークは差別化という難しいタスクを扱うことができ、ビジネス アプリケーションについて、最も効率的に機器間のリンクを使用します。
QoS は以下のテクニックを追加することにより、ネットワークに保障と予測されたネットワーク トラフィックの選択を助けます。
QoS は以下のテクニックを追加することにより、ネットワークで保障と予測したネットワーク トラフィックを選別します。
* スケジューリングによる、帯域幅の保障
* スケジューリングによる、帯域幅の保障
上記のテクニックを用いてあなたのネットワークに QoS を実装することで、以下の優位点を得られるでしょう。
上記のテクニックを用いてあなたのネットワークに QoS を実装することで、以下の優位点を得られるでしょう。
* 帯域幅、レート制限のように、リソースを超えたもののコントロール 例えば、重要なデータベース アクセスを優先するために優先度を与え、FTP 転送はリンク上で消費する帯域幅を制限したりできます。
* 帯域幅、レート制限のように、リソースを超えたもののコントロール
** 例えば、重要なデータベース アクセスを優先するために優先度を与え、FTP 転送はリンク上で消費する帯域幅を制限したりできます
* ミッション クリティカル アプリケーションとの共存
* ミッション クリティカル アプリケーションとの共存
** 帯域幅と最小遅延が
** 時間に敏感なマルチメディアと音声アプリケーションに、要求される帯域幅と最小遅延が提供できます
** FTP , メール、HTTP , 取引のような他のアプリケーションがリンクを利用するとき、音声のようなミッション クリティカル トラフィックに干渉させず、公平なレベルのサービスを使用できます
さらにネットワークに QoS 機能を実装することで、将来にすべてが統合されたネットワークとなる基盤を手に入れて、輻輳を管理する効率的なテクニックを使用できます。
=== 輻輳とは何ですか ? ===
輻輳は宛先ポートがすべてのパケットを外部へ送信できないときに発生し、いくつかのパケットは想定よりもドロップや遅延が発生します。画像 1. は 2 つのタイプの輻輳で、QoS とキューイングが必要とされるイラストです。
==== 輻輳のタイプ ====
[[ファイル:C90-QoS-01.png|なし|画像 1. 輻輳のタイプ|代替文=|フレーム]]2 つのタイプの輻輳は画像 1. に示しています :
* '''複数ポートから単一ポートへ :''' 複数の送信元ポートから単一の宛先ポートへ同時に送信するとき、複数の送信元から合計されたトラフィックが届いてしまい、宛先ポートが輻輳します
* '''スピード ミスマッチ :''' 高速なポートで受信して低速なポート (例えば 10Gbps から 1Gbps) で送信するとき、パケットは出力ポートから流れるのに時間がかかるため、結果としてパケットのドロップや遅延となります
=== なぜ輻輳に配慮しなくてはなりませんか ? ===
輻輳が発生したときに、輻輳管理機能が適切に設定されていない場合、パケットはドロップされます。パケットがドロップされると、上位プロトコルによっては再送が発生、もしくはネットワークの再収束が必要になる場合があります。これはネットワークの パフォーマンスに影響を与える可能性があります。
すでにネットワークが輻輳していると、これが既存のパフォーマンスの問題に追加されてしまい、ネットワーク全体のパフォーマンスがさらに低下する可能性があります。
それは ボーダー・ゲートウェイ・プロトコル (BGP) , オープン・ショーテスト・パス・ファースト (OSPF) , リンク・アグリゲーション・コントロール・プロトコル (LACP) のようなプロトコルの場合、一時的もしくは完全に接続が切れてしまう結果になりえます。
このようなコントロール プレーン プロトコルのパケットが、輻輳によりドロップすることで、それらのキープ アライブ メッセージが、受信できなくなることで発生します。
ネットワークの収束と輻輳管理は、さらに重要になります。レイテンシやジッターは、音声やビデオのように敏感なトラフィックでは、もし遅延が発生すると厳しい影響があります。
バッファの追加は常に簡潔なソリューションにはなりえません。ソリューションを探す前に重要なステップを踏むことで、アプリケーションのトラフィック パターンの何が影響しているか理解してください。
個別のアプリケーションで QoS を確保するために、適切なツールのセットが必要とされます。Cisco Catalyst 9000 ファミリは、エンタープライズ ネットワークで見られる、一般的なアプリケーションを扱うために必要とされるすべてのツールを提供します。
輻輳を管理するう方法はいくつかあります :
* オーバーサブスクリプション比の削減
* 優先するためのトラフィックに、キューイング スケジューラを使用
* 輻輳管理にウェイテッド・ランダム・アーリー・テール・ドロップ (WRED) やウェイテッド・テール・ドロップのように、いくつかのトラフィックを早期にドロップさせるためのアルゴリズムを採用
* ドロップを削減するためにバッファを使用し、送信する前のパケット保存量を増加
* 入力側でトラフィックをポリシングして、トラフィックを出力する前に削減
次のセクションでは、異なるスイッチのモデルで QoS 機能の統合の仕方を議論します。
=== Cisco Catalyst 9000 ファミリにおける ASIC の QoS の統合 ===
Cisco Catalyst 9000 スイッチング プラットフォームは、エンタープライズ LAN アクセス、ディストリビューション、コアスイッチにおける次世代の Cisco ファミリです。Cisco ユニファイド・アクセス・データ・プレーン (UADP) アプリケーション・スペシフィック・インテグレーテッド・サーキット (ASIC) はこのプラットフォームはより高速なパフォーマンス、多くの新機能と動作を提供します。
[[ファイル:C90-QoS-02.png|なし|画像 2. Cisco Catalyst 9000 ファミリ スイッチ|代替文=|フレーム]]
Cisco Catalyst 9000 スイッチング プラットフォームは、一般的で強力なハードウェアとソフトウェア基盤で成り立っています。その性質と一貫性は、ネットワークエンジニアと管理者にシンプルさと運用のしやすさをもたらし、トータルで運用コストの削減とよりよい体験を創出します。
==== 一般的なハードウェア ====
Cisco Catalyst 9000 ファミリのハードウェアは、その内部と外部で一般的なデザインを持っています。内部にはハードウェアとして ASIC を使用し、Cisco UADP がパケットの扱いに柔軟性を提供します。他の一般的なコンポーネントはスイッチの CPU です。
Cisco Catalyst スイッチの歴史において、最初に x86 ベースの CPU を搭載 (Cisco Catalyst 9200 を除く) し、ネットワーク スイッチで通常使用可能なルーティングなどのアプリケーションを超えて、コンテナされたアプリケーションを追加することが可能です。
==== 一般的なソフトウェア ====
すべての Cisco Catalyst 9000 ファミリ スイッチは、異なる CPU を持つ Cisco Catalyst 9200 を除いて、まったく同じバイナリ イメージの Cisco IOS XE で動作します。
Cisco IOS XE は拡張され、オープンで、プログラマブルな OS です。30 年の歴史の中で 1000 を超える機能を持ち、Cisco IOS XE はネットワーキング市場において、間違いなく最も機能が豊富な OS です。
Cisco Catalyst 9000 プラットフォームを横断してシングル バイナリ イメージを持ち、モジュラー・クオリティ・オブ・サービス・CLI (MQC) のようなエンド ツー エンドの機能のサポートを有効化し、ネットワークのどのポイントにおいても、同等の動作であることを担保します。
この共通性はキャンパス ネットワーク全体でテストするイメージが単一であるため、ソフトウェア リリースの評価試験を行う際に役立ちます。
Cisco Catalyst 9000 のハードウェアとソフトウェア基盤は、基本機能の上に新モデルを構築する時、同じエンド ツー エンドの QoS 機能を有効化します。それは顧客へ一貫性と簡潔性をもたらします。
これらの Cisco Catalyst 9000 ファミリの 5 つのメンバーは、9300 シリーズ スタッカブル スイッチ、9400 シリーズ モジュラー シャーシ、9500 シリーズと 9500 ハイパフォーマンス シリーズ 固定コア スイッチ、そして 9600 シリーズです。このセクションでは QoS アーキテクチャの観点から、これらのプラットフォームについて議論します。
===== Cisco Catalyst 9200 シリーズ アーキテクチャ =====
Cisco Catalyst 9200 シリーズスイッチは、シンプルなアーキテクチャを持っています。ネットワーク モジュール ポートを含むすべてのフロント パネル ポートは、24- か 48 ポートモデルで 1 つの UADP Mini ASIC に、マルチ ギガビット モデルで 2 つの UADP Mini ASICs に接続されます。
UADP Mini として単一 ASIC コアがあることで、その QoS バッファはすべてのポート間で共有されます。すべてのポートは個別のキューイング機能をサポートします。
Cisco Catalyst 9200 シリーズは、StackWise-160 / 80 を使用するスタッカブル スイッチです。それぞれのスイッチは 2 つのスタック インターフェースで、スタック内で別の 2 つのスイッチへ接続できます。そのスタックインターフェースは ASIC の一部であり、スタックリングへパケットを送出します。
専用のバッファがスタック インターフェースに割り当てられ、ユーザは設定で変更することはできません。
[[ファイル:C90-QoS-03.png|なし|フレーム|画像 3. Cisco Catalyst 9200 シリーズ デュアル ASIC スイッチのアーキテクチャ]]
===== Cisco Catalyst 9300 シリーズ アーキテクチャ =====
Cisco Catalyst 9300 シリーズスイッチは、シンプルなアーキテクチャを持っています。ネットワーク モジュール ポートを含むすべてのフロントパネルポートは、UADP 2.0 ASIC に接続されます。モデルによっては、スイッチは 1 つかそれ以上の ASIC にすべてのポートを割り当てます。
1 つより多くの ASIC を持つスイッチについては、殆どの場合同じ数のポートに分割して ASIC に収容されますが、これはすべてのポートが ASICs から同じリソースを利用できるようにするためです。
QoS バッファは ASIC コアごとに分割され、ASIC コアに接続されたポートの中でのみ共有されます。すべてのポートは個別のキューイング機能をサポートします。
Cisco Catalyst 9300 シリーズは、スタッカブルスイッチです。それぞれのスイッチは 2 つのスタック インターフェースで、スタック内で別の 2 つのスイッチへ接続できます。そのスタックインターフェースは ASIC の一部であり、スタックリングへパケットを送出します。
専用のバッファがスタック インターフェースに割り当てられ、ユーザは設定で変更することはできません。
[[ファイル:C90-QoS-04.png|なし|フレーム|画像 4. Cisco Catalyst 9300 シリーズ デュアル ASIC スイッチのアーキテクチャ]]
Cisco Catalyst 9300-B スイッチは UADP 2.0 XL ベースで、Catalyst 9300 の他のモデルよりも、より大きなテーブルと UADP 2.0 と比較して QoS のディープバッファを提供します。
===== Cisco Catalyst 9400 シリーズ アーキテクチャ =====
Cisco Catalyst 9400 シリーズ スイッチは、中央処理アーキテクチャをベースにしており、スーパーバイザですべてのパケットが処理されることを意味します。ラインカードはスタブ ASICs と PHYs のみを持っており、透過的であると考えることができます。
結果として、スーパーバイザにすべての QoS のリソースが存在しており、それはポートごとのバッファとその他の QoS リソースを含んでいます。中央処理デザインのシンプルさは、既存のラインカードをそのまま使用しつつ、将来スーパーバイザをアップグレードすることで、機能を簡単にアップグレードできる点にあります。
[[ファイル:C90-QoS-05.png|なし|フレーム|画像 5. Cisco Catalyst 9400 シリーズ アーキテクチャ]]
スーパーバイザ アーキテクチャは UADP 2.0 XL がベースになっており、Cisco Catalyst 9300 で使用されている UADP 2.0 と比較して QoS はより大きなテーブルを持っています。
===== Cisco Catalyst 9500 シリーズ アーキテクチャ =====
Cisco Catalyst 9500 シーズのそれぞれのモデルは、異なるポート速度と密度を提供しますが、QoS アーキテクチャの観点からは、9500 シリーズは 9300 シリーズと似ています。モデルによって、UADP 2.0 XL と UADP 3.0 のどちらも 9500 シリーズ スイッチには存在しています。
表 1. は、それぞれに使用されるモデルと ASICs のまとめです。
{| class="wikitable"
|+表 1. Cisco Catalyst 9500 シリーズの UADP バージョン
!モデル
!UADP 2.0 XL
!UADP 3.0
|-
|C9500-32C
|
|2 ASICs
|-
|C9500-32QC
|
|1 ASIC
|-
|C9500-48Y4C
|
|1 ASIC
|-
|C9500-24Y4C
|
|1 ASIC
|-
|C9500-16X
|1 ASIC
|
|-
|C9500-40X
|2 ASICs
|
|-
|C9500-12Q
|2 ASICs
|
|-
|C9500-24Q
|3 ASICs
|
|}
画像 6. と 7. に Cisco Catalyst 9500 シリーズ スイッチのフロント パネルと ASIC の接続を示します。
[[ファイル:C90-QoS-06.png|なし|フレーム|画像 6. Cisco Catalyst 9500 シリーズ UADP 2.0 XL ベース モデルのアーキテクチャ]]
[[ファイル:C90-QoS-07.png|なし|フレーム|画像 7. Cisco Catalyst 9500 シリーズ ハイパフォーマンス UADP 3.0 ベース モデルのアーキテクチャ]]
ハイパフォーマンス系のすべてのスイッチは UADP 3.0 ASIC を使用し、2 つの ASIC コアの間でユニファイド バッファをサポートします。これはバースト トラフィックの吸収量を増加でき、スイッチのすべてのポート間で、1 つの共有バッファを持つことになります。
[[ファイル:C90-QoS-08.png|なし|フレーム|画像 8. UADP 2.0 (と 2.0 XL) と UADP 3.0 のバッファの違い]]
===== Cisco Catalyst 9600 シリーズ アーキテクチャ =====
Cisco Catalyst 9600 シリーズ スイッチは、中央処理アーキテクチャをベースにしており、スーパーバイザですべてのパケットが処理されることを意味します。ラインカードはスタブ ASICs と PHYs のみを持っており、透過的であると考えることができます。
結果として、スーパーバイザにすべての QoS のリソースが存在しており、それはポートごとのバッファとその他の QoS リソースを含んでいます。中央処理デザインのシンプルさは、既存のラインカードをそのまま使用しつつ、将来スーパーバイザをアップグレードすることで、機能を簡単にアップグレードできる点にあります。
[[ファイル:C90-QoS-09.png|なし|フレーム|画像 9. Cisco Catalyst 9600 シリーズ アーキテクチャ]]
スーパーバイザ アーキテクチャは UADP 3.0 がベースになっており、Cisco Catalyst 9500 で使用されている UADP 2.0 XL と比較して QoS はより大きなテーブルを持っており、ASIC コア間はユニファイド バッファになります。
[[ファイル:C90-QoS-10.png|なし|フレーム|画像 10. Cisco Catalyst 9600 シリーズ ASIC 相互接続]]
=== UADP パケット ウォーク ===
Cisco Catalyst 9000 ファミリで使用されているすべての UADP ASICs は、 イーサネット フレーム or IPv4 / IPv6 ヘッダのフィールドを使用し、QoS の機能をラインレートで提供できます。
パケット ヘッダのマーキングは、ホップ間でサービスレベルをやり取りします。すべての IPv4 / IPv6 パケットはレイヤ 2 とレイヤ 3 のマーカーを持っており、QoS とキューイングに使用するためにデザインされています。
しかしそれらはクラスでトラフィックを分類するためにのみ使用されるわけではありません。UADP ASICs は送信元と宛先 IP アドレス、TCP / UDP ポート、他のパケット ヘッダのデータも、分類に使用することができます。
パケット ヘッダの分類は、以下の値を使用することができます :
* レイヤ 2 クラス・オブ・サービス (CoS) : 3 ビット (0 - 7 の値)
* マルチ・プロトコル・ラベル・スイッチング (MPLS) エクスペリメンタル・ビット (EXP) フィールド : 3 ビット (0 - 7 の値)
* レイヤ 3 ディファレンシエイテッド・サービシズ・コード・ポイント (DSCP) , IPv4 の IP プレシデンス タイプ・オブ・サービス (ToS)
* IPv6 のトラフィック クラス (0 - 63 の値)
もしスイッチからパケットが生成された場合、パケット ヘッダにマーキングされていなくても、CPU は優先度を設定してパケットを分類できます。例えば、LACP プロトコル・データ・ユニット (PDUs) はタグなし (=CoS なし) ですが、CPU は内部優先度を用いて、それらをプライオリティ キューでスケジュールできます。
パケット フォーマットについては追加の詳細情報は付録 C. を見てください。
UADP 2.0 (と 2.0 XL) と 3.0 は、QoS とキューイングについて同じ ASIC パケット ウォークを共有しています。パケットがシステムに入った時、それは内部ディスクリプタに紐付けられます。ディスクリプタは複数バイトから構成され、いくつかのビットは QoS 専用になっています。
これらの QoS ビットはパケットヘッダで、入力マーカーごとに初期セットされます。ディスクリプタはスイッチから出るまでにパケットと紐付けられます。最終転送先が決定されるとすぐに、ディスクリプタはパケットを書き換えるために使用されます。
パケットが UADP ASIC に入った時、復号化のために MACsec ブロックへ行きます。次に、入力 FIFO がパケットのコピーを作成するために使用され、パケット・バッファー・コンプレックス (PBC) で変更されずに保存され、イングレス・フォワーディング・コントローラ (IFC)、は複数の並列ルックアップとディスクリプタでルックアップの結果を保存します。
* もしパケットがスタック インターフェースを越える時、イングレス・キュー・スケジューリング (IQS) ブロックを経由して送信され、スタック・キューイング・アンド・スケジューリング (SQS) ブロックによって、別のスイッチはスタック インターフェースから受信します。
* もしパケットが同じ ASIC 内で送信されるときは、スタック インターフェースはスキップします。
パケットがローカル PBC から、もしくはスタックのどちらか一方から届いた時、それは出力処理の準備が整っていることを意味します。キューイングのための、イーグレス・キュー・システム (EQS) で送信されます。
EQS は 2 つのサブブロックでできており、SQS はスタックからパケットを受信すると、アクティブ・キュー・マネジメント (AQM) は、ポート キューを管理します。
その結果、入力側でセットされたパケット ディスクリプタからパケットと情報が、イーグレス・フォワーディング・コントローラ (EFC) によって使用され、出力で設定された機能 (画像 12. 緑色の部分) を適用されます。出力ルックアップが完了すると、最終結果がディスクリプタに保存されます。
パケットがディスクリプタで最後の値をベースに書き換えられます。次に、パケットは暗号化され、ASIC の外に送信されます。
[[ファイル:C90-QoS-11.png|なし|フレーム|画像 11. UADP ASIC コンポーネント]]
パケット ウォークは QoS 処理の観点から、4 つのパートに分割することができます。
# イングレス・フォワーディング・コントローラによる、入力分類 (イングレス クラシフィケーション)、ポリシング、マーキングが動作
# イングレス・キュー・スケジューリング (IQS) とスタック・キューイング・アンド・スケジューリング (SQS) ブロックによる、スタック インターフェースへのキューイングが動作
# アクティブ・キュー・マネージメント (AQM) による、出力キューイングとスケジューリングが動作
# イーグレス・フォワーディング・コントローラ (EFC) による、出力分類、ポリシング、マーキングが動作
画像 12. は 4 つのパートの描写です。それぞれのステップは後のセクションで詳細を記載します。[[ファイル:C90-QoS-12.png|なし|フレーム|画像 12. ASIC ブロックごとの QoS ツール]]ASIC はパケットを処理するための、ハードウェア リソースを提供します。スケールの数は、付録 B で提供します。
=== モジュラー・クオリティ・オブ・サービス コマンド-ライン (MQC) モデル ===
MQC モデルは、異なる機種を横断して、標準的に QoS を設定する方法です。Cisco Catalyst 9000 ファミリ スイッチは、ポリサー、シェイパー、トラフィック リマーキング機能など、異なる QoS ツールを設定するために、構造化された方法として、同じ MQC モデルを使用します。
すべての MQC ポリシーは、インターフェースに適用されるポリシー マップ、クラス マップがベースになっています。画像 13. は MQC ポリシー構造を示しています。[[ファイル:C90-QoS-13.png|なし|フレーム|画像 13. MQC ポリシーの仕組み]]画像 14. は、QoS ポリシーのサンプルを示しています。[[ファイル:C90-QoS-14.png|なし|フレーム|画像 14. MQC サンプル ポリシー]]QoS ツールは前に画像 12. に示したように、入力と出力で分類することが可能です。その画像ではパート 1 と 2 が入力ツールを描写しており、3 と 4 が出力ツールを描写しています。2 つの QoS ツールセットは、後述のセクションで議論します。これらのツールの組み合わせが、望まれるクオリティ・オブ・サービス (QoS) を目的として、使用することができます。
=== 入力ツールセット ===
==== 信頼 ====
Cisco Catalyst 9000 ファミリ スイッチでは、すべての入力パケットの DSCP は、デフォルトで信頼されます。ポリシーでマーキングが変更されない限り、パケット着信時のマーキングは変更されません。
これは古い世代のプラットフォームでは望ましくなく、Cisco Catalyst 3750 シリーズのように、MLS QoS を有効にすると、すべての入力トラフィックが非信頼と (ToS / EXP などが) 0 にマークダウンされてしまいます。
Cisco Catalyst 9000 プラットフォームでは、ポリシーで変更しない限り、すべてのマーキングは保持されます。
==== 条件付き信頼 ====
Cisco Catalyst 9000 ファミリ スイッチは条件付き信頼をサポートし、特定のタイプ・オブ・サービス (ToS) を信頼します。ポート レベルで設定できる信頼デバイス コマンドは、この機能を容易にします。
信頼デバイスコマンドがポートに適用されると、ポートは信頼されたデバイスのみ DSCP , IP プレシデンス , CoS を信頼するようになります。他のデバイスから送信されたパケットは信頼されず、DSCP , IP プレシデンス , CoS は 0 にリマーキングされます。<syntaxhighlight lang="c">
interface <interface name>
description IP Phone
switchport access vlan 99
switchport mode access
trust device cisco-phone
</syntaxhighlight>条件付き信頼は、1 つのタイプのみポートで有効化できます。しかし、複数のデバイスが 1 つのポートに接続する可能性があるため、その場合は同時に複数のデバイスについて、条件付き信頼を有効にすることはできません。
例えば、IP 電話がスイッチに接続され PC が電話に接続される場合があります。IP 電話は信頼デバイスとして設定されますが、PC はそうではありません。これはモバイル環境で信頼をプロビジョニングする際に問題となる可能性があります。次の例を考えてみましょう。:
* ポート A は接続された機器を信頼に設定され、初期は IP 電話です。
* ポート B は接続された機器を非信頼に設定され、初期は PC です。
移動するため、反対のポートに機器を接続しなおします。この移動によって IP 電話 (現在は非信頼のポート B に接続されている) から発信されたボイス・オーバー・IP (VoIP) の品質が損なわれてしまい、PC (現在は信頼のポート A に接続されている) によって、意図的・計画的な QoS の悪用にネットワークが利用されてしまいます。
1 つの解決策は、デバイスが接続されたポートスイッチの間で、インテリジェントな情報をやり取りすることです。もしスイッチがデバイスを発見して信頼できるように見えたら、動的に信頼を拡大します。もしそうでなければ、信頼しません。現在の Cisco の実装では、Cisco ディスカバリ・プロトコル (CDP) を使用して、インテリジェントな情報のやり取りを行っています。
代表的に IP 電話は、VoIP とシグナリング (それぞれデフォルト値は 5 と 3) の両方について、802.1Q/p CoS 値をマーキングする能力を持っています。さらに、それらは VoIP を DSCP EF に、コール シグナリングを DSCP CS3 にマークする能力も持っています。
==== クラシフィケーション ====
入力クラシフィケーションは、ポリシーが適用されたインターフェースで、スイッチにパケットが届いた時に実施されます。
Cisco Catalyst 9000 ファミリ スイッチは、以下のクラシフィケーションを使用します。:
* アクセス・コントロール・リスト (ACLs) (送信元 / 宛先 IP , TCP / UDP ポート , その他)
* DSCP
* IP プレシデンス (ToS)
* IPv6 トラフィック クラス
* dot1q CoS
* MPLS EXP (17.3.1 からサポート)
* ネットワーク・ベースド・アプリケーション・認識 (NBAR) プロトコル
* VLANs
クラシフィケーションは、複数のクラシフィケーション パラメータ間で、"AND" や "OR" などの論理演算子を使用できます。
以下の例は "AND" と "OR" の論理演算子間の典型的な違いです。<syntaxhighlight lang="c">
class-map match-any VOICE
match ?
access-group Access group
--- Or ---
dscp Match DSCP in IPv4 and IPv6 packets
</syntaxhighlight>ノート : "match-any" は、access-group "OR" DSCP 値にマッチします
<syntaxhighlight lang="c">
class-map match-all VOICE
match ?
access-group Access group
--- And ---
dscp Match DSCP in IPv4 and IPv6 packets
--- And ---
vlan VLANs to match
</syntaxhighlight>ノート : "match-all" は、access-group "AND" DSCP 値 "AND" Vlan のすべてにマッチします
クラシフィケーション結果は、以下で使用されます :
* ポリシング
* 条件付き or 非条件付きマーキング
UADP ASIC の実装における、ハードウェア入力クラシフィケーションの詳細情報は、付録 A. を参照してください。
==== ポリシング ====
入力ポリサーは、入力レートを下げるために使用される、もう 1 つの QoS ツールです。このセクションでは、超過したトラフィックを早急にドロップさせることで、ポリサーがどのようにトラフィック削減を実現しているか説明します。[[ファイル:C90-QoS-15.png|なし|フレーム|画像 15. ポリサーの動作]]MQC モデル経由でポリサーを設定するために、使用するパラメータについて、以下で説明します。
==== ポリサーレートとバースト ====
ポリシングの設定には、レートとバーストの 2 つの重要なパラメータがあります。そのレート (コミッテド・インフォーメーション・レート (CIR)) は特定の時間間隔 (通常は Kbps , Mbps , Gbps を参照します) の間、最大限転送することができるデータ量を定義したものです。与えられた時間内に受信できる全体データ量は、バーストと呼ばれます。
これらのパラメータがどのように相互作用するかのシンプルな例として、レート 10Mbps とバースト 11Mbps を使用するポリシーを挙げます。このポリシーは 10Mbps (レート) のデータを、特定の時間間隔で最大 11Mbps で受信できることを指定します。
このバーストはどのくらいデータを受信 (バケットをいっぱいにできることを想像してください) できるか、レートはどのくらいデータを転送 (バケットを空にできる速度を想像してください) できるかを定義します。
強調するべき重要なポイントは、バーストは指定されたレートを下回ってはならない、ということです。仮に不可能な設定としてバーストを 8Mbps にセットしたとすると、レートを 10Mbps にセットしても、転送速度として 10Mbps を達成することはできません。もしバケット (バースト受信サイズ) は 8Mb だけ保持することができるため、同様に最大レートは 8Mbps のみになってしまいます。
==== ピーク インフォメーション レートと最大バースト ====
ピーク・インフォメーション・レート (PIR) と最大バーストは、次に理解するべきパラメータのセットです。もしレートとバーストが最初のバケットと関連付けられたら、PIR と最大バーストは次のバケットと関連付けられます。
最大バーストは、2 つめのバケットの深さを定義づけし、PIR は 2 つめのバケットから転送することができる、データ量を意味します。PIR の 1 つの考え方は、リソースが使用可能であれば、追加して使用することが可能な、追加の小さいバケットといえます。
==== ハードウェア 間隔 ====
上記のレートに関する定義で、"与えられた時間間隔" の用語の使用は、特定のハードウェアに定義・組み込まれた間隔に関連しています。ポリサー レートの精度は 0.0875% です。ハードウェア インターバルは、トークンがトークン バケットを満たすレートに関連しています。[[ファイル:C90-QoS-16.png|なし|フレーム|画像 16. ポリサー トークンが満ちる間隔]]画像 16. に見られるように、データは与えられた時間間隔でスイッチに到着し始めて、データの総数が定義されたレート (その間隔で) 内に収まる限り転送されます。データカウントが与えられた時間間隔でレートの限界を超えると、次のハードウェア インターバルが始まるまで、データは転送されません。
ハードウェア間隔は通常、CIR が使用される時 Tc" として、PIR の時は "Tp" と呼ばれます。
=== ポリサー設定 ===
Cisco Catalyst 9000 ファミリ スイッチは、1 レートと 2 レートポリサーをサポートします。画像 17. で、ポリサーの動作順を説明します。[[ファイル:C90-QoS-17.png|なし|フレーム|画像 17. UADP ASIC のポリサーのタイプ]]以下はポリシングに関する MQC ポリシーのサンプルです。<syntaxhighlight lang="c">
class-map match-all dscp46
match dscp ef => Classification
policy-map InputPort
class dsp46
police rate percent 10 => Policer 10 % of interface line rate
interface <interface name>
service-policy input InputPort
</syntaxhighlight>
==== マーキング ====
マーキングは、パケットのさまざまなマーキング用フィールド (CoS , DSCP/IP プレシデンス , EXP) の操作を可能にするもう一つの QoS ツールです。Cisco Catalyst 9000 ファミリ スイッチは、ヘッダを書き換えるために複数の方法を提供します。 (パケットフォーマットの詳細は付録 C を参照してください)
* 条件付きマーキング : もしポリシング レートが超過したら、パケットのマーキングを変更する
* 無条件マーキング : ポリシーに該当するすべてのパケットをマークする
==== マーキング ポリシー設定 ====
<syntaxhighlight lang="c">
class-map match-all dscp20
match dscp 20 => Classification
class-map match-all dscp21
match dscp 21 => Classification
policy-map InputPort
class dscp20
set dscp af11 => Unconditional marking
class dscp21
police cir percent 10 pir percent 50
conform-action transmit
exceed-action set-dscp-transmit dscp table MARKDOWN
=> Conditional marking, as the DSCP value is changed only
if policing rate is exceeded
violate-action drop
class dscp22
police cir percent 10 pir percent 50
set dscp af11 => Unconditional marking can be combined with policing
interface <interface name>
service-policy input InputPort
</syntaxhighlight>
変換 (ミューテーション) マップ : これらのマップは、レイヤ 2 CoS ヘッダ情報を元にした、レイヤ 3 DSCP ヘッダの書き換えを許可します。テーブル 2. はヘッダの変換をサポートするリストです。
{| class="wikitable"
|+
テーブル 2. サポートされる変換マップの組み合わせ
! colspan="2" rowspan="2" |
! colspan="5" |To :
|-
!プレシデンス
!DSCP / トラフィック クラス
!CoS
!QoS グループ
!EXP
|-
| rowspan="5" |From :
|プレシデンス
|X
|X
|X
|X
|
|-
|DSCP / トラフィック クラス
|X
|X
|X
|X
|
|-
|CoS
|X
|X
|X
|X
|
|-
|QoS グループ
|X
|X
|X
|
|X
|-
|EXP
|X
|X
|X
|X
|
|}
以下に変換マップの設定の仕方を示します。<syntaxhighlight lang="c">
table-map CoS2DSCP
map from 1 to 46
policy-map Mutation
class class-default
set dscp cos table CoS2DSCP
</syntaxhighlight>ここで "set <to> <from>" はマーカー間の変換を設定します。
ポリシーではテーブルマップを使用する時、以下の機能をサポートします。
* クラス デフォルトのみが、テーブル マップを適用できます
* 変換 : テーブル マップはとある DSCP 値のセット (訳注 : ここは複数を意味するセット) を別の DSCP 値にセットし、出力ポートに適用できます
* リライト : 着信パケットは設定されたテーブル マップに応じて書き換えられます
* マッピング : セットされたポリシーの代わりに、テーブル マップ ベースのポリシーが使用可能です
まとめると、信頼、クラシフィケーション、ポリシング、マーキングは、画像 12. "ASIC ブロックごとの QoS ツール" のステップ 1 から定義しているように、入力転送パスで適用されるツールです。 これらのツールは入力 QoS ツール セットを定義します。このセクションでは、ツールの使用方法として、MQC ポリシーの例を提供しました。
次のセクションでは、画像 12. のステップ 2 を元に、スタック インターフェースのキューイングについて説明します。
===== 異なる ASIC に届けるための、スタック インターフェースへのキューイングとバッファ =====
入力転送の結果が来た (信頼 or クラシファイド (分類) され、ポリサーやリマークされた) 後、パケットは宛先 ASIC へ向かってスケジュールされます。このステージでパケット ディスクリプタからの情報は、パケットをキューに入れるために使用されます。
この情報は入力転送パスで変更されるか、オリジナルとして保存されるでしょう。パケットは書き換えられず、オリジナルの QoS 優先度を持ったまま宛先へ着信します。
PBC からスタック リングへパケットが送信されると、画像 11. "UADP ASIC コア コンポーネント" に示すように、イングレス・キュー・スケジューラ (IQS) ブロックが使用されます。IQS は第 1 レベルのキュー構造を提供し、高優先度のトラフィックが最初に送信されます。
これはスタック リング全体でパケットの優先度が確実に保持されるようにするために行われます。Cisco Catalyst 9300 シリーズのようにスタック インターフェースを外部にしたり、Cisco Catalyst 9400 , 9500 , 9500 ハイパフォーマンス スイッチのように、内部にすることができます。しかし QoS とキューイングの視点からは、同じ機能を共有できます。
スタック インターフェースは転送するメディアのみ提供し、パケット優先度を変更するための能力は持っていません。パケットがスタックから届いた時、オリジナルの ASIC コアから入ってきた時と全く同じ設定になっています。
スタック インターフェースはスケジューリングについて、8 つの個別キューを提供します。画像 18. に、スタック インターフェースの "TO" と "FROM" を使用するキュー構造を示します。[[ファイル:C90-QoS-18.png|なし|フレーム|画像 18. ASIC コア間の接続]]パケットは出力ポートのスケジューラへ送信され、画像 12. のステップ 3 に示すように、出力ツールを使用してパケットを更に処理します。
=== 出力ツールセット ===
==== 出力キューイングとスケジューリング ====
出力ポート スケジューラは、複数ポートのキューとバッファとキューしきい値を提供するもう一つの QoS ツールです。スケジューラはインターフェースからパケットが離れる時、優先順位をつけるために使用されます。すべてのパケットは、異なる優先度によってキューへ振り分けられます。
キュー システムは、一般のキューと、アイテムが少ない人のための "特急" キューを持った、地元の食料品店とよく似ています。画像 19. に通常キューと、特急・優先キューのイラストを示します。[[ファイル:C90-QoS-19.png|なし|フレーム|画像 19. 食料品店における行列のタイプの違い]]キュー構造を提供するために、UADP ASIC はイーグレス・キュー・システム (EQS) ブロックを使用します。主要な EQS のコンポーネントは、以下になります。
* ポート キュー
このタイプのキューは、パケットを同じ方法でグループ化して処理できます。複数のキューがあると、ASIC は次のパケットを取得して、送信するキューを選択できます。食料品店の例を使用すると、すべてのキューは 購入された商品を処理する 1 人のレジ係を表します。
特急キューは、処理時間を短縮することで、人々が商品の購入を高速に行うことで、すばやく食料品店を出る方法を表しています。[[ファイル:C90-QoS-20.png|なし|フレーム|画像 20. フロントパネル ポート キュー]]
* ポートは物理キューに分割されています
* すべてのキューはパケットをためておくのに使用できる、バッファ / メモリを持ちます
* ポートごとのキューの数は、1 から 8 個を可変して持つことができます
食料品店の例では、人々は彼らが購入した商品の数に応じて列に並んでいます。同様に、パケットも ASIC でキューに割り当てられる必要があります。UADP ASIC では、パケット ディスクリプタからの情報が、キューにパケットを割り当てるために使用されます。
パケットがキューに割り当てられると、スケジューリング アルゴリズムはキューで順番を管理するのに役立ちます。優先 / 特急キューを優先できますが、非優先キューの場合は、輻輳を避けるために、ウェイテッド・ラウンド・ロビン (WRR) が使用されます。
===== なぜ絶対優先キューなのですか ? =====
絶対優先キューは、ポートで他の通信をすべて抑制することができ、パケットがある限りキューからパケットを送信します。パケットが絶対優先キューにある時、パケットのスケジューリングは WRR キューを停止し、絶対優先キューのパケットが送信されます。絶対優先キューが空である時のみ、スケジューリング プロセスは、WRR キューからパケットの送信を再開します。
画像 21. は絶対優先キューが WRR キューよりも優先される方法を 3 つのステップで表しています。各シーケンスの矢印は、どのキューが初に処理されるをかを示してます。[[ファイル:C90-QoS-21.png|なし|フレーム|画像 21. WRR キューと比較した、絶対優先キューの処理]]UADP ASIC は、ポートごとに 1 つのレベル 1 絶対優先キュー (PQ1) と 1 つのレベル 2 絶対優先キュー (PQ2) をサポートします。PQ1 と PQ2 は WRR スケジューリング アルゴリズムの範囲外で動作します。PQ1 の目的は、最小の遅延で音声トラフィックを処理することです。PQ2 は、もう少し遅延を許容することができる、映像トラフィックを処理するために使用されます。
===== なぜ WRR なのですか ? =====
通常のラウンド ロビン アルゴリズムは、送信キューの間で交互に動作し、次のキューに移動する前に、それぞれのキューから同じ数のパケットを送信します。WRR の重み付け比率により、スケジューリング アルゴリズムは、各キューに割り当てられた、重み付けを検査できます。
この重み付けは、それぞれのキューがどのくらいの帯域幅でアクセスできるか定義します。WRR スケジューリング アルゴリズムは、他のキューよりも高い重み付け (各間隔) の場合に、キューからより多くのデータを取り出せるように、指定されたキューを偏らせて処理します。
画像 22. は、それぞれのキューから送信されるパケットの数が異なることを示しています。なぜならば 1 つのキューが高帯域幅 / 高い重み付けを持っていると、より多くのパケットがそこから送信され、キューはより頻繁に使用されます。[[ファイル:C90-QoS-22.png|なし|フレーム|画像 22. WRR キューの帯域幅管理]]デフォルト キュー構造は、すべての Cisco Catalyst 9000 ファミリ スイッチ間のすべてのポートで共通化され、速度に関係なく、2 つのキュー モデルをベースとします。デフォルトでは、優先とコントロール トラフィックは Q0 に分離されますが、Q0 は優先キューとして動作しません。[[ファイル:C90-QoS-23.png|なし|フレーム|画像 23. デフォルト トラフィック マッピング]]デフォルト キュー設定は、カスタム MQC ポリシーによって変更することが可能です。顧客はポリシー マップで明示的に指定されていない場合でも、クラス デフォルトが常に定義する、最小の 1 個から 8 個のキューまで柔軟に使用できます。
キュー構造は体系を使用して、多くの通常キューと絶対優先キューの数、キューごとに使用可能なしきい値の数を示します。キュー構造タイプのキーワードは、以下になります。 :
* Q : 通常キュー、もしくは UADP ASIC による WRR キューの数を表す
* P : 絶対優先 (低遅延) キューの数を表す
* T : 通常キューごとのしきい値の数を表す 絶対優先キューはしきい値を実装しません
以下はキュー体系の例と、キューに割り当てたトラフィックのマッピングです。
# 8Q3T : 8 つの通常キュー、キューごとに 3 つのしきい値
# 1P7Q3T : 1 つの優先キュー、7 つの通常キュー、キューごとに 3 つのしきい値
# 2P6Q3T : 2 つの優先キュー (レベル 1 と 2)、6 つの通常キュー、キューごとに 3 つのしきい値
以下は MQC ポリシーのサンプルで、キューの優先度を管理するために、クラス マップとポリシー マップを使用します。WRR 帯域幅はキューごとに調整され、バッファ比率は手動で調整されます。しきい値は後のセクションで説明します。
トラフィックをアサインするには、 DSCP , CoS , QoS グループを使用します。 ACL クラシフィケーションは、キューイング ポリシーでは使用できません。<syntaxhighlight lang="c">
class-map VOICE
match dscp 46
class-map RT-VIDEO
match dscp 32
* クラスマップのその他の部分は省略
クラシフィケーションは、キューにトラフィックをマッピングします
</syntaxhighlight><syntaxhighlight lang="c">
policy-map 2P6Q3T
class VOICE
priority level 1
queue-buffers ratio 5
class RT-VIDEO
priority level 2
queue-buffers ratio 10
class MGT-CONTROL
bandwidth remaining percent 10
queue-buffers ratio 10
class MULTIMEDIA-CONFERENCE
bandwidth remaining percent 10
queue-buffers ratio 10
class MULTIMEDIA-STREAMING
bandwidth remaining percent 10
queue-buffers ratio 10
class TRANSACTIONAL-DATA
bandwidth remaining percent 10
queue-buffers ratio 10
class BULK-SCAVENGER
bandwidth remaining percent 5
queue-buffers ratio 10
class class-default
bandwidth remaining percent 25
queue-buffers ratio 35
</syntaxhighlight><syntaxhighlight lang="c">
interface <name>
service-policy output 2P6Q3T
=> キューイング MQC ポリシーは、output 方向のポリシーのみサポートされます
</syntaxhighlight>
17.3(1) から、MPLS EXP をベースにした、出力キューイングがサポートされます。
まとめると、UADP 2.0 ASIC とその後のバージョンでは、すべてのポートで固有の設定を持つことで、非常に柔軟なキューイングモデルをサポートし、異なる数の優先キュー、もしくは帯域幅設定を使用できます。
===== キュー バッファ =====
キュー バッファは主に以下で使用されます :
* プライオリティ キューが送信を終了するまで、通常キュー・WRR キューで待機させる
* 高レベルのマイクロ バーストの吸収
* 異なる速度のリンク間 (高速 -> 低速) で、トラフィックを保持する
食料品店の例に戻ると、キュー バッファはお店の責任者が人々を別の列に移動し始める前に、どのくらい多くの人々が 1 列に並ぶことができるかを示します。
マイクロ バーストを説明するため、画像 24. に入力トラフィックのレートを示します。この伸びた棒は、処理されたパケットの数が瞬間的に多くなったことを示します。UADP ASIC は、これらのパケットを廃棄することなく、物理メモリに保存できます。
[[ファイル:C90-QoS-24.png|なし|フレーム|画像 24. トラフィック スパイクとマイクロ バースト]]
[[ファイル:C90-QoS-25.png|なし|フレーム|画像 25. UADP ブロックごとのバッファ区分]]全体の物理バッファが、UADP ASIC の一部をベースとして複数のセグメントに分割されて、メモリ スペースを使用します :
* スタック インターフェースに向かうようにスケジュールされたパケットについて、To-スタック バッファが使用されます これらは IQS UADP ASIC ブロックによって使用されます。
* スタック インターフェースから受信するトラフィックについて、From-スタック バッファが使用されます これらは SQS UADP ASIC ブロックによって使用されます
* 出力ポート キュー バッファは最大のバッファで、ポート キュー構造によって使用されます。このバッファは異なるキュー、もしくはポート間で共有が可能です。それはアクティブ・キュー・マネジメント (AQM) UADP ASIC ブロックによって使用されます。
これらの 2 つのアプローチは、セグメントにバッファを割り当てるためのものです : そのアプローチとは、静的と動的です。UADP ASIC では、To-スタックと From-スタックのバッファ ブロック、つまり IQS と SQS について、固定アプローチを使用します。
しかし出力ポートに固定割当バッファを割り当てることは、バースト トラフィックで発生しうるパケットドロップには、効率的に対処できません。
UADP ASIC では、デフォルトでは最小の専用バッファをすべてのポートのキューに持たせ、高バーストを吸収するために、共有プールから動的に追加バッファを加えることができます。共有メモリプールの物理スペースは限られており、トラフィック バーストが来た時にポートキューに割り当てられます。
食料品店の例では、顧客はすべての有効なキューに分散するよりも、1 つのキューに長い列を作ると腹立たしく思うでしょう。すでにいっぱいになっているキューに更に多くの人が来た場合、店舗責任者は物理スペースを広げるために、より列の長さが短いキューから、整列用に一時な線を引くでしょう。
スイッチでも同じように、キューが輻輳した時には動的により多くの物理スペースを提供するのです。
ダイナミック・スレッショルド(しきい値)・スケール (DTS) アルゴリズムは、マイクロ バーストに対して UADP ASIC のバッファ パフォーマンスを高めるために導入されました。DTS は UADP ASIC の AQM ブロックの一部です。
DTS は以下の利点を提供します :
* バーストの間、ポートごと、キューごとに動的な追加バッファを割り当て
* 共有バッファはマイクロ バーストの間、トラフィックのドロップを削減
* 共有バッファと動的割当のバッファの数の間で、バランスを提供
* 柔軟なバッファ管理 : 専用バッファに共有バッファを追加
DTS は以下の機能を動作させます :
* バッファを使用していないポートから、共有プールを作成
* ポートごと、キューごとに設定可能な、専用しきい値の有効化
* グローバルに設定可能な、最大共有しきい値の有効化
* ハード バッファ (専用) とソフト バッファ (共有) 間で、ポートごとにバッファの分割
* 最初に専用バッファを使用し、次に共有プールの消費が公平になるように使用
以下のステップで DTS から共有プールが構築されます :
ステップ 1. DTS はフリーのポートバッファをまとめて、マイクロバーストの間、動的に分散できる 1 つの共有プールを作成します。全体の合計は、まだトラフィックが無いものと仮定します。画像 26. は共有バッファ スペースが作られたことを示しています。
[[ファイル:C90-QoS-26.png|なし|フレーム|画像 26. DTS グローバル とポート共有プール]]ステップ 2. 共有プールから作成し、バッファを取得してマイクロ バーストが来ているポートキューへ割り当てます。マイクロ バーストが終了すると、バッファは共有プールへ戻されます。画像 27. は共有プールがどのように消費されるかを示しています。[[ファイル:C90-QoS-27.png|なし|フレーム|画像 27. グローバルと共有プールが提供するポート キューの調整]]次に DTS のパラメータと、それらが動的割当バッファとしてどのように使用されるか説明します。画像 28. はメイン パラメータとそれらの相関関係を示します。[[ファイル:C90-QoS-28.png|なし|フレーム|画像 28. DTS のパラメータ]]'''専用 / ハード バッファ :''' これは特定のキューで最小予約されるバッファです。UADP ASIC はレベル 1 優先キューにのみ、ハード バッファを使用します。ハード バッファは画像 28. には表示させていません。しかしそれらは "HardMax" コマンドと呼ばれます。
'''共有 / ソフト バッファ :''' これらのバッファはポート キューへ動的に割り当てられますが、他のポート キューによっても共有されます。ソフト バッファを管理するためのパラメータは以下です :
* '''SoftMin :''' ポートに与えられる、最小共有バッファです。デフォルトでは、共有バッファの小さな部分が非優先キューに割り当てられ、トラフィックを確実に送信できるようになります。設定によって、削除が可能です。
* '''SoftMax :''' ポート キューが共有プールから消費できる、最大のバッファです。これは設定可能なパラメータで、デフォルトは 100 です。
* '''Soft Start :''' 共有バッファは使用率を定期的に監視されています。もし全体バッファ使用率が 75% に届くと、ポートごとのバッファの動的割当の一部が削減され始めます。共有バッファの使用率が高くなると、バッファの減少をもっと積極的に行います。
* '''Soft End :''' 共有バッファの使用率が最大に達した時、マイクロ バースト (SoftMin と SoftMax が等しい) を吸収するための、追加バッファをポートキューへ提供できなくなります。共有バッファはポート キューごとの SoftMin バッファをまだ提供しており、キューは最小バッファを送信のために持っていますが、追加バッファはありません。
'''ポートごとと、グローバル共有バッファプール :''' DTS のメッセージは共有プールの 2 セットがあります。
'''グローバル :''' ポート間で共有が許可されたバッファ。このプールはパラメータの前に "Global" の接頭辞を使用します。例 : GlblSMin.
'''ポート キュー間 :''' ポート キュー間で共有が許可されたバッファ。このプールはパラメータの前に "Port" 接頭辞を使用します。例 : PortSMin , PortStEnd.
ポート キュー バッファが調整される時、2 つの独立した調整が要求されます : グローバル プールからと、ポート共有プールから行われます。グローバル プールとポート プールの占有率がチェックされ、ポート キューはより大きなバッファを提供する共有プールからバッファを取得し、それを使用してマイクロ バーストを吸収します。
* Q0 は専用 / HardMax バッファを固定的に持っています
* Q0 は HardMax を使用した後、共有プールから消費できます
* Q1 は専用 / HardMax バッファを持っていません しかし SoftMin と同じ値で共有プールから専用にバッファの割当を受けています
* Q0 用の SoftMax は、HardMax の 4 倍です
* Q0 が優先レベル 1 にセットされている時、SoftMax は HardMax の値と同じに設定されます
* Q1 の SoftMax は GlobalSoftMin (GblSMin) の 4 倍です
ポート キュー設定を読みとるには、"'''show platform hardware fed [switch] [active] qos queue config interface"''' コマンドを使用し、前述のバッファの DTS パラメータをスイッチから直接表示させます。[[ファイル:C90-QoS-29.png|なし|フレーム|画像 29. DTS パラメータと CLI の設定を読むためのマッピング]]
共有プールからポートへバッファの割当を増やすためには、SoftMax しきい値を増やすコマンド "qos queue-softmax-multiplier" を使用します。その最大値は 1200 で、マイクロ バーストを吸収する単一ポートのキューの能力が、12 倍になります。
このコマンドはポート キューしきい値を向上させ、ポート キューが共有プールから追加バッファを消費できます。共有プールはリースが限られており、それは物理メモリの消費を意味します。
従ってすべてのポートがすべてのマイクロ バーストを処理するために、必要なバッファを共有プールから消費できるわけではありません。バッファ共有自体は、同時にスイッチのすべてのポートでマイクロ バーストが発生するわけではないことを、前提としています。
もしマイクロ バーストがランダムな瞬間に発生すると、共有バッファはそれらを吸収するために専用の追加バッファを割り当てることができるでしょう。このように DTS を使用することによって、UADP ASIC は非常に効率的に PBC を利用できます。
ポートごとの全体バッファの数は、増やすことができませんが、ポート速度に依存して割り当てられたバッファは、ポート キューごとのバッファの数を、デフォルトの割当から変更することができます。
Cisco Catalyst C9300-24UB と C9300-48UB スイッチは、スタック ポートを無効化するオプションを提供し、16.12(1) から "qos stack-buffer" コマンドをサポートします。これは IQS と SQS からバッファを共有プールに戻す機能です。
UADP 3.0 ベースの Cisco Catalyst スイッチは、17.2(1) からユニファイド バッファ機能を有効にするための、"qos share-buffer" コマンドを使用できます。
表 3. にさまざまな Cisco Catalyst 9000 ファミリのポート速度ごとに割り当てられた全体バッファを示します。
{| class="wikitable"
|+
!プラットフォーム
!キュー
! colspan="2" |100M , 1 / 2.5 / 5Gbps
! colspan="2" |10Gbps
! colspan="2" |25Gbps
! colspan="2" |40Gbps
! colspan="2" |100Gbps
|-
|
|
|Hard Max
|Soft Max
|Hard Max
|Soft Max
|Hard Max
|Soft Max
|
|
|
|
|-
|Cisco Catalyst
9200 シリーズ
|Q0
|81
(1Gbps のみ)
|324
(1Gbps のみ)
|408
|1632
| -
| -
| -
| -
| -
| -
|-
|Cisco Catalyst
9300 シリーズ
|Q0
|100
|400
|600
|2400
|600
|2400
|2400
|9600
| -
| -
|-
|Cisco Catalyst
9400 シリーズ
|Q0
|176
|700
|176
|700
|176
|700
|176
|700
| -
| -
|-
|Cisco Catalyst
9500 シリーズ
|Q0
|200
|800
|1200
|4800
|1200
|4800
|4800
|19,200
|–
|–
|-
|Cisco Catalyst
9500 ハイパフォーマンス と 9600
シリーズ
|Q0
|112
|448
|240
|960
|480
|1920
|720
|2880
|1920
|7680
|-
|
|
|Soft
Min
|Soft
Max
|Soft
Min
|Soft
Max
|Soft
Min
|Soft
Max
|Soft
Min
|Soft
Max
|Soft
Min
|Soft
Max
|-
|Cisco Catalyst
9200 シリーズ
|Q1
|4721 (1 Gbps only)
|488 (1 Gbps only)
|1912
|2448
|–
|–
|–
|–
|–
|–
|-
|Cisco Catalyst
9300 シリーズ
|Q1
|150
|600
|300
|1200
|300
|1200
|3600
|14,400
|–
|–
|-
|Cisco Catalyst
9400 シリーズ
|Q1
|336
|1344
|264
|1056
|264
|1056
|337
|10,800
|–
|–
|-
|Cisco Catalyst
9500 シリーズ
|Q1
|300
|1200
|1800
|7200
|1800
|7200
|7200
|28,800
|–
|–
|-
|Cisco Catalyst
9500 ハイパフォーマンス と 9600
シリーズ
|Q1
|336
|672
|360
|1440
|720
|2880
|1080
|4320
|2880
|11,520
|}
ノート : 表 3. はほとんどデフォルトの数値を示していますが、プラットフォームごとに若干調整されている場合があります。
以下の設定はポート キューに、どのように与えられたバッファの 100% を再配分するかを示しています。バッファ用の MQC ポリシー (削減された CLI) はポートの出力方向にのみ適用できます。<syntaxhighlight lang="c">
policy-map 2P6Q3T
class PRIORITY-QUEUE
queue-buffers ratio <number>
class VIDEO-PRIORITY-QUEUE
queue-buffers ratio <number>
class DATA-QUEUE
queue-buffers ratio <number>
class class-default
queue-buffers ratio <number>
</syntaxhighlight>
バッファを手動で書き換えた時、ユーザは全ポートで一定量のバッファを確保して、割り当てる必要があります。もしバッファが割り当てられていなければ、トラフィックはキューでドロップするでしょう。
例 1. に設定するべきではない例を示します。これはネットワークが停止する原因となるでしょう。<syntaxhighlight lang="c">
例 1.
policy-map 2P6Q3T
class PRIORITY-QUEUE
class VIDEO-PRIORITY-QUEUE
class DATA-QUEUE
queue-buffers ratio 50
class class-default
queue-buffers ratio 50
</syntaxhighlight>例 1. は以下の問題があります :
* キュー バッファを 100% まで、2 つのキューのみにすべて割り当ててしまっている
* もしそれぞれのキューがキューバッファの指定を持っていない場合、以下の動作になります :
(100% - 特定のキューにバッファを割り当てて) 次にキューバッファを設定していないキューで均等に分割する
例 1. の結果として、キュー "DATA-QUEUE" と "class-default" はバッファ全体を消費してしまい、残りのキューから出力されようとスケジュールされた、すべてのトラフィック はドロップするでしょう。
例 2. でどのように手動で再配分すれば良いか示します。<syntaxhighlight lang="c">
例 2.
policy-map 2P6Q3T
class PRIORITY-QUEUE
queue-buffers ratio 10
class VIDEO-PRIORITY-QUEUE
queue-buffers ratio 10
class DATA-QUEUE
queue-buffers ratio 35
class class-default
queue-buffers ratio 45
</syntaxhighlight>
例 2. のポリシーの結果として、すべてのキューがトラフィックの送信を有効化するためのバッファを持ちます。
[[ファイル:C90-QoS-0a.png|代替文=]]
もう一つ重要なコマンドとして、バッファ使用率がポート キューごとにどのように変化するか、リアルタイムで示します。このコマンドは、ASIC から値を読み取ります。
* ポート キューしきい値
** ウェイテッド・テール・ドロップ (WTD)
<blockquote>ポート キューしきい値は、キューの最後 (テール・ドロップ) よりトラフィックを早期にドロップするために使用されます。
もしポート キューがキューの終わり前で特定のトラフィックをドロップする機能がある場合、ユーザ設定に基づいてポート キューによって管理されるその他のトラフィックよりも、特定のパケットのためにバッファスペースを確保できます。
画像 30. に様々なキューしきい値として、DSCP , CoS , IPv4 IP プレシデンス (ToS) , IPv6 トラフィック クラスを、ユーザが柔軟に割り当てできることを示します。
17.3(1) から、同じように MPLS EXP ベースの WTD をサポートします。
もしキュー使用率が TH0 を超えたとき、キューの使用率を TH0 を下回るまで、このしきい値に該当するように設定された、すべての新しいトラフィックはドロップされます。
TH1 も同じように動作しますが、トラフィックのグループが異なる (=優先度が高いため、ドロップが遅らせる) ため、TH0 より大きな値を持っています。明示的に定義されていない QoS 優先度を持つトラフィックは、TH2 と一致するため、キューのテール エンドは自動的に縮小します。</blockquote>[[ファイル:C90-QoS-30.png|なし|フレーム|画像 30. 1 つのポートの WTD しきい値]]
UADP ASICs は、ポート キューごとに 3 つまでのしきい値を提供します。1 つのキューの 3 つのしきい値は、同じタイプのパケット ヘッダを使用する必要があります。例として、1 つのキューで 3 つのすべてのしきい値が CoS を使用する場合、他のキューは DSCP のように他のパケット ヘッダを使用することができません。
デフォルトでは、TH0 を 80% に設定し、TH1 を 90% に、TH2 を 100% or テール ドロップと同じに設定されています。すべてのトラフィックは初期状態として TH2 に割り当てられておりますが、MQC ポリシー経由でしきい値を変更することができます。しきい値の別名は、ウェイテッド・テール・ドロップ (WTD) で、しきい値は重み付けと同じ意味になります。
以下は WTD を変更するための MQC ポリシーのサンプルです。<syntaxhighlight lang="c">
policy-map 2P6Q3T
class DATA-QUEUE
queue-limit dscp values af13 cs1 percent 80
queue-limit dscp values af12 percent 90
queue-limit dscp values af11 percent 100
</syntaxhighlight>ASIC で設定されたしきい値を見るためには、以下のコマンドを使用します。
[[ファイル:C90-QoS-0b.png|代替文=]]
キューとしきい値に割り当てられたトラフィック タイプが何なのか見るために、トラフィック タイプをラベルにマッピングし、2 つめのコマンドを使用して、ラベルが適用されているキューを確認する必要があります。この場合は、共有機能を向上させるために、ラベルが使用されます。<syntaxhighlight lang="c">
Switch# show platform software fed [switch] [active] qos tablemap dir ingress interface <name>
Label legend: DSCP:1 COS:65 UP:73 PREC:81 EXP:89 GROUP:97 CTRL:128 CPU:130
DSCP-to-Label --
0-Label: 1 1-Label: 2 2-Label: 3 3-Label: 4
4-Label: 5 5-Label: 6 6-Label: 7 7-Label: 8
….
COS-to-Label --
0-Label:65 1-Label:66 2-Label:67 3-Label:68
4-Label:69 5-Label:70 6-Label:71 7-Label:72
UP-to-Label --
0-Label:73 1-Label:74 2-Label:75 3-Label:76
4-Label:77 5-Label:78 6-Label:79 7-Label:80
PREC-to-Label --
0-Label:81 1-Label:82 2-Label:83 3-Label:84
4-Label:85 5-Label:86 6-Label:87 7-Label:88
EXP-to-Label --
0-Label:89 1-Label:90 2-Label:91 3-Label:92
4-Label:93 5-Label:94 6-Label:95 7-Label:96
GROUP-to-Label --
0-Label: 0 1-Label: 0 2-Label: 0 3-Label: 0
4-Label: 0 5-Label: 0 6-Label: 0 7-Label: 0
…..
</syntaxhighlight>
'''ステップ 2.''' ラベルの値がキューかしきい値に該当させるために、次のコマンドを使用します。
[[ファイル:C90-QoS-0c.png|代替文=]]
* ウェイテッド・ランダム・アーリー・ディスカード (WRED)
<blockquote>WRED はキューがいっぱいになるために、帯域を超過したポートのキューで、ランダムにフレームを廃棄するためのアルゴリズムです。WRED はランダム・アーリー・ディスカード (RED) アルゴリズムがベースになっています。</blockquote><blockquote>RED と WRED を見る前に、TCP フロー管理を簡単に振り返ってみましょう。フロー管理は、TCP 送信側がネットワークを埋め尽くさないようにします。"TCP スロー スタート" アルゴリズム (RFC2001 で定義) はこれに対処するための解決策の一部です。
それはフローを開始する時に指示し、1 つのパケットが送信されると、次に確認応答 (ACK) を待ちます。ACK が受信されると、TCP エンドポイントは 2 つのパケットを送信し、さらにデータを送る前に、次の ACK を待ちます。パケットの数を段々と増加させて送信します。
これはフローが送信レベル (パケットを x 個送信) に達するまで継続し、ネットワークに混雑を伴う負荷を発生させないように、管理します。混雑が発生した場合、スロースタート アルゴリズムは、ウィンドウ サイズ (ACK を待つ前に送信したパケットの数) を抑制します。
これによりネットワークがそれらをドロップせずに処理できる数に、送信が正規化されます。
RED はキューが一杯になり始めるか監視します。しきい値を超過すると、パケットはランダムにドロップさせられます。これらのパケットは高優先 or 低優先フローから選択され、単一のフロー or 複数の TCP フローからなる場合もあります。
もし複数のフローに影響があると、上記で説明したように、それぞれのフローのウィンドウ サイズで考慮すべき影響が出てしまいます。</blockquote>
<blockquote>RED とは異なり、WRED ではパケットをドロップする時に完全なランダムではありません。WRED はパケットの優先度 (CoS , DSCP , トラフィック クラス , IP プレシデンス値) を考慮して、ドロップするパケットを選択します。
この処理は高優先度のフローは影響を受けず、大きなウィンドウ サイズを保持でき、送信側から受信側へパケットを送る際、遅延を最小化に抑えることができます。
WRED の実装は、UADP 2.0 かそれ以降 (AQM ブロック内) で、アプラクサメイト・フェア・ドロップ (AFD) アルゴリズムとキューの使用率がベースになっています。
AFD はパケットのドロップ確率を、低しきい値と高しきい値の平均をとして計算するために使用されます。WRED しきい値は、WTD しきい値とは異なるものです。
17.3(1) から MPLS EXP ベースとした WRED もサポートされます。
パケットがキューに来た時、WRED は最初に計算されます。WRED に基づいて、キューが帯域幅を超過した場合、パケットは最初の WRED 計算でドロップされ、次にテールドロップでドロップされます。 </blockquote>画像 31. に AFD で計算された WRED の例を示します。この計算は低しきい値の CoS 0 , 1 と、高しきい値の CoS 2 ,3 の平均をベースにしています。
AFD はドロップの確率を以下のように計算します :
* CoS 0 ,1 が低優先度 = 20 と 高 = 30 の場合パケットの重み付けは以下 : (20 + 30) / 2 = 重み付け 25 or CoS 2 , 3 より前にパケットをドロップさせはじめる ドロップの確率は、(1 / weight) = 1 / 25 = 0.04
* CoS 2 ,3 が低優先度 = 60 と 高 = 80 の場合パケットの重み付けは以下 : (60 + 80) / 2 = 重み付け 70 or CoS 0 , 1 より後にパケットをドロップさせはじめる ドロップの確率は、(1 / weight) = 1 / 70 = 0.01428
CoS 0 , 1 のドロップ確率は、ドロップが早く開始され、キューをいっぱいになるとさらに増加するため、確率も常に高くなります。
[[ファイル:C90-QoS-31.png|なし|フレーム|画像 31. WRED ドロップ確率の増加]]
それぞれのポート キューは WRED クラシフィケーションの 1 つのタイプのみを使用できます。例えば、もし DSCP 値を使用すると、同じポート キューでは CoS は使用できません。しかし同じポートの別のキューでは、DSCP ではなく CoS を使用できます。<syntaxhighlight lang="c">
policy-map 2P6Q3T
class DATA-QUEUE
random-detect dscp-based
random-detect dscp 10 percent 60 80
class BULK-QUEUE
random-detect cos-based
random-detect cos 1 percent 60 80
</syntaxhighlight>
Cisco Catalyst 9000 ファミリ スイッチは、以下の WRED をサポートします :
* UADP 2.0 と 2.0 XL ASIC は 8 個のポートキューから、4 個の WRED キューまで有効にできます
* UADP 3.0 ASIC は 8 個のポートキューまで 、WRED をサポートします
UADP ASIC バージョンに関係なく、以下をサポートします :
* ポート キューは WRED を使用しないと WTD を使用します
* WRED は優先キューでサポートされません
* クラスマップごとに 3 つの WRED レンジまでサポートされ、1 つのレンジはパケット クラシファイアーのレンジによって使用することが可能です
<syntaxhighlight lang="c">
class <queuing-class-map>
random-detect cos 1 percent 10 20 (range1)
random-detect cos 2 percent 30 40 (range2)
random-detect cos 3 percent 50 60 (range3)
</syntaxhighlight>
まとめ : キューイング、バッファリング、しきい値の出力 QoS ツールは、ビジネス クリティカルなトラフィックの管理と優先付けを助けることが可能です。しかし出力ポートでドロップの削減を助けるために、いくつかのテクニックが存在します :
* UADP ASIC コア間でバースト要件に従って、アクティブ ポートを分散し、コアの物理バッファスペースを共有するポートが少なくなるようにします。
* 分散のサンプル 1 : コア 1 に 1 つのポートのみとします このモデルは 1 つのポートがすべての UADP ASIC コアのバッファを消費する必要がある場合に使用され、残りのポートで高レベルのマイクロ バーストが発生しない場合に使用できます
[[ファイル:C90-QoS-32.png|なし|フレーム|画像 32. 1 つのポートが PBC 全体を消費可能]]
* 分散のサンプル 2 : すべてのアクティブポートは、すべての ASIC コアを横断して等しく分散させます このモデルは、すべてのアクティブ ポートが似たレベルのマイクロバーストがある場合に使用されます ; このため PBC リソースの使用率を、異なる UADP ASIC コアを横断して、等しく分散できます
[[ファイル:C90-QoS-33.png|なし|フレーム|画像 33. 物理ポート分散]]
===== 均等なポート分散 =====
以下のようにコマンドでマッピングを確認でき、フロント パネル ポートをインスタンスにマッピングできます
[[ファイル:C90-QoS-0d.png|代替文=]]
* "qos queue-softmax-multiplier <100-1200>" コマンドを使用します このコマンドは、DTS セクションで説明したものです マイクロ バーストを吸収するために、PBC の能力を増加させるには、1200 に近い値を使用します
* ポートごとのキューの数を削減します 例えば 8 つではなく、3 つののキューを使用します すべてのキューが共有プールから専用のバッファを持ちますが、ことはグローバル プールの全体サイズを減らしてしまいます いくつかのキューは共有プールが大きなサイズを持ちます
===== 出力シェーピング =====
シェーピングは出力 QoS ツールで、ポート キューのパケット送信を制限するために使用できます。シェーピング機能はポリシングとは異なり、パケットをドロップする前に空いたバッファ スペースを使用しようと試みます。しかしポリシングはパケットをすぐにドロップします。
バッファされたパケットは、ポートが次の送信サイクルが来ると送信されるでしょう。画像 34. にシェーピングとポリシングの違いを示します。
17.3(1) から出力キューイングで MPLS EXP も他と同様にサポートされました。
[[ファイル:C90-QoS-34.png|なし|フレーム|画像 34. シェーピングとポリシング]]
===== シェーピングとポリシング =====
シェーピングは、一定量のトラフィックがバッファされ、バーストがなくなったときポートから送信されます。バッファリングは送信を遅らせるため、パケットに遅延を加えることになります。
UADP ASIC はすべてのポートキューについて、シェーパーを提供します。以下はシェーピングを設定するためのサンプル MQC シェーピングです :<syntaxhighlight lang="c">
policy-map Shaper
class Voice
shape average percent 10
class Video
shape average percent 20
class Signaling
shape average percent 5
class Transactions
shape average percent 30
</syntaxhighlight>
まとめ : シェーピングは主にキューの優先度をコントロールするために使用されます。それは WRR キューでいくらかのスペースを残すため、優先キューの合計帯域幅を制限します。
<span></span><ins class="adsbygoogle" style="display:block; text-align:center;" data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-1930311742297749" data-ad-slot="5409634032"></ins><span></span><span></span>
===== 出力クラシフィケーション、ポリシング、マーキング =====
画像 35. に 2 つの注釈の例を示します。1 つめは入力側で、2 つめは出力側です。オリジナル パケットの代わりに、入力結果を出力側で使用します :
# IFC は入力パケットの DSCP を 10 から 30 にリマークします
# しかし EFC は出力ポート 2 で MQC ポリシーを使用し、DSCP 30 から 40 へ リマークを指示し、出力ポート 1 は IFC の結果を保持します
[[ファイル:C90-QoS-35.png|なし|フレーム|画像 35. 2 ステージ リマーキング]]
===== 2 ステージ リマーキング =====
以下は 2 ステージ リマーキングを設定するための MQC ポリシーの例です :
[[ファイル:C90-QoS-0e.png|代替文=|なし|フレーム]]
まとめ : 出力クラシフィケーション、ポリシング、マーキングは、QoS に関する UADP ASIC の機能を更に拡張します。それらは複数の送信元ポートから、パケットを取り出すためのオプションを提供し、1 つの出力 MQC ポリシーのみを適用する選択肢を提供します。さらに 2 ステージ リマーキング or ポリシングのオプションも提供します。
=== 階層型 QoS ===
階層型 QoS (HQoS) は、2 つの MQC ポリシーに親と子として 2 つのレベルに積み重ねられる出力ツールで、ポリシーの粒度を高めることができます。親ポリシーは上位側のレベルで、子は下位側のレベルです。管理者は QoS を以下のように使用できます。 :
* 親クラスは子ポリシーで、複数キューをシェープできるようにします
* 特定のポリシー マップのアクションを、集約トラフィックに適用します
* クラス固有のポリシー マップ アクションを適用します
Cisco Catalyst 9000 ファミリ スイッチの重要な優位点の一つは、ハードウェアで HQoS をサポートすることです。
以下 4 つの組み合わせを HQoS でサポートします。:
* ポート シェーパー
* 集約ポリサー
* ポートごと、VLAN ごとのポリシー
* 親ポリシーがシェーパーを使用
==== ポート シェーパー ====
HQoS ポート シェーパーは、class-default を使用してすべての出力トラフィックにシェーパーを適用します。このシェープされた帯域幅は、追加した子ポリシーで特定が可能です。
以下の例は、HQoS ポート シェーパー設定のサンプルです。<syntaxhighlight lang="c">
policy-map PARENT
class class-default
shape average percent 10
service-policy CHILD
policy-map CHILD
class VOICE
priority level 1
police rate percent 20
class C1
bandwidth remaining percent 10
class C2
bandwidth remaining percent 20
class C3
bandwidth remaining percent 70
</syntaxhighlight>
HQoS ポート シェーパー ポリシーの注意点 :
* 親ポリシーで class-default クラスのみ、使用されます
* 子ポリシーで 1 つ or 2 つの優先キューのみ、許可されます
* 子ポリシーのクラスごとに、異なる帯域幅が許可されます
==== 集約ポリサー ====
HQoS 集約ポリサーは、class-default を使用してすべての出力トラフィックにポリサーを適用します。この減少された帯域幅は、追加した子ポリシーで特定が可能です。
以下の例は、HQoS 集約ポリサー設定のサンプルです。<syntaxhighlight lang="c">
policy-map PARENT
class class-default
police cir percent 30
service-policy CHILD
policy-map CHILD
class C1
set dscp 10
class C2
set dscp 20
class C3
set dscp 30
</syntaxhighlight>HQoS 集約ポリサーと シェーパー ポリシーの注意点 :
* テーブル マップは、子ポリシーで set action として使用可能です
==== ポートごと、VLAN ごとのポリシー ====
ポートごと、VLAN ごとのポリシーは、複数の HQoS 親ポリサーに適用され、それぞれのポリサーはクラシファイアとして VLAN にマッチします。それぞれの VLAN で個別のポリサーで帯域幅を削減され、追加子ポリシーが適用されます。
以下の例は、HQoS ポートごと、VLAN ごとのポリサー設定のサンプルです。<syntaxhighlight lang="c">
policy-map PARENT
class vlan10
police rate percent 10
service-policy CHILD
class vlan20
police rate percent 20
service-policy CHILD
class vlan30
police rate percent 30
service-policy CHILD
policy-map CHILD
class C1
set dscp 10
</syntaxhighlight>
HQoS ポートごと、VLAN ごとのポリサーの注意点 :
* テーブル マップは、子ポリシーで set action として使用可能です
* 複数のクラスは親ポリシーで許可されます
==== 親ポリシーのシェーパー使用 ====
複数 HQoS シェーパーは親ポリシーに適用され、それぞれのシェーパーはトラフィック クラスにマッチします。それぞれ個別にシェーピングで帯域幅を削減され、追加子ポリシーが適用されます。
以下の例は、HQoS 親ポリシー シェーピング設定のデモです。<syntaxhighlight lang="c">
policy-map PARENT
class C1
shape average percent 10
service-policy CHILD
class C3
shape average percent 20
service-policy CHILD
class class-default
shape average percent 30
service-policy CHILD
policy-map CHILD
class C1
police rate percent 10
set dscp 10
class C2
police rate percent 20
set dscp 20
class C3
police rate percent 30
set dscp 30
</syntaxhighlight>HQoS 親ポリシー シェーパーの注意点 :
* テーブル マップは、子ポリシーで set action として使用可能です
==== ポリシーマップ カウンター ====
入力と出力 QoS ツールは、UADP ASIC で処理されるパケットの可視化に統計情報を提供します。
ポリシーマップはアクションで使用されるものをベースに、異なるカウンターをサポートします :
* もしマーキングかポリシングを使用していると、ポリシーマップはいくつのパケット or バイトが、クラスマップにマップされたか or ポリサーによって破棄されたか表示します
* もしキューイング アクションがインターフェースで設定されていると、ポリシーマップはキューに入った・ドロップされたパケットの数 or バイト数のカウンターをサポートします
* もし同じポリシーが 2 つ or より多くのポートあいだで共有されていると、カウンターはポリシーを共有するすべてのポートあいだで集約されません
* QoS ポリシー マップ カウンターは、以下の手法で取得てきます :
** YANG モデルの運用と設定
** SNMP MIB : CiscoCBQoSMIB
以下の出力は、異なるツールをベースにしたカウンターのサンプルです。 :
注意点 : CLI 出力はソフトウェア リリースの 16.9(2) から取得できます
* マーキングとポリサーのポリシーカウンター ('''入力と出力で適用可能''') :
注意点 :
* もし複数のポートで同じ名前のポリシーが共有されていると、ポリシー マップ カウンターは集約され、ポート間で TCAM エントリが共有されます 結果として、あるインターフェースではトラフィックなしで増加が見られてしまいますが、共有化されることで TCAM 使用率は削減されます
* もしポリシー マップ カウンターがポートごとに必要とされる場合は、異なる名前でポリシーマップを作成すれば可能ですが、TCAM のエントリは共有されません
<syntaxhighlight lang="c">
Switch# show policy-map interface <interface>
<interface>
Service-policy input: <policy-map name>
Class-map: dscp20 (match-all) à Marking Action
452651460 packets
Match: dscp af22 (20)
QoS Set
dscp af23
Class-map: dscp21 (match-all) à Policing Action
73673977 packets
Match: dscp 21
police:
cir 10 %
cir 1000000000 bps, bc 31250000 bytes
pir 20 %
pir 2000000000 bps, be 62500000 bytes
conformed 3757257000 bytes; actions:
transmit
exceeded 3758219000 bytes; actions:
set-dscp-transmit dscp table MARKDOWN
violated 29321508000 bytes; actions:
drop
conformed 96546000 bps, exceeded 96571000 bps, violated 753431000 bps
</syntaxhighlight>
キューイング ポリシーのカウンター (出力ポートごと、キューごとに表示可能)<syntaxhighlight lang="c">
Switch# show platform hardware fed [switch] [active] qos queue stats interface <interface>
DATA Port:16 Enqueue Counters
------------------------------------------------------------------------------
Queue Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
--- ---- ---- ------ ----- -----
0 0 0 0 4797 0
1 0 0 0 64310 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:16 Drop Counters
------------------------------------------------------------------------------
Queue Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
-- ----- ------- ------ ------ ----- -------
0 0 0 3 0 0 0
1 0 0 87 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
</syntaxhighlight>
* シェーパー (出力ポートごと、キューごとに表示可能) :
<syntaxhighlight lang="c">
Switch# show policy-map interface <egress interface>
<interface>
<snip>
queue stats for all priority classes:
Queueing
priority level 2
(total drops) 9772202000 -> in bytes by default
(bytes output) 2443152000
pkts output) 4910606 -> switch to packets with CLI “qos queue-stats-frame-count”
</syntaxhighlight>
* WRED (出力ポートごと、キューごとに表示可能):
<syntaxhighlight lang="diff">
Switch# show policy-map interface <egress-interface>
<snip>
Class-map: dscp2 (match-all)
0 packets
Match: dscp 2
Queueing
(total drops) 0
(bytes output) 0
bandwidth remaining 9%
queue-buffers ratio 9
AFD WRED STATS BEGIN
Virtual Class min/max Transmit Random drop AFD Weight
0 10 / 20 (Byte)0 0 4
(Pkts)0 0
dscp : 2
1 100/ 100 (Byte)0 0 29
(Pkts)0 0
dscp :
2 100/ 100 (Byte)0 0 29
(Pkts)0 0
dscp :
Total Drops(Bytes) : 0
Total Drops (Packets) : 0
</syntaxhighlight>
=== オーバーレイ技術の QoS とキューイング ===
このセクションでは、UADP ASIC によってどのようにパケットのカプセル化を処理するか説明します。カプセル化されたパケットは、1 つ以上の IP ヘッダを持ちます。このためそれらは異なる処理が必要です。
==== GRE , VXLAN , CAPWAP ====
ジェネリック・ルーティング・エンキャプスレーション (GRE) トンネル、バーチャル・エクステンシブル・LAN (VXLAN)、コントロール・アンド・プロビジョニング・オブ・ワイヤレス・アクセス・ポイント (CAPWAP) は、オリジナルのパケットを外部ヘッダで包むことで、オリジナル パケットを書き換えることなく、複数のホップを横断する際、より効率的にパケットを運ぶことを可能する、オーバーレイ技術です。
===== GRE がカプセル化したパケットが内部に持つ、オリジナルのレイヤ 3 パケット : =====
[[ファイル:C90-QoS-36.png|なし|フレーム|画像 36. GRE でカプセル化されたパケット]]
カプセル化を画像 36. に示します。パケットは新しい IP ヘッダと GRE ヘッダを後ろに追加します。IP ヘッダの ToS バイト値は、内部 IP ヘッダから外部 IP ヘッダへコピーされます。
===== VXLAN がカプセル化したパケットが部に持つ、オリジナルのレイヤ 2 フレームとレイヤ 3 パケット : =====
[[ファイル:C90-QoS-37.png|なし|フレーム|画像 37. VXLAN にカプセル化されたパケット]]
カプセル化を画像 37. に示します。パケットは新しい IP ヘッダと VXLAN ヘッダを後ろに追加します。IP ヘッダの ToS バイト値は、内部 IP ヘッダから外部 IP ヘッダへコピーされます。
===== CAPWAP が内部に持つ、オリジナルのレイヤ 2 フレームとレイヤ 3 パケット : =====
[[ファイル:C90-QoS-38.png|なし|フレーム|画像 38. CAPWAP カプセル化パケット]]
カプセル化を画像 38. に示します。パケットは新しい IP ヘッダと CAPWAP ヘッダを後ろに追加します。IP ヘッダの ToS バイト値は、内部 IP ヘッダから外部 IP ヘッダへコピーされます。
==== ASIC からのカプセル化パス ====
UADP ASIC は、パケットを転送するためにオーバーレイ ヘッダを加えることが可能で、オリジナル パケットを全く書き換えず、現状のまま転送します。そのプロセスはカプセル化と呼ばれ、ハードウェアによってラインレートで行われます。
画像 39. に GRE , VXLAN , CAPWAP カプセル化について、パケットの主要処理を示します。パケットが 5 の DSCP 値を持ってスイッチに入ってきたと仮定します。そのパケットがカプセル化されると、外部 IP ヘッダは内部の DSCP 値 5 と同じ値を持ちます。
# 入力側物理インターフェースの入力 QoS ポリシーは、オリジナル パケットを元にしてクラシファイ (分類) します もし QoS ポリシーが入力側物理インターフェースで適用されていれば、カプセル化に使用した外部ヘッダに作用します
# GRE , VXLAN , CAPWAP トンネル インターフェースは、入力側で QoS ポリシーをサポートしません
# パケットは外部カプセル化ヘッダを加えるため、再循環されます
# GRE , VXLAN , CAPWAP トンネル インターフェースは、出力側で QoS ポリシーをサポートしません
# もし QoS ポリシーが出力側物理インターフェースで適用されていれば、カプセル化されたパケットが離れる時に、:
* クラシフィケーションは外部ヘッダのみで使用されます
* 出力キューイングは、外部ヘッダの書き換えられた ToS 値を使用しません
* 出力キューイングは、外部ヘッダの ToS 値をベースにします これは内部ヘッダからコピーされたものです
QoS ポリシーが適用されない場合 :
* 出力キューイングは、外部ヘッダの ToS 値をベースにします これは内部ヘッダからコピーされたものです
内部カプセル化パケットは書き換えられず、クラシフィケーションは実行されません。
[[ファイル:C90-QoS-39.png|なし|フレーム|画像 39. GRE , VXLAN , CAPWAP カプセル化の処理]]
==== ASIC からのカプセル化解除パス ====
UADP ASIC は、内部パケットを宛先へ届けるためにオーバーレイ ヘッダを削除することが可能です。そのプロセスはカプセル化解除と呼ばれ、ハードウェアによってラインレートで行われます。
画像 40. に GRE , VXLAN , CAPWAP カプセル化解除を示します。再循環されると、外部ヘッダは廃棄され、内部 IP ヘッダは出力キューイングされるインターフェースで使用されます。
# 入力側物理インターフェースの入力 QoS ポリシーは、外部ヘッダを元にしてクラシファイ (分類) します
# GRE , VXLAN , CAPWAP トンネル インターフェースは、入力側で QoS ポリシーをサポートしません
# パケットは外部カプセル化ヘッダを削除するため、再循環されます
# GRE , VXLAN , CAPWAP トンネル インターフェースは、出力側で QoS ポリシーをサポートしません
# もし QoS ポリシーが出力側物理インターフェースで適用されていれば、カプセル化されたパケットが離れる時に、:
* クラシフィケーションはカプセル化解除されたパケットヘッダで使用されます
* 出力キューイングは、カプセル化解除されたヘッダの、書き換えられた ToS 値を使用しません
* 出力キューイングは、カプセル化解除されたヘッダの、ToS 値をベースにします
QoS ポリシーが適用されていない場合は、:
* 出力キューイングはカプセル化が解除されたヘッダをベースにして実施されます
[[ファイル:C90-QoS-40.png|なし|フレーム|画像 40. GRE , VXLAN , CAPWAP カプセル化解除の QoS 処理]]
=== MPLS QoS ===
MPLS パケットはラベルを持っており、高速転送とセグメンテーションに使用されます。UADP ASIC は、ヘッダから EXP マーカーを抜き出して、クラシフィケーション (分類) に使用します。MPLS 機能セットは、以下のモードがサポートされています。 :
パイプ モード : DiffServ トンネリング パイプ モードは、2 つのレイヤで QoS を使用します :
* データの基盤となる QoS は、コアを通過する際に変更されません
* コアごとの QoS は、基盤となる IP パケットとは別のものです このコアごとの QoS は、パー・ホップ・ビエイビア (PHB) と呼ばれ、エンドユーザからは透過的に見えます。
パケットが MPLS コアの協会に届くと、出力側プロバイダー・エッジ (PE) スイッチである PE2 は、MPLS PHB ベースでアウト バウンド キューイングのため、直近で削除されたラベルの EXP ビットから、取り出した IP パケットをクラシファイ (分類) します。
[[ファイル:C90-QoS-41.png|なし|フレーム|画像 41. MPLS パイプ モードの QoS 処理]]
ショート パイプ モードはサポートされません。
* ユニフォーム モード (デフォルト) : DiffServ トンネリングのユニフォーム モードは、QoS レイヤが 1 つだけで、末端の端末から末端の端末へ届かせます
入力側 PE スイッチ (PE1) は、入力された IP パケットから、付与された MPLS ラベルの EXP ビットにコピーします。EXP ビットはコアを旅して、それらは中間の P スイッチによって書き換えられなかったり、書き換えられたりします。画像 42. に例を示します。この例では、P スイッチである P1 が、トップにあるラベルの EXP ビットを書き換えます。出力 P スイッチである P2 は、PHP (ペナルティ メイト・ホップ・ポップ=最後から 2 番目のラベルの取り外し) の後に、新たなラベルの EXP ビットへコピーします。最終的に、出力 PE スイッチである PE2 で、EXP ビットを取り出した IP パケットの DSCP ビットへコピーします。
[[ファイル:C90-QoS-42.png|なし|フレーム|画像 42. MPLS ユニフォーム モードの QoS 処理]]
=== オート QoS ===
Cisco オート QoS は、音声と映像トラフィックについて、自動化した QoS 機能によって、QoS の構築を劇的に簡素化し、テンプレートを使うことで、一貫性のあるやり方と進化した機能と Cisco IOS XE ソフトウェアの知性を利用できます。
オート QoS テンプレートは RFC4594 の推奨による、マーキングと medianet アプリケーション クラスのプロビジョニングに従っています。
[[ファイル:C90-QoS-43.png|なし|フレーム|画像 43. マーカー割り当てごとの、オート QoS トラフィック]]
以下のテンプレートは、オート QoS テンプレートに統合済みで、12 クラスが常にテンプレートによって必要とされたり、使用されたりするわけではありません。
* auto qos trust {cos | dscp} : このオプションは、CoS や DSCP のどちらかを、ポートで固定的に信頼するよう設定します もし CoS も DSCP も明示的に設定していねければ、auto qos trust コマンドは、レイヤ 2 スイッチポートでは CoS 信頼、レイヤ 3 ルーテッド インターフェースでは DSCP 信頼に設定します このコマンドはCisco Catalyst 9000 ファミリ スイッチでオプションとなり、デフォルトの動作は、レイヤ 2 と レイヤ 3 マーカー (CoS と DSCP) を信頼します
* auto qos video [cts | ip-camera] : このオプションは、cts キーワードで Cisco テレプレゼンス システムを、ip-camera キーワードで Cisco IP ビデオ サーベイランス カメラの自動設定を提供します
* auto qos classify {police} : このオプションは包括的なテンプレートを提供し、クラシファイ (分類) と 6 つのクラスの medianet トラフィックのマーク アップが可能です オプションとして police キーワードを使用することで、データプレーンとごみクラスの QoS ポリシー要素のポリシングを準備します
* auto qos voip [cisco-phone | cisco-softphone | trust] : このオプションは、旧世代の VoIP IP テレフォニーをサポートするだけではなく、これらのモデルを拡張し、リッチ メディア アプリケーションについて追加クラスの提供を含んでいます データプレーンとごみクラスの QoS ポリシー要素のポリシングを準備し、これらのアプリケーションの保護とセキュリティを実現します
画像 44. に、インターフェース信頼モデルの推奨を示します。
[[ファイル:C90-QoS-44.png|なし|フレーム|画像 44. 推奨のオート QoS 信頼モデル]]
条件付き信頼モデルは、エンド ポイントの機器からマーキングを動的に受け入れるモデルです。シスコ・ディスカバリー・プロトコル (CDP) ネゴシエーションのように特定の条件に合致すると、画像 44. の緑丸に示すように、インターフェースを信頼に設定します。
このモデルは以下を接続するスイッチポートに適しています。:
* Cisco IP フォン : trust device cisco-phone
* Cisco テレプレゼンス システム : trust device cts
* Cisco IP ビデオ サーベイランス カメラ : trust device ip-camera
* Cisco デジタル メディア プレーヤー : trust device media-player
==== オート QoS キューイング モデル ====
それぞれの オート QoS オプションは、自動的にすべてのスイッチ ポートで出力キューイング モデルを準備し、適用されます。
オート QoS のさらなる情報は、Cisco Catalyst 9000 QoS コンフィギュレーションガイドを参照してください。
=== StackWise Virtual システム ===
StackWise Virtual システム (SVS) は、2 つの物理スイッチを 1 つの論理スイッチ システムとして結合させる機能です。SYS の 1 つのコンポーネントとして、StackWise Virtual Link (SVL) があります。このセクションでは QoS と SVL のキューイングの挙動について説明します。
* SVL QoS とキューイング メカニズムは、固定設定されています
* QoS と SVL のキューイング ポリシーは、変更することができません
画像 45. に、キューごとの SVL のマーカー割り当てを示します。
[[ファイル:C90-QoS-45.png|なし|フレーム|画像 45. SVL ポートにおける、キューごとのトラフィック]]
=== CPU へ向かうパケットと CPU から出るパケット ===
Cisco Catalyst 9000 スイッチ ファミリは、特別なセットのキューを持っており、CPU のアクセスを管理します。このキューのセットは、優先パケットが最初に受信できるようになります。
==== CPU へ向かうパケット ====
CPU へ向かうパケットは、通常の入力データ転送パスを通ります。パケット タイプによっては、 CPU キューの一つに入ります。すべての CPU キューは、CPU を保護するために事前定義されたポリサーを持っています。これは一般的にコントロール・プレーン・ポリシング (CoPP) と呼ばれます。
[[ファイル:C90-QoS-46.png|なし|フレーム|画像 46. CPU に向かうパケットの処理]]
CPU にパケットが届く前に、4 つのステップがあります。 :
# もしトラフィックを CPU に届けたくない場合、トラフィックを拒否するために入力 ACL が使用可能です このステップはオプションです ポート、VLAN , ルーテッド ACL のように、異なる ACL タイプがサポートされています
# パケットは CoPP ポリシーをベースに分類され、CPU キューに入ります このステップで最初に優先トラフィックを届けます
# 特定の 1 つめのレベルのポリシング レートごとに、トラフィックは削減されます いくつかのポリサーは共有されます
# 最後に高レベルと低レベルのポリサーが追加されます 2 レベル目の集約された 1 つめのクラスは、レートを追加で削減できます 2 レベル目のポリサーは、Cisco IOS XE 16.9 以降で追加されました
CoPP は以下の制限があります。:
* CoPP は入力方向のみサポートされます system-cpp-policy ポリシー マップは、入力方向のコントロール プレーン インターフェースのみで有効です
* system-cpp-policy マップと、システムで定義された17 個のクラスは、変更や削除ができません
* police アクションは、system-cpp-policy ポリシー マップの下で有効です さらに、police レートはパケット・パー・セカンド (pps) でのみ設定可能です
* CPU キューの有効化 or 無効化 :
** system-cpp-policy ポリシー マップ内で対応する、クラス マップの下で policer アクションを pps で設定することで、CPU キューを有効にできます
** system-cpp-policy ポリシー マップ内で対応する、クラス マップの下で policer アクション削除することで、CPU キューを無効にできます
* cpp system-default コマンドをグローバル コンフィギュレーション モードで入力することで、これらの値をデフォルト値に戻すことが可能です
* CoPP は 2 レベルの階層型を使用します (Cisco IOS XR 16.9 以降で導入されました)
* カスタム CoPP プロファイル or カスタム クラスは、サポートされません
[[ファイル:C90-QoS-47.png|なし|フレーム|画像 47. CoPP ポリシーの出力を確認]]
==== CPU から出るパケット ====
パケットは CPU によって生成され、ダイレクトに出力キューへ送信されます。
ポートにキューイング ポリシーを定義したとき、コントロール パケットは以下の順番にキューへマッピングされます。:
# 最高レベルの優先キューは、常に最初に選ばれます
# 優先キューが無いとき、キュー 0 が選択されます
2 つめのケースではキュー 0 が選択され、CPU で生成されたトラフィックに最適な QoS 処理を適用するために、このキュ0-へ最大の帯域幅を割り当てる必要があります。
次に、優先度が組み込まれていないパケットタイプである、LACP PDU について説明します。
サンプル ポリシー : <syntaxhighlight lang="c">
First case:
policy-map <name>
class <name>
priority level 1
=> LACP パケットはこのキューに入ります
Second case:
policy-map <name>
class <name associated with queue 0>
=> LACP パケットは優先キューが定義されていないため、キュー 0 に入ります
</syntaxhighlight>
最後に、パケットが CPU から生成されると、レイヤ 2 ポートやルーテッド インターフェースに適用された ACL 分類で、出力 QoS ポリシーが動作し、ポリシーはこれらのパケットをリマークすることが可能です。しかし CPU から生成されたパケットで DSCP , CoS , トラフィック クラスが使用されると、QoS ポリシーはこれらのパケットをリマークしません。
=== 結論 ===
Cisco Catalyst 9000 ファミリ スイッチは、QoS とキューイング用に、柔軟にハードウェア リソースを変更・調整するための、技術を提供します。これらの技術は、時間の経過による変化に適応するための、様々なオプションを提供します。
=== 参照 ===
Cisco Catalyst 9000 ファミリの概要 :
https://www.cisco.com/c/en/us/products/switches/catalyst-9000.html
モデルごと :
https://www.cisco.com/c/en/us/products/switches/catalyst-9200-series-switches/index.html
https://www.cisco.com/c/en/us/products/switches/catalyst-9300-series-switches/index.html
https://www.cisco.com/c/en/us/products/switches/catalyst-9400-series-switches/index.html
https://www.cisco.com/c/en/us/products/switches/catalyst-9500-series-switches/index.html
https://www.cisco.com/c/en/us/products/switches/catalyst-9600-series-switches/index.html
=== 付録 A : TCAM のクラシフィケーション (分類) ===
このセクションでは、QoS ポリシーに対応する ASIC 内部のハードウェア プログラミングを記載します。
==== TCAM テーブルとは何ですか ? VCUs とはなにですか ? ====
===== TCAM (ターナリー・コンテント・アドレッサブル・メモリ) =====
1 回のクロック サイクルでコンテンツ全体を検索できる、特別なタイプの高速メモリです。"ターナリー (3 値)" という用語は、0 , 1 , X と異なる入力を使用してデータを保存したり呼び出したりする、メモリの機能を挿しています。
===== VCUs (バリュー・コンペアリング・ユニット) =====
TCAM でレイヤ 4 処理をスケールするために使用される、特別なレジスタです。それらは TCAM からリンクされ、複数の TCAM エントリ間で共有できます。レイヤ 4 処理は VCU レジスタを使用し、より少ない (Less Than = LT) , より多い (Greater Than = GT) , 範囲指定 , イコールでない (NOR) , イコール (EQ) は、VCU を使用するレイヤ 4 処理とはみなされません。
その分類処理は、TCAM のテーブルを使用します。TCAM テーブルは MQC ポリシーをベースに事前プログラムされます。テーブルは必要とされるすべての分類に一致する、エントリが含まれています。
[[ファイル:C90-QoS-48.png|なし|フレーム|画像 48. TCAM ルックアップ (ステップ 1)]]
スイッチはパケット ヘッダやマーカーを使用してハッシュキーを生成することで、ポリサーやリマークされた値を得ることができ、エントリと照合できます。
[[ファイル:C90-QoS-49.png|なし|画像 49. TCAM ルックアップ (ステップ 2)|代替文=|フレーム]]
結果が得られると、スイッチは必要とされるアクションを取ります。:
* ポリサー
* マーキング
* マークダウン
* ミューテーション
QoS ACL は異なる数の VCUs を使用し、レイヤ 4 処理によって、:
* イコールでない (NE=Not Equal) は、1 つの VCU を消費
* 範囲指定は、2 つの VCUs を消費し、小さい値と高い値を持ちます
* より大きい (GT) とより小さい (LT) は、1 つの VCU を消費します
* 送信元と宛先レイヤ 4 処理は、別々の VCUs を消費します
[[ファイル:C90-QoS-50.png|なし|フレーム|画像 50. VCU 使用率]]
VCU エントリは、ACL が複数の TCAM エントリ (アクセス リスト エントリ = ACE) で同じ範囲のポートを使用した場合、削減されます。
=== 付録 B : UADP ASIC スケール ===
表 4. に UADP ASICs スケールの情報をリストアップします。
{| class="wikitable"
|+
!クオリティ・オブ・サービス
UADP スケール
!UADP
Mini
!UADP
2.0
!UADP
2.0 XL
!UADP 3.0
|-
|Catalyst スイッチで使用されている
|Cat9200
|Cat
9300
|Cat9300 ,
9400 , 9500
|Cat9500 High ,
9600
|-
|ポリシーごとの入力クラスマップ
|256
|256
|256
|256
|-
|ポリシーごとの出力クラスマップ
|256
|256
|256
|256
|-
|ポリシーごとの入力ポリサー
|63
|63
|63
|63
|-
|ポリシーごとの出力ポリサー
|63
|63
|63
|63
|-
|スイッチごとの全体ポリシーマップ
|1599
|1599
|1599
|1599
|-
|コアごとの集約ポリサー 1R2C
|1024
|4096
|4096
|4096
|-
|コアごとの集約ポリサー 2R3C
|512
|2048
|2048
|2048
|-
|入力テーブルマップ
|16
|16
|16
|16
|-
|出力テーブルマップ
|16
|16
|16
|16
|-
|マークダウン テーブル (超過アクション)
|8
|8
|8
|8
|-
|マークダウン テーブル (違反アクション)
|8
|8
|8
|8
|-
|ポートごとの出力キュー
|8
|8
|8
|8
|-
|コアごとのバッファ (MB)
|6
|8
|16
|18
|-
|ASIC ごとのバッファ (MB)
|6
|16
|32
|36
|-
|コアごとの QoS ACLs
|1000
|5000
|18000
|16000
|-
|方向ごとの QoS ACLs
|1000
|5000
|18000
|8000
|-
|WRED (キューまで)
|NA
|4
|4
|8
|-
|入力 VCU
|192
|192
|192
|192
|-
|出力 VCU
|96
|96
|96
|96
|}
==== QoS TCAM の消費ルール : ====
* UADP 2.0 , 2.0 XL , UADP Mini
** IPv4 ACL は 1 つの ACE を消費
** IPv6 ACL は 2 つの ACE を消費
** もしクラスマップが DSCP でマッチすると、3 つの ACE をインストールされる : 1 つの IPv4 と 2 つの IPv6
* UADP 3.0
** IPv4 ACL は 1 つの ACE を消費
** IPv6 ACL は 1 つの ACE を消費
** もしクラスマップが DSCP でマッチすると、2 つの ACE をインストールされる : 1 つの IPv4 と 1 つの IPv6
=== 付録 C : パケット フォーマットの詳細 ===
以下の画像 51. は、異なるキャプチャでパケットの中でマーカーを見つけて、どのように読み取るか示したものです。
[[ファイル:C90-QoS-51.png|なし|フレーム|画像 51. レイヤ 2 CoS (ユーザー プライオリティ) パケット フォーマット]]
[[ファイル:C90-QoS-52.png|なし|フレーム|画像 52. MPLS EXP パケットフォーマット]]
タイプ・オブ・サービス (ToS) は 1 バイトのフィールドで、IPv4 ヘッダに存在します。IPv6 ヘッダでも似たフィールドがあり、トラフィック クラスと呼ばれます。
[[ファイル:C90-QoS-53.png|なし|フレーム|画像 53. レイヤ 3 IP プレシデンス (ToS) と DSCP パケット フォーマット]]
ToS フィールドは 8 つのビットからなっており、最初の 3 ビットが IP パケットの優先度を示しています。これらの最初の 3 ビットは、IP プレシデンス ビットとして参照され、0 から 7 の値 (0 は低優先度で、7 が高優先度) を持ちます。Cisco IOS XE では IP プレシデンスによる設定を長年サポートしています。画像 54. は ToS ヘッダの IP プレシデンス ビットを説明しています。
[[ファイル:C90-QoS-54.png|なし|フレーム|画像 54. IP プレシデンスとして ToS バイトを読む方法]]
ToS バイトは DSCP やトラフィック クラス フォーマットとして読むことができ、6 ビットを持っています。
[[ファイル:C90-QoS-55.png|なし|フレーム|画像 55. DSCP と IP プレシデンス間の比較]]
* ToS バイトの 3 つの最上位ビット (MSB) は、DSCP と互換性を持ち、IP プレシデンスとして、解釈されます
* ToS バイトの 3 つの最下位ビット (LSB) は、Drop 確率として解釈されます
* ToS バイトの最後の 2 ビットは、明示的輻輳通知 (エクスプリシット・コンジェスチョン・ノーティフィケーション = ECN) です ECN ビットは、Cisco Catalyst 9000 スイッチ ファミリでは使用されません
=== エキスパートの推奨するドキュメント ===
* [https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9000/nb-09-cat-9k-aag-cte-en.html Cisco Catalyst 9000 At-a-Glance]
* [https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xe/nb-06-cisco-ios-xe-faq-en.html Open IOS XE FAQ]
<span></span><ins class="adsbygoogle" style="display:block; text-align:center;" data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-1930311742297749" data-ad-slot="5409634032"></ins><span></span><span></span>
{{#seo:
|title={{#if: {{{page_title|}}} | {{{page_title}}} | Cisco Catalyst 9000 スイッチング プラットフォーム QoS and キューイング ホワイトペーパー}}
|titlemode={{{title_mode|}}}
|keywords={{{keywords|}}}
|description={{{description|}}}
}}
[[Category:アーキテクチャ]]
[[カテゴリ:Catalyst]]
[[カテゴリ:翻訳]]