ネットワーク管理 コンフィギュレーション ガイド Cisco IOS Release 15.1S
トラブルシューティングおよび障害管理
トラブルシューティングおよび障害管理
発行日;2012/02/02 | 英語版ドキュメント(2011/04/25 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

トラブルシューティングおよび障害管理

トラブルシューティングおよび障害管理のタスク リスト

show コマンドを使用したシステム情報の表示

ネットワーク接続のテスト

TCP キープアライブ パケット サービスの設定

ping コマンドによる接続のテスト

パケット ルートのトレース

システム メッセージのロギング

システム メッセージ ロギングのイネーブル化

スレーブ カードのメッセージ ロギングのイネーブル化

syslog 宛先の設定

ロギング メッセージの同期の設定

ログ メッセージでのタイムスタンプのイネーブル化

エラー メッセージの重大度およびファシリティの制限

UNIX システム ロギング ファシリティの定義

ロギング情報の表示

UNIX syslog デーモンへのエラーのロギング

syslog 送信元アドレスの設定

ラインカードでのフィールド診断の使用

特定のラインカードのトラブルシューティング

ラインカードのクラッシュ情報の保存

システムの例外のコア ダンプの作成

コア ダンプ ファイルの宛先の指定

コア ダンプでの TFTP の使用

コア ダンプでの FTP の使用

コア ダンプでの rcp の使用

コア ダンプでのフラッシュ ディスクの使用

例外メモリ コア ダンプの作成

スプリアス割り込みコア ダンプの設定

デバッグ操作のイネーブル化

条件付きトリガー デバッグのイネーブル化

プロトコル特有の debug コマンドのイネーブル化

条件付きデバッグ コマンドのイネーブル化

1 つのインターフェイスのメッセージの表示

複数のインターフェイスのメッセージの表示

条件に基づいたメッセージ数の制限

複数のデバッグ条件の指定

条件付きトリガー デバッグの設定例

環境モニタの使用

トラブルシューティングおよび障害管理

この章では、システムおよびネットワークのトラブルシューティングのために実行できる基本的なタスクについて説明します。トラブルシューティング手順の詳細については、『 Internetwork Troubleshooting Guide 』を参照してください。すべての debug コマンドの詳細については、『 Cisco IOS Debug Command Reference 』を参照してください。

この章で説明するトラブルシューティング コマンドの詳細については、リリース 12.2 『 Cisco IOS Configuration Fundamentals Command Reference 』の「Cisco IOS System Management Commands」パートにある「Troubleshooting and Fault Management Commands」を参照してください。この章で出現するその他のコマンドのマニュアルを見つけるには、『 Cisco IOS Command Reference Master Index 』または検索オンラインを参照してください。

トラブルシューティングおよび障害管理のタスク リスト

ネットワークの障害を管理するには、問題を検出し、隔離し、修正する必要があります。システム モニタリング コマンドを使用して問題を検出し、システム テスト コマンドを使用して問題を隔離し、 debug コマンドなどの他のコマンドを使用して問題を解決できます。

一般的な障害管理を行うには、次の項で説明する作業を実行します。

「show コマンドを使用したシステム情報の表示」

「ネットワーク接続のテスト」

「システム メッセージのロギング」

「ラインカードでのフィールド診断の使用」

「特定のラインカードのトラブルシューティング」

「ラインカードのクラッシュ情報の保存」

「システムの例外のコア ダンプの作成」

「デバッグ操作のイネーブル化」

「条件付きトリガー デバッグのイネーブル化」

「環境モニタの使用」

この章で示す資料以外に、Cisco IOS ソフトウェア コンフィギュレーション ガイドの多くの章に、特定のテクノロジーおよび機能に特有の障害管理タスクが含まれています。「Monitoring and Maintaining」の項に、これらのタスクがあります。

show コマンドを使用したシステム情報の表示

システム プロセスに関する情報を提供するために、Cisco IOS ソフトウェアには、実行するとシステム情報の詳細な表を表示する、 show という単語で始まる EXEC コマンドの広範囲なリストが含まれています。次に、システム管理の show コマンドの部分的なリストを示します。記載された情報を表示するには、必要に応じて、EXEC モードで次のコマンドを使用します。

 

コマンド
目的

Router# show c2600

割り込み、IOS プライオリティ マスク、および IDMA ステータスなど、トラブルシューティングのための Cisco 2600 プラットフォームに関する情報を表示します。

Router# show c7200

Cisco 7200 シリーズ ルータの CPU およびミッドプレーンに関する情報を表示します。

Router# show context

ルータがクラッシュした場合、NVRAM に保存された情報を表示します。このコマンドは、テクニカル サポート担当者にだけ役立ちます。このコマンドは、Cisco 2600 および 7000 シリーズ ルータでサポートされています。

Router# show controllers

ラインカード上のハードウェアに特有の情報を表示します。

Router# show controllers logging

ラインカードに関するロギング情報を表示します。

Router# show controllers tech-support

問題を報告する際に使用する回線に関する一般的な情報を表示します。

Router# show controllers vip slot-number tech-support

問題を報告する際に使用する Versatile Interface Processor(VIP; 多用途インターフェイス プロセッサ)カードに関する情報を表示します。

Router# show diag

ラインカードのハードウェア情報(DRAM およびスタティック RAM の詳細を含む)を表示します。

Router# show environment [ all | last | table ]

環境警告条件が現在存在するかどうか、温度および電圧の情報、不揮発性メモリに保存された 6 つの各テスト ポイントから最後に測定された値、または環境仕様を示すメッセージを表示します。このコマンドをサポートするシステムの例には、Cisco 7000 および Cisco 12000 シリーズ ルータが含まれています。

Router# show gsr

Cisco 12000 シリーズ Gigabit Switch Router(GSR; ギガビット スイッチ ルータ)に関するハードウェア情報を表示します。

Router# show gt64010

Cisco 7200 シリーズ ルータでのすべての GT64010 内部レジスタおよび割り込みステータスを表示します。

Router# show memory [ memory-type ] [ free ] [ summary ]

システム メモリ アロケータのアクティビティおよびメモリ使用のブロック別の表示に関するサマリー情報を含む、メモリ プール統計情報を表示します。

Router# show pci { hardware | bridge [ register ]}

Cisco 2600 および 7000 シリーズ ルータの Peripheral Component Interconnect(PCI)ハードウェア レジスタまたはブリッジ レジスタに関する情報を表示します。

Router# show processes [ cpu ]

すべてのアクティブなプロセスに関する情報を表示します。

Router# show processes memory

メモリの使用状況に関する情報を表示します。

Router# show protocols

設定されているプロトコルを表示します。

Router# show stacks

最後のシステム リブートの理由を含む、プロセスおよび割り込みルーチンのスタック使用状況を表示します。このコマンドは、テクニカル サポート担当者にだけ役立ちます。

Router# show subsys [ class class | name name ]

サブシステム情報を表示します。

Router# show tcp [ line-number ]

TCP 接続のステータスを表示します。

Router# show tcp brief [ all ]

TCP 接続エンドポイントの簡潔な説明を表示します。

Router# show tdm connections [ motherboard | slot number ]

Cisco AS5200 アクセス サーバでの Time-Division Multiplexing(TDM; 時分割多重)バス接続またはデータ メモリのスナップショットを表示します。

Router# show tech-support [ page ] [ password ]

問題を報告する際に使用するシステムに関する情報を表示します。

Cisco IOS ソフトウェア コンフィギュレーション ガイドの章全体で示されているコンフィギュレーション コマンドの表にある特定の show コマンドを参照してください。コマンドの詳細については、Cisco IOS ソフトウェア コマンド リファレンスを参照してください。

ネットワーク接続のテスト

基本的なネットワーク接続をテストするには、次の項で説明する作業を実行します。

「TCP キープアライブ パケット サービスの設定」

「ping コマンドによる接続のテスト」

「パケット ルートのトレース」

TCP キープアライブ パケット サービスの設定

TCP キープアライブ機能を使用すると、データが送信されなくなった場合でも(いずれの方向にも)、ルータは、通信しているホストでシステム障害が発生している時間を検出できるようになります。この機能は着信接続において最も役立ちます。たとえば、ルータがプリンタと通信中にホスト障害が発生した場合、プリンタは逆方向のトラフィックを生成しないため、ルータはこれを認識しない可能性があります。キープアライブがイネーブルの場合、ディセーブルであればアイドルな接続で、キープアライブが毎分 1 回送信されます。5 分が経過し、キープアライブが検出されない場合、接続は閉じられます。ホストがリセット パケットを持つキープアライブ パケットに応答した場合も、接続は閉じられます。この状態は、ホストがクラッシュし、再び活動化した場合に発生します。

TCP キープアライブ パケット サービスを生成するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# service { tcp-keepalives-in | tcp-keepalives-out }

アイドル ネットワーク接続(リモート ホストによって開始される着信接続またはユーザによって開始される発信接続のいずれか)で、TCP キープアライブ パケットを生成します。

ping コマンドによる接続のテスト

基本的なネットワーク接続の診断の手助けとして、多くのネットワーク プロトコルがエコー プロトコルをサポートしています。プロトコルでは、宛先ホストに特殊なデータグラムを送信し、そのホストからの応答データグラムを待ちます。このエコー プロトコルからの結果は、パスとホスト間の信頼性、パスでの遅延、およびホストに到達できるか、またはホストが機能しているかどうかを評価するのに役立ちます。

エコー プロトコルを呼び出すには、ユーザ モードまたは特権 EXEC モードのいずれかで次のコマンドを使用します。

 

コマンド
目的

Router# ping [ protocol ] { host | address }

接続性をテストする診断ツールを起動します。

Cisco IOS ソフトウェア コンフィギュレーション ガイドの章全体で示されているコンフィギュレーション コマンドの表にある特定の ping コマンドを参照してください。コマンドの詳細については、Cisco IOS ソフトウェア コマンド リファレンスを参照してください。

パケット ルートのトレース

パケットが宛先に移動するときに実際に使用するルートをトレースするには、ユーザ モードまたは特権 EXEC モードのいずれかで次のコマンドを使用します。

 

コマンド
目的

Router# trace [ protocol ] [ destination ]

ネットワーク(特権レベル)経由でパケットのルートをトレースします。

システム メッセージのロギング

デフォルトでは、ルータはロギング プロセスでロギング メッセージ(デバッグ コマンド出力を含む)を送信します。ロギング プロセスは、さまざまな宛先(設定に応じて、ロギング バッファ、端末回線、または UNIX syslog サーバなど)へのロギング メッセージの配信を制御します。プロセスはコンソールにもメッセージを送信します。ロギング プロセスがオンの場合、メッセージを生成したプロセスの修了後、メッセージがコンソールに表示されます。

ロギング プロセスがディセーブルの場合、メッセージはコンソールにだけ送信されます。メッセージは生成されると送信されるため、エラーおよびデバッグ出力は、プロンプトまたはコマンドからの出力によって挿入されます。

コンソールおよび各宛先に表示されるメッセージのタイプを制御するために、メッセージの重大度を設定できます。ログ メッセージにタイムスタンプを付加するか syslog 送信元アドレスを設定し、リアルタイムのデバッグと管理を強化できます。

システム ロギング メッセージは、従来「システム エラー メッセージ」と呼ばれています。特定のシステム ロギング メッセージの詳細については、『 Cisco IOS Software System Error Messages 』を参照してください。

システム メッセージ ロギングのイネーブル化

システム メッセージ ロギングは、デフォルトでイネーブルになっています。コンソール以外の宛先にメッセージを送信するには、イネーブルにする必要があります。

メッセージ ロギングをディセーブルにするには、 no logging on コマンドを使用します。ロギング プロセスをディセーブルにすると、メッセージがコンソールに書き込まれるまでプロセスが継続できないため、ルータの速度が低下する可能性があります。

メッセージ ロギングをディセーブルにした後、再度イネーブルにするには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# logging on

メッセージ ロギングをイネーブルにします。

スレーブ カードのメッセージ ロギングのイネーブル化

スレーブ VIP カードのコンソールへのステータス メッセージのロギングをイネーブルにする(メッセージを画面に出力する)には、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# service slave-log

スレーブ メッセージ ロギングをイネーブルにします。

syslog 宛先の設定

メッセージ ロギングがイネーブルの場合、コンソール以外に、指定された場所にメッセージを送信できます。

メッセージを受信する場所を設定するには、必要に応じて、次のコマンドを使用します。

 

コマンド
目的

Router(config)# logging buffered [ size ]

メッセージを内部バッファにロギングします。

Router(config)# logging host

メッセージを syslog サーバ ホストにロギングします。

Router# terminal monitor

メッセージを非コンソール端末にロギングします。

logging buffered コマンドは、ロギング メッセージを内部バッファにコピーします。バッファは循環式であるため、バッファがいっぱいになると、新しいメッセージが古いメッセージを上書きします。バッファにロギングされたメッセージを表示するには、 show logging EXEC コマンドを使用します。表示される最初のメッセージは、バッファ内で最も古いメッセージです。バッファの現在の内容をクリアするには、 clear logging 特権 EXEC コマンドを使用します。

logging コマンドは、ロギング メッセージを受信する syslog サーバ ホストを識別します。 host 引数は、ホストの名前または IP アドレスです。このコマンドを複数回実行すると、ロギング メッセージを受信する syslog サーバのリストが作成されます。 no logging コマンドは、指定されたアドレスを持つ syslog サーバを syslog のリストから削除します。

terminal monitor EXEC コマンドは、システム ロギング メッセージを端末に表示する作業をローカルで実行します。

ロギング メッセージの同期の設定

割り込みメッセージおよび debug コマンド出力が、特定の回線の送信請求されたデバイス出力およびプロンプトと同期するようにシステムを設定できます。重大度に基づいて、非同期で出力するメッセージのタイプを識別できます。また、のちにメッセージが廃棄される端末の非同期メッセージを保存するバッファの最大数も決定できます。

割り込みメッセージおよび debug コマンド出力の同期ロギングをオンにすると、送信請求されたデバイス出力が表示または印刷された後に、送信請求されていないデバイス出力がコンソールに表示されるか、または印刷されます。割り込みメッセージおよび debug コマンドは、ユーザ入力のプロンプトが返された後、コンソールに表示されます。したがって、割り込みメッセージおよび debug コマンドは、送信請求されたデバイス出力およびプロンプトの途中に挿入されません。割り込みメッセージの表示後、コンソールは再びユーザ プロンプトを表示します。

割り込みメッセージおよび debug コマンド出力が、送信請求されたデバイス出力およびプロンプトと同期するようにロギングを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

ステップ 1

Router(config)# line [ aux | console | vty ] beginning-line-number [ ending-line-number ]

メッセージの同期ロギングに設定する回線を指定します。

ステップ 2

Router(config-line)# logging synchronous [ level severity-level | all ] [ limit number-of-buffers ]

メッセージの同期ロギングをイネーブルにします。

ログ メッセージでのタイムスタンプのイネーブル化

デフォルトでは、ログ メッセージにはタイムスタンプが付いていません。ログ メッセージのタイムスタンプをイネーブルにするには、グローバル コンフィギュレーション モードで次のいずれかのコマンドを使用します。

 

コマンド
目的

Router(config)# service timestamps log uptime

 

または

Router(config)# service timestamps log datetime [ msec ] [ localtime ] [ show-timezone ]

ログのタイムスタンプをイネーブルにします。

エラー メッセージの重大度およびファシリティの制限

エラー メッセージの重大度を指定することによって、選択されたデバイスに表示されるメッセージ数を制限できます(重大度については、 表 1 を参照してください)。そのためには、必要に応じて、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# logging console level

コンソールにロギングするメッセージ数を制限します。

Router(config)# logging monitor level

端末回線にロギングするメッセージ数を制限します。

Router(config)# logging trap level

syslog サーバにロギングするメッセージ数を制限します。

snmp-server enable trap コマンドを使用して、Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)ネットワーク管理ステーションに送信する syslog メッセージのトラップをイネーブルにした場合、ルータの履歴テーブルに送信されて保存されたメッセージのレベルを変更できます。また、履歴テーブルに保存されるメッセージ数を変更できます。

