サービス品質(QoS) : QoS リンク効率性メカニズム

Catalyst 6000 ファミリ スイッチの Quality of Service(QoS)について

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2003 年 9 月 29 日) | 英語版 (2015 年 9 月 19 日) | フィードバック


目次


概要

この文書では、Catalyst 6000 ファミリ スイッチで使用できる Quality of Service(QoS)機能について説明します。 この文書では、QoS の設定機能について説明するほか、QoS の実装方法についていくつかの例を紹介しています。

この文書は設定ガイドではありません。 Catalyst 6000 ファミリー ハードウェア および ソフトウェアの QoS 機能の説明で助けるのにこの用紙全体設定例が使用されています。 Qos コマンド構造の構文参照に関しては、Catalyst 6000 ファミリー用の次の設定およびコマンド ガイドを参照して下さい:

レイヤ2 QoS の定義

レイヤ 2(L2)スイッチでの QoS は、単にイーサネット フレームの優先順位付けであると考えられがちで、実際にはもっと豊富な機能を提供していることは、あまり理解されていません。 L2 QoS は次を伴ないます:

    1. インプットキュー スケジューリング: フレームがポートに着信すると、出力ポートへのスイッチングのスケジューリングに先立ち、ポートベースの複数のキューのいずれかへの割り当てが可能です。 トラフィックによって異なるサービス レベルが必要な場合や、スイッチによる遅延を最小に抑える必要がある場合は、通常は複数のキューが使用されます。 たとえば、IP はビデオを基づかせ、音声データは低遅延を、そうそこにかもしれません File Transfer Protocol (FTP)のような他のデータを、Web 切り替える前にこのデータを切り替える、必要である電子メール、Telnet、等必要とします。

    2. 分類: 分類のプロセスはイーサネット L2 ヘッダで IP ヘッダー(のフィールドと共に異なるフィールドを、レイヤ3 (L3)点検することを)含みます そして伝送制御プロトコル/ユーザ データグラム プロトコル(TCP/UDP)ヘッダ(レイヤ4 (L4)) それとしてフレームに加えられるサービスのレベルの判別で助けることはスイッチを通過します。

    3. ポリシング: ポリシングとは、イーサネット フレームを検査して、一定のタイムフレーム内でトラフィックが事前に定義されているレートを超過していないかどうかを確認するプロセスです(通常、スイッチでは、このタイムフレームは固定値として設定されています)。 そのフレームがプロファイル外(すなわち、それは定義済みレート リミット以上データ ストリームの一部です)なら、廃棄することができますまたはサービスの分類 (CoS)値はマークダウンすることができます。

    4. リライト: リライト処理とは、イーサネット ヘッダー内の CoS や、IPV4 ヘッダー内の Type of Service(ToS)ビットを変更するというスイッチの機能です。

    5. 出力キューのスケジューリング: リライト処理の後、イーサネット フレームはスイッチングのために適切な発信(出力)キューに置かれます。 スイッチでは、このバッファのオーバーフローを防止することにより、このキューのバッファ管理が行われます。 それは Random Early Discard (RED)アルゴリズムの利用によって一般的に ランダム帯がキューから(廃棄される)取除かれるという、これをします。 Weighted RED(WRED; 重み付けランダム早期検出)は、RED から派生したもので、廃棄するフレームを決定するために CoS 値を検査します。これは、Catalyst 6000 ファミリの一部のモジュールで使用されています。 バッファが事前に定義されているしきい値に達すると、通常は優先順位の低いフレームが廃棄され、優先順位の高いフレームはキューに残されます。

この文書では、これに続くセクションで、上記の各メカニズムの詳細と、Catalyst 6000 ファミリとの関係について説明します。

スイッチにおけるQoS の必要性

巨大なバックプレーン、数百万の交換されたパケット 毎秒およびノンブロッキング スイッチはすべて多くのスイッチと今日同義です。 QoS が必要とされる理由は何でしょうか。 その答えは、輻輳にあります。

スイッチに輻輳が生じる上で図で示されている 2 つのシナリオのどちらかがある場合世界のファースト スイッチである。 輻輳の発生時に、輻輳管理機能が設定されていなければ、パケットは廃棄されます。 パケットが廃棄されると、再送信が行われます。 再送信が行われると、ネットワークの負荷が増大します。 既に混雑しているネットワークでは、これは既存のパフォーマンス上の問題に追加でき、可能性としてはそれ以上パフォーマンスを低下させて下さい。

集約型ネットワークの場合には、輻輳管理はさらに重要になります。 音声およびビデオのような待ち時間に敏感なトラフィックは遅延が招く場合大きく影響することができます。 単にスイッチのバッファを大きくするだけでは、輻輳問題の解決には不十分です。 待ち時間に敏感なトラフィックはできるだけ速く切り替えられる必要があります。 最初に、分類 技術によってこの重要なトラフィックを識別する必要があり次に輻輳の間の廃棄からの高優先順位トラフィックを避ける緩衝域管理手法を実装します。 最終的には、キューからの重要なパケットをできるだけすぐに交換するスケジューリング手法を統合する必要があります。 この資料を読取るので、Catalyst 6000 ファミリーはこれらの手法すべてを実装しま、QoS サブシステム 1 を企業の広範囲の今日作ります。

前のセクションに説明があったこの資料の全体にわたって QoS 手法すべてはより詳しく探索されます。

Catalyst 6000 ファミリーにおけるQoS のハードウェアサポート

Catalyst 6000 ファミリで QoS をサポートするには、ハードウェアによるサポートが必要です。 QoS をサポートするハードウェアには、Multilayer Switch Feature Card(MSFC)、Policy Feature Card(PFC)、およびこのラインカード上のポート Application Specific Integrated Circuit(ASIC; 特定用途集積回路)などがあります。 この文書では、MSFC の QoS 機能については説明していませんが、PFC とラインカード上の ASIC の QoS 機能に絞って説明を行います。

PFC

PFC バージョン 1 は、Catalyst 6000 ファミリのスーパーバイザ I(SupI)およびスーパーバイザ IA(SupIA)に装着されるドーター カードです。 PFC2 は、PFC1 を再設計したもので、新型のスーパーバイザ II(SupII)と、新しいオンボード ASIC と一緒に出荷されています。 PFC1 と PFC2 は、主に L3 スイッチングでのハードウェア アクセラレーションとしての機能が知られていますが、QoS もその目的とする機能の 1 つです。 PFC を次に示します。

PFC1 と PFC2 は基本的には同じものですが、QoS 機能に関してはいくつかの相違点があります。 即ち、PFC2 は次を追加します:

    1. QoS ポリシーを Distributed Forwarding Card(DFC)に送出する機能。

    2. ポリシング判定が、わずかに異なっています。 集約か microflow ポリシーがプロファイル外のデシジョンを戻す場合帯が廃棄されるか、またはマークダウンされるという PFC1 および PFC2 は両方正常なポリシングをサポートします。 ただし、PFC2 はポリシー アクションはで奪取 することができること水平な秒ポリシングを示す超過レートのためのサポートを追加します。

超過レート ポリサーを定義すると、パケットが超過レートを超えた場合に、そのパケットは廃棄またはマークダウンされます。 超過ポリス レベルが設定 される場合マークダウン値とオリジナル DSCP 値を取り替えるのに、過剰 DSCPマッピングが使用されています。 水平な正常なポリシングするだけ設定 される場合、正常な DSCPマッピングは使用されます。 両方のポリシー レベルが設定されていると、マッピング ルールの選択には超過ポリシング レベルが優先されます。

述べられる ASIC によって実行されたこの資料に説明がある QoS 機能がパフォーマンス の レベルをもたらすことに注意することは重要です。 基本的な Catalyst 6000 ファミリでの QoS のパフォーマンス(スイッチ ファブリック モジュールなし)は、15 MPPS になります。 DFC が使用される場合今以上 の パフォーマンス向上を QoS のために達成することができます。

DFC

DFC は、WS-X6516-GBIC にオプションとして装着できます。 ただし、それは WS-X6816-GBIC カードの標準取付具です。 それはまた最近導入されたファブリック 10/100 (WS-X6548-RJ45)ラインカード、ファブリック RJ21 ラインカード(WS-X6548-RJ21)、および 100FX ラインカードのような他の未来のファブリック ラインカードでことができます(WS-X6524-MM-FX)サポートする。 DFC を次に示します。

DFC を装着すると、そのファブリック(クロスバー接続)ラインカードでローカル スイッチングが行えるようになります。 これをするために、それはまたスイッチのために定義された QoS ポリシーをサポートする必要があります。 管理者は直接 DFC を設定できません; むしろ、それはアクティブ監視プログラムのマスター MSFC/PFC の管理下に来ます。 プライマリ PFC から Forwarding Information Base(FIB)テーブルがプッシュされ、これにより DFC に L2 および L3 フォワーディング テーブルが付与されます。 それはまたそれらがラインカードにまたローカルであるように QoS ポリシーのコピーを押下げます。 これにそれに続く、ローカル スイッチング デシジョンは Distributed Switching ハードウェア QoS 処理速度を兼ね備えるおよびの上位レベルをパフォーマンスしかしもたらすあらゆる QoS ポリシーのローカル コピーを参照できます。

ポートベースのASIC

ハードウェアの機能を補完するために、各ラインカードには多数の ASIC が実装されています。 これらの ASIC には、フレームがそのスイッチを通過する際の一時的な保存領域として使用されるキュー、バッファリング、しきい値が実装されています。 10/100 カードでは、ASIC の組み合わせにより、10/100 ポートが 48 ポート提供されています。

基本的な 10/100 ラインカード(WS-X6348-RJ45)

10/100 の ASIC では、それぞれの 10/100 ポートごとに、一連の受信(Rx)キューと送信(Tx)キューが用意されています。 またこの ASIC では、10/100 の 1 ポートあたり 128 K のバッファリングが備わっています。 各ラインカードで利用可能であるポート バッファリングごとのものをの詳細に関するリリース ノートを参照して下さい。 このラインカードの各ポートは Rx 1 キューおよび 2 つの TX キューによって表示される高低をサポートします。 これを次の図で示します。

上記のダイアグラムでは、各 10/100 ASIC はポート 12 10/100 のにブレイクアウトを提供します。 各 10/100 ポートに関しては、128 の K バッファは提供されます。 このバッファの 128 K は、3 つのキューに分割されています。 上の図で示しているキューはデフォルトの設定ではありませんが、設定される代表的な例を表しています。 1 つの Rx キューが 16 K を使用し、残りの 112 K のメモリは 2 つの Tx キューで分割されています。 デフォルトで(CatOS で)、高いキュー gets この領域の 20%および低いキュー 80%得ます。 Catalyst IOS では、デフォルトは 90%高いキューに 10%および低いキューを与えることです。

このカードでは、2 段階のバッファリングを行いますが、QoS 設定の際に操作できるのは 10/100 ASIC ベースのバッファリングだけです。

ファブリック 10/100 ラインカード(WS-X6548-RJ45)

新型の 10/100 の ASIC では、それぞれの 10/100 ポートごとに、一連の Rx キューと Tx キューが用意されています。 この ASIC では、10/100 ポート全体で使用できるメモリの共有プールが提供されています。 各ラインカードで利用可能であるポート バッファリングごとのものをの詳細に関するリリース ノートを参照して下さい。 このラインカードの各ポートは Rx 2 つのキューおよび 3 つの TX キューをサポートします。 1 つの Rx キューと 1 つの Tx キューは、絶対的に優先されるキューとされています。 これらは、低遅延キューとして動作し、Voice over IP(VoIP)トラフィックなどの遅延の影響を受けやすいトラフィックに最適です。

GE ラインカード(WS-X6408A、WS-X6516、WS-X6816)

GE ラインカードに関しては、ASIC はポート バッファリングごとにの 512 K を提供します。 8 ポート GE ラインカードの表示は下記の図で示されています。

10/100 ポートと同様に、各 GE ポートに 3 つのキュー、1 Rx および 2 つの TX キューがあります。 これは WS-X6408-GBIC ラインカードのデフォルトであり、次の図で説明します。

