出力スケジューリングは、インターフェイスの出力でオーバーサブスクリプションが過剰に発生した場合に、重要なトラフィックが廃棄されないことを保証します。このドキュメントは、Catalyst 3550 スイッチでの出力スケジューリングに関連するテクニックとアルゴリズムについて包括的に説明しています。また、Catalyst 3550 スイッチにおいて出力スケジューリングの処理を設定および確認する方法についても詳しく説明しています。
このドキュメントに特有の要件はありません。
このドキュメントの情報は、Cisco IOS®ソフトウェアリリース12.1EA1が稼働するCatalyst 3550に基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
3550 スイッチのポートには、次の 2 つのタイプがあります。
ギガビット ポート
非ギガビット ポート(10/100 Mbps ポート)
これら 2 つのポートには異なる機能が装備されています。このセクションでは、以降、これらの機能の概要を紹介しています。機能の詳しい説明は、後のセクションで行っています。
3550 の各ポートには 4 つの異なる出力キューがあります。これらのいずれかのキューを完全優先キューとして設定できます。残りの各キューは非完全優先キューとして設定され、Weighted Round-Robin(WRR; ウエイテッド ラウンドロビン)で処理されます。 すべてのポート上で、Class of Service(CoS; サービス クラス)に基づいて、パケットは 4 つの使用可能なキューのいずれかに割り当てられます。
ギガビット ポートは、各キュー内でキュー管理メカニズムもサポートしてます。各キューを設定して、Weighted Random Early Detection(WRED; 重み付けランダム早期検出)、または 2 つのしきい値を持つテール ドロップを使用できます。また、各キュー(各キューに割り当てられるバッファ)のサイズを調整できます。
非ギガビット ポートには、WRED や、2 つのしきい値を使用したテール ドロップなどのキューイング メカニズムはありません。10/100 Mbps ポートでの FIFO キューイングのみがサポートされます。これらのポートの 4 つの各キューのサイズを変更することはできません。ただし、キューごとに最小(min)予約サイズを割り当てられます。
このセクションは、3550 がキューへの各パケットの配置をどのように決定するかについて説明しています。パケットは CoS に基づいてキューに配置されます。8 つの使用可能な各 CoS 値は、次の例が示しているキューに対する CoS のマップ インターフェイス コマンドを使用して、4 つの使用可能なキューのいずれかにマッピングされます。
(config-if)#wrr-queue cos-map queue-id cos1... cos8
以下が一例です。
3550(config-if)#wrr-queue cos-map 1 0 1 3550(config-if)#wrr-queue cos-map 2 2 3 3550(config-if)#wrr-queue cos-map 3 4 5 3550(config-if)#wrr-queue cos-map 4 6 7
この例では次のものが配置されます。
Q1 に CoS 0 および 1
Q2 に CoS 2 および 3
Q3 に CoS 4 および 5
Q4 に CoS 6 および 7
次のコマンドを発行すると、ポートでのキューに対する CoS のマッピングを確認できます。
cat3550#show mls qos interface gigabitethernet0/1 queueing GigabitEthernet0/1 ...Cos-queue map: cos-qid 0 - 1 1 - 1 2 - 2 3 - 2 4 - 3 5 - 3 6 - 4 7 - 4...
完全優先キューは、最初は常に空にされます。そのため、完全優先キューにパケットがあると、そのパケットは即座に転送されます。各パケットが WRR キューのいずれかから転送された後、完全優先キューはチェックされ、必要に応じて空にされます。
完全優先キューは、音声などの遅延/ジッタの影響を受けやすいトラフィック用に特化した設計になっています。完全優先キューは、結果的にその他のキューの処理停滞を発生させる可能性があります。パケットが完全優先キューで待機している場合、その他 3 つの WRR キューに配置されたパケットは転送されません。
他のキューの処理停滞を防ぐために、優先キューにどのようなトラフィックが配置されているかに特に注意してください。このキューは、通常、音声トラフィックに使用されます。トラフィックの量は、通常、あまり多くありません。ただし、いずれかのユーザが CoS プライオリティを使用して大量のトラフィック(サイズの大きなファイルの転送やバックアップなど)を完全優先キューに送れるような場合、結果としてその他のトラフィックの処理が停滞します。この問題を避けるために、ネットワークでのトラフィックの分類/アドミッションおよびマーキングに、特別なトラフィックが配置される必要があります。たとえば、次の対策を行うことができます。
すべての信頼できない送信元ポートには、信頼できないポートの QoS ステータスを使用する。
Cisco IP Phone ポートには信頼境界機能を使用して、別のアプリケーションの IP Phone 用に設定された信頼状態で Cisco IP Phone ポートが使用されないようにする。
完全優先キューが宛先であるトラフィックを監視する。CoS が 5(Differentiated Services Code Point(DSCP; DiffServ コード ポイント)46)のポリシング トラフィックの制限をギガビット ポート上で 100 MB に設定する。
これらのトピックの詳細は、次のドキュメントを参照してください。
3550 では、1 つのキューを優先キュー(常に Q4)に設定できます。 インターフェイス モードで次のコマンドを使用します。
3550(config-if)#priority-queue out
インターフェイスで優先キューが設定されていない場合、Q4 は標準 WRR キューと見なされます。このドキュメントの「Catalyst 3550 でのウエイテッド ラウンドロビン」セクションは、さらに詳細を説明しています。次と同じ Cisco IOS コマンドを発行すると、インターフェイスに完全優先キューが設定されているかどうかを確認できます。
NifNif#show mls qos interface gigabitethernet0/1 queueing GigabitEthernet0/1 Egress expedite queue: ena
WRR は、3550 での出力スケジューリングで使用されるメカニズムです。(完全優先キューが存在しない場合)WRR は 3 または 4 つのキューの間で動作します。 WRR で使用されるキューはラウンドロビン方式で(送信処理されて)空になり、さらに各キューの重み付けを設定できます。
たとえば、次の表に示すように、キューが別々に処理されるように重み付けを設定できます。
サーバWRR Q1:時間の 10 %
サーバWRR Q2:20 %の時間
サーバWRR Q3:WRR Q3 の処理:時間の 60 %
サーバWRR Q4:時間の 10 %
各キューに対して、インターフェイス モードで次のコマンドを発行すると、4 つの重み付け(1 つが各キューに関連付けられている)を設定できます。
(config-f)#wrr-queue bandwidth weight1 weight2 weight3 weight4
以下が一例です。
3550(config)#interface gigabitethernet 0/1
3550(config-if)#wrr-queue bandwidth 1 2 3 4
注:重みは相対的です。次の値が使用されます。
Q1 = weight 1 / (weight1 + weight2 + weight3 + weight4) = 1 / (1+2+3+4) = 1/10
Q2 = 2/10
Q3 = 3/10
Q4 = 4/10
WRR は、次の 2 つの方法で実装できます。
帯域幅ごとの WRR:各重み付けは、送信を許可されている特定の帯域幅を表します。重み付け Q1 は帯域幅の約 10 % を使用することが許可され、Q2 は帯域幅の 20 % を取得する、などのようになります。この方式は、現時点では Catalyst 6500/6000 シリーズのみで実装されています。
パケットごとの WRR:これが 3550 スイッチで実装されているアルゴリズムです。各重み付けは、サイズに関係なく、送信される特定の数のパケットを表します。
3550 はパケットごとに WRR を実装するため、この動作はこのセクションでの設定に次のように適用されます。
Q1 は 10 パケットのうち 1 パケットを送信する
Q2 は 10 パケットのうち 2 パケットを送信する
Q3 は 10 パケットのうち 3 パケットを送信する
Q4 は 10 パケットのうち 4 パケットを送信する
送信されるパケットはすべて同じサイズであることが考えられます。この段階ではまだ、4 つのキューの間での帯域幅の共有は予測可能です。ところが、キューの間で平均パケット サイズが異なる場合には、輻輳が発生すると、何が送信され何が廃棄されるかには大きな影響が生じます。
たとえば、スイッチには 2 つのフローしか存在しないと仮定します。また仮定として、次の条件が該当するとします。
CoS が 3 のサイズの小さなインタラクティブ アプリケーション トラフィック(80 バイト [B] フレーム)が 1 Gbps で Q2 に配置されている。
CoS が 0 のサイズの大きなファイル転送トラフィック(1518-B フレーム)が 1 Gbps で Q1 に配置されている。
スイッチの 2 つのキューでは 1 Gbps でデータが送信される。
両方のストリームは、同じ出力ギガビット ポートを共有する必要がある。Q1とQ2の間に同じ重みが設定されていると仮定します。WRRはパケットごとに適用され、各キューから送信されるデータの量は2つのキューの間で異なります。各キューからは同じ数のパケットが送信されますが、スイッチは実際には次の量のデータを送信します。
Q2 からは 77700 パケット/秒(pps)=(77700 × 8 × 64)ビット/秒(bps)(約 52 Mbps)
Q1 からは 77700 pps =(77700 × 8 × 1500)bps(約 948 Mbps)
ネットワークへの各キューに関する公平なアクセスを実現したい場合は、各パケットの平均サイズを考慮します。各パケットは 1 つのキューに配置され、重み付けはそれに従って変更されることが想定されています。たとえば、各キューが帯域幅の 1/4 を取得するように、4 つの各キューに等しいアクセスを付与する場合、トラフィックは次のようになります。
Q1:ベスト エフォートのインターネット トラフィック。トラフィックは 256 B の平均パケット サイズを持っているとします。
第2四半期:パケットが主に 1500 B である、ファイル転送から構成されるバックアップ。
第3四半期:192 B のパケットで処理されるビデオ ストリーム。
Q4:主に 64 B のパケットから構成されるインタラクティブ アプリケーション。
これにより次の条件が成立します。
Q1 は Q4 の 4 倍の帯域幅を消費する。
Q2 は Q4 の 24 倍の帯域幅を消費する。
Q3 は Q4 の 3 倍の帯域幅を消費する。
ネットワークへの等しい帯域幅アクセスを実現するには、次のように設定します。
Q1 の重み付けを 6
Q2 の重み付けを 1
Q3 の重み付けを 8
Q4 の重み付けを 24
上記の重み付けを割り当てた場合、輻輳が発生すると、4 つのキューの間で等しい帯域幅共有が実現されます。
完全優先キューが有効である場合、WRR の重み付けは、残りの 3 つのキューの間で再分配されます。完全優先キューが有効であり、Q4 が設定されていない場合、重み付けが 1、2、3、および 4 の最初の例は次のようになります。
Q1 = 1 / (1+2+3) = 6 つのうち 1 パケット
Q2 = 6 つのうち 2 パケット
Q3 = 6 つのうち 3 パケット
次の Cisco IOS ソフトウェアの show コマンドを発行すると、キューの重み付けを確認できます。
NifNif#show mls qos interface gigabitethernet0/1 queueing GigabitEthernet0/1 QoS is disabled. Only one queue is used When QoS is enabled, following settings will be applied Egress expedite queue: dis wrr bandwidth weights: qid-weights 1 - 25 2 - 25 3 - 25 4 - 25
緊急優先キューが有効である場合、緊急キューが無効になると、Q4 の重み付けのみが使用されます。以下が一例です。
NifNif#show mls qos interface gigabitethernet0/1 queueing GigabitEthernet0/1 Egress expedite queue: ena wrr bandwidth weights: qid-weights 1 - 25 2 - 25 3 - 25 4 - 25 !--- The expedite queue is disabled.
3550 シリーズ スイッチでは、WRED はギガビット ポートのみで使用できます。WRED は、Random Early Detection(RED; ランダム早期検出)を修正したもので、輻輳回避で使用されます。RED では次のパラメータが定義されています。
最小しきい値:キュー内部でのしきい値を表します。このしきい値未満では、パケットは廃棄されません。
最大(max)しきい値:キュー内の別のしきい値を表します。最大しきい値を超えると、すべてのパケットは廃棄されます。
スロープ:最小と最大の間でパケットをドロップする確率。廃棄の確率は、キュー サイズとともに(ある程度のスロープで)直線的に増加します。
次のグラフは RED キューでのパケット廃棄の確率を示します。
注:REDを実装するすべてのCatalystスイッチでは、スロープを調整できます。
WRED では、異なるサービスが重み付けの対象になります。標準サービスとプレミアム サービスを定義できます。各サービスは、しきい値の別のセットを受け取ります。最小しきい値 1 に到達すると、標準サービスに割り当てられているパケットのみが廃棄されます。最小しきい値 2 に到達すると、プレミアム サービスのパケットのみが廃棄されるようになります。最小しきい値 2 が最小しきい値 1 よりも高い場合、プレミアム サービスのパケットよりも多くの標準サービスのパケットが廃棄されます。次のグラフに、WRED を使用した各サービスの廃棄の確率の例を示します。
注:3550スイッチでは、最小しきい値を調整することはできませんが、最大しきい値だけを調整できます。最小しきい値は常に0に設定されます。これにより、3550で現在実装されている値を表す廃棄確率が得られます。
3550 上で WRED が有効になっているすべてのキューは、常に廃棄の確率がゼロではなく、また常にパケットを廃棄します。これは、最小しきい値が常に0であるためです。最大でのパケット廃棄を回避する必要がある場合は、「Catalyst 3550スイッチでのテールドロップ」の項で説明する重み付けテールドロップを使用します。
ヒント:Cisco Bug ID CSCdz73556 (登録ユーザ専用)に、最小しきい値の設定に関する拡張要求が記載されています。
RED および WRED の詳細は、『輻輳回避の概要』を参照してください。
3550 では、2 つの異なる最大しきい値で WRED を設定して、2 つの異なるサービスを提供できます。異なる種類のトラフィックがいずれかのしきい値に割り当てられますが、これは内部 DSCP のみに依存します。これは、パケットの CoS のみに依存するキュー割り当てとは異なります。しきい値に対する DSCP テーブルのマッピングが、64 個の DSCP のそれぞれが実行するしきい値を決定します。次のコマンドを発行すると、テーブルを表示および変更できます。
(config-if)#wrr-queue dscp-map threshold_number DSCP_1 DSCP_2 DSCP_8
たとえば、次のコマンドは DSCP 26 をしきい値 2 に割り当てます。
NifNif(config-if)#wrr-queue dscp-map 2 26 NifNif#show mls qos interface gigabitethernet0/1 queueing GigabitEthernet0/1 Dscp-threshold map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 02 01 01 01 2 : 01 01 01 01 02 01 02 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 02 01 01 01 01 01 02 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01
しきい値に対する DSCP のマップの定義後、WRED はユーザが選択したキュー上で有効になります。次のコマンドを実行します。
(config-if)#wrr-queue random-detect max-threshold queue_id threshold_1 threshold_2
この例では、次のように設定します。
しきい値が 1 の Q1 = 50 % としきい値 2 = 100 %
しきい値が 1 の Q2 = 70 % としきい値 2 = 100 %
3550(config)#interface gigabitethernet 0/1 3550(config-if)#wrr-queue random-detect max-threshold 1 50 100 3550(config-if)#wrr-queue random-detect max-threshold 2 70 100 3550(config-if)#wrr-queue random-detect max-threshold 3 50 100 3550(config-if)#wrr-queue random-detect max-threshold 4 70 100
次のコマンドを発行すると、各キューのキューイングの種類(WRED であるかどうか)を確認できます。
nifnif#show mls qos interface gigabitethernet0/1 buffers GigabitEthernet0/1 .. qid WRED thresh1 thresh2 1 dis 10 100 2 dis 10 100 3 ena 10 100 4 dis 100 100
ena は有効を意味し、キューは WRED を使用します。dis は無効を意味し、キューはテール ドロップを使用します。
各しきい値で廃棄されるパケットの数を監視することもできます。次のコマンドを実行します。
show mls qos interface gigabitethernetx/x statistics
WRED drop counts:
qid thresh1 thresh2 FreeQ
1 : 327186552 8 1024
2 : 0 0 1024
3 : 37896030 0 1024
4 : 0 0 1024
テール ドロップは、3550 のギガビット ポートのデフォルトのメカニズムです。各ギガビット ポートは 2 つのテール ドロップのしきい値を使用できます。このドキュメントの「Catalyst 3550 スイッチでの WRED」セクションで定義されている同じ DSCP しきい値マップを使用して、DSCP のセットが各テール ドロップのしきい値に割り当てられます。しきい値に到達すると、そのしきい値に割り当てられている DSCP を持つすべてのパケットが廃棄されます。次のコマンドを発行すると、テール ドロップのしきい値を設定できます。
(config-if)#wrr-queue threshold queue-id threshold-percentage1 threshold-percentage2
この例では、次のように設定します。
テール ドロップしきい値が 1 の Q1 = 50 % としきい値 2 = 100 %
しきい値が 1 の Q2 = 70 % としきい値 2 = 100 %
Switch(config-if)#wrr-queue threshold 1 50 100 Switch(config-if)#wrr-queue threshold 2 70 100 Switch(config-if)#wrr-queue threshold 3 60 100 Switch(config-if)#wrr-queue threshold 4 80 100
3550 スイッチはセントラル バッファリングを使用します。このことは、ポート単位で固定されたバッファ サイズがないことを意味します。ただし、ギガビット ポート上にはキューイング可能な固定数のパケットが存在します。この固定数は 4096 です。デフォルトでは、パケット サイズに関係なく、ギガビット ポートの各キューは最大 1024 までパケットを持つことができます。ただし、これらの 4096 個のパケットが 4 つのキューの間で分割される方法を変更できます。次のコマンドを実行します。
wrr-queue queue-limit Q_size1 Q_size2 Q_size3 Q_size4
以下が一例です。
3550(config)#interface gigabitethernet 0/1 3550(config-if)#wrr-queue queue-limit 4 3 2 1
これらのキュー サイズのパラメータは相対的です。この例は次のことを示しています。
Q1 は Q4 の 4 倍の大きさである。
Q2 は Q4 の 3 倍の大きさである。
Q3 は Q4 の 2 倍の大きさである。
4096 個のパケットは次の方法で再配布されます。
Q1 = [4 / (1+2+3+4)] * 4096 = 1639パケット
Q2 = 0.3 * 4096 = 1229 パケット
Q3 = 0.2 * 4096 = 819 パケット
Q4 = 0.1 * 4096 = 409 パケット
次のコマンドを発行すると、4 つのキューの間で分割されたバッファの相対的な重み付けを確認できます。
cat3550#show mls qos interface buffers GigabitEthernet0/1 Notify Q depth: qid-size 1 - 4 2 - 3 3 - 2 4 - 1 ...
また次のコマンドを発行すると、各キューがまだ保持できる空きパケットがいくつあるかを確認できます。
(config-if)#show mls qos interface gigabitethernetx/x statistics
WRED drop counts:
qid thresh1 thresh2 FreeQ
1 : 0 0 1639
2 : 0 0 1229
3 : 0 0 819
4 : 0 0 409
FreeQ カウント パラメータはダイナミックです。FreeQ カウンタの値は、最大キュー サイズから現在キュー内に存在するパケットの数を引いたものです。たとえば、現在 Q1 に 39 個のパケットが存在する場合、FreeQ カウントでは 1600 個のパケットがフリーです。以下が一例です。
(config-if)#show mls qos interface gigabitethernetx/x statistics
WRED drop counts:
qid thresh1 thresh2 FreeQ
1 : 0 0 1600
2 : 0 0 1229
3 : 0 0 819
4 : 0 0 409
10/100 Mbps ポートで使用できるキュー管理スキームはありません(2 つのしきい値を持つ WRED またはテール ドロップはありません)。 4 つすべてのキューは FIFO キューです。また、各ギガビット ポートに 4096 個のパケットを予約する最大キュー サイズも存在しません。10/100 Mbps ポートは、リソース不足によりいっぱいになるまで、各キューにパケットを格納します。キューごとにパケットの最小数を予約できます。この最小値は、デフォルトではキューごとに 100 パケットに設定されています。異なる最小予約値を定義し、いずれかの値を各キューに割り当てた場合、各キューのこの最小予約値を変更できます。
このように変更するには、次の手順を実行します。
各グローバル最小予約値のバッファ サイズを割り当てます。
最大 8 つの異なる最小予約値を設定できます。次のコマンドを実行します。
(Config)# mls qos min-reserve min-reserve-level min-reserve-buffersize
これらの最小予約値はスイッチに対してグローバルです。デフォルトでは、すべての最小予約値が 100 パケットに設定されています。
たとえば、150 パケットの最小予約レベル 1 と 50 パケットの最小予約レベル 2 を設定するには、次のコマンドを発行します。
nifnif(config)#mls qos min-reserve ? <1-8> Configure min-reserve level nifnif(config)#mls qos min-reserve 1 ? <10-170> Configure min-reserve buffers nifnif(config)#mls qos min-reserve 1 150 nifnif(config)#mls qos min-reserve 2 50
各キューにはいずれかの最小予約値を割り当てます。
キューに保証されているバッファの数を知るには、各キューをいずれかの最小予約値に割り当てる必要があります。デフォルトでは、次の条件が適用されます。
Q1 は最小予約レベル 1 に割り当てられる。
Q2 は最小予約レベル 2 に割り当てられる。
Q3 は最小予約レベル 3 に割り当てられる。
Q4 は最小予約レベル 4 に割り当てられる。
デフォルトでは、すべての最小予約値は 100 です。
次のインターフェイス コマンドを発行すると、キューごとに異なる最小予約値を割り当てることができます。
(config-if)#wrr-queue min-reserve queue-id min-reserve-level
たとえば、最小予約 2 を Q1 に割り当て、最小予約 1 を Q2 に割り当てるには、次のコマンドを発行します。
nifnif(config)#interface fastethernet 0/1 nifnif(config-if)#wrr-queue min-reserve ? <1-4> queue id nifnif(config-if)#wrr-queue min-reserve 1 ? <1-8> min-reserve level nifnif(config-if)#wrr-queue min-reserve 1 2 nifnif(config-if)#wrr-queue min-reserve 2 1
次のコマンドを発行すると、結果の最小予約割り当てを確認できます。
nifnif#show mls qos interface fastethernet0/1 buffers FastEthernet0/1 Minimum reserve buffer size: 150 50 100 100 100 100 100 100 !--- This shows the value of all eight min reserve levels. Minimum reserve buffer level select: 2 1 3 4 !--- This shows the min reserve level that is assigned to !--- each queue (from Q1 to Q4).
3550 上のポートでのキューイングとスケジューリングは次の手順で行います。
各 CoS をいずれかのキューに割り当てる。
必要に応じて、完全優先キューを有効にする。
WRR の重み付けを割り当て、キュー内で想定されるパケット サイズを考慮する。
キュー サイズを変更する(ギガビット ポートのみ)。
キュー管理メカニズムを有効にする(テール ドロップまたは WRED、ギガビット ポートのみ)。
適切なキューイングとスケジューリングは、音声/ビデオ トラフィックの遅延/ジッタを減らし、ミッションクリティカルなトラフィックが失われるのを回避できます。スケジューリングのパフォーマンスを最大にするには、必ずこれらのガイドラインに従ってください。
信頼または特定のマーキングを使用して、異なるクラスのネットワークに存在するトラフィックを分類する。
過度なトラフィックをポリシングする。