シスコサポートコミュニティ
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel

Cisco IOS ソフトウェア プラットフォームでのキュー制限および出力ドロップについて

概要

このドキュメントは、一般に Cisco 7200VXR と Cisco ISR 3800、2800、1800  シリーズのルータ、および 3700、3600、2600、1700 シリーズ ルータなどのレガシー Cisco アクセス ルータを含む  Cisco IOS® ソフトウェア プラットフォームにのみ適用されます。

前提条件

要件

次の項目に関する知識があることが推奨されます。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づくものです。

  • Pre-HQF:Cisco IOS ソフトウェア リリース 12.3(26) が稼働する Cisco ルータ

  • HQF:Cisco IOS ソフトウェア リリース 12.4(22)T が稼働する Cisco ルータ

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

表記法

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

クラスベース重み付け均等化キューイング(CBWFQ)の基本

Pre-HQF の IOS イメージでは、一般的に、クラスの重みに基づいて、bandwidth コマンドを持つクラスが、

bandwidth または priority を持たないクラスよりも、全般的に優先されます。

Class-Based Weighted Fair Queueing(CBWFQ;  クラスベース重み付け均等化キューイング)スケジューリング

アルゴリズムを理解するには、まず、重みの概念を理解する必要があります。重みは、フローベース均等化キューでは

フローに固有で、クラスベース重み付け均 等化キュー内の個々のクラスベースド キューではクラスに固有です。

フローベース均等化キューの重みの計算式は、次のとおりです。

32384 / (IP Prec + 1)

クラスベース重み付け均等化キュー内のユーザ定義クラスは、クラスベースド キューの

すべての bandwidth クラスの合計に占める割合として、クラス内に設定された bandwidth コマンドに

応じて、それぞれの重みを取得します。厳密には、独自の計算式があります。


HQF イメージでは、フローベースの均等化キューは、ユーザ定義クラスおよび fair-queue
がデフォルトのクラスの両方で設定可能で、(重み付けによってではなく)均等にスケジュール設定されています。

さらに、HQF では、クラスベースド キューのスケジューリングの優先順位は、

従来型のクラスの重み付けの式ではなく、HQF スケジューラに基づいて決定されます。

注:このセクションは、クラスベースド キューイングの動作について、

完全な動作分析を網羅するものではありません。

キュー制限および出力ドロップを理解するために必要な CBWFQ についての概要説明が目的です。


キュー制限および出力ドロップについて

priority コマンドで設定するユーザ定義クラス

prioritypriority <kbps>priority percent など、priority コマンドのバリアントのいずれかで設定された MQC ユーザ定義クラス。

Pre-HQF の動作

技術的には、確認可能な CLI(コマンドライン  インターフェイス)がなく、設定不可能であったとしても、

すべてのプライオリティ クラス データが共有する「隠し」システム  キューが存在します。

このキューは、分類され、輻輳認識ポリシング機能によって許可された後に、プライオリティ  データの

保持エリアとして機能します。LLQ  パケットは、受信割り込み中に出力インターフェイスの

転送リングに直接配置されることができない場合、この「隠し」システム  キューに配置されますが、

これは機能輻輳とも呼ばれます。この状態では、機能輻輳が存在するため、パケットは、受信インターフェイスの

ドライバにまだ所有 されている状態で、受信割り込み中に LLQ 条件付きポリシング機能に照らして評価されます。

パケットが LLQ  条件付きポリシング機能によって廃棄されない場合、この「隠し」LLQ システム  キューに配置され、

受信割り込みがリリースされます。したがって、この「隠し」システム キューに配置されたパケットは

すべて LLQ  輻輳認識ポリシング機能に当てはめられ、LLQ/CBWFQ スケジューラにより、

即座に出力インターフェイスの転送リングに送り出されます。

このキューの存在にもかかわらず、このキューのパケットは LLQ/CBWFQ  スケジューラによって

即座に転送リングに排出されるために、(転送リング遅延を超えた)追加キューイング遅延は

発生しないという点で、非 LLQ  データ向けに作成された IOS  のキュー(均等化キュー、帯域幅キューなど)

