1,903
回編集
差分
ナビゲーションに移動
検索に移動
1行目:
1行目: − {{#seo:+ − |title={{#if: {{{page_title|}}} | {{{page_title}}} | Welcome to WikiSEO}} − |titlemode={{{title_mode|}}} − |keywords={{{keywords|}}} − |description={{{description|}}} − }} − − [[Category:アーキテクチャ]] − − 40行目:
31行目: − + 64行目:
55行目: − + 847行目:
838行目: − + + + 873行目:
866行目: − + 906行目:
899行目: − [[ファイル:C90-QoS-0c.png|代替文=|なし|フレーム]] + − + − − − − − − RED はキューが一杯になり始めるか監視します。しきい値を超過すると、パケットはランダムにドロップさせられます。これらのパケットは高優先 or 低優先フローから選択され、単一のフロー or 複数の TCP フローからなる場合もあります。もし複数のフローに影響があると、上記で説明したように、それぞれのフローのウィンドウ サイズで考慮すべき影響が出てしまいます。 − − + + 926行目:
913行目: − + − − − + − + − ドロップの確率は、(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 のドロップ確率は、ドロップが早く開始され、キューをいっぱいになるとさらに増加するため、確率も常に高くなります。 968行目:
947行目: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Cisco Catalyst 9000 スイッチング プラットフォーム QoS and キューイング ホワイトペーパー (ソースを閲覧)
2021年4月11日 (日) 20:48時点における版
、 2021年4月11日 (日) 20:48編集の要約なし
このドキュメントは、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] を非公式に翻訳したものです。
このドキュメントは、hkatou Lab が Cisco Catalyst 9500 Architecture White Paper を非公式に翻訳したものです。
原文・画像の著作権は Cisco Systems にあります。
原文・画像の著作権は Cisco Systems にあります。
==== 輻輳のタイプ ====
==== 輻輳のタイプ ====
[[ファイル:C90-QoS-01.png|なし|フレーム|画像 1. 輻輳のタイプ]]2 つのタイプの輻輳は画像 1. に示しています :
[[ファイル:C90-QoS-01.png|なし|画像 1. 輻輳のタイプ|代替文=|フレーム]]2 つのタイプの輻輳は画像 1. に示しています :
* '''複数ポートから単一ポートへ :''' 複数の送信元ポートから単一の宛先ポートへ同時に送信するとき、複数の送信元から合計されたトラフィックが届いてしまい、宛先ポートが服装します
* '''複数ポートから単一ポートへ :''' 複数の送信元ポートから単一の宛先ポートへ同時に送信するとき、複数の送信元から合計されたトラフィックが届いてしまい、宛先ポートが服装します
=== Cisco Catalyst 9000 ファミリにおける ASIC の QoS の統合 ===
=== Cisco Catalyst 9000 ファミリにおける ASIC の QoS の統合 ===
Cisco Catalyst 9000 スイッチング プラットフォームは、エンタープライズ LAN アクセス、ディストリビューション、コアスイッチにおける次世代の Cisco ファミリです。Cisco ユニファイド・アクセス・データ・プレーン (UADP) アプリケーション・スペシフィック・インテグレーテッド・サーキット (ASIC) はこのプラットフォームはより高速なパフォーマンス、多くの新機能と動作を提供します。
Cisco Catalyst 9000 スイッチング プラットフォームは、エンタープライズ LAN アクセス、ディストリビューション、コアスイッチにおける次世代の Cisco ファミリです。Cisco ユニファイド・アクセス・データ・プレーン (UADP) アプリケーション・スペシフィック・インテグレーテッド・サーキット (ASIC) はこのプラットフォームはより高速なパフォーマンス、多くの新機能と動作を提供します。
[[ファイル:C90-QoS-02.png|なし|フレーム|画像 2. Cisco Catalyst 9000 ファミリ スイッチ]]
[[ファイル:C90-QoS-02.png|なし|画像 2. Cisco Catalyst 9000 ファミリ スイッチ|代替文=|フレーム]]
Cisco Catalyst 9000 スイッチング プラットフォームは、一般的で強力なハードウェアとソフトウェア基盤で成り立っています。その性質と一貫性は、ネットワークエンジニアと管理者にシンプルさと運用のしやすさをもたらし、トータルで運用コストの削減とよりよい体験を創出します。
Cisco Catalyst 9000 スイッチング プラットフォームは、一般的で強力なハードウェアとソフトウェア基盤で成り立っています。その性質と一貫性は、ネットワークエンジニアと管理者にシンプルさと運用のしやすさをもたらし、トータルで運用コストの削減とよりよい体験を創出します。
例 2. のポリシーの結果として、すべてのキューがトラフィックの送信を有効化するためのバッファを持ちます。
例 2. のポリシーの結果として、すべてのキューがトラフィックの送信を有効化するためのバッファを持ちます。
[[ファイル:C90-QoS-0a.png|代替文=|なし|フレーム]]
[[ファイル:C90-QoS-0a.png|代替文=]]
もう一つ重要なコマンドとして、バッファ使用率がポート キューごとにどのように変化するか、リアルタイムで示します。このコマンドは、ASIC から値を読み取ります。
もう一つ重要なコマンドとして、バッファ使用率がポート キューごとにどのように変化するか、リアルタイムで示します。このコマンドは、ASIC から値を読み取ります。
queue-limit dscp values af11 percent 100
queue-limit dscp values af11 percent 100
</syntaxhighlight>ASIC で設定されたしきい値を見るためには、以下のコマンドを使用します。
</syntaxhighlight>ASIC で設定されたしきい値を見るためには、以下のコマンドを使用します。
[[ファイル:C90-QoS-0b.png|代替文=|なし|フレーム]]
[[ファイル:C90-QoS-0b.png|代替文=]]
'''ステップ 2.''' ラベルの値がキューかしきい値に該当させるために、次のコマンドを使用します。
'''ステップ 2.''' ラベルの値がキューかしきい値に該当させるために、次のコマンドを使用します。
[[ファイル:C90-QoS-0c.png|代替文=]]
* ウェイテッド・ランダム・アーリー・ディスカード (WRED)
* ウェイテッド・ランダム・アーリー・ディスカード (WRED)
<blockquote>WRED はキューがいっぱいになるために、帯域を超過したポートのキューで、ランダムにフレームを廃棄するためのアルゴリズムです。WRED はランダム・アーリー・ディスカード (RED) アルゴリズムがベースになっています。</blockquote><blockquote>RED と WRED を見る前に、TCP フロー管理を簡単に振り返ってみましょう。フロー管理は、TCP 送信側がネットワークを埋め尽くさないようにします。"TCP スロー スタート" アルゴリズム (RFC2001 で定義) はこれに対処するための解決策の一部です。それはフローを開始する時に指示し、1 つのパケットが送信されると、次に確認応答 (ACK) を待ちます。ACK が受信されると、TCP エンドポイントは 2 つのパケットを送信し、さらにデータを送る前に、次の ACK を待ちます。パケットの数を段々と増加させて送信します。これはフローが送信レベル (パケットを x 個送信) に達するまで継続し、ネットワークに混雑を伴う負荷を発生させないように、管理します。混雑が発生した場合、スロースタート アルゴリズムは、ウィンドウ サイズ (ACK を待つ前に送信したパケットの数) を抑制します。これによりネットワークがそれらをドロップせずに処理できる数に、送信が正規化されます。
WRED はキューがいっぱいになるために、帯域を超過したポートのキューで、ランダムにフレームを廃棄するためのアルゴリズムです。WRED はランダム・アーリー・ディスカード (RED) アルゴリズムがベースになっています。
RED と WRED を見る前に、TCP フロー管理を簡単に振り返ってみましょう。フロー管理は、TCP 送信側がネットワークを埋め尽くさないようにします。"TCP スロー スタート" アルゴリズム (RFC2001 で定義) はこれに対処するための解決策の一部です。それはフローを開始する時に指示し、1 つのパケットが送信されると、次に確認応答 (ACK) を待ちます。ACK が受信されると、TCP エンドポイントは 2 つのパケットを送信し、さらにデータを送る前に、次の ACK を待ちます。パケットの数を段々と増加させて送信します。これはフローが送信レベル (パケットを x 個送信) に達するまで継続し、ネットワークに混雑を伴う負荷を発生させないように、管理します。混雑が発生した場合、スロースタート アルゴリズムは、ウィンドウ サイズ (ACK を待つ前に送信したパケットの数) を抑制します。これによりネットワークがそれらをドロップせずに処理できる数に、送信が正規化されます。
RED とは異なり、WRED ではパケットをドロップする時に完全なランダムではありません。WRED はパケットの優先度 (CoS , DSCP , トラフィック クラス , IP プレシデンス値) を考慮して、ドロップするパケットを選択します。この処理は高優先度のフローは影響を受けず、大きなウィンドウ サイズを保持でき、送信側から受信側へパケットを送る際、遅延を最小化に抑えることができます。
RED はキューが一杯になり始めるか監視します。しきい値を超過すると、パケットはランダムにドロップさせられます。これらのパケットは高優先 or 低優先フローから選択され、単一のフロー or 複数の TCP フローからなる場合もあります。もし複数のフローに影響があると、上記で説明したように、それぞれのフローのウィンドウ サイズで考慮すべき影響が出てしまいます。</blockquote>
<blockquote>RED とは異なり、WRED ではパケットをドロップする時に完全なランダムではありません。WRED はパケットの優先度 (CoS , DSCP , トラフィック クラス , IP プレシデンス値) を考慮して、ドロップするパケットを選択します。この処理は高優先度のフローは影響を受けず、大きなウィンドウ サイズを保持でき、送信側から受信側へパケットを送る際、遅延を最小化に抑えることができます。
WRED の実装は、UADP 2.0 かそれ以降 (AQM ブロック内) で、アプラクサミトゥ・フェア・ドロップ (AFD) アルゴリズムとキューの使用率がベースになっています。AFD はパケットのドロップ確率を、低しきい値と高しきい値の平均をとして計算するために使用されます。WRED しきい値は、WTD しきい値とは異なるものです。
WRED の実装は、UADP 2.0 かそれ以降 (AQM ブロック内) で、アプラクサミトゥ・フェア・ドロップ (AFD) アルゴリズムとキューの使用率がベースになっています。AFD はパケットのドロップ確率を、低しきい値と高しきい値の平均をとして計算するために使用されます。WRED しきい値は、WTD しきい値とは異なるものです。
17.3(1) から MPLS EXP ベースとした WRED もサポートされます。
17.3(1) から MPLS EXP ベースとした WRED もサポートされます。
パケットがキューに来た時、WRED は最初に計算されます。WRED に基づいて、キューが帯域幅を超過した場合、パケットは最初の WRED 計算でドロップされ、次にテールドロップでドロップされます。
パケットがキューに来た時、WRED は最初に計算されます。WRED に基づいて、キューが帯域幅を超過した場合、パケットは最初の WRED 計算でドロップされ、次にテールドロップでドロップされます。 </blockquote>画像 31. に AFD で計算された WRED の例を示します。この計算は低しきい値の CoS 0 , 1 と、高しきい値の CoS 2 ,3 の平均をベースにしています。
画像 23. に AFD で計算された WRED の例を示します。この計算は低しきい値の CoS 0 , 1 と、高しきい値の CoS 2 ,3 の平均をベースにしています。
AFD はドロップの確率を以下のように計算します :
AFD はドロップの確率を以下のように計算します :
* CoS 0 ,1 が低優先度 = 20 と 高 = 30 の場合パケットの重み付けは以下 :
* CoS 0 ,1 が低優先度 = 20 と 高 = 30 の場合パケットの重み付けは以下 : (20 + 30) / 2 = 重み付け 25 or CoS 2 , 3 より前にパケットをドロップさせはじめる ドロップの確率は、(1 / weight) = 1 / 25 = 0.04
(20 + 30) / 2 = 重み付け 25 or CoS 2 , 3 より前にパケットをドロップさせはじめる
* 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">
それぞれのポート キューは WRED クラシフィケーションの 1 つのタイプのみを使用できます。例えば、もし DSCP 値を使用すると、同じポート キューでは CoS は使用できません。しかし同じポートの別のキューでは、DSCP ではなく CoS を使用できます。<syntaxhighlight lang="c">
* WRED は優先キューでサポートされません
* WRED は優先キューでサポートされません
* クラスマップごとに 3 つの WRED レンジまでサポートされ、1 つのレンジはパケット クラシファイアーのレンジによって使用することが可能です
* クラスマップごとに 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 キューでいくらかのスペースを残すため、優先キューの合計帯域幅を制限します。
===== 出力クラシフィケーション、ポリシング、マーキング =====
画像 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 ===
階層型 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”
● WRED (applicable for egress per port per queue):
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
AFD WRED STATS END
</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 システム (SYS) は、2 つの物理スイッチを 1 つの論理スイッチ システムとして結合させる機能です。SYS の 1 つのコンポーネントとして、StackWise Virtual Link (SVL) があります。このセクションでは QoS と SVL のキューイングの挙動について説明します。
* SVL QoS とキューイング メカニズムは、固定設定されています
* QoS と SVL のキューイング ポリシーは、変更することができません
画像 45. に、キューごとの SVL のマーカー割り当てを示します。
[[ファイル:C90-QoS-45.png|なし|フレーム|画像 45. SVL ポートにおける、キューごとのトラフィック]]
=== CPU へ向かうパケットと CPU から出るパケット ===
The Cisco Catalyst 9000 switch family has a special set of queues that manage the access to the CPU. This set of queues can ensure that priority packets are received first.
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 バイトの 2 つの最下位ビット (LSB) は、明示的輻輳通知 (エクスプリシット・コンジェスチョン・ノーティフィケーション = 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]
{{#seo:
|title={{#if: {{{page_title|}}} | {{{page_title}}} | Cisco Catalyst 9000 スイッチング プラットフォーム QoS and キューイング ホワイトペーパー}}
|titlemode={{{title_mode|}}}
|keywords={{{keywords|}}}
|description={{{description|}}}
}}
[[Category:アーキテクチャ]]