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

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

2003 年 9 月 29 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 1 月 30 日) | フィードバック

目次


概要

この文書では、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. 分類:分類のプロセスでは、フレームがスイッチを通過するときに割り当てるサービスのレベルを判定するために、IP ヘッダー(レイヤ 3(L3))と Transmission Control Protocol(TCP; 伝送制御プロトコル)/User Datagram Protocol(UDP; ユーザ データグラム プロトコル)ヘッダー(レイヤ 4(L4))のフィールドとともに、イーサネット L2 ヘッダー内の他のフィールドを調べる必要があります。

    3. ポリシング:ポリシングとは、イーサネット フレームを検査して、一定のタイムフレーム内でトラフィックが事前に定義されているレートを超過していないかどうかを確認するプロセスです(通常、スイッチでは、このタイムフレームは固定値として設定されています)。 フレームがプロファイル外である場合(たとえば、事前定義されたレートの制限を超えるデータ ストリームの一部であるなど)は、そのフレームは廃棄されるか、Class of Service(CoS)値がマークダウンされます。

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

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

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

スイッチでの QoS の必要性

大規模なバックプレーン、1 秒当たり数百万回のパケットのスイッチング、さらにノンブロッキング スイッチであることは、今日の多くのスイッチでは当然のこととなっています。 QoS が必要とされる理由は何でしょうか。 その答えは、輻輳にあります。

世界で一番高速なスイッチであっても、上の図で示すような 2 つのシナリオのいずれかの場合は、輻輳が発生することになります。 輻輳が発生した場合に、輻輳を管理する機能が働かなければ、パケットは廃棄されてしまいます。 パケットが廃棄されると、再送信が行われます。 再送信が行われると、ネットワークの負荷が増大します。 すでに輻輳が発生しているネットワークでは、これによって、それまでに起きていたパフォーマンスの問題に拍車がかかり、さらにパフォーマンスが低下する恐れが生じます。

集約型ネットワークの場合には、輻輳管理はさらに重要になります。 遅延が発生すると、音声やビデオなどの遅延の影響を受けやすいトラフィックには大きな影響があります。 単にスイッチのバッファを大きくするだけでは、輻輳問題の解決には不十分です。 遅延の影響を受けやすいトラフィックは、できる限り迅速にスイッチングする必要があります。 まず最初に、分類の技術を使用して、重要なトラフィックを識別する必要があります。次に、バッファ管理技術を活用して、高い優先順位を付けたトラフィックが輻輳が生じた際に廃棄されないようにします。 最後に、スケジューリング技術を組み入れて、重要なパケットをキューからできる限り早くスイッチングする必要があります。 以降、この文書では、Catalyst 6000 ファミリはこれらのすべての技術を実装することにより、今日の業界で最も包括的な QoS サブシステムとなっていることが説明されています。

上のセクションで挙げられたすべての 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. ポリシング判定が、わずかに異なっています。 PFC1 と PFC2 では通常のポリシングをサポートしています。この場合、集約ポリシーあるいはマイクロフロー ポリシーによりプロファイル外であるという判定が返されると、フレームが廃棄またはマークダウンされます。 しかし、PFC2 では、2 番目のポリシング レベルを指定して、そこでポリシーのアクションを実行するという、レートの超過に対する処理をサポートしています。

超過レート ポリサーを定義すると、パケットが超過レートを超えた場合に、そのパケットは廃棄またはマークダウンされます。 超過ポリシング レベルが設定されていると、元の DSCP 値をマークダウンの値に置き換えるのに、超過 DSCP マッピングが使用されます。 通常のポリシー レベルだけが設定されている場合は、通常の DSCP マッピングが使用されます。 両方のポリシー レベルが設定されていると、マッピング ルールの選択には超過ポリシング レベルが優先されます。

この文書で説明されている QoS 機能は、より高いレベルのパフォーマンスが得られるとされている ASIC によって実行されていることに注意してください。 基本的な Catalyst 6000 ファミリでの QoS のパフォーマンス(スイッチ ファブリック モジュールなし)は、15 MPPS になります。 DFC を使用した場合は、さらに高い QoS のパフォーマンスが得られます。

DFC

DFC は、WS-X6516-GBIC にオプションとして装着できます。 ただし、WS-X6816-GBIC カードには、これが標準として装着されています。また、DFC は最近発表されたファブリック 10/100(WS-X6548-RJ45)ラインカード、ファブリック RJ21 ラインカード(WS-X6548-RJ21)、および 100FX ラインカード(WS-X6524-MM-FX)などの、他のこれからのファブリック ラインカードでもサポートされる可能性があります。 DFC を次に示します。