とは動作が異なります。受信割り込み中に、条件付きポリシング機能によりプライオリティ クラス  パケットが

廃棄されない場合、この LLQ パケットは、出力インターフェイスの転送リングに送り出される前の短時間、

この「隠し」システム  キューに存在します。この場合、LLQ/CBWFQ  スケジューラは、

即座にパケットを出力インターフェイスの転送リングに送り出します。条件付きポリシング機能は、

LLQ/CBWFQ  にパケットが許可される前に実行されるため、LLQ は、設定プライオリティ レートに限定されます。

要約すると、輻輳時には、LLQ の基本コンポーネントである追加キューイング遅延を発生させるよりは、

LLQ  データを廃棄することが推奨されます。この条件付きポリシング機能のメカニズムにより、

プライオリティ キューがインターフェイス PLIM  全体を占有することなく、完全優先キューが許可されます。

これは、IOS の従来のプライオリティ キューイング機能からの改善点です。

- Pre-HQF キュー制限:該当せず

- Pre-HQF “priority” + “random-detect” 動作:該当せず、LLQ で許可されない WRED

- Pre-HQF “priority” + “fair-queue” 動作:該当せず、LLQ で許可されない fair-queue

- Pre-HQF “priority” + “random-detect” + “fair-queue” 動作:該当せず、

  LLQ でサポートされる fair-queue または random-detect

HQF の動作

隠しキューが確認可能になり、キュー制限が設定可能になり、デフォルトが 64 パケットになる場合を除き、Pre-HQF と同じ。

- HQF キュー制限:64 パケット


- HQF “priority” + “random-detect” 動作:該当せず、LLQ で許可されない WRED

- HQF “priority” + “fair-queue” 動作:該当せず、LLQ で許可されない fair-queue

- HQF “priority” + “random-detect” + “fair-queue” 動作:該当せず、

  LLQ でサポートされる fair-queue または random-detect


bandwidth コマンドで設定するユーザ定義クラス

bandwidth <kbps>bandwidth percentbandwidth remaining percent などの bandwidth コマンドの

バリアントのいずれかで設定された MQC ユーザ定義クラス。

Pre-HQF の動作

デフォルトのキュー制限は 64 パケットですが、調整可能です。受信割り込み中に、結果として

64 パケットを超えるパケットをキューに入れようとした場合、パケットの末尾が廃棄されます。

- Pre-HQF キュー制限:64 パケット、queue-limit で調整可能

- Pre-HQF “bandwidth” + “random-detect” 動作

例:

policy-map PRE_HQF_BANDWIDTH_WRED
class 1
   bandwidth 32
   random-detect

bandwidth のバリアントのいずれかが、random-detect
のバリアントのいずれかと同時に設定されている場合、キュー制限の CLI
のいずれかを無視すると、クラスのバッファ制限が削除されます。
つまり、Pre-HQF イメージでは、random-detect と
queue-limit は相互排他的です。random-detect をドロップ方式として使用すると、
現在のキュー サイズが制限されなくなり、理論的には、クラスベースの均等化キューに
割り当てられたバッファすべてを占有することができます。クラスベースの均等化
キューに割り当てられたこのバッファの数は、サービスポリシーを
適用する場所に基づいて計算されます。

-
物理インターフェイス:1,000 パケット、インターフェイス CLI の hold-queue out で調整可能

-
ATM PVC:500 パケット、PVC CLI の vc-hold-queue で調整可能

-
フレームリレー マップクラス:600 パケット、フレームリレー マップクラス CLI の
  frame-relay holdq で調整可能

-
(サブ)インターフェイスに適用されるクラスベースのシェーピング ポリシー(pre-HQF):
   1,000 パケット、MQC クラス CLI の shape max-buffers で調整可能

注:フレームリレーおよびクラスベースのシェーピングの例はすべて、シェーパーの合計がインターフェイスの

クロック レートを超えないと仮定しています。

注:pre-HQF イメージでは、クラスベースのシェーピング ポリシーが(サブ)インターフェイスに適用される場合、

2 Mbps  未満のインターフェイスでは Weighted Fair Queue(WFQ; 重み付け均等化キュー)がデフォルトになり、

