Cisco IOS と NX-OS ソフトウェア : Cisco IOS ソフトウェア リリース 12.1 メインライン

メモリ問題のトラブルシューティング

2008 年 12 月 4 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 11 月 28 日) | フィードバック

Interactive:This document offers customized analysis of your Cisco device.


目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
メモリ割り当ての失敗とは
症状
「Unable to Create EXEC」エラーまたはコンソールが応答しない場合
エラー メッセージについて
考えられる原因
      プロセッサ メモリの場合(すべてのプラットフォームでの「Pool Processor」)
      パケット メモリの場合(ハイエンド ルータでは「I/O」または「Processor」、7200 シリーズと VIP カードでは「PCI」)
トラブルシューティング
      セキュリティ関連の問題
      メモリ サイズが Cisco IOS ソフトウェア イメージの要件を満たしていない
      メモリ リークの不具合
      正常または異常プロセスによる大量のメモリ使用
      メモリ断片化の問題または不具合
      プロセスでのメモリ割り当ての失敗 = interrupt level
      ユーザ別アクセス リストをダウンロードすることによるメモリの減少
      既知の問題
      インターフェイス用の共有メモリの不足
      バッファ リークの不具合
      ルータのファースト メモリの不足
      IPFAST-4-RADIXDELETE: Error trying to delete prefix entry [IP_address]/[dec] (expected [hex], got [hex])
      %SYS-2-CHUNKEXPANDFAIL: Could not expand chunk pool for TACL Bitmap. No memory available
トラブルシューティングの要約
      Pool「Processor」メモリ割り当ての失敗
      Pool「I/O」メモリ割り当ての失敗(ハイエンド ルータでは「Processor」、7200 シリーズでは「PCI」)
TAC のサービスリクエストをオープンする場合に収集すべき情報
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

このドキュメントでは、Memory Allocation Failure(MALLOCFAIL; メモリ割り当てエラー)の症状と、考えられる原因について説明し、メモリ問題のトラブルシューティングのためのガイドラインを示しています。

前提条件

要件

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

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • すべての Cisco IOS(R) ソフトウェア バージョン

  • すべての Cisco ルータ

注:このドキュメントは Cisco Catalyst スイッチや MGX プラットフォームには適用されません。

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

表記法

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

メモリ割り当ての失敗とは

メモリ割り当ての失敗とは、次のいずれかを意味します。

  • ルータが使用可能なメモリを(一時的または継続的に)すべて使い果たした。

  • メモリが細かく断片化し、ルータが使用可能なブロックを見つけることができない。これはプロセッサ メモリ(Cisco IOS が使用するメモリ)またはパケット メモリ(着信および発信パケットが使用するメモリ)で発生します。

症状

メモリ割り当てエラーの症状には次のようなものがありますが、これらに限定されるものではありません。

  • コンソールまたはログに、次のメッセージが出力される。「%SYS-2-MALLOCFAIL:Memory allocation of 1028 bytes failed from 0x6015EC84, Pool Processor, alignment 0」

  • Telnet セッションの拒否

  • コンソールにどのコマンドを入力しても、show processor memory コマンドが表示される。

  • 一部の show コマンドから何も出力されない。

  • 「Low on memory」メッセージが出力される。

  • コンソールにメッセージ「Unable to create EXEC - no memory or too many processes」が出力される。

  • ルータがハングし、コンソールがまったく応答しない。

「Unable to Create EXEC」エラーまたはコンソールが応答しない場合

ルータのメモリが不足すると、そのルータに Telnet できなくなる場合があります。この場合は、すぐにコンソール ポートにアクセスして、トラブルシューティングに必要なデータを収集することが重要です。コンソール ポートに接続する際に、次のように表示されることがあります。

%% Unable to create EXEC - no memory or too many processes

上記のメッセージが表示されたときは、コンソール接続に必要なメモリさえ不足している状態にあります。ただし、この場合でもコンソールからデータを取得する方法があります。ルータのメモリを一部解放してやると、コンソールの応答が可能になり、トラブルシューティングに必要なデータをルータから取得できるようになります。

注:ルータで Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)が設定されている場合は、『最適ルーティングの実現と BGP メモリ消費の削減』を参照して、このプロセスに関連するメモリ消費を減らす必要があります。

