Quality of Service ソリューション ガイド、 Cisco IOS Release 15.1S
輻輳回避の概要
輻輳回避の概要
発行日;2012/02/03 | 英語版ドキュメント(2011/04/26 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

輻輳回避の概要

テール ドロップ

重み付けランダム早期検出

ランダム早期検出について

機能のしくみ

パケットの廃棄確率

TCP でのトラフィック損失の処理方法

ルータと TCP との相互作用の方法

WRED について

WRED を使用する理由とは

機能のしくみ

平均キュー サイズ

制約事項

分散型重み付けランダム早期検出

機能のしくみ

平均キュー サイズ

パケットの廃棄確率

DWRED を使用する理由とは

制約事項

前提条件

フローベースの WRED

フローベースの WRED を使用する理由とは

機能のしくみ

DiffServ 準拠の WRED

機能のしくみ

使用シナリオ

使用上の注意点

輻輳回避の概要

輻輳回避技術は、コモン ネットワーク ボトルネックでの輻輳を予測し回避するために、ネットワーク トラフィック負荷をモニタします。輻輳の回避は、パケットのドロップにより行われます。より一般的に使用されている輻輳回避メカニズムは Random Early Detection(RED; ランダム早期検出)で、これは高速中継ネットワークに最適です。Cisco IOS QoS には、設定されている場合は、ルータがパケットをドロップする時期をコントロールする RED の実装が含まれています。Weighted Random Early Detection(WRED; 重み付けランダム早期検出)を設定しない場合、ルータは、よりおおまかな、テール ドロップと呼ばれるデフォルトのパケット ドロップ メカニズムを使用します。

ネットワーク輻輳の説明については、「 Quality of Service(QoS)の概要 」の章を参照してください。

この章では、Cisco IOS QoS 機能で行える輻輳回避メカニズムの種類について簡単に説明します。次の機能について説明します。

テール ドロップ。これは、WRED を設定しない場合のデフォルトの輻輳回避動作です。

WRED。WRED および Distributed WRED(DWRED; 分散 WRED)は、両方とも RED のシスコ実装で、RED アルゴリズムの機能を IP Precedence 機能に統合したものです。WRED のセクションで、次の関連機能について説明します。

フローベースの WRED。フローベースの WRED は WRED を拡張し、インターフェイス上のすべてのフローでのパケットのドロップ方法をより均等化します。

DiffServ 準拠の WRED。DiffServ 準拠の WRED は、WRED を拡張し、Differentiated Services(DiffServ; ディファレンシエーテッド サービス)および Assured Forwarding(AF)Per Hop Behavior(PHB)をサポートします。この機能により、Differentiated Service Code Point(DSCP)値に従ってパケットをカラリングし、それらのパケットに優先ドロップ確率を割り当てることで、AF PHB を実装できます。

WRED、DWRED、フローベースの WRED、および DiffServ 準拠の WRED の設定については、「重み付けランダム早期検出の設定」の章を参照してください。

テール ドロップ

テール ドロップでは、すべてのトラフィックを平等に扱い、サービスのクラス間で区別しません。輻輳期間中はキューが一杯になります。出力キューが一杯でテール ドロップが有効な場合、輻輳が解消されてキューが一杯でなくなるまでパケットはドロップされます。

重み付けランダム早期検出

このセクションでは、RED の概念と WRED への対処、標準的な Cisco IOS プラットフォームでの RED のシスコ実装についての概要を説明します。

WRED ではルータの輻輳回避メカニズムとして、テール ドロップを使用する場合に発生する、グローバル化の問題を回避します。グローバル同期は、輻輳の波の頂点として発生し、後には伝送リンクの一部だけが活用されている状態の谷が続きます。TCP ホストのグローバル同期は、たとえば、パケットがいっせいにドロップされるために発生することがあります。グローバル同期は、複数の TCP ホストが伝送レートを、パケットのドロップに応じて低下させる場合に現れます。輻輳が減少すると、再び伝送レートを増加させます。

ランダム早期検出について

RED メカニズムは、対処方式ではなく応答方式でネットワーク輻輳に対応することを目的に Sally Floyd および Van Jacobson によって 1990 年代初めに提唱されました。RED メカニズムは基本的に、ほとんどのトラフィックは、損失しやすいデータ転送が実装されている上を通過しており、トラフィックの一部がドロップすると、一時的に低速になるということを前提としています。TCP は、たとえ堅牢でも、そのトラフィック伝送を低下させることによってトラフィックのドロップに適切に対応し、RED のトラフィックドロップ動作を輻輳回避シグナリング メカニズムとして効果的に動作させることができます。

TCP は、最も良く使用されているネットワーク伝送となっています。TCP が普遍的に存在することで、RED は幅広い、効果的な輻輳回避メカニズムを実現します。

TCP のような堅牢な伝送が行き渡っている場合の RED の有用性を考える際、かなりの割合のトラフィックがパケット損失に対して堅牢ではない場合に RED を採用することの、重大なマイナスの結果も考えることが重要です。Novell NetWare と AppleTalk の両方とも、パケット損失の点では十分堅牢ではないため、RED をこれらに使用するべきではありません。

機能のしくみ

RED は、パケットの伝送が一時的に低下しているエンド ホストに指示することで、平均キュー サイズをコントロールすることを目的としています。

RED は、TCP の輻輳コントロール メカニズムを利用します。高輻輳期間の前にランダムにパケットをドロップすることにより、RED はパケットの送信元に、その伝送レートを低下させるよう指示します。そのパケットの送信元が TCP を使用している場合、すべてのパケットがその宛先に到達する、つまり輻輳がなくなったことが示されるまで伝送レートを下げます。RED を、TCP のパケットの転送速度を下げる方法として使用できます。TCP は停止するだけでなく、素早く再起動して、ネットワークがサポート可能なレートに伝送レートを対応させます。

RED は、損失を一定間隔で分散し、波を吸収しながら通常の低いキュー深度を維持します。インターフェイスでイネーブルにすると、RED は、設定時に選択したレートで輻輳が発生した場合にパケットのドロップを開始します。

シスコの WRED 実装での、WRED キュー サイズ計算で使用するパラメータの決定方法と、重み付け要素に使用する最適な値の決定方法については、この章の後半のセクション「平均キュー サイズ」を参照してください。

パケットの廃棄確率

パケットの廃棄確率は、最低しきい値、最高しきい値、およびマーク確率値です。

平均のキュー深度が最低しきい値より大きい場合、RED はパケットのドロップを開始します。パケットのドロップ率は、平均キュー サイズの増加に対して、平均キュー サイズが最高しきい値に達するまで直線的に増加します。

マーク確率値は、平均キュー 深度が最高しきい値の場合のドロップしたパケットの比です。たとえば、分母が 512 の場合、512 パケットごとに 1 つのパケットが、平均キューが最大しきい値にあるときにドロップします。

平均キュー サイズが最大しきい値を超えた場合、すべてのパケットがドロップします。図 1で、パケットの廃棄確率をまとめています。

図 1 RED パケットの廃棄確率

 

最低しきい値は、リンクを最大限活用するのに十分な高さに設定してください。最低しきい値が低すぎると、パケットが不必要にドロップされ、伝送リンクが最大限に使用されません。

最大しきい値と最低しきい値の差は、TCP ホストのグローバル同期を避けるのに十分な大きさにしてください(TCP ホストのグローバル同期は、複数の TCP ホストの伝送レートが低下して発生することがあります)。最大および最低しきい値の差が小さすぎると、一度に多くのパケットがドロップし、グローバル同期につながることがあります。

TCP でのトラフィック損失の処理方法


) セクション「TCP でのトラフィック損失の処理方法」および「ルータと TCP との相互作用の方法」に、WRED を使用するためや、RED の一般的な機能を備えるためには読まなくてもよい詳細情報が記載されています。テール ドロップがデフォルトで使用されている場合に、輻輳の発生に応じてグローバル同期の問題が起こる理由と、RED のこの問題への対処方法を知りたい場合は、これらのセクションを参照してください。