DFC を装着すると、そのファブリック(クロスバー接続)ラインカードでローカル スイッチングが行えるようになります。 そのためには、そのスイッチ用に定義されている QoS ポリシーもサポートする必要があります。 管理者が DFC を直接設定することはできません。DFC はアクティブなスーパーバイザ上にあるマスター MSFC/PFC の制御を受ける状態で出荷されます。 プライマリ PFC から Forwarding Information Base(FIB)テーブルがプッシュされ、これにより DFC に L2 および L3 フォワーディング テーブルが付与されます。 また、QoS ポリシーのコピーもプッシュされるため、これらのポリシーもラインカードにローカルで備えられるようになります。これ以降の処理では、ローカル スイッチングの判定の際に 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 のバッファリングが備わっています。 各ラインカードで使用可能な 1 ポートあたりのバッファリングの詳細については、リリースノートを参照してください。このラインカードの各ポートでは、1 つの Rx キューと、高優先と低優先の 2 つの Tx キューがサポートされています。 次の図を参照してください。

上の図では、10/100 ASIC ごとに、10/100 ポート 12 に対してブレークアウトが 1 つ提供されています。 また 10/100 ポートごとに 128 K のバッファが提供されています。 このバッファの 128 K は、3 つのキューに分割されています。 上の図で示しているキューはデフォルトの設定ではありませんが、設定される代表的な例を表しています。 1 つの Rx キューが 16 K を使用し、残りの 112 K のメモリは 2 つの Tx キューで分割されています。 デフォルト(CatOS の場合)では、このメモリ領域の 20 % を高優先キューで使用し、80 % を低優先キューで使用します。 Catalyst IOS の場合、デフォルトでは、高優先キューに 10 %、低優先キューに 90 % が使用されます。

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

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

新型の 10/100 の ASIC では、それぞれの 10/100 ポートごとに、一連の Rx キューと Tx キューが用意されています。 この ASIC では、10/100 ポート全体で使用できるメモリの共有プールが提供されています。 各ラインカードで使用可能な 1 ポートあたりのバッファリングの詳細については、リリースノートを参照してください。このラインカードの各ポートでは、2 つの Rx キューと、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 つのキュー(Rx キューが 1 つ、Tx キューが 2 つ)が備わっています。 これは 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 年の後半、ラインカードあたり 10 GE のポートを 1 つ搭載した一連の 10 GE ラインカードを発表しました。このモジュールは、6000 シャーシのスロットを 1 つ使用します。 この 10 GE ラインカードでは、QoS がサポートされています。 10 GE のポートには、2 つの Rx キューと 3 つの Tx キューが備わっています。 1 つの Rx キューと 1 つの Tx キューは、それぞれ SP キュー専用です。 ポートにはバッファリング機能も実装されており、Rx バッファリングには合計 256K、TX バッファリングには 64MB が用意されています。 このポートには、Rx 側に 1p1q8t のキュー構造、Tx 側に 1p2q1t のキュー構造が実装されています。 キュー構造については、この文書の後の方で説明します。

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

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

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

Catalyst 6000 ファミリでは、2 つのオペレーティング システムがサポートされています。 元来のソフトウェア プラットフォームである CatOS は、Catalyst 5000 プラットフォームで使用されていたコード ベースに由来するものです。 最近になって、シスコでは統合 Cisco IOS(R) (ネイティブ モード)(以前のネイティブ IOS)を発表しました。このシステムでは、シスコ ルータの IOS に由来するコード ベースが使用されています。 どちらの OS プラットフォーム(CatOS および統合 Cisco IOS(ネイティブ モード))でも、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 と呼ばれるMSB(先頭)の 6 ビットが使用されるようになりました。 DSCP では、IP パケットに 64 段階の優先順位値(2 の 6 乗)を割り当てることができます。

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 によって処理されます。 このフレームは、ポート ASIC により Rx キューに置かれます。 Catalyst 6000 ファミリに装着されているラインカードの種類に応じて、1 つまたは 2 つの Rx キューがあります。

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

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

    1. フレームがスイッチに着信するより前に設定されていた既存の DSCP 値

    2. IPV4 ヘッダーに設定されていた受信時の IP 優先順位ビット。 DSCP には 64 段階の値がありますが、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 値が基準)

デフォルト マッピングがある場合、管理者はそれらのマッピングを上書きできます。 マッピングは次の用途で使用されます。

  • 着信フレームの CoS 値を DSCP 値に変換

  • 着信フレームの IP 優先順位の値を DSCP 値に変換

  • 発信フレームで DSCP 値を CoS 値に変換

  • 受信キューで CoS 値から廃棄しきい値を導出

  • 発信キューで CoS 値から廃棄しきい値を導出

  • ポリシングの設定を超過したフレームに対する DSCP マークダウン値

  • 特定の宛先 MAC アドレスを持ったフレームに対する CoS 値