SNMP トラップはその宛先に到達することが保証されていないため、メッセージは履歴テーブルに保存されます。デフォルトでは、syslog トラップがイネーブルでない場合でも、レベル警告および上記( 表 1 を参照)の 1 つのメッセージが履歴テーブルに保存されます。

レベルおよびテーブル サイズのデフォルトを変更するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

ステップ 1

Router(config)# logging history level

履歴ファイルに保存され、SNMP サーバに送信される syslog メッセージのデフォルト レベルを変更します。

ステップ 2

Router(config)# logging history size number

履歴テーブルに保存できる syslog メッセージの数を変更します。


表 1 に、レベル キーワードと重大度を示します。SNMP を使用する場合、重大度の値は +1 を使用します。たとえば、emergency は 0 ではなく 1 になり、critical は 2 ではなく 3 になります。


logging console コマンドは、コンソール端末に表示されるロギング メッセージを、指定された重大度( level 引数によって指定される)以下のレベル番号を持つメッセージに制限します。 表 1 に、エラー メッセージの level キーワードおよび対応する UNIX syslog の定義を、最も重大なレベルから最も重大でないレベルの順で示します。

 

表 1 システム ロギング メッセージの重大度

レベル キーワード
レベル
説明
syslog の定義

emergencies

0

システムは使用不能