2 Mbps  を超えるインターフェイスでは FIFO がデフォルトになるため、基礎となっている物理インターフェイスの

速度に注意が必要です。Pre-HQF  では、シェーピング キューは、シェーピング ポリシーがサブインターフェイス

または物理インターフェイス  レベルに接続されているかどうかを、インターフェイス保持キューに送ります。

受信割り込みの間、パケットがインターフェイスの出力キューの候補になるたびに、

次の式を使用して WRED の平均キュー サイズが計算されます。

Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

平均キュー サイズの計算結果が、

-
WRED の最小しきい値より小さい場合、パケットがキューに入り、受信割り込みがリリースされます。
-
WRED の最小しきい値と WRED の最大しきい値の間の場合、平均キュー サイズが WRED
の最大しきい値に近づくにつれ、パケットの廃棄の可能性が高まります。
平均キュー サイズが WRED の最大しきい値と一致する場合、パケットはマーク確率値に
従って廃棄されます。平均キュー制限が WRED の最大しきい値と完全に一致はしないものの、
WRED の最小しきい値よりは大きい場合に、マーク確率値は、廃棄されるパケットの割合を
判断するためのベースラインとしても使用されます。次の図に例を示します。

queue-limit-output-drops-ios-01.gif

パケットが廃棄されると、受信割り込みがリリースされ、ランダムな廃棄が増加します。

パケットが廃棄されない場合、パケットはキューに入れられ、受信割り込みがリリースされます。

- WRED の最大しきい値よりも大きい場合、パケットが廃棄され、受信割り込みがリリースされ、

  テール ドロップが増加します。

注:IP precedence ベース(デフォルト)および DSCP ベースの WRED  では、最小しきい値、最大しきい値、

およびマーク確率値をそれぞれ異なる値に定義することができます。ここでは、ランダム早期検出の

重み付けコンポーネン トが明確です。他の値に関連するある特定の ToS 値を、関連するしきい値

およびマーク確率値の調整によって保護することができます。

random-detect および bandwidth が同時に設定される場合、現在のキュー  サイズはある特定の時点で

WRED の最大しきい値よりも大きくなる可能性もあります。これは WRED  の最小および最大しきい値が、

(現在ではなく)平均のキュー サイズに基づいてのみアクションを実行するためです。

これにより、クラスベースド  キューに割り当てられたすべてのバッファが期限切れとなり、結果として、

クラスベースの均等化キューで no-buffer drops  が起きる可能性があります(Cisco bug ID CSCsm94757 を参照してください)。

- Pre-HQF “bandwidth” + “fair-queue” 動作:該当せず、帯域幅クラスで許可されない fair-queue

- Pre-HQF “bandwidth” + “random-detect” + “fair-queue” 動作:該当せず、帯域幅クラスで許可されない fair-queue

HQF の動作

この動作は Pre-HQF セクションで説明されている動作と同じです。

- HQF キュー制限:64 パケット、queue-limit で調整可能

これは pre-HQF の場合と同様です。

- HQF “bandwidth” + “random-detect” 動作

例:

policy-map HQF_BANDWIDTH_WRED
class 1
   bandwidth 32
   queue-limit 512
   random-detect

注:デフォルトのキュー制限は 64 パケットです。

この動作は、対応する pre-HQF セクションと同じですが、重要な例外が 1 つあります。HQF  イメージでは、

random-detect と queue-limit は同じユーザ定義クラス(または class  class-default)に共存することが可能で、

キュー制限を有効にして、デフォルト設定で 64  パケットに調整できます。したがって、queue-limit を random-detect クラスの

現在のキュー  サイズの最大値として使用できるため、対応する pre-HQF セクションで説明した

no-buffer drops  を制限するメカニズムが提供されます。この追加機能のため、設定された queue-limit は、

random-detect  の最大しきい値以上である必要があり、random-detect の最大しきい値はデフォルトの

40  パケットになります。そうでなければ、パーサーが設定を拒否します。

これにより、WRED クラスで current-queue-limit  の確認が行われます。この場合、平均的なキュー項目数の計算が