さらに新しい 16 ポートの GE カード、スーパーバイザ IA とスーパーバイザ II の GBIC ポート、および WS-X6408A-GBIC 8 ポート GE カードでは、Strict Priority(SP; 完全優先)キューが 2 つ追加装備されています。 SP キューの 1 つが Rx キューに割り当てられ、もう 1 つの SP キューが Tx キューに割り当てられます。 この SP キューは、主として音声などの遅延の影響を受けやすいトラフィックのキューイングに使用されます。 SP キューを使用すると、このキューに置かれたあらゆるデータは、高優先キューと低優先キューにあるデータよりも先に処理されます。 高優先キューと低優先キューの内容が処理されるのは、SP キューが空の場合だけです。

10 GE ラインカード(WS-X6502-10GE)

2001 年の後半に、Cisco は一組のラインカードごとに 10 GE の 1 つのポートを提供する 10 の GE ラインカードを導入しました。 このモジュールは 6000 シャーシからの 1 つのスロットを奪取 します。 この 10 GE ラインカードでは、QoS がサポートされています。 10 GE ポートに関しては、それは Rx 2 つのキューおよび 3 つの TX キューを提供します。 1 つの Rx キューと 1 つの Tx キューは、それぞれ SP キュー専用です。 バッファリングはまたポートに提供され、TX バッファリングの Rx バッファリングの 256 K および 64 MB の合計を提供します。 このポートには、Rx 側に 1p1q8t のキュー構造、Tx 側に 1p2q1t のキュー構造が実装されています。 キュー構造については、この文書の後の方で説明します。

Catalyst 6000 ファミリーQoS ハードウェアの概要

次の表に、Catalyst 6000 ファミリで前述の QoS 機能を実行するハードウェア コンポーネントの詳細が記載されています。

Catalyst 6000 ファミリーソフトウェアのQoSサポート

Catalyst 6000 ファミリでは、2 つのオペレーティング システムがサポートされています。 元来のソフトウェア プラットフォームである CatOS は、Catalyst 5000 プラットフォームで使用されていたコード ベースに由来するものです。 もっと最近、Cisco は Ciscoルータ IOS から得られるコード ベースを使用する統合 Cisco IOS ® ((以前に Native IOS として知られている)ネイティブモード)をもたらしました。 両方の OS プラットフォーム(CatOS および Integrated Cisco IOS (Native Mode)) 前のセクションに説明があるハードウェアを使用して Catalyst 6000 スイッチ ファミリープラットフォームの QoS を有効に するためにソフトウェアサポートを実装して下さい。

注: この文書では、両方の OS プラットフォームの設定例を使用しています。

IP およびイーサネットの優先メカニズム

データに適用されるべき QoS サービスに関しては IPパケットかイーサネットフレームをタグ付けするか、または優先順位をつける方法がある必要があります。 ToS および CoS のフィールドは、このために使用されます。

ToS

ToS は IPV4 ヘッダーにある 1 バイトのフィールドです。 ToS フィールドは 8 ビットで構成されており、そのうちの最初の 3 ビットが IP パケットの優先順位を示すために使用されます。 この 3 ビットは、IP 優先順位ビットと呼ばれます。 これらのビットで 0 から 7 までの値を設定でき、0 が最低の優先度、7 が最高の優先度を表します。 IP 優先順位を設定する機能は、IOS で長年に渡ってサポートされてきました。 IP 優先順位を再設定する機能は、MSFC または PFC(MSFC とは無関係)によりサポートされています。 信頼できないの信頼 設定はまた着信 フレームの IP 優先順位設定を一掃できます。

IP 優先順位に設定できる値は、次のとおりです。

次の図では、ToS ヘッダー内の IP 優先順位ビットの例を表しています。 MSB(先頭)の 3 ビットが、IP 優先順位として解釈されます。

もっと最近、ToS フィールドの使用は DSCP と言われる 6 MSB を取囲むために拡張されました。 DSCP は IPパケットに割り当てることができる 64 のプライオリティ値(6 の電源への 2)という結果に終ります。

Catalyst 6000 ファミリでは、ToS の処理が可能です。 この処理には、PFC と MSFC のいずれかまたは両方を使用します。 フレームがスイッチに着信すると、DSCP 値が割り当てられます。 この DSCP 値は、管理者が定義したサービス レベル(QoS ポリシー)を割り当てるために、スイッチの内部で使用されるものです。 DSCP は、すでにフレーム内にあってそれが使用されることもあり、また既存の CoS、IP 優先順位、またはフレーム内の DSCP から得られる場合もあります(そのポートが信頼されている場合)。 スイッチでマップが内部で DSCP を得るのに使用されています。 デフォルトのマップでは、8 段階の CoS/IP 優先順位値と 64 段階の DSCP 値を使用して、CoS/IP 優先順位の 0 を DSCP の 0 に、CoS/IP 優先順位の 1 を DSCP の 7 に、CoS/IP 優先順位の 2 を DSCP の 15 にというようにマップします。 管理者は、このデフォルトのマッピングを書き換えることができます。 フレームがある発信ポートにスケジュールされている場合は、その CoS を書き換えし、その DSCP 値を元にして新しい CoS 値を設定できます。

CoS

CoS はスイッチド ネットワークを通ると同時にイーサネットフレームの優先順位を示すのに使用する ISL ヘッダまたは 802.1Q ヘッダの 3 ビットを示します。 この資料の目的で、802.1Q ヘッダの使用だけを参照します。 802.1Q ヘッダーの CoS ビットは、一般的には 802.1p ビットと呼ばれます。 予想通り、CoS 3 つのビットがあります、IP 優先順位に使用するビットの数と一致する。 多くのネットワークでは、QoS をエンドツーエンド維持するために、パケットはドメイン L2 および L3 を両方横断するかもしれません。 QoS を維持するためには、ToS を CoS にマップすることも、CoS を ToS をマップすることもできます。

次の図は、802.1Q フィールドでタグ付けがされたイーサネット フレームを表しています。これは、2 バイトのイーサタイプと、2 バイトのタグで構成されています。 2 バイトのタグの内容は、ユーザ プライオリティ ビット(802.1p)です。

Catalyst 6000 ファミリーのQoS フロー

Catalyst 6000 ファミリでの QoS は、現在の Cisco Catalyst スイッチの中でも、QoS の最も包括的な実装です。 次のセクションでは、フレームがスイッチを通過する際に、さまざまな QoS プロセスがどのように適用されるかについて説明します。

多くの提供 L2 および L3 スイッチができるいくつかの QOS 要素があることに先にこの資料で、注意しました。 これらの要素には、分類、入力キューのスケジューリング、ポリシング、リライト、および出力キューのスケジューリングが含まれています。 Catalyst 6000 ファミリとの違いは、これらの QoS 要素が L2 エンジンによって適用されることです。この L2 エンジンでは、単に L2 ヘッダー情報だけでなく、L3 および L4 の詳細も考慮されます。 次の図は、Catalyst 6000 ファミリでこれらの要素が実装されている仕組みを要約したものです。

フレームはスイッチに入り、フレームを受信したポート ASIC によって最初に処理されます。 それは Rx キューにフレームを置きます。 Catalyst 6000 ファミリー ラインカードによっては、Rx 1-2 のキューがあります。

ポート ASIC では、CoS ビットを指標として使用し、フレームをどのキューに置くかを判定します(入力キューが複数ある場合)。 ポートが信頼できないように分類される場合、ポート ASIC は事前定義値に基づいて CoS 既存のビットを上書きできます。

その後、フレームは L2/L3 フォワーディング エンジン(PFC)に渡されます。ここでは、フレームを分類し、オプションでポリシング(レート制限)を適用します。 分類はフレームにフレームを処理するためにスイッチによって内部で使用される DSCP 値を割り当てることのプロセスです。 DSCP の値は次のいずれかで求められます。

    1. スイッチに入るフレーム前の既存の DSCP 値が設定

    2. IPv4 ヘッダーにすでに設定されている、受信した IP 優先順位ビット。 64 DSCP 値および IP 優先順位値が 8 つだけあるので、管理者は DSCP を得るのにスイッチによって使用するマッピングを設定します。 デフォルトマッピングはもし管理者がマップを設定しなければきちんと整っています。

    3. フレームがスイッチに着信するより前に設定されていた CoS ビット。 IP 優先順位と同様に、CoS 値には 8 段階の値しかないため、それぞれを 64 段階の DSCP 値にマップする必要があります。 このマップは設定することもできますが、スイッチが、すでに存在するデフォルト マップを使用することもできます。

    4. Access Control List(ACL; アクセス コントロール リスト)のエントリで通常割り当てられている DSCP のデフォルト値を使用して、フレームに DSCP 値を設定。

DSCP 値がフレームに割り当てられた後、もしポリシング設定があれば、ポリシング(制限する比率)は適用します。 ポリシングとは、PFC を通過するデータのフローを制限するもので、プロファイル外のトラフィックは廃棄またはマークダウンされます。 プロファイル外という用語は、トラフィックが管理者によって定義されている制限値を超えたことを意味します。この制限値は、PFC が送信する 1 秒当たりのビット数で表されます。 プロファイル外のトラフィックは、廃棄されるか、CoS の値がマークダウンされます。 PFC1 と PFC2 では、現在、入力ポリシング(レート制限)だけがサポートされています。 入出力ポリシングのサポートは、新しい PFC のリリースで使用可能になる予定です。

その後、PFC によりそのフレームが出力ポートに渡され、処理されます。 この時点で、書き直しプロセスはフレームの CoS 値および IPV4 ヘッダの TOS 値を修正するために呼び出されます。 これは内部の DSCP に基づいて行われます。 次に、フレームは CoS 値に基づいて送信キューに置かれて、転送できる状態になります。 フレームがキュー内にある間、ポート ASIC はそのバッファを監視し、オーバーフローを防ぐために WRED を実行します。 WRR スケジューリングアルゴリズムがそれから出力ポートから帯をスケジュールし、送信するのに使用されています

下記の例のそれぞれはより詳しく上述されていたステップのそれぞれのための設定例を与えるこのフローを探索します。

キュー、バッファ、しきい値およびマッピング

QoS 設定が詳しく説明される前に十分にスイッチの QoS 設定機能を理解するようにするために、ある特定の用語は更に説明する必要があります。

キュー

スイッチの各ポートにデータのために一時記憶域域として使用する一連の入出力キューがあります。 Catalyst 6000 ファミリー ラインカードは各ポートのためのキューの異なる数が実装されています。 通常、キューは各ポート用のハードウェア ASIC の中に実装されています。 Catalyst 6000 ファミリのラインカードの最初の世代では、入力キューが 1 つと、出力キューが 2 つという構成が一般的でした。 新しいラインカード(10/100 および GE)では、ASIC によってさらに 2 つのキューの組(入力キューが 1 つと、出力キューが 1 つ)が追加され、合計で 2 つの入力キューと 3 つの出力キューが実装されています。 これらの新しい 2 つのキューは、VoIP のような遅延の影響を受けやすいトラフィックのために使用される特別な SP(完全優先)キューです。 これらは SP 方式で処理されます。 つまり、SP キューにフレームが到達すると、低優先キューからのフレームのスケジューリングが停止され、SP キューにあるフレームが処理されます。 SP キューが空の場合にだけ、低優先キューからのパケットのスケジューリングが再開されます。

輻輳時にポート(入力ポートまたは出力ポート)にフレームが到達すると、そのフレームはキューに置かれます。 フレームをどのキューに置くかの決定は、通常、着信フレームのイーサネット ヘッダー内の CoS 値に基づいて行われます。

出力の場合、スケジューリング アルゴリズムを使用して、Tx(出力)キューが空にされます。 WRR は、このために使用される技術です。 各キューに関してはどの位データが次のキューかに進む前のキューから空になるか定めるのに、ウエイト設定が使用されています。 管理者によって割り当てられる重み付けは、1 から 255 までの数値で、各 Tx キューに割り当てられます。

