プライオリティ キューイングによる出力ドロップのトラブルシューティング

概要

このドキュメントでは、ルータのインターフェイスでのプライオリティ キューイングのメカニズム設定が原因で発生する出力ドロップのトラブルシューティング方法について説明しています。

前提条件

要件

このドキュメントの読者は、次の概念について理解している必要があります。

• priority-group または frame-relay priority-group：Cisco の従来のプライオリティ キューイング メカニズムをイネーブルにします。4 レベルまでのプライオリティ キューがサポートされます。

• ip rtp priority または frame-relay ip rtp priority：UDP ポート番号により、VoIP パケットがカプセル化された Real-Time Protocol（RTP）トラフィックを照合し、一致したパケットをプライオリティ キューに入れます。

• priority：Cisco の Low Latency Queueing（LLQ; 低遅延キューイング）機能をイネーブルにし、モジュラ QoS（Quality of Service）command-line interface（CLI; コマンドライン インターフェイス）のコマンド ストラクチャを使用します。

上記のどの方式が設定されていても、ルータでの出力ドロップのレポートは可能ですが、それぞれの場合での方式とドロップの理由には重要な機能上の違いがあります。

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

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

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

表記法

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

ip rtp priority と LLQ による廃棄

『Cisco IOS コンフィギュレーション ガイド』には、これらのプライオリティ キューイング メカニズムによる出力ドロップに関する警告が記載されています。

• ip rtp priority：ip rtp priority コマンドを実行すると他のトラフィックよりも絶対的に優先されるプライオリティが設定されるので、慎重に使用する必要があります。輻輳が発生した場合、トラフィック量が設定帯域幅を超えると、過剰なトラフィックはすべてドロップされます。

• priority コマンドと LLQ：クラスに対して priority コマンドを指定する際には、最大帯域幅を指定する帯域幅の引数が必要です。輻輳が発生した場合、最大帯域幅を超えると、ポリシングの使用によりパケットがドロップされます。

これらの2つの方式は、ビルトイン ポリサーを使用してトラフィック フローを測定します。ポリサーの目的は、他のキューがキューイング スケジューラによって確実に処理されるようにすることです。priority-group コマンドと priority-list コマンドを使用する Cisco の元来のプライオリティ キューイング機能では、スケジューラによって常に優先順位の最も高いキューが最初に処理されていました。常に優先順位の高いキューにトラフィックがある場合、優先順位の低いキューには、帯域幅が不足し、パケットは非プライオリティ キューに置かれることになります。

従来のプライオリティ キューイングによるドロップ

Priority Queueing（PQ; プライオリティ キューイング）は、Cisco の従来のプライオリティ キューイング メカニズムです。下図に示すように、PQでは4レベルのキューがサポートされます:（High、Medium、Normal、Low）

次に示すように、インターフェイス上でプライオリティ キューイングをイネーブルに設定すると、出力キューの表示が変わります。プライオリティ キューイングを適用する前のイーサネット インターフェイスでは、デフォルトのキュー サイズが 40 パケットである出力待機キューが 1 つだけ使用されます。

R6-2500# show interface ethernet0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1) 
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec) 
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:02, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239407 packets input, 22644297 bytes, 0 no buffer 
     Received 239252 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374436 packets output, 31095372 bytes, 0 underruns 
     0 output errors, 1 collisions, 13 interface resets 
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

PQを有効にすると、次の出力に示すように、イーサネット インターフェイスはキューサイズの異なる4つの優先キューを使用します。

R6-2500(config)# interface ethernet0 
R6-2500(config-if)# priority-group 1 
R6-2500(config-if)# end 
R6-2500# show interface ethernet 0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters never 
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: priority-list 1 
  Output queue (queue priority: size/max/drops): 
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239411 packets input, 22644817 bytes, 0 no buffer
     Received 239256 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374440 packets output, 31095658 bytes, 0 underruns
     0 output errors, 1 collisions, 14 interface resets
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

