ルータ : Cisco 7500 シリーズ ルータ

ソフトウェア強制クラッシュについて

2005 年 2 月 16 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 7 月 31 日) | フィードバック

目次

概要
はじめに
      表記法
      前提条件
      使用するコンポーネント
ソフトウェア強制クラッシュの識別
考えられる原因
トラブルシューティング
設定手順
      ルータの設定手順
      TFTP サーバ ホストの設定手順
TAC のサービス リクエストをオープンする前に収集する情報
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、ソフトウェア強制クラッシュの原因として最も頻度の高いものについて説明し、さらに、トラブルシューティングのために収集する情報について説明します。ソフトウェア強制クラッシュのために TAC のサービス リクエストを開く場合は、これらの情報の収集が問題の解決のために不可欠になります。

はじめに

表記法

文書表記の詳細については、「シスコ テクニカル ティップスの表記法」を参照してください。

前提条件

この文書を読む前に、「トラブルシューティング:ルータのクラッシュ」に目を通すことをお勧めします。

使用するコンポーネント

この文書は、特定のソフトウェアやハードウェアのバージョンに限定されていません。

この文書の情報は、特定のラボ環境にある装置に基づいて作成されています。この文書内で使用されているデバイスはすべて、クリアーな状態(デフォルト)から設定作業を始めています。コマンドを実行する前に、実稼動中のネットワークに与える影響について理解しておいてください。

ソフトウェア強制クラッシュの識別

ソフトウェア強制クラッシュは、復旧できない重大なエラーをルータが検出し、破損したデータの送信を防ぐために自らリロードする際に発生します。ソフトウェア強制クラッシュの大部分は Cisco IOS(R) ソフトウェアの Bug が原因ですが、一部のプラットフォーム(古い Cisco 4000 など)では、ハードウェアの問題がソフトウェア強制クラッシュとしてレポートされる場合があります。

ルータの電源をオフ/オンしたり、手動でルータをリロードしたりしなければ、show version コマンドからの出力は次のようになります。

Router uptime is 2 days, 21 hours, 30 minutes 
 System restarted by error - Software-forced crash, PC 0x316EF90 at 20:22:37 edt 
 System image file is "flash:c2500-is-l.112-15a.bin", booted via flash

使用中のシスコ デバイスの、show version コマンドの出力データがあれば、、アウトプットインタープリタを使用して潜在的な問題と修正を表示できます。、アウトプットインタープリタを使用するには、登録ユーザであり、ログインしている必要があります。


一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

考えられる原因

ソフトウェア強制クラッシュの考えられる原因としては、次のものがあります。

原因

説明

ウォッチドッグ
タイムアウト

プロセッサは無限ループに陥らないようにタイマーを使用していますが、これが原因でルータの応答が停止します。通常の動作では、このタイマーは CPU によって定期的な間隔でリセットされます。
これに失敗した場合、システムのリロードにつながります。

ソフトウェア強制クラッシュとしてレポートされるウォッチドッグ タイムアウトは、ソフトウェアに関連しています。その他のタイプのウォッチドッグ タイムアウトについては、「ウォッチドッグ タイムアウトに関するページ」を参照してください。リロードする前にシステムがループ状態に陥っているため、スタック トレースが妥当であるかどうかは保証されません。このタイプのソフトウェア強制クラッシュは、コンソール ログの次の行から識別できます。

%SYS-2-WATCHDOG: Process aborted on watchdog timeout, process = Exec 
                and  
                *** System received a Software forced crash *** 
                signal = 0x17, code = 0x24, context= 0x60ceca60 
 

メモリ不足

ルータはメモリが極端に少なくなると、自らリロードしてソフトウェア強制クラッシュとしてレポートする場合があります。この場合は、コンソール ログに次のようなメモリ割り当てエラー メッセージが表示されます。

%SYS-2-MALLOCFAIL: Memory allocation of 734 bytes failed from 0x6015EC84, 
                pool Processor, alignment 0 

ソフトウェア
イメージの破損

ブートの際に、ルータによって Cisco IOS ソフトウェア イメージが破損していることが検出されると、compressed image checksum is incorrect というメッセージが返され、リロードが行われます。
この現象がソフトウェア強制クラッシュとして報告されます。

Error : compressed image checksum is incorrect 0x54B2C70A
         Expected a checksum of 0x04B2C70A
 *** System received a Software forced crash ***
 signal= 0x17, code= 0x5, context= 0x0
 PC = 0x800080d4, Cause = 0x20, Status Reg = 0x3041f003
 