バッファ

各キュー 中継 データを保存するある程度のバッファ領域は割り当てられます。 ポート ASIC にはメモリがあり、分割されてポートごとに割り当てられます。 各 GE ポートに関しては、GE ASIC はバッファ領域の 512 K を割り当てます。 ポート 10/100 ののために、ポート ASIC は 64 K かポート バッファリングごとにの 128 K を(ラインカードによって)予約します。 このバッファ領域は、さらに Rx(入力)キュー用と Tx(出力)キュー用に分割されます。

しきい値

通常のデータ送信では、パケットが廃棄されると、そのパケットは再送信されます(TCP フロー)。 輻輳の発生時に、これはネットワークのロードに追加し、可能性としては原因バッファさらに過剰にすることができます。 バッファがオーバーフロー しないようにすることの手段として、Catalyst 6000 ファミリ スイッチは出来事からこれを避けるいくつかの手法を用います。

しきい値は、スイッチ(または管理者)によって設定される予測値で、輻輳管理アルゴリズムがキューからのデータの廃棄を開始できる適用水準を定義するものです。 Catalyst 6000 ファミリのポートでは、通常は入力キューに対応付けられた 4 つのしきい値が用意されています。 通常、出力キュー用には、2 つのしきい値が設定されています。

また、QoS 上、これらのしきい値は、さまざな優先順位を持ったフレームを割り当てる手段としても配置されています。 バッファが充満し始めるおよびしきい値が超えられると同時に、管理者は帯が廃棄する必要があるスイッチに示す異なるしきい値にしきい値が超過するとき異なる優先順位をマッピング することができます。

マッピング

上記のキューおよびしきい値セクションではバッファのどんなポイント置くどのキューにいっぱいになることが廃棄されるべきフレーム 適格なであるかイーサネットフレームの CoS 値がにかフレームをおよび判別するのに使用されていることが述べられました。 これがマッピングの目的です。

Catalyst 6000 ファミリで QoS が設定されている場合は、デフォルト マッピングがイネーブルになり、次のことが定義されます。

  • ある CoS 値を持ったフレームが廃棄されるようになるしきい値

  • フレームが配置されるキュー(CoS 値が基準)

デフォルト マッピングがある場合、管理者はそれらのマッピングを上書きできます。 次のための存在をマッピング すること:

  • DSCP 値への着信 フレームの CoS 値

  • DSCP 値への着信 フレームの IP 優先順位値

  • 発信 フレームのための CoS 値への DSCP 値

  • 受信キューのドロップしきい値への CoS 値

  • 送信キューのドロップしきい値への CoS 値

  • ポリシング文を超過する帯の DSCP マークダウン値

  • 特定の宛先MAC アドレスとのフレームへの CoS 値

WRED およびWRR

WRED と WRR は、Catalyst 6000 ファミリに搭載されている 2 つのきわめて強力なアルゴリズムです。 WRED および WRR は両方拡張 な 緩衝域管理および送信スケジューリングを提供するのにイーサネットフレームの中のプライオリティ タグ(CoS)を使用します。 B

WRED

WRED は、Catalyst 6000 ファミリで使用されているバッファ管理アルゴリズムであり、輻輳発生時の、高優先度トラフィック廃棄への影響を最小限にするものです。 WRED は、RED アルゴリズムをベースとしています。

RED および WRED を理解するために、TCP フロー管理の概念に再アクセスして下さい。 フロー管理は TCP 送信側がネットワークを圧倒しないようにします。 TCP スロースタート アルゴリズムは、これに対する解決策の一環です。 確認応答を待っている前にフローが開始するとき、シングルパケットは送信 されることを定めます。 さらに、ACK を受信する前にパケットを 2 つ送信します。こうして、段階的に各 ACK を受信する前に送信するパケットの数を増やして行きます。 輻輳を発生させるような負荷なしでネットワークで処理できる送信レベルに達するまで、これが続けられます(つまり x 個のパケットが送信されます)。 従って輻輳が発生する場合、スロースタートのアルゴリズムは支持しまウィンドウ サイズを(すなわち、パケットの数は確認応答を待っている前に送信 しま)絞りま、その TCP セッション(フロー)のための全体的なパフォーマンスを低下させます。

RED は、キューの開始から、満杯になるのを監視します。 あるしきい値を超過すると、パケットはランダムに廃棄され始めます。 点は特定のフローに与えられません; むしろ、ランダム パケットは廃棄されます。 これらのパケットは、高優先度のフローである場合も、低優先度のフローの場合もあります。 破棄された パケットはシングルフローまたは複数の TCP フローの一部である場合もあります。 複数のフローが、上記されているように影響を与えられれば、これは各フロー ウィンドウ サイズのかなり影響がある場合があります。

RED とは異なり、WRED では、ランダムなフレームの廃棄は行われません。 WRED では、フレームの優先順位が考慮されます(Catalyst 6000 ファミリでは、CoS 値が使用されます)。 WRED では、管理者が、ある CoS 値を持つフレームを特定のしきい値に割り当てます。 これらのしきい値を超過すると、そのしきい値にマップされた CoS 値を持つフレームは廃棄対象になります。 より高いしきい値に割り当てられた CoS 値を持つフレームは、キューの中で維持されます。 この処理により、高い優先順位を持つフローはそのまま保持され、その大きなウィンドウ サイズもそのまま維持されます。送信元から受信先へ送られるパケットの遅延も最小限に留まります。

ラインカードが WRED をサポートするかどうかどのようにしてわかりますか。 次のコマンドを発行して下さい。 そのポートの WRED のためのサポートを示す出力では、セクションがあるように確認して下さい。

 
Console> show qos info config 2/1 
QoS setting in NVRAM: 
QoS is enabled 
Port 2/1 has 2 transmit queue with 2 drop thresholds (2q2t). 
Port 2/1 has 1 receive queue with 4 drop thresholds (1q4t). 
Interface type:vlan-based 
ACL attached: 
The qos trust type is set to untrusted. 
Default CoS = 0 
Queue and Threshold Mapping: 
Queue Threshold CoS 
----- --------- --------------- 
1     1         0 1 
1     2         2 3 
2     1         4 5 
2     2         6 7 
Rx drop thresholds: 
Rx drop thresholds are disabled for untrusted ports. 
Queue #  Thresholds - percentage (abs values) 
-------  ------------------------------------- 
1        50% 60% 80% 100% 
TX drop thresholds: 
Queue #  Thresholds - percentage (abs values) 
-------  ------------------------------------- 
1        40% 100% 
2        40% 100% 
TX WRED thresholds: 
WRED feature is not supported for this port_type.
!-- Look for this.
Queue Sizes: 
Queue #  Sizes - percentage (abs values) 
-------  ------------------------------------- 
1        80% 
2        20% 
WRR Configuration of ports with speed 1000MBPS: 
Queue #  Ratios (abs values) 
-------  ------------------------------------- 
1        100 
2        255 
Console> (enable)

WRED がポートで利用できなければ、ポートは緩衝域管理のテール ドロップ 方式を使用します。 テール ドロップ方式とは、その名前が示しているように、バッファが完全に使用中の状態になったときに、着信したフレームを単純に廃棄するというものです。

WRR

WRR は、Tx キューからの出力トラフィックのスケジューリングに使用されます。 正常なラウンドロビンアルゴリズムはからの次のキューへパケット移行する前にの等しい 番号を各キュー 送信 する TX キューの間で交互になります。 WRR の重み付け機能により、キューに適用されている重みの値をチェックするスケジューリング アルゴリズムが実現されます。 これによって、定義されたキューが帯域幅をより多く使用できるようになります。 WRR スケジューリング アルゴリズムでは、指定したキューで、他のキューよりも多くのデータを空にすることができます。これによって、選択したキューを優先することができます。

上述されていたものがの WRR のための設定および他の側面は以降のセクションで説明されます。

Catalyst 6000 ファミリー上でポートASIC ベースのQoS を設定する方法

QoS の設定により、ポート ASIC あるいは PFC に対して QoS アクションの実行が指示されます。 次のセクションでは、これら両方の処理に対する QoS の設定について説明します。 ポート ASIC の場合、QoS の設定は、着信トラフィックと発信トラフィックの両方に影響します。

上記のダイアグラムから、次の QoS コンフィギュレーションプロセスが適用することが見られる場合があります:

    1. ポートの信頼状態

    2. ポート ベースの CoS の適用

    3. Rx 側の廃棄しきい値の割り当て

    4. Rx ドロップしきい値マップへの CoS

フレームが MSFC または PFC で処理される場合、フレームはその後の処理のために発信側のポート ASIC に渡されます。 MSFC によって処理されたどの帯でもゼロに設定し直された CoS 値があります。 これは、発信側ポートでの QoS 処理を受けるために必要です。

上の図は、ポート ASIC によって発信トラフィックに対して行われる QoS の処理を表しています。 発信側での QoS 処理で実行される処理には、次のようなものがあります。

    1. TX 側のテール ドロップおよび WRED しきい値の割り当て

    2. TX テール ドロップおよび WRED マップへの CoS

また、上記のダイアグラムで示されていなくて、送信フレームへ CoS を割当て直すことのプロセスは CoS マップに DSCP を使用してです。

次のセクションでは、ポート ベース ASIC の QoS 設定機能を、さらに詳しく検証します。

注: 作るべき重要な点は Qos コマンドが CatOS を使用して呼び出されるとき、規定 された キュータイプが付いているすべてのポートに一般的に適用することです。 たとえば、WRED ドロップ しきい値がキュータイプ 1p2q2t が付いているポートに加えられれば、この WRED ドロップ しきい値はこのキュータイプをサポートするすべてのラインカードのすべてのポートに加えられます。 IOS を使用している場合は、通常は QoS コマンドはインターフェイス レベルで適用されます。

QoS の有効化

どの QOS 設定でも Catalyst 6000 ファミリーで起こることができる前に QoS はスイッチで最初に有効に する必要があります。 これを行うには、次のコマンドを発行します。

CatOS

 
Console> (enable) set qos enable
!-- QoS is enabled.
Console> (enable)

Integrated Cisco IOS (Native Mode)

 
Cat6500(config)# mls qos

Catalyst 6000 ファミリで QoS をイネーブルにすると、そのスイッチでは、一連の QoS デフォルト値に設定されます。 これらのデフォルトには次の設定が含まれます。

信頼されるポートと信頼されないポート

Catalyst 6000 ファミリーのある特定のポートは信頼されるで設定することができますまたはそれとしてどのようにフレームを示し、分類し、スケジュールするか信頼できないポート命令の信頼 状態はスイッチを通過します。 デフォルトで、すべてのポートは信頼できない状態にあります。

信頼できないポート(ポートのデフォルト設定)

ポートが信頼できないポートとして設定されている場合、フレームが最初にポートに着信した時点で、そのフレームの CoS 値と ToS 値はポート ASIC によってゼロにリセットされます。 これは、このフレームがスイッチを通過するパスでは、最低の優先順位のサービスが与えられることを意味します。

また、管理者は前もって決定された値に信頼できないポートを入力するあらゆるイーサネットフレームの CoS 値をリセットできます。 これの設定以下のセクションで説明されています。

ポートを信頼できないとして設定することは、スイッチには輻輳回避を何も行わないように指示することになります。 輻輳回避はそのキューのために定義されるしきい値を超過すれば CoS 値に基づいて帯を廃棄するのに使用される方式です。 このポートを入力するすべての帯は均等にバッファが 100%達すれば廃棄される資格があります。

CatOS では、10/100 または GE ポートは信頼できないで次のコマンドの発行によって設定することができます:

CatOS

 
Console> (enable) set port qos 3/16 trust untrusted
!-- Port 3/16 qos set to untrusted. 
Console> (enable)

このコマンドでは、モジュール 3 のポート 16 を信頼できないとして設定します。

注: Integrated Cisco IOS (Native Mode)に関しては、ソフトウェアは現在 GE ポートのための設定信頼しかサポートしません。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config)# interface gigabitethernet 1/1 
Cat6500(config-if)# no mls qos trust