LOG_EMERG

alerts

1

即時対処が必要

LOG_ALERT

critical

2

クリティカルな状況

LOG_CRIT

errors

3

エラー状況

LOG_ERR

warnings

4

警告状況

LOG_WARNING

notifications

5

正常だが重要な状況

LOG_NOTICE

informational

6

情報提供だけを目的とするメッセージ

LOG_INFO

debugging

7

デバッグ メッセージ

LOG_DEBUG

no logging console コマンドは、コンソール端末へのロギングをディセーブルにします。

デフォルトでは、 debugging レベルとそれより下位のレベル番号(すべてのレベルを意味する)のコンソールにメッセージをロギングします。 logging monitor コマンドは、デフォルトで debugging にもなります。 logging trap コマンドは、デフォルトで informational レベルになります。

ロギング メッセージを端末に表示するには、 terminal monitor EXEC コマンドを使用します。

現在のソフトウェアは、次の 4 つのエラー メッセージのカテゴリを生成します。

ソフトウェアまたはハードウェアの誤動作に関するエラー メッセージ( warnings から emergencies までのレベルで表示される)

debug コマンドからの出力( debugging レベルで表示される)

インターフェイスのアップ/ダウンの移行とシステム再起動のメッセージ( notifications レベルで表示される)

リロード要求とロープロセス スタック メッセージ( informational レベルで表示される)

UNIX システム ロギング ファシリティの定義

UNIX システム ユーティリティによって生成されるメッセージをロギングできます。この作業を行うには、このタイプのロギングをイネーブルにし、メッセージをロギングする UNIX システム ファシリティを定義します。 表 2 に、Cisco IOS ソフトウェアによってサポートされている UNIX システム ファシリティを示します。これらの UNIX システム ファシリティの詳細については、ご使用の UNIX オペレーティング システムのオペレータ マニュアルを参照してください。syslog の形式は、Berkeley Standard Distribution(BSD)UNIX バージョン 4.3 と互換性があります。

UNIX システム ファシリティのメッセージ ロギングを定義するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# logging facility facility-type

システム ログ ファシリティを設定します。

 

表 2 ロギング ファシリティ タイプのキーワード

ファシリティ タイプのキーワード
説明

auth