これは、Cisco IOS ソフトウェア イメージが、ルータへの転送の際に実際に破損したことによって発生します。この場合は、ルータに新しいイメージをロードすることによって解決します。 [このページで、
使用しているプラットフォームに適した ROMMON リカバリ方法を検索してください。]

また、この現象は、メモリのハードウェアの欠陥や、ソフトウェアの Bug によって発生する場合もあり
ます。

その他の障害

クラッシュの原因になったエラーは、多くの場合、プロセッサ ハードウェアによって検出され、これによって自動的に ROM モニタ の特別なエラー処理コードが呼び出されます。ROM モニタは、エラーを識別し、メッセージを出力して、障害に関する情報を保存してからシステムを再起動します。

しかし、これらのいずれも行われないクラッシュも存在し(上記の「ウォッチドッグ タイムアウト」を参照)、またソフトウェアが問題を検出して、クラッシュダンプ機能を呼び出すクラッシュも存在します。これは、本当の「ソフトウェア強制」クラッシュと言えます。

Power PC プラットフォームでは、少なくとも最近までは、「ソフトウェア強制クラッシュ」はクラッシュダンプ機能が呼び出される際に出力される再起動の理由ではありません。 これらのプラットフォーム(Cisco IOS ソフトウェア リリース 12.2(12.7) より前)では、これらは「SIGTRAP」例外と呼ばれてい
ます。すなわち、SIGTRAP と SFC は同じものになります。

トラブルシューティング

ソフトウェア強制クラッシュは、通常は Cisco IOS ソフトウェアの Bug によって発生します。メモリ割り当てエラー メッセージがログに表示される場合は、「メモリ問題のトラブルシューティング」を参照してください。

メモリ割り当ての 失敗に関するエラー メッセージが表示されず、ソフトウェア強制クラッシュの後に手作業によるリロードや電源のオフ/オンを行っていない場合は、アウトプットインタープリタ登録ユーザのみ)ツールを使用して、既知の Bug ID との照合を行うのが最もよい方法です。このツールには、以前のスタック デコーダ ツールの機能が組み込まれています。

ルータから show stack の出力を収集し、アウトプットインタープリタ登録ユーザのみ)ツールにアクセスして、プルダウン メニューから show stack を選択し、収集した出力を貼り付け、submit をクリックします。show stack コマンドからのデコード出力が既知のソフトウェア Bug と一致する場合は、ソフトウェア強制クラッシュの原因である可能性が最も高いソフトウェア Bug のBug ID が送信されます。Bug ID のハイパーリンクをクリックすると、シスコの Software Bug Toolkit登録ユーザのみ)から Bug の詳細が表示されます。これは、Bug ID が一致しているかどうかの判別に役立ちます。

一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

一致するBug ID が特定されたら、「fixed in」フィールドを参照して、その Bug の修正を含む最初の Cisco IOS ソフトウェア バージョンを確認します。

一致する Bug ID、または問題の修正を含む Cisco IOS ソフトウェア バージョンが不明な場合は、Cisco IOS ソフトウェアをリリース群の最新バージョンにアップグレードするという選択肢もあります。最新バージョンには通常、数多くの Bug の修正が含まれているため、多くの場合これで問題が解決します。これによっても問題が解決しない場合でも、ソフトウェアの最新バージョンを使用することにより、バグの報告と解決手順が簡潔かつ迅速になります。.

アウトプット インタープリタ ツールを使用した後でも、未解決の Bug が疑われる場合、あるいは Bug が存在する可能性がある場合は、TAC のサービス リクエストを開き、 Bug の解決に役立つ情報を提供し、その Bug が最終的に解決されたときには迅速に通知されるようにすることを推奨します。

設定手順

問題が新規のソフトウェア Bug であることが確認された場合は、シスコ TAC エンジニアからお客様に、ルータでコア ダンプが収集されるように設定することをお願いする場合があります。コア ダンプは、ソフトウェア Bug の修正方法を突きとめるために必要になることがあります。

コア ダンプでできるだけ有用な情報を収集するため、隠しコマンド debug sanity を使用することをお勧めします。これにより、システム内で使用されるすべてのバッファについて、それらの割り当て時および解放時に正常性がチェックされます。debug sanity コマンドは特権 EXEC モード(イネーブル モード)で発行する必要があり、多少 CPU を必要としますが、ルータの機能に著しい影響を与えることはありません。sanity コマンドを無効にするには、特権 EXEC コマンド undebug sanity を使用します。