上述の例では、それが IOS であるので信頼できないのでインターフェイスコンフィギュレーションを入力し、ポートを設定 するためにコマンドの no 形式を加えます。

信頼できるポート

時々、スイッチに入るイーサネットフレームはフレームがスイッチを通過すると同時に管理者がスイッチに維持してほしいこと CoS または TOS 設定を備えています。 このトラフィックの場合、管理者はそのトラフィックが信頼されるようにスイッチに到達するポートの信頼 状態を設定できます。

上記されるように、スイッチはそのフレームにサービスの前もって決定されたレベルを指定するのに DSCP 値を内部で使用します。 フレームが信頼できるポートを入力するので、管理者は既存の CoS、IP 優先順位、または内部DSCP値を設定 するために DSCP 値を検知 するようにポートを設定できます。 また、管理者は各パケットにポートを入力するあらかじめ定義された DSCP を設定できます。

ポートの信頼状態を信頼できると設定するには、次のコマンドを使用します。

CatOS

 
Console> (enable) set port qos 3/16 trust trust-cos
!-- Port 3/16 qos set to trust-COs
Console> (enable)

このコマンドは、WS-X6548-RJ45 ラインカードに適用され、ポート 3/16 の信頼状態を信頼できるとして設定します。 このスイッチでは、着信フレームで設定されている CoS 値の設定を使用して、内部 DSCP が設定されます。 DSCP 値は、そのスイッチで QoS がイネーブルにされたときに作成されたデフォルト マップか、管理者によって定義されたマップから取得されます。 CoSを信用するキーワードの代わりに、管理者はまた trust-dscp か trust-ipprecキーワードを使用できます。

以前の 10/100 ラインカード(WS-X6348-RJ45 および WS-X6248-RJ45)の場合は、set qos acl コマンドを実行して、ポートの信頼状態を設定する必要があります。 このコマンドでは、信頼 状態は set qos acl コマンドの補助的なパラメータによって割り当てることができます。 また、これらのラインカードでは、次に示すとおり、trust CoS というポート設定はサポートされていません。

 
Console> (enable) set port qos 4/1 trust trust-COs
Trust type trust-COs not supported on this port.
!-- Trust-COs not supported, use acl instead.
Rx thresholds are enabled on port 4/1. 
!-- Need to turn on input queue scheduling.
Port  4/1 qos set to untrusted. 
!-- Trust-COs not supported, so port is set to untrusted.

上記のコマンドでは、入力キューのスケジューリングをイネーブルにする必要があります。 そのため、WS-X6248-RJ45 および WS-X6348-RJ45 ラインカードの 10/100 ポートの場合は、信頼状態の設定にも set port qos x/y trust trust-COs コマンドを設定して、ACL を使用する必要があります。

統合 Cisco IOS(ネイティブ モード)の場合は、新しい WS-X6548-RJ45 ラインカードの GE インターフェイスおよび 100/100 ポートに信頼状態を設定できます。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config)# interface gigabitethernet 5/4 
Cat6500(config-if)# mls qos trust ip-precedence 
Cat6500(config-if)#

この例では、GE ポート 5/4 の信頼状態を信頼できると設定しています。 DSCP 値の決定には、フレームの IP 優先順位値が使用されます。

入力分類および設定ポートベースのCoS

イーサネット フレームがスイッチのポートに着信したとき、次の 2 つの基準のいずれかを満たしている場合は、このフレームの CoS を変更できます。

    1. ポートが信頼できないとして設定されている

    2. そのイーサネット フレームに CoS 値が設定されていない

着呼イーサネットフレームの CoS を再構成したい場合次のコマンドを発行する必要があります:

CatOS

 
Console> (enable) set port qos 3/16 cos 3
!-- Port 3/16 qos set to 3. 
Console> (enable)

このコマンドは、モジュール 3 のポート 16 に着信したイーサネット フレームの CoS を、フレームに CoS の設定がない場合や、ポートが信頼できないと設定されていた場合に、3 という値に設定します。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config)# interface fastethernet 5/13 
Cat6500(config-if)# mls qos COs 4
Cat6500(config-if)#

このコマンドは 4 という値にマークされていないフレームが到着するときまたはポートが信頼できないに設定 されれば モジュール 5 のポート 13 の着呼イーサネットフレームの CO を設定 します。

Rx ドロップしきい値の設定

フレームは、スイッチのポートに着信すると、Rx キューに置かれます。 バッファのオーバーフローを防ぐために、ポート ASIC には各 Rx キューに 4 つのしきい値が実装されており、これらのしきい値により、超過時に廃棄するフレームが決定されます。 ポート ASIC では、フレームにセットされた CoS 値を使用して、しきい値の超過が生じたときに廃棄するフレームを決定します。 この機能によって、輻輳が発生したときには、優先順位が高いフレームほど、バッファに長く留まるようになります。

上記のダイアグラムに示すように、帯はキューに到着し、置かれます。 キューが充満し始めると同時にしきい値はポート ASIC によって監察されます。 しきい値に達すると、管理者が特定した CoS 値を持つフレームは、キューからランダムに廃棄されます。 1q4t キュー(WS-X6248-RJ45 および WS-X6348-RJ45 ラインカードで使用されるキュー)に対するデフォルトのしきい値マッピングは、次のとおりです。

  • しきい値 1 は 50% に設定 され、CO 値 0 および 1 はこのしきい値にマッピング されます
  • しきい値 2 は 60% に設定 され、CO 値 2 および 3 はこのしきい値にマッピング されます
  • しきい値 3 は 80% に設定 され、CO 値 4 および 5 はこのしきい値にマッピング されます
  • しきい値 4 の設定は 100 %、CoS の値 6 および 7 がこのしきい値にマップされる

1P1q4t (GE ポートで見つけられる)キューに関しては、デフォルトマッピングは次の通りです:

  • しきい値 1 は 50% に設定 され、CO 値 0 および 1 はこのしきい値にマッピング されます
  • しきい値 2 は 60% に設定 され、CO 値 2 および 3 はこのしきい値にマッピング されます
  • しきい値 3 の設定は 80 %、CoS の値 4 がこのしきい値にマップされる
  • しきい値 4 の設定は 100 %、CoS の値 6 および 7 がこのしきい値にマップされる
  • 5 という CO 値は完全優先キューにマッピング されます

1p1q0t に関しては(WS-X6548-RJ45 ラインカードのポート 10/100 ので見つけられる)、デフォルトマッピングは次の通りです:

  • CO 5 の帯は SP Rx キュー(2) キューに SP 受信キュー バッファが 100%完全時だけスイッチが着信 フレームを廃棄するところ、行きます。
  • CO 0、1、2、3、4、6、か 7 の帯は Rx 標準キューに行きます。 この場合、Rx キューのバッファの使用率が 100 % に達したときに着信フレームが廃棄されます。

これらの廃棄しきい値は、管理者が変更することもできます。 また、各しきい値にマッピング されるデフォルト CO 値はまた変更することができます。 さまざまなラインカードは異なる Rx キュー 実装を設定します。 キュータイプの概略は下記に表示されます。

CatOS

 
Console> (enable) set qos drop-threshold 1q4t rx queue 1 20 40 75 100
!-- Rx drop thresholds for queue 1 set at 20%, 40%, 75%, and 100%.
Console> (enable)

このコマンドでは、1 つのキューと 4 つのしきい値を持つ入力ポート(1q4t)すべての受信廃棄しきい値を、20 %、40 %、75 %、および 100 % に設定しています。

統合 Cisco IOS(ネイティブ モード)では、次のコマンドを実行します。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config-if)# wrr-queue threshold 1 40 50 
Cat6500(config-if)# wrr-queue threshold 2 60 100 

!-- Configures the 4 thresholds for a 1q4t rx queue and.

Cat6500(config-if)# rcv-queue threshold 1 60 75 85 100

!-- Configures for a 1p1q4t rx queue, which applies to 
!-- the new WS-X6548-RJ45 10/100 line card.

Rx の廃棄しきい値は、管理者がイネーブルにする必要があります。 現在(x がモジュール番号であり、y がそのモジュールのポートであるかところで)、set port qos x/y trust trust-cos コマンドが Rx ドロップしきい値をアクティブにするのに使用する必要があります。

Tx ドロップしきい値の設定

出力ポートでは、輻輳回避メカニズムの一部として、キュー 1 とキュー 2 という 2 つの Tx しきい値が使用されます。キュー 1 は標準の低優先キュー、キュー 2 は標準の高優先キューになります。 使用されたラインカードによっては彼らはテール ドロップか WRED しきい値管理 アルゴリズムを用います。 アルゴリズムは両方とも各 TX キューのための 2 つのしきい値を用います。

管理者は、これらのしきい値を次のように設定できます。

CatOS

 
Console> (enable) set qos drop-threshold 2q2t TX queue 1 40 100
!-- TX drop thresholds for queue 1 set at 40% and 100%.
Console> (enable)

このコマンドでは、2 つのキューと 2 つのしきい値(2q2t)を持つすべての出力ポートのキュー 1 の Tx 廃棄しきい値を、40 % および 100 % に設定しています。

 
Console> (enable) set qos wred 1p2q2t TX queue 1  60 100
!-- WRED thresholds for queue 1 set at 60% 100% on all WRED-capable 1p2q2t ports.
Console> (enable)

このコマンドでは、1 つの SP キューと 2 つの通常キューと 2 つのしきい値(1p2q2t)を持つすべての出力ポートのキュー 1 の WRED 廃棄しきい値を、60 % および 100 % に設定しています。 キュー 1 は通常の低優先キューとして定義されており、その優先順位は最低になります。 キュー 2 は通常の高優先キューであり、キュー 1 よりも高い優先順位を持ちます。キュー 3 は SP キューであり、そのポートでは他のどのキューよりも先にサービスを受けます。

統合 Cisco IOS(ネイティブ モード)では、これと同等のコマンドを次のように実行します。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config-if)# wrr-queue random-detect max-threshold  1 40 100
Cat6500(config-if)#

これにより、1p2q2t ポートのキュー 1 の WRED 廃棄しきい値として、しきい値 1(Tx)が 40 %、しきい値 2(Tx)が 100 % に設定されます。

統合 Cisco IOS(ネィティブ モード)では、WRED を必要に応じてディセーブルにすることもできます。 ディセーブルにするには、このコマンドの no 形式を使用します。 WRED をディセーブルにする例は次の通り示されています:

Integrated Cisco IOS (Native Mode)

 
Cat6500(config-if)# no wrr-queue random-detect queue_id

CO 値への MAC アドレスをマッピング すること

グローバル な ポート 定義に基づいて CO の設定に加えてスイッチは管理者が宛先MAC アドレスおよび VLAN ID に基づいて CO 値を設定 することを可能にします。 これは前もって決定された CO 値とタグ付けされるべき特定のターゲットに向かう帯を可能にします。 この設定には、次のコマンドを実行します。

CatOS

 
Console> (enable) set qos Mac-COs 00-00-0c-33-2a-4e 200 5
!-- COs 5 is assigned to 00-00-0c-33-2a-4e VLAN 200.
Console> (enable)

このコマンドでは、宛先 MAC アドレスが 00-00-0c-33-2a-4e で、VLAN 200 から送られたフレームすべてに対して、CoS として 5 を設定しています。

統合 Cisco IOS(ネイティブ モード)には、これに相当するコマンドはありません。 これは、このコマンドは PFC がまだ存在しなかった時期に限ってサポートされていたものであり、統合 Cisco IOS(ネイティブ モード)では実行に PFC を必要とするためです。

しきい値への CO をマッピング すること

しきい値が設定された後、管理者はこれらのしきい値にしきい値が超過したら、特定 の CoS 値を用いる帯が廃棄することができるようにそれから CO 値を割り当てることができます。 通常は、低い優先順位を持つフレームを低いしきい値に割り当てるため、輻輳が発生したときには高い優先順位を持つトラフィックがキュー内に維持されます。