TCP トラフィックの受け手(受信者と呼びます)がデータ セグメントを受信すると、データ セグメントが順番に受信されたことを示す、受信者が予想している番号に対し、セグメントの 4 オクテット(32 ビット)のシーケンス番号がチェックされます。この番号が一致すると、受信者は、ターゲット アプリケーションに保持されているデータをすべて送信し、シーケンス番号をアップデートして、次の順番の番号を反映します。最後に、Acknowledgment(ACK; 確認応答)パケットを送信者にただちに送信するか、短い遅延の後で送信者に送信するよう ACK をスケジューリングします。ACK は送信者に、受信者が、到着したすべてのデータ セグメントを受信したが、新しいシーケンス番号でマークされたセグメントは含まれていないことを通知します。

受信者は通常、ACK を、受信したデータ セグメントと交換で送信しようとします。多くのアプリケーションで、受信者が短い遅延が終わるまで待機している場合、通常の送信者への応答に、応答認識を効果的に含めることができるため、ACK を送信します。しかし、受信者がデータ セグメントをばらばらの順番で受信した場合、ACK をただちに返信し、送信者に、損失したデータ セグメントを再送するよう指示します。

送信者が ACK を受信すると、未処理のデータがあるかどうかが調査されます。未処理のデータがない場合、送信者は、ACK がキープアライブであると決定します。つまり、回線をアクティブのままにし、何もしません。未処理のデータがある場合、送信者は、受信者がデータの一部を受け取ったか、まったく受け取っていないかが ACK に示されているかを確認します。ACK に、送信データの一部を受領していることが示されている場合、送信者は、さらにデータを送信できる新しいクレジットが付与されているかどうかを確認します。ACK に、送信したデータがまったく受領されていないことが示されている場合で、未処理のデータがある場合は、送信者はこの ACK を、再送信が繰り返されている ACK であると解釈します。この状態は、一部のデータがばらばらの順番で受信され、受信者が最初の ACK を強制的に送信し、2 番めのデータ セグメントが、ばらばらの順番で受信され、受信者が別の ACK を強制的に送信したことを示しています。多くの場合、データ セグメントのうち 1 つがドロップしたため、受信者は 2 つのセグメントをばらばらの順番で受け取ります。

