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

はじめに

このドキュメントでは、Cisco IOS®ソフトウェアプラットフォームおよびレガシーアクセスルータでのキュー制限と出力ドロップについて説明します。

前提条件

要件

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

• Cisco IOS® Quality of Serviceソリューションコンフィギュレーションガイド

• QoS：階層型キューイング フレームワーク（HQF）

使用するコンポーネント

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

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

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

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

表記法

表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

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

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

Pre-HQFのCisco IOSイメージでは、 bandwidth コマンドを持つクラスはすべて、通常、帯域幅のないクラスや、クラスの重みに基づく優先順位に対して優先順位を付けることができます。Class-Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）スケジューリング アルゴリズムを理解するには、まず、重みの概念を理解する必要があります。重みは、フローベース均等化キューではフローに固有で、クラスベース重み付け均等化キュー内の個々のクラスベースド キューではクラスに固有です。

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

32384 / (IP Prec + 1)

クラスベース重み付け均等化キュー内のユーザ定義クラスは、クラスベースキュー内のすべての帯域幅クラスの合計に対する割合として、クラス内に設定された bandwidth コマンドの関数としてそれぞれの重み付けを導出します。厳密には、独自の計算式があります。

HQF イメージでは、フローベースの均等化キューは、ユーザ定義クラスおよび fair-queue がデフォルトのクラスの両方で設定可能で、（重み付けによってではなく）均等にスケジュール設定されています。さらに、HQF では、クラスベースド キューのスケジューリングの優先順位は、従来型のクラスの重み付けの式ではなく、HQF スケジューラに基づいて決定されます。

注：このセクションは、クラスベースキューイング動作の包括的な動作分析を目的としたものではありません。この目的は、CBWFQがキュー制限と出力ドロップを適用する方法を説明することです。

キュー制限と出力ドロップについて

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

priority コマンドのバリアントのいずれかで設定されたMQCユーザ定義クラスの場合、 priority、 priority <kbps>、および priority percent includedを使用します。

Pre-HQF の動作

技術的には、これを確認するためのCLIは存在せず、設定もできませんが、すべてのプライオリティクラスデータによって共有される隠しシステムキューが存在します。これは、分類された後、および輻輳認識ポリサーによって許可された後に、プライオリティデータの一時リポジトリとして機能します。LLQパケットは、受信割り込み中に出力インターフェイスの送信リングに直接配置できない場合、この隠しシステムキューに配置されます。これは機能輻輳とも呼ばれます。この状況では、機能輻輳が存在するため、パケットは受信割り込み中および受信インターフェイスドライバによって引き続き所有されている間に、LLQ条件付きポリサーに照らして評価されます。パケットがLLQ条件付きポリサーによって廃棄されない場合、この隠しLLQシステムキューに配置され、受信割り込みがリリースされます。したがって、この隠しシステムキューに配置されたすべてのパケットはLLQ輻輳認識ポリサーに適合しており、LLQ/CBWFQスケジューラによって出力インターフェイスの送信リングに即時にデキューできます。

このキューが存在するにもかかわらず、非LLQデータ用に作成されたCisco IOSキュー（均等化キューや帯域幅キューなど）とは動作が異なります。このキューでは、LLQ/CBWFQスケジューラによって、このキュー内のパケットが送信リングにすぐに排出されるため、キュー遅延（送信リング遅延を超える）が発生しません。受信割り込み中に条件付きポリシング機能によってプライオリティクラスパケットが廃棄されない場合、このLLQパケットは、出力インターフェイスの送信リングにデキューされる前の短時間、この隠しシステムキューに存在する可能性があります。この場合、LLQ/CBWFQスケジューラは、出力インターフェイスの送信リングにパケットを即時に提示できます。条件付きポリサーは、パケットをLLQ/CBWFQに許可する前に実行されているため、LLQは設定されたプライオリティレートに制限されます。

要約すると、輻輳時にプライオリティレートを超えるLLQデータをドロップすることは、LLQの基本コンポーネントである追加のキューイング遅延を発生させるよりも推奨されます。この条件付きポリシングメカニズムでは、完全優先キューが許可され、優先キューがインターフェイスPLIM全体を独占することはできなくなります。これは、Cisco IOSの従来のプライオリティキューイング機能からの改善点です。