上の図では、4 つのしきい値を持つ入力キューと、CoS 値がどのように各しきい値に割り当てられたかが示されています。

次の出力では、CoS 値がどのようにしきい値に割り当てられるかが示されています。

CatOS

 
Console> (enable) set qos map 2q2t 1 1 COs 0 1 
!-- QoS TX priority queue and threshold mapped to COs successfully.
Console> (enable)

このコマンドは 1 を並べるために 0 および 1 という CO 値をしきい値 1.割り当てます。 Integrated Cisco IOS (Native Mode)の相当するコマンドは下記に示されています。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config-if)# wrr-queue COs-map  1  1  0  1 
Cat6500(config-if)#

Tx キューの帯域幅の設定

フレームが出力キューに配置された場合、そのフレームは出力スケジューリング アルゴリズムを使用して送信されます。 この出力スケジューラの処理では、フレームを出力キューから送信するために WRR が使用されます。 使用されるラインカード ハードウェアによってはポート毎に 2 つ、3 つ、か 4 つの送信キューがあります。

WS-X6248 および WS-X6348 ラインカード(キュー構造は 2q2t)では、WRR メカニズムによって 2 つの Tx キューがスケジューリングに使用されます。 WS-X6548 ラインカード(キュー構造は 1p3q1t)には、4 つの Tx キューがあります。 この 4 つの TX キューの、3 つの TX キューは WRR アルゴリズムによって保守されます(最後の TX キューは SP キューです)。 GE ラインカードで、3 つの TX キューがあります(1p2q2t キュー 構造を使用して); これらのキューの 1 つはそう SP キュー WRR アルゴリズム唯一にサービス 2 つの TX キューです。

通常、管理者は Tx キューに重みを割り当てます。 WRR は、ポートのキューに割り当てられた重みを調べて動作します。この重みはスイッチの内部において、次のキューに移る前に、どれだけのトラフィックが送信されるかを判断するために使用されます。 1 および 255 間のというウエイト設定値はポートキューのそれぞれに割り当てることができます。

CatOS

 
Console> (enable) set qos wrr 2q2t 40 80 
!-- QoS wrr ratio set successfully.
Console> (enable)

このコマンドは 1 および 2.を並べるために 80 を並べるように 40 のウエイト設定を割り当てます。 これは効果的に 2 つから 1 つの比率(80 に 40 = 帯域幅の 2 つのキューの間で割り当てられる 1)への 2 を意味します。 このコマンドは、2 つのキューと 2 つのしきい値を持つすべてのポートに有効です。

統合 Cisco IOS(ネイティブ モード)では、これと同等のコマンドを次のように実行します。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config-if)# wrr-queue bandwidth 1 3
Cat6500(config-if)#

ここでは、2 つのキュー間の 3 対 1 の比率が示されています。 このコマンドの Cisco IOS バージョンは、特定の 1 つのインターフェイスだけに適用されます。

DSCPからCOsへのマッピング

フレームが出力ポートに置かれると、ポート ASIC により、割り当てられた CoS を使用して、輻輳回避(つまり WRED)が実行されます。さらに、その CoS を使用して、フレームのスケジューリングが決定されます(フレームの送信)。 この時点で、スイッチはデフォルトマップを割り当てられた DSCP を奪取 し、CO 値に戻ってそれをマッピング するのに使用します。 デフォルトのマップはこの表で示されています。

また、管理者は割り当てられた内部DSCP値を奪取 し、フレームの新しい CO 値を作成するのにスイッチによって使用するマップを作成できます。 これを実現させるのに CatOS および Integrated Cisco IOS (Native Mode)をどのようにの使用するか例は下記に示されています。

CatOS

 
Console> (enable) set qos dscp-cos--map 20-30:5 10-15:3 45-52:7 
!-- QoS dscp-cos-map set successfully.
Console> (enable)

上のコマンドは 5 という CO 値に 30 に DSCP 値 20 を、への DSCP 値 10 〜 15 3 の CO マッピング し、DSCP は 7.という CO 値に 52 に 45 をしかし評価します。 他の DSCP 値はすべて QoS がスイッチで有効に なったときに作成されるデフォルトマップを使用します。

統合 Cisco IOS(ネイティブ モード)では、これと同等のコマンドを次のように実行します。

Integrated Cisco IOS (Native Mode)

 
Cat6500(config)# mls qos map dscp-cos 20 30 40 50 52 10 1 to 3
Cat6500(config)#

ここでは、DSCP 値の 20、30、40、50、52、10、および 1 が CoS 値の 3 に設定されています。

PFC の分類およびポリシング

PFC では、フレームの分類とポリシングがサポートされています。 分類は(マーク)優先順位(DSCP)によって着信 フレームを割り当てるのに ACL を使用できます。 またポリシングを行うことで、トラフィックの流れを帯域幅の一定量に制限できます。

次のセクションでは、この PFC の機能について、CatOS と統合 Cisco IOS(ネィティブ モード)の両 OS プラットフォームの観点から説明します。 PFC によって実行される処理を次の図に示します。

CatOS を実行するCatalyst 6000 ファミリーのポリシングの設定

ポリシングの機能は、CatOS と統合 Cisco IOS(ネィティブ モード)の 2 つのセクションに分けて説明します。 両方ともさまざまな方法で同じ最終結果を実現させが、設定され、設定されます。

ポリシング

PFC では、スイッチに着信したトラフィックのレート制限(またはポリシング)を行って、トラフィックのフローを事前に定義した制限まで減らすことができる機能をサポートしています。 この制限を超えたトラフィックは、廃棄されるか、フレームの DSCP 値が低い値にマークダウンされます。

出力側のレート制限については、現在は PFC1 と PFC2 のどちらにおいてもサポートされていません。 2002 年の後半に予定されている、出力ポリンシングをサポートする PFC の新しいリビジョンでは、この機能が追加される予定です。

ポリシングは、CatOS と新しい統合 Cisco IOS(ネイティブ モード)の両方でサポートされていますが、機能の設定方法は大きく異なっています。 次のセクションでは、両方の OS プラットフォームでのポリシングの設定について説明します。

集計および Microflow (CatOS)

集計および Microflow は PFC が行うポリシングのスコープを定義するのに使用される用語です。

microflow はシングルフローのポリシングを定義します。 フローはユニークな SA/DA MAC アドレス、SA/DA IP アドレスおよび TCP/UDP ポート番号とのセッションによって定義されます。 各々の新しいフローの場合 VLAN のポートを通して始められる、microflow がスイッチによってそのフローのために受け取ったデータの量を制限するのに使用することができます。 microflow 定義では、所定のレート リミットを廃棄することができる超過するまたはマークダウンされる DSCP 値がありますパケットに。

マイクロフローと同様に、集約も、トラフィックをレート制限するために使用できます。 ただし、集約 レートは規定 された QoS ACL と一致するポートか VLAN で受信すべてのトラフィックに適用します。 集約は、Access Control Entry(ACE; アクセス コントロール エントリ)のプロファイルに一致する累積的なトラフィックのポリシングであると見なすことができます。

集約および microflow は両方スイッチに受け入れることができるトラフィック量を定義します。 集約および microflow は両方ポートか VLAN に同時に割り当てることができます。

マイクロフローを定義するときには最大 63 件まで、また集約は 1023 件まで定義できます。

アクセス制御エントリおよび QoS ACL (CatOS)

PFC が着信 フレームを処理するのに使用することを QoS ACL は一組の QoS を定義する ACE のリストで支配します構成されています。 エースは Router Access Control List (RACL)に類似したです。 ACE では、着信フレームに対する分類、マーキング、ポリシングの基準を定義します。 着信 フレームが ACE で設定 される条件を満たす(ACE によって考えられる)場合 QoS エンジンはフレームを処理します。

すべての QoS 処理はハードウェアで実行されます、従って QoS ポリシングを有効に することはスイッチのパフォーマンスに影響を与えません。

現在、PFC2 では、最大 500 の ACL をサポートしています。また、その ACL は最大 32000 の ACE(総計)で構成できます。 実際の ACE 数は定義されたその他のサービスおよび PFC の利用可能なメモリによって異なります。

定義できる ACE には 3 つのタイプがあります。 これらは IP、IPX、および MAC です。 IP および IPX 両方エースは MAC がエース Inspect L2 ヘッダー情報だけ基づかせていた一方、L3 ヘッダー情報を点検します。 MAC エースが非 IP および非IPXトラフィックにしか加えることができないことにまた注意する必要があります。

ポリシング ルールの作成

ポリシング ルールを作成するには、集約(またはマイクロフロー)を作成した後、この集約(またはマイクロフロー)を ACE にマップする処理が必要です。

、たとえば、要件が 20 MB の最大にポート 5/3 のすべての着信IPトラフィックを制限すること上記される 2 つのステップは設定する必要があります。

最初に、例はすべての着信IPトラフィックを制限されるように要求します。 これは、集約ポリサーを定義する必要があることを意味しています。 これの例は次の通りであるかもしれません:

 
Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13 policed-dscp  
!-- Hardware programming in progress?
!-- QoS policer for aggregate test-flow created successfully.
Console> (enable)

ここでは、test-flow という集約を作成しました。 それは 20000 KBPS (20MBPS)および 13 のバーストの比率を定義します。 policed-dscp キーワードはこのポリシーを超過するどのデータでも DSCP マークダウンマップで指定どおりにマークダウンされた DSCP 値があることを示します(デフォルト 1 は管理者によって存在またはこれ修正することができます)。 policed-dscp キーワードの使用への交替はドロップする キーワードを使用することです。 キーワード drop を定義すると、プロファイル外のトラフィック(割り当てられているバースト値を外れたトラフィック)は単純に廃棄されます。

ポリシング機能は、リーキー トークン バケット方式で動作しています。この方式では、まずバースト(所定の時間間隔内で受容できるデータの総量をビット/秒で定義したもの)を定義し、さらにレート(1 秒間にバケットを空にできるデータの総量を定義したもの)を定義します。 どのデータでもこのバケットを廃棄されるオーバーフロー するまたはマークダウンされる DSCP があります。 上で説明した所定の時間間隔とは、0.00025 秒(1/4000 秒)で固定されています(つまり、この数値を変更するコマンドは使用できません)。