メモリが極端に不足した状況では、次の手順に従って、コンソール ポートからデータを取得します。

  1. ルータのインターフェイスから LAN ケーブルと WAN ケーブルを取りはずします。これでルータのパケット送受信が停止します。

  2. コンソールをもう一度チェックします。応答があるか、またコマンドを実行できるかを確認します。しばらく経つと、コンソールが応答できるだけのメモリが使用可能になります。

  3. 特権 EXEC モード(Router#)から必要な情報を収集します。少なくとも、show memory allocating-process totals コマンド(または show memory allocating-process totals を使用できない場合は show memory summary)と show logging コマンドの出力を完全に収集する必要があります。可能であれば、show technical-support コマンドの出力も収集します。

  4. 必要なデータを収集し終えたら LAN リンクと WAN リンクをすべて再接続し、引き続きルータのメモリ使用状況を監視します。

エラー メッセージについて

show logging コマンドを実行すると、次のような出力が表示されます。

%SYS-2-MALLOCFAIL: Memory allocation of [X] bytes failed from
0x6015EC84, pool [Pool], alignment 0 -Process= 
"[Process]" ipl= 6, pid=5

[X] はルータが割り当てを試みたものの、割り当てに必要な空きメモリが見つからなかったバイト数です。

[Pool] は、プロセッサ メモリ(「Pool Processor」)とパケット メモリ(「pool I/O」)のいずれに影響が出ているかを示します。ハイエンド ルータ(7000、7500 シリーズ)はメインの DRAM 内にバッファを持つため、パケット メモリの不足は「pool processor」としてレポートされます。7200 シリーズと Versatile Interface Processor(VIP; バーサタイル インターフェイス プロセッサ)カードでは、パケット メモリの不足がプール プロトコル制御情報のエラー(「pool PCI」)としてレポートされる場合もあります。

[Process] はメモリ不足の影響を受けたプロセスです。

考えられる原因

プロセッサ メモリの場合(すべてのプラットフォームでの「Pool Processor」)

メモリ サイズが Cisco IOS ソフトウェア イメージの要件を満たしていない

メモリ リークの不具合

正常または異常プロセスによる大量のメモリ使用

メモリ断片化の問題または不具合

プロセスでのメモリ割り当ての失敗 = <interrupt level>

既知の問題

70x0 問題(フラッシュまたはネットブートから大きな Cisco IOS ソフトウェアをロードする場合に発生)

IP Input および CiscoWorks UT ディスカバリ

パケット メモリの場合(ハイエンド ルータでは「I/O」または「Processor」、7200 シリーズと VIP カードでは「PCI」)

インターフェイス用の共有メモリの不足

バッファ リークの不具合

ルータのファースト メモリの不足

トラブルシューティング

セキュリティ関連の問題

一般に、MALLOCFAIL エラーは、ネットワーク内で活動するワームやウィルスなどを原因としたセキュリティ関連の問題によって発生します。特に、ルータの IOS のアップグレードなどのネットワークに対する変更を直前に加えていない場合は、これが原因である可能性が大きくなります。通常は、アクセス リストに行を追加するといった設定の変更によって、この問題の影響を軽減できます。『Cisco 製品の Security Advisory と Notice』のページには、考えられる原因の検出方法と、具体的な回避策が記載されています。

詳細については、次を参照してください。

メモリ サイズが Cisco IOS ソフトウェア イメージの要件を満たしていない

まず、『リリース ノート登録ユーザ専用)』または Download Software Area登録ユーザ専用)で、実行中の機能セットとバージョンの最小メモリ サイズをチェックします。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。
これらが十分満たされていることを確認します。Cisco Connection Online(CCO)に掲載されているメモリ要件は、一般的な企業ネットワークでルータが正常に動作するための最小推奨サイズです。実際のメモリ要件は、プロトコル、ルーティング テーブル、トラフィック パターンなどによって異なります。

メモリ リークの不具合

ご使用の Cisco デバイスの、show memory allocating-process totals コマンド、show memory summary コマンド、または show technical-support コマンドの出力データがあれば、アウトプットインタープリタ を使用して今後予想される障害や修正を表示できます。アウトプットインタープリタ を使用するためには、 登録ユーザであり、ログインしていて、さらに JavaScript を有効にしている必要があります。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

