Cisco インターフェイスとモジュール : Cisco チャネル インターフェイス プロセッサ

バッファの不足または失敗

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


目次


概要

このドキュメントでは、ルーティング プロセッサ(RP)でのバッファの不足または失敗について説明します。

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

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

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

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

バッファの不足または失敗

ルーティング プロセッサ(RP)は、プロセッサ メモリをいくつかのプールに分割します。 各プールには、大きさの等しいメモリブロックが多数含まれています 。 これらのメモリ ブロックをバッファと呼びます。

バッファ プール

バッファ プールは 6 つあります。

  • 小型 104 のバイト バッファ

  • Middle:600 バイト バッファ

  • 大きい 1524 のバイト バッファ

  • VeryBig:4520 バイト バッファ

  • Large:5024 バイト バッファ

  • Huge:18024 バイト バッファ

たとえば、インターフェイス プロセッサが 20 バイトのパケットを RP に送信する必要がある場合は、Small バッファを要求します。 インターフェイス プロセッサが 500 バイトのパケットを RP に送信する必要がある場合は、Middle バッファを要求します。以降も同様です。

注: インターフェイス プロセッサは、一定のサイズのバッファを要求しなければなりません。

インターフェイス プロセッサがバッファを要求すると、次のことが行われます。

  • フリー バッファが要求されたプールにある場合、そのバッファが付与されます。 フリーバッファがない場合は、 "misses" をカウントして、バッファ アルゴリズムはそのプールに追加バッファを作成します。

  • 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 パラメータは、任意の時点でプールからバッファへの要求を予測するときに使用します。

    • in free list のバッファ数が 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:追加バッファを作成するメモリ不足により発生し た failures の数。

各プールの特性を検査して、どのプールで問題が発生しているかを判断できます。 プールが次の特性を表しているように見える場合は、プールのパラメータを調整して、ルータがロードの処理をより適切に準備できるようにすることができます。

  • misses および creates の数が高いレートで増加している(hits の比率が高い)。

  • フリー リスト内のバッファの数が常に低い。

  • failures または no memory の数が増加している。

buffers コンフィギュレーション コマンド

buffers コンフィギュレーション コマンドを使用して、各バッファ プールの次のパラメータを調整できます。

  • initial:システムのリロード時に割り当てられる一時的なバッファ。

  • max-free:フリー バッファの最大数。

  • min-free:フリー バッファの最小数。

  • permanent:固定バッファの数。

初期バッファ

ルータのリロード後にセッションを確立するときのバーストに対応できるように initial バッファを調整します。

buffers small initial 250

これらのバッファは、最終的に「削除」され、システムに戻されます。

初期バッファは、セッションの確立を処理するよう設計されていて、常にプロセス スイッチが行われます。

セッションの確立中は、(他のルーティング プロトコルによって使用される)ファースト スイッチング キャッシュが読み込まれ、 プロセス スイッチされたバッファは不要になり、システムに返されます。

初期バッファの調整は、IBM フィーチャ セットには正しいソリューションではない場合があります。これは、ほとんどすべてのパケット(セッション確立後)がプロセス スイッチされ、いずれにしても追加のバッファリングが必要になるためです。

注: IBM プロセス スイッチ フィーチャでは、一時的な初期バッファを調整するより permanent バッファを調整する方が適しています。

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 の出力で増加するカウンタに対応しています。 該当するバッファ プールが調整される場合があります。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 14620