TCP 送信者は、ドロップしたデータ セグメントを検出し、そのセグメントを再送信します。その後、転送レートを、ドロップが検出される前の半分に調整します。これが、TCP のバックオフまたは低速化動作です。この動作は、輻輳に対し適切に対応しますが、複数の TCP セッションが同じルータで同時に実行され、すべての TCP 送信者が同時にパケットの送信速度を低下させたときに問題が発生する場合があります。

ルータと TCP との相互作用の方法


) セクション「TCP でのトラフィック損失の処理方法」および「ルータと TCP との相互作用の方法」に、WRED を使用するためや、RED の一般的な機能を備えるためには読まなくてもよい詳細情報が記載されています。テール ドロップがデフォルトで使用されている場合に、輻輳の発生に応じてグローバル同期の問題が起こる理由と、RED のこの問題への対処方法を知りたい場合は、これらのセクションを参照してください。


ルータがどのように TCP と相互作用するかを、例で確認します。この例では、平均して、ルータは、MAE-EAST または FIX-WEST のインターフェイスの 1 つおき、10 個おき、100 個または 200 個おきのメッセージごとに 1 つの特定の TCP ストリームからトラフィックを受信します。ルータは、複数の TCP セッションを同時に処理できます。ネットワーク フローが加法型なため、トラフィックが Transmit Queue Limit(TQL; 送信キュー制限)を超えた場合はすべて、制限を大きく超える可能性が非常に高くなります。ただし、超過トラフィックの深度が一時的で、トラフィック フローが統合するポイントやエッジ ルータを除き、トラフィックが過度に深いままにはならない可能性も大いにあります。

ルータが、TQL を超えるトラフィックをすべてドロップした場合、テール ドロップがデフォルトで使用された場合と同じように、多くの TCP セッションが同時にスロー スタートが開始されます。したがって、トラフィックは一時的に極端に低速になり、すべてのフローが再度スロースタートで処理されます。この動作により、グローバル同期の状態が作り出されます。

しかし、均等化キューイングまたは Custom Queueing(CQ; カスタム キューイング)などのキューイング機能が使用されている場合と同様に、ルータがトラフィックをドロップしない場合、データはメイン メモリに格納されることが多く、ルータの性能が著しく低下します。

一度に 1 つの TCP セッションの速度低下を指示することで、RED は上記の問題を解決し、トラフィックの使用が山と谷として現れずに、帯域幅を完全に使用することができます。

WRED について

WRED は、RED アルゴリズムの機能を IP Precedence 機能と統合して、優先順位の高いパケットの優先的なトラフィック処理を実現します。WRED では、インターフェイスで輻輳が発生し始めると、優先順位が低いトラフィックを選択的に廃棄し、異なるサービス クラスに対して差別化したパフォーマンス特性を提供できます。

重み付けされていない RED の動作が行われるように、ドロップの決定を行う際に IP Precedence を無視するよう WRED を設定できます。

Resource Reservation Protocol(RSVP; リソース予約プロトコル)機能を使用するよう設定されたインターフェイスでは、WRED は、RSVP フロー以外の他のフローから、ドロップするパケットを選択します。また、IP Precedence で、どのパケットをドロップするかを制御します。優先順位の低いトラフィックは、ドロップ率が高く、抑制されやすくなります。

WRED は、キューイング戦略のような他の輻輳回避技術とは異なります。発生した輻輳をコントロールするのではなく、輻輳を予測し回避しようとするためです。