認可システムを示します。

cron

cron ファシリティを示します。

daemon

システム デーモンを示します。

kern

カーネルを示します。

local0-7

ローカルで定義されたメッセージ用に予約されます。

lpr

回線プリンタ システムを示します。

mail

メール システムを示します。

news

USENET ニュースを示します。

sys9

システムの使用を示します。

sys10

システムの使用を示します。

sys11

システムの使用を示します。

sys12

システムの使用を示します。

sys13

システムの使用を示します。

sys14

システムの使用を示します。

syslog

システム ログを示します。

user

ユーザ プロセスを示します。

uucp

UNIX 間のコピー システムを示します。

ロギング情報の表示

ロギング情報を表示するには、必要に応じて、EXEC モードで次のコマンドを使用します。

 

コマンド
目的

Router# show logging

syslog エラーおよびイベント ロギングの状態を表示します(ホスト アドレス、コンソール ロギングがイネーブルかどうか、および他のロギング統計情報を含む)。

Router# show controllers vip slot-number logging

VIP カードの syslog エラーおよびイベント ロギングの状態を表示します(ホスト アドレス、コンソール ロギングがイネーブルかどうか、および他のロギング統計情報を含む)。

Router# show logging history

テーブルのサイズ、メッセージのステータス、およびテーブルに保存されたメッセージのテキストなど、syslog 履歴テーブル内の情報を表示します。

UNIX syslog デーモンへのエラーのロギング

4.3 BSD UNIX システム上で syslog デーモンを設定するには、/etc/syslog.conf ファイルに次のような行を含めます。

local7.debugging /usr/adm/logs/cisco.log
 

debugging キーワードは、syslog のレベルを指定します。他のキーワードの一般的な説明については、 表 1 を参照してください。 local7 キーワードは、使用するロギング ファシリティを指定します。他のキーワードの一般的な説明については、 表 2 を参照してください。

syslog デーモンは、次のフィールドで指定されたファイルに、このレベルまたはより重大なレベルのメッセージを送信します。ファイルがすでに存在し、syslog デーモンがそのファイルに書き込む権限をもっている必要があります。

syslog 送信元アドレスの設定

デフォルトでは、syslog メッセージには、ルータから出るために使用するインターフェイスの IP アドレスが含まれています。使用するインターフェイスにかかわらず、すべての syslog メッセージに同じ IP アドレスが含まれるように設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# logging source-interface type number

syslog 送信元アドレスを設定します。

ラインカードでのフィールド診断の使用

Cisco 12000 シリーズ ルータの各ラインカードは、フィールド診断テストを行い、システムの正常な動作を中断せずに、故障したハードウェアを隔離できます。ただし、ラインカードでフィールド診断テストを行うと、テスト中にラインカードでのすべてのアクティビティが一時停止します。フィールド診断テストが無事に終了すると、Cisco IOS ソフトウェアは、ラインカード上に自動的にリロードされます。


) フィールド診断 diag コマンドは、Gigabit Route Processor(GRP; ギガビット ルート プロセッサ)のメイン コンソール ポートから実行する必要があります。


ラインカードでフィールド診断テストを行うには、特権 EXEC モードで次のコマンドを使用します。

 

コマンド
目的

Router# diag slot-number [ previous | post | verbose | wait ]

診断テストを行うラインカードを指定します。

任意で、以前のテスト結果を表示するか、拡張 Power-On Self-Test(POST)だけを行うか、最大のメッセージを表示するか、またはテストが無事に終了した後に Cisco IOS ソフトウェアをラインカードにリロードしないように指定します。次のプロンプトが表示されます。

Running Diags will halt ALL activity on the requested slot. [confirm]
 

プロンプトで Return キーを押して、指定されたラインカードでフィールド診断テストを行うことを確定するか、 no とタイプしてテストを中止します。

ラインカードでフィールド診断テストを中止するには、特権 EXEC モードで次のいずれかのコマンドを使用します。

 

コマンド
目的

Router# diag slot-number halt

 

または

Router# no diag slot-number

診断テストを中止するラインカードを指定します。


) フィールド診断テストを中止すると、ラインカードはダウン状態(起動していない状態)になります。ほとんどの場合、ラインカードを取り外すか交換する必要があるために、テストを中止します。それ以外の場合で、ラインカードを再び活動化(オンラインの状態)する場合、microcode reload グローバル コンフィギュレーション コマンドを使用するか、ラインカードの電源を再投入する必要があります。


特定のラインカードのトラブルシューティング

Cisco IOS は、 execute-on コマンドを提供し、モニタリングとメンテナンスのために、Cisco IOS コマンド( show コマンドなど)を特定のラインカードに発行できるようにします。たとえば、 execute-on slot 3 show version コマンドを発行することによって、Cisco 12012 Gigabit Switch Router(GSR; ギガビット スイッチ ルータ)のスロット 3 のカードにロードされる Cisco IOS イメージを表示できます。また、このコマンドは、シスコ アクセス サーバのダイヤル シェルフ内のカードのトラブルシューティングにも使用できます。このコマンドの詳細については、リリース 12.2 『 Cisco IOS Configuration Fundamentals Command Reference 』の「Troubleshooting」の章を参照してください。

ラインカードのクラッシュ情報の保存

ここでは、ラインカードのクラッシュ情報を保存できるようにし、任意で保存された情報のタイプと量を指定する方法について説明します。テクニカルサポート担当者は、ラインカードの重大な問題のトラブルシューティングのために、ラインカードからのクラッシュ情報を調査できる必要があります。クラッシュ情報には、メイン メモリおよび送受信バッファの情報を含む、すべてのラインカード メモリ情報が含まれています。


注意 exception linecard グローバル コンフィギュレーション コマンドは、テクニカルサポート担当者によって指示を受けた場合にだけ使用し、テクニカルサポート担当者がイネーブルにするように要求するイネーブル オプションだけを使用します。

ラインカードのクラッシュ情報オプションをイネーブルにして設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# exception linecard { all | slot slot-number } [ corefile filename | main-memory size [ k | m ] | queue-ram size [ k | m ] | rx-buffer size [ k | m ] | sqe-register-rx | sqe-register-tx | tx-buffer size [ k | m ]]

ラインカードがリセットされた場合にクラッシュ情報を取得するラインカードを指定します。任意で、保存するメモリのタイプと量を指定します。

システムの例外のコア ダンプの作成

「システムの例外」は、予期しないシステムのシャットダウンまたはリブート(システム障害によって発生する場合が最も多く、一般的に「システム クラッシュ」と呼ばれる)です。例外が発生した場合、メモリ イメージのフル コピー(「コア ダンプ」と呼ばれる)を取得し、予期しないシャットダウンの原因を特定することが役立つ場合があります。すべての例外タイプがコア ダンプを生成するとは限りません。

