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

CscTsWebDocs · ‎2011-02-08

概要

このドキュメントは、一般に 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 コマンドで設定するユーザ定義クラス

priority、priority <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 percent、bandwidth 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 の最小しきい値よりは大きい場合に、マーク確率値は、廃棄されるパケットの割合を
判断するためのベースラインとしても使用されます。次の図に例を示します。

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

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

- 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 とは異なります。