WRED を使用する理由とは

WRED は、輻輳の可能性を早期検出し、複数のトラフィック クラスを実現します。また、グローバル同期に対して保護されます。そのため、WRED は輻輳が発生すると予測されるいずれの出力インターフェイスでも有用です。

ただし、WRED は通常は、ネットワークのエッジではなくネットワークのコア ルータで使用されます。エッジ ルータは、ネットワークに送信されてくるパケットに IP Precedence を割り当てます。WRED は、これらの優先順位を使用して、異なる種類のトラフィックの処理方法を定義します。

WRED は個別のしきい値と重み付けを、それぞれの IP Precedence に使用し、異なるトラフィックの種類でのパケットのドロップに対し、異なるサービス品質を実現できます。標準的なトラフィックは、輻輳時には、優先度の高いトラフィックよりも頻繁にドロップされる可能性があります。

また WRED は、RSVP を認識し、統合サービスの負荷制御型 QoS サービスも提供します。

機能のしくみ

高輻輳期間の前にランダムにパケットをドロップすることにより、WRED はパケットの送信元に、その伝送レートを低下させるよう指示します。そのパケットの送信元が TCP を使用している場合、すべてのパケットがその宛先に到達する、つまり輻輳がなくなったことが示されるまで伝送レートを下げます。

WRED では一般的に、IP Precedence に基づいてパケットを選択的にドロップします。より高い IP Precedence のパケットは、低い IP Precedence のパケットよりもドロップしにくくなります。したがって、パケットの優先順位が高いほど、パケットが送信される確率が高くなります。

WRED は、出力インターフェイスが、輻輳の兆候を示し始めると選択的にパケットをドロップすることで、テール ドロップの確率を減らします。キューがいっぱいになるのを待たずに、早期にパケットの一部をドロップすることで、WRED は一度に大量のパケットがドロップしないようにし、グローバル同期の確率を最低限にします。このように、WRED は、いつでも伝送ラインをいっぱいに使用することができるようにします。

さらに、WRED は統計的に、小さなユーザよりも大きなユーザから、より大きなパケットをドロップします。したがって、トラフィックの大部分を生成しているトラフィック発信元は、生成しているトラフィックが少しのトラフィック発信元よりも速度が低下しやすくなります。

WRED では、テール ドロップが輻輳回避メカニズムとして使用される場合に発生する、グローバル化の問題を回避します。グローバル同期は、複数の TCP ホストが伝送レートを、パケットのドロップに応じて低下させる場合に現れます。輻輳が減少すると、再び伝送レートを増加させます。

WRED は、ほとんどのトラフィックが TCP/IP トラフィックである場合にだけ有用です。TCP では、破棄されたパケットは輻輳を示しているため、パケットの発信元は伝送レートを低くします。他のプロトコルでは、パケットの発信元は応答しないか、または破棄されたパケットを同じレートで再送信します。このため、パケットを破棄しても輻輳は削減されません。

WRED は非 IP トラフィックを優先度 0 の最低優先順位として扱います。したがって、非 IP トラフィックは通常、IP トラフィックよりもドロップしやすくなります。

図 2に、WRED の動作方法について図示します。

図 2 重み付けランダム早期検出

 

平均キュー サイズ

ルータで、WRED 計算で使用するパラメータが自動的に定義されます。平均キュー サイズは、キューの前回の平均と現在のサイズを基にしています。式は次のようになります。

average = (old_average * (1-2 -n)) + (current_queue_size * 2 -n)
 

ここで、 n は指数加重係数で、ユーザが設定可能な値です。指数加重係数のデフォルト値は 9 です。指数加重係数にはデフォルト値のみ使用することを推奨します。この値は、使用シナリオが、異なる値を使用することで利点を得られることがわかった場合にのみ、デフォルト値から変更してください。

n を高い値にすると、前回の平均が重要視されます。係数を大きくすると、キューの長さの最大値と最小値が滑らかになります。平均キュー サイズは、素早い変化はしにくく、サイズの急激な増減を回避します。WRED 処理で、パケットのドロップの開始が遅くなりますが、実際のキュー サイズが最低しきい値を下回った時点でも、パケットのドロップが続く場合があります。平均がゆっくり変化するため、トラフィックの一時的なバーストに対応します。


n の値が高すぎる場合、WRED は輻輳に反応しません。パケットは、WRED が無効のときのように送信またはドロップします。


n の値が低い場合、平均キュー サイズは現在のキュー サイズ付近を追跡します。結果、平均はトラフィック レベルの変化とともに上下します。この場合、WRED 処理は、長いキューに素早く応答します。キューが最低しきい値を下回ると、パケットのドロップ処理が停止します。