コア ダンプは、一般的にテクニカルサポート担当者にだけ役立ちます。きわめて大きなバイナリ ファイルであるコア ダンプ ファイルは、Trivial File Transfer Protocol(TFTP)、File Transfer Protocol(FTP; ファイル転送プロトコル)、または Remote Copy Protocol(RCP; リモート コピー プロトコル)に転送するか、(限定されたプラットフォームで)フラッシュ ディスクに保存した後、ソース コードおよび詳細なメモリ マップにアクセスする技術担当者が解釈できます。


注意 exception コマンドは、テクニカルサポート担当者の指示があった場合だけ使用します。ルータがネットワーク内で機能しているときにコア ダンプを作成すると、ネットワークの動作が妨げられることがあります。

コア ダンプ ファイルの宛先の指定

ルータがコア ダンプを生成するように設定するには、例外ダンプをイネーブルにし、コア ダンプ ファイルの宛先を設定する必要があります(次の項を参照)。

「コア ダンプでの TFTP の使用」

「コア ダンプでの FTP の使用」

「コア ダンプでの rcp の使用」

「コア ダンプでのフラッシュ ディスクの使用」

コア ダンプでの TFTP の使用

ほとんどの TFTP アプリケーションには制限があるため、ルータはコア ファイルの最初の 16 MB だけをダンプします。したがって、ルータのメイン メモリが 16 MB を超える場合、TFTP を使用しないでください。

TFTP を使用してコア ダンプにルータを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンドまたはアクション
目的

ステップ 1

exception protocol tftp

 

(任意)TFTP をルータの例外に使用するプロトコルとして明示的に指定します(予期しないシステムのシャットダウンのためのコア ダンプ)。

コマンドを使用します。

ステップ 2

exception dump ip-address

 

ルータがクラッシュした場合、ルータがコア ファイルを指定されたサーバにダンプするように設定します。

ステップ 3

exception core-file [ filepath /] filename

 

(任意)コア ダンプ ファイルに使用する名前を指定します。通常、ファイルは TFTP サーバにあらかじめ存在し、書き込み可能である必要があります。

たとえば、次のコマンドは、ルータがコア ファイルを IP アドレス 172.17.92.2 のサーバに送信するように設定します。例外プロトコルが指定されていないので、TFTP のデフォルト プロトコルが使用されます。

Router(config)# exception dump 172.17.92.2
 

コア ダンプは TFTP サーバ上の「 hostname -core」という名前のファイルに書き込まれます。hostname はルートの名前です(上の例では、ファイルは「Router-core」と命名されます)。 exception core-file filename コンフィギュレーション コマンドを追加することによって、コア ファイルの名前を変更できます。

使用する TFTP サーバ アプリケーションに応じて、ルータがコアを書き込むことができる空のターゲット ファイルを TFTP サーバ上に作成しなければならない場合があります。また、TFTP サーバにコア ダンプ全部を収容する十分なメモリがあることを確認してください。

コア ダンプでの FTP の使用

FTP を使用してコア ダンプにルータを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

ステップ 1

Router(config)# ip ftp username username

(任意)FTP 接続のユーザ名を設定します。

ステップ 2

Router(config)# ip ftp password [ type ] password

(任意)FTP 接続で使用するパスワードを指定します。

ステップ 3

Router(config)# exception protocol ftp

コア ダンプ ファイルの転送に FTP を使用するように指定します。

ステップ 4

Router(config)# exception dump ip-address

ルータがクラッシュした場合、ルータがコア ファイルを特定のサーバにダンプするように設定します。

ステップ 5

Router(config)# exception core-file filename

(任意)コア ダンプ ファイルに使用する名前を指定します。

次の例では、ルータがクラッシュした場合に、ルータが FTP を使用して、「dumpfile」という名前のコア ファイルを 172.17.92.2 の FTP サーバにダンプするように設定します。

ip ftp username red
ip ftp password blue
exception protocol ftp
exception dump 172.17.92.2
exception core-file dumpfile

コア ダンプでの rcp の使用

リモート コピー プロトコルを使用してコア ダンプ ファイルを送信することもできます。ルータが rcp を使用してコア ダンプ ファイルを送信するように設定するには、次のコマンドを使用します。

 

コマンドまたはアクション
目的

ステップ 1

i p rcmd remote-username username

(任意)ルータが rcp コピー/書き込み要求を使用してリモート サーバに送信するユーザ名を指定します。リモート rcp サーバは、指定されたユーザ名に書き込みアクセス権を与えるように設定する必要があります(言い換えれば、ユーザ名のネットワーク サーバでアカウントを定義する必要があります)。

ステップ 2

exception protocol rcp

rcp をコア ダンプ ファイルの送信で使用するプロトコルとして設定します。

ステップ 3

exception dump ip-address

 

ルータがクラッシュした場合、ルータがコア ファイルを指定されたサーバにダンプするように設定します。

ステップ 4

exception core-file filename

 

(任意)コア ダンプ ファイルに使用する名前を指定します。

rcp ユーザ名が ip rcmd remote-username コマンドを使用して設定されていない場合、rcp ユーザ名は、デフォルトで現在の端末(tty)接続に関連したユーザ名になります。たとえば、ユーザが Telnet 経由でルータに接続されていて、username コマンドによって認証された場合、ルータのソフトウェアは、Telnet ユーザ名を rcp ユーザ名として送信します。端末ユーザ名が使用できない場合、ルータ ホスト名が rcp ユーザ名として使用されます。

コア ダンプでのフラッシュ ディスクの使用

一部のルータ プラットフォームは、リニア フラッシュ メモリまたは PCMCIA フラッシュ カードの代替として、フラッシュ ディスクをサポートしています。これらのフラッシュ ディスクはストレージ容量が大きいため、コア ダンプをキャプチャする他の手段の候補となります。フラッシュ ディスクを使用してコア ダンプにルータを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的
Router(config)# exception flash [ procmem | iomem | all ] device-name [ : partition-number ] [ erase | no_erase ]

フラッシュ ディスクを使用してコア ダンプにルータを設定します。

Router(config)# exception core-file filename

 

(任意)コア ダンプ ファイルに使用する名前を指定します。

show flash all EXEC コマンドは、 exception flash コマンドで使用できるデバイスを示します。

例外メモリ コア ダンプの作成

デバッグ プロセス中に特定のメモリ サイズ パラメータが違反された場合に、ルータがコア ダンプを作成し、リブートするようにするには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

