内容

はじめに

前提条件

要件

使用するコンポーネント

表記法

ウォッチドッグ タイムアウトの識別

トラブルシュート

ソフトウェア ウォッチドッグ タイムアウト

プロセス ウォッチドッグ タイムアウト

ウォッチドッグ タイムアウトに関連するエラー メッセージ

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

関連情報

はじめに

このドキュメントでは、Cisco ルータでのウォッチドッグ タイムアウトの原因と、そのトラブルシューティング方法について説明しています。

前提条件

要件

このドキュメントの読者は次のトピックについて専門知識を有している必要があります。

- トラブルシューティング：ルータのクラッシュ

使用するコンポーネント

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

- すべての Cisco ルータ

- すべての Cisco IOS® ソフトウェア バージョン

注：このドキュメントは、Cisco CatalystスイッチまたはMGXプラットフォームには適用されず、Ciscoルータにのみ適用されます。

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

表記法

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

ウォッチドッグ タイムアウトの識別

Cisco のプロセッサには、ある種のシステム ハングから防護するためのタイマーが備わっています。CPU は定期的にウォッチドッグ タイマーをリセットします。ウォッチドッグ タイマーは基本的に各プロセスの時間を制御します。タイマーがリセットされていない場合はトラップが発生します。あるプロセスが必要以上に長い時間動作している場合は、このプロセスから抜け出すためにウォッチドッグ タイマーが使用されます。

これが起こるのは、何らかの問題がある場合だけです。状況に基づき、ルータが自動的にリセットするか、または障害から復旧した後、コンソール ログに次のようなエラー メッセージが生成される場合があります。

*** Watch Dog Timeout ***

PC = 0x6022536C, SP = 0x00000000

または

%SYS-2-WATCHDOG: Process aborted on watchdog timeout, process = Exec

*** System received a Software forced crash ***

signal = 0x17, code = 0x24, context= 0x60ceca60

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

Router#show version

...

Router uptime is 1 hour, 47 minutes

System restarted by watchdog timer expired at 09:26:24 UTC Mon Mar 27 2000

System image file is "flash:c3640-is-mz.113-7-T.bin", booted via flash

...

ご使用のシスコデバイスの、show versionコマンドの出力データがあれば、Cisco CLI Analyzerを使用して潜在的な問題および修正を表示できます。Cisco CLI Analyzer を使用するには、登録ユーザとしてログインする必要があり、また、JavaScript を有効にする必要があります。

トラブルシュート

ウォッチドッグ タイムアウトの根本原因は、ハードウェアに関連している場合とソフトウェアに関連している場合があります。問題の原因を特定する上で役立つ一般的な症状は次のとおりです。

- ルータが数か月間正常に動作していて、突然 20 分ごとにリロードを始めた場合、あるいはルータが継続的にリブートを繰り返し、ルータにアクセスできない場合、問題はおそらくハードウェアに関連するものです。これは、最近ルータに新しいモジュールを取り付けたばかりで、その後ウォッチドッグ タイムアウトによるクラッシュが発生し始めた場合にも当てはまります。

- 設定の変更後、または Cisco IOS ソフトウェア バージョンの変更後にルータがクラッシュし始めた場合は、おそらくソフトウェア関連の問題です。

この種の問題のトラブルシューティングを行う際は、最初にどのタイプのウォッチドッグ タイムアウトが発生したのかを特定します。ウォッチドッグ タイムアウトには次の 2 つのタイプがあります。

- ソフトウェア ウォッチドッグ タイムアウト。これはその名前とは異なり、多くの場合、ハードウェアに関連するものです。

- プロセス ウォッチドッグ タイムアウト。これは多くの場合、ソフトウェアに関連するものです。

ソフトウェア ウォッチドッグ タイムアウト

ここであげたタイムアウトの原因は割り込みレベルでの無限ループか、またはハードウェアの問題で、このタイプのタイムアウトの症状の一部は次のとおりです。

- コンソール ログに次の行が含まれます。

*** Watch Dog Timeout ***

PC = 0x6022536C、SP = 0x00000000

- show version の出力中に、リロードの理由が「watchdog timer expired」と報告されます。

Router#show version

...

Router uptime is 1 hour, 47 minutes

System restarted by watchdog timer expired at 06:30:24 UTC Mon Jan 28 2000

System image file is "flash:c3640-is-mz.113-7-T.bin", booted via flash

- Crashinfo ファイルは生成されません。詳細については、『Crashinfo ファイルからの情報の取得』を参照してください。

ほとんどの場合、これらのメッセージはメイン プロセッサ ボードまたはいずれかのモジュールに関するハードウェアの問題があることを示します。

ソフトウェア ウォッチドッグ タイムアウトであることが確認されたら、次に『最新日本語版 Field Notice』をチェックし、使用しているプラットフォームおよびそのシステムに装備されているすべてのコンポーネントについて、既知の重大なハードウェア問題が報告されていないかを調べます。たとえば、Cisco 3600 シリーズ ルータには Field Notice が 1 つあります（『Cisco 3600 T1/E1 PRI モジュールのウォッチドッグ タイムアウト』）。次のトラブルシューティングに進む前に、必ず Field Notice をチェックしてください。