n の値が低すぎると、WRED は一時的なトラフィック バーストに過剰に反応し、不必要にトラフィックをドロップします。

制約事項

Route Switch Processor(RSP; ルート スイッチ プロセッサ)ベースの CQ、Priority Queueing(PQ; プライオリティ キューイング)、Weighted Fair Queueing(WFQ; 重み付け均等化キューイング)と同じインターフェイス上に WRED を設定することはできません。

分散型重み付けランダム早期検出

Distributed WRED(DWRED; 分散 WRED)は、Versatile Interface Processor(VIP)向けの WRED の実装です。DWRED は、WRED が標準 Cisco IOS プラットフォームで実現する VIP 向け機能の一式を完全に提供します。

DWRED 機能は、RSP ベースの RSP 7000 インターフェイス プロセッサ搭載 Cisco 7000 シリーズ ルータおよび VIP ベース VIP2-40 以降のインターフェイス プロセッサ搭載 Cisco 7500 シリーズ ルータでのみサポートされます。VIP のポート アダプタの集約ライン レートが DS3 を上回る場合は、VIP2-50 インターフェイス プロセッサを強く推奨します。OC-3 レートには VIP2-50 インターフェイス プロセッサが必要です。

DWRED は WRED と同様に設定します。VIP2-40 以降などの、2 MB の SRAM を搭載した DWRED に適した VIP インターフェイスで WRED をイネーブルにすると、DWRED が代わりにイネーブルになります。

DWRED を使用するには、distributed Cisco Express Forwarding(dCEF; 分散型シスコ エクスプレス フォワーディング)スイッチングがインターフェイスでイネーブルになっている必要があります。dCEF については、『 Cisco Express Forwarding Features Roadmap 』モジュールを参照してください。

DWRED と Distributed Weighted Fair Queueing(DWFQ; 分散型重み付け均等化キューイング)の両方を同じインターフェイスで設定できますが、分散 WRED を、RSP ベースの CQ、PQ、WFQ が設定されているインターフェイスで設定することはできません。

Modular Quality of Service Command-Line Interface(Modular QoS CLI)機能を使用して、DWRED をイネーブルにできます。Modular QoS CLI 機能に関する考え方や設定情報については、『 Applying QoS Features Using the MQC 』モジュールを参照してください。

機能のしくみ

パケットが到着し、DWRED がイネーブルになると、次のイベントが発生します。

平均キュー サイズが計算されます。詳細は「平均キュー サイズ」を参照してください。

平均が最低キューしきい値未満の場合は、到着したパケットはキューイングされます。

平均が、最低キューしきい値と最大キューしきい値の間の場合、パケットは、パケットの廃棄確率に応じてドロップまたはキューイングされます。詳細は「パケットの廃棄確率」を参照してください。

平均キュー サイズが最大キューしきい値を超える場合、パケットは自動的にドロップします。

平均キュー サイズ

平均キュー サイズは、キューの前回の平均と現在のサイズを基にしています。式は次のようになります。

average = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)
 

ここで、n は指数加重係数で、ユーザが設定可能な値です。

n を高い値にすると、前回の平均キュー サイズがより重要視されます。係数を大きくすると、キューの長さの最大値と最小値が滑らかになります。平均キュー サイズは、素早い変化はしにくく、サイズの急激な増減を回避します。WRED 処理で、パケットのドロップの開始が遅くなりますが、実際のキュー サイズが最低しきい値を下回った時点でも、パケットのドロップが続く場合があります。平均がゆっくり変化するため、トラフィックの一時的なバーストに対応します。


) n の値が高すぎる場合、WRED は輻輳に反応しません。パケットは、WRED が無効のときのように送信またはドロップします。


n の値が低い場合、平均キュー サイズは現在のキュー サイズ付近を追跡します。結果、平均はトラフィック レベルの変化とともに上下します。この場合、WRED 処理は、長いキューに素早く応答します。キューが最低しきい値を下回ると、パケットのドロップ処理が停止します。

n の値が低すぎると、WRED は一時的なトラフィック バーストに過剰に反応し、不必要にトラフィックをドロップします。

パケットの廃棄確率

パケットがドロップする確率は、最低しきい値、最大しきい値、マーク確率値に基づきます。

平均キュー サイズが最低しきい値より大きい場合、RED はパケットのドロップを開始します。パケットのドロップ率は、平均キュー サイズの増加に対して、平均キュー サイズが最高しきい値に達するまで直線的に増加します。

