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

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

2016 年 1 月 16 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 2 月 16 日) | 英語版 (2015 年 12 月 31 日) | フィードバック


対話式: この文書では、個別のユーザに合わせたシスコ デバイスの分析を行います。


目次


概要

このドキュメントでは、ソフトウェア強制クラッシュの原因として最も頻度の高いものについて説明し、さらに、トラブルシューティングのために収集する必要がある情報について説明します。 ソフトウェア強制クラッシュの 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

Ciscoデバイスからの 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ソフトウェアイメージが破損していること検出する、リロードするように試みることができます。 この場合、イベントはソフトウェア強制クラッシュとして報告されます。
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 回復手順 方式のために、Cisco 7200、7300、7400、7500、RSP7000、Catalyst 5500 RSM、uBR7100、uBR7200、uBR10000 および 12000 シリーズ ルータにおける ROMmon 回復手順を参照して下さい。]また不良なメモリ ハードウェアまたはソフトウェアバグによって引き起こされる場合があります。
その他の障害 クラッシュの原因になったエラーは、多くの場合、プロセッサ ハードウェアによって検出され、これによって自動的に ROM モニタ の特別なエラー処理コードが呼び出されます。 ROM モニタはエラーを識別し、メッセージを出力して、障害に関する情報を保存し、システムを再起動します。 これのどれも(ウォッチドッグ タイムアウトを参照すれば)起こる場合がない、ソフトウェアが問題を検出する、クラッシュダンプ 機能を呼出すクラッシュがありますクラッシュがあります。 これは、本当の「ソフトウェア強制」クラッシュと言えます。 -少なくとも印刷される Power PC プラットフォームで、クラッシュダンプ 機能が呼出される非常に最近までとき「ソフトウェア強制クラッシュ」は再始動原因ではないです。 これらのプラットフォーム(Cisco IOS ソフトウェア リリース 12.2(12.7) より前)では、これらは「SIGTRAP」例外と呼ばれています。 他のすべての方法では、SIGTRAPs および SFC は同じです。

トラブルシューティング

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

メモリアロケーション障害 エラーメッセージが表示されないし、ソフトウェア強制クラッシュの後で手動で ルータをリロードしなかったし、またはパワーサイクルを行わなかったら場合、である既知 マッチするバグID を捜すアウトプットインタープリタ登録ユーザのみ)使用できる最もよいツール。 このツールは古いスタックデコーダツールの機能性を組み込みます。

例:

  1. ルータから show stack の出力を集めて下さい。

  2. アウトプットインタープリタ登録ユーザのみ)ツールに行って下さい。

  3. プルダウン メニューから show stack を選択して下さい。

  4. 集めた出力に貼り付けて下さい。

  5. 『SUBMIT』 をクリック して下さい。

    show stack コマンドからのデコードされた出力が既知のソフトウェアバグと一致する場合、ソフトウェア強制クラッシュを引き起こしたかもしれない可能性が高いソフトウェアバグのバグID を受け取ります。

  6. 正しいバグID 一致を判別するのを助けることができる Ciscoバグ ツールキット登録ユーザのみ)からの追加バグ詳細を表示するためにバグID ハイパーリンクをクリックして下さい。

エラーと一致するバグID を識別したら、不具合のための修正が含まれている最初の Cisco IOS ソフトウェア バージョンを判別するために" fixed in " フィールドを参照して下さい。

バグID、か問題のための修正が含まれている Cisco IOS ソフトウェア バージョンについて不確か、リリース トレインの最新バージョンに Cisco IOSソフトウェアをアップグレードして下さい。 これは、最新バージョンが多数のバグのための修正が含まれているので助けます。 これが問題を解決しないソフトウェアの最新バージョンがあるときバグ レポートおよび解決プロセスはより簡単、より速いです。

Output Interpreter ツールを使用した後、未解決に残る不具合を疑うか、または肯定的に識別したら、不具合が最終的に解決されるときその他の情報を提供するように不具合の解決を助けるように TAC サービス リクエストを開くおよび推奨しますことをより速い通知のために。

設定手順

問題点が新しいソフトウェアバグとして明らかにされる場合、Cisco TAC エンジニアはコアダンプを集めるためにルータを設定するように要求できます。 時々コアダンプがすることができるソフトウェアバグをフィックスするためにものが識別するために必要となります。

非表示 debug sanity コマンドを使用することをコアダンプの有益な情報を収集するために、推奨します。 これにより、システム内で使用されるすべてのバッファについて、それらの割り当て時および解放時に正常性がチェックされます。 debug sanity コマンドは特権EXECモード(イネーブル モード)で発行されなければなり、が CPU を含みましたり、それほどルータの機能性に影響を与えません。 サニティ チェックをディセーブルにしたいと思う場合 undebug 正気 privileged exec コマンドを使用して下さい。

ルータのメイン メモリが 16 MB 以下の場合は、Trivial File Transfer Protocol(TFTP; トリビアル ファイル転送プロトコル)を使用してコア ダンプを収集できます。 ルータのメイン メモリが 16 MB を超える場合は、File Transfer Protocol(FTP; ファイル転送プロトコル)を使用することをお勧めします。 このセクションでコンフィギュレーション手順を使用して下さい。 また、コアダンプを作成することを参照して下さい。

ルータの設定手順

ルータを設定するためにこれらのステップを完了して下さい:

  1. configure terminal コマンドでルータを設定して下さい。

  2. n.n.n.n がリモート Trivial File Transfer Protocol (TFTP) サーバホストの IP アドレスである例外 ダンプ n.n.n.n を入力して下さい。

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

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

TFTPサーバホストを設定するためにこれらのステップを完了して下さい:

  1. 選択のエディタの助けによってリモートホストの /tftpboot ディレクトリの下でファイルを作成して下さい。 ファイル名は Cisco ルータのホスト名-core です。

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

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

    システムがクラッシュすると、exception dump コマンドによって上記のファイルへの出力が作成されます。 ルータにメインメモリの 16 MB より多くがある場合、コアダンプを得るのに File Transfer Protocol (FTP)かリモート コピー プロトコル (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 ファイル(もしあれば) – Cisco は正常に解決するために crashinfo 機能をサポートする Cisco IOS ソフトウェア リリースを使用することを推奨します。 これのために、バージョンはネットワークの他の必要を満たす必要があります。 Crashinfo ファイルから情報を検索することを参照するか、または crashinfo 機能をサポートする Cisco IOS ソフトウェア バージョンを見つけるのに Software Advisor登録ユーザのみ)ツールを使用して下さい。 潜在的なボーナスは Cisco IOSソフトウェアのより古いバージョンがあれば、この機能をサポートするより新しい IOSソフトウェアリリースは既にフィックスされた不具合がある可能性があることです。
情報をサービス リクエストに添付するには、TAC Service Request Tool登録ユーザ専用)を使用してアップロードします。 TAC Service Request Tool にアクセスできない場合は、情報を電子メールの添付ファイルとし、メッセージの件名にサービス リクエスト番号を付けて attach@cisco.com 宛てに送信してください。

注意 注意: これが問題の根本的な原因を判別するために必要である重要な情報を失います場合があるので上の情報を、もし可能なら収集する前に手動で ルータをリロードしましたり、またはパワーサイクルを行わないで下さい。

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

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


関連情報


Document ID: 26145