メモリ リークは、あるプロセスによってメモリが要求されるか、または割り当てられ、タスク終了後にメモリが解放(割り当て解除)されない場合に発生します。結果として、ルータがリロードされるまでの間、メモリ ブロックが専有されます。時間が経つにつれて、プロセスによって割り当てられるメモリ ブロックが増え、最終的に使用可能な空きメモリがなくなります。その時点でのメモリ不足の程度によっては、ルータをリロードしない限り稼働状態に戻らない場合があります。

これは、Cisco IOS の不具合です。この不具合を取り除くには、リリーストレインの最新のバージョンにアップグレードしてください(たとえば、Cisco IOS(R) ソフトウェア リリース 11.2(14)を使用している場合は、最新の 11.2(x)イメージにアップグレードします)。

それでも問題が解決しない場合、またはルータのアップグレードを希望しない場合は、定期的に(たとえば、メモリ リークの速度に応じて数時間から数日間隔で)show processes memory コマンドを入力します。これによって、空きメモリの減少が続き、元に戻らないかどうかをチェックします。空きメモリが減少する速度は、リークの原因となるイベントが発生する頻度によって異なります。メモリが解放されないため、メモリ スナップショットの経過を取得して、メモリを使用しているプロセスを追跡します。さまざまなプロセスが必要に応じてメモリの割り当てと解放を行うため、メモリ スナップショットは変動しますが、リークが続くにつれて、より多くのメモリを継続的に消費しているプロセスを特定できます(注:Border Gateway Protocol(BGP; ボーダーゲートウェイ プロトコル)や Open Shortest Path First(OSPF)ルータなどの一部のプロセスは、通常の動作で 1 MB を超えるメモリを使用しますが、これはメモリ リークが発生しているわけではありません)。

より多くのメモリを継続的に消費しているプロセスを特定するには、一定の間隔で show processes memory コマンドを実行し、Holding カラムを比較します。あるプロセスが数 MB のメモリを専有していることが、はっきりとわかる場合があります。問題のプロセスを発見するために、スナップショットを数回取る必要がある場合もあります。著しい量のメモリが失われる場合は、さらに踏み込んだトラブルシューティングを行うために、show memory allocating-process totals コマンドまたは show memory summary コマンドの結果を収集します。次に Cisco Technical Assistance Center(TAC)に連絡し、収集した情報と、ルータの show technical-support サマリーを提供してください。

アウトプットインタープリタ ツールを使用すると、show memory allocating-process totals コマンドまたは show memory summary の出力の分析結果が得られます。

次の表は、show memory summary コマンドの出力の最初の 3 行を示しています。

Router>show memory summary 

            Head       Total (b)   Used (b)  Free (b)   Lowest (b)  Largest (b)
Processor   60AB4ED0   5550384     2082996   3467388    3464996     3454608
I/O         40000000   16777216    1937280   14839936   14839936    14838908

Total = システム イメージがデータ構造をロードおよびビルドした後に使用可能なメモリ量の合計。

Used = 現在割り当てられているメモリの量。

Free = 現在空いているメモリの量。

Lowest = ルータが最後にブートされてから記録された最小の空きメモリ量。

Largest = 現在使用可能な空きメモリ ブロックの最大量。

show memory allocating-process totals コマンドには、show memory summary コマンドの最初の 3 行と同じ情報が含まれています。

show processes memory コマンドの出力から、次のことがわかります。

Router>show processes memory 
Total: 3149760, Used: 2334300, Free: 815460

PID   TTY   Allocated    Freed      Holding    Getbufs    Retbufs   Process
0     0     226548       1252       1804376    0          0         *Initialization*
0     0     320          5422288    320        0          0         *Scheduler*
0     0     5663692      2173356    0          1856100    0         *Dead*
1     0     264          264        3784       0          0         Load Meter
2     2     5700         5372       13124      0          0         Virtual Exec
3     0     0            0          6784       0          0         Check heaps
4     0     96           0          6880       0          0         Pool Manager
5     0     264          264        6784       0          0         Timers
6     0     2028         672        8812       0          0         ARP Input
7     0     96           0          6880       0          0         SERIAL A' detect
8     0     504          264        7024       0          0         ATM ILMI Input
9     0     0            0          6784       0          0         ILMI Process
10    0     136          0          6920       0          0         M32_runts pring
11    0     136          0          6920       0          0         Call drop procs
12    0     340          340        12784      0          0         ATMSIG Timer
13    0     445664       442936     13904      0          0         IP Input
14    0     2365804      2357152    17992      0          0         CDP Protocol
15    0     528          264        7048       0          0         MOP Protocols
16    0     188          0          9972       0          0         IP Background
17    0     0            1608       6784       0          0         TCP Timer
18    0     5852116      0          14236      0          0         TCP Protocols