• Pre-HQFキュー制限：なし

• Pre-HQFプライオリティ+ランダム検出動作：NA、WREDはLLQでは許可されません。

• Pre-HQF priority + fair-queue」動作：NA、fair-queueはLLQでは許可されません。

• Pre-HQF priority + random-detect + fair-queue behavior：該当せず、LLQではfair-queueもrandom-detectもサポートされていません。

HQF の動作

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

• HQFキュー制限：64パケット

• HQFプライオリティ+ランダム検出動作：NA、WREDはLLQでは許可されません。

• HQFプライオリティ+ fair-queue動作：なし、LLQではfair-queueは許可されません。

• HQF priority + random-detect + fair-queue behavior：該当せず、LLQではfair-queueもrandom-detectもサポートされていません。

bandwidthコマンドで設定されたユーザ定義クラス

bandwidth コマンドのバリアントのいずれかで設定されたMQCユーザ定義クラスの場合、 bandwidth <kbps> 、 bandwidth percent 、および bandwidth remaining percentincluded。

Pre-HQF の動作

デフォルトのキュー制限は 64 パケットですが、調整可能です。受信割り込み中に、結果として 64 パケットを超えるパケットをキューに入れようとした場合、パケットの末尾が廃棄されます。

• Pre-HQF queue-limit:64パケット、queue-limitで調整可能

• Pre-HQF帯域幅+ 「ランダム検出」動作：

以下に例を挙げます。

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

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

• 物理インターフェイス：1000パケット、インターフェイスCLI hold-queue outで調整可能

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

• Frame-Relay map-class:600パケット、frame-relay map-class CLI frame-relay hold-queueで調整可能

• （サブ）インターフェイスに適用されるクラスベースシェーピングポリシー(pre-HQF):1000パケット、MQCクラスCLIシェイプ最大バッファで調整可能

注：すべてのフレームリレーおよびクラスベースのシェーピングの例では、シェーパーの合計がインターフェイスのクロックレートを超えていないことを前提としています。

注: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の最大しきい値と等しくないが、WREDの最小しきい値よりも高い

• • パケットが廃棄されると、受信割り込みがリリースされ、ランダムな廃棄が増加します。パケットが廃棄されない場合、パケットはキューに入れられ、受信割り込みがリリースされます。

  • WRED の最大しきい値よりも大きい場合、パケットが廃棄され、受信割り込みがリリースされ、テール ドロップが増加します。

注:IP Precedenceベース（デフォルト）およびDSCPベースのWREDでは、最小しきい値、最大しきい値、およびマーク確率値を、値ごとに異なる方法で定義できます。ここでは、ランダム早期検出の重み付けコンポーネントが明確です。特定のToS値の相対しきい値を調整し、確率値をマークすると、他の値に対する特定のToS値を保護できます。

random-detect および bandwidth が同時に設定される場合、現在のキュー サイズはある特定の時点で WRED の最大しきい値よりも大きくなる可能性もあります。これは、WREDの最小および最大しきい値が、現在のキューサイズではなく、平均キューサイズのみに基づいて動作するためです。これにより、クラスベースドキューに割り当てられたすべてのバッファが期限切れになり、結果としてクラスベース均等化キューのどこかでno-buffer dropsが発生する可能性があります(Cisco Bug ID CSCsm94757を参照)。

• Pre-HQF bandwidth + fair-queue behavior：なし、帯域幅クラスではfair-queueは許可されません。

• Pre-HQF bandwidth + random-detect + fair-queue behavior：なし、帯域幅クラスで許可されないfair-queue

HQF の動作

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

• HQF queue-limit:64パケット、queue-limitで調整可能

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

• HQF帯域幅+ランダム検出動作：

以下に例を挙げます。

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）に共存でき、queue-limitを有効にしてデフォルト設定で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 の全体のキューイングバッファの定義は次の通りです。

• 物理インターフェイス：1000パケット、インターフェイスCLI hold-queue outで調整可能

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

• フレームリレーマップクラス：600パケット、frame-relay map-class CLI frame-relay hold-queueで調整可能