最近新しいモジュールを取り付けたばかりの場合は、そのモジュールがウォッチドッグ タイムアウトの原因であるかどうかを確認するために、まずそのモジュールを取り外す必要があります。それでもウォッチドッグ タイムアウトが解決しない場合は、着脱可能なコンポーネントをすべて装着し直してみます。

この時点でウォッチドッグ タイムアウトがまだ続いていて、使用しているハードウェアについての Field Notice が存在せず、なおかつ最近新しいハードウェアを取り付けたという事実がない場合は、次のステップに進んでメイン プロセッサ ボードを交換します。ハイエンド プラットフォームでは、プロセッサ ボードは独立したカードです（NPE-400 や RSP8 など）。 ローエンド プラットフォーム（Cisco 1700、2500、4000、2600、3600 など）では、マザーボードだけを個別に出荷できません。この場合はシャーシ自体を交換する必要があります。

プロセス ウォッチドッグ タイムアウト

ここであげるタイムアウトの原因はプロセス レベルでの無限ループです。このタイムアウトの症状の一部は次のとおりです。

- コンソール ログに次の行が含まれます。

%SYS-2-WATCHDOG: Process aborted on watchdog timeout,

process = Exec

*** System received a Software forced crash ***

signal = 0x17, code = 0x24, context= 0x60ceca60

- show version の出力中に、「software-forced crash」としてクラッシュが報告されます。

Router#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

- crashinfo ファイルが生成されます（crashinfo ファイルをサポートしているプラットフォームの場合）。

この問題の原因として最も可能性が高いのは、Cisco IOS ソフトウェアの不具合です。

ご使用のシスコデバイスの、show stacks（イネーブルモードでの）コマンドの出力データがあれば、Cisco CLI Analyzerを使用して潜在的な問題および修正を表示できます。Cisco CLI Analyzer を使用するには、登録ユーザとしてログインする必要があり、また、JavaScript を有効にする必要があります。

ただし、リロードする前にシステムがループ状態に陥っています。そのため、スタック トレースは必ずしも妥当であるというわけではありません。Cisco IOS ソフトウェア リリース トレインの最新のソフトウェア バージョンにアップグレードすると、プロセス ウォッチドッグに関する既知の問題を一掃できます。アップグレード後もクラッシュが発生する場合は、できる限り多くの情報を収集した上で（『トラブルシューティング：ルータのクラッシュ』を参照）、テクニカル サポート担当者に連絡してください。

ウォッチドッグ タイムアウトに関連するエラー メッセージ

前述したもの以外にも、ウォッチドッグ タイマーに関連するコンソール エラー メッセージがあります。これらのメッセージをウォッチドッグ タイマー クラッシュと混同しないでください。エラーメッセージデコーダ（登録ユーザ専用）を使用して、これらのエラー メッセージの意味を必ずチェックしてください。 このツールでは、各種のエラー メッセージと、それを解決するための推奨処置に関する詳しい説明が示されます。

次のメッセージについて検討します。

%SYS-2-WATCHDOG: Process aborted on watchdog timeout,

process = [chars]

このメッセージは、指定されたプロセスが長時間動作し続け、プロセッサが解放されなかったったことを示しています。指定されたプロセスはシステムによってすでに停止されています。システムのコンフィギュレーションによっては、これがシステム クラッシュにつながる可能性があります。このメッセージが単発であれば、特に対処する必要はありません。しかし、再度発生する場合は、これをプロセス ウォッチドッグ タイムアウトと見なし、必要な措置を講ずる必要があります。

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

上記のトラブルシューティング手順を実行しても、なおサポートが必要で、Cisco TAC でサービス リクエストをオープンする（登録ユーザ専用）場合には、必ず次の情報を提供してください。

- サービス リクエストをオープンする前に実施したトラブルシューティング

- show technical-support の出力（可能な場合はイネーブル モードで）

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

- ラインカード クラッシュが発生したスロットの execute-on slot [slot #] show tech

- crashinfo ファイル（ファイルが利用でき、show technical-support の出力に含まれていない場合）

収集したデータは、圧縮しないプレーン テキスト形式（.txt）でサービス リクエストに添付してください。 情報をサービス リクエストに添付するには、TAC Service Request Tool（登録ユーザ専用）を使用してアップロードします。 Service Request Tool にアクセスできない場合は、attach@cisco.com への電子メールに情報を添付して送信できます。この場合は、メッセージの件名（Subject）行にサービス リクエスト番号を記入してください。

注：Cisco 12000シリーズインターネットルータでのラインカードクラッシュのトラブルシューティングに必要でない限り、上記の情報を収集する前にルータを手作業でリロードしたり、電源のオフ/オンを行わないようにしてください。これを行うと、問題の根本原因の判別に必要な重要な情報が失われる可能性があります。

関連情報

- トラブルシューティング：ルータのクラッシュ

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

- ルータの問題のトラブルシューティング：Cisco IOS ソフトウェア リリース 12.1 EX

- テクニカルサポート - Cisco Systems