上の例で使用されている値 13 は、1/4000 秒ごとに最大 13,000 ビットのデータを受容できるバケットを意味しています。 これは毎秒に換算すると、52 MB(13K ×((1 / 0.00025)あるいは 13K × 4000)になります。 設定するバースト値を送出するデータのレートと同等か、それ以上に設定する必要があることには、常に注意してください。 すなわち、バーストはある特定の期間の間送信したいデータの最低要量に等しい、 またはそれ以上であるはずです。 比率として規定 したものをにバーストがより低い図という結果に終れば、レートリミットはバーストに匹敵します。 すなわち、15MBPS に計算する 20 MBPS およびバーストの比率を定義すれば、比率は 15MBPS にだけ到達します。 次に疑問となるのは、なぜバースト値が 13 であるかということでしょう。 バーストは、トークン バケットの深さ、つまり 1/4000 秒ごとの着信データの受信に使用されるバケットの深さを定義していることを思い出してください。 よって、バースト値は、1 秒間に 20 MB 以上の着信データ レートをサポートするいずれかの数値になります。 20 MB のレート制限に使用できる最小のバースト値は、20000 / 4000 = 5 になります。

ポリサーを処理する場合、トークン バケットがトークンでいっぱいになると、ポリシング アルゴリズムが始動します。 このトークン数は、バースト値と同じになります。 このようにバースト値が 13 なら、バケット等号 13,000 のトークンの数。 秒の各 1/4000th のために、ポリシングアルゴリズムは 4000 で割ることによって求められた定義された レートと等しいデータの量を送信します。 データの各ビット(2 進数字送信 される)に関しては、それはバケットからの 1 トークンを消費します。 間隔の終わりに、それは新しい一組のトークンのバケットを補充します。 取り替えるトークンの数は比率/4000 によって定義されます。 上述の例をこれを理解するために参照して下さい:

Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13

これが 100 MBPS ポートであり、ポートに 100 MBPS の一定したストリームで送信 して いることを仮定して下さい。 これは、100,000,000 ビット/秒の着信レートに相当します。 ここのパラメータは 20000 の比率および 13 のバーストです。 タイムインターバル t0、(13,000 の)のトークンの全 必要量がバケットあります。 タイムインターバル t0 で、最初のデータセットをポートに着いてもらいます。 このタイムインターバルに関しては、着信速度は 100,000,000/4000 = 25,000 ビット/秒です。 トークンバケットに 13,000 のトークンの深度があるただので、この間隔のポートに着く 25,000 ビットの 13,000 ビットだけが送信のために適格で、12,000 ビットが廃棄される。

指定したレートでは、20,000,000 ビット/秒のフォワーディング レートを定義しています。これは 1/4000 秒に換算すると 5,000 ビットになります。 送信される 5,000 ビット毎にに関しては消費される 5,000 のトークンがあります。 タイムインターバル T1 で、データのもう 25,000 ビットは着きますが、バケットは 12,000 ビットを廃棄します。 バケットは、レートを 4000 で除した数のトークン(5,000 個の新しいトークン)で再度いっぱいになります。 そして、次の 5,000 ビットに相当するデータが送出され(新たに 5,000 トークンを消費)、これが各時間間隔ごとに繰り返されます。

基本的に、バケット の 深さ(定義されたバースト)以上来るどのデータでも廃棄されます。 データが(比率示される作る一致する)廃棄される送信 された後残っているデータ、次に到着データまたの設定 されるのための方法を。 不完全な パケットはポートに十分に受け取られるまでタイムインターバルの内で十分に廃棄されなかったり保存される受け取られなかったが、1 つです。

このバースト値は、トラフィックのフローが一定であると仮定しています。 ただし、現実の世界ネットワークで、データは一定していないし、フローは伝達の合併 TCP 確認応答が配列する TCP ウィンドウ サイズによって判別されます。 TCP ウィンドウ サイズの問題を考慮するには、バースト値を 2 倍にすることを推奨します。 上述の例では、推奨値の 13 は 26 で実際に設定されます。

もう 1 つの重要なポイントは、時間間隔 0(つまり、ポリシング サイクルの開始時点)で、トークン バケットはトークンでいっぱいになる点です。

現在、この集約ポリシーは QoS ACE に組み込む必要があります。 ACE は、着信フレームに対する一連の基準を満たすように、仕様を作成する場所です。 次の例について考えます。 上で定義した集約をすべての IP トラフィック、特にサブネット 10.5.x.x を発信元とし、サブネット 203.100.45.x を宛先とするトラフィックに適用するものとします。 このときの ACE は次のようになります。

 
Console> (enable) set qos acl ip test-acl trust-dscp aggregate test-flow tcp 10.5.0.0 203.100.45.0  
!-- Test-acl editbuffer modified. Issue the commit command to apply changes.
Console> (enable)

上記のコマンドでは、IP ACE(set qos acl ip コマンドを使用したことで判明)を作成し、test-acl という QoS ACL に関連付けています。 この後に作成されて ACL test-acl に関連付けられる ACE は、この ACE リストの末尾に追加されます。 ACE エントリには、集約 test-flow が関連付けられています。 10.5.0.0 のソース サブネットおよび 203.100.45.0 の宛先 サブネットのどの TCP フローでもそれに適用されたこのポリシーがあります。

ACL (および関連するエース)管理者が使用できる設定 の 柔軟性の非常に粒状レベルを提供します。 ACL は 1 つのまたはいくつかのエースで構成される場合がありソースをたどりますポリシングが行われるために必要となる特定フローを識別するのにおよび/または宛先アドレスが、また L4 ポート値使用することができます。

ただし、どのポリシングでも実際に発生する前に、ACL は物理ポートか VLAN にマッピング されなければなりません。

PFC2 ポリシングの決定

PFC2 に関しては、ポリシングのためのデュアル漏出バケットアルゴリズムをもたらした CatOS 7.1 および CatOS 7.2 の変更を行いました。 この新しいアルゴリズムにより、次に示す 2 つのレベルが新しく追加されました。

    1. 水平な正常なポリシング: これは最初のバケットに相当し、バケットの深さ(バースト)とバケットからデータが送出されるときのレート(レート)を指定するパラメータを定義します。
    2. 水平な過剰ポリシング: これは 2 番目のバケットに相当し、バケットの深さ(eburst)とバケットからデータが送出されるときのレート(erate)を指定するパラメータを定義します。

この処理が動作する方式は、最初のバケットにデータが入り始めるということになります。 PFC2 では、最初のバケットの深さ(バースト値)以下の着信データ ストリームを受け入れます。 データは最初のバケットからオーバーフロー するマークダウンすることができ、第 2 バケットに通じます。 2 番目のバケットでは、1 番目のバケットからオーバーフローしたデータを、eburst 値以下の着信レートで、受け入れることができます。 第 2 バケットからのデータはレートパラメータ引く erate パラメータによって定義される比率で送信 されます。 データはまた第 2 バケットからオーバーフロー するマークダウンされるか、または廃棄することができます。

デュアル漏出バケット ポリシング機能の例は次の通りです:

Console> (enable) set qos policer aggregate AGG1 rate 10000 policed-dscp erate 12000 drop burst 13 eburst 13

この例では、10 Mbps を超えるトラフィック レートを持つ集約 AGG1 を設定し、ポリシングした DSCP マップに基づいてマークダウンを行います。 erate(12 Mbps に設定)を超えるトラフィックは、キーワード drop が指定されているため、廃棄されます。

DFC イネーブルになったモジュールにアグリゲートポリサーを適用する方法

DFC 中央集中型フォワーディング エンジンの実装により、所定の VLAN のトラフィック統計を追跡することが可能になりました。 この処理は、集約ポリサーを VLAN に適用するために使用できます。

しかし DFC 対応 ラインカードで転送の決定はそのラインカードに配られます。 DFC は即時ラインカードのポートだけに気づき、他のラインカードのトラフィック移動に気づいていないです。 従ってアグリゲートポリサーが複数の DFC モジュールを渡るメンバーのポートがある VLAN に適用されれば、ポリシング機能は矛盾 した 結果を生むかもしれません。 これは、DFC で追跡するのはローカルのポートの統計値だけであり、他のラインカード上のポートの統計値は対象にされていないためです。 従って、DFC 対応 ラインカードのメンバーのポートとの VLAN に適用されたアグリゲートポリサーは DFC ラインカードだけである VLANポートのための定格制限値に DFC ポリシング トラフィックという結果に終ります。

DSCP マークダウンマップ(CatOS)

DSCP マークダウンマップはポリシング機能がマークダウン プロファイル外 の トラフィックにそれを廃棄するかわりに定義されるとき使用されます。 プロファイル外のトラフィックとは、定義されたバースト設定を超過したトラフィックです。

デフォルト DSCP マークダウンマップは QoS が有効に なるとき設定されます。 デフォルトのマークダウン マップは、前出のこの表で示しています。 管理者は、Command Line Interface(CLI; コマンドライン インターフェイス)で set qos policed-dscp-map コマンドを発行すると、デフォルトのマークダウン マップを変更できます。 次にこの例を示します。

Cat6500(config)# set qos policed-dscp-map 20-25:7 33-38:3

この例では、ポリシングされている DSCP マップを変更し、20 から 25 の DSCP 値を 7 に、33 から 38 の DSCP 値を 3 にマークダウンしています。

VLAN およびポート(CatOS)へのマッピング ポリシー

ACL を作成したら、その ACL を適用するポートまたは VLAN にマップする必要があります。

関係するコマンドの 1 つであり、あまり気付かれていないものに、すべての QoS をポート ベースにするデフォルトの QoS 設定があります。 VLAN に集約(か microflow を)適用する場合、そのポートが VLAN によって基づく QoS のために設定されなかったらポートに対する実施されません。

 
Console> (enable) set port qos 2/5-10 vlan-based  
!-- Hardware programming in progress ?
!-- QoS interface is set to vlan-based for ports 2/5-10.
Console> (enable)

VLANベース QoS へポートベース QoS を変更することはすぐにそのポートに割り当てられるすべての ACL を取り外しそのポートに VLAN によって基づく ACL を割り当てます。

ポート(または VLAN)への ACL をマッピング することは次のコマンドの発行によってされます:

 
Console> (enable) set qos acl map test-acl 3/5  
!-- Hardware programming in progress ?
!-- ACL test-acl is attached to port 3/5.
Console> (enable)

Console> (enable) set qos acl map test-acl 18  
!-- Hardware programming in progress ?
!-- ACL test-acl is attached to VLAN 18.
Console> (enable)

ポート(または VLAN)への ACL をマッピング することの後でさえも、ACL はまだ ACL がハードウェアに託されるまで実施されません。 このことについては、次のセクションで説明します。 この時点で、ACL は一時に編集しますメモリのバッファを常駐します。 ACL がこのバッファにある間は変更を加えることができます。

editbuffer に常駐する行なわれていない ACL を取除きたければ、rollback コマンドを発行します。 このコマンドにより、ACL がエディット バッファから削除されます。

 
Console> (enable) rollback qos acl test-acl 
!-- Rollback for QoS ACL test-acl is successful.
Console> (enable)

託す ACL (CatOS)

上で定義した QoS ACL を適用するには、この ACL がハードウェアにコミットされる必要があります。 コミット処理では、ACL が一時的なバッファから PFC ハードウェアにコピーされます。 PFC メモリに読み込まれると、この QoS ACL で定義されているポリシーが、ACE の条件を満たすすべてのトラフィックに適用されます。

設定の容易さに関しては、ほとんどの管理者は commit all コマンドを発行します。 ただし、編集バッファに現在常駐するかもしれない仕様 ACL (多数の 1)を託すことができます。 commit コマンドの例は下記に示されています。

 
Console> (enable) commit qos acl test-acl 
!-- Hardware programming in progress ?
!-- ACL test-acl is  committed to hardware.  
Console> (enable)

ポート(か VLAN)から ACL を取除きたければマップをクリアする必要がありますそのポート(か VLAN)に次のコマンドの発行によってその ACL を関連:

 
Console> (enable) clear qos acl map test-acl 3/5  
!-- Hardware programming in progress ?
!-- ACL test-acl is detached from port 3/5.
Console>(enable)

統合Cisco IOS (ネイティブモード) を実行するCatalyst 6000 ファミリーのポリシングの設定

ポリシングは統合 Cisco IOS(ネイティブ モード)でもサポートされています。 ただし、ポリシング機能の設定および実装はポリシーマップを使用して実現します。 各ポリシーマップはポリシーマップを構成するのに複数のポリシー クラスを使用し、これらのポリシー クラスはトラフィックフローの異なる型のために定義することができます。

ポリシー マップ クラスでは、フィルタリングの際に IOS ベースの ACL とクラス マッチ文を使用して、トラフィックをポリシングするかどうかが判定されます。 ポリシングを受けるトラフィックが識別されると、ポリシー クラスが集約またはマイクロフロー ポリサーを使用して、ポリシング用ポリシーをそのトラフィックに適用します。

次のセクションでは、統合 Cisco IOS(ネイティブ モード)でのポリシングの設定について、詳しく説明します。

集計および Microflow (Integrated Cisco IOS (Native Mode))

集計および microflow は PFC が行うポリシングのスコープを定義するのに使用される用語です。 CatOS の場合と同様に、統合 Cisco IOS(ネイティブ モード)でも集約とマイクロフローが使用されます。

microflow はシングルフローのポリシングを定義します。 フローはユニークな SA/DA MAC アドレス、SA/DA IP アドレスおよび TCP/UDP ポート番号とのセッションによって定義されます。 各々の新しいフローの場合 VLAN のポートを通して始められる、microflow がスイッチによってそのフローのために受け取ったデータの量を制限するのに使用することができます。 microflow 定義では、所定のレート リミットを廃棄することができる超過するまたはマークダウンされる DSCP 値がありますパケットに。 Microflow はポリシーマップ クラスの一部分になる police flow コマンドを使用して適用します。

統合 Cisco IOS(ネイティブ モード)でマイクロフロー ポリシングをイネーブルにするには、スイッチ上でグローバルにイネーブルにする必要があります。 これには、次のコマンドを実行します。

Cat6500(config)# mls qos flow-policing

Microflow ポリシングはまたトラフィックであるブリッジドトラフィックに適用することができますレイヤ 3 (L3) スイッチドではない。 スイッチでブリッジ トラフィックに対するマイクロフロー ポリシングがサポートされるようにするには、次のコマンドを実行します。

 
Cat6500(config)# mls qos bridged

このコマンドは、マルチキャスト トラフィックに対するマイクロフロー ポリシングもイネーブルにします。 マルチキャストトラフィックはそれに適用される microflow ポリサがある必要がある場合このコマンド(mls qos bridged)は有効に する必要があります。

マイクロフローと同様に、集約も、トラフィックをレート制限するために使用できます。 ただし、集約 レートは規定 された QoS ACL と一致するポートか VLAN で受信すべてのトラフィックに適用します。 集約は、定義されたトラフィック プロファイルに一致する累積的なトラフィックのポリシングであると見なすことができます。

統合 Cisco IOS(ネイティブ モード)では、次の 2 つの形式の集約を定義できます。

  • インターフェイス単位の集約ポリサー

  • 名前付き集約ポリサー

インターフェイス単位の集約は、ポリシー マップ クラスで police コマンドを発行することにより、個々のインターフェイスに適用されます。 これらのマップ クラスは、複数のインターフェイスにマップできますが、ポリサーは各インターフェイスに個別に適用されます。 名前付き集合はポートの集まりに加えられ、すべてのインターフェイスを渡るトラフィックを累積によってポリシングを行ないます。 名前付き集合は mls qos aggregate policer コマンドの発行によって加えられます。

マイクロフローを定義するときには最大 63 件まで、また集約は 1023 件まで定義できます。

作成しますポリシング ルール(Integrated Cisco IOS (Native Mode))を

ポリシング ルールを作成するには、ポリシー マップで集約(またはマイクロフロー)を作成した後、このポリシー マップをインターフェイスに関連付ける処理が必要です。

同じ例を CatOS のために作成されて参照して下さい。 要件は、ポート 5/3 に着信するすべての IP トラフィックを、最大 20 Mbps に制限することです。

最初に、ポリシーマップは作成する必要があります。 制限トラフィックと指名されるポリシーマップを作成して下さい。 これは、次のように実行します。

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)#