最大しきい値より小さくても、(平均ではなく)現在のキュー サイズが  queue-limit よりも大きければ、パケットが廃棄され、

受信割り込みがリリースされ、テール ドロップが記録さます。queue-limit  が、クラスベースド キューのために全体の

キューイングバッファを排出するのに十分な高さに調整されている場合でも、no-buffer drops  は発生する

可能性があることに注意してください。HQF の全体のキューイングバッファの定義は次の通りです。

- 物理インターフェイス:1,000 パケット、インターフェイス CLI の hold-queue out で調整可能

- ATM PVC:500 パケット、PVC CLI の vc-hold-queue で調整可能

- フレームリレー マップクラス:600 パケット、フレームリレー マップクラス CLI の frame-relay holdq で調整可能

- HQF コードの物理インターフェイスに適用されるクラスベースのシェーピング ポリシー:1,000  パケット、

インターフェイスの CLI の hold-queue out および子ポリシーの queue-limit にインターフェイスの  hold-queue out の

上限がある子ポリシーの queue-limit の組み合せで調整可能

-  HQF コードのサブインターフェイスに適用されるクラスベースのシェーピング ポリシー:512 パケット、調整不可能

(調整が必要な場合は、NSSTG QoS platform Team に確認してください)

注:フレームリレーおよびクラスベースのシェーピングの例はすべて、シェーパーの合計がインターフェイスの

クロック レートを超えないと仮定しています。

次に実際の例を示します。

policy-map JACKLYN
class 1
    bandwidth 64
    queue-limit 500 packets
     random-detect
     random-detect precedence 1 22 300

この出力の間、インターフェイスを通過するトラフィックは生成されていません。

F340.11.25-7200-5_LAC#show policy-map interface | i queue      
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 0/387595/0

!--- Current_q_depth は 0

        Mean queue depth: 107 packets

!--- average_queue_depth の最終計算

この時点でトラフィックが開始されます。ストリームは 400 PPS で非バースト性、1,000 バイト フレームで構成されています。

F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 461/387641/0

!--- Current_q_depth は 461 で、Prec 1 max-thresh of 300 より大きいが
!--- "queue-limit 500 packets" より小さい。


        Mean queue depth: 274 packets

!--- Avg_q_depth が上昇、Mark Prob Denom が使用されている。

 
F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 363/387919/0

!--- Current_q_depth は 363 で、前回と比較して下降 
!--- WRED がランダム廃棄パケットのため反復。


        Mean queue depth: 351 packets

!--- Avg_q_depth が max_thresh を超え、WRED はランダム廃棄に加え、
!--- テール ドロップを開始。


  
F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 199/388263/0
        Mean queue depth: 312 packets
 
F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 303/388339/0
        Mean queue depth: 276 packets
   
F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 325/388498/0
        Mean queue depth: 314 packets

F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 298/390075/0
        Mean queue depth: 300 packets

非バースト性ストリームにより、最終的に WRED 平均キュー項目数が現在のキュー項目数と等しくなる経緯に注目してください。これは予測できる動作です。

- HQF “bandwidth” + “fair-queue” 動作

bandwidth および fair-queue が、HQF  ユーザ定義クラスに同時に適用される場合、各フローベースのキューは、

0.25 * queue-limit  に等しいキュー制限を割り当てられます。デフォルトのキュー制限は 64 パケットなので、

fair-queue の各フローベースのキューは 16  パケットを割り当てられます。4 つのフローがこのクラスを通過する場合、

デフォルトで各フローキューに 16  のパケットがあることになり、キューに入れられた 64(4 * 16)を超えた

パケット全体を確認することはできません。  個々のフローキューからのテール ドロップはすべて、フロードロップとして

記録されます。フローキューの数がキュー制限と同様に著しく多い場合、さらに  no-buffer drops の可能性があります。

たとえば、ポリシー接続ポイントが物理インターフェイスであり、そこに 1,000  の集約バッファが割り当てられると仮定します。

policy-map TEST
class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128

