トラブルシューティング：Cisco 12000 シリーズ インターネット ルータでの ignored パケットとメモリ不足による廃棄
内容
概要
この文書は、Cisco 12000 シリーズ インターネット ルータでの show interfaces コマンドの出力が、ignored エラーの数の増加を示している場合のトラブルシューティング方法を説明しています。また、execute-on slot <slot#> show controllers (frfab)の出力でno mem dropsが増加している場合のトラブルシューティングのヒントも示しています | tofab) qm statコマンドこうしたエラーのトラブルシューティングを行う場合は、カウンタが単なる履歴値ではなく、増加していることを確認してください。
注：show interfacesの出力に表示される入力キュードロップの増加については、「Cisco 12000シリーズインターネットルータでの入力ドロップのトラブルシューティング」で別に説明しています。
前提条件
要件
この文書を読むには、Cisco 12000 シリーズ インターネット ルータ アーキテクチャを理解している必要があります。特に、ToFab キューと FrFab キューの理解が必要です。show controllers frfabの出力の読み方を参照してください | tofab queue参照用コマンドです。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
-
Cisco 12000 シリーズ インターネット ルータをサポートするすべての Cisco IOS® ソフトウェア リリース。通常は、12.0S および 12.0ST リリースです。
-
この文書では Cisco 12000 プラットフォームのすべてを対象としています。これには、12008、12012、12016、12404、12410、および 12416 が含まれます。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
症状
Cisco 12000 シリーズ インターネット ルータでは、分散アーキテクチャを使用して転送パフォーマンスを最適化しています。高い転送レートをサポートするために、着信および発信ラインカードの両方でパケット バッファを保持しています。これらのパケット バッファにはさまざまなサイズがあり、通常は Maximum Transmission Unit（MTU; 最大伝送ユニット）サイズのフレームをサポートするように設計されています。
パケットの発信インターフェイスを決定した後、転送プロセッサは次の処理を行います。
-
転送プロセッサはパケットの情報（メモリ上の位置など）を指し示すポインタを、発信インターフェイスの仮想出力キューに送信します。
-
ラインカードのスケジューラが、スケジューラに要求を出します。マスター スケジューラが許可を出し、パケットはバッファ メモリからスイッチング ファブリックを経由して発信ラインカードに転送されます。
-
発信ラインカードはパケットをバッファに入れます。
-
発信 LC の L3 プロセッサおよび関連する Application-Specific Integrated Circuits（ASIC; 特定用途集積回路）が、インターフェイスからパケットを伝送します。
発信インターフェイスが輻輳状態になると、超過パケットのバッファリングが始まります。輻輳状態が続いている間、発信 LC の送信キューは満杯の状態が続きます。この場合は、発信 LC のエンジン タイプに応じて次のことが起こります。
| 発信 LC のエンジン タイプ | 発信輻輳への対応 | エラー カウンタ |
|---|---|---|
| エンジン 0 および 1 | バックプレッシャ信号を送信する。着信インターフェイスは超過パケットのバッファリングを開始する。 | L3 転送エンジンに応じて、show interfaces コマンド出力の ignored エラーと、着信 LC の execute-on slot <slot #> show controllers tofab QM stat コマンド出力の no mem drop のどちらか、または両方。 |
| エンジン 2、3、4 | 出力側の超過パケットをすべてドロップする。 | 発信 LC での execute-on slot <slot #> show controllers frfab QM stat コマンド出力の no mem drop。 |
1L3 エンジン 0、1、および 2 の着信 LC の場合は ignored エラーの数が取得します。しかし、エンジン 2 LC のポート数が 4、16、およびそれ以上の場合、このカウンタは増えません。
インテリジェントなネットワーク デバイスでは、1 つまたは複数の高速インターフェイスが相対的に低速のインターフェイスにデータを送信する場合、インターフェイスの速度に不一致が生じます。低速の発信インターフェイスは、高速の着信インターフェイスが出力保留キューにデータを送信する速さではバッファを戻せないため、その部分で生じた遅れがある種のドロップにつながります。このパケットの流れにより、発信インターフェイスはバッファの管理速度でバッファを戻すという前提が崩れます。
インターフェイス速度の不一致に加えて、到達するパケットの速度が CPU の処理速度を超えると、ignored エラーの数が増えます。Cisco 12000 ではこうした状況はほとんど起こりませんが、通常は非常に小さいパケットが大量に到達した場合や、Access Control List（ACL; アクセス コントロール リスト）やトラフィック ポリシングなどの CPU 中心の機能がソフトウェアに実装されている LC で、これらの機能が有効になっている場合などに、このような状況が発生します。この問題は、多くの機能がソフトウェアに実装されているエンジン 0 LC でよく起こります。しかし、それ以降のエンジンでは、ほとんどすべての機能がハードウェアに実装されています。たとえば、エッジ アプリケーション向けに設計されているエンジン 3（IP Services Engine（ISE; IP サービス エンジン））とエンジン 4+ のラインカードは拡張 IP サービス（QOS など）をハードウェアに実装していて、パフォーマンスに影響が生じることはありません。このハードウェアには、1 ポート CHOC-48 ISE、4 ポート CHOC-12 ISE、16 ポート OC-3 POS ISE、4 ポート OC-12 POS ISE、1 ポート OC-48 POS ISE、1 ポート OC-48 POS ISE などの種類があります。
ignored カウンタは、入力ラインカードに到達したパケットを処理するために適切なサイズのバッファが使用できない場合にも増えます。しかしこの状態は非常にまれなので、この文書では説明していません。
発信インターフェイスの加入過多の管理
発信インターフェイスの輻輳によって発生する ignored エラーや no mem drop を解決する方法はどの L3 エンジン タイプの場合でも同じで、バッファ不足を防止することです。つまり、FrFab キューがいっぱいにならないようにするメカニズムが必要になります。
エンジン 0 および 1
簡単に説明すれば、ignored カウンタが増えるのは、入力 Line Card（LC; ラインカード）に到達したパケットを処理するために適切なサイズのバッファが使用できない場合です。そのため一般的には、ignored パケットが Cisco IOS ソフトウェアのバグを示すことはありません。
Cisco 12000 シリーズ ルータで、0 以外の ignored カウンタを持つ show interfaces コマンドの出力例を次に示します。
router#show interfaces G3/0
GigabitEthernet3/0 is up, line protocol is up
Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980
(bia 0030.71f5.7980)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex mode, link type is force-up, media type is SX
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:00:07
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 99000 bits/sec, 74 packets/sec
5 minute output rate 104000 bits/sec, 68 packets/sec
478 packets input, 71057 bytes, 0 no buffer
Received 19 broadcasts, 0 runts, 0 giants, 0 throttles
2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored
!--- Ignored counter is > 0. Ensure it is incrementing.
0 watchdog, 53 multicast, 0 pause input
541 packets output, 139133 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
発信 LC がエンジン 0 または 1 の場合は、この発信 LC にこれ以上データを送信しないよう伝えるバックプレッシャ メッセージが発信 LC から他の LC に送信されます。着信インターフェイスはこの指示を受けて、この宛先スロットに対応する ToFab キューに超過パケットをバッファリングします。
ignored カウンタが増える最も可能性の高い原因を切り分けるためには、入力 LC の ToFab キューを調べる必要があります。ToFab キューをチェックするには、attach コマンドを使用して Maintenance BUS（MBUS; メンテナンス バス）経由で LC に接続するか、または execute-on slot <slot#> show controllers tofab queue コマンドを使用します。このコマンドを数回実行して、次の症状があるかどうかを調べます。
-
非 IPC フリー キューの #Qelem カラムの値が減少していて小さい、または 0 であること。
-
宛先スロットのキューの #Qelem カラムの値が大きいこと。
エンジン 2、3、4
最近の L3 エンジン アーキテクチャを使用したラインカードは、バックプレッシャ メカニズムを使用しません。その代わりに、インターフェイスが輻輳状態で、 FrFab キューがいっぱいになった場合、パケットは出力ラインカードに到達した時点でドロップされます。
エンジン 2 LC は、小さなバッファ プールがいっぱいになると、次に大きいプールに「フォールバック」します。たとえば、エンジン 2 LC が 300 バイトのパケットを格納する必要がある場合、まず 608 バイトのバッファを持つプールからバッファを要求します。 このプールが空の場合は、1568 バイトのプールからバッファを得ようとします。
こうしたドロップは、次のように execute-on slot <slot #> show controllers frfab QM stat コマンド出力の no mem drop（メモリ不足によるドロップ）としてカウントされます。
Router#execute-on slot 1 show controller frfab QM stat ========= Line Card (Slot 1) ======= 174 no mem drop, 0 soft drop, 0 bump count !--- Look for an incrementing value for the "no mem drop" counter 0 rawq drops, 0 global red drops, 0 global force drops 0 no memory (ns), 0 no memory hwm (Ns) no free queue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 multicast drops Tx Counts Interface 0 8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps Interface 1 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
LC で着信インターフェイスの輻輳や単純にパケットがドロップされてしまうほど、FrFab 側でパケットがバッファリングされないようにする方法を見つける必要があります。
エンジン 2 LC を除くすべてのラインカードで有効な解決策として、マルチインターフェイスの LC の特定の発信インターフェイスで使用可能なバッファの数を減らす方法があります。デフォルトでは、インターフェイスは分割された FrFab バッファのすべてを使用できます。デフォルト以外の値を設定するには、tx-queue-limit コマンドを使用します。これにより、特定のポート用のインターフェイス キューに設定された数を超えるパケットが出力 LC にバッファリングされる事態を回避できます。このコマンドには必ず、このインターフェイス用のすべての FrFab キューが含まれないような小さい数を設定してください。この方法は優先順位の高いパケットと低いパケットを区別せず、特定のインターフェイスのパケットに対して無条件にテール ドロップを行う点に注意してください。
エンジン 3 ラインカードでは、従来の Command Line Interface（CLI; コマンドライン インターフェイス）の代わりに、Modular QoS CLI（MQC; モジュラ QoS CLI）を使用する必要があります。 このコマンドはエンジン 2 ベースのラインカードではサポートされていません。
従来の Class of Service（COS; サービス クラス）設定を使用した設定例を次に示します。
interface POS 0/0
tx-queue-limit <max Q length in packets>
MQC を使用した設定例を次に示します。
policy-map TX_QUEUE_LIMIT
class class-default
queue-limit
interface POS 0/0
service-policy out TX_QUEUE_LIMIT
さらに高速の出力インターフェイスを実装して、パイプを太くするという解決策もあります。しかし、大きなパイプはすぐに充填できます。したがって、推奨されるソリューションは、アウトバウンドLCにQuality of Service(QoS)メカニズムを実装することです。
Cisco の Weighted Random Early Detection（WRED; 重み付けランダム早期検出）機能は、差別化されたインテリジェントなドロップメカニズムを実現します。この機能は、TCP フローなどの適応型のトラフィックを扱えるよう設計されています。キュー サイズを監視し、計算した平均キューが設定可能な最小しきい値を超えると、複数のフローからランダムにパケットをドロップして、一定の平均キュー サイズを維持しようとします。
Cisco 12000 シリーズに WRED を実装すると、FrFab キューがいっぱいになる事態が回避され、ドロップするパケットを選択できます。エンジン 0 LC はソフトウェアで WRED をサポートしますが、エンジン 1 LC は WRED をまったくサポートしません。その他の L3 エンジンの LC はハードウェアで WRED をサポートします。
WREDの設定の詳細については、次のドキュメントを参照してください。
この輻輳回避メカニズムが機能するのは、TCP ベースの環境だけです。TCP はトラフィック転送の速度を落とすことで、適切かつ確実にトラフィックのドロップに対応します。TCP によるパケット損失の対処方法については、「TCP によるトラフィック損失の対処方法」と「ルータと TCP との相互作用」を参照してください。
Cisco 12000 シリーズ ルータでサポートされている QOS メカニズムにはその他に、Committed Access Rate（CAR; 専用アクセス レート）を使用するトラフィック ポリシング（エンジン 0 LC）と、Per Interface Rate Control（PIRC）と呼ばれる CAR の変更バージョン（エンジン 2 LC）があります。発信インターフェイスでトラフィック ポリシングを設定してください。
着信ラインカードでの過負荷状態の CPU の管理
この状況が起こるのは非常にまれです。
着信 LC の CPU に負荷がかかりすぎているかどうかをチェックするには、execute-on slot <slot #> show controllers tofab queues コマンドを使用します。「Raw Queue」行の #Qelem カラムの数が非常に大きい場合は、大量のパケットを（LC 自体に搭載されている）CPU で処理しようとしていることを表しています。 この場合はパケットの量に CPU の処理が追いつかないため、ignored パケットが増え始めます。これらのパケットは、Gigabit Route Processor（GRP; ギガビット ルート プロセッサ）ではなく、LC の CPU に送信されます。
この時点で行うべきことは、トラフィックの一部をこの着信 LC から他へ移動し、CPU への影響を軽減させることです。
また、LC の設定を調べて、CPU に影響を与える機能が LC に設定されていないかどうかをチェックします。一部の機能（CAR、ACL、NetFlow など）がソフトウェアに実装されているために、LC のパフォーマンスを悪化させている可能性があります（エンジン 0 LC の場合のみ）。 この場合は該当する機能を削除するか、その機能の実装方法が改善されている新しいリリースに Cisco IOS ソフトウェアをアップグレードする必要があります（ターボ ACL など）。 各種 LC の実装機能や改良済みの機能を調べるには、「Cisco 12000 シリーズ ルータのリリース ノート」を参照してください。
最終的には、使用している LC を、必要な機能をハードウェアに実装している最近の LC に交換する以外に解決策がない場合があります。これは LC のエンジン タイプによります。
次のショートカット コマンドを使用すると、LC の L3 エンジン タイプを調べることができます。
Router#show diag | i (SLOT | Engine) ... SLOT 1 (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode L3 Engine: 0 - OC12 (622 Mbps) SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet L3 Engine: 2 - Backbone OC48 (2.5 Gbps) ...
注：エンジン3(IP Services Engine - ISE)およびエンジン4+ラインカードは、エッジアプリケーション向けに設計されており、ハードウェアに拡張IPサービス（QoSなど）を実装し、パフォーマンスに影響しません。
設計ガイドラインの要約
-
ターボ ACL を使用します。これにより、ACL をルータでコンパイルしてから LC プロセッサにダウンロードできるので、パフォーマンスが最適化されます。
-
ACL で「log」キーワードを使用しないようにします。
-
可能な場合は、発信 ACL を使用しないようにします。エンジン 0、1、2 の LC が搭載されたシステムでは、ACL のすべての処理が着信 LC で行われます。パケットの宛先となる発信インターフェイスが判明すると、発信 ACL フィルタリングでさえ着信カードで行われます。こうした理由から、インターフェイスで発信 ACL を設定すると、システムのすべての LC に影響がおよびます。また、エンジン 2 LC は、着信 ACL と発信 ACL のどちらも実行できますが、ハードウェア転送を実行する ASIC で両方同時に実行するわけではありません。LC に着信 ACL と発信 ACL の両方を設定すると、発信アクセス リストに対しては CPU ベースの転送へとフォールバックされるため、LC のスイッチング パフォーマンスに影響がおよびます。ただし、エンジン 3 やエンジン 4+ などの新しいエンジンは、ACL などの拡張 IP サービス向けに高度に最適化されており、発信 LC で発信 ACL を処理します。
-
特定の機能を必要とするトラフィックを特定の LC のセットに割り当てます。
-
機能を必要としないトラフィックを他の LC のセットに割り当て、ピーク時のパケット転送のパフォーマンスが下がらないようにします。
-
高いパフォーマンスが必要な場合は、上位のエンジン タイプを持つ LC を使用します。
-
バックボーンまたはコアの方向に接続する LC で、ハードウェアまたはマイクロコードでサポートされる機能を実行するように設計します。
ケース スタディ
このケース スタディでは、スロット 6 の LC のインターフェイスで増えている ignored エラーのトラブルシューティング方法を示します。
手順 1 - スロット 6 の ToFab キューをチェックする。
Router#exec slot 6 show controllers tofab queue
========= Line Card (Slot 6) =======
Carve information for ToFab buffers
SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100
134115072 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize,
2 carve(s)
max buffer data size 4544 bytes, min buffer data size 80 bytes
174538/174538 buffers specified/carved
110797216/110797216 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
4 non-IPC free queues:
88964/88964 (buffers specified/carved), 50.97%, 80 byte data size
1 21120 84604 81074 262143
54076/54076 (buffers specified/carved), 30.98%, 608 byte data size
2 122270 116965 49567 262143
26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size
3 164160 145355 19518 262143
!-- Out of the 26165 buffers that are carved, only 19518 are available
5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size
4 172325 172088 5233 262143
IPC Queue:
100/100 (buffers specified/carved), 0.5%, 4112 byte data size
30 61 60 100 262143
Raw Queue:
31 44229 88895 0 43634
!-- The Raw Queue has a low or 0 value for the #Qelem column, indicating !-- that the CPU is not overwhelmed with packets destined to it.
ToFab Queues:
Dest
Slot
0 73769 60489 0 262143
1 7909 27395 0 262143
2 61416 71346 0 262143
3 80352 14567 0 262143
4 138236 107121 18955 262143
!-- 18955 packets are waiting for space in the outbound queues !-- on the LC in slot 4.
5 4852 48171 0 262143
6 98318 111757 0 262143
7 44229 88895 0 262143
8 0 0 0 262143
9 0 0 0 262143
10 0 0 0 262143
11 0 0 0 262143
12 0 0 0 262143
13 0 0 0 262143
14 0 0 0 262143
15 0 0 0 262143
Multicast 0 0 0 262143
手順 2 - スロット 4 の FrFab キューのチェック
ToFab キューの出力は、キューに置かれている多くのパケットがスロット 4 の LC を宛先としていることを示しているため、この LC の FrFab キューをチェックします。
Router#exec slot 4 show controllers frfab queue
========= Line Card (Slot 4) =======
Carve information for FrFab buffers
SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100
66924288 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize,
2 carve(s)
max buffer data size 4544 bytes, min buffer data size 80 bytes
65534/65534 buffers specified/carved
66789056/66789056 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
4 non-IPC free queues:
26174/26174 (buffers specified/carved), 39.93%, 80 byte data size
1 10123 4332 14515 65535
19630/19630 (buffers specified/carved), 29.95%, 608 byte data size
2 27898 37167 12279 65535
13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size
3 0 52275 0 65535
!-- Zero buffers available for this pool
6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size
4 60805 60804 6543 65535
IPC Queue:
100/100 (buffers specified/carved), 0.15%, 4112 byte data size
30 75 74 100 65535
Raw Queue:
31 0 80 0 65535
Interface Queues:
0 0 39413 0 65535
1 0 44192 0 65535
2 48426 58230 32111 65535
!-- Interface 2 is using half or 32111 of the carved packet buffers
3 0 41219 0 65535
手順 3 - オーバースクライブ状態の同じインターフェイスを対象にした show interfaces コマンド出力の比較
show controllers frfab queue の出力に示された輻輳状態のインターフェイスを、同じインターフェイスの show interfaces の出力と比較します。次の出力から、出力インターフェイス速度が回線速度と同じであり、輻輳状態にあることがわかります。
Router#show interfaces POS 4/2
POS4/2 is up, line protocol is up
Hardware is Packet over SONET
Description: Pacbell OC3 to other ISP...
Internet address is 10.10.10.10/30
MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255
Encapsulation HDLC, crc 32, loopback not set
Keepalive set (10 sec)
Scramble enabled
Last input 00:00:01, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: FIFO Output queue 0/300, 0 drops; input queue 0/300,
0 drops
5 minute input rate 20274000 bits/sec, 6263 packets/sec
5 minute output rate 148605000 bits/sec, 28776 packets/sec
!-- The output interface rate is at line rate which means that the interface !-- is oversubscribed.
1018621328 packets input, 2339977099 bytes, 0 no buffer
Received 0 broadcasts, 1 runts, 0 giants, 0 throttles
0 parity
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
378645 packets output, 156727974 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
手順 4 - ソリューションの実装
このステップでは、特定の発信インターフェイスのアーキテクチャに基づいて増加する ignored エラーを解決します。解決策については、この文書の「症状」の項を参照してください。たとえばエンジン 0 LC では、一部のトラフィックを他のインターフェイスに振り分けるようにするか、一時的な措置として、このインターフェイスがラインカードのフリー キューから使用できるパケット バッファの数を減らします。次のコマンドを使用します。
Router(config)#int POS 4/2 Router(config-if)#tx-queue-limit 5000
Cisco IOS ソフトウェアの不具合
Cisco IOS ソフトウェアのバグが原因でカウンタが増える場合があります。該当するトレインの最新の Cisco IOS ソフトウェア リリースを使用していて、すでに修正済みのバグがすべて取り除かれていることを確認してください。それでも ignored パケットが解消されず、この文書の情報では問題が解決しない場合は、Cisco Technical Assistance Center（TAC）にお問い合せください。
フィードバック