WRED および WRR

WRED と WRR は、Catalyst 6000 ファミリに搭載されている 2 つのきわめて強力なアルゴリズムです。 WRED と WRR のどちらも、イーサネット フレーム内のプライオリティ タグ(CoS)を使用して、高度なバッファ管理と送信のスケジューリングを行います。

WRED

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

RED と WRED について理解するには、TCP フロー管理の概念を再読してください。 フロー管理によって、TCP の送信元がネットワーク処理に悪影響を及ぼさないようになります。 TCP スロースタート アルゴリズムは、これに対する解決策の一環です。 これは、いつフローが開始されるかを宣言し、ACK(確認応答)を待つ前にパケットを 1 つ送信します。 さらに、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.
 !--- この箇所を見ます。
 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. CoS から Rx 側の廃棄しきい値へのマップ

フレームが MSFC または PFC で処理される場合、フレームはその後の処理のために発信側のポート ASIC に渡されます。 MSFC によって処理されるフレームは、すべて CoS 値がゼロにリセットされます。 これは、発信側ポートでの QoS 処理を受けるために必要です。

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

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

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

また、上の図では示されていませんが、発信するフレームへの CoS の再割り当て処理でも DSCP から CoS へのマップを使用します。

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

注:設定する上での重要なポイントは、CatOS によって QoS コマンドがいつ起動されるかです。通常、コマンドは、指定したキューのタイプを持つすべてのポートに対して適用されます。 たとえば、WRED 廃棄しきい値が、1p2q2t というキュー タイプを持つポートに適用される場合、この WRED 廃棄しきい値は、このキュー タイプをサポートしている全ラインカードの全ポートに適用されます。 IOS を使用している場合は、通常は QoS コマンドはインターフェイス レベルで適用されます。

QoS をイネーブルに

Catalyst 6000 ファミリであらゆる QoS 設定を行う前に、まずそのスイッチ上で QoS をイネーブルにしておく必要があります。 これを行うには、次のコマンドを発行します。

CatOS

 Console> (enable) set qos enable
 !-- QoS をイネーブルにしました。
 Console> (enable)
 

統合 Cisco IOS(ネイティブ モード)

 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
 !-- ポート 3/16 の QoS を信頼できないとして設定しました。 
 Console> (enable)
 

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

注:現在、統合 Cisco IOS(ネイティブ モード)の場合、ソフトウェアでは GE ポートに対して信頼できるという設定だけをサポートしています。

統合 Cisco IOS(ネイティブ モード)

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

上の例では、IOS なので、まずインターフェイスの設定を入力し、次にコマンドを no の形式で実行して、ポートを信頼できないとして設定しています。

信頼できるポート

スイッチに着信するイーサネット フレームに、管理者にとって、そのフレームがスイッチを通過する際にそのまま維持しておきたい CoS あるいは ToS 設定がされている場合があります。 このようなトラフィックの場合、管理者は、そのトラフィックが着信するポートの信頼状態を、信頼できるとして設定できます。

前述したように、スイッチでは内部的に DSCP 値を使用して、事前に決められたサービスのレベルをそのフレームに割り当てます。 信頼できるポートへのフレームの着信に際して、管理者は、既存の CoS、IP 優先順位、または DSCP 値を参照して内部的な DSCP 値を与えるように、そのポートを設定できます。 あるいは、そのポートに着信するすべてのパケットに、事前に定義した 1 つの DSCP 値を設定することもできます。

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

CatOS

 Console> (enable) set port qos 3/16 trust trust-cos
 !-- ポート 3/16 の QoS を trust-CoS(信頼できる)と設定しました。
 Console> (enable)
 

このコマンドは、WS-X6548-RJ45 ラインカードに適用され、ポート 3/16 の信頼状態を信頼できるとして設定します。 このスイッチでは、着信フレームで設定されている CoS 値の設定を使用して、内部 DSCP が設定されます。 DSCP 値は、そのスイッチで QoS がイネーブルにされたときに作成されたデフォルト マップか、管理者によって定義されたマップから取得されます。 trust-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 はサポートされていません。acl を使用してください。
 Rx thresholds are enabled on port 4/1. 
 !-- 入力キューのスケジューリングをイネーブルにする必要があります。
 Port  4/1 qos set to untrusted. 
 !-- Trust-COs はサポートされていないため、ポートは信頼できないと設定されます。
 