マーク確率値は、平均キュー サイズが最高しきい値の場合のドロップしたパケットの端数です。たとえば、分母が 512 の場合、512 パケットごとに 1 つのパケットが、平均キューが最大しきい値にあるときにドロップします。

平均キュー サイズが最大しきい値を超えた場合、すべてのパケットがドロップします。図 3で、パケットの廃棄確率をまとめています。

図 3 パケットの廃棄確率

 

最低しきい値は、リンクを最大限活用するのに十分な高さに設定してください。最低しきい値が低すぎると、パケットが不必要にドロップされ、伝送リンクが最大限に使用されません。

最大しきい値と最低しきい値の差は、TCP ホストのグローバル同期を避けるのに十分な大きさにしてください(TCP ホストのグローバル同期は、複数の TCP ホストの伝送レートが低下して発生することがあります)。最大および最低しきい値の差が小さすぎると、一度に多くのパケットがドロップし、グローバル同期につながることがあります。

DWRED を使用する理由とは

DWRED は、RSP ベースの WRED よりも速いパフォーマンスを提供します。Cisco 7500 シリーズ プラットフォームで、非常に速い速度を得たい場合は VIP で DWRED を実行してください。たとえば、WRED を VIP2-50 インターフェイス プロセッサで実行すると、OC-3 レートの速度を得られます。

また、WRED を標準の Cisco IOS プラットフォームで使用するのと同じ理由が、DWRED にも当てはまります(この章の前半のセクション「WRED を使用する理由とは」を参照してください)。たとえば、WRED または DWRED が設定されていない場合、テール ドロップが輻輳時に設定されます。DWRED をイネーブルにすると、輻輳回避のためにテール ドロップが使用されたときに起こるグローバル同期問題を未然に防ぐことができます。

DWRED 機能を使用することで、トラフィック フローが一定になります。RED が設定されていない場合、輻輳中は出力バッファが一杯になります。バッファが一杯の場合、テール ドロップが発生します。後から来たパケットはすべてドロップします。パケットが一度にすべてドロップするため、複数の TCP ホストで伝送レートの低下が起こり、TCP ホストのグローバル同期が発生することがあります。輻輳が解消され、TCP ホストが伝送レートを増加させると、伝送リンクが完全に使用されない期間の後に続き輻輳の波が起こります。

RED は、出力インターフェイスが輻輳の兆候を示し始めると、選択的にパケットをドロップしてテール ドロップの確率を減らします。バッファが一杯になるのを待たずに、早期にパケットの一部をドロップすることで、RED は一度に大量のパケットがドロップしないようにし、グローバル同期の確率を最低限にします。このように、RED は、いつでも伝送ラインを一杯に使用できるようにします。

さらに、RED は統計的に、小さなユーザよりも大きなユーザから、より大きなパケットをドロップします。したがって、トラフィックの大部分を生成しているトラフィック発信元は、生成しているトラフィックが少しのトラフィック発信元よりも速度が低下しやすくなります。

DWRED で、異なる IP Precedence に個別のしきい値と重み付けを設定でき、異なるトラフィックに異なる QoS を適用できます。標準的なトラフィックは、輻輳時には、優先度の高いトラフィックよりも頻繁にドロップされる可能性があります。

制約事項

DWRED 機能には、次のような制約事項が適用されます。

インターフェイスベースの DWRED は、サブインターフェイスでは設定できません(サブインターフェイスは、単一の物理インターフェイスの、いくつかの仮想インターフェイスのうちの 1 つです)。

DWRED は、Fast EtherChannel およびトンネル インターフェイスではサポートされません。

RSVP は、DWRED ではサポートされません。

DWRED は、ほとんどのトラフィックが TCP/IP トラフィックである場合にだけ有用です。TCP では、破棄されたパケットは輻輳を示しているため、パケットの発信元は伝送レートを低下させます。他のプロトコルでは、パケットの発信元は応答しないか、または破棄されたパケットを同じレートで再送信します。このため、パケットを破棄しても、必ずしも輻輳は削減されません。

DWRED は非 IP トラフィックを優先度 0 の最低優先順位として扱います。したがって、非 IP トラフィックは通常、IP トラフィックよりもドロップしやすくなります。

DWRED は、RSP ベース CQ、PQ または WFQ と同じインターフェイスでは設定できません。ただし、DWRED と DWFQ の両方を同じインターフェイスで設定することはできます。


) 一致基準として非 IP プロトコルを使用したトラフィック クラスの作成に、match protocol コマンドは使用しないでください。VIP は、非 IP プロトコルのマッチングをサポートしません。


