このドキュメントは、応答のないシステムのトラブルシューティングに役立ちます。また、この問題の原因と再発防止の方法についても説明します。
システムがコンソールやネットワークから送信されたクエリー(Telnet、Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)など)に応答しないとき、ルータは動作を停止しているように見えます。この問題は、2 つの大きなカテゴリに分類できます。
コンソールが応答しない場合
トラフィックが通過しない場合
このドキュメントに関する固有の要件はありません。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
すべての Cisco IOS® ソフトウェア バージョン
すべての Cisco ルータ
このドキュメントは、Cisco Catalyst スイッチまたは MGX プラットフォームには適用されません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
コンソールの問題は、ルータがコンソール ポートで入力に応答しなくなったときに発生します。コンソールが応答しない場合、それは、高い優先順位のプロセスが、コンソール ドライバが入力に応答するのを阻んでいることを意味します。
ケーブルの接続を確認します。
電源がオンになっていることを確認します。
ルータの LED ステータスを確認します。すべての LED が消灯している場合、最も考えられるのはルータの電源に障害があることです。
トラフィックが引き続きルータを流れている場合は、次のことを実行します。
ネットワーク インターフェイスの接続を解除して、ルータが応答するかどうかを確認します。多くの場合、ルータは、exec セッションにサービスを提供するために何か非常に重要なことを行っていると想定します。
また、次のコマンドを発行した後で問題を再現させることもできます。
Cisco 7200 および 7500 シリーズの場合:
configure terminal scheduler allocate 3000 1000 ^Z
scheduler allocate コマンドは、優先順位の低いプロセスに対して CPU 時間を保証します。ネットワーク割り込みのコンテキストごとに、高速スイッチング(3000 マイクロ秒(usec))とプロセス スイッチング(1000 usec)に最大時間を割り当てるようにします。
他のすべてのプラットフォームには、次を使用します。
configure terminal scheduler interval 500 ^Z
scheduler interval コマンドは、優先順位の低いプロセスが 500 usec ごとにスケジュールされるように許可し、これによって、CPU の使用率が 100% になっている場合であってもいくつかのコマンドを入力できます。
これらのコマンドの詳細は、Cisco IOS ソフトウェアのコマンド リファレンスの『基本的なシステム管理コマンド』を参照してください。
ルータの CPU 使用率が高いためにコンソールが応答しない場合、その高い CPU 使用率の原因を検出して修正することが重要です。たとえば、プロセス スイッチ IP トラフィックが問題を起こした場合、これが show processes cpu コマンドからの出力の「IP 入力」プロセスに反映されます。このような状況では、 show interfaces、show interfaces stat、および場合によっては show processes をからの出力を収集して、さらに問題を診断することが大切です。問題を修正するには、プロセスがスイッチされる IP トラフィックの量を減らす必要があります。詳細は、『Cisco ルータの CPU 使用率が高い場合のトラブルシューティング』を参照してください。
明らかにハングしているもう1つの原因として、メモリ割り当ての失敗が考えられます。つまり、ルータが使用可能なすべてのメモリを使用したか、メモリが細かく断片化されているために使用可能なブロックをルータが見つけられなかったことが考えられます。詳細は、『メモリ問題のトラブルシューティング』を参照してください。
ルータは、ワームやウイルスなど、セキュリティ関連の問題のために応答を停止することがあります。特に、ルータの IOS のアップグレードなどのネットワークに対する変更を直前に加えていない場合は、これが原因である可能性が大きくなります。通常は、アクセス リストに行を追加するといった設定の変更によって、この問題の影響を軽減できます。『Cisco セキュリティ アドバイザリおよび注意』ページには、一番可能性が高い原因の検出方法と、具体的な回避策に関する情報が含まれています。
詳細については、次を参照してください。
起動プロセス中にルータがフリーズしたように見える場合、それは、不適切に設定された機能があるか、設定された機能にソフトウェア上の欠陥が存在する結果と考えられます。これは、多くの場合、ルータがフリーズする直前にコンソールに警告やエラーのメッセージが表示されることでわかります。
この問題の回避策として、ルータを ROMMON モードにブートして、保存した設定をバイパスしてから再度ルータを設定します。次のステップを実行します。
ターミナルまたはターミナル エミュレーションを搭載した PC をルータのコンソール ポートに接続します。
次のターミナル設定を使用します。
9600 ボーレート
パリティなし
8 データ ビット
1 ストップ ビット
フロー制御なし
ルータをリブートして、電源投入から 60 秒以内にターミナルのキーボードの Break キーを押して ROMMON 状態にします。ブレーク シーケンスがうまく動作しない場合は、『パスワード回復中の標準的なブレーク キー シーケンスの組み合せ』を参照して他のキーの組み合わせを試してください。
コンフィギュレーション レジスタを 0x2142 に変更してからルータをリセットします。このために、rommon 1> プロンプトで confreg 0x2142 コマンドを実行します。rommon 2> プロンプトで reset と入力します。これによって、ルータは設定をロードせず、フラッシュからブートします。
セットアップのそれぞれの質問の後に no と入力するか、Ctrl+C キーを押して初期セットアップ手順をスキップします。
Router> プロンプトで enable と入力します。
これでイネーブル モードになり、Router# プロンプトが表示されるはずです。
ここで空の設定を保存することができます(すべてのコマンドは削除されます)。copy running-config startup-config コマンドを発行します。あるいは、特定のコマンドが問題を引き起こしているのではないかと疑っている場合は、設定を編集できます。設定を編集をするには、copy startup-config running-config コマンドを発行します。その後、configure terminal と入力して変更を行います。
完了したら、コンフィギュレーション レジスタを 0x2102 に戻します。それには、config-register 0x2102 と入力します。copy running-config startup-config コマンドを発行して変更を確定します。
トラフィックがルータを流れない場合、次の内容を検討します。
トラフィックがルータを通過しなくなり、コンソールが応答しない場合、おそらくシステムで問題があります。一般に、これは、ルータが継続的なループまたは機能にとどまるようになることを意味しています。この原因は、ほぼ常にソフトウェアのバグです。現在実行している Cisco IOS ソフトウェア トレインの最新のメンテナンス リリースをインストールします。
Cisco TAC のサービス リクエストを作成する前に、ROM モニタからスタック トレースを取得します。問題発生中にスタック トレースを取得することによって、コードのどの部分でルータがループしているか、またはとどまっているかを判断できるようになります。
トラフィックの問題は、コンソールが応答可能なままであっても、トラフィックがルータを通過しないときに発生します。この場合、トラフィックの一部またはインターフェイスの一部が応答しなくなります。この動作は、さまざまな異なる原因によって引き起こされます。この問題が発生したときは、コンソールからルータの情報を収集することができます。このような トラフィックが通過しない問題は、インターフェイスのエラーやソフトウェアおよびハードウェア 問題などさまざまな原因が考えられます。
ルーティングの問題 – ネットワーク トポロジまたはいくつかのルータの設定の変更は、ルーティング テーブルに影響を与えている可能性があります。
高い CPU 使用率 – show process cpu コマンドを発行します。CPU の使用率が 95% を超える場合、ルータのパフォーマンスも影響を受けている可能性があり、パケットが遅延または廃棄される可能性があります。詳細は、『ルータの CPU 使用率が高い場合のトラブルシューティング』を参照してください。
インターフェイスがダウンしている – ルータ インターフェイスの 1 つがダウンしている可能性があります。この原因となるイベントは複数存在し、誤った設定コマンドからインターフェイスまたはケーブルのハードウェア障害までさまざまです。show interfaces コマンドを発行したときにいくつかのインターフェイスでダウンしているとわかった場合、何が原因なのかを見つけ出してください。
ブロックされたインターフェイス – これは、インターフェイスの入力キューがパケットを受け付けられなくなるポイントまで満たされる原因となる、バッファ リークの特別な事例です。ルータをリロードします。これによって入力キューが開放され、キューが再度満杯状態になるまでトラフィックを復元します。これは、リークの重大度に従い、数秒から数週間までかかります。
ブロックされたインターフェイスを特定する最も簡単な方法は、show interfaces コマンドを発行して、次に似たものを探すことです。
Output queue 0/40, 0 drops; input queue 76/75, 27 drops
ガイドラインとサンプルの詳細は、『バッファ リークのトラブルシューティング』を参照してください。
K-trace は、ROM モニタからのルータからスタック トレースを取得するために使われる手順のことです。古い ROM モニタ コードのルータでは、スタック トレースは k コマンドで取得します。より新しい ROM モニタ コードを実行するルータでは、stack コマンドも使用できます。
これらの手順を実行して、応答しないルータからスタック トレースを取得します。
ブレーク シーケンスをイネーブルにします。このために、コンフィギュレーション レジスタ値を変更します。この 8 ビット値を 0 に設定して、ブレークが無視されないようにする必要があります。0x2002 の値が動作します。
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#config-register 0x2002
ルータをリロードして、新しいコンフィギュレーション レジスタ値を有効にしておく必要があります。
問題が発生したときにはブレーク シーケンスを送信します。ROM モニタのプロンプト「>」または「rommon 1 >」が表示されるはずです。
スタック トレースをキャプチャします。このために、k 50 コマンドか stack 50 コマンドからの出力を収集します。コマンドに 50 を追加するのは、長いスタック トレースを印刷するためです。
c または cont コマンドを発行して続けます。
継続ループ内の複数のポイントが確実にキャプチャされるように、最後の 3 つのステップを複数回繰り返します。
複数のスタック トレースを取得した後、ハング状態から回復するためにルータをリブートします。
次にこの手順の例を示します。
User break detected at location 0x80af570 rommon 1 > k 50 Stack trace: PC = 0x080af570 Frame 00: FP = 0x02004750 RA = 0x0813d1b4 Frame 01: FP = 0x02004810 RA = 0x0813a8b8 Frame 02: FP = 0x0200482c RA = 0x08032000 Frame 03: FP = 0x0200483c RA = 0x040005b0 Frame 04: FP = 0x02004b34 RA = 0x0401517a Frame 05: FP = 0x02004bf0 RA = 0x04014d9c Frame 06: FP = 0x02004c00 RA = 0x040023d0 Frame 07: FP = 0x02004c68 RA = 0x04002e9e Frame 08: FP = 0x02004c78 RA = 0x040154fe Frame 09: FP = 0x02004e68 RA = 0x04001fc0 Frame 10: FP = 0x02004f90 RA = 0x0400c41e Frame 11: FP = 0x02004fa4 RA = 0x04000458 Suspect bogus FP = 0x00000000, aborting rommon 2 > cont
スタック トレースの複数の例を収集するために、システム問題が発生したときに複数回この手順を繰り返します。
ルータが応答しないとき、ほとんどすべての場合、それはソフトウェアの問題です。この場合、TAC サービス リクエストをオープンする前に、スタック トレースを含めて、できるだけ多くの情報を収集します。また、show version、show run、show interfaces のコマンドからの出力を含めることも重要です。
TAC サービス リクエストをオープンする場合、ハングしたルータのトラブルシューティングのリクエストに次の情報を添付してください。 |
注:コンソールが応答する場合、ルータハングのトラブルシューティングに必要でない限り、上記の情報を収集する前にルータを手作業でリロードしたり、電源のオフ/オンを行わないようにしてください。これを行うと、問題の根本原因の判別に必要な、重要な情報が失われる可能性があります。 |
改定 | 発行日 | コメント |
---|---|---|
1.0 |
02-Aug-2006 |
初版 |