上記のコマンドでは、入力キューのスケジューリングをイネーブルにする必要があります。 そのため、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 ポートに信頼状態を設定できます。

統合 Cisco IOS(ネイティブ モード)

 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
 !-- ポート 3/16 の QoS を 3 に設定します。 
 Console> (enable)
 

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

統合 Cisco IOS(ネイティブ モード)

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

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

Rx 側の廃棄しきい値の設定

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

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

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

1P1q4t(GE ポート)のキューの場合、デフォルト マッピングは次のとおりです。

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

1p1q0t(WS-X6548-RJ45 ラインカードの 10/100 ポート)のキューの場合、デフォルト マッピングは次のとおりです。

  • CoS の値が 5 のフレームを SP Rx キュー(キュー 2)に入れる。SP 受信キュー バッファでは使用率が 100 % に達したときにだけ着信フレームが廃棄されます。
  • CoS の値が 0、1、2、3、4、6、および 7 のフレームは、標準の Rx キューに入れる。 この場合、Rx キューのバッファの使用率が 100 % に達したときに着信フレームが廃棄されます。

これらの廃棄しきい値は、管理者が変更することもできます。 また、各しきい値にマップされているデフォルトの CoS 値も変更できます。 ラインカードが異なると、実装されている Rx キューも異なります。 キューの種類を要約したものを次に示します。

CatOS

 Console> (enable) set qos drop-threshold 1q4t rx queue 1 20 40 75 100
 !-- キュー 1 の Rx 廃棄しきい値を、20 %、40 %、75 %、および 100 % に設定しました。
 Console> (enable)
 

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

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

統合 Cisco IOS(ネイティブ モード)

 Cat6500(config-if)# wrr-queue threshold 1 40 50 
 Cat6500(config-if)# wrr-queue threshold 2 60 100 
 !-- 1q4t Rx キューに 4 つのしきい値を設定します。
 Cat6500(config-if)# rcv-queue threshold 1 60 75 85 100
 !-- 1p1q4t Rx キューを設定します。これは新型の 
 !-- WS-X6548-RJ45 10/100 ラインカードに適用されます。
 

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

Tx 側の廃棄しきい値の設定

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

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

CatOS

 Console> (enable) set qos drop-threshold 2q2t TX queue 1 40 100
 !-- キュー 1 の Tx 廃棄しきい値を、40 % および 100 % に設定します。
 Console> (enable)
 

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

 Console> (enable) set qos wred 1p2q2t TX queue 1  60 100
 !-- WRED 対応のすべての 1p2q2t ポートについて、キュー 1 の WRED しきい値を、60 % および 100 % に設定します。
 Console> (enable)
 

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

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

統合 Cisco IOS(ネイティブ モード)

 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 をディセーブルにする例を次に示します。

統合 Cisco IOS(ネイティブ モード)

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

MAC アドレスを CoS 値にマッピング

グローバルなポート定義に基づいて CoS を設定するほかに、管理者は、宛先の MAC アドレスや VLAN ID に基づいて CoS 値を設定することもできます。これにより、特定の宛先向けのフレームに、事前に定義した CoS 値をタグ付けできます。 この設定には、次のコマンドを実行します。

CatOS

 Console> (enable) set qos Mac-COs 00-00-0c-33-2a-4e 200 5
 !-- 00-00-0c-33-2a-4e VLAN 200 に CoS 5 を割り当てます。
 Console> (enable)
 

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

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

しきい値に CoS をマッピング

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

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

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

CatOS

 Console> (enable) set qos map 2q2t 1 1 COs 0 1 
 !-- QoS TX 優先キューとしきい値が CoS に正常にマップされています。
 Console> (enable)
 

このコマンドでは、0 と 1 の CoS 値をキュー 1、しきい値 1 に割り当てています。統合 Cisco IOS(ネィティブ モード)での同等のコマンドは次のとおりです。

統合 Cisco IOS(ネイティブ モード)

 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 アルゴリズムで処理する Tx キューは 2 つだけです。

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

CatOS

 Console> (enable) set qos wrr 2q2t 40 80 
 !-- QoS の WRR の比率が正しく設定されました。
 Console> (enable)
 

このコマンドでは、40 という重みの値をキュー 1 に、80 をキュー 2 に割り当てています。これは実際には、帯域幅が 2 対 1 の比率(80 対 40 = 2 対 1)で 2 つのキューに割り当てられたことを意味しています。 このコマンドは、2 つのキューと 2 つのしきい値を持つすべてのポートに有効です。

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

