このドキュメントでは、ルータのインターフェイスでのプライオリティ キューイングのメカニズム設定が原因で発生する出力ドロップのトラブルシューティング方法について説明しています。
このドキュメントの読者は、次の概念について理解している必要があります。
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; コマンドライン インターフェイス)のコマンド ストラクチャを使用します。
上記のどの方式が設定されていても、ルータでの出力ドロップのレポートは可能ですが、それぞれの場合での方式とドロップの理由には重要な機能上の違いがあります。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
『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 バイトも削除されません。
データを収集するための手順は、次のとおりです。
次のコマンドを数回実行し、ドロップ数がどの程度の速さと頻度で増加するかを調べます。出力を分析して、トラフィック パターンとトラフィック レベルの基準を作成します。インターフェイスの「平常時」のドロップ レートを判断してください。
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
次の方法で、トラフィック フローおよびパケットの特性を判断します。
パケットの平均サイズはどのくらいなのか。
MTU サイズのフレームのフローはどの方向に向かっているのか。多くのトラフィック フローは、負荷に関して非同期です。たとえば、FTP ダウンロードの場合、MTU サイズのパケットの大部分は FTP サーバからクライアントに対して送信されます。FTP クライアントからサーバへのパケットは単純な TCP ACK です。
パケットはTCPかUDPを使用していますか。TCP では、承認されたパケット数だけを各フローで送信することができますが、承認されたパケット数を超えると発信元によって送信が一時停止され、送信されたパケットの宛先による確認応答が待機されます。
フレームリレーの場合は、インターフェイス キューまたはVirtual Circuit(VC; 仮想回線)単位のキューでドロップが発生しているかどうかを確認します。次の図は、フレームリレー仮想回線のパケット フローを示しています。
プライオリティ キューイングでは、プライオリティ キュー レベルの異なる出力キューが最大で 4 つサポートされ、各キューにキュー制限が定義されています。このキューイング システムでは、パケットをキューに入れる前に、設定されたキュー制限に対するキューのサイズがチェックされます。選択されたキューが満杯の場合、ルータはパケットをドロップします。priority-list {#} queue-limit コマンドでキューのサイズを増加させ、モニタリングを再開してください。
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:コール単位の帯域幅の使用量』を参照してください。
インターフェイス上のプライオリティ キューから送信される一連のパケットの処理は、パケットのサイズおよびトークン バケットに残っているバイト数によって異なります。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
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 が引き続きポリシングされますが、輻輳時にドロップされるのは他の非適合パケットだけです。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
15-Feb-2008 |
初版 |