特定のキューにトラフィック フローを指定するには、priority-list {list-number} コマンドを使用します。インターフェイスにパケットが着信すると、そのインターフェイスでは優先順位の高い順にプライオリティ キューでパケットがスキャンされます。スキャンは、高プライオリティ キューが最初、中プライオリティ キューが次という順序で行われます。プライオリティの最も高いキューの先頭にあるパケットが送信に選択されます。パケットを送信するごとに、この手順が繰り返されます。

各キューは、最大長または保管できる最大パケット数によって定義されます。現在のキューの深さが設定されたキュー制限が着信パケットで超過されると、そのパケットはドロップされます。つまり、PQによる出力ドロップはキュー リミットを超えることが原因であり、LLQのように内部ポリサーによるドロップではありません。プライオリティ キューのサイズは、priority-list list-number queue-limit コマンドで変更できます。

トークン バケットによるトラフィック測定

LLQ および IP RTP プライオリティでは、トラフィック測定システムとしてトークン バケットを使用することで、組み込みポリサーが実装されます。ここでは、トークン バケットの概念について説明します。

トークン バケット自体は、廃棄ポリシーも優先順位ポリシーも持ちません。トークン バケットというメタファは次のように動作します。

• トークンはある一定のレートでバケットに入れられます。

• 各トークンは、発信元がある一定のビット数をネットワークに送信するための許可を表します。

• パケットを送信するには、トラフィック レギュレータが、パケット サイズに相当するトークン数をバケットから削除できる必要があります。

• パケットを送信するために十分なトークンがバケットにない場合は、パケットはバケットに十分な数のトークンが溜まるまで待機するか（シェーパーの場合）、廃棄またはマークダウンされます（ポリサーの場合）。

• バケット自体には指定された容量があります。バケットの容量がいっぱいになると、新しく着信したトークンは廃棄されて、今後のパケットのためにそれらのトークンを使用できなくなります。したがって、どんな場合でも、アプリケーションがネットワークに送信できる最大のバーストは、バケットのサイズにほぼ比例します。トークン バケットでは、バーストが許可されますが、制限があります。

Committed Information Rate（CIR; 認定情報レート）が 8000 bps の場合のパケット送信の例を考えてみましょう。

• この例では、トークン バケットは 1000 バイトでいっぱいの状態から始まります。

• 450 バイトのパケットが着信すると、適合するトークン バケットには十分なバイト数があるため、このパケットは適合します。このパケットが送信されると、トークン バケットから 450 バイトが削除され、残りは 550 バイトになります。

• 0.25 秒後に次のパケットが着信しますが、トークン バケットには 250 バイト（(0.25 * 8000)/8）が追加され、700 バイトになっています。次のパケットが 800 バイトである場合、送信可能なバイト数を超えているので、このパケットはドロップされます。トークン バケットからは 1 バイトも削除されません。

ドロップを診断するトラブルシューティングの手順

ステップ 1：データ収集

データを収集するための手順は、次のとおりです。