前提条件

このセクションでは、DWRED 機能を設定する前に満たしておく必要がある前提条件について説明します。

重み付け均等化キューイング

サービス ポリシーをインターフェイスに適用すると、WFQ がそのインターフェイスに設定されている場合、その WFQ はディセーブルになります。このため、DWRED を設定する前に、このようなインターフェイスで WFQ をイネーブルにしないようにしてください。

WFQ については、本書の「重み付け均等化キューイングの設定」の章を参照してください。

WRED

インターフェイスに、WRED を使用するよう設定したサービス ポリシーを適用すると、そのインターフェイスでは WRED がディセーブルになります。ポリシー マップで設定したトラフィック クラスで、パケットのドロップにテール ドロップではなく WRED を使用する場合、WRED がこのサービス ポリシーを適用しようとしているインターフェイスで設定されないようにしてください。

アクセス コントロール リスト

番号を付けたアクセス リストを、作成した任意のトラフィック クラスの一致基準として指定できます。したがって、DWRED を設定する前に、アクセス リストの設定方法を知っておく必要があります。

シスコ エクスプレス フォワーディング

DWRED を使用するには、dCEF スイッチングをインターフェイスでイネーブルにする必要があります。dCEF については、『 Cisco Express Forwarding Features Roadmap 』モジュールを参照してください。

フローベースの WRED

フローベースの WRED 機能では、パケットをドロップする方法に関して、インターフェイス上のすべてのフローをより公平に扱うよう WRED に指示します。

フローベースの WRED を使用する理由とは

提供されているフローベースの WRED の使用の利点を考える前に、異なる種類のパケット フローに WRED が与える影響(フローベースの WRED が設定されていない状態で)について考えてみます。フローベースの WRED がパケット フローを分類する前でも、フローは、次のカテゴリのいずれかに属するものとして考えられます。

非適応フロー。輻輳の影響を受けないフローです。

堅牢なフロー。平均して、一定のデータ レートで、輻輳に対応して低速になります。

脆弱なフロー。輻輳を認識していても、堅牢なフローよりもゲートウェイでのパケットのバッファが少ないフローです。

出力キューに比較的少ないパケットも含めてすべてのフローは、輻輳時にはパケット ドロップの影響を受けやすいため、WRED は脆弱なフローに対しバイアスをかけることが多くあります。脆弱なフローは、バッファされるパケットが少ないため、他のフローのパケットと同じレートでドロップします。

すべてのフローを均等にするため、フローベースの WRED には次の機能があります。

バッキング オフ パケット送信により WRED パケット ドロップに応答するフローは、WRED パケット ドロップに応答しないフローから保護されます。

1 つのフローがインターフェイスのバッファ リソースを独占するのを禁止します。

機能のしくみ

フローベースの WRED は、次の 2 つの主な手法によって、不均等なパケットのドロップを改善します。

着信トラフィックを、宛先および送信元アドレス、ポートなどのパラメータに基づいて分類する。

アクティブなフロー(出力キューにパケットがあるフロー)に関するステータスを維持する。

フローベースの WRED は、この分類とステータス情報を使用して、各フローが出力バッファ リソースを、許可した共有よりも多く使用しないかを確認します。フローベースの WRED は、どのフローがリソースを独占しているか決定し、そのフローにより重いペナルティを課します。

フロー間で均等性を確保するため、フローベースの WRED は出力インターフェイスに存在するアクティブ フローの数をカウントし、保持します。フローベースの WRED は、アクティブ フロー数と出力キュー サイズから、フローごとに使用可能なバッファ数を決定します。

ある程度のバースト性を許容するため、フローベースの WRED は、フローごとに使用可能なバッファ数を、係数を設定することで測定し、各アクティブ フローが、出力キューで特定のパケット数を保持できるようにします。このスケール係数は、すべてのフローで共通です。測定したバッファ数の結果は、フローごとの制限になります。フローが、フローごとの制限を超えると、そのフローからのパケットがドロップする確率が高まります。

DiffServ 準拠の WRED

DiffServ 準拠の WRED で、DiffServ および AF Per Hop Behavior PHB をサポートできるよう WRED の機能を拡張します。この機能により、DSCP 値に従ってパケットをカラリングし、それらのパケットに優先ドロップ確率を割り当てることで、AF PHB を実装できます。


) この機能は、IP パケットでのみ使用できます。Multiprotocol Label Switching(MPLS; マルチプロトコル ラベル スイッチング)カプセル化パケットで使用することは意図されていません。


クラスベースの QoS MIB でこの機能をサポートしています。この MIB は、実際は次の 2 つの MIB です。

