概要
このドキュメントでは、シスコ ルータでウォッチドッグ タイムアウトが発生する原因と、そうしたタイムアウトをトラブルシュートする方法について説明します。
前提条件
要件
このドキュメントの読者は次のトピックについての専門知識を有している必要があります。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
注：このドキュメントは、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シリーズルータには、次の1つのField Noticeがあります。Cisco 3600 T1/E1 PRIモジュールウォッチドッグタイムアウト。次のトラブルシューティングに進む前に、必ず Field Notice をチェックしてください。
最近新しいモジュールを取り付けたばかりの場合は、そのモジュールがウォッチドッグ タイムアウトの原因であるかどうかを確認するために、まずそのモジュールを取り外す必要があります。それでもウォッチドッグ タイムアウトが解決しない場合は、着脱可能なコンポーネントをすべて装着し直してみます。
この時点でウォッチドッグ タイムアウトがまだ続いていて、使用しているハードウェアについての Field Notice が存在せず、なおかつ最近新しいハードウェアを取り付けたという事実がない場合は、次のステップに進んでメイン プロセッサ ボードを交換します。ハイエンド プラットフォームでは、プロセッサ ボードは独立したカードです（NPE-400 や RSP8 など）。 ローエンド プラットフォーム（Cisco 1700、2500、4000、2600、3600 など）では、マザーボードだけを個別に出荷できません。この場合はシャーシ自体を交換する必要があります。
プロセス ウォッチドッグ タイムアウト
ここであげるタイムアウトの原因はプロセス レベルでの無限ループです。このタイムアウトの症状の一部は次のとおりです。
この問題の原因として最も可能性が高いのは、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シリーズインターネットルータでラインカードのクラッシュをトラブルシューティングする必要がない限り、上記の情報を収集する前に手動でリロードまたは電源のオフ/オン |
関連情報
フィードバック