ルータのメイン メモリが 16 MB 以下の場合は、Trivial File Transfer Protocol(TFTP; トリビアル ファイル転送プロトコル)を使用してコア ダンプを収集できます。ルータのメイン メモリが 16 MB を超える場合は、File Transfer Protocol(FTP; ファイル転送プロトコル)を使用することをお勧めします。次の設定手順に従うか、または「コア ダンプの作成」に進みます。

ルータの設定手順

ルータを設定するには、次のステップに従います。

  1. configure terminal コマンドを使用してルータを設定します。

  2. コマンド exception dump n.n.n.n を入力します。n.n.n.n はリモート Trivial File Transfer Protocol(TFTP; トリビアル ファイル転送プロトコル)サーバ ホストの IP アドレスです。

  3. 設定モードを終了します。

TFTP サーバ ホストの設定手順

TFTP サーバ ホストを設定する手順は次のとおりです。

  1. 任意のエディタを使用して、リモート ホストの /tftpboot ディレクトリの下にファイルを作成します。ファイル名は Cisco ルータのホスト名-core です。

  2. UNIX システムでは、「ホスト名-core」の権限モードを 666 に変更し、グローバルに互換性のあるものとします。TFTP 設定を確認するには、そのファイルに copy running-config tftp コマンドを使用します。

  3. /tftpboot の下に 16 MB を超える空きディスク領域があることを確認します。

    システムがクラッシュすると、exception dump コマンドによって上記のファイルへの出力が作成されます。ルータのメイン メモリが 16 MB を超える場合は、File Transfer Protocol(FTP; ファイル転送プロトコル)または Remote Copy Protocol(RCP; リモート コピー プロトコル)を使用してコア ダンプを入手する必要があります。ルータで次のように設定します。

     exception protocol ftp 
     exception dump n.n.n.n 
     ip ftp username <string> 
     ip ftp password <string> 
     ip ftp source-interface <slot/port/interface> 
     exception core-file <core-filename>
     
     

    コア ダンプを収集したら、ftp://ftp-sj.cisco.com/incoming にアップロードして(UNIX では、pftp ftp-sj.cisco.com と入力し、次に cd incoming と入力します)、サービス リクエストの担当者にこのファイル名を通知します。

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

上記のトラブルシューティング方法を実行した後も、依然としてサポートが必要で、Cisco TAC でサービス リクエストをオープンする必要がある場合は、次の情報を必ず収集してください。

  • show technical-support の出力 - show technical-support の出力には、ルータの現在の状態に関する情報や、クラッシュ前にルータに保存されていた重要な情報が多数含まれています。

  • コンソール ログ - コンソール ログは、通常は syslog サーバに保存されていますが、このログにはクラッシュの前にルータで発生したイベントに関する重要な情報が含まれます。これらの情報は、通常の場合、収集可能な最も重要な情報になります。

  • crashinfo ファイル(存在する場合) - crashinfo 機能をサポートしている Cisco IOS ソフトウェアのバージョンが、使用しているネットワークの他のニーズを満たしている場合は、トラブルシューティング用にそのバージョンを使用することを強く推奨します。

    crashinfo 機能をサポートする Cisco IOS ソフトウェア バージョンを調べるには、「Crashinfo ファイルからの情報の取得」を参照するか、Software Advisor登録ユーザのみ)ツールを使用してください。

    Cisco IOS ソフトウェアの古いバージョンを使用している場合に、この機能をサポートしている新しい IOS ソフトウェア リリースを導入すると、当該の Bug が修正されているという思いがけないメリットが得られることがあります。

情報をサービス リクエストに添付するには、TAC Service Request Tool登録ユーザのみ)を使用してアップロードします。TAC Service Request Tool にアクセスできない場合は、情報を電子メールの添付ファイルとし、メッセージの件名にサービス リクエスト番号を付けて attach@cisco.com 宛てに送信してください。

注:問題の根本原因を特定するのに必要な重要情報が失われる可能性があるため、可能であれば、上記情報を収集する前に、手動によるリロードやルータの電源のオフ/オンなどの操作は実行しないでください。


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

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


関連情報


Document ID: 26145