12000シリーズルータでのMDRR/WREDの理解と設定

ダウンロード オプション

  • PDF     (449.0 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (127.8 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (204.5 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2008 年 3 月 6 日
Document ID:18841

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

この文書では、Cisco 12000 シリーズ インターネット ルータで、Cisco IOS(R) ソフトウェアの輻輳管理機能と輻輳回避機能を設定する方法について説明します。

このドキュメントを読むと、次のことを習得できます。

  • Modified Deficit Round Robin（MDRR）および重み付けランダム早期検出（WRED）を中核となるネットワークに設定することの重要性。

  • Cisco 12000 シリーズでの MDRR と WRED の基本的な実装方法。

  • 従来のクラス オブ サービス（CoS）構文とモジュラ QoS CLI（MQC）を使用した MDRR と WRED の設定。

前提条件

要件

このドキュメントの読者は次のトピックについての専門知識を有している必要があります。

  • Cisco 12000 シリーズ インターネット ルータ アーキテクチャに関する全般的知識。

  • 特に、キューイング アーキテクチャと以下の用語に関する認識：

    • ToFab（Towards the fabric）：着信ラインカードの受信側のキュー

    • FrFab（From the fabric）：発信ラインカードの送信側のキュー

注：show controller frfabの出力の読み方を調べることもお勧めします | tofab queueコマンドを使用します。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

  • すべての Cisco 12000 プラットフォーム（12008、12012、12016、12404、12406、12410、および 12416 が含まれます）。

  • Cisco IOS ソフトウェア リリース 12.0(24)S1。

注：このドキュメントの設定はCisco IOSソフトウェアリリース12.0(24)S1でテストされていますが、Cisco 12000シリーズインターネットルータをサポートするCisco IOSソフトウェアリリースを使用できます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。

背景説明

キューイング方法は、パケット スケジューリング メカニズム（つまり、パケットがキューから取り出されて物理ワイヤでの転送用のインターフェイスに送られる順序）を定義します。キューイング方法は、キューがスケジューラ機能からサービスを受ける順番や回数をベースとして、最小帯域幅の保証や低遅延についてもサポートしています。

パケット スケジューリング メカニズムが、実装先のスイッチング アーキテクチャをサポートすることが重要です。重み付け均等化キューイング（WFQ）は、バスベースのアーキテクチャを持つ Cisco ルータ プラットフォームでリソース割り当てを行うためのよく知られたスケジューリング アルゴリズムです。ただし、Cisco 12000 シリーズ インターネット ルータではサポートされていません。さらに、従来の Cisco IOS ソフトウェア プライオリティ キューイングおよびカスタム キューイングもサポートされていません。代わりに、Cisco 12000 シリーズでは、相対帯域幅の保証と低遅延キューを提供する、Modified Deficit Round Robin（MDRR）と呼ばれる特別なキューイングを使用します。MDRR の M は、「modified（変更された）」を表し、DRR にプライオリティ キューを追加したことを意味します。MDRR の詳細は、「MDRR の概要」を参照してください。

さらに、Cisco 12000 シリーズでは、MDRR キュー内でドロップ ポリシーとして重み付けランダム早期検出（WRED）をサポートしています。この輻輳回避メカニズムは、デフォルトのテール ドロップ メカニズムの代わりになります。ドロップを制御することで、輻輳を回避できます。

輻輳回避および管理メカニズム（WRED、MDRR など）は、チャネル化ラインカード（LC）などの比較的低速な発信インターフェイスの FrFab キューで特に重要です。 高速スイッチ ファブリックは、チャネル グループが転送できるよりもはるかに高速にチャネル グループにパケットを転送できます。キューイングおよびバッファは物理ポート レベルで管理されるため、1 つのチャネルに対するバックプレッシャがそのポートの他のすべてのチャネルに影響を及ぼす可能性があります。したがって、WRED や MDRR でバックプレッシャを管理することは非常に大切であり、これによって問題となる他のチャネルへの影響を抑えることができます。発信インターフェイスの加入過多の管理の詳細は、「トトラブルシューティング：Cisco 12000 シリーズ インターネット ルータでの ignored エラーとメモリ不足によるドロップ」を参照してください。

MDRR の概要

この項では、Modified Deficit Round Robin（MDRR）の概要を説明します。

MDRR がキューイング方式として設定されている場合、空でないキューがラウンドロビン方式で順に処理されます。キューが処理されるごとに、一定量のデータがキューから取り出されます。その後、次のキューが処理されます。キューが処理されるとき、MDRR は、設定値を超えてキューから取り出されたデータのバイト数を追跡します。次のパスでそのキューが再び処理されるときは、以前に余分に処理されたデータの分だけキューから取り出されるデータが少なくなります。その結果、キューあたりキューから取り出されるデータの量は設定値に近づきます。加えて、MDRR は、優先的に処理されるプライオリティ キューを保守します。MDRR については、この項で詳しく説明します。

MDRR 内部の各キューは次の 2 つの変数によって定義されます。

  • Quantum 値：各ラウンドで処理されるクォンタム値のバイト数の平均です。

  • Deficit カウンタ：各ラウンドでキューから転送されたバイト数を追跡するために使用される不足カウンタ。不足カウンタはクォンタム値に初期化されます。

キュー内のパケットは、デフィシット カウンタが 0 よりも大きい限り処理されます。処理されたパケットは、それぞれそのバイト長に等しい値だけデフィシット カウンタを減らします。デフィシット カウンタが 0 以下になると、キューは処理されません。新しいラウンドごとに、空でない各キューのデフィシット カウンタがクォンタム値の分だけ増分されます。

注：一般に、キューのクォンタムのサイズは、インターフェイスの最大伝送ユニット(MTU)より小さくすることはできません。これにより、スケジューラは、空でない各キューから少なくとも 1 つのパケットを常に取り出します。

それぞれの MDRR キューは、グループにあるキューのうちの 1 つをプライオリティ キューとすることで、相対的な重みを与えることができます。この重みにより、インターフェイスで輻輳が発生しているときの各キューの相対帯域幅が割り当てられます。MDRR アルゴリズムは、送信すべきデータがキュー内にある場合に、ラウンドロビン方式で各キューからデータを取り出します。

通常の MDRR キューすべてにデータがある場合、それらは次のように処理されます。

0-1-2-3-4-5-6-0-1-2-3-4-5-6...

各サイクルの間、設定されている重みに基づいてクォンタムがキューから取り出されます。エンジン 0 およびエンジン 2 のラインカード上では、値 1 は、インターフェイスにその MTU の重みを与えることを意味します。値が 1 を超える場合は、1 増えるごとにキューの重みが 512 バイトずつ増えていきます。たとえば、特定のインターフェイスの MTU が 4470 で、キューの重みが 3 に設定されている場合、ローテーションを経過するたびに 4470 + (3-1)*512 = 5494 バイトをキューから取り出すことが許可されます。通常のDRRキューQ0とQ1が2つ使用されている場合、Q0には重み1が設定され、Q1には9が設定されます。両方のキューが輻輳している場合、回転するたびにQ0から4470バイトが送信され、Q1から[44470 + (9-1) 2] = 8566バイト。この結果、Q0 へ流れるトラフィックには帯域幅の約 3 分の 1 が与えられ、Q1 を通過するトラフィックには帯域幅の約 3 分の 2 が与えられます。

注：MDRR帯域幅割り当ての計算に使用される標準のデキュー式はD = MTU + (weight-1)*512です。Cisco IOSソフトウェアリリース12.0(21) S/STより前のバージョンでは、エンジン4のラインカードは異デキュー式を使用していました。帯域幅が正しく割り当てられるようにMDRR 重み付けを設定するには、必ずリリース 12.0(21)S/ST よりも後のバージョンの Cisco IOS ソフトウェアを実行してください。

注：エンジン4+ラインカードのクォンタム式は（toFab方向の場合、これはFrFabには有効ではありません） Quantum = BaseWeight + {BaseWeight * (QueueWeight - 1) * 512} / MTUです。BaseWeight を求める式は、BaseWeight = {(MTU + 512 - 1) / 512} + 5 となります。

注：  計算されたすべての値の端数は切り捨てられます。つまり、小数点以下はすべて無視されます。

注：特定のエンジンラインカードがMDRRをサポートしているかどうかを確認するには、「エンジンタイプ別のMDRRサポート」を参照してください。

MDRR のプライオリティ キュー

Cisco 12000 シリーズは、MDRR 内部のプライオリティ キュー（PQ）をサポートします。このキューは、Voice over IP（VoIP）のような時間依存型のトラフィックに求められる低遅延および低ジッターを提供します。

すでに説明したように、Cisco 12000 シリーズは 重み付け均等化キューイング（WFQ）をサポートしていません。 したがって、MDRR 内部の PQ は、他のプラットフォームで使用可能な Cisco IOS ソフトウェアの低遅延キューイング（LLQ）機能とは動作が異なります。

主な違いは、表 1 に示すように、PQ を処理するために 2 つのモードの MDRR スケジューラ設定方法があることです。

表 1：PQ を処理するための 2 つのモードの MDRR スケジューラ設定方法

交互モード 完全優先モード
長所 PQ は、他のキューの合間に処理されます。つまり、MDRR スケジューラは、PQ とその他の設定されているキューを交互に処理します。 PQ は、空でないときはいつでも処理されます。これにより、一致するトラフィックに対して最小の遅延が実現されます。
デメリット このモードでは、完全優先モードよりもジッターと遅延が発生します。 このモードでは特に、積極的な送信にフローが一致する場合、他のキューが枯渇する可能性があります。

交互モードでは、ジッターと遅延の制御性が低下します。MDRR スケジューラがデータ キューからの MTU のサイズのフレームの処理を開始した後、音声パケットが PQ に到着した場合、交互モードのスケジューラは、デフィシット カウンタが 0 になるまで非プライオリティ キューの処理に集中します。この間 PQ は処理されないため、VoIP パケットは遅延します。

一方、完全優先モードでは、スケジューラは、現在の非プライオリティ パケットのみを処理した後、PQ の処理に切り替わります。スケジューラが非プライオリティ キューの処理を開始するのは、PQ が完全に空になった後です。

交互優先モードのプライオリティ キューは 1 回のサイクルで複数回処理されるため、名目上の重みが同じである他のキューよりも多くの帯域幅を占有する点に注意することが重要です。その重みは、定義されているキューの数によって決まります。たとえば、キューを 3 個定義した場合、サイクルあたりの低遅延キューの処理回数は他のキューの 2 倍になり、2 倍の重みで送信されます。キューを 8 個定義した場合は、低遅延キューの処理回数が 7 倍になり、実効重みが 7 倍高くなります。したがって、キューが占有できる帯域幅は、ラウンドロビンごとに何回処理されるかに関係し、これはさらに全体で何個のキューを定義したかによって決まります。この特別な理由のため、交互優先モードでは通常はプライオリティ キューが小さい重みで設定されます。

たとえば、次の4つのキューが定義されているとします。0、1、2、およびプライオリティキュー。代替プライオリティモードでは、すべてのキューが輻輳している場合、次のように処理されます。0, llq, 1, llq, 2, llq, 0, llq, 1, ....ここで llq は低遅延キューを表します。

キューが処理されるたびに、キューは最大で個別に設定された重みに相当する量を送信できます。したがって、低遅延キューが占有できる最小帯域幅は次のとおりです。

  • WL = 低遅延キューの重み。

  • W0、W1、...Wn = 通常の DRR キューの重み。

  • n = このインターフェイス用に使用される通常の DRR キューの数。

  • BW = リンクの帯域幅。

交互優先モードの場合、低遅延キューの最小帯域幅 = BW * n * WL / (n * WL + Sum(W0,Wn)) になります。

重みは、MDRR 内で設定できる唯一の変数パラメータです。重みは、トラフィック クラスが使用できる帯域幅の相対量と、1 回の順番で送信されるトラフィックの量に影響を与えます。重みを大きくすると、全体のサイクルが長くかかり、遅延が増える可能性が高くなります。

設定のガイドライン

  • 最低の帯域幅要件を持つクラスでは、他のクラスとの間で遅延やジッターをできるだけ低く抑えるために、その重みを 1 に設定することをお勧めします。

  • できるだけ低い重み値を選択します。最低の帯域幅を持つクラスでは、重み 1 から始めます。たとえば、各クラスに50 %の帯域幅を持つ2つのクラスを使用する場合、1と1を設定する必要があります。10と10を使用しても意味がありません。1を選択するとパフォーマンスに影響しません。また、重みが大きいほど、ジッタが増えます。

  • LLQ に対して重み値を低くすることが非常に重要です。特に交互モードでは、他のクラスに加わる遅延やジッターが大きくなりすぎないように、LLQ の重み値を低くする必要があります。

MDRR の例

この項の例は、Cisco Press 発行の『インサイド Cisco IOS® ソフトウェア アーキテクチャ』を基にしています。

次の 3 個のキューがあるとします。

  • キュー 0：クォンタムは 1500 バイト。低遅延キューであり、交互モードで動作するように設定されています。

  • キュー 1：クォンタムは 3000 バイト。

  • キュー 2：クォンタムは 1500 バイト。

図 1 は、各キューの初期状態と、すでに受信してキューに置かれたいくつかのパケットを示しています。

図 1：MDRR の初期状態

mdrr_wred_18841a.gif

キュー 0 のクォンタムがそのデフィシット カウンタに追加され、250 バイトのパケット 1 が送信されて、そのサイズがデフィシット カウンタから差し引かれます。キュー 0 の不足カウンタは依然として 0 より大きいため（1500 - 250 = 1250）、パケット 2 が転送され、その長さがデフィシット カウンタから差し引かれます。キュー 0 のデフィシット カウンタが -250 になったため、次にキュー 1 が処理されます。図 2 にこの状態を示します。

図 2：MDRR の後続の状態

mdrr_wred_18841b.gif

キュー 1 のデフィシット カウンタが 3000（0 + 3000 = 3000）に設定され、パケット 4 および 5 が転送されます。送信された各パケットで、不足カウンタからパケットのサイズを引くと、キュー1の不足カウンタが0に減ります。図3にこの状態を示します。

図 3：キュー 1 のデフィシット カウンタが 0 になったときの MDRR の状態

mdrr_wred_18841c.gif

代替優先モードからサービスキュー0に戻る必要があります。ここでも、クォンタムは現在の不足カウンタに追加され、キュー0の不足カウンタは結果(-250 + 1500 = 1250)に設定されます。 デフィシット カウンタが 0 よりも大きいため、ここでパケット 3 が送信され、キュー 0 は空になります。キューが空になると、図 4 のようにそのデフィシット カウンタが 0 に設定されます。

図 4：キューが空になったときの MDRR の状態

mdrr_wred_18841d.gif

次に、キュー 2 が処理され、そのデフィシット カウンタが 1500（0 + 1500 = 1500）に設定されます。 パケット 7 ～ 10 が送信され、デフィシット カウンタが 500（1500 - (4*250) = 500）になります。 デフィシット カウンタが依然として 0 よりも大きいため、パケット 11 も送信されます。

パケット 11 が送信されるとキュー 2 が空になり、図 5 のようにそのデフィシット カウンタが 0 に設定されます。

図 5：パケット 11 が送信されたときの MDRR の状態

mdrr_wred_18841e.gif

続いて、再びキュー 0 が処理されます（交互優先モードのため）。 キュー 0 は空のため、次にキュー 1 が処理され、パケット 6 が送信されます。

エンジン タイプ別の MDRR のサポート

Cisco 12000 シリーズは、独自のレイヤ 3（L3）フォワーディング エンジン アーキテクチャを持つ 5 種類のラインカード モデルをサポートしています。MDRR のサポートは L3 エンジン タイプやカードのタイプによって異なります。たとえば、エンジン 0 ATM ラインカードでは、MDRR および WRED のサポートはありません。show diag を使用すると、搭載されているラインカードの L3 エンジン タイプを調べることができます。 

router#show diags | include (SLOT | Engine)

!--- The regular expression is case-sensitive.

...
SLOT 1  (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode
  L3 Engine: 0 - OC12 (622 Mbps)
SLOT 3  (RP/LC 3 ): 3 Port Gigabit Ethernet
  L3 Engine: 2 - Backbone OC48 (2.5 Gbps)

ToFab（Rx）キューでの MDRR

Cisco 12000 シリーズの MDRR を設定するには、「従来の CoS 構文」または「モジュラ QoS コマンドライン インターフェイス」を使用できます。従来の CoS またはモジュラ QoS を使用して MDRR を設定する方法については、このドキュメントの後の項で説明します。ToFab キューは従来の CoS 構文を使用して設定する必要があります。これらのキューは MQC の新しい構文をサポートしていません。詳細は表 2 を参照してください。

表 2：ToFab（Rx）キューの MDRR の詳細

実装形態 ToFab MDRR ToFab 交互 PQ ToFab 完全 PQ ToFab WRED
Eng0 [ソフトウェア（Software）] × ** × ** Yes Yes
Eng1 - No No No No
Eng2 ハードウェア Yes Yes Yes Yes
Eng3 ハードウェア No Yes Yes Yes
Eng4 ハードウェア Yes Yes Yes Yes
Eng4+ ハードウェア Yes Yes Yes Yes

** MDRR は ToFab（Rx）方向でのエンジン 0 LC でサポートされていますが、完全優先モードのみであり、交互優先モードはサポートされていません。残り 7 つのキューは通常どおりサポートされています。

着信インターフェイスは、宛先 LC ごとに別個の仮想出力キューを管理しています。これらのキューがどのように実装されるかは L3 エンジン タイプによって異なります。

  • エンジン 0：着信 LC は宛先スロットごとに 8 つのキューを管理しています。したがって、キューの最大数は16x8 = 128です。各キューは別々に設定できます。

  • エンジン 2、3、4、および 4+：着信 LC は宛先インターフェイスごとに 8 個のキューを管理しています。宛先スロットの数が 16 個で、スロットあたり 16 個のインターフェイスがあることから、キューの最大数は 16 x 16 x 8 = 2048 となります。宛先スロット上のインターフェイスはすべて同じパラメータを使用する必要があります。

FrFab（Tx）キューでの MDRR

FrFab キューでの MDRR は、ハードウェアかソフトウェアかの実装形態を問わず、一貫した動作を示します。すべての L3 エンジン タイプは、各発信インターフェイスに対して 8 個のクラス キューをサポートします。詳細は表 3 を参照してください。

表 3：FrFab（Tx）キューの MDRR の詳細

実装形態 FrFab 交互 PQ FrFab 完全 PQ FrFab WRED
Eng0 ソフトウェア1 No Yes Yes
Eng1 - No No No
Eng2 ハードウェア あり2 Yes Yes
Eng3 ハードウェア No Yes Yes
Eng4 ハードウェア Yes Yes Yes
Eng4+ ハードウェア Yes Yes Yes

1エンジン 0 LC の FrFab キューにおける MDRR のサポートは、次の各バージョンの Cisco IOS ソフトウェアで導入されています。

  • Cisco IOS ソフトウェア リリース 12.0(10)S：4xOC3 および 1xOC12 POS、4xOC3、および 1xCHOC12/ STM4。

  • Cisco IOS ソフトウェア リリース 12.0(15)S：6xE3 および 12xE3。

  • Cisco IOS ソフトウェア リリース 12.0(17)S：2xCHOC3/STM1。

2従来の CoS 構文を使用して FrFab 方向の交互 MDRR を設定する必要があります。

注：3xGE LCは、ToFabキューでMDRRをサポートし、Cisco IOSソフトウェアリリース12.0(15)Sと同様に、FrFabキューで固定クォンタムとインターフェイスごとに1つのCoSキューをにサポートします。プライオリティ キューは、設定可能なクォンタムと、完全および交互の両方の優先モードをサポートしています。3 つのインターフェイスはすべて単一の PQ を共有します。

注：Cisco 12000シリーズLCでサポートされるQoS機能の最新情報については、『Cisco 12000シリーズルータリリースノート』を参照してください。

WRED の概要

重み付けランダム早期検出（WRED）は、インターフェイスの輻輳がネットワーク スループットに悪影響を与えるのを防ぐために設計されました。

図 6：WRED パケットのドロップ確率

10778.gif

WRED パラメータの詳細は、「Cisco 12000 シリーズ ルータでの重み付けランダム早期検出（WRED」を参照してください。最小、最大、およびマーク確率パラメータは、実際のランダム早期検出（RED）曲線を記述します。重み付けされたキューの平均が最小しきい値を下回っているときは、パケットは廃棄されません。重み付けされたキューの平均が最大キューしきい値を上回っているときは、平均が最大しきい値未満になるまで、すべてのパケットが廃棄されます。平均が最小しきい値と最大しきい値の範囲内のときは、パケットが廃棄される確率を、最小しきい値（ドロップ確率 = 0）から最大しきい値（ドロップ確率 = 1/マーク確率分母）までの直線で計算することができます。

RED と WRED との違いは、WRED ではインターフェイスが輻輳し始めたときにプライオリティの低いトラフィックを選択的に廃棄でき、各種の サービス クラス（CoS）に対して差異化されたパフォーマンス特性を実現できることです。 デフォルトでは、WRED は各重みについて異なる RED プロファイルを使用します（IP precedence - 8 個のプロファイル）。 WRED では、重要なパケットよりも重要でないパケットが、より優先的に廃棄されます。

WRED パラメータを調整してキュー項目数を管理するのは複雑であり、次のようなさまざまな要素に左右されます。

  • 提供されるトラフィック負荷およびプロファイル。

  • 負荷と使用可能なキャパシティとの比率。

  • 輻輳発生時のトラフィックの動作。

これらの要素は、ネットワークごとに異なり、さらには提供されるサービスやそのサービスを利用する顧客によっても異なります。したがって、特定のお客様の環境に当てはまる推奨値を示すことはできませんが、表 4 に、リンクの帯域幅に基づいた一般的な推奨値を示しておきます。ここでは、各種のサービス クラス間で廃棄特性を区別していません。

表 4：リンクの帯域幅に基づいた推奨値

帯域幅 理論上の帯域幅（kbps） 物理的な帯域幅1（kbps） 最小しきい値 最大しきい値
OC3 155000 149760 94 606
OC12 622000 599040 375 2423
OC48 2400000 239616 1498 9690
OC192 10000000 9584640 5991 38759

1物理的な SONET レート

上のしきい値を計算する際は、いくつかの制限事項について考慮する必要があります。たとえば、平均キュー項目数を最小にしてリンクの使用率を最大化することや、最大と最小との差を必ず 2 のべき乗にすること（ハードウェアの制限による）があります。 経験上およびシミュレーションの結果によれば、RED によって制御されるキューの最大瞬間項目数は、2 MaxTh 未満です。たとえば、0C48 以上では、1 MaxTh です。しかし、これらの値の正確な決定については、このドキュメントでは説明しません。

注：Exponential weighting constant valueは、Engine 2以上のラインカードでは設定する必要はありません。ハードウェアキューのサンプリングが代わりに使用されるためです。エンジン 0 LC の場合は、以下の値を設定できます。

  • ds3：9

  • oc3：10

  • oc12：12

注：エンジン1 LCではWREDはサポートされていません。

以降の各項で説明しているように、WRED の設定は従来の CoS 構文と新しい MQC 構文の両方を使用して実行できます。

従来の CoS 構文を使用した設定

Cisco 12000 シリーズの従来の Class of Service（CoS）構文では、一連の CoS 定義に cos-queue-group テンプレートを使用します。その後、そのテンプレートを着信または発信インターフェイスの ToFab キューおよび FrFab キューにそれぞれ適用します。

ステップ 1：cos-queue-group の定義

cos-queue-group コマンドは、MDRR および WRED パラメータの名前付きテンプレートを作成します。CLI で使用できる設定パラメータは次のとおりです。 

Router(config)#cos-queue-group oc12
Router(config-cos-que)#?
Static cos queue commands:  

default                            Set a command to its defaults
dscp                               Set per DSCP parameters, Engine 3 only
exit                               Exit from COS queue group configuration mode
exponential-weighting-constant     Set group's RED exponential weight constant.
                                   (Not used by engine 0, 1 or 2 line cards)
no                                 Negate a command or set its defaults
precedence                         Set per precedence parameters
queue                              Set individual queue parmeters
random-detect-label                Set RED drop criteria
traffic-shape                      Enable Traffic Shaping on a COS queue group

MDRR を使用すると、IP precedence を MDRR キューにマップし、特別な低遅延キューを設定することができます。それには、cos-queue-group コマンドに precedence パラメータを使用します。 

precedence <0-7> queue [ <0-6> | low-latency]

特別な IP precedence を、通常の MDRR キュー（キュー 0 ～ 6）あるいはプライオリティ キューにマップすることができます。上記のコマンドでは、複数の IP precedence を同じキューに割り当てることができます。

注：低遅延キューには優先順位5を使用することをお勧めします。precedence 6 は、ルーティング アップデートに使用されます。

それぞれの MDRR キューは、グループにあるキューのうちの 1 つをプライオリティ キューとすることで、相対的な重みを与えることができます。cos-queue-groupの下でqueueコマンドを使用すると、次のことが可能です。 

queue <0-6> <1-2048> 
queue low-latency [alternate-priority | strict-priority] <1-2048>

!--- The weight option is not available with strict priority.

WRED パラメータを定義するには、cos-queue-group コマンドを使用します。

random-detect-label

oc12という名前のcos-queue-groupの例を次に示します。oc12は3つのトラフィッククラスを定義しています。キュー0、1、および低遅延。queue 0 には IP precedence の値 0 ～ 3 を、queue 1 には 4、6、7 を、low-latency queue には 5 をマップしています。queue 1 にはより多くの帯域幅が割り当てられています。

設定例 
cos-queue-group oc12

!--- Creation of cos-queue-group called "oc12".

precedence 0 queue 0

!--- Map precedence 0 to queue 0.

precedence 0 random-detect-label 0

!--- Use RED profile 0 on queue 0.

precedence 1 queue 0
precedence 1 random-detect-label 0
precedence 2 queue 0
precedence 2 random-detect-label 0
precedence 3 queue 0
precedence 3 random-detect-label 0

!--- Precedence 1, 2 and 3 also go into queue 0.

precedence 4 queue 1
precedence 4 random-detect-label 1
precedence 6 queue 1
precedence 6 random-detect-label 1
precedence 7 queue 1
precedence 7 random-detect-label 1
precedence 5 queue low-latency

!--- Map precedence 5 to special low latency queue. !--- We do not intend to drop any traffic from the LLQ. We have an SLA !--- that commits not to drop on this queue. You want to give it all !--- the bandwidth it requires.

Random-detect-label 0 375 2423 1

!--- Minimum threshold 375 packets, maximum threshold 2423 packets. !--- Drop probability at maximum threshold is 1.

random-detect-label 1 375 2423 1
queue 1 20

!--- Queue 1 gets MDRR weight of 20, thus gets more Bandwidth.

queue low-latency strict-priority

!--- Low latency queue runs in strict priority mode.

ステップ 2：ToFab キュー用の slot-table-cos の作成

Cisco 12000 シリーズの着信インターフェイスでは、Head of Line Blocking を回避するために、宛先スロットごとに仮想出力キューを保持しています。attach コマンドを使用してラインカードに接続し、execute-on show controller tofab queue コマンドを実行して（または execute-on slot 0 show controllers tofab queue コマンドを直接入力して）、これらの仮想出力キューを表示します。LC コンソールから直接取得したサンプル出力を次に示します。詳細については、「Cisco 12000 シリーズ インターネット ルータでの show controller frfab | tofab queueコマンドを使用します。 

LC-Slot1#show controllers tofab queues
 Carve information for ToFab buffers
  SDRAM size: 33554432 bytes, address: 30000000, carve base: 30029100
  33386240 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s)
  max buffer data size 9248 bytes, min buffer data size 80 bytes
  40606/40606 buffers specified/carved
  33249088/33249088 bytes sum buffer sizes specified/carved
            Qnum    Head    Tail        #Qelem     LenThresh
            ----    ----    ----        ------     ---------
       5 non-IPC free queues:

            20254/20254    (buffers specified/carved), 49.87%, 80 byte data size
            1       17297   17296       20254      65535
            12152/12152    (buffers specified/carved), 29.92%, 608 byte data size
            2       20548   20547       12152      65535
            6076/6076    (buffers specified/carved), 14.96%, 1568 byte data size
            3       32507   38582       6076       65535
            1215/1215    (buffers specified/carved), 2.99%, 4544 byte data size
            4       38583   39797       1215       65535
            809/809    (buffers specified/carved), 1.99%, 9248 byte data size
            5       39798   40606       809        65535
       IPC Queue:
            100/100 (buffers    specified/carved), 0.24%, 4112 byte data size
            30      72      71          100        65535
       Raw  Queue:
            31      0       17302       0          65535
       
       ToFab Queues:
               Dest
            Slot
            0       0       0           0          65535
            1       0       0           0          65535
            2       0       0           0          65535
            3       0       0           0          65535
            4       0       0           0          65535
            5       0       17282       0          65535
            6       0       0           0          65535
            7       0       75          0          65535
            8       0       0           0          65535
            9       0       0           0          65535
            10      0       0           0          65535
            11      0       0           0          65535
            12      0       0           0          65535
            13      0       0           0          65535
            14      0       0           0          65535
            15      0       0           0          65535
     Multicast      0       0           0          65535
    LC-Slot1#

slot-table-cos コマンドを使用して、名前付きの cos-queue-group を宛先仮想出力キューにマップします。すべての出力キューに対して一意の cos-queue-group テンプレートを設定できます。

Router(config)#slot-table-cos table1
Router(config-slot-cos)#destination-slot ?
  <0-15>  Destination slot number
  all     Configure for all destination slots
Router(config-slot-cos)#destination-slot 0 oc48
Router(config-slot-cos)#destination-slot 1 oc48
Router(config-slot-cos)#destination-slot 2 oc48
Router(config-slot-cos)#destination-slot 3 oc48
Router(config-slot-cos)#destination-slot 4 oc12
Router(config-slot-cos)#destination-slot 5 oc48
Router(config-slot-cos)#destination-slot 6 oc48
Router(config-slot-cos)#destination-slot 9 oc3
Router(config-slot-cos)#destination-slot 15 oc48

注：上記の構成ではoc48、oc12、oc3という3つのテンプレートが使用されます。oc12という名前のcos-queue-groupの設定はステップ1に示すとおりです。同様に、oc3とoc48を設定してください。

ステップ 3：slot-table-cos の着信インターフェイスへの割り当て

rx-cos-slot コマンドを使用して、slot-table-cos を LC に割り当てます。

Router(config)#rx-cos-slot 0 ?
  WORD  Name of slot-table-cos
Router(config)#rx-cos-slot 0 table1
Router(config)#rx-cos-slot 2 table1

ステップ 4：cos-queue-group の発信インターフェイスへの割り当て

Cisco 12000 シリーズでは、発信インターフェイスごとに別個のキューが保持されます。これらのキューを表示するには、ラインカード CLI に接続します。attach コマンドを使用した後、次に示すように、show controller frfab queue コマンドを実行します。 

LC-Slot1#show controller frfab queue
    ========= Line Card (Slot 2) =======
  Carve information for FrFab buffers
   SDRAM size: 16777216 bytes, address: 20000000, carve base: 2002D100
   16592640 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize, 2 carve(s)
   max buffer data size 9248 bytes, min buffer data size 80 bytes
   20052/20052 buffers specified/carved
   16581552/16581552 bytes sum buffer sizes specified/carved
            Qnum    Head       Tail               #Qelem  LenThresh
            ----    ----       ----               ------  ---------
       5 non-IPC free queues:
            9977/9977 (buffers    specified/carved), 49.75%, 80 byte data size
            1       101        10077              9977    65535
            5986/5986 (buffers    specified/carved), 29.85%, 608 byte data size
            2       10078      16063              5986    65535
            2993/2993 (buffers    specified/carved), 14.92%, 1568 byte data size
            3       16064      19056              2993    65535
            598/598 (buffers    specified/carved), 2.98%, 4544 byte data size
            4       19057      19654              598     65535
            398/398 (buffers    specified/carved), 1.98%, 9248 byte data size
            5       19655      20052              398     65535
       IPC Queue:
            100/100 (buffers    specified/carved), 0.49%, 4112 byte data size
            30      77         76                 100     65535
       Raw Queue:
            31      0          82                 0       65535
       Interface Queues:
            0       0          0                  0       65535
            1       0          0                  0       65535
            2       0          0                  0       65535
            3       0          0                  0       65535

tx-cos コマンドを使用して、cos-queue-group テンプレートをインターフェイス キューに適用します。次に示すように、パラメータ セットを直接インターフェイスに適用します。テーブルは必要ありません。この例では、pos48 はパラメータ セットの名前です。

Router(config)#interface POS 4/0
Router(config-if)#tx-cos ?
  WORD  Name of cos-queue-group
Router(config-if)#tx-cos pos48

show cos コマンドを使用して、設定を確認します。

Router#show cos

!--- Only some of the fields are visible if MDRR is configured on Inbound !--- or Outbound interfaces.

Interface      Queue cos Group
Gi4/0             eng2-frfab

!--- TX-cos has been applied.

Rx Slot        Slot Table
4             table1

!--- rx-cos-slot has been applied.

Slot Table Name - table1
1           eng0-tofab
3           eng0-tofab

!--- slot-table-cos has been defined.

cos Queue Group - eng2-tofab

!--- cos-queue-group has been defined.

Prec    Red Label [min, max, prob]      Drr Queue [deficit]
0       0 [6000, 15000, 1/1]                  0 [10]
1       1 [10000, 20000, 1/1]                 1 [40]
2       1 [10000, 20000, 1/1]                 1 [40]
3       1 [10000, 20000, 1/1]                 0 [10]
4       2 [15000, 25000, 1/1]                 2 [80]
5       2 [15000, 25000, 1/1]                 2 [80]
6       no drop                               low latency
7       no drop                               low latency

注：レガシーCLIでは、マルチプロトコルラベルスイッチング(MPLS)トラフィックにもprecedence構文が使用されます。ルータは、MPLS ビットを IP タイプ オブ サービス（ToS）ビットと同じように扱い、適切なパケットを適切なキューに格納します。これは、MQC には該当しません。MPLS QoS については、このドキュメントでは取り上げていません。

モジュラ QoS CLI（MQC）を使用した設定

シスコのモジュラ QoS CLI（MQC）は、異なる QoS 機能のすべてを論理的に結び付けて、Cisco IOS ソフトウェアの Quality of Service（QoS）機能の設定を単純化することを目的としています。たとえば、分類はキューイングやポリシング、シェーピングとは別に実行されます。MQC により、テンプレートをベースとする QoS 用の単一コンフィギュレーション フレームワークが提供されます。MQC 設定に関して、次の点に注目してください。

  • インターフェイスへの適用とインターフェイスからの削除を簡単に行うことができます。

  • 簡単に再利用できます（同じポリシーを複数のインターフェイスに適用できます）。

  • プロビジョニング、監視、およびトラブルシューティングを簡単に行うことができる、QoS 用の単一コンフィギュレーション フレームワークを提供します。

  • より高いレベルの抽象化が可能になります。

  • プラットフォームに依存しません。

Cisco 12000 シリーズでは、従来のサービス クラス（CoS）構文の代わりに MQC コマンドを使用できます。

Cisco 12000シリーズでのMQCサポートは、Cisco 7500シリーズなどの別のプラットフォームで使用可能な同じQoS機能セットがCisco 12000で使用可能になったことを意味するものではありません。MQCは、コマンドの結果が共通ののの構文です。たとえば、bandwidth コマンドは、最小帯域幅保証を設定します。Cisco 12000 シリーズでは、MDRR をスケジューリング メカニズムとして使用して帯域幅を予約します。一方、Cisco 7500 シリーズでは、WFQ を使用します。主要なアルゴリズムは、特定のプラットフォームを補完します。

FrFab キューのみが MQC を介した QoS 機能の設定をサポートすることに注目してください。ToFab キューは、仮想出力キューであり、真の入力キューではないため、MQC でサポートされません。これらは、従来の CoS コマンドを使用して設定する必要があります。

L3 エンジン タイプに関する MQC のサポートを表 5 に示します。

表 5：L3 エンジン タイプに関する MQC のサポート

L3 エンジン タイプ エンジン 0 エンジン 1 エンジン 2 エンジン 3 エンジン 4 エンジン 4+
MQC のサポート Yes No Yes Yes Yes Yes
IOS リリース 12.0(15)S - 12.0(15)S1 12.0(21)S 12.0(22)S 12.0(22)S

1エンジン 0 および 2 のラインカード（LC）での MQC のサポートについては、次の例外に注意してください。

  • 2xCHOC3/STM1：12.0(17)S で導入されました。

  • 1xOC48 DPT：12.0(18)S で導入されました。

  • 8xOC3 ATM：12.0(22)S での導入が予定されています。

MQC で QoS ポリシーを作成するには、次の 3 つのステップに従います。

  1. class-map コマンドを使用して 1 つまたは複数のトラフィック クラスを定義します。

  2. policy-map コマンドを使用して QoS ポリシーを作成し、bandwidth や priority などの QoS アクションを名前付きのトラフィック クラスに割り当てます。

  3. service-policy コマンドを使用して、ポリシーマップを発信インターフェイスの FrFab キューに割り当てます。

ポリシーを監視するには、show policy-map interface コマンドを使用します。

詳細は、『モジュラ QoS コマンドライン インターフェイスの概要』を参照してください。

ステップ 1：クラスマップの定義

トラフィック クラスを定義するには、class-map コマンドを使用します。Cisco 12000 シリーズでは、class-map コマンドは、内部的にクラスをラインカード上の特定の CoS キューに割り当てます（詳しくは、ステップ 4 を参照してください）。

class-map コマンドは、match ステートメントのいずれかに一致するパケットをクラスに配置する「match-any」と、すべてのステートメントが満たされた場合にのみパケットをこのクラスに配置する「match-all」をサポートしています。これらのコマンドは、「Prec_5」という名前のクラスを作成し、すべてのパケットを 5 つの IP precedence を用いてこのクラスに分類します。

Router(config-cmap)#match ?
  access-group         Access group
  any                  Any packets
  class-map            Class map
  destination-address  Destination address
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
Router(config-cmap)#match ip precedence 5

各 L3 エンジン タイプでサポートされている照合基準を表 6 に示します。

表 6：L3 エンジンでサポートされている照合基準

エンジン 0、2 エンジン 3 エンジン 4 エンジン 4+
IP precedence Yes Yes Yes ○1
access-group No Yes No No
mpls exp No Yes No ○（12.0.26S）
ip dscp No Yes No ○（12.0.26S）
qos-group No Yes No No
match input-interface POS x/y No ○（受信ポリシーに関してのみ） No No

1 入力/出力(12.0.26S以降)

ステップ 2：ポリシーマップの作成

パケット処理ポリシーまたはアクションを 1 つまたは複数の定義済みクラスに割り当てるには、policy-map コマンドを使用します。たとえば、帯域予約を割り当てたり、ランダム廃棄プロファイルを適用したりするときに使用します。

Cisco 12000 シリーズでは、L3 エンジンの高速アーキテクチャに基づいて、MQC 機能のサブセットをサポートしています。サポートされているコマンドを表 7 に示します。

表 7：サポートされているコマンド

コマンド 説明
bandwidth 輻輳時の最小帯域幅保証を提供します。リンク速度のパーセンテージまたは絶対値として指定されます。予約された kbps に等しい帯域幅をクラスが使用しない場合や必要としない場合、使用可能な帯域幅を他の帯域幅クラスが使用できます。
police、shape クラスが送信できるトラフィックの量を制限します。これらのコマンドは、機能が若干異なります。police コマンドは、設定されている帯域幅を超過したトラフィックを識別し、廃棄または再マーキングします。shape コマンドは、超過トラフィックをバッファリングし、一定のレートで送信するようにトラフィックをスケジュールします。廃棄や再マーキングは行いません。
Queue-limit 固定のキュー長を、対象クラスのトラフィックに割り当てます。キューに格納できるパケットを指定できます。
priority キューを低遅延キューとして識別します。MQC では、PQ に対して完全モードのみをサポートします。MQC では、交互モードはサポートされません。完全優先モードを有効にするには、パーセンテージ値を指定せずに priority コマンドを使用します。

注：Cisco 12000シリーズでのpriorityコマンドの実装は、Cisco IOSソフトウェアが稼働する他のルータでの実装とは異なります。このプラットフォームでは、プライオリティ トラフィックは、輻輳時に、設定されている kbps 値に制限されません。したがって、police コマンドを設定して、プライオリティ クラスが使用できる帯域幅を制限し、他のクラスに帯域幅が適切に割り当てられるようにする必要があります。現時点では、police コマンドはエンジン 3 ラインカードでのみサポートされています。他のエンジンのラインカードでは、プライオリティ クラスの設定時に class-default のみが許可されます。
random-detect WRED プロファイルを割り当てます。random-detect precedence コマンドを使用し、IP precedence 値ごとに非デフォルトの WRED 値を設定します。

エンジン 3 LC では、モジュラ QoS CLI（MQC）を使用して FrFab キューを設定する必要があります。従来のコマンドライン インターフェイス（CLI）はサポートされていません。

bandwidth コマンドを設定する際、エンジン 0 および 2 の LC は 6 つの帯域幅クラスのみをサポートすることに注意してください。7 番目のクラスは低遅延サービス用に使用でき、8 番目のクラス（class-default）は一致しないすべてのトラフィック用に使用できます。したがって、合計 8 個のキューがあります。class-default はプライオリティ クラスとしては使用されません。

エンジン3 LCでは、bandwidth percentコマンドは、基になるリンクレートによって異なるkbps値に変換され、キューに直接設定されます。この最小帯域幅保証の精度は 64 kbps です。

bandwidth コマンドではクォンタム値への変換は行われませんが、すべてのキューはクォンタムを持ちます。エンジン 3 の LC では、クォンタム値は、内部的に、インターフェイスの最大伝送単位（MTU）に基づいてすべてのキューに均等に設定されます。直接的にも間接的にも、この割当値を変更するための MQC CLI メカニズムはありません。クォンタム値は、インターフェイスの MTU 以上の値である必要があります。内部的に用いられるクォンタム値の単位は 512 バイトとなります。したがって、MTU が 4470 バイトの場合、MTU の最小クォンタム値は 9 である必要があります。

エンジン 3 LC での MDRR

この項では、エンジン 3 LC で WRED および MDRR を実装する際の設定上の注意事項について説明します。

  • CLI で設定された MDRR の帯域幅は、L2 に対応する量に変換されます（たとえば、L1 のオーバーヘッドが削除されるなど）。 この量は次の 64 kbps に切り上げられてハードウェアにプログラムされます。

  • 1 つのクラスについて 3 つの異なる WRED プロファイルがサポートされています。

  • WRED（最大しきい値 – 最小しきい値）は、最も近い2の累乗に近似されます。その後、最小しきい値は自動的に調整され、最大しきい値は変更されません。

  • マーク確率値 1 がサポートされています。

  • 指数の重み付け定数コンフィギュレーションはサポートされていません。

  • IP precedence、MPLS EXP ビット、および DSCP 値がサポートされています。

注：Tetra(4GE-SFP-LC=)またはCHOC12/DS1-IR-SC= Frostbiteラインカードの各ポートまたはチャネルには、デフォルトで4つのキューが割り当てられています。この 4 つのキューは以下から構成されます。

  • プライオリティ キュー（LLQ）クラス × 1

  • デフォルト キュー クラス × 1

  • 通常の非プライオリティ クラス × 2

これらの 4 つ（1 つの HPQ、2 つの LPQ、および class-default）を超えるクラスを含むサービス ポリシーをインターフェイスに適用すると、次のエラーが報告されます。

Router(config-if)#service-policy output mdrr-policy

% Not enough queuing resources available to satisfy request.

12.0(26)S では、4GE-SFP-LC= Tetra ラインカード用に、4 つではなく 8 つのキュー/VLAN の設定を可能にするコマンドが追加されました。この 8 つのキューは以下から構成されます。

  • LLQ × 1

  • class-default キュー × 1

  • 通常のキュー × 6

このコマンドを使用するには、ラインカードのマイクロコードのリロードが必要です。このコマンドでは、設定できる VLAN の数が 1022 個ではなく 508 になります。コマンド構文は次のとおりです。

[no] hw-module slot <slot#> qos interface queues 8

以下に、いくつかの例を示します。

Router(config)#hw-module slot 2 qos interface queues 8

警告：Please micro reload the linecard for this command to take effect

Router(config)#microcode reload 2

このコマンドは、12.0(32)S の CHOC12/DS1-IR-SC= Frostbite ラインカードで使用できます。

例 1：bandwidth percent コマンド

この例は、使用可能な帯域幅のうち 20 % をクラス Prec_4 トラフィックに割り当て、30 % をクラス Prec_3 トラフィックに割り当てます。残りの 50 % は class-default クラス用に残します。

また、WRED を、すべてのデータ クラスに関するドロップ メカニズムとして設定します。

例 1 – bandwidth percent 
policy-map GSR_EXAMPLE
 class Prec_4
  bandwidth percent 20
  random-detect
  random-detect precedence 4 1498 packets 9690 packets 1 

 !--- All data classes should have WRED configured.

 class Prec_3
  bandwidth percent 30
  random-detect
  random-detect precedence 3 1498 packets 9690 packets 1
 class class-default

!--- Class-default uses any leftover bandwidth. 


  random-detect
  random-detect precedence 2 1498 packets 9690 packets 1
  random-detect precedence 1 1498 packets 9690 packets 1
  random-detect precedence 0 1498 packets 9690 packets 1

例 2：bandwidth {kbps} コマンド

この例は、bandwidth コマンドをパーセンテージではなく kbps の絶対値として適用する方法を示しています。

例 2：bandwidth {kbps} 
policy-map GSR_EXAMPLE
 class Prec_4
  bandwidth 40000 

!--- Configures a minimum bandwidth guarantee of 40000 kbps or 40 Mbps in !--- times of congestion.
 
  Random-detect

  random-detect precedence 4 1498 packets 9690 packets 1
 class Prec_3
  bandwidth 80000

!--- Configures a minimum bandwidth guarantee of 80000 kbps or 80 Mbps in !--- times of congestion.

  Random-detect
  random-detect precedence 3 1498 packets 9690 packets 1
 class class-default

!--- Any remaining bandwidth is given to class-default.

  Random-detect
  random-detect precedence 2 1498 packets 9690 packets 1
  random-detect precedence 1 1498 packets 9690 packets 1
  random-detect precedence 0 1498 packets 9690 packets 1

例 3 – priority コマンド

この例は、Cisco 12000 シリーズ ルータを MPLS プロバイダー エッジ（PE）ルータとして使用し、PE ルータとカスタマー エッジ（CE）ルータとの間のリンクに QoS サービス ポリシーを設定する必要があるサービス プロバイダー向けに設計されています。この例では、5 つの IP precedence パケットをプライオリティ キューに格納し、このキューの出力を 64 Mbps に制限します。それから、残りの帯域幅部分を各帯域幅クラスに割り当てます。

非プライオリティ クラスのキューはすべて、random-detect コマンドによって WRED を廃棄ポリシーとして有効にするように設定されます。すべての帯域幅クラスと class-default には WRED が明示的に設定されている必要があります。

例 3 – priority 
policy-map foo
  class Prec_5
    police 64000000 conform-action transmit exceed-action drop

!--- The police command is supported on Engine 3 line cards.

    priority
  class Prec_4
    bandwidth percent 30
    random-detect
    random-detect precedence 4 1498 packets 9690 packets 1
  class Prec_3
    bandwidth percent 10
    random-detect
    random-detect precedence 3 1498 packets 9690 packets 1
  class Prec_2
    bandwidth percent 10
    random-detect
    random-detect precedence 2 1498 packets 9690 packets 1
  class Prec_1
    bandwidth percent 10
    random-detect
    random-detect precedence 1 1498 packets 9690 packets 1
  class Prec_0
    bandwidth percent 25
    random-detect
    random-detect precedence 0 1498 packets 9690 packets 1
  class class-default
    random-detect
    random-detect precedence 6 1498 packets 9690 packets 1
    random-detect precedence 7 1498 packets 9690 packets 1

ステップ 3：発信インターフェイス キューへのポリシーマップの割り当て

すでに説明したように、MQC は、発信インターフェイスの FrFab キューでのみ動作します。定義済みのポリシーマップを適用するには、次のように service-policy output コマンドを使用します。 

Router(config)#interface POS 0/0
Router(config-if)#service-policy ?
  history  Keep history of QoS metrics
  input    Assign policy-map to the input of an interface
  output   Assign policy-map to the output of an interface
Router(config-if)#service-policy output ?
  WORD  policy-map name
Router(config-if)#service-policy output GSR_EXAMPLE

ステップ 4：サービス ポリシーの監視と検証

ポリシーの適用状況を表示するには、show policy-map interface コマンドを使用します。show policy-map interface コマンドは、次の情報を表示します。

  • 設定された帯域幅とプライオリティ クラス、および照合基準。

  • すべての WRED プロファイル。

  • シェーピング パラメータとポリシング パラメータ。

  • トラフィックのアカウンティングと速度。

  • 特定のクラスがマップされる内部 CoS キュー。これらのキューは、show controller frfab queue コマンドの出力で使用されるのと同じインデックスで参照されます。

詳細な設定の例と、ポリシーを監視するための show コマンドの例を次に示します。

詳細な設定 
class-map match-all class1
   match ip precedence 1
class-map match-all class2
   match ip precedence 2

!--- Step 1 - Configure traffic classes.

!
policy-map policy1e
  Class class1
    bandwidth percent 10
    random-detect
    random-detect precedence 1 375 packets 2423 packets 1
  Class class2
    bandwidth percent 20
    random-detect

!--- Step 2 - Configure a policy-map.

!
interface POS6/0
 ip address 12.1.1.1 255.255.255.0
 no ip directed-broadcast
 no keepalive
 service-policy output policy1e

!--- Step 3- Attach policy-map to the interface.

show policy-map interface コマンドを使用して、インターフェイスで設定されているポリシーを、設定されているすべてのクラスとともに表示します。コマンドの出力を次に示します。

Router#show policy-map int pos6/0
 POS6/0

  Service-policy output: policy1e (1071)

    Class-map: class1 (match-all) (1072/3)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 1  (1073)
      Class of service queue: 1
      Tx Queue (DRR configured)  
      bandwidth percent         Weight
        10                      1
      Tx Random-detect:
      Exp-weight-constant: 1 (1/2)
      Precedence        RED Label       Min             Max             Mark
      1                 1               375             2423            1

    Class-map: class2 (match-all) (1076/2)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 2  (1077)
      Class of service queue: 2
      Tx Queue (DRR configured)
      bandwidth percent         Weight
        20                      9
      Tx Random-detect:
      Exp-weight-constant: 1 (1/2)
      Precedence        RED Label       Min             Max             Mark

    Class-map: class-default (match-any) (1080/0)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any  (1081)
        0 packets, 0 bytes
        5 minute rate 0 bps

輻輳管理および回避を監視するためのコマンド

この項では、輻輳管理および回避ポリシーを監視するために使用できるコマンドを紹介します。

表 8 に、入力ラインカードおよび出力ラインカードに関連するコマンドを示します。

表 8：ラインカード用のコマンド

入力ラインカード 出力ラインカード
  • show interfaces
  • exec slot <x> sh controller tofab queue
  • exec slot <x> show controller tofab queue <slot> <port>
  • exec slot <x> show controller tofab qm stat
  • show interfaces
  • show interfaces <y> random
  • exec slot <y> show controller frfab queue
  • exec slot <y> show controller frfab queue <port>
  • exec slot <y> show controller frfab QM stat

この項では、これらのコマンドについて説明します。

show interfaces コマンド

このコマンドを使用する前に、適切な「キューイング方式」を確認してください。 出力に「First In, First Out (FIFO)」と表示される場合は、実行中の設定に service-policy コマンドが表示されることを確認してください（MQC を使用して MDRR が設定されている場合）。

出力ドロップ数を監視します。これは、このインターフェイスの発信トラフィックに対して発生した WRED FrFab のドロップ合計数を表します。show interfaces コマンドの出力に表示される出力ドロップ数は、show interfaces <number> random コマンドの出力に表示される出力ドロップ数と等しいか、またはそれよりも高い値になります。

注：Cisco 12000シリーズルータでは、インターフェイス出力ドロップはWREDドロップの更新後に更新されます。ツールを使用して両方のドロップ カウンタを問い合せる際、インターフェイス ドロップ数がまだ更新されていない可能性もあります。

Router#show interfaces POS 4/0
POS4/0 is up, line protocol is up
  Hardware is Packet over SONET
  Description: link to c12f9-1
  Internet address is 10.10.105.53/30
  MTU 4470 bytes, BW 622000 Kbit, DLY 100 usec, rely 255/255, load 82/255
  Encapsulation PPP, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  LCP Open
  Open: IPCP, CDPCP, OSICP, TAGCP
  Last input 00:00:02, output 00:00:05, output hang never
  Last clearing of "show interface" counters 00:04:54
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 38753019 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 200656000 bits/sec, 16661 packets/sec
     135 packets input, 6136 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     7435402 packets output, 11182627523 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

show interfaces {number} random コマンド

このコマンドを使用する際は、次のことを行う必要があります。

  • 正しい cos-queue-group テンプレートがこのインターフェイスに適用されていることを確かめます。

  • MDRR 重みを確認します。それぞれの MDRR キューに対し、キューの長さと最大到達値（パケット数）の加重平均をチェックできます。 これらの値は加重平均として計算されるため、実際に到達したキューの最大項目数を反映する必要はありません。

  • WRED の最小および最大のしきい値をチェックします。

  • 各 RED ラベルについてランダム ドロップ数としきい値ドロップ数をチェックします（「To Fabric」ドロップ数は、すべてのラインカードのこのラベルに対するドロップ合計数を示します）。

  • 「TX-queue-limit drops」カウンタは、WRED がサポートされていないエンジン 1 LC でのみ使用されます。エンジン 1 カードでは、TX-queue-limit インターフェイス コマンドを使用して MDRR キューの制限を設定できます。WRED がサポートされている場合は、WRED のしきい値によって MDRR キューの項目数が決まります。

Router#show interfaces POS 4/0 random
POS4/0
cos-queue-group: oc12
RED Drop Counts
                
TX Link                    
To Fabric
RED Label          Random       Threshold          Random       Threshold
0                29065142           73492         9614385               0
1                       0               0               0               0
2                       0               0               0               0
3                       0               0               0               0
4                       0               0               0               0
5                       0               0               0               0
6                       0               0               0               0

TX-queue-limit drops: 0

Queue Lengths

TX Queue (DRR configured) oc12
Queue              Average              High Water Mark         Weight
0                    0.000                2278.843               1
1                    0.000                   0.000              73
2                    0.000                   0.000              10
3                    0.000                   0.000              10
4                    0.000                   0.000              10
5                    0.000                   0.000              10
6                    0.000                   0.000              10
Low latency          0.000                   0.000              10

TX RED config
  Precedence 0: 375 min threshold, 2423 max threshold, 1/1 mark weight
  Precedence 1: not configured for drop
  Precedence 2: not configured for drop
  Precedence 3: not configured for drop
  Precedence 4: 375 min threshold, 2423 max threshold, 1/1 mark weight
  Precedence 5: not configured for drop
  Precedence 6: 375 min threshold, 2423 max threshold, 1/1 mark weight
  Precedence 7: not configured for drop weight 1/2

exec slot (y) show controller frfab queue {port} コマンド

このコマンドは、対象スロットの対象ポートについて、その瞬間的なキュー項目数を表示します。このセクションの出力例は、インターフェイスPOS 4/1のMDRRキューを示しています。1964パケットのMDRRキュー1のキュー項目数を示しています。Weight には、このキューで処理可能なバイト数が表示されます。この重みにより、このキューに割り当てる帯域幅のパーセンテージが決まります。デフィシットは、処理が必要なパケットの数を DRR アルゴリズムに通知する値を示します。LLQ（DRR キュー 7）にはパケットが 1 つもないことが確認できます。 

Router#execute-on slot 4 show controllers frfab queue 1
========= Line Card (Slot 4) =======
FrFab Queue
Interface 1
DRR#    Head    Tail    Length  Average         Weight  Deficit
0       95330   40924   0            0.000      4608    0
1       211447  233337  1964      1940.156     41472    35036 
2       0       0       0            0.000      9216    0
3       0       0       0            0.000      9216    0
4       0       0       0            0.000      9216    0
5       0       0       0            0.000      9216    0
6       0       0       0            0.000      9216    0
7       0       0       0            0.000      9216    0

このコマンドは、特に出力ラインカードのプライオリティ キューの項目数を監視する場合に使用します。この LLQ でパケットが待機し始めたことが検出されたら、一部の Voice over IP（VOIP）トラフィックを他の出力ラインカードに転送する必要があります。適切な設計では、長さは常に0または1である必要があります。実際のネットワークでは、音声データに対してもバーストトラフィックが発生します。音声負荷の総量が短時間で、出力帯域幅の 100 % を超えると、余分な遅延がさらに深刻になります。ルータは許容値よりも多くのトラフィックをネットワークに送ることができず、そのため音声トラフィックが自身のプライオリティ キューに溜まります。この結果、音声トラフィック自体のバーストによって、音声遅延や音声ジッターが発生します。

Router#execute-on slot 4 show controllers frfab queue 0
========= Line Card (Slot 4) =======
FrFab Queue
Interface 0
DRR#    Head    Tail    Length  Average         Weight  Deficit
0       181008  53494   2487      2282.937      4608    249
1       16887   45447   7            0.000      41472   0
2       0       0       0            0.000      9216    0
3       0       0       0            0.000      9216    0
4       0       0       0            0.000      9216    0
5       0       0       0            0.000      9216    0
6       0       0       0            0.000      9216    0
7       107818  142207  93           0.000      9216    -183600

キュー 7 は LLQ であり、その Length によって、LLQ に溜まっているのパケットの数を確認できます。

exec slot (y) show controller frfab QM stat コマンド

このコマンドは、LC のパケット メモリが最大容量に近づいていると思われる場合に使用します。「no mem drop」カウンタの値が増えているということは、WRED が設定されていないか、設定されている WRED のしきい値が高すぎることを示しています。通常、このカウンタの値は増えません。詳細は、「トラブルシューティング：Cisco 12000 シリーズ インターネット ルータでの ignored エラーとメモリ不足によるドロップ」を参照してください。 

Router#execute-on slot 4 show controllers frfab QM stat
========= Line Card (Slot 4) =======
68142538 no mem drop, 0 soft drop, 0 bump count
0 rawq drops, 8314999254 global red drops, 515761905 global force drops
0 no memory (ns), 0 no memory hwm (Ns)
no free queue
0       0       1968    88
0       0       0       0
0       0       0       0
0       0       0       0
0 multicast drops
TX Counts
 Interface 0
859672328848 TX bytes, 3908130535 TX pkts, 75431 kbps, 6269 pps
 Interface 1
86967615809 TX bytes, 57881504 TX pkts, 104480 kbps, 8683 PPS
 Interface 2
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
 Interface 3
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS

着信輻輳管理の監視

この項では、着信輻輳管理の監視に使用するコマンドについて説明します。

show interfaces コマンド

このコマンドを発行する前に、ignored カウンタの値が増加しているかどうかを確認してください。無視されたパケットは、ToFab 側でメモリ不足になった場合、またはラインカードがパケットを迅速に受け入れていない場合に見られます。詳細は、「Cisco 12000 シリーズ インターネット ルータの入力ドロップのトラブルシューティング」を参照してください。 

Router#show interfaces POS 14/0
POS14/0 is up, line protocol is up
  Hardware is Packet over SONET
  Description: agilent 3b for QOS tests
  Internet address is 10.10.105.138/30
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 234/255, load 1/255
  Encapsulation HDLC, crc 32, loopback not set
  Keepalive not set
  Scramble disabled
  Last input never, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:34:09
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 2231000 bits/sec, 4149 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     563509152 packets input, 38318622336 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     166568973 input errors, 0 CRC, 0 frame, 0 overrun, 166568973 ignored, 0 abort
     35 packets output, 12460 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

exec slot (x) show controller tofab queue コマンド

exec slot <x> show controller tofab queue コマンドのこのサンプル出力は、スロット 3 の出力ラインカードに輻輳が発生していないときに取得した情報です。

Router#execute-on slot 13 show controllers tofab queue
========= Line Card (Slot 13) =======
Carve information for ToFab buffers

!--- Output omitted.

   ToFab Queues:
        Dest
        Slot
        0       0       0               0       9690
        1       0       0               0       9690
        2       0       0               0       9690
        3   11419   16812               0       9690
        4       0       0               0       2423
        5       0       0               0       9690
        6       0       0               0       9690
        7       0       0               0       262143
        8       0       0               0       262143
        9       0       0               0       606
        10      0       0               0       262143
        11      0       0               0       262143
        12      0       0               0       262143
        13      0       0               0       262143
        14      0       0               0       262143
        15      0       0               0       9690
 Multicast      0       0               0       262143

次に、スロット 3 で輻輳が存在したときに取得した出力を示します。 

Router#execute-on slot 13 show controllers tofab queue
========= Line Card (Slot 13) =======
Carve information for ToFab buffers

!--- Output omitted.

   ToFab Queues:
        Dest
        Slot
        0       0       0               0       9690
        1       0       0               0       9690
        2       0       0               0       9690
        3  123689   14003            1842       9690
        4       0       0               0       2423
        5       0       0               0       9690
        6       0       0               0       9690
        7       0       0               0       262143
        8       0       0               0       262143
        9       0       0               0       606
        10      0       0               0       262143
        11      0       0               0       262143
        12      0       0               0       262143
        13      0       0               0       262143
        14      0       0               0       262143
        15      0       0               0       9690
 Multicast      0       0               0       262143

exec slot (x) show controller tofab queue (slot) (port) コマンド

このコマンドは、ToFab 側のメモリの使用量を調べる場合に使用します。特に、「#Qelem」カラムの値に注目してください。次の点に注意してください。

  • 使用中のメモリがないとき、各値はそれぞれの最大値になります。

  • パケットがバッファリングされるにつれて「#Qelem」カラムの値が減ります。

  • 「#Qelem」カラムの値が 0 に達すると、分割されたバッファがすべて使用中になります。エンジン 2 LC では、小さいパケットが大きいパケットからバッファ領域を借用できます。

また、このコマンドを使用して、仮想出力キューにキューイングされているパケットの数を調べることもできます。この例では、スロット 4、ポート 1（POS 4/1）のこれらのキューの瞬間的なパケット数についてスロット 14 をチェックする方法を示しています。 MDRR キュー 1 に 830 パケットがキューイングされていることがわかります。

Router# execute-on slot 14 show controllers tofab queue 4 1
========= Line Card (Slot 14) =======
ToFab Queue
Slot 4 Int 1
DRR#    Head    Tail    Length  Average         Weight  Deficit
0       0       0       0            0.000      4608    0
1       203005  234676  830        781.093      41472   37248
2       0       0       0            0.000      9216    0
3       0       0       0            0.000      9216    0
4       0       0       0            0.000      9216    0
5       0       0       0            0.000      9216    0
6       0       0       0            0.000      9216    0
7       0       0       0            0.000      9216    0

exec slot (x) show controller tofab QM stat コマンド

このコマンドは、ラインカードあたりの ToFab ドロップ数を調べるために使用します。「no memory drop」カウンタの値の増加もチェックしてください。CoS が ToFab 側で設定されていなければ、このカウンタが増えます。

Router#execute-on slot 13 show controllers tofab QM stat
========= Line Card (Slot 13) =======
0 no mem drop, 0 soft drop, 0 bump count
0 rawq drops, 1956216536 global red drops, 6804252 global force drops
0 no memory (Ns), 0 no memory hwm (Ns)
no free queue
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0
Q status errors
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0

ケース スタディ

このケース スタディでは、サービス プロバイダー環境のネットワーク コア向けに一般的なポリシーを設定する方法について説明します。ここでは、キュー コマンドを適用し、アクティブ キュー管理のために MDRR/WRED を使用できるようにします。通常、エッジ ルータの QoS ポリシーは、トラフィックのマーキング、条件設定などを使用して、コアのルータが IP precedence または DiffServ コード ポイント（DSCP）値に基づいてトラフィックをクラスに分類できるようにします。このケース スタディでは、厳しいサービス レベル契約（SLA）に加えて、同じ IP バックボーン上の音声、ビデオ、およびデータ サービスに対する異なるサービス レベルを満たすために、Cisco IOS ソフトウェア QoS 機能を使用します。

この方法については、サービス プロバイダーが 3 つのクラスのトラフィックを実装しています。最も重要なトラフィックは、低遅延キューイング（LLQ）クラスです。これは音声およびビデオ用のクラスです。このクラスは、遅延およびジッターが最も少なく、このクラスの帯域幅がリンクの帯域幅を超えない限り、パケット損失も順序の正しくないパケットも発生しません。このクラスは、DiffServ アーキテクチャでは Expedited Forwarding Per-Hop Behavior（EF PHB）トラフィックと呼ばれます。インターネット サービス プロバイダー（ISP）では、LLQ クラスの負荷がリンク帯域幅の平均負荷で 30% を超えないように自社のネットワークを設計しています。残りの 2 つのクラスは、ビジネス クラスとベスト エフォート クラスです。

この設計では、ビジネス クラスが常に残りの帯域幅の 90% を占め、ベスト エフォート クラスが 10% を占めるようにルータを設定しています。これら 2 つのクラスは時間的制約があまりないトラフィックであり、トラフィック損失、大きな遅延、およびジッターが発生する可能性があります。設計で注目の対象となるのは、エンジン 2 の、1xOC48 rev B、4xOC12 rev B、および 8xOC3 の各ラインカードです。

改良された ASIC とハードウェア アーキテクチャを持ち、遅延のほとんどない Rev B ラインカードは、VoIP トラフィックの送信に適しています。改良された ASIC では、ラインカード ドライバによって、カードの最大 MTU のほぼ 2 倍になるように送信 FIFO キューのサイズが変更されています。OC48E/POS-SR-SC-B= のように、部品番号の末尾の「-B」が目印になります。

注：送信FIFOキューと、エンジン0ラインカードで調整可能なFrFabキューを、tx-queue-limitインターフェイスコマンドと混同しないでください。

表 9 に、各クラスのマッチング基準を示します。

表 9：各クラスのマッチング基準

クラス名 マッチング基準
プライオリティ キュー：音声トラフィック Precedence 5
Business Queue 優先順位 4
Best Effort Queue 優先順位 0

OC48 ラインカードは、ToFab キュー内に多数のパケットをキューイングできます。したがって、出力インターフェイスがOC48などの高速インターフェイスの場合は、ToFabキューでMDRR/WREDを設定することが重要です。ファブリックは理論上の最大レート3 Gbps（1500バイトパケット）でのみトラフィックを受信ラインカードにスイッチングできます。 送信されるトラフィックの総量が、スイッチング ファブリックが受信カードに伝送できる量よりも多い場合は、多くのパケットが ToFab キューにキューイングされます。 

Interface POS3/0 
  description OC48 egress interface 
 ip address 10.10.105.53 255.255.255.252 
 no ip directed-broadcast 
 ip router Isis encapsulation ppp 
 mpls traffic-eng tunnels 
 tag-switching ip 
 no peer neighbor-route 
 crc 32 
 clock source internal 
 POS framing sdh 
 POS scramble-atm 
 POS threshold sf-ber 4 
 POS flag s1s0 2 
 TX-cos oc48 
 Isis metric 2 level-1 
 Isis metric 2 level-2 
 ip rsvp bandwidth 2400000 2400000 
! 
interface POS4/1 
 description OC12 egress interface 
 ip address 10.10.105.121 255.255.255.252 
 no ip directed-broadcast 
 ip router Isis encapsulation ppp 
 mpls traffic-eng tunnels 
 no peer neighbor-route 
 crc 32 
 clock source internal 
 POS framing sdh 
 POS scramble-ATM POS threshold sf-ber 4 
 POS flag s1s0 2 
 TX-cos oc12 
 Isis metric 2 level-1 
 Isis metric 2 level-2 
 ip RSVP bandwidth 600000 60000 
! 
interface POS9/2 
 description OC3 egress interface 
 ip address 10.10.105.57 255.255.255.252 
 no ip directed-broadcast 
 ip router Isis crc 16 
 POS framing sdh 
 POS scramble-ATM POS flag s1s0 2 
 TX-cos oc3 
 Isis metric 200 level-1 
 Isis metric 2 level-2 
! 
interface POS13/0 
 description agilent 3a for QOS tests - ingress interface. 
 ip address 10.10.105.130 255.255.255.252 
 no ip directed-broadcast 
 no ip route-cache cef 
 no ip route-cache 
 no ip mroute-cache 
 no keepalive 
 crc 32 
 POS threshold sf-ber 4 
 TX-cos oc48 
! 
interface POS14/0 
 description agilent 3b for QOS tests - ingress interface. 
 ip address 10.10.105.138 255.255.255.252 
 no ip directed-broadcast 
 no keepalive 
 crc 32 
 POS threshold sf-ber 4 
 TX-cos oc48 
! 
interface POS15/0 
 description agilent 4A for QOS tests - ingress interface 
 ip address 10.10.105.134 255.255.255.252 
 no ip directed-broadcast 
 no ip mroute-cache 
 no keepalive 
 crc 32 
 POS threshold sf-ber 4 
 TX-CoS oc48 
! 
rx-cos-slot 3 StotTable 
rx-cos-slot 4 StotTable 
rx-cos-slot 9 StotTable 
rx-cos-slot 13 StotTable 
rx-cos-slot 14 StotTable 
rx-cos-slot 15 StotTable 
! 
slot-table-cos StotTable 
 destination-slot 0 oc48 
 destination-slot 1 oc48 
 destination-slot 2 oc48 
 destination-slot 3 oc48 
 destination-slot 4 oc12 
 destination-slot 5 oc48 
 destination-slot 6 oc48 
 destination-slot 9 oc3 
 destination-slot 15 oc48 
! 
cos-queue-groupoc3 
 precedence 0 random-detect-label 0 
 precedence 4 queue 1 
 precedence 4 random-detect-label 1 
 precedence 5 queue low-latency 
 precedence 6 queue 1 
 precedence 6 random-detect-label 1 
 random-detect-label 0 94 606 1 
 random-detect-label 1 94 606 1 
 queue 0 1 
 queue 1 73 
 queue low-latency strict-priority 

!--- Respect the tight SLA requirements. !--- No packets drop/low delay and jitter for the priority queue.
 
! 
CoS-queue-groupoc12 
 precedence 0 random-detect-label 0 
 precedence 4 queue 1 
 precedence 4 random-detect-label 1 
 precedence 5 queue low-latency 
 precedence 6 queue 1 
 precedence 6 random-detect-label 1 
 random-detect-label 0 375 2423 1 
 random-detect-label 1 375 2423 1 
 queue 0 1 
 queue 1 73 
 queue low-latency strict-priority 
! 
CoS-queue-groupoc48 
 precedence 0 random-detect-label 0 
 precedence 4 queue 1 
 precedence 4 random-detect-label 1 
 precedence 5 queue low-latency 
 precedence 6 queue 1 
 precedence 6 random-detect-label 1 
 random-detect-label 0 1498 9690 1 
 random-detect-label 1 1498 9690 1 
 queue 0 1 
 queue 1 73 
 queue low-latency strict-priority

VoIP トラフィックが増えるほど、処理待ちになるビジネス トラフィックも増えることが予想されます。しかし、厳しい SLA により、プライオリティ キューに対してはパケット廃棄なし、および超低遅延かつ超低ジッターが要求されているため、これは問題にはなりません。

関連情報

更新履歴

改定 発行日 コメント
1.0
02-Dec-2013
初版

提供

  • jrode
    saalvare
  • lebrooks
    pdevrien

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ

このドキュメントは次の製品に対応しています