1. 次のコマンドを数回実行し、ドロップ数がどの程度の速さと頻度で増加するかを調べます。出力を分析して、トラフィック パターンとトラフィック レベルの基準を作成します。インターフェイスの「平常時」のドロップ レートを判断してください。

   • show queueing interface

     router# show queueing interface hssi 0/0/0
               Interface Hssi0/0/0 queueing strategy: priority
     
               Output queue utilization (queue/count)
     
                high/12301 medium/4 normal/98 low/27415

   • show interface - 出力に表示される負荷の値を監視します。また、show interface の出力に表示されたキュー単位のドロップ数の合計が、出力ドロップ数と一致しているか確認します。show interface の出力ドロップ カウンタには、WRED 廃棄、バッファ不足（「no buffer」エラー）による廃棄、およびオンボード ポート アダプタのメモリでの廃棄を含めた、出力ドロップすべての合計数が表示されるはずです。

     router# show interface serial 4/1/2
     
     Serial4/1/2 is up, line protocol is up 
     Hardware is cyBus Serial 
     Description: E1 Link to 60W S9/1/2 Backup 
     Internet address is 169.127.18.228/27 
     MTU 1500 bytes, BW 128 Kbit, DLY 21250 usec, rely 255/255, load 183/255 
     Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
     Last input 00:00:00, output 00:00:00, output hang never 
     Last clearing of "show interface" counters 5d10h 
     Input queue: 0/75/0 (size/max/drops); Total output drops: 68277 
     Queueing strategy: priority-list 7 
     Output queue: high 0/450/0, medium 0/350/143, normal 0/110/27266, low 0/100/40868 
     5 minute input rate 959000 bits/sec, 419 packets/sec 
     5 minute output rate 411000 bits/sec, 150 packets/sec 
     144067307 packets input, 4261520425 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     42 input errors, 34 CRC, 0 frame, 0 overrun, 1 ignored, 8 abort 
     69726448 packets output, 2042537282 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 46686454 output buffers swapped out 
     0 carrier transitions

     注：一部のインターフェイスでは、「txload」と「rxload」の値が個別に表示されます。

     Hssi0/0/0 is up, line protocol is up 
      Hardware is cyBus HSSI 
      MTU 1500 bytes, BW 7500 Kbit, DLY 200 usec, 
      reliability 255/255, txload 138/255, rxload 17/255 
      Encapsulation FRAME-RELAY IETF, crc 16, loopback not set 
      Keepalive set (5 sec) 
      LMI enq sent 4704, LMI stat recvd 4704, LMI upd recvd 0, DTE LMI up 
      LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 
      LMI DLCI 1023 LMI type is CISCO frame relay DTE 
      Broadcast queue 0/256, broadcasts sent/dropped 8827/0, interface 
      broadcasts 7651 
      Last input 00:00:00, output 00:00:00, output hang never 
      Last clearing of "show interface" counters 06:31:58 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 84 
      Queueing strategy: priority-list 1 
      Output queue (queue priority: size/max/drops): 
      high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/84 
      5 minute input rate 524000 bits/sec, 589 packets/sec 
      5 minute output rate 4080000 bits/sec, 778 packets/sec 
      11108487 packets input, 1216363830 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 
      15862186 packets output, 3233772283 bytes, 0 underruns 
      0 output errors, 0 applique, 1 interface resets 
      0 output buffer failures, 2590 output buffers swapped out 
      0 carrier transitions 
      LC=down CA=up TM=down LB=down TA=up LA=down

   • show policy-map interface interface-name：「pkts discards」カウンタの値がゼロ以外であることを確認します。

     Router# show policy-map interface s1/0
      Serial1/0.1: DLCI 100 -
      output : mypolicy
       Class voice
        Weighted Fair Queueing
            Strict Priority
            Output Queue: Conversation 72 
              Bandwidth 16 (kbps) Packets Matched 0
             (pkts discards/bytes discards) 0/0
       Class immediate-data
        Weighted Fair Queueing
            Output Queue: Conversation 73 
              Bandwidth 60 (%) Packets Matched 0
              (pkts discards/bytes discards/tail drops) 0/0/0
              mean queue depth: 0
              drops: class  random   tail     min-th   max-th   mark-prob 
                     0      0        0        64       128      1/10
                     1      0        0        71       128      1/10
                     2      0        0        78       128      1/10
                     3      0        0        85       128      1/10
                     4      0        0        92       128      1/10
                     5      0        0        99       128      1/10
                     6      0        0        106      128      1/10
                     7      0        0        113      128      1/10
                     rsvp   0        0        120      128      1/10

     注：次の出力例は、「packets」カウンタと「pkts matched」カウンタの一致する値を示しています。この状況は、大量のパケットがプロセス スイッチングされているか、またはインターフェイスに過度の輻輳が生じていることを示しています。いずれの状態もクラスのキュー リミットを超える原因になるので、詳しく調べる必要があります。

     router# show policy-map interface
     
     Serial4/0 
     
     Service-policy output: policy1 
     
     Class-map: class1 (match-all) 
     189439 packets, 67719268 bytes 
     5 minute offered rate 141000 bps, drop rate 0 bps 
     Match: access-group name ds-class-af3 
     Weighted Fair Queueing 
     Output Queue: Conversation 265 
     Bandwidth 50 (%) Max Threshold 64 (packets) 
     (pkts matched/bytes matched) 189439/67719268 
     (depth/total drops/no-buffer drops) 0/0/0