デバッグの手順として、特定のメモリ サイズ パラメータが違反された場合に、ルータがコア ダンプを作成し、リブートするように設定できます。コア ダンプをトリガーするには、次の exception memory コマンドを使用します。

 

コマンド
目的

Router(config)# exception memory minimum bytes

フリー メモリの量が指定されたバイト数を下回ると、コア ダンプとシステムのリロードをトリガーします。

ルータはコア ダンプを提供するために一定の量のフリー メモリを必要とするため、低すぎるメモリの値を指定しないでください。

フリー メモリよりも大きいサイズを入力した場合( exception dump コマンドが設定されている)、コア ダンプとルータのリロードは、60 秒後に生成されます。

Router(config)# memory check-interval seconds

(任意)メモリをチェックするインターバルを大きくします。デフォルトは 60 秒ですが、60 秒間に破損の原因を隠す多くのことが発生する可能性があります。インターバルを小さくすると、CPU 使用率が増加します(約 12%、ほとんどの場合許容できる)が、使用できるコアを得る可能性も高くなります。CPU 使用率が 100% に到達しないようにするには、処理負荷が高いルータでインターバルを徐々に小さくする必要があります。理想的なインターバルは、他のシステムの問題を発生させない範囲でできるだけ低い値です。

Router(config)# exception memory fragment bytes

連続した(断片化していない)フリー メモリの量が指定されたバイト数を下回ると、コア ダンプとシステムのリロードをトリガーします。

Router(config)# exception core-file filename

 

(任意)コア ダンプ ファイルに使用する名前を指定します。通常、ファイルは TFTP サーバに存在し、書き込み可能である必要があります。ファイルはルータ上のプロセッサ メモリの量と同じサイズになることに注意してください。

exception memory minimum コマンドは、主に、コア ダンプがトリガーされるか、他のデバッグが行われる(急速なメモリ リーク)前にメモリの不足が予測される場合に役立ちます。メモリ リークが段階的である場合(スロー ドリフト)、一般的に、システムでメモリが不足し、リロードする前に、デバッグを行う時間はあります。

デフォルトでは、フリー メモリのバイト数は、これらのコマンドが設定されている場合、60 秒おきにチェックされます。このチェックの頻度は、 memory check-interval seconds コマンドを使用して増やすことができます。

exception dump ip-address コマンドは、これらのコマンドとともに設定する必要があります。 exception dump コマンドが設定されていない場合、ルータはコア ダンプをトリガーせずにリロードします。

次の例では、ルータがフリー メモリを監視するように設定します。メモリが 250000 バイトを下回ると、コア ダンプが作成され、ルータがリロードします。

exception dump 172.18.92.2
exception core-file memory.overrun
exception memory minimum 250000

スプリアス割り込みコア ダンプの設定

デバッグ プロセス中、指定された数の割り込みが発生した場合に、ルータがスプリアス割り込みコア ダンプを作成し、リブートするように設定できます。


注意 exception spurious-interrupt グローバル コンフィギュレーション コマンドは、テクニカルサポート担当者によって指示を受けた場合にだけ使用し、テクニカルサポート担当者によって要求されたイネーブル オプションだけを使用します。

スプリアス割り込みのクラッシュ情報をイネーブルにして設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。

 

コマンド
目的

Router(config)# exception spurious-interrupt number

リロード前にコア ダンプに含めるスプリアス割り込みの最大数を設定します

Router(config)# exception dump ip-address

 

または

Router(config)# exception flash

コア ダンプ ファイルの宛先を指定します。

次の例では、ルータが 2 つのスプリアス割り込みの制限を持つコア ダンプを作成するように設定します。

exception spurious-interrupt 2
exception dump 209.165.200.225

デバッグ操作のイネーブル化

ルータには、内部の問題およびネットワーク上の他のホストの問題のトラブルシューティングに役立つハードウェアとソフトウェアが含まれています。 debug 特権 EXEC モード コマンドは、いくつかのクラスのネットワーク イベントのコンソール表示を開始します。次のコマンドは、一般的に、システム デバッグ メッセージ機能について説明します。 debug コマンドの詳細については、『 Cisco IOS Debug Command Reference 』を参照してください。また、追加情報については、『 Internetwork Troubleshooting Guide 』を参照してください。

デバッグ操作をイネーブルにするには、次のコマンドを使用します。

 

コマンド
目的

Router# show debugging

各デバッグ操作の状態を表示します。

Router# debug ?

すべての debug コマンド オプションのリストと簡単な説明を表示します。

Router# debug command

指定された debug コマンドのメッセージ ロギングを開始します。

Router# no debug command

指定された debug コマンドのメッセージ ロギングをオフにします。


注意 システムはデバッグ出力に高いプライオリティを与えます。このため、デバッグ コマンドは、特定の問題のトラブルシューティングまたはテクニカルサポート担当者とのトラブルシューティング セッション中にだけオンにする必要があります。過度のデバッグ出力によって、システムが動作不能になることがあります。

システムの debug メッセージのタイムスタンプを設定できます。タイムスタンプは、ロギングされたイベントの相対的なタイミングを提供することによって、リアルタイム デバッグを強化します。この情報は、特に、サポートのためにデバッグ出力をテクニカルサポート担当者に送信する場合に役立ちます。システムの debug メッセージのタイムスタンプをイネーブルにするには、グローバル コンフィギュレーション モードで次のいずれかのコマンドを使用します。

 

コマンド
目的

Router(config)# service timestamps debug uptime

 

または

Router(config)# service timestamps debug datetime [ msec ] [ localtime ] [ show-timezone ]

システムの debug メッセージのタイムスタンプをイネーブルにします。

通常では、メッセージはコンソール端末にだけ表示されます。出力デバイスを変更するには、この章の前半にある「syslog 宛先の設定」の項を参照してください

条件付きトリガー デバッグのイネーブル化

条件付きトリガー デバッグ機能がイネーブルの場合、ルータは、指定されたインターフェイス上のルータを出入りするパケットのデバッグ メッセージを生成します。ルータは、異なるインターフェイスを通して出入りするパケットのデバッグ出力を生成しません。インターフェイスを明示的に指定できます。たとえば、1 つのインターフェイスまたはサブインターフェイスのデバッグ メッセージを表示できます。また、指定された条件を満たすすべてのインターフェイスのデバッグをオンにすることもできます。この機能は、多くのポートを持つダイヤル アクセス サーバで役立ちます。

通常では、ルータはすべてのインターフェイスのデバッグ メッセージを生成するため、多数のメッセージが生成されます。多数のメッセージはシステム リソースを消費し、必要とする特定の情報を検索する機能に影響を与える可能性があります。デバッグ メッセージの数を制限することによって、トラブルシューティングを行うポートだけに関連するメッセージを受信できます。