統合 Cisco IOS(ネイティブ モード)

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

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

DSCP から CoS へのマッピング

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

あるいは、スイッチで使用するマップを管理者が作成し、割り当てられた内部的な DSCP 値を使用して、フレームに対して新しい CoS 値を与えることもできます。 この機能を実行するための CatOS と統合 Cisco IOS(ネイティブ モード)の使用例は次のとおりです。

CatOS

 Console> (enable) set qos dscp-cos--map 20-30:5 10-15:3 45-52:7 
 !-- QoS の dscp-cos-map(DSCP と CoS のマップ)が正しく設定されました。
 Console> (enable)
 

上記のコマンドでは、DSCP 値の 20 から 30 を CoS 値の 5 に、DSCP 値の 10 から 15 を CoS 値の 3 に、DSCP 値の 45 から 52 を CoS 値の 7 に割り当てています。他のすべての DSCP 値については、そのスイッチで QoS がイネーブルにされたときに作成されたデフォルトのマップが使用されます。

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

統合 Cisco IOS(ネイティブ モード)

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

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

CatOS を使用する Catalyst 6000 ファミリでのポリシングの設定

ポリシングの機能は、CatOS と統合 Cisco IOS(ネィティブ モード)の 2 つのセクションに分けて説明します。 どちらの OS でも同じ結果を得ることができますが、設定と実行の方法は異なります。

ポリシング

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

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

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

集約とマイクロフロー(CatOS)

集約およびマイクロフローとは、PFC が実行するポリシングのスコープを定義するために使用する用語です。

マイクロフローでは、単一フローのポリシングが定義されます。 一意の SA/DA MAC アドレス、SA/DA IP アドレス、および TCP/UDP ポート番号を持ったセッションにより、フローが定義されます。 マイクロフローは、VLAN のポートから発信された新しい各フローに対して、そのフローからスイッチが受信するデータ量を制限するために使用できます。 マイクロフローの定義では、所定のレート制限を超過したパケットは、廃棄されるか、その DSCP 値がマークダウンされます。

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

集約とマイクロフローのいずれも、スイッチで受容できるトラフィックの総量を定義するものです。 また、集約とマイクロフローの両方を、1 つのポートまたは VLAN に同時に適用できます。

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

アクセス コントロール エントリと QoS ACL(CatOS)

QoS ACL は、PFC が着信フレームの処理に使用する QoS ルールのセットを定義した ACE のリストで構成されています。 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 ACE はいずれも L3 ヘッダー情報を調べます。一方、MAC ベースの ACE では、L2 ヘッダー情報だけを調べます。 さらに、MAC ACE は、非 IP および非 IPX トラフィックだけに適用されることにも注意してください。

ポリシング ルールの作成

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

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

まず、この例では着信するすべての IP トラフィックを制限する必要があります。 これは、集約ポリサーを定義する必要があることを意味しています。 この設定例は次のようになります。

 Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13 policed-dscp  
 !-- ハードウェアのプログラミングを実行中
 !-- 集約 test-flow のための QoS ポリサーが正しく作成されました。
 Console> (enable)
 

ここでは、test-flow という集約を作成しました。 ここでは、20,000 Kbps(20Mbps)のレートとバースト値 13 を定義しています。キーワード policed-dscp は、このポリシーを超過したデータはすべて、その DSCP 値が DSCP マークダウン マップでの指定によりマークダウンされることを示しています。このマップにはデフォルトのものがあり、これを管理者が変更することもできます。 キーワード policed-dscp を使用する代わりに、drop というキーワードも使用できます。 キーワード drop を定義すると、プロファイル外のトラフィック(割り当てられているバースト値を外れたトラフィック)は単純に廃棄されます。

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

