バッファの不足または失敗
概要
このドキュメントでは、ルーティング プロセッサ（RP）でのバッファ ミスとバッファの障害について説明します。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
バッファの不足または失敗
ルーティング プロセッサ（RP）は、プロセッサ メモリをいくつかのプールに分割します。各プールには、大きさの等しいメモリ ブロックが多数含まれています。これらのメモリ ブロックをバッファと呼びます。
バッファ プール
バッファ プールは 6 つあります。
-
Small：104 バイト バッファ
-
Middle：600 バイト バッファ
-
Big：1524 バイト バッファ
-
VeryBig：4520 バイト バッファ
-
Large：5024 バイト バッファ
-
Huge：18024 バイト バッファ
たとえば、インターフェイス プロセッサが 20 バイトのパケットを RP に送信する必要がある場合は、Small バッファを要求します。インターフェイス プロセッサが 500 バイトのパケットを RP に送信する必要がある場合は、Middle バッファを要求します。以降も同様です。
注：インターフェースプロセッサは、特定のサイズのバッファを要求する必要があります。
インターフェイス プロセッサがバッファを要求すると、次のことが行われます。
-
要求されたプールにフリー バッファがある場合は、そのバッファが付与されます。フリー バッファがない場合は、“miss” をカウントして、バッファ アルゴリズムはそのプールに追加バッファの作成を試行します。
-
IOS が Small バッファの取得に失敗した場合はパケットをドロップせず、failures カウンタを増やして次のレベルのバッファ、つまり Middle バッファに対象を変え、そこのバッファを要求します。Middle バッファの取得に失敗した場合は、次のレベルである Big バッファを要求します。このプロセスは Huge バッファ プールに到達するまで続けられます。Huge バッファの取得に失敗した場合はパケットをドロップします。
-
IBM フィーチャ セットを使用している場合のバッファ ミスはほぼすべて失敗にカウントされます。
-
IBM フィーチャがプロセス スイッチされた場合でも、インターフェイスから RP へパケットを送信するためのバッファを入手するコードが、割り込みレベルで実行されます
-
バッファは、割り込みレベルでは作成できないため、ミスは、RP へのバッファ増加要求をキューに入れます。
-
スポットでは追加バッファを作成できないため、バッファ要求は失敗し、パケットはドロップされます。
バッファの失敗は、パケットがドロップされる最も一般的な理由の一つです。バッファの失敗によりパケットのドロップが発生した場合は、次のことが起こります。
-
バッファが失敗した後、RP では、特定のプールに適切なサイズの追加バッファを作成する要求が未処理となります。
-
RP がバッファの作成要求に対応している間に、プールではさらに失敗が発生する可能性があります。
-
RP は、過度にバッファを要求されると、システムのメモリ制約により追加バッファの作成にさえ失敗する場合があります。
-
基本的に、バッファ作成のオペレーションには数マイクロ秒かかりますが、その間にもパケットはバッファ不足によりドロップされ続けます。
-
さらに、バッファが作成と同時に使用された場合、RP はパケット処理よりもバッファ作成に多くの時間を費やさざるを得なくなる可能性があります。
-
これにより、パフォーマンスの低下やセッションの損失を招くほどの速さでパケットがドロップされ始める可能性があります。
幸い、バッファの失敗に関する問題は、このドキュメントで述べるように、判別および解決が難しいものではありません。次の show buffers コマンド出力は、ルータのバッファ プールの現在の状態を示したものです。
dspu-7k#show buffers
Buffer elements:
500 in free list (500 max allowed)
2370 hits, 0 misses, 0 created
Public buffer pools:
Small buffers, 104 bytes (total 16, permanent 10):
11 in free list (0 min, 10 max allowed)
1770 hits, 33 misses, 22 trims, 28 created
9 failures (0 no memory)
Middle buffers, 600 bytes (total 90, permanent 90):
89 in free list (10 min, 200 max allowed)
590 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Big buffers, 1524 bytes (total 90, permanent 90):
90 in free list (5 min, 300 max allowed)
126 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10):
10 in free list (0 min, 300 max allowed)
50 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 10, permanent 10):
10 in free list (0 min, 30 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 2, permanent 0):
0 in free list (0 min, 13 max allowed)
2 hits, 2 misses, 0 trims, 2 created
0 failures (0 no memory)
show buffers の出力には、次の項目があります。
-
Total：プール内のバッファの総数。これには使用済みバッファと未使用バッファが含まれます。
-
Permanent：プール内の割り当て済みバッファの固定数。これらのバッファは常にプール内にあり、削除することはできません。
-
In free list：現在プール内にあって利用可能なバッファの数。
-
Min：RP がフリー リスト内に確保を試みる必要のあるバッファの最小数。
-
min パラメータは、任意の時点でプールからバッファへの要求を予測するときに使用します。
-
フリー リスト内のバッファの数が min の値を下回ると、RP はそのプールにさらにバッファを作成しようとします。
-
-
Max-allowed：フリー リスト内に許可されるバッファの最大数。
-
max-allowed パラメータは、不要になったバッファにプールを独占されないようにします。また、他の用途に備えてシステムにこのメモリを戻して解放します。
-
フリー リスト内のバッファの数が max-allowed の値を上回ると、RP はプールからバッファを削除しようとします。
-
-
Hits：プールから要求されているバッファの数。hits カウンタは、どのプールをバッファの上限の要求に適合させる必要があるのかを判定する仕組みを提供します。
-
Misses：バッファが要求され、バッファの追加が必要なプールを RP が検出した回数。つまり、フリー リスト内のバッファの数が、min レベルを下回ったことを意味します。misses カウンタは、RP が追加バッファの作成を強いられた回数を表します。
-
Trims：RP がプールから削除したバッファの数。削除が行われるのは、フリー リスト内のバッファの数が max-allowed バッファ数を上回ったときです。
-
Created：プール内に作成されたバッファの数。バッファは次の状況になると作成されます。
-
バッファへの要求が増加し、フリー リスト内のバッファ数が min バッファ数を下回った場合。
-
フリー リストにバッファがないために miss が発生した場合。
-
上記の 2 つの状況になった場合。
-
-
Failures：IOS が Small バッファの取得に失敗して、パケットをドロップしなかった回数。failures カウンタを増やして次のレベルのバッファ、つまり Middle バッファに対象を変え、そこのバッファを要求します。Middle バッファの取得に失敗した場合は、次のレベルである Big バッファを要求します。このプロセスは Huge バッファ プールに到達するまで続けられます。Huge バッファの取得に失敗した場合はパケットをドロップします。
-
No memory：メモリ不足が原因で、追加のバッファの作成に失敗した回数。
各プールの特性を検査して、どのプールで問題が発生しているかを判断できます。プールが次の特性を表しているように見える場合は、プールのパラメータを調整して、ルータがロードの処理をより適切に準備できるようにすることができます。
-
misses および creates の数が高いレートで増加している（hits の比率が高い）。
-
フリー リスト内のバッファの数が常に低い。
-
failures または no memory の数が増加している。
buffers コンフィギュレーション コマンド
buffers コンフィギュレーション コマンドを使用して、各バッファ プールの次のパラメータを調整できます。
-
initial：システムのリロード時に割り当てられる一時的なバッファ。
-
max-free：フリー バッファの最大数。
-
min-free：フリー バッファの最小数。
-
permanent：固定バッファの数。
初期バッファ
ルータのリロード後にセッションを確立するときのバーストに対応できるように initial バッファを調整します。
buffers small initial 250
これらのバッファは、最終的に「削除」され、システムに戻されます。
初期バッファはセッション確立の処理を目的にしていますが、セッションの確立時は必ずプロセス スイッチが行われます。
セッションの確立中は、（他のルーティング プロトコルによって使用される）ファースト スイッチング キャッシュが読み込まれ、プロセス スイッチされたバッファは不要になり、システムに戻されます。
初期バッファの調整は、IBM フィーチャ セットには正しいソリューションではない場合があります。これは、ほとんどすべてのパケット（セッション確立後）がプロセス スイッチされ、いずれにしても追加のバッファリングが必要になるためです。
注：IBMのプロセススイッチ機能の場合は、一時の初期バッファを調整する代わりに、固定バッファを調整する必要があります。
max-free バッファ
max-free バッファの値は、permanent バッファ以上になるように調整します。すべての permanent バッファがフリー リスト内にある場合は、permanent バッファの削除を RP が試行する必要はありません。max-free を使用すると、不定期なバースト中に作成された未使用のバッファをシステム メモリに確実に戻すことができます。
buffers small max-free 175 buffers small permanent 125
min-free バッファ
min-free バッファの値は、絶対に必要なバッファの推定最小数を表すように調整します。min-free を使用すると、バッファ不足状態を予測したり、最小限のバッファ数を常に利用できる状態にすることができます。
buffers small min-free 50
permanent バッファ
permanent バッファの値は、通常の処理に必要なバッファの推定数が表されるように調整します。
buffers small permanent 125
permanent バッファは、ルータの通常のバッファ要件（頻繁なバーストを含む）への対応に使用されます。通常のバッファ要件の判別は、対話型プロセスであり、ここで、show buffer 出力には、特定の時点にプールで使用された合計バッファが示される必要があります。permanent バッファは、必要な一貫した "total" バッファを考慮して調整する必要があります。permanent バッファを調整するときは、creates が減って misses と failures がなくなることを重視する必要があります。
その他の show コマンド
バッファの割り当てに関する問題の判別に使用できる show コマンドは他に 2 つあります。
-
show interfaces interface-identifier
-
show source-bridge
次の show interfaces interface-identifier コマンドの出力例には no buffer のカウンタが含まれています。
dspu-7k#show interfaces channel 4/2
Channel4/2 is up, line protocol is up
Hardware is cxBus IBM Channel
MTU 4472 bytes, BW 98304 Kbit, DLY 100 usec, rely 255/255, load 1/255
Encapsulation CHANNEL, loopback not set, keepalive not set
Virtual interface
Last input 0:00:04, output 0:00:04, output hang never
Last clearing of "show interface" counters never
Output queue 0/40, 0 drops; input queue 0/75, 8 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
646 packets input, 27760 bytes, 8 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
328 packets output, 16959 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
show interfaces interface-identifier コマンドの出力では、次の内容が示されます。
-
no buffer カウンタは、インターフェイスが着信パケット用のバッファの取得に失敗すると増加します。
-
no buffer と drops（入力キュー）の両カウンタは、インターフェイスが着信パケット用のバッファの取得に失敗すると増加します。
-
no buffer カウンタは show interfaces の出力の中で増加しますが、このカウンタは misses という show buffers の出力で増加するカウンタに対応しています。該当するバッファ プールが調整される場合があります。
次に示す show source-bridge の出力には、インターフェイスにソースルート ブリッジング（SRB）が設定されている場合の throttles を示すインターフェイス カウンタが含まれています。
dspu-7k#show source-bridge
Local Interfaces: receive transmit
srn bn trn r p s n max hops cnt:bytes cnt:bytes drops
Ch4/2 666 1 99 * f 7 7 7 652:26020 6:266 0
Global RSRB Parameters:
TCP Queue Length maximum: 100
Ring Group 99:
This TCP peer: 150.10.20.2
Maximum output TCP queue length, per peer: 100
Peers: state bg lv pkts_rx pkts_tx expl_gn drops TCP
TCP 150.10.20.1 open *3 261 266 0 0 0
TCP 150.10.20.2 - *3 0 0 0 0 0
Rings:
bn: 1 rn: 888 locvrt ma: 4000.7000.fff1 Buff Ring888 fwd: 0
bn: 1 RN: 666 local ma: 4000.0c48.2e80 Channel4/2 fwd: 261
bn: 1 RN: 88 remote ma: 4000.4000.fff1 TCP 150.10.20.1 fwd: 322
bn: 1 RN: 250 remote ma: 4000.300f.7c09 TCP 150.10.20.1 fwd: 0
Explorers: ------- input ------- ------- output -------
spanning all-rings total spanning all-rings total
Ch4/2 0 0 0 0 1 1
Local: fastswitched 0 flushed 0 max Bps 256000
rings inputs bursts throttles output drops
Ch4/2 0 0 8 0
show source-bridge コマンドの出力では、次の内容が示されます。
-
throttles カウンタは、インターフェイスが着信パケット用のバッファの取得に失敗すると増加します。
-
throttles カウンタは show interfaces コマンドの出力の中で増加しますが、このカウンタは misses という show buffers の出力で増加するカウンタに対応しています。該当するバッファ プールが調整される場合があります。
フィードバック