条件付きトリガー デバッグは、次のプロトコル特有の debug コマンドからの出力を制御します。

debug aaa { accounting | authorization | authentication }

debug dialer { events | packets }

debug isdn { q921 | q931 }

debug modem { oob | trace }

debug ppp { all | authentication | chap | error | negotiation | multilink events | packet }

この機能は示されたコマンドの出力を制限しますが、これらのコマンドからのデバッグ出力の生成を自動的にはイネーブルにしません。デバッグ メッセージは、プロトコル特有の debug コマンドがイネーブルの場合にだけ生成されます。 debug コマンド出力は、2 つのプロセスを通して制御されます。

プロトコル特有の debug コマンドは、デバッグされているプロトコルを指定します。たとえば、 debug dialer events コマンドは、ダイヤラ イベントに関連するデバッグ出力を生成します。

debug condition コマンドは、これらのデバッグ メッセージを特定のインターフェイスに関連するメッセージに制限します。たとえば、 debug condition username bob コマンドは、bob のユーザ名を指定するパケットを持つインターフェイスだけのデバッグ出力を生成します。

条件付きトリガー デバッグを設定するには、次の項で説明する作業を実行します。

「プロトコル特有の debug コマンドのイネーブル化」

「条件付きデバッグ コマンドのイネーブル化」

「複数のデバッグ条件の指定」

プロトコル特有の debug コマンドのイネーブル化

デバッグ出力を生成するには、希望する出力のプロトコル特有の debug コマンドをイネーブルにする必要があります。イネーブルにするデバッグのタイプを決定するには、 show debugging コマンドを使用します。現在のデバッグ条件を表示するには、 show debug condition コマンドを使用します。希望するプロトコル特有の debug コマンドをイネーブルにするには、特権 EXEC モードで次のコマンドを使用します。

 

コマンド
目的

Router# show debugging

イネーブルにするデバッグのタイプを決定します。

Router# show debug condition [ condition-id ]

現在の debug 条件を表示します。

Router# debug protocol

希望するデバッグ コマンドをイネーブルにします。

Router# no debug protocol

希望しないデバッグ コマンドをディセーブルにします。

出力を行わない場合、すべてのプロトコル特有の debug コマンドをディセーブルにします。

条件付きデバッグ コマンドのイネーブル化

debug condition コマンドがイネーブルになっていない場合、インターフェイスに関係なく、イネーブルなプロトコル特有の debug コマンドのすべてのデバッグ出力が表示されます。

最初に入力した debug condition コマンドが条件付きデバッグをイネーブルにします。ルータは、指定された条件のいずれかを満たすインターフェイスのメッセージだけを表示します。複数の条件が指定されている場合、メッセージを表示するには、インターフェイスは少なくとも 1 つの条件を満たす必要があります。

明示的に指定されたインターフェイスまたは特定の条件を満たすインターフェイスのメッセージをイネーブルにするには、次の項で説明する作業を実行します。

「1 つのインターフェイスのメッセージの表示」

「複数のインターフェイスのメッセージの表示」

「条件に基づいたメッセージ数の制限」

1 つのインターフェイスのメッセージの表示

1 つを除くすべてのインターフェイスのデバッグ メッセージをディセーブルにするには、特権 EXEC モードで次のコマンドを使用します。

 

コマンド
目的

Router# debug condition interface interface

指定されたインターフェイスに対してだけ、デバッグ出力をイネーブルにします。

すべてのインターフェイスに対して再度デバッグ出力をイネーブルにするには、 no debug interface コマンドを使用します。

複数のインターフェイスのメッセージの表示

複数のインターフェイスのデバッグ メッセージをイネーブルにするには、特権 EXEC モードで次のコマンドを使用します。

 

コマンド
目的

ステップ 1

Router# debug condition interface interface

指定されたインターフェイスに対してだけ、デバッグ出力をイネーブルにします。

ステップ 2

Router# debug condition interface interface

追加のインターフェイスのデバッグ メッセージをイネーブルにします。希望するすべてのインターフェイスでデバッグ メッセージがイネーブルになるまで、この作業を繰り返します。

このコマンドを複数回入力して、複数のインターフェイスを指定する場合、指定されたすべてのインターフェイスに対してデバッグ出力が表示されます。特定のインターフェイスでのデバッグをオフにするには、 no debug interface コマンドを使用します。 no debug interface all コマンドを使用するか、最後の debug interface コマンドを削除した場合、すべてのインターフェイスに対して、デバッグ出力が再びイネーブルになります。

条件に基づいたメッセージ数の制限

ルータはインターフェイスを監視し、次のいずれかの条件に対して指定された値がパケットに含まれるかどうかを学習できます。

ユーザ名

発番号

着番号

発番号などの条件を入力すると、すべてのインターフェイスに対するデバッグ出力が中止されます。次に、ルータはすべてのインターフェイスを監視し、指定された発番号を持つパケットが任意のインターフェイスで送受信されるかどうかを学習します。インターフェイスまたはサブインターフェイスで条件が満たされると、そのインターフェイスに対して debug コマンド出力が表示されます。インターフェイスのデバッグ出力は、条件が満たされた場合に「トリガー」されます。デバッグ出力は、他のインターフェイスに対してはディセーブルのままです。その後、別のインターフェイスに対して条件が満たされた場合、デバッグ出力はそのインターフェイスに対してもイネーブルになります。

いったんデバッグ出力がインターフェイスでトリガーされると、その出力はインターフェイスがダウン状態になるまで継続されます。ただし、そのインターフェイスのセッションが変更され、新しいユーザ名、着番号、または発番号になる可能性があります。特定のインターフェイスでデバッグ トリガー メカニズムをリセットするには、 no debug interface コマンドを使用します。そのインターフェイスのデバッグ出力は、インターフェイスが指定されたいずれかの条件を満たすまでディセーブルになります。

指定された条件に基づいてデバッグ メッセージの数を制限するには、特権 EXEC モードで次のコマンドを使用します。

 

コマンド
目的

Router# debug condition { username username | called dial-string | caller dial-string }

条件付きデバッグをイネーブルにします。ルータは、この条件を満たすインターフェイスのメッセージだけを表示します。

すべてのインターフェイスのデバッグ出力を再度イネーブルにするには、 no debug condition all コマンドを使用します。

複数のデバッグ条件の指定

複数の条件に基づいてデバッグ メッセージの数を制限するには、特権 EXEC モードで次のコマンドを使用します。

 

コマンド
目的

ステップ 1

Router# debug condition { username username | called dial-string | caller dial-string }