上の例で使用されている値 13 は、1/4000 秒ごとに最大 13,000 ビットのデータを受容できるバケットを意味しています。 これは毎秒に換算すると、52 MB(13K ×((1 / 0.00025)あるいは 13K × 4000)になります。 設定するバースト値を送出するデータのレートと同等か、それ以上に設定する必要があることには、常に注意してください。 言い換えれば、バースト値は、所定の時間内に送信するデータの最小量と同等以上の値である必要があります。 バーストをレートとして指定した値よりも小さい数値で発生させると、レート制限がバーストと同じになります。 つまり、レートとして 20 Mbps を定義し、さらに 15 Mbps と換算されるバースト値を定義した場合は、レートは最大で 15 Mbps になります。 次に疑問となるのは、なぜバースト値が 13 であるかということでしょう。 バーストは、トークン バケットの深さ、つまり 1/4000 秒ごとの着信データの受信に使用されるバケットの深さを定義していることを思い出してください。 よって、バースト値は、1 秒間に 20 MB 以上の着信データ レートをサポートするいずれかの数値になります。 20 MB のレート制限に使用できる最小のバースト値は、20000 / 4000 = 5 になります。

ポリサーを処理する場合、トークン バケットがトークンでいっぱいになると、ポリシング アルゴリズムが始動します。 このトークン数は、バースト値と同じになります。 したがって、バースト値が 13 の場合、バケット内のトークンの数は 13,000 になります。1/4000 秒ごとに、ポリシング アルゴリズムによって、定義したレートを 4000 で除した値に等しい量のデータを送出します。送信されるデータ 1 ビットごとに、バケットから 1 トークンが消費されます。 この時間間隔の最後には、バケットが新しいセットのトークンで再びいっぱいになります。 置き換えられるトークンの数は、レートを 4000 で除した数になります。次の定義を理解するには、上の例を参考にしてください。

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

これは 100 Mbps のポートであり、このポートに 100 Mbps の一定のストリームを送信していると仮定します。 これは、100,000,000 ビット/秒の着信レートに相当します。 この定義文でのパラメータは、レートが 20,000 でバースト値が 13 です。時間間隔 t0 の時点で、バケットには総容量に等しいトークン(13,000)が入っています。 時間間隔 t0 の時点では、ポートに着信したデータの最初の 1 セット分が入っています。 この時間間隔での着信レートは 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 トークンを消費)、これが各時間間隔ごとに繰り返されます。

基本的に、バケットの深さ(バースト値で定義)を超過した着信データは廃棄されます。 データが送出(設定されたレートに一致)された残りのデータは廃棄され、着信データの次のセットに取り掛かれるようになります。 この時間間隔内に完全に受信されなかった不完全なパケットは廃棄されず、そのポートで完全に受信されるまで維持されます。

このバースト値は、トラフィックのフローが一定であると仮定しています。 しかし、実際のネットワーク環境では、データは一定ではなく、そのフローは 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 エディット バッファが変更されました。 commit コマンドを発行して、変更を適用します。
 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(および関連する ACE)には、非常に細密なレベルで設定を行える柔軟性があり、管理者はこれを使用できます。 ACL は、1 つまたは多数の ACE で構成でき、ポリシーを適用する必要のあるフローを指定するために、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 対応モジュールへの集約ポリサーの適用

Catalyst 6000 ではトラフィックの転送に中央集中型のフォワーディング エンジン(PFC)が使用されているため、非 DFC ラインカードへの集約ポリサーの適用が可能です。 中央集中型フォワーディング エンジンの実装により、所定の VLAN のトラフィック統計を追跡することが可能になりました。 この処理は、集約ポリサーを VLAN に適用するために使用できます。

しかし、DFC 対応のラインカードでは、フォワーディングの判定はそのラインカードで個別に行われます。DFC は、直接接続されているラインカード上のポートだけを認識しており、他のラインカードでのトラフィックの動きについては認識していません。 この理由から、複数の DFC モジュールにまたがるメンバ ポートで構成された VLAN に集約ポリサーを適用すると、ポリサーによって矛盾する結果が生じることがあります。 これは、DFC で追跡するのはローカルのポートの統計値だけであり、他のラインカード上のポートの統計値は対象にされていないためです。 この理由から、DFC 対応のラインカード上にあるメンバ ポートを持つ VLAN に集約ポリサーを適用すると、その DFC 対応ラインカード上にある VLAN ポートでだけ、トラフィックをレート制限する DFC ポリシングが実行されます。

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

DSCP マークダウン マップは、プロファイル外のトラフィックを廃棄ではなくマークダウンするようポリサーで定義されている場合に使用されます。 プロファイル外のトラフィックとは、定義されたバースト設定を超過したトラフィックです。

QoS をイネーブルにしたときには、デフォルトの DSCP マークダウン マップが設定されます。 デフォルトのマークダウン マップは、前出のこの表で示しています。 管理者は、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 に集約(またはマイクロフロー)を適用しても、そのポートが VLAN ベースの QoS に設定されていない場合は、ポートへの影響はありません。

 Console> (enable) set port qos 2/5-10 vlan-based  
 !-- ハードウェアのプログラミングを実行中
 !-- QoS インターフェイスがポート 2/5-10 に対して vlan-based と設定されました。
 Console> (enable)
 

ポートベースの QoS を VLAN ベースの QoS に変更すると、そのポートに割り当てられていたすべての ACL が即座に解除され、そのポートに VLAN ベースの ACL が割り当てられます。