Allocated = ルータがブートして以降、プロセスによって割り当てられたメモリの総バイト数。

Freed = このプロセスによって解放されたメモリの総バイト数。

Holding = このプロセスによって現在専有されているメモリの総バイト数。このカラムは、このプロセスに割り当てられているメモリの実際の量を示しているため、トラブルシューティングの際には最も重要です。Holding は Allocated から Freed を引いた値とは必ずしも一致しません。これは、あるプロセスに割り当てられたメモリのブロックが、後で別のプロセスによって空きプールに戻される場合があるためです。

*Dead* プロセス

*Dead* プロセスは、実際のプロセスではありません。このプロセスは、すでに終了した別のプロセスのコンテキストで割り当てられたメモリを分類するためのものです。このプロセスに割り当てられたメモリはカーネルによって回収され、ルータ自体によって必要に応じてメモリ プールに戻されます。IOS では、次のようにメモリが処理されます。メモリ ブロックは、そのブロックを作成したプロセスが終了して実行されなくなった場合に Dead 状態であると見なされます。各ブロックには、そのブロックを作成したプロセスのアドレスおよび pid が記録されています。定期的なメモリの集計処理時に、スケジューラによってブロックの pid から検索されたプロセスとブロックに記録されているプロセスが一致しない場合、そのブロックは Dead 状態としてマーキングされます。

したがって、プロセス *Dead* に属するとマーキングされているメモリは、すでに実行されなくなったプロセスによって割り当てられたメモリです。通常、このような状態のメモリは大量に存在します。次に例を示します。

Telnet セッションでは、Network Address Translation(NAT; ネットワーク アドレス変換)を構成する際にメモリが割り当てられます。このメモリは、Telnet プロセス(「Virtual Exec」)で割り当てられたものと見なされます。このプロセスが終了した後も、NAT 構成のためのメモリはまだ使用されています。これは、*Dead* プロセスで示されます。

このメモリがどのコンテキストで割り当てられたかは、show memory dead コマンドの「What」カラムに表示されます。

Router#show memory dead 
               Head   Total(b)    Used(b)    Free(b)  Lowest(b) Largest(b) 
      I/O    600000    2097152     461024    1636128    1635224    1635960 
  
          Processor memory 
  
 Address  Bytes Prev.    Next     Ref  PrevF   NextF   Alloc PC  What 
1D8310       60 1D82C8   1D8378     1                  3281FFE   Router Init 
2CA964       36 2CA914   2CA9B4     1                  3281FFE   Router Init 
2CAA04      112 2CA9B4   2CAAA0     1                  3A42144   OSPF Stub LSA RBTree 
2CAAA0       68 2CAA04   2CAB10     1                  3A420D4   Router Init 
2ED714       52 2ED668   2ED774     1                  3381C84   Router Init 
2F12AC       44 2F124C   2F1304     1                  3A50234   Router Init 
2F1304       24 2F12AC   2F1348     1                  3A420D4   Router Init 
2F1348       68 2F1304   2F13B8     1                  3381C84   Router Init 
300C28      340 300A14   300DA8     1                  3381B42   Router Init 

メモリ リークが検出され、*Dead* プロセスがメモリを消費している可能性がある場合は、show memory dead の情報も含めて Cisco TAC に提供してください。

正常または異常プロセスによる大量のメモリ使用

これは確認が非常に困難な原因の 1 つです。この問題の特徴は、空きメモリが大量にあるにもかかわらず、「Lowest」カラムの値が小さい点にあります。このケースでは、正常または異常なイベント(たとえば、大量のルーティングによって不安定になるなど)が原因で、ルータが短時間のうちにきわめて大量のプロセッサ メモリを使用し、この間にメモリが枯渇します。この状況が発生している間は、ルータから MALLOCFAIL が報告されます。まもなくメモリが解放され、問題が解消される場合もあります(たとえば、ネットワークが安定するなど)。メモリ不足は、たとえば次のような要因が重なり合って発生することもあります。

  • メモリ リークによって大量のメモリが消費され、続いてネットワークが不安定になって空きメモリがゼロになる。

  • ルータに最初から十分なメモリがないにもかかわらず、まれなネットワーク イベントでしか問題が顕在化しない。

