ソフトウェア強制クラッシュについて
内容
概要
このドキュメントでは、ソフトウェア強制クラッシュの原因として最も頻度の高いものについて説明し、さらに、トラブルシューティングのために収集する必要がある情報について説明します。ソフトウェア強制クラッシュの TAC サービス リクエストをオープンする場合は、収集するように要求される情報は、問題のトラブルシューティングに必要です。
前提条件
要件
このドキュメントの読者は次のトピックについての専門知識を有している必要があります。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
ルータによって深刻で修復不可能なエラーが検出されると、ソフトウェアによる強制クラッシュが発生し、破損したデータの送信を防止するためにリロードが実行されます。ソフトウェア強制クラッシュの大部分は、Cisco IOS®ソフトウェアのバグが原因です。ただし、一部のプラットフォーム（古い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コマンドの出力データがあれば、Cisco CLI Analyzer(登録ユーザ専用)を使用して、潜在的な問題と修正を表示できます。
考えられる原因
次の表に、ソフトウェア強制クラッシュの考えられる原因を示します。
| 原因 | 説明 |
|---|---|
| ウォッチドッグ タイムアウト | プロセッサは無限ループを避けるためにタイマーを使用していますが、これが原因でルータの応答が停止します。通常の動作では、このタイマーは 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 ソフトウェア イメージにより発生する可能性があります。この場合は、ルータに新しいイメージをロードすることによって問題を解決することができます。[プラットフォームの Rommom 復旧方法については、Cisco 7200、7300、7400、7500、RSP7000、Catalyst 5500 RSM、uBR7100、uBR7200、uBR10000、および 12000 シリーズ ルータの ROMmon 復旧手順を参照してください。]また、この現象は、メモリのハードウェアの欠陥や、ソフトウェアの不具合によって発生する場合もあります。 |
| その他の障害 | クラッシュの原因になったエラーは、多くの場合、プロセッサ ハードウェアによって検出され、これによって自動的に ROM モニタ の特別なエラー処理コードが呼び出されます。ROM モニタはエラーを識別し、メッセージを出力して、障害に関する情報を保存し、システムを再起動します。しかし、これらのいずれも行われないクラッシュも存在し（ウォッチドッグ タイムアウトを参照）、またソフトウェアが問題を検出して、クラッシュダンプ機能を呼び出すクラッシュも存在します。これは、本当の「ソフトウェア強制」クラッシュと言えます。少なくともごく最近まで、Power PC プラットフォームでは、「ソフトウェア強制クラッシュ」が crashdump 関数が呼び出されたときに出力される再起動理由になっていませんでした。これらのプラットフォーム（Cisco IOS ソフトウェア リリース 12.2(12.7) より前）では、これらは「SIGTRAP」例外と呼ばれています。その他のすべての点は、SIGTRAP と SFC が同じです。 |
トラブルシュート
ソフトウェア強制クラッシュは、通常は Cisco IOS ソフトウェアのバグによって発生します。メモリ割り当てエラー メッセージがログに表示される場合は、「メモリ問題のトラブルシューティング」を参照してください。
メモリ割り当て障害のエラーメッセージが表示されないが、ソフトウェア強制クラッシュ後に手動でリロードまたは電源のオフ/オンを行っていない場合は、Cisco CLI Analyzer (登録ユーザ専用)を使用して既知のバグIDをを検索します。このツールには、従来のスタック デコーダ ツールの機能が組み込まれています。
例：
-
ルータから show stack の出力を収集します。
-
プルダウン メニューから [show stack] を選択します。
-
収集した出力を貼り付けます。
-
[Submit] をクリックします。
show stack コマンドからのデコード出力が既知のソフトウェア バグと一致する場合は、ソフトウェア強制クラッシュの原因である可能性が最も高いソフトウェア バグのバグ ID が送信されます。
-
バグ ID のハイパーリンクをクリックすると、Cisco Bug Toolkit（登録ユーザ専用）からのバグ詳細情報が表示されます。この情報は、バグ ID が一致しているかどうかの判別に役立ちます。
エラーと一致するバグ ID が特定されたら、「fixed in」フィールドを参照して、そのバグの修正が入っている最初の Cisco IOS ソフトウェア バージョンを確認します。
バグ ID が不明な場合、または問題の修正が入っている Cisco IOS ソフトウェア バージョンが不明な場合は、Cisco IOS ソフトウェアをリリース群の最新バージョンにアップグレードします。最新バージョンには多数のバグに対する修正プログラムが含まれているため、この方法は有効です。問題が解決しなくても、ソフトウェアが最新バージョンになっていることによって、バグの報告や解決プロセスが簡単かつ迅速になります。
Cisco CLI Analyzerを使用した後、未解決のバグが疑われる、または明確に特定された場合は、TACサービスリクエストをオープンして、バグの解決に役立つ追加情報を提供し、バグが最終的に解決された際の通知を迅速化してください。
設定手順
問題が新規のソフトウェア バグであることが確認された場合は、シスコ TAC エンジニアからお客様に、ルータでコア ダンプが収集されるように設定することをお願いする場合があります。コア ダンプは、ソフトウェア バグの修正方法を突きとめるために必要になることがあります。
コア ダンプでできるだけ有用な情報を収集するため、隠しコマンド debug sanity を使用することをお勧めします。これにより、システム内で使用されるすべてのバッファについて、それらの割り当て時および解放時に正常性がチェックされます。debug sanity コマンドは特権 EXEC モード（イネーブル モード）で発行する必要があり、多少 CPU を必要としますが、ルータの機能に大きな影響を与えることはありません。サニティ チェックを無効にするには、undebug sanity 特権 EXEC コマンドを使用します。
ルータのメイン メモリが 16 MB 以下の場合は、Trivial File Transfer Protocol（TFTP; トリビアル ファイル転送プロトコル）を使用してコア ダンプを収集できます。ルータのメイン メモリが 16 MB を超える場合は、File Transfer Protocol（FTP; ファイル転送プロトコル）を使用することをお勧めします。このセクションの設定手順を使用します。または、コア ダンプの作成を参照してください。
ルータを設定するには、次の手順を実行します。
-
configure terminal コマンドを使用してルータを設定します。
-
「exception dump n.n.n.n」と入力します。ここで、n.n.n.n はリモート Trivial File Transfer Protocol（TFTP）サーバ ホストの IP アドレスです。
-
設定モードを終了します。
TFTP サーバ ホストの設定手順
次の手順を実行して、TFTP サーバ ホストを設定します。
-
任意のエディタを使用して、リモート ホストの /tftpboot ディレクトリの下にファイルを作成します。ファイル名は Cisco ルータのホスト名-core です。
-
UNIX システムでは、「ホスト名-core」の権限モードを 666 に変更し、グローバルに互換性のあるものとします。 TFTP セットアップを検査するには、そのファイルに copy running-config tftp コマンドを使用します。
-
/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
ip ftp password exception core-file コア ダンプを収集したら、ftp://ftp-sj.cisco.com/incoming にアップロードし（UNIX の場合は pftp ftp-sj.cisco.com と入力してから cd incoming と入力し）、所有者にこの事例とファイル名を通知します。
TAC のサービスリクエストをオープンする場合に収集すべき情報
| 上記のトラブルシューティング方法を実行した後も、依然としてサポートが必要で、Cisco TAC でサービスリクエストをオープンする必要がある場合は、次の情報を必ず収集してください。 |
|---|
|
注意：問題の根本原因を特定するために必要な重要な情報が失われる可能性があるため、上記の情報を収集する前に手動でリロードしたり、ルータの電源をオフ/オンしたりしないでください。
フィードバック