条件付きデバッグをイネーブルにし、最初の条件を指定します。

ステップ 2

Router# debug condition { username username | called dial-string | caller dial-string }

2 つめの条件を指定します。すべての条件が指定されるまで、この作業を繰り返します。

複数の debug condition コマンドを入力した場合、インターフェイスが少なくとも 1 つの条件を満たすと、デバッグ出力が生成されます。 no debug condition コマンドを使用して、いずれかの条件を削除した場合、その条件だけを満たすインターフェイスは、デバッグ出力を生成しなくなります。ただし、削除された条件以外の条件を満たすインターフェイスは、引き続き出力を生成します。インターフェイスに対してアクティブな条件が満たされていない場合にだけ、そのインターフェイスの出力がディセーブルになります。

条件付きトリガー デバッグの設定例

この例では、次のコマンドによって 4 つの条件が設定されています。

debug condition interface serial 0

debug condition interface serial 1

debug condition interface virtual-template 1

debug condition username fred

最初の 3 つの条件は、1 つのインターフェイスによって満たされています。4 つめの条件はまだ満たされていません。

Router# show debug condition
 
Condition 1: interface Se0 (1 flags triggered)
Flags: Se0
Condition 2: interface Se1 (1 flags triggered)
Flags: Se1
Condition 3: interface Vt1 (1 flags triggered)
Flags: Vt1
Condition 4: username fred (0 flags triggered)
 

debug condition コマンドが入力されている場合、条件付きデバッグのデバッグ メッセージがイネーブルになります。次のデバッグ メッセージは、シリアル 0 とシリアル 1 のインターフェイスが活動化すると異なるインターフェイスで満たされる条件を示します。たとえば、出力の 2 行目は、シリアル インターフェイス 0 がユーザ名 fred の条件を満たすことを示します。

*Mar 1 00:04:41.647: %LINK-3-UPDOWN: Interface Serial0, changed state to up
*Mar 1 00:04:41.715: Se0 Debug: Condition 4, username fred triggered, count 2
*Mar 1 00:04:42.963: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
*Mar 1 00:04:43.271: Vi1 Debug: Condition 3, interface Vt1 triggered, count 1
*Mar 1 00:04:43.271: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
*Mar 1 00:04:43.279: Vi1 Debug: Condition 4, username fred triggered, count 2
*Mar 1 00:04:43.283: Vi1 Debug: Condition 1, interface Se0 triggered, count 3
*Mar 1 00:04:44.039: %IP-4-DUPADDR: Duplicate address 172.27.32.114 on Ethernet 0, sourced by 00e0.1e3e.2d41
*Mar 1 00:04:44.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
*Mar 1 00:04:54.667: %LINK-3-UPDOWN: Interface Serial1, changed state to up
*Mar 1 00:04:54.731: Se1 Debug: Condition 4, username fred triggered, count 2
*Mar 1 00:04:54.735: Vi1 Debug: Condition 2, interface Se1 triggered, count 4
*Mar 1 00:04:55.735: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
 

一定の期間が経過すると、 show debug condition コマンドは、条件の改訂リストを表示します。

Router# show debug condition
 
Condition 1: interface Se0 (2 flags triggered)
Flags: Se0 Vi1
Condition 2: interface Se1 (2 flags triggered)
Flags: Se1 Vi1
Condition 3: interface Vt1 (2 flags triggered)
Flags: Vt1 Vi1
Condition 4: username fred (3 flags triggered)
Flags: Se0 Vi1 Se1
 

次に、シリアル 1 とシリアル 0 のインターフェイスは、ダウン状態になります。インターフェイスがダウン状態になると、そのインターフェイスの条件はクリアされます。

*Mar 1 00:05:51.443: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar 1 00:05:51.471: Se1 Debug: Condition 4, username fred cleared, count 1
*Mar 1 00:05:51.479: Vi1 Debug: Condition 2, interface Se1 cleared, count 3
*Mar 1 00:05:52.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
*Mar 1 00:05:56.859: %LINK-3-UPDOWN: Interface Serial0, changed state to down
*Mar 1 00:05:56.887: Se0 Debug: Condition 4, username fred cleared, count 1
*Mar 1 00:05:56.895: Vi1 Debug: Condition 1, interface Se0 cleared, count 2
*Mar 1 00:05:56.899: Vi1 Debug: Condition 3, interface Vt1 cleared, count 1
*Mar 1 00:05:56.899: Vi1 Debug: Condition 4, username fred cleared, count 0
*Mar 1 00:05:56.903: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
*Mar 1 00:05:57.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
*Mar 1 00:05:57.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
 

最終的な show debug condition の出力は、インターフェイスが活動化する前の出力と同じです。

Router# show debug condition
 
Condition 1: interface Se0 (1 flags triggered)
Flags: Se0
Condition 2: interface Se1 (1 flags triggered)
Flags: Se1
Condition 3: interface Vt1 (1 flags triggered)
Flags: Vt1
Condition 4: username fred (0 flags triggered)

環境モニタの使用

一部のルータおよびアクセス サーバには、ルータの物理的条件を監視する環境モニタが付いています。測定値が許容できる限界を超えた場合、警告メッセージがシステム コンソールに出力されます。システム ソフトウェアは 60 秒おきに測定値を収集しますが、特定のテスト ポイントに対する警告は、多くても 4 時間おきに出力されます。温度測定値がシャットダウンよりも大きく仕様から外れている場合、ソフトウェアはルータをシャットダウンします(ファンはオンのままです)。このようなシャットダウンの後、ルータを手動でオフにしてからオンにする必要があります。 show environment コマンドを使用して、いつでも環境モニタを照会し、測定値が許容誤差から外れているかどうか判断できます。環境モニタの警告メッセージの詳細については、『 Cisco IOS System Error Messages 』を参照してください。

環境モニタのあるルータでは、温度テスト ポイントのいずれかが最大限界を超えたことをソフトウェアが検出した場合、次の手順を行います。

1. 6 つの各テスト ポイントから最後に測定された値を内部の不揮発性メモリに保存します。

2. システム ソフトウェアを中断し、シャットダウン メッセージをシステム コンソールに出力します。

3. 数ミリ秒の遅延後、電源を遮断します。

温度が最大限界を超えた場合、システムは、シャットダウンの理由を示すメッセージとともに、次のメッセージを表示します。

Router#
%ENVM-1-SHUTDOWN: Environmental Monitor initiated shutdown
%ENVM-2-TEMP: Inlet temperature has reached SHUTDOWN level at 64(C)
 

環境仕様の詳細については、ご使用のルータのハードウェア インストレーションおよびメンテナンス マニュアルを参照してください。