ポート(または VLAN)に ACL をマップするには、次のコマンドを発行します。

 Console> (enable) set qos acl map test-acl 3/5  
 !-- ハードウェアのプログラミングを実行中
 !-- ACL test-acl がポート 3/5 に割り当て.
 Console> (enable)
 Console> (enable) set qos acl map test-acl 18  
 !-- Hardware programming in progress ?E
 !-- ACL test-acl is attached to VLAN 18.
 Console> (enable)
 

ACL をポート(または VLAN)に設定しても、ACL がハードウェアにコミットされるまでは、ACL は有効になりません。 このことについては、次のセクションで説明します。 この時点で、ACL はメモリ上の一時的なエディット バッファに読み込まれています。 ACL がこのバッファにある間は変更を加えることができます。

エディット バッファ上にあって、まだコミットされていない ACL を削除する場合は、rollback コマンドを発行します。 このコマンドにより、ACL がエディット バッファから削除されます。

 Console> (enable) rollback qos acl test-acl 
 !-- QoS ACL test-acl のロールバックに成功しました。
 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 
 !-- ハードウェアのプログラミングを実行中
 !-- ACL test-acl がハードウェアにコミットされました。  
 Console> (enable)
 

ACL をポート(または VLAN)から削除する場合には、次のコマンドを使用して、その ACL をポート(または VLAN)に関連付けているマップをクリアする必要があります。

 Console> (enable) clear qos acl map test-acl 3/5  
 !-- ハードウェアのプログラミングを実行中
 !-- ACL test-acl のポート 3/5 との関連付けを解除しました。
 Console>(enable)
 

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

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

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

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

集約とマイクロフロー(統合 Cisco IOS(ネイティブ モード))

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

マイクロフローは、単一のフローのポリシングを定義します。 フローは、一意の SA/DA MAC アドレス、SA/DA IP アドレス、および TCP/UDP ポート番号を持ったセッションによって定義されます。 マイクロフローは、VLAN のポートから発信された新しい各フローに対して、そのフローからスイッチが受信するデータ量を制限するために使用できます。 マイクロフローの定義では、所定のレート制限を超過したパケットは、廃棄されるか、その DSCP 値がマークダウンされます。 マイクロフローを適用するには、ポリシー マップ クラスの一部であるポリシー フロー コマンドを使用します。

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

Cat6500(config)# mls qos flow-policing

マイクロフロー ポリシングは、ブリッジ トラフィックに適用されます。ブリッジ トラフィックとは、L3 でのスイッチを受けていないトラフィックです。 スイッチでブリッジ トラフィックに対するマイクロフロー ポリシングがサポートされるようにするには、次のコマンドを実行します。

 Cat6500(config)# mls qos bridged
 

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

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

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

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

  • 名前付き集約ポリサー

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

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

ポリシング ルールの作成(統合 Cisco IOS(ネイティブ モード))

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

CatOS 用に作成したものと同じ例について考えます。 要件は、ポート 5/3 に着信するすべての IP トラフィックを、最大 20 Mbps に制限することです。