ルータがリブートされていない場合は、show memory allocating-process totals コマンド(show memory allocating-process totals が使用できない場合は、show memory summary コマンド)を入力して最初の 3 行を確認してください。ログ メッセージに、大量のメモリを消費しているプロセスを特定する手がかりがある場合があります。

メモリが大量に使用される原因が、

  • 通常のイベントの場合は、メモリの増設が解決策になります。

  • まれなイベント、または異常なイベントの場合は、関連する問題を修正する必要があります。その後、将来の「保険」として追加のメモリを購入することもできます。

メモリ断片化の問題または不具合

これは、あるプロセスが大量のプロセッサ メモリを消費し、その大部分またはすべてを解放した後、このプロセス、または問題発生中にメモリが割り当てられた別のプロセスによって、メモリの断片が割り当てられたままになっている状況を示します。同じイベントが何度も発生する場合は、メモリが非常に小さなブロックに断片化しているため、より大きなメモリ ブロックを要求するすべてのプロセスに、必要なメモリ量を割り当てられなくなっている可能性があります。このようにメモリの断片化が進むと、ルータの動作に影響がおよび、ルータへの接続やプロンプトの取得が不可能になる場合があります。

この問題の特徴は、show memory コマンドの「Largest」カラムの値が小さい(20,000 バイト未満)にもかかわらず、「Freed」カラムの値は十分(1 MB 以上)であるか、またはこの 2 つのカラムの値の差が大きい点にあります。この問題は、ルータが極端なメモリ不足になると発生する可能性があります。これは、IOS には断片化を解消するルーチンがないためです。

メモリ断片化の疑いがある場合は、いくつかのインターフェイスをシャットダウンします。これにより、断片化したブロックが解放される場合があります。この方法が有効であれば、メモリの動作は正常であり、メモリを追加するだけで問題は解決します。インターフェイスをシャットダウンしても解決しない場合は、不具合である可能性があります。この場合は Cisco のサポート担当者に連絡し、収集した情報を提供してください。

プロセスでのメモリ割り当ての失敗 = interrupt level

この状況は、エラー メッセージ中のプロセスによって特定できます。プロセスが次の例のように <interrupt level> として示されている場合、このメモリ割り当ての失敗は、ソフトウェアの問題によって引き起こされています。

"%SYS-2-MALLOCFAIL: Memory allocation of 68 bytes failed from 0x604CEF48, 
pool Processor, alignment 0-Process= <interrupt level>, ipl= 3"

これは、Cisco IOS の不具合です。Bug Toolkit登録ユーザ専用)を使用して、この問題に該当するソフトウェア Bug ID を検索できます。ソフトウェアの不具合を特定したら、問題を解決するための修正が含まれたバージョンの Cisco IOS ソフトウェアにアップグレードします。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

ユーザ別アクセス リストをダウンロードすることによるメモリの減少

ユーザごとにアクセス リストを使用すると、大量のメモリを消費する場合があります。この場合には、アクセス リストはミニ Access Control List(ACL; アクセス コントロール リスト)として分類するには大き過ぎるため、ターボ ACL としてコンパイルされます。この場合、毎回 TACL プロセスが起動され、新しい ACL が処理されます。これにより、コンパイル時間および利用可能な処理時間に基づいて、トラフィックが許可されたり却下されたりします。

コンパイルされた ACL は、XCM に送信される必要があります。利用可能な領域が非常に少ないためにメモリ不足に陥った場合は、コンソール メッセージが表示され、メモリ デフラグ ツールが起動します。

回避策は次のとおりです。

  • ミニ ACL としてコンパイルされるようにし、コンパイル時のメモリ消費と処理能力の両方を削減できるようにするために、簡潔な ACL を使用して、少数の Application Control Engine(ACE)を使用する。

  • ルータで、RADIUS アトリビュート filterID を使用して参照される事前定義された ACL を使用する。

既知の問題

フラッシュまたはネットブートから大きな Cisco IOS ソフトウェアをロードする際に発生する既知の 70x0 問題