この設定では、すべてのフローキューの大量のトラフィックにより集約インターフェイス
バッファが不足し、他のユーザ定義クラスの no buffer drops が発生する可能性があります
(Cisco bug ID CSCsw98427 を参照してください)。これは、それぞれ 32 パケットのキュー制限を持つ
1,024 のフローキューが、1,000 の集約インターフェイス クラスベースド キューイングの
バッファ割り当てを容易にオーバーサブスクライブする可能性があるためです。


- HQF “bandwidth” + “random-detect” + “fair-queue” 動作

例:


policy-map TEST
class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128
  random-detect

パケットが到着するたびに WRED 平均キュー サイズが計算され、パケットがランダム廃棄されるか
テール ドロップされるかが決定される点を除き、このセクションの bandwidth + fair-queue と
同じです。pre-HQF と同様に、すべてのフローキューは WRED しきい値の 1 つのインスタンスを共有します。
つまり、すべてのフローキューのキューに入れられるすべてのパケットが WRED
平均キュー項目数の計算に使用され、次に、廃棄の決定は、すべてのフローキューの集約パケットに対する WRED
最小および最大しきい値に適用されます。ただし、WRED しきい値の 1 つのインスタンスが
すべてのフローベースのキューに適用されるため、個々のフローキューのキュー制限
(0.25 * queue-limit)は無視され、代わりに現在のキュー制限チェックのためのクラス
集約キュー制限が使用される点も、このセクションの
bandwidth + fair-queue とは異なります。

クラスデフォルトの動作

Pre-HQF の動作

Pre-HQF では、クラス デフォルトは fair-queue  をデフォルトとし、すべてのフローキューはクラスのキュー制限を共有し

(デフォルトは  64)、帯域予約はありません。つまり、すべてのフローキューでキューに入れられたパケットの合計数は、

キュー制限を超過することはありません。各フロー キューでキューに入れられたパケットの量は、計算されたフローキューの

重みによって決定されます。反対に、fair-queue および  random-detect が class-default で同時に使用されると、

キュー制限は無視され、すべてのフローキューは同じ WRED  しきい値を共有します。そのため、すべてのフローキューで、

その時点でキューに入れられたすべてのパケットが、WRED 平均キュー  サイズの計算に使用されます。

この設定では、現在のキュー サイズに上限がないため、no-buffer drops  の可能性は高くなります

(Cisco bug ID CSCsm94757 を参照してください)。

- class-default に bandwidth を追加すると、「bandwidth コマンドで設定するユーザ定義クラス」の「Pre-HQF の動作」セクションで

説明した動作が起こります。

- class class-default クラスに bandwidth および random-detect を追加すると、

「bandwidth コマンドで設定するユーザ定義クラス」の「Pre-HQF の動作」セクションの

Pre-HQF “bandwidth” + “random-detect” 動作」で説明した動作が起こります。

注:Pre-HQF では、class-default 内で、bandwidth は fair-queue と共存できません。

HQF の動作

HQF では、クラス デフォルトは、FIFO キューをデフォルトとし、ユーザ定義クラスから割り当ての残りに基づいて

擬似帯域予約が割り当てられます。そのため、HQF の class class-default のデフォルトの動作については、

「bandwidth コマンドで設定するユーザ定義クラス」の「HQF の動作」セ クションを参照してください。

どのような場合でも、設定にかかわらず、HQF イメージの class class-default  は、ユーザ定義クラスによって

消費されていない未使用のインターフェイス帯域幅と等しい暗黙的な帯域予約を常に保持しています。

デフォルトでは、 class-default クラスは、インターフェイスまたは親シェイプ帯域幅の最低でも 1 % を受け取ります。

クラス デフォルトに、帯域幅  CLI を明示的に設定することも可能です。

- class class-default に fair-queue が設定されている場合、動作は、

「bandwidth コマンドで設定するユーザ定義クラス」の「HQF の動作」セクションの

HQF “bandwidth” + “fair-queue” 動作」と同じです。

- class-default に fair-queue および random-detect が同時に設定されている場合、

動作は、「bandwidth コマンドで設定するユーザ定義クラス」の「HQF の動作」セクションの

HQF “bandwidth” + “random-detect” + “fair-queue” 動作」と同じです。

----------------------------------------------------

Document ID: 110850

2300
閲覧回数
9
いいね!
0
コメント