2. 次の方法で、トラフィック フローおよびパケットの特性を判断します。

   • パケットの平均サイズはどのくらいなのか。

   • MTU サイズのフレームのフローはどの方向に向かっているのか。多くのトラフィック フローは、負荷に関して非同期です。たとえば、FTP ダウンロードの場合、MTU サイズのパケットの大部分は FTP サーバからクライアントに対して送信されます。FTP クライアントからサーバへのパケットは単純な TCP ACK です。

   • パケットはTCPかUDPを使用していますか。TCP では、承認されたパケット数だけを各フローで送信することができますが、承認されたパケット数を超えると発信元によって送信が一時停止され、送信されたパケットの宛先による確認応答が待機されます。

3. フレームリレーの場合は、インターフェイス キューまたはVirtual Circuit（VC; 仮想回線）単位のキューでドロップが発生しているかどうかを確認します。次の図は、フレームリレー仮想回線のパケット フローを示しています。

   

4. プライオリティ キューイングでは、プライオリティ キュー レベルの異なる出力キューが最大で 4 つサポートされ、各キューにキュー制限が定義されています。このキューイング システムでは、パケットをキューに入れる前に、設定されたキュー制限に対するキューのサイズがチェックされます。選択されたキューが満杯の場合、ルータはパケットをドロップします。priority-list {#} queue-limit コマンドでキューのサイズを増加させ、モニタリングを再開してください。

ステップ 2：十分な帯域幅の確保

LLQ では、ポリシングによって、他の Class-Based Weighted Fair Queuing（CBWFQ）や WFQ のキューの他のデータ パケットを均等に処理することができます。パケットのドロップを避けるには、使用するcodecのタイプおよびインターフェイスの特性を考慮して、プライオリティ キューに最適な帯域幅を割り当てる必要があります。IP RTPプライオリティでは、割り当てられた帯域幅を超えるトラフィックは転送されません。

安全上、プライオリティ キューには、必要とされる帯域幅よりもわずかに広い帯域幅を割り当てることが常に推奨されます。たとえば、プライオリティ キューに、音声伝送に必要な標準帯域である 24 kbps の帯域幅を割り当てたとします。音声パケットは一定のビット レートで伝送されるので、この割り当てで問題はありません。ただし、ネットワーク、ルータ、またはスイッチは、ジッタおよび遅延に対して多少の帯域幅を消費するので、必要帯域幅よりもわずかに多め（25 kbpsなど）に割り当てておくと、持続性とアベイラビリティを確保できます。

プライオリティ キューに割り当てられた帯域幅には、常にレイヤ 2 カプセル化ヘッダーが含まれています。巡回冗長検査(CRC)は含まれていません。(『IP to ATM CoSキューイングでカウントされるバイト』を参照してください。を参照してください)。 わずかなバイト数ですが、トラフィック フローに多数の小さなパケットが含まれていると、CRC による影響が出ることがあります。

また、ATM インターフェイスのプライオリティ キューに割り当てられた帯域幅には、次の ATM セル タックス（cell tax）オーバーヘッドは含まれていません。

• パケットの最終セルを48バイトの倍数にするための、Segmentation and Reassembly（SAR; 分割と再構成）によるパディング

• ATM Adaptation Layer 5（AAL5; ATM アダプテーション レイヤ 5）トレーラの 4 バイトの CRC

• 5 バイトの ATM セル ヘッダー。

特定のプライオリティ クラスに割り当てる帯域幅を計算する場合、レイヤ 2 ヘッダーが含まれていることを考慮する必要があります。ATM を使用する場合には、ATM セル タックス（cell tax）オーバーヘッドが含まれていないことを考慮する必要があります。また、音声経路のネットワーク デバイスによってジッタが生じることを考慮し、帯域幅を余分にとっておく必要があります。『低遅延キューイング機能の概要』を参照してください。

プライオリティ キューイングを使用して VoIP パケットを搬送する場合は、『VoIP：コール単位の帯域幅の使用量』を参照してください。

ステップ3 - 十分なバーストサイズを確保する。

インターフェイス上のプライオリティ キューから送信される一連のパケットの処理は、パケットのサイズおよびトークン バケットに残っているバイト数によって異なります。LLQ ではシェーパーではなくポリサーが使用されるので、プライオリティ キューに向けられるトラフィック フローの特性を考慮することが重要です。ポリサーは次のようにトークン バケットを使用します。

• バケットは、クラス レートに基づいて、バースト パラメータの最大値に相当するトークン数まで満たされます。

• トークン数がパケット サイズ以上であれば、パケットは送信され、トークン バケットは減少します。設定されている場合、パケットはドロップされます。

LLQ のトークン バケット トラフィック メータのデフォルトのバースト値は、設定された帯域幅レートでのトラフィックの 200 ミリ秒の値として計算されています。一部の状況においては、特に TCP トラフィックがプライオリティ キューを通過する場合など、デフォルト値は適切ではありません。TCP フローは一般的にバースト性があるので、特に低速リンク上では、キューイング システムによって割り当てられるデフォルト値よりも大きなバースト サイズが必要になることがあります。

次に、Sustained Cell Rate（SCR; 平均セル レート）が128 kbpsであるATM PVC上で生成された出力例を示します。priority コマンドによって指定された値を変更すると、キューイング システムによってバースト サイズが調整されます。

7200-17# show policy-map int atm 4/0.500
 ATM4/0.500: VC 1/500 - 
  
Service-policy output: drops 

    Class-map: police (match-all)
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 90 (%) 
        Bandwidth 115 (kbps) Burst 2875 (Bytes) 
        
!--- Burst value of 2875 bytes is assigned when !--- the reserved bandwidth value is 115 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

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

7200-17# show policy-map int atm 4/0.500 
 ATM4/0.500: VC 1/500 - 

  Service-policy output: drops 

    Class-map: police (match-all) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 50 (%) 
        Bandwidth 64 (kbps) Burst 1600 (Bytes) 
        
!--- Burst value changes to 1600 bytes when the !--- reserved bandwidth value is changed to 64 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

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

LLQ の機能が拡張され、低遅延キューイング機能のバースト サイズ設定を行うことで、Committed Burst（Bc）サイズを設定できるようになりました。この新機能により、ネットワークが一時的なトラフィック バーストに対応できるようになり、ネットワーク トラフィックをより効率的に処理できます。

バースト値を 1600 バイトから 3200 バイトに増加するには、priority コマンドのバースト パラメータを使用します。

policy-map AV 
  class AV 
  priority percent 50 3200

注：高い値を指定すると、プライオリティクラスが使用できる有効な帯域幅が増加し、プライオリティクラスが帯域幅の公平な割合を超えていることがわかります。

また、キューイング システムでは、元来、低遅延キューに対して 64 パケットの内部キュー制限が割り当てられています。場合によっては、プライオリティ キューに 64 パケットのバーストが到達すると、トラフィック メータではこのバーストが設定レートに適合していると判断されながら、パケット数がキュー制限を超えていることがあります。その結果、一部のパケットの末尾がドロップされます。この問題は、プライオリティ キュー サイズをトラフィック メータの許容サイズまで増分可能にすることで、Cisco Bug ID CSCdr51979（登録ユーザ専用）によって解決されています。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

次に、CIR が 56 kbps に設定されたフレームリレー PVC 上の出力例を示します。最初の出力例で、c1 および c2 クラスの提示レートの合計は 76 kbps です。これは、提示レートからドロップ レートを差し引いた値は実際の転送レートではなく、送信される前にシェーパに保管されているパケットは含まれていないためです。

router# show policy-map int s2/0.1
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 16000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 7311/657990 
         (total drops/bytes drops) 2221/199890 

     Class-map: c2 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 44000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 7310/657900 
         (depth/total drops/no-buffer drops) 64/6650/0 

     Class-map: class-default (match-any) 
       2 packets, 382 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

2 番目の出力例で、show policy-map interface のインターフェイス カウンタはノーマライズ済みです。56 kbps PVC では、c1 クラスは約 50 kbps、c2 クラスは約 6 kbps を送信しています。

router# show policy-map int s2/0.1 
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 21000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 15961/1436490 
         (total drops/bytes drops) 4864/437760 

     Class-map: c2 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 66000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 15960/1436400 
         (depth/total drops/no-buffer drops) 64/14591/0 

     Class-map: class-default (match-any) 
       5 packets, 1096 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

手順 4：debug priority

debug priority コマンドでは、プライオリティ キューからパケットがドロップされた場合のプライオリティ キューイングの出力が表示されます。

注意：  debug コマンドを使用する前に、「debug コマンドの重要な情報」を参照してください。debug priority コマンドを実行すると、実稼働ルータ上で混乱を引き起こす大量のデバッグ情報が出力されることがあります。その量は、輻輳のレベルによって異なります。

次に、Cisco 3640 での出力例を示します。

r3-3640-5# debug priority 
Priority output queueing debugging is on 

r3-3640-5# ping 10.10.10.2 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
r3-3640-5# 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:41: PQ: Serial0/1 output (Pk size/Q 13/0) 
r3-3640-5#no debug priority 
00:42:51: PQ: Serial0/1 output (Pk size/Q 13/0) 
Priority output queueing debugging is off

次の debug priority の出力で、64 はパケットがドロップされた時点での実際のプライオリティ キューの深さを示しています。

*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64

その他のドロップの原因

LLQ による出力ドロップのその他の原因として、Cisco Technical Assistance Center（TAC）でサービス リクエストのトラブルシューティング中に発見され、Cisco の不具合レポートに記述されているものには、次のものがあります。

• 別のクラスのWeighted Random Early Detection（WRED; 重み付きランダム早期検出）の最大しきい値を増加すると、使用可能なバッファが消費され、プライオリティ キューで廃棄が発生します。この問題を診断するために、IOS の今後のリリースにはプライオリティ クラスの「no-buffer drops」カウンタが追加される予定です。

• 入力インターフェイスのキュー リミットが出力インターフェイスのキュー リミットよりも小さいと、入力インターフェイスでパケットがドロップされます。これらの症状は、Cisco Bug ID CSCdu89226（登録ユーザ専用）に記述されています。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。 入力インターフェイスでのドロップを防止し、発信プライオリティ キューイングを有効に動作させるには、入力キューと出力キューのサイズを適切に設定して、この問題を解決してください。

• CEF スイッチングまたはファースト スイッチング パスでサポートされない機能を有効にすると、大量のパケットがプロセス スイッチングされます。現在、LLQ ではインターフェイスの輻輳に関係なく、プロセス スイッチングされたパケットがポリシングされます。つまり、インターフェイスに輻輳が生じていなくても、キューイング システムはプロセス スイッチングされたパケットを測定し、負荷が、priority コマンドで設定した帯域幅を超えないようにします。この問題は、Cisco Bug ID CSCdv86818（登録ユーザ専用）に記述されています。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

プライオリティ キュー ドロップとフレームリレー

プライオリティ キューのポリシングに関して、フレームリレーは特殊ケースです。フレームリレーのLLQ機能の概要には、次の注意事項が記載されています："PQ は均等化キューが帯域幅不足に陥らないようにポリシングされます。PQを設定する場合、そのキューで使用可能な最大帯域幅を kbps で指定します。最大帯域幅を超えるパケットはドロップされます」。 すなわち、当初、フレームリレー マップ クラスに設定したサービス ポリシーのプライオリティ キューは、輻輳時も非輻輳時もポリシングされていました。IOS 12.2 では、この例外が除かれています。FRF.12 では PQ が引き続きポリシングされますが、輻輳時にドロップされるのは他の非適合パケットだけです。

関連情報

• QoS に関するサポート ページ
• Cisco IOS ソフトウェア リリース 12.2 トラフィック ポリシング フィーチャ モジュール
• テクニカルサポート - Cisco Systems