7000 Route Processor(RP; ルート プロセッサ)がフラッシュからイメージをブートするときは、メモリにまず ROM イメージがロードされ、次にフラッシュ イメージがロードされます。古い RP にはメモリが 16 MB しか搭載されていませんが、バージョン 11.0 以降の Cisco IOS(R) ソフトウェア リリースの Enterprise バージョンでは、圧縮解除したときのサイズは 8 MB を超えます。このため 7000 RP では、ブートアップ プロセスで ROM、フラッシュの順にイメージをロードする際に、メモリが枯渇するか、またはメモリ断片化が発生し、メモリ関連のエラー メッセージが出力されることがあります。

この問題を解決するには、コンフィギュレーション レジスタを使用して Fast Boot を有効にします。これにより、RP は ROM から Cisco IOS ソフトウェア イメージの最少サブセットのみをロードし、次にフラッシュから Cisco IOS ソフトウェア全体をロードします。Fast Boot を有効にするには、コンフィギュレーション レジスタを 0x2112 に設定します。これにより、ブート プロセスの速度も向上します。

IP Input および CiscoWorks UT ディスカバリ

CiscoWorks の UT ディスカバリ機能を使用すると、ルータの一部で空きメモリの量が非常に少なくなる場合があります。show proc memory コマンドを使用すると、「IP Input」プロセスによって多くのメモリが専有されていることが示されます。これは「IP Input」プロセスの「正常または異常プロセスによる大量のメモリ使用」の問題に特有の現象です。またメモリ不足が原因でメモリが断片化すると、「メモリ断片化」の問題が発生することもあります。

UT ディスカバリ機能を使用すると、検出されたすべてのサブネット内のすべての IP に対して、ネットワーク管理ステーションから一斉に ping が送信されます。新しい宛先すべてについて新しいキャッシュ エントリが作成されるため、ルータ上の IP ファーストスイッチング キャッシュのサイズが増大し、メモリ問題が発生します。キャッシュ内のエントリに使用されるマスクはサブネットの構成によって決まるため、主要ネットワークに 32 ビット マスクを使用するアドレス(ループバック アドレスなど)が存在すると、そのネットワークのすべてのエントリで 32 ビット マスクが使用されることになります。その結果、非常に多くのキャッシュ エントリが作成され、大量のメモリが使用されます。

最善の解決策は、UT ディスカバリを無効にすることです。そのためには、次の手順を実行します。

  1. C:\Program Files\CSCOpx\etc\cwsi\ANIServer.properties に移動します。

  2. UTPingSweep=0」を追加します。

  3. ANI を再始動します。

これを行うと、User Tracking テーブル内の一部のエンド サーバのエントリが失われたり、User Tracking テーブルの情報が最新のものでなくなったりする(これは、User Registration ツールと呼ばれる、UT に依存した別の Cisco アプリケーションで問題になる可能性があります)場合がありますが、SNMP トラフィックのみを使用するキャンパス ディスカバリには影響しません。この状況は、CEF スイッチングによっても改善される場合があります(CEF では、ブートアップ時にルーティング テーブルから IP キャッシュが作成されます)。CEF とその他の使用可能なスイッチング パスについての詳細は、『ネットワークに最適なルータ スイッチング パスの選択方法』を参照してください。

同様のメモリ不足状況につながるアプリケーションは、他にも多数存在します。ほとんどの場合、問題の根本的原因は、ルータではなくアプリケーション自体にあります。通常、このようなパケット ストームは、アプリケーションの設定をチェックすることで防止できます。

インターフェイス用の共有メモリの不足

一部のルータ(2600、3600、および 4000 シリーズなど)は、特定の種類のインターフェイス プロセッサをサポートするために最小限の I/O メモリが必要です。

リロードしてもルータが共有メモリ不足になる場合は、インターフェイスを物理的に取りはずすことで問題が解決します。

3600 シリーズのルータでは、グローバル設定コマンドの memory-size iomem i/o-memory-percentage を使用して、I/O メモリおよびプロセッサ メモリに使用する DRAM の割合を再割り当てできます。i/o-memory-percentage で使用できる値は、10152025(デフォルト)、3040、および 50 です。I/O メモリには、最小で 4 MB のメモリが必要です。

この問題のトラブルシューティングについては、次を参照してください。

バッファ リークの不具合