最初に、ポリシー マップを作成します。 ここでは、limit-traffic という名前のポリシー マップを作成します。 これは、次のように実行します。

 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)のバースト値とともに設定しています。 トラフィックがこのプロファイルに合致し、このレート制限以内にある場合は、confirm-action 文で設定されているように、プロファイル内のトラフィックを転送するアクションが取られます。 トラフィックがプロファイル外(上の例では 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 マークダウン マップは、プロファイル外のトラフィックを廃棄ではなくマークダウンするようポリサーで定義されている場合に使用されます。 プロファイル外のトラフィックとは、定義されたバースト設定を超過したトラフィックです。

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

 

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

この例では、DSCP 値 32 のデフォルトの policed-dscp マップを、DSCP 値 16 にマークダウンするよう変更しています。このポリサーで定義されたポートでは、この DSCP 値を持つ着信データで、指定されたバースト値を超過したデータ ブロックの部分は、値が 16 にマークダウンされます。

VLAN とポートへのポリシーのマップ(統合 Cisco IOS(ネイティブ モード))

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

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

VLAN ポリシーを適用する VLAN 上の各ポートごとに、VLAN にポリシーをマップする場合は、mls qos vlan-based コマンドを発行して、QoS が 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 は VLAN 100 に含まれ、VLAN 100 に適用される limit-traffic という名前のポリシーが、インターフェイス 3/5 にも適用されると仮定します。

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

PFC には、L2、L3、および L4 ヘッダー情報を調べられる ACL を使用する、データの分類のサポートを導入されています。 スーパーバイザ I、または IA(PFC なし)の場合、分類はポートに対してキーワード trust を使用するものに限られています。

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

CoS から DSCP へのマッピング(CatOS)

スイッチにフレームが着信する際には、スイッチによってフレームに DSCP 値が設定されます。 ポートが信頼できる状態で、管理者がキーワード trust-COs を使用した場合には、フレームに設定されている CoS 値を元にして、そのフレームに割り当てる DSCP 値が決定されます。 前述したように、スイッチはフレームがスイッチを通過する際、その内部的な DSCP 値に基づいて、異なるレベルのサービスを割り当てます。

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

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

 Console> (enable) set qos cos-dscp-map 20 30 1 43 63 12 13 8 
 !-- QoS の cos-dscp-map が正しく設定されました。
 Console> (enable)
 

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

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

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

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

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 が正しく設定されました。
 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 の設定に使用されます。 しかし、この段階では、ACE に設定された分類基準に基づいて、トラフィックに対する DSCP 値を決定するために、ACL が使用できる状況です。 このことは、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 文があります。 最初の文は、ポート番号が 80(80 = HTTP)であるあらゆる TCP フロー(キーワード any はトラフィックの送信元と宛先両方の指定に使用されています)を DSCP 値 32 に割り当てるように指定しています。2 番目の ACE は、TCP ポート番号が 21(FTP)で、あらゆる発信元からと、あらゆる宛先へのトラフィックを、DSCP 値 16 に割り当てています。

統合 Cisco IoS(ネイティブ モード)を使用する Catalyst 6000 ファミリでの分類の設定

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

CoS から DSCP へのマッピング(統合 Cisco IOS(ネイティブ モード))

スイッチにフレームが着信する際には、スイッチによってフレームに DSCP 値が設定されます。 ポートが信頼できる状態で、管理者がキーワード mls qos trust-COs を使用(WS-X6548 ラインカードの GE ポートまたは 10/100 ポートが対象)した場合には、フレームに設定されている CoS 値を元にして、そのフレームに割り当てる 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

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

IP 優先順位から DSCP へのマッピング(統合 Cisco IOS(ネイティブ モード))

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

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

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

分類(統合 Cisco IOS(ネイティブ モード))

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

ポリシー マップ クラスのアクションは、次のために使用できます。

    1. TRUST COs
    2. TRUST IP-PRECEDENCE
    3. TRUST DSCP
    4. NO TRUST

キーワード 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 優先順位、または CoS)を元にして 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 を使用するクラス マップ(名前は test)。
    4. クラス マップ test は、着信フレームの信頼状態を信頼できないとして設定し、そのフローに DSCP 値 24 を割り当てる。
    5. さらに、このクラス マップは、すべての http フローの集約を最大 1 MB に制限。

Common Open Policy Server(COPS)

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

この文書は、QPM の動作については説明しませんが、外部での QoS 設定をスイッチでサポートするための設定を QPM を使用して説明します。

COPS の設定

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

 Console> (enable) set qos policy-source cops   
 !---  スイッチの QoS ポリシーの設定元を COPS に設定しました。
 Console> (enable)
 

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

    1. キューに対する CoS のマッピング
    2. 入力キューと出力キューのしきい値の割り当て
    3. WRR 帯域幅の割り当て
    4. 集約とマイクロフローのポリシー
    5. 出力トラフィックに対する DSCP から CoS へのマップ
    6. ACL
    7. デフォルトのポート CoS の割り当て

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

設定されるポート ASIC は、GE ASIC です。 GE ラインカードには、GE ごとに 4 つのポートがあります(ポート 1-4、5-8、9-12、13-16)。 これらのラインカードでは、COPS の設定はポートの各グループに対して効力があります。 10/100 ラインカード(この文書で前述)には、GE ASIC および 10/100 ASIC という 2 つの ASIC のグループがあります。 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 に適用されます。 COPS による設定を特定の ASIC に適用することもできます。 これには、次のコマンドを使用します。

 Console> (enable) set port qos 5/4 policy-source cops   
 !-- ポート 5/1-4 について、QoS ポリシーの設定元を COPS としました。
 Console> (enable)
 

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

Policy Decision Point Server とドメイン名

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 をプライマリ サーバとして COPS diff-serv サーバ テーブルに追加しました。
 !-- 192.168.1.1 をプライマリ サーバとして COPS rsvp サーバ テーブルに追加しました。
 Console> (enable)
 

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

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

 Console> (enable) set cops domain name remote-cat6k
 !-- ドメイン名は remote-cat6k と設定されました。
 Console> (enable)
 

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


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

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


関連情報


Document ID: 24906