2010 年 6 月 9 日 - ライター翻訳版
その他のバージョン： PDF 機械翻訳版 (2011 年 11 月 18 日) | 英語版 (2006 年 8 月 2 日) | フィードバック
目次
概要 前提条件 要件 使用するコンポーネント 表記法 コンソールが応答しない トラブルシューティングのステップ トラフィックが通過しない 考えられる原因 ROM モニタからのスタック トレースの取得 TAC のサービス リクエストをオープンする場合に収集する情報 Cisco サポート コミュニティ - 特集対話 関連情報
このドキュメントは、応答しないシステムのトラブルシューティングを行う際に役立ちます。また、問題の原因と解決方法についても説明しています。
システムがコンソールやネットワークから送信されたクエリー（Telnet、Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）など）に応答しないとき、ルータは動作を停止しているように見えます。この問題は、2 つの大きなカテゴリに分類できます。
コンソールが応答しない場合
トラフィックが通過しない場合
このドキュメントに関する特別な要件はありません。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
このドキュメントは Cisco Catalyst スイッチや MGX プラットフォームには適用されません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼動中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法 』を参照してください。
コンソールの問題は、ルータがコンソール ポートで入力に応答しなくなったときに発生します。コンソールが応答しない場合、それは、高い優先順位のプロセスが、コンソール ドライバが入力に応答するのを阻んでいることを意味します。
トラフィックが引き続きルータを流れている場合は、次のことを実行します。
ネットワーク インターフェイスの接続を解除して、ルータが応答するかどうかを確認します。多くの場合、ルータは、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 サービス リクエストをオープンする場合、ハングしたルータのトラブルシューティングのリクエストに次の情報を添付してください。
サービス リクエストをオープンする前に実行したトラブルシューティング
show technical-support の出力（可能な場合はイネーブル モードで）
show log の出力またはコンソールのキャプチャ（可能な場合）
ROM モニタからのスタック トレース
収集したデータは、圧縮しないプレーンなテキスト形式（.txt）でサービス リクエストに添付してください。情報をサービス リクエストに添付するには、TAC Service Request Tool （登録 ユーザ専用
注： コンソールが応答する場合、ルータがハングする問題のトラブルシューティングに必要でない限り、上記の情報を収集する前にルータを手作業でリロードしたり、電源のオフ/オンを行わないようにしてください。これを行うと、問題の原因の判別に必要な、重要な情報が失われる可能性があります。
Cisco サポート コミュニティ では、フォーラムに参加して情報交換することができます。現在、このドキュメントに関連するトピックについて次のような対話が行われています。
|