ご使用の Cisco デバイスの、show buffers コマンドまたは show technical-support コマンド(イネーブル モード)の出力データがあれば、アウトプットインタープリタ を使用して今後予想される障害や修正を表示できます。アウトプットインタープリタ を使用するためには、登録ユーザであり、ログインしていて、さらに JavaScript を有効にしている必要があります。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

プロセスがバッファの使用を終了したときは、そのバッファを解放する必要があります。バッファ リークは、バッファを処理するコード、またはパケット処理の後にバッファを解放するコードが欠落している場合に発生します。その結果、バッファにスタックされるパケットが増えるにつれて、バッファ プールのサイズが拡張していきます。

バッファ リークを判別するには、show buffers コマンドを使用します。バッファ リークが発生していれば、Public Buffer プールのいくつかが異常に大きくなり、空きバッファが少なくなっています。リロードしても、空きバッファ数が合計バッファ数に近づかないこともあります。

アウトプットインタープリタを使用すると、show buffers コマンドの出力の分析結果が得られます。

次の例では、Middle バッファに問題があります。show buffers コマンドの出力から、約 8094 のバッファが使用され、解放されていないことがわかります(合計 8122 - 解放済み 28)。

Public buffer pools: Small buffers, 104 bytes (total 50, permanent 50): 
     50 in free list (20 min, 150 max allowed)
     403134 hits, 0 misses, 0 trims, 0 created
     0 failures (0 no memory)
Middle buffers, 600 bytes (total 8122, permanent 200):
     28 in free list (10 min, 300 max allowed)
     154459 hits, 41422 misses, 574 trims, 8496 created
Big buffers, 1524 bytes (total 50, permanent 50):
     50 in free list (5 min, 150 max allowed)
     58471 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, 100 max allowed)
     0 hits, 0 misses, 0 trims, 0 created
     0 failures (0 no memory)
Large buffers, 5024 bytes (total 0, permanent 0)
     0 in free list (0 min, 10 max allowed) 
     0 hits, 0 misses, 0 trims, 0 created  
     0 failures (0 no memory)
Huge buffers, 18024 bytes (total 0, permanent 0): 
     0 in free list (0 min, 4 max allowed)
     0 hits, 0 misses, 0 trims, 0 created  
     0 failures (0 no memory) 

これは、Cisco IOS ソフトウェアの不具合です。既知のバッファ リークの不具合を修正するために、リリーストレインの最新のバージョンにアップグレードしてください(たとえば、Cisco IOS ソフトウェア リリース 11.2(14) の場合は、最新の 11.2(x) イメージにアップグレードします)。それでも問題が解決しない場合、またはルータをアップグレードできない場合は、ルータがメモリ不足になったときに、問題のプールに対して次のコマンドを発行します。これらのコマンドを実行することで、バッファの内容についてさらに詳しい情報が得られます。

  • show buffer old:割り当てられてから 1 分以上経過したバッファを示します

  • show buffer pool (small - middle - big - verybig - large - huge):指定されたプールに関するバッファのサマリーを示します。

  • show buffer pool (small - middle - big - verybig - large - huge) dump:指定されたプールで使用されているすべてのバッファの 16 進数/ASCII ダンプを示します。

詳細は、『バッファリークのトラブルシューティング』を参照してください。

ルータのファースト メモリの不足

これは 7500 シリーズに固有の問題です。ルータで「fast」メモリが不足すると、代わりにメインのダイナミック RAM(DRAM)が使用されます。特に対処の必要はありません。

IPFAST-4-RADIXDELETE: Error trying to delete prefix entry [IP_address]/[dec] (expected [hex], got [hex])

IPFAST-4-RADIXDELETE: Error trying to delete prefix entry [IP_address]/[dec] (expected [hex], got [hex]) エラー メッセージは、メモリ内のルータ ファースト スイッチング キャッシュ テーブルが破損していることを示しています。通常処理でルータによってキャッシュ テーブルのクリアが試みられた際や、clear ip cache コマンドが入力された際に、メモリの破損のためエントリの削除に失敗します。ルータでこのようなエントリの削除に失敗した場合には、IPFAST-4-RADIXDELETE メッセージが表示されます。

キャッシュ テーブルのメモリ破損の問題を解決するには、ルータのハード リブートが必要です。リブートによって、システム メモリ構造が再構成されて、破損のないファースト キャッシュが再構築されます。