スイッチのプロンプトが変わり、マップ クラスを作成する設定モードに入ったことがすぐに分かります。 ポリシー マップには複数のクラスを含めることができることを思い出してください。 各クラスは異なるトラフィックストリームに適用することができるポリシー アクションの別個のセットが含まれています。

ここでは、着信トラフィックを 20 Mbps に制限するトラフィック クラスを作成します。 このクラス limit-to-20 を呼出します。 これは下記に示されています。

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)# class limit-to-20
Cat6500(config-pmap-c)#

再びプロンプトが変わり、マップ クラスを設定中であることが示されます(プロンプトの末尾に -c と表示されています)。 特定の着信トラフィックを一致するためにレートリミットを適用したいと思った場合 ACL を設定し、クラスネームにこれを適用できます。 ネットワーク 10.10.1.x から送信されるトラフィックに 20 MBPS 限界を適用したいと思う場合次の ACL を発行して下さい:

Cat6500(config)# access-list 101 permit ip 10.10.1.0  0.0.0.255 any

この ACL をこのクラス名に追加するには、次のようにします。

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)# class limit-to-20 access-group 101
Cat6500(config-pmap-c)#

クラス マップを定義すると、このクラスに個々のポリサーを定義できるようになり、 集約(キーワード police を使用)またはマイクロフロー(キーワード police flow を使用)を作成できます。 下記に示されているように集約を、作成して下さい。

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)# class limit-to-20 access-group 101
Cat6500(config-pmap-c)# police 20000000 13000 confirm-action transmit exceed-action drop
Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit
Cat6500(config)#

上記の class 文では、(police コマンド)で 20,000 K(20 Mbps)のレート制限を 52 Mbps(13000 × 4000 = 52 MB)のバースト値とともに設定しています。 トラフィックがプロファイルと一致し、定格制限値の内にある場合、操作はインプロファイル トラフィックを送信するために確認処理文によって設定 することです。 トラフィックがプロファイル外(すなわち、上述の例で 20 MB 限界)ならトラフィックを廃棄するために、exceed-action 文は設定 されます(すなわち、例で 20 MB 以上のすべてのトラフィックは廃棄されます)。

マイクロフローの定義には、同様の操作を行います。 レートリミットに 200 K それぞれにある特定のクラスマップを一致させたポートへのすべてのフローがほしいと思ったら、そのフローの設定は次に類似したです:

 
Cat6500(config)# mls qos flow-policing
Cat6500(config)# policy-map limit-each-flow
Cat6500(config-pmap)# class limit-to-200 
Cat6500(config-pmap-c)# police flow 200000 13000 confirm-action transmit exceed-action drop
Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit

DSCP マークダウンマップ

DSCP マークダウンマップはポリシング機能がマークダウン プロファイル外 の トラフィックにそれを廃棄するかわりに定義されるとき使用されます。 プロファイル外のトラフィックとは、定義されたバースト設定を超過したトラフィックです。

デフォルト DSCP マークダウンマップは QoS が有効に なるとき確立されます。 このデフォルト マークダウン マップはこの表で示されています。 CLI を使用して、set qos policed-dscp-map コマンドを発行すると、デフォルトのマークダウン マップを変更できます。 次にこの例を示します。

 

Cat6500(config)# mls qos map policed-dscp normal-burst 32 to 16

この例は 32 という DSCP 値が 16 という DSCP 値にマークダウンされることデフォルトによってポリシングが行われる DSCPマップへの修正を定義したものです。 定義されるこのポリシング機能のポートに関しては示されたバースト以上であるデータのブロックの一部 DSCP 値を 16 にマークダウンするこの DSCP のどの着信 データでも評価します。

VLAN およびポート(Integrated Cisco IOS (Native Mode))へのマッピング ポリシー

ポリシーを作成したら、そのポリシーを有効にするために、適用するポートまたは VLAN にマップする必要があります。 CatOS でのコミット処理とは異なり、統合 Cisco IOS(ネイティブ モード)には、これに相当する処理はありません。 ポリシーがインターフェイスにマップされると、そのポリシーは有効になります。 上記のポリシーをインターフェイスにマップするには、次のコマンドを使用します。

 
Cat6500(config)# interface fastethernet 3/5
Cat6500(config-if)# service-policy input limit-traffic

ポリシーが VLAN にマッピング される場合、VLAN の各ポートのために mls qos vlan-based コマンドのことを発行によって QoS が基づく VLAN であることに適用するために VLAN方針を希望することインターフェイスを知らせて下さい。

 
Cat6500(config)# interface fastethernet 3/5
Cat6500(config-if)# mls qos vlan-based
Cat6500(config-if)# exit
Cat6500(config)# interface vlan 100
Cat6500(config-if)# service-policy input limit-traffic

インターフェイス 3/5 を仮定することは 3/5 をインターフェイスさせるためにまた VLAN 100 に適用する加えられた VLAN 100 の一部、制限トラフィックと指名されたポリシーでした。

CatOS を使用するCatalyst 6000 ファミリーでの分類の設定

PFC には、L2、L3、および L4 ヘッダー情報を調べられる ACL を使用する、データの分類のサポートを導入されています。 SupI、か IA に関しては(PFC なしで)、分類はポートの信頼キーワードの使用に制限されます。

次のセクションでは、CatOS で PFC が分類に使用する QoS の設定要素について説明します。

DSCPマッピング(CatOS)への CO

スイッチにフレームが着信する際には、スイッチによってフレームに DSCP 値が設定されます。 ポートが信頼 された 状態にあり、管理者が CoSを信用するキーワードを使用したら場合、フレームの CO 値が設定がフレームのための DSCP 値が設定を判別するのに使用されます。 前述のように、スイッチはそれとしてフレームに通過します内部DSCP値に基づいてスイッチをサービスのレベルを指定できます。

初期の 10/100 モジュール(WS-X6248 および WS-X6348)では、このキーワードはサポートされていません。 それらのモジュールに関しては、それは推奨され着信 データの CO 設定を加えるのに ACL を使用します。

QoS をイネーブルにすると、スイッチではデフォルト マップが作成されます。 このマップは、CoS 値に基づいて設定される DSCP 値を指定するために使用されます。 このマップについては、前出のこの表で示しています。 また、管理者はユニークなマップを設定できます。 次にこの例を示します。

 
Console> (enable) set qos cos-dscp-map 20 30 1 43 63 12 13 8 
!-- QoS cos-dscp-map set successfully.
Console> (enable)

上記のコマンドでは、次のようなマップを設定しています。

COS 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

上記のマップが、実際のネットワークで使用されることはまずありませんが、このコマンドで実行できることの説明のために提示してあります。

DSCPマッピング(CatOS)への IP 優先順位

CoS から DSCP へのマッピングと同様に、フレームの DSCP 値を着信パケットの IP 優先順位の設定から決めることもできます。 これは、ポートが管理者によって信頼できると設定された場合にだけ行われ、これにはキーワード trust-ipprec を使用します。

QoS をイネーブルにすると、スイッチではデフォルト マップが作成されます。 このマップについては、前出のこの表で参照できます。 このマップは、IP 優先順位の値に基づいて設定される DSCP 値を指定するために使用されます。 また、管理者はユニークなマップを設定できます。 次に例を示します。

 
Console> (enable) set qos ipprec-dscp-map 20 30 1 43 63 12 13 8 
!-- QoS ipprec-dscp-map set successfully.
Console> (enable)

上記のコマンドでは、次のようなマップを設定しています。

IP 優先順位 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

上記のマップが、実際のネットワークで使用されることはまずありませんが、このコマンドで実行できることの説明のために提示してあります。

分類(CatOS)

フレームが PFC に渡されると、そのフレームに対する分類の処理が行われます。 PFC では、事前に定義された ACL(またはデフォルト ACL)を使用して、フレームに DSCP 値を割り当てます。 ACE の内部では、DSCP 値の割り当てに、4 つのキーワードのいずれかを使用します。 あります。

    1. TRUST-DSCP(IP ACL だけ)
    2. TRUST-IPPREC(IP ACL だけ)
    3. TRUST-COS(PFC2 の IPX および MAC を除くすべての ACL)
    4. DSCP

キーワード TRUST-DSCP では、PFC に到達したフレームには、スイッチに着信する前にすでに DSCP 値が設定されているものと仮定されています。 スイッチでは、この DSCP 値が維持されます。

TRUST-IPPREC では、PFC が DSCP 値を、ToS フィールドにある既存の IP 優先順位値を元にして設定します。 PFC は、IP 優先順位から DSCP へのマップを使用して、正しい DSCP 値を割り当てます。 デフォルトマップは QoS がスイッチで有効に なるとき作成されます。 また、管理者が作成するマップが DSCP 値を得るのに使用することができます。

TRUST-IPPREC と同様に、キーワード TRUS-COS でも、PFC に対して DSCP 値をフレーム ヘッダーの CoS を元にして設定するように指示されます。 この場合も CoS から DSCP へのマップがあり(デフォルトまたは管理者が割り当てたもの)、PFC が DSCP を決定するために使用されます。