• HQFコードの物理インターフェイスに適用されるクラスベースのシェーピングポリシー：1000パケット、インターフェイスCLIのhold-queue outと子ポリシーqueue-limitの組み合わせで調整可能（子ポリシーqueue-limitがインターフェイスhold-queue outの上限を持つ）

• HQFコードのサブインターフェイスに適用されるクラスベースのシェーピングポリシー：512パケット、チューニング不可（NSSTG QoSプラットフォームチームで調査、チューニング可能であること）

注：すべてのフレームリレーおよびクラスベースのシェーピングの例では、シェーパーの合計がインターフェイスのクロックレートを超えていないことを前提としています。

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

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 is 0

        Mean queue depth: 107 packets

!--- last calculation of Average_queue_depth

この時点でトラフィックが開始されます。ストリームは400PPSでバースト性がなく、1000バイトのフレームで構成されます。

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

!--- 461 is Current_q_depth > Prec 1 max-thresh of 300 
!--- but < "queue-limit 500 packets".

  Mean queue depth: 274 packets

!--- Avg_q_depth is rising, Mark Prob Denom is being used.

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 

!--- 363 is Current_q_depth and it is falling compared to last 
!--- iteration because WRED is random dropping packets. Mean queue depth: 351 packets 
!--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop 
!--- in addition to random-drop. 

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 が、HQF ユーザ定義クラスに同時に適用される場合、各フローベースのキューは、0.25 * queue-limit に等しいキュー制限を割り当てられます。デフォルトのキュー制限は64パケットなので、fair-queue内の各フローベースのキューには16パケットを割り当てることができます。4つのフローがこのクラスを通過した場合、デフォルトでは各フローキューに16個のパケットが含まれるため、64を超えるパケットがキューに入れられることは予想されません(4 *16)。個々のフローキューからのすべてのテールドロップは、フロードロップとして記録されます。フローキューの数がキュー制限と同様に著しく多い場合、さらに no-buffer drops の可能性があります。たとえば、ポリシーアタッチポイントが物理インターフェイスで、1000の集約バッファが割り当てられているとします。

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

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

クラス デフォルトの動作

Pre-HQF の動作

Pre-HQF では、クラス デフォルトは fair-queue をデフォルトとし、すべてのフローキューはクラスのキュー制限を共有し（デフォルトは 64）、帯域予約はありません。つまり、すべてのフローキューにキューイングされるパケットの総数は、キュー制限を超えることはできません。各フローキューにキューイングされるパケットの量は、計算されたフローキューの重み付けによって異なります。逆に、fair-queueとrandom-detectがclass-defaultで一緒に使用される場合、queue-limitは無視され、すべてのフローキューは同じ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では、bandwidthはclass-defaultのfair-queueと共存できません。

HQF の動作

HQF では、クラス デフォルトは、FIFO キューをデフォルトとし、ユーザ定義クラスから割り当ての残りに基づいて擬似帯域予約が割り当てられます。そのため、HQFのclass-defaultのデフォルトの動作については、「bandwidthコマンドで設定するユーザ定義クラス」の「HQFの動作」を参照してください。常に、設定に関係なく、HQFイメージのclass class-defaultは、ユーザ定義クラスによって消費されない未使用のインターフェイス帯域幅と等しい暗黙的な帯域幅予約を常に保持できます。デフォルトでは、class-default クラスは、インターフェイスまたは親シェイプ帯域幅の最低でも 1 % を受け取ります。クラス デフォルトに、帯域幅 CLI を明示的に設定することも可能です。

• class class-defaultにfair-queueが設定されている場合、動作は、「bandwidthコマンドで設定するユーザ定義クラス」の「HQFの動作」の「HQF bandwidth + fair-queueの動作」セクションと一致します。

• fair-queueとrandom-detectがClass-Default内で同時に設定されている場合、動作は、「bandwidthコマンドで設定するユーザ定義クラス」の「HQFの動作」セクションの「HQF bandwidth + random-detect + fair-queueの動作」と同じです。

関連情報

• Cisco IOS Quality of Serviceソリューションコンフィギュレーションガイド、リリース12.2SR
• QoS:Hierarchical Queueing Framework(HQF)[未サポート]
• ルータ サポート
• シスコのテクニカルサポートとダウンロード