%SYS-2-CHUNKEXPANDFAIL: Could not expand chunk pool for TACL Bitmap. No memory available

%SYS-2-CHUNKEXPANDFAIL: Could not expand chunk pool for TACL Bitmap. No memory available エラー メッセージは、プロセッサ メモリの不足により指定されたチャンク プールを増加できないことが原因で表示されます。異常な動作をするプロセスが原因である場合があります。

回避策として、次のコマンドの出力を定期的に(問題発生の頻度に応じて)キャプチャして、ルータのメモリ使用量を監視します。

  • show processes memory sorted

  • show memory statistics

  • show memory allocating-process totals

トラブルシューティングの要約

Pool「Processor」メモリ割り当ての失敗

次の手順に従ってください。

  1. 使用中の IOS ソフトウェア リリース バージョンまたは機能セットのメモリ要件をチェックします。

  2. 可能な場合は、ご使用の Cisco IOS ソフトウェア リリース トレインの最新バージョンにアップグレードします。

  3. 正常または異常プロセスによる大量のメモリ使用についてチェックします。必要であればメモリを追加します。

  4. これがリークまたは断片化(ハイエンド ルータではバッファ リーク)によるものかどうかをチェックします。

  5. 関連する情報を収集し、TAC に連絡します。

Pool「I/O」メモリ割り当ての失敗(ハイエンド ルータでは「Processor」、7200 シリーズでは「PCI」)

次の手順に従ってください。

  1. 共有メモリの用件をチェックします(「インターフェイス用の共有メモリの不足」を参照)。

  2. 可能な場合は、ご使用の Cisco IOS ソフトウェア リリース トレインの最新バージョンにアップグレードします。

  3. 問題が発生しているバッファ プールを特定し、関連する情報を収集して、Cisco TAC に連絡します。

TAC のサービスリクエストをオープンする場合に収集すべき情報

上記のトラブルシューティング手順を実行した後も、依然としてサポートが必要で、TAC サービスリクエストをオープンする登録ユーザ専用)必要がある場合は、次の情報を必ず収集してください。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。
  • サービス リクエストをオープンする前に実行したトラブルシューティング

  • show technical-support コマンドの出力(可能な場合はイネーブル モードで)。時間の経過とともに変化するルータの使用メモリ量を見るために、複数の出力を収集します。

  • show log 出力、または(可能であれば)コンソールのキャプチャ。

  • show memory allocating-pool totals コマンドまたは show memory summary コマンドの出力。時間の経過とともに変化するルータの使用メモリ量を確認するために、複数の出力を収集します。

情報を収集する方法については、「「Unable to Create EXEC」エラーまたはコンソールが応答しない場合」の手順を参照してください。問題の原因を特定するには、複数の情報を収集する必要があります。メモリ リークには複数の種類があるため、TAC エンジニアはメモリ リークの種類を特定した後も、さらに情報が必要になります。

メモリ断片化の問題が発生している可能性がある場合は、次の情報を収集してください。

  • show memory free

  • show memory bigger

バッファ リークの問題が発生している可能性がある場合は、次の情報を収集してください。

  • show buffer old

  • show buffer pool (small - middle - big - verybig - large - huge):問題のあるプールに関するもの。たとえば、middle プールでリークが発生している可能性がある場合は、show buffer pool middle コマンドの出力を含めます。

  • show buffer pool (small - middle - big - verybig - large - huge) packet:問題のあるプールに関するもの。たとえば、middle プールでリークが発生している可能性がある場合は、show buffer pool middle packet コマンドの出力を含めます。

情報をサービスリクエストに添付するには、TAC Service Request Tool登録ユーザ専用)を使用してアップロードします。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

Service Request Tool にアクセスできない場合は、情報を電子メールの添付ファイルとし、メッセージの件名にサービスリクエスト番号を付けて attach@cisco.com 宛てに送信してください。これにより、サービスリクエストに関連する情報が添付されます。

注:メモリ問題のトラブルシューティングに必要でない限り、上記の情報を収集する前にルータを手作業でリロードしたり、電源のオフ/オンを行わないようにしてください。これを行うと、問題の原因の判別に必要な、重要な情報が失われる可能性があります。原因によっては、トラブルシューティングの一部としてルータをリロードし、リロード後の情報を収集することを TAC エンジニアが求める場合もあります。


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

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


関連情報


Document ID: 6507