DSCP キーワードは、フレームが信頼できないポートから着信した場合に使用されます。 これは、DSCP 値の設定に関する興味深い状況を表しています。 この時点で、set qos acl 文で設定される DSCP が DSCP を得るのに使用されています。 ただし、それはこの時点で ACL が ACE で設定 される 分類 の 基準に基づいてトラフィックのための DSCP を得るのに使用することができるところにです。 このことは、ACE では、トラフィックの識別に、発信元と宛先の IP アドレス、TCP/UDP ポート番号、ICMP コード、IGMP タイプ、IPX ネットワーク番号およびプロトコル番号、発信元および宛先の MAC アドレス、イーサタイプ(非 IP および非 IPX のトラフィックに限定)などの分類基準を使用できることを意味しています。 これはつまり、FTP トラフィック上の HTTP トラフィックなどに特定の DSCP 値を割り当てるように、ACE を設定できることになります。

以下のようになります。

 
Console> (enable) set port qos 3/5 trust untrusted

ポートを信頼できないとして設定することにより、PFC には、ACE を使用してフレームに DSCP を設定するように指示されます。 ACE が分類 の 基準で設定される場合、ユーザーは異なる優先順位でそのポートから分類することができますフローします。 次の ACE はこれを表しています。

 
Console> (enable) set qos acl ip abc dscp 32 tcp any any eq http 
Console> (enable) set qos acl ip ABC dscp 16 tcp any any eq ftp

この例では、2 つの ACE 文があります。 第 1 はポート番号 32 という DSCP 値が割り当てられる 80 (80 = HTTP)である TCP フローを識別します(送信元 および 宛先トラフィックを識別するのにキーワードが使用されています)。 第 2 ACE はあらゆるホストから送信されるトラフィックを識別し、TCPポート番号があるあらゆるホストに予定されて 21 (FTP) 16 という DSCP 値は割り当てられます。

統合Cisco IOS (ネイティブモード) を実行するCatalyst 6000 ファミリーの分類の設定

次のセクションでは、統合 Cisco IOS(ネイティブ モード)により、PFC での分類のサポートに使用される QoS の設定要素について説明します。

DSCPマッピング(Integrated Cisco IOS (Native Mode))への CO

スイッチにフレームが着信する際には、スイッチによってフレームに DSCP 値が設定されます。 ポートが信頼 された 状態にあり、管理者が MLS QoS CoSを信用するキーワードを(GE ポートか WS-X6548 ラインカードのポート 10/100 ので)使用したら場合、フレームの CO 値が設定がフレームのための DSCP 値が設定を判別するのに使用されます。 前述のように、スイッチはそれとしてフレームに通過します内部DSCP値に基づいてスイッチをサービスのレベルを指定できます。

QoS をイネーブルにすると、スイッチではデフォルト マップが作成されます。 詳細な設定については、この表を参照してください。 このマップは、CoS 値に基づいて設定される DSCP 値を指定するために使用されます。 また、管理者はユニークなマップを設定できます。 次にこの例を示します。

 
Cat6500(config)# mls qos map cos-dscp 20 30 1 43 63 12 13 8
Cat6500(config)#

上記のコマンドでは、次のようなマップを設定しています。

COS 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

上記のマップが、実際のネットワークで使用されることはまずありませんが、このコマンドで実行できることの説明のために提示してあります。

DSCPマッピング(Integrated Cisco IOS (Native Mode))への IP 優先順位

CoS から DSCP へのマッピングと同様に、フレームの DSCP 値を着信パケットの IP 優先順位の設定から決めることもできます。 これは、ポートが管理者によって信頼できると設定された場合にだけ行われ、これにはキーワード mls qos trust-ipprec を使用します。 このキーワードは、WS-X6548 ラインカードの GE ポートおよび 10/100 ポートでだけサポートされています。 ポート 10/100 ののために o WS-X6348 および WS-X6248 ラインカードが、ACL 着信 データに IP 優先順位信頼を割り当てるのに使用する必要があります。

QoS をイネーブルにすると、スイッチではデフォルト マップが作成されます。 詳細な設定については、この表を参照してください。 このマップは、IP 優先順位の値に基づいて設定される DSCP 値を指定するために使用されます。 また、管理者はユニークなマップを設定できます。 次にこの例を示します。

 
Cat6500(config)# mls qos map ip-prec-dscp 20 30 1 43 63 12 13 8
Cat6500(config)#

上記のコマンドでは、次のようなマップを設定しています。

IP 優先順位 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

上記のマップが、実際のネットワークで使用されることはまずありませんが、このコマンドで実行できることの説明のために提示してあります。

分類(Integrated Cisco IOS (Native Mode))

フレームが PFC に渡されると、分類処理を実行して、着信フレームに新しい優先順位を割り当てられます。 ここでの重要な点は、この処理はフレームが信頼できないポートから送られたものであるか、フレームが信頼できないとして分類されている場合にだけ行われることです。

ポリシ マップ クラス アクションはに使用することができます:

    1. TRUST COS
    2. TRUST IP-PRECEDENCE
    3. TRUST DSCP
    4. 信頼無し

キーワード TRUST DSCP では、PFC に到達したフレームには、スイッチに着信する前にすでに DSCP 値が設定されているものと仮定されています。 スイッチでは、この DSCP 値が維持されます。

TRUST IP-PRECEDENCE では、PFC が DSCP 値を ToS フィールドにある既存の IP 優先順位値を元にして設定します。 PFC では IP 優先順位から DSCP へのマップを使用して、正しい DSCP 値を割り当てます。 デフォルトマップは QoS がスイッチで有効に なるとき作成されます。 また、管理者が作成するマップが DSCP 値を得るのに使用することができます。

TRUST IP-PRECEDENCE と同様に、キーワード TRUST COs でも、PFC に対して DSCP 値をフレーム ヘッダーの CoS を元にして設定するように指示されます。 この場合も CoS から DSCP へのマップがあり(デフォルトまたは管理者が割り当てたもの)、PFC が DSCP を決定するために使用されます。

既存の優先順位(DSCP、IP 優先順位、または CO)から DSCP を得る例は下記に示されています。

 
Cat6500(config)# policy-map assign-dscp-value
Cat6500(config-pmap)# class test 
Cat6500(config-pmap-c)# trust COs
Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit
Cat6500(config)#

上のクラス マップでは、イーサネット ヘッダーの CoS から DSCP 値を得ています。

キーワード NO TRUST は、フレームが信頼できないポートから着信したときに使用されます。 これによって、ポリシング処理の際にフレームに DSCP 値を割り当てることができるようになります。

新しい優先順位(DSCP)が次のポリシー 定義を使用して PFC に入って来る異なるフローにどのようにの割り当てることができるか次の例を参照して下さい。

 
Cat6500(config)# access-list 102 permit tcp any any eq http
Cat6500(config)# policy-map new-dscp-for-flow
Cat6500(config-pmap)# class test access-group 102 
Cat6500(config-pmap-c)# no trust 
Cat6500(config-pmap-c)# police 1000 1 confirm-action set-dscp-transmit 24  Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit
Cat6500(config)#

上の例では、次のことが示されています。

    1. ポートに入って来る http フローを識別するために作成される ACL。
    2. ポリシーマップは new-dscp-for-flow を呼出しました。
    3. このクラスマップが操作をのための行うことそのクラスマップ(名前テスト)はトラフィックを識別するのにアクセス リスト 102 を使用します。
    4. クラス マップ test は、着信フレームの信頼状態を信頼できないとして設定し、そのフローに DSCP 値 24 を割り当てる。
    5. さらに、このクラス マップは、すべての http フローの集約を最大 1 MB に制限。

Common Open Policy Server (COPS)

COPS はプロトコルですリモートホストから設定される QoS があることを Catalyst 6000 ファミリーが可能にする。 現在、COPS は CatOS を使用してだけサポートされ、QoS のための IntServアーキテクチャの一部です。 現在(この文書の作成時点)、統合 Cisco IOS(ネイティブ モード)を使用している場合には、COPS はサポートされていません。 COPS プロトコルは QoS 設定情報をスイッチに搬送するものであり、QoS 設定情報の発信元ではありません。 COPS プロトコルを使用するには、スイッチ向けの QoS 情報をホスティングする外部 QoS マネージャが必要です。 外部 QoS マネージャは、COPS プロトコルを使用して、設定情報のスイッチへの送出を起動します。 Cisco の QoS Policy Manager (QPM)は外部 QoS マネージャの例です。

QPM の作業を説明する、しかし QPM の使用からの外部 QoS コンフィギュレーションをサポートすることをスイッチで必要な設定を説明するこの資料のインテントではないです。

COPSの設定

デフォルトで、COPS サポートは無効です。 スイッチで COPS を使用するには、これをイネーブルにする必要があります。 これには、次のコマンドを実行します。

 
Console> (enable) set qos policy-source cops   
!-- QoS policy source for the switch set to COPS.
Console> (enable)

このコマンドが起動されると、所定のデフォルトの QoS 設定値が COPS サーバから送られます。 これには次の項目が含まれます。

    1. キュー マッピングへの CO
    2. 入出力キューしきい値割り当て
    3. WRR 帯域幅の割り当て
    4. 集約および microflow ポリシー
    5. 出トラフィックのための CoS マップへの DSCP
    6. ACL
    7. デフォルトポートCoS 割り当て

COPS を使用して QoS 設定を行う場合には、これらの設定の適用方法が他とは異なることを理解しておくことが重要です。 COPS は、ポートを直接設定するよりも、ポート ASIC の設定に使用されます。 通常、ポート ASIC はポートのグループを制御するため、COPS による設定は、同時に多数のポートに適用されます。

設定されるポート ASIC は、GE ASIC です。 GE ラインカードで、GE (ポート 1-4、5-8、9-12、13-16)毎に 4 つのポートがあります。 これらのラインカードでは、COPS の設定はポートの各グループに対して効力があります。 (先にこの用紙で説明されている)通りラインカード 10/100 ので、ASIC、GE および 10/100 ASIC の 2 グループがあります。 10/100 ASIC 4 つに対して GE ASIC が 1 つあります。 各 10/100 ASIC はポート 12 10/100 のサポートします。 COPS は GE ASIC を設定します。 したがって、COPS を使用して QoS 設定を 10/100 ラインカードに適用すると、その設定は 48 個の 10/100 ポートすべてに適用されます。

set qos policy-source cops コマンドを発行して COPS のサポートをイネーブルにすると、COPS による QoS 設定が、スイッチのシャーシにあるすべての ASIC に適用されます。 仕様 ASIC に COPS 設定を適用することは可能性のあるです。 これには、次のコマンドを使用します。

 
Console> (enable) set port qos 5/4 policy-source cops   
!-- QoS policy source set to COPS for port (s) 5/1-4.
Console> (enable)

上のコマンドを実行することで、このコマンドは GE モジュールに対して発行され、4 つのポートがこのコマンドの影響を受けることが分かります。

Policy Decision Pointサーバ およびドメイン名

Policy Decision Point Server(PDPS)は、スイッチへ送出する QoS 設定の詳細を保存するために使用される外部ポリシー マネージャです。 COPS がスイッチで有効に なる場合、スイッチはスイッチに QoS コンフィギュレーションの詳細を供給する外部マネージャの IP アドレスで設定する必要があります。 これは、SNMP をイネーブルにしている場合に、SNMP マネージャの IP アドレスを指定するようなものです。

外部 PDPS を指定するコマンドは、次のように実行します。

 
Console> (enable) set cops server 192.168.1.1 primary
!-- 192.168.1.1 is added to the COPS diff-serv server table as primary server.
!-- 192.168.1.1 is added to the COPS rsvp server table as primary server.
Console> (enable)

上記のコマンドでは、デバイス 192.168.1.1 をプライマリの PDPS として指定しています。

スイッチが PDPS と通信する際には、PDPS で定義されているドメインに属している必要があります。 PDPS は、定義されているドメインに参加しているスイッチとしか通信しないため、スイッチは PDPS が属している COPS ドメインを識別するよう設定する必要があります。 この作業を行うには、次のコマンドを発行します。

 
Console> (enable) set cops domain name remote-cat6k
!-- Domain name set to remote-cat6k.
Console> (enable)

上のコマンドは、スイッチが remote-cat6k という名前のドメインに属すように設定されていることを示しています。 このドメインは QPM で定義されている必要があり、スイッチもこのドメインに属している必要があります。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報



Document ID: 24906