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

ルータ ハングに関するトラブルシューティング

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


目次


概要

このドキュメントは、応答しないシステムのトラブルシューティングを行う際に役立ちます。 また、問題の原因と解決方法についても説明しています。

システムがコンソールやネットワークから送信されたクエリー(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 interfacesshow interfaces stat、および場合によっては show processes をからの出力を収集して、さらに問題を診断することが大切です。 問題を修正するには、プロセスがスイッチされる IP トラフィックの量を減らす必要があります。 詳細は、『Cisco ルータの CPU 使用率が高い場合のトラブルシューティング』を参照してください。

  • 明白なハングの原因となる可能性のあるもう 1 つのことは、メモリ割り当ての失敗です。 つまり、ルータが利用可能なすべてのメモリを使い尽くしたか、メモリがフラグメントを起こして、ルータが利用可能なブロックを使用できるとわからないほどの小さな部分になったかのいずれかです。 詳細は、『メモリ問題のトラブルシューティング』を参照してください。

  • ルータは、ワームやウイルスなど、セキュリティ関連の問題のために応答を停止することがあります。 特に、ルータの IOS のアップグレードなどのネットワークに対する変更を直前に加えていない場合は、これが原因である可能性が大きくなります。 通常は、アクセス リストに行を追加するといった設定の変更によって、この問題の影響を軽減できます。 『Cisco セキュリティ アドバイザリおよび注意』ページには、一番可能性が高い原因の検出方法と、具体的な回避策に関する情報が含まれています。

    詳細については、次を参照してください。

  • 起動プロセス中にルータがフリーズしたように見える場合、それは、不適切に設定された機能があるか、設定された機能にソフトウェア上の欠陥が存在する結果と考えられます。 これは、多くの場合、ルータがフリーズする直前にコンソールに警告やエラーのメッセージが表示されることでわかります。

    この問題の回避策として、ルータを ROMMON モードにブートして、保存した設定をバイパスしてから再度ルータを設定します。 次の手順を実行します。

    1. ターミナルまたはターミナル エミュレーションを搭載した PC をルータのコンソール ポートに接続します。

      次のターミナル設定を使用します。

      • 9600 ボーレート

      • パリティなし

      • 8 データ ビット

      • 1 ストップ ビット

      • フロー制御なし

    2. ルータをリブートして、電源投入から 60 秒以内にターミナルのキーボードの Break キーを押して ROMMON 状態にします。 ブレーク シーケンスがうまく動作しない場合は、『パスワード回復中の標準的なブレーク キー シーケンスの組み合せ』を参照して他のキーの組み合わせを試してください。

    3. コンフィギュレーション レジスタを 0x2142 に変更してからルータをリセットします。 このために、rommon 1> プロンプトで confreg 0x2142 コマンドを実行します。 rommon 2> プロンプトで reset と入力します。 これによって、ルータは設定をロードせず、フラッシュからブートします。

    4. 各セットアップ質問の後に no を入力するか Ctrl+C キーを押して、初期セットアップ手順をスキップします。

    5. Router> プロンプトで enable と入力します。

      これでイネーブル モードになり、Router# プロンプトが表示されるはずです。

    6. ここで空の設定を保存することができます(すべてのコマンドは削除されます)。 copy running-config startup-config コマンドを発行します。 あるいは、特定のコマンドが問題を引き起こしているのではないかと疑っている場合は、設定を編集できます。 設定を編集をするには、copy startup-config running-config コマンドを発行します。 その後、configure terminal と入力して変更を行います。

    7. 完了したら、コンフィギュレーション レジスタを 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 

    ガイドラインとサンプルの詳細は、『バッファ リークのトラブルシューティング』を参照してください。

ROM モニタからのスタック トレースの取得

K-trace は、ROM モニタからのルータからスタック トレースを取得するために使われる手順のことです。 古い ROM モニタ コードのルータでは、スタック トレースは k コマンドで取得します。 より新しい ROM モニタ コードを実行するルータでは、stack コマンドも使用できます。

これらの手順を実行して、応答しないルータからスタック トレースを取得します。

  1. ブレーク シーケンスをイネーブルにします。 このために、コンフィギュレーション レジスタ値を変更します。 この 8 ビット値を 0 に設定して、ブレークが無視されないようにする必要があります。 0x2002 の値が動作します。

    Router#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)#config-register 0x2002
    
  2. ルータをリロードして、新しいコンフィギュレーション レジスタ値を有効にしておく必要があります。

  3. 問題が発生したときにはブレーク シーケンスを送信します。 ROM モニタのプロンプト「>」または「rommon 1 >」が表示されるはずです。

  4. スタック トレースをキャプチャします。 このために、k 50 コマンドか stack 50 コマンドからの出力を収集します。 コマンドに 50 を追加するのは、長いスタック トレースを印刷するためです。

  5. c または cont コマンドを発行して続けます。

  6. 継続ループ内の複数のポイントが確実にキャプチャされるように、最後の 3 つのステップを複数回繰り返します。

  7. 複数のスタック トレースを取得した後、ハング状態から回復するためにルータをリブートします。

次にこの手順の例を示します。

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 versionshow runshow interfaces のコマンドからの出力を含めることも重要です。

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

TAC サービス リクエストをオープンする場合、ハングしたルータのトラブルシューティングのリクエストに次の情報を添付してください。
収集したデータは、圧縮しないプレーンなテキスト形式(.txt)でサービス リクエストに添付してください。 サービスリクエストに情報を添付するには、TAC Service Request Tool登録ユーザ専用)を使用してアップロードします。 TAC Service Request Tool にアクセスできない場合は、メッセージの件名の行にお客様のサービス リクエスト番号を記入し、attach@cisco.com にメッセージを送信することにより、お客様のサービス リクエストに関連情報を添付できます。

コンソールが応答する場合、ルータがハングする問題のトラブルシューティングに必要でない限り、上記の情報を収集する前にルータを手作業でリロードしたり、電源のオフ/オンを行わないようにしてください。これを行うと、問題の原因の判別に必要な、重要な情報が失われる可能性があります。


関連情報


Document ID: 15105