CISCO-CLASS-BASED-QOS-MIB

CISCO-CLASS-BASED-QOS-CAPABILITY-MIB

DiffServ 準拠の WRED 機能では、次の RFC をサポートしています。

RFC 2474、『 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

RFC 2475、『 An Architecture for Differentiated Services Framework

RFC 2597、『 Assured Forwarding PHB

RFC 2598、『 An Expedited Forwarding PHB

機能のしくみ

DiffServ 準拠の WRED 機能で、パケットの廃棄確率を計算する場合に WRED で DSCP 値を使用できるようにします。DSCP 値は、IP Type of Service(ToS; タイプ オブ サービス)バイトの最初の 6 ビットです。

この機能で、 random-detect dscp および dscp の 2 つの新しいコマンドが追加されます。また、 dscp-based および prec-based の 2 つの新しい引数を 、既存の random-detect (インターフェイス)コマンドおよび random-detect-group コマンドの 2 つの WRED 関連コマンドに追加します。

dscp-based 引数で、パケットの廃棄確率を計算する際のパケットの DSCP 値を WRED で使用できます。 prec-based 引数で、パケットの廃棄確率を計算する際のパケットの IP Precedence 値を WRED で使用できます。

これらの引数は、任意です(このコマンドを使用するために、これらの引数のいずれかを必ずしも使用しなくてもかまいません)が、二者択一です。つまり、 dscp-based 引数を使用する場合は、同じコマンドで prec-based 引数は使用できません。

WRED で DSCP 値を使用できるようにしたら、新しい random-detect dscp コマンドを使用して、DSCP 値の最低および最高パケットしきい値を変更できます。

3 つの引数を使用するための 3 つのシナリオが用意されています。

使用シナリオ

新しい dscp-based および prec-based 引数は、インターフェイス レベル、per-Virtual Circuit(VC; 仮想回線)レベル、またはクラス レベル(ポリシー マップを使用した Class-based WFQ(CBWFQ; クラスベース WFQ)の一部として)のどのレベルで WRED を使用するかに関わらず、使用できます。

インターフェイス レベルの WRED

インターフェイス レベルでは、パケットの廃棄確率の計算の際に WRED で DSCP 値を使用する場合、 random-detect (インターフェイス)コマンドで dscp-based 引数を使用して、DSCP 値を指定します。その後、 random-detect dscp コマンドを使用して、DSCP 値の最低および最高しきい値を指定します。

VC 単位レベルの WRED

VC 単位レベルでは、パケットの廃棄確率の計算の際に WRED で DSCP 値を使用する場合、 random-detect-group コマンドで dscp-based 引数を使用できます。その後、 dscp コマンドを使用して、DSCP 値またはマーク確率値の最低および最高しきい値を指定します。

この設定は、ネットワークの各 VC に適用できます。

クラス レベルの WRED

クラス レベルで WRED を使用(CBWFQ とともに)する場合、 dscp-based および prec-based 引数をポリシー マップで使用できます。

最初に、ポリシー マップ、クラス、帯域幅を指定します。次に、廃棄確率を計算する際に WRED で DSCP を使用する場合は、 random-detect (インターフェイス)コマンドで dscp-based 引数を使用して DSCP 値を指定します。その後、 random-detect dscp コマンドを使用して、DSCP 値のデフォルトの最低および最高しきい値を修正します。

この設定は、ポリシー マップが適用される場所ではどこでも適用できます(インターフェイス レベル、VC 単位レベル、シェーパー レベルなど)。

使用上の注意点

この機能に含まれる新しいコマンドと引数を使用する際は、次の点に留意してください。

dscp-based 引数を使用する場合、WRED では廃棄確率の計算に DSCP が使用されます。

prec-based 引数を使用する場合、WRED では廃棄確率の計算に IP Precedence 値が使用されます。

dscp-based および prec-based 引数は、二者択一です。

いずれの引数も指定しない場合、WRED では廃棄確率の計算に IP Precedence 値が使用されます(デフォルトの方式です)。

random-detect dscp コマンドは、 random-detect (インターフェイス)コマンドと併用してください。

random-detect dscp コマンドは、 dscp-based 引数が random-detect (インターフェイス)コマンドで使用されている場合にのみ使用できます。

dscp コマンドは、 random-detect-group コマンドと併用してください。

dscp コマンドは、 dscp-based 引数が random-detect-group コマンドで使用されている場合にのみ使用できます。

この 3 つのコマンドの使用の詳細については、『 Cisco IOS Quality of Service Solutions Command Reference 』を参照してください