ルータ : Cisco 7200 シリーズ ルータ

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

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2010 年 12 月 22 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

この資料は Cisco IOS に適当ですか。 ソフトウェア プラットフォーム 3700、3600、2600、および 1700 シリーズ ルータを含む一般に Cisco 7200VXR および Cisco ISR 3800 を含む 2800、1800 シリーズ ルータ、またレガシー Cisco アクセスルータだけ。

前提条件

要件

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

使用するコンポーネント

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

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

      http://www.cisco.com/c/dam/en/us/support/docs/routers/7200-series-routers/110850-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 is 0
      
              Mean queue depth: 107 packets
      
      !--- last calculation of 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
      
      !--- 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” 動作

    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 を参照してください)。

注: 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