Cisco NX-OS トラブルシューティング ガイド Release 4.0
インストール、アップグレード、および 再起動のトラブルシューティング
インストール、アップグレード、および再起動のトラブルシューティング
発行日;2012/01/09 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 1MB) | フィードバック

目次

インストール、アップグレード、および再起動のトラブルシューティング

概要

ガイドライン

インストールのガイドライン

アップグレードのガイドライン

再起動のガイドライン

Cisco NX-OS ソフトウェア インストールの確認

無停止アップグレードの確認

ROM モニタ モードの使用

Cisco NX-OS ソフトウェアのアップグレードとダウングレードのトラブルシューティング

インストール時のソフトウェアのエラーによる終了

Cisco NX-OS ソフトウェアのインストール

Cisco NX-OS ソフトウェア システム再起動のトラブルシューティング

電源投入時または再起動時におけるスイッチのハングアップ

破損したブートフラッシュの復旧

スーパーバイザ モジュールの loader> プロンプトからの復旧

loader> プロンプトからの復旧

switch(boot)# プロンプトからの復旧

デュアル スーパーバイザ モジュール搭載スイッチの復旧

1 つのスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

スイッチまたはプロセスのリセット

回復可能なシステムの再起動

回復不能なシステムの再起動

管理パスワードの回復

インストール、アップグレード、および再起動のトラブルシューティング

この章では、Cisco NX-OS のインストール、アップグレード、または再起動時に発生する可能性のある問題を識別して解決する方法について説明します。

この章で説明する内容は、次のとおりです。

「概要」

「ガイドライン」

「Cisco NX-OS ソフトウェア インストールの確認」

「Cisco NX-OS ソフトウェアのアップグレードとダウングレードのトラブルシューティング」

「Cisco NX-OS ソフトウェア システム再起動のトラブルシューティング」

「管理パスワードの回復」

概要

Cisco NX-OS は、キックスタート イメージとシステム イメージの 2 つのイメージで構成されます。

インストール、アップグレード、および再起動は、ネットワーク メンテナンス活動の一部分で継続的に実施されます。これらの操作を実稼働環境で実行する際に継続中の動作が中断されるリスクを最小限に抑え、また何らかの問題が発生したときに素早く復旧させる方法を確認しておくことが重要です。


) 文書化の目的で、このマニュアルでは「アップグレード」という用語を使用します。ただし、アップグレードは、ユーザのニーズにより、スイッチのアップグレードとダウングレードの両方を意味しています。


ガイドライン

ここでは、Cisco NX-OS ソフトウェアのインストール、イメージのアップグレードとダウングレード、および再起動に関するガイドラインを示します。具体的な内容は、次のとおりです。

「インストールのガイドライン」

「アップグレードのガイドライン」

「再起動のガイドライン」

インストールのガイドライン

Cisco NX-OS ソフトウェア イメージをインストールする際は、次のガイドラインに従ってください。

サーバの可用性 -- FTP または TFTP サーバが利用できることを確認します。

互換性チェック -- show install all impact コマンドを使用して、新しいイメージが正常であること、および新規のロードがハードウェアの互換性に与える影響を確認します。互換性を調べてください。

アップグレードのガイドライン

次のチェックリストを使用して、アップグレードの準備を行ってください。

 

チェックリスト
確認済み

新しい Cisco NX-OS イメージを、bootflash: または slot0: にあるスーパーバイザ モジュールにコピーします。

 

実行コンフィギュレーションをスタートアップ コンフィギュレーションに保存します。

 

コンフィギュレーションのコピーをリモート TFTP サーバにバックアップします。

 

ネットワークに対するメンテナンスの適切な時間枠の中でアップグレードのスケジュールを確保します。

 

チェックリストの確認を終了すると、ネットワーク内のスイッチをアップグレードする準備は完了です。


) アップグレード中にアクティブ スーパーバイザはスタンバイ スーパーバイザになりますが、これは正常な動作です。


Cisco NX-OS ソフトウェア イメージをアップグレードまたはダウングレードする際は、次のガイドラインに従ってください。

アップグレードまたはダウングレードするリリースに対応する『 Cisco NX-OS Release Notes 』の内容を確認します。『 Cisco NX-OS Release Notes 』は、次の Web サイトから入手できます。

http://cisco.com/en/US/products/ps5989/prod_release_notes_list.html

FTP または TFTP サーバが利用できることを確認します。

スタートアップ コンフィギュレーションを NVRAM 内のスナップショット コンフィギュレーションにコピーします。このステップでは、スタートアップ コンフィギュレーションのコピーをバックアップします(『 Cisco NX-OS System Management Configuration Guide, Release 4.0 』の「Rollback」の章を参照してください)。

可能であれば、中断のないアップグレードの実行を選択します。

各スーパーバイザ コンソールへの PC シリアル接続を確立して、アップグレードの作業をファイルに記録します。このシリアル接続で、起動時のすべてのエラー メッセージまたは問題を受け取ります。

install all [{| kickstart | system} URL] コマンドを使用して、完了スクリプトの実行、イメージのテスト、およびハードウェアの互換性の確認を行います。詳細については、「Cisco NX-OS ソフトウェアのインストール」を参照してください。install all コマンドを使用すると、次の利点があります。

1 つのコマンドを使用するだけで、中断を最小限に抑えた手順を実行し、スイッチ全体をアップグレードできます。

コマンドを続行する前に、目的のシステム変更に関する説明情報を受け取れます。

コマンドを取り消すオプションがあります。コマンドの効果についての説明が表示されたあとに次の質問が表示されるので、続行または取り消しを選択できます(デフォルトは no)。

Do you want to continue (y/n) [n] :y
 

このコマンドの進捗状況は、コンソール、Telnet、および SSH の画面に表示できます。

稼働中のキックスタート イメージおよびシステム イメージを含むイメージの整合性は、自動的にチェックされます。

このコマンドでは、プラットフォームの妥当性検査を実行して、不正なイメージが使用されていないことを確認します。たとえば、デバイスのアップグレードに、誤って Cisco NX-OS イメージが使用されていないこと確認します。

install all コマンドを発行したあとに、シーケンス内でいずれかのステップが失敗すると、コマンドは進行中のステップを完了してから終了します。

再起動のガイドライン

Cisco NX-OS から実行できるシステム再起動には、次の 3 つの異なるタイプがあります。

回復可能 -- プロセスが再起動し、サービスには影響しません。

回復不能 -- プロセスの再起動回数が一定時間(秒)内に実行できる再起動の最大数を超えたために、プロセスの再起動を再実行できない場合に使用します。

システム停止またはクラッシュ -- システムとの通信が完全にできなくなった場合に使用します。

再起動のスケジュールは、重要な業務時間内にサービスが中断されないように設定してください。


) ログ メッセージは、システム再起動後には消去されています。ただし、重大度が critical 以上(レベル 0、1、および 2)のログ メッセージは、最大 100 個まで NVRAM に保存されます。このログは、show logging nvram CLI コマンドを使用していつでも表示できます。


Cisco NX-OS ソフトウェア インストールの確認

show install all status コマンドを使用して、ソフトウェアのインストールの進捗状況を監視できます。

また、show install all status CLI コマンドを使用すると、実行中の install all コマンドまたは最後に install all コマンドが実行されたときのログを、コンソール、SSH、または Telnet セッションから表示できます。

このコマンドでは、コンソール端末に接続していない場合でも、install all コマンドの出力がアクティブ スーパーバイザ モジュールおよびスタンバイ スーパーバイザ モジュールの両方に提供されます。ここでは、CLI から発行された install all コマンドのステータスだけを表示します。例2-1を参照してください。

例2-1 install all コマンドの出力

switch# show install all status
There is an on-going installation... <---------------------- in progress installation
Enter Ctrl-C to go back to the prompt.
Verifying image bootflash:/b-4.0.0.104
-- SUCCESS
Verifying image bootflash:/i-4.0.0.104
-- SUCCESS
Extracting “system” version from image bootflash:/i-4.0.0.104.
-- SUCCESS
Extracting “kickstart” version from image bootflash:/b-4.0.0.104.
-- SUCCESS
Extracting “loader” version from image bootflash:/b-4.0.0.104.
-- SUCCESS
switch# show install all status
This is the log of last installation. <----------------- log of last install
Verifying image bootflash:/b-4.0.0.104
-- SUCCESS
Verifying image bootflash:/i-4.0.0.104
-- SUCCESS
Extracting “system” version from image bootflash:/i-4.0.0.104.
-- SUCCESS
Extracting “kickstart” version from image bootflash:/b-4.0.0.104.
-- SUCCESS
Extracting “loader” version from image bootflash:/b-4.0.0.104.
-- SUCCESS
 

無停止アップグレードの確認

無停止アップグレードが開始されると、Cisco NX-OS はアップグレードが開始されようとしていることをすべてのサービスに通知し、アップグレードを進めることができるかどうかを調べます。アップグレードを続行できない場合、アップグレードは打ち切られます。そのような場合は、show install all failure-reason コマンドを入力して、アップグレードを続行できない理由を識別してください。

...
Do you want to continue with the installation (y/n)? [n] y
 
Install is in progress, please wait.
 
Notifying services about the upgrade.
[# ] 0% -- FAIL. Return code 0x401E0066 (request timed out).
 
Please issue "show install all failure-reason" to find the cause of the failure.<---system prompt to enter the show all failure-reason command.
 
Install has failed. Return code 0x401E0066 (request timed out).
Please identify the cause of the failure, and try 'install all' again.
 
switch# show install all failure-reason
Service: "cfs" failed to respond within the given time period.
switch#
 

何らかの理由(保存ランタイム状態障害やラインカード アップグレード障害など)で障害がある場合、アップグレードがすでに進行中のときには、変更をロールバックできないため、アップグレードの途中でスイッチが再起動されます。そのような場合、アップグレードは失敗します。show install all failure-reason コマンドの入力は求められません。このコマンドを入力しても有益な情報は得られません。

アップグレードに失敗した理由を判別する場合にサポートが必要な場合は、 show tech support コマンド出力から詳細を収集し、可能であればインストールからコンソール出力を収集します。

ROM モニタ モードの使用

ロードする有効なシステム イメージを検出できない場合、システムは ROM モニタ モードで起動します。ROM モニタ モードには、起動時に起動シーケンスを中断してアクセスすることもできます。ROM モニタ モードでは、デバイスの起動または診断テストを実行できます。

大半のシステムでは、 reload EXEC コマンドを入力してから、システム起動中の最初の 60 秒間に Break コマンドを発行すると、ROM モニタ モードを開始できます。Break コマンドを発行するには、キーボード上の Break キーを押すか、Break キーの組み合わせを使用します(デフォルトの Break キーの組み合わせは Ctrl+C です)。

Cisco NX-OS ソフトウェアのアップグレードとダウングレードのトラブルシューティング

ここでは、ソフトウェアのインストレーションへのアップグレードまたはダウングレードが失敗した場合に考えられる原因とその解決方法について説明します。

インストール時のソフトウェアのエラーによる終了

現象 ソフトウェアのインストールが、エラーにより終了する。

 

表2-1 ソフトウェアのインストールがエラーにより終了

問題
考えられる原因
解決方法

インストールがエラーにより終了する。

スタンバイ スーパーバイザ モジュールの bootflash: ファイルシステムに、更新されたイメージを格納する十分な領域がない。

delete コマンドを使用して、ファイルシステムから不要なファイルを削除します。

指定されたシステム イメージとキックスタート イメージの間に互換性がない。

インストール プロセスの出力を調べて、非互換性の詳細について確認します。システム イメージをアップデートする前に、キックスタート イメージをアップデートしている可能性があります。

install all コマンドが、スタンバイ スーパーバイザ モジュール上で発行された。

このコマンドをアクティブ スーパーバイザ モジュールだけで発行するようにします。

アップグレードの進行中にモジュールが装着された。

インストールを再実行します。詳細については、「Cisco NX-OS ソフトウェアのインストール」を参照してください。

アップグレードの進行中にスイッチの電源が停止した。

インストールを再実行します。「Cisco NX-OS ソフトウェアのインストール」を参照してください。

ソフトウェア イメージの指定されたパスが正しくない。

リモート ロケーションへのパス全体を正しく指定します。

別のインストール プロセスがすでに進行中である。

すべてのステージでスイッチの状態を確認し、10 秒間待機してからインストールを再び実行します。10 秒経過する前にインストール プロセスを再実行すると、コマンドは拒否され、インストールが現在進行していることを示すエラー メッセージが表示されます。

モジュールがアップグレードに失敗した。

インストールを再実行します。詳細については、「Cisco NX-OS ソフトウェアのインストール」を参照してください。

または、install module CLI コマンドを使用して失敗したモジュールをアップグレードします。

Cisco NX-OS ソフトウェアのインストール

スイッチ上のソフトウェアの自動アップグレードを CLI から実行する手順は次のとおりです。


ステップ 1 アクティブ スーパーバイザのコンソール、Telnet、または SSH ポートからスイッチにログインします。

ステップ 2 必要であれば、既存のコンフィギュレーション ファイルのバックアップを作成します。

ステップ 3 install all コマンドを発行して、アップグレードを実行します。

次の例は、SPC サーバにあるソース イメージを使用して、 install all コマンドでアップグレードする方法を示しています。


ヒント install all コマンドの互換性チェックの出力内容は、必ず慎重に確認してください。この互換性チェックでは、アップグレードが必要な対象(BIOS、ローダ、ファームウェア)および無停止アップグレードに対応していないモジュールが正確に示されます。出力の結果に対して何らかの疑問や懸念がある場合は、n を選択してインストールを停止し、次のレベルのサポートに連絡してください。

switch# install all system scp://testuser@tftp-server1/tftpboot/rel/qa/4.0/final/m95
00-sf1ek9-mz.4.0.bin kickstart scp://testuser@tftp-server1/tftpboot/rel/qa/4.0/fin
al/n7000-s1-kickstart-mz.4.0.bin
For scp://testuser@tftp-server1, please enter password:
For scp://testuser@tftp-server1, please enter password:
 
Copying image from scp://testuser@pal/tftpboot/rel/qa/4.0/final/n7000-s1
-kickstart-mz.4.0.bin to bootflash:///n7000-s1-kickstart-mz.4.0.bin.
[####################] 100% -- SUCCESS
 
Copying image from scp://testuser@pal/tftpboot/rel/qa/4.0/final/n7000-s1
-mz.4.0.bin to bootflash:///n7000-s1-mz.4.0.bin.
[####################] 100% -- SUCCESS
 
Verifying image bootflash:///n7000-s1-kickstart-mz.4.0.bin
[####################] 100% -- SUCCESS
 
Verifying image bootflash:///n7000-s1-mz.4.0.bin
[####################] 100% -- SUCCESS
 
Extracting "slc" version from image bootflash:///n7000-s1-mz.4.0.bin.
[####################] 100% -- SUCCESS
 
Extracting "ips" version from image bootflash:///n7000-s1-mz.4.0.bin.
[####################] 100% -- SUCCESS
 
Extracting "svclc" version from image bootflash:///n7000-s1-mz.4.0.bin.
[####################] 100% -- SUCCESS
 
Extracting "system" version from image bootflash:///n7000-s1-mz.4.0.bin.
[####################] 100% -- SUCCESS
 
Extracting "kickstart" version from image bootflash:///n7000-s1-kickstart-mz
.4.0.bin.
[####################] 100% -- SUCCESS
 
Extracting "loader" version from image bootflash:///n7000-s1-kickstart-mz.2.
1.1a.bin.
[####################] 100% -- SUCCESS
 
 
 
Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes non-disruptive rolling
2 yes non-disruptive rolling
3 yes disruptive rolling Hitless upgrade is not supported
4 yes disruptive rolling Hitless upgrade is not supported
5 yes non-disruptive reset
6 yes non-disruptive reset
 
 
 
Images will be upgraded according to following table:
Module Image Running-Version New-Version Upg-Required
------ ---------- -------------------- -------------------- ------------
1 slc 2.0(2b) 2.1(1a) yes
1 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
2 slc 2.0(2b) 2.1(1a) yes
2 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
3 ips 2.0(2b) 2.1(1a) yes
3 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
4 svclc 2.0(2b) 2.1(1a) yes
4 svcsb 1.3(5m) 1.3(5m) no
4 svcsb 1.3(5m) 1.3(5m) no
4 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
5 system 2.0(2b) 2.1(1a) yes
5 kickstart 2.0(2b) 2.1(1a) yes
5 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
5 loader 1.2(2) 1.2(2) no
6 system 2.0(2b) 2.1(1a) yes
6 kickstart 2.0(2b) 2.1(1a) yes
6 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
6 loader 1.2(2) 1.2(2) no
 
Do you want to continue with the installation (y/n)? [n] y
 
Install is in progress, please wait.
 
Syncing image bootflash:///n7000-s1-kickstart-mz.4.0.bin to standby.
[####################] 100% -- SUCCESS
 
Syncing image bootflash:///n7000-s1-mz.4.0.bin to standby.
[####################] 100% -- SUCCESS
 
Setting boot variables.
[####################] 100% -- SUCCESS
 
Performing configuration copy.
[####################] 100% -- SUCCESS
 
Module 5: Waiting for module online.
2005 May 20 15:46:03 ca-9506 %KERN-2-SYSTEM_MSG: mts: HA communication with standby terminated. Please check the standby supervisor.
-- SUCCESS
 
"Switching over onto standby".
 

ステップ 4 スイッチのコンソールを終了し、新規のターミナル セッションを開き、 show module コマンドを使用してアップグレードされたスーパーバイザ モジュールを表示します。

install all コマンドが発行されたときに、コンフィギュレーションがすべてのガイドラインに適合していれば、すべてのモジュール(スーパーバイザおよびスイッチング)がアップグレードされます。


 

Cisco NX-OS ソフトウェア システム再起動のトラブルシューティング

ここでは、ソフトウェアの再起動で発生する可能性のある問題とその解決方法について説明します。具体的な内容は、次のとおりです。

「電源投入時または再起動時におけるスイッチのハングアップ」

「破損したブートフラッシュの復旧」

「スーパーバイザ モジュールの loader> プロンプトからの復旧」

「loader> プロンプトからの復旧」

「switch(boot)# プロンプトからの復旧」

「デュアル スーパーバイザ モジュール搭載スイッチの復旧」

電源投入時または再起動時におけるスイッチのハングアップ

現象 電源投入時または再起動時にスイッチがハングアップする。

 

表2-2 電源投入時または再起動時におけるスイッチのハングアップ

問題
考えられる原因
解決方法

デュアル スーパーバイザ構成で、電源投入時または再起動時にスイッチがハングアップする。

ブートフラッシュが破損している。

詳細については、「デュアル スーパーバイザ モジュール搭載スイッチの復旧」を参照してください。

シングル スーパーバイザ構成で、電源投入時または再起動時にスイッチがハングアップする。

BIOS が破損している。

このモジュールを交換します。カスタマー サポート担当者に連絡して、故障したモジュールを返却してください。

キックスタート イメージが破損している。

>loader プロンプトで、起動プロセスを中断します。キックスタート イメージをアップデートします。詳細については、「スーパーバイザ モジュールの loader> プロンプトからの復旧」を参照してください。

起動パラメータが不正である。

起動パラメータを確認して修正し、スイッチを再起動します。

システム イメージが破損している。

switch#boot プロンプトで、起動プロセスを中断します。システム イメージをアップデートします。詳細については、「switch(boot)# プロンプトからの復旧」を参照してください。

破損したブートフラッシュの復旧

すべてのスイッチ コンフィギュレーションは、内蔵ブートフラッシュに格納されています。内蔵ブートフラッシュが破損すると、場合によってはコンフィギュレーションが失われることがあります。コンフィギュレーション ファイルを、定期的に保存およびバックアップしてください。通常、スイッチの起動は、次のシーケンスで行われます(図2-1 を参照)。

1. BIOS によって、ローダがロードされます。

2. ローダでは、キックスタート イメージを RAM にロードして起動します。

3. キックスタート イメージでは、システム イメージをロードして起動します。

4. システム イメージでは、スタートアップ コンフィギュレーション ファイルを読み込みます。

図2-1 通常の起動シーケンス

 

スイッチ上のイメージが破損しているために先に進めない場合は(エラー状態)、スイッチの起動シーケンスを中断して次の項で説明されている BIOS 設定ユーティリティに入ることにより、イメージを復旧できます。このユーティリティには、破損した内蔵ディスクを復旧する必要がある場合にだけアクセスしてください。


注意 ここで説明されている BIOS 設定の変更は、破損したブートフラッシュを復旧する場合にだけ必要になります。

復旧の手順では、通常のシーケンスを中断する必要があります。スイッチの内部シーケンスでは、スイッチの電源を投入してから端末に switch プロンプトが表示されるまでの間に、BIOS、ブート ローダ、キックスタート、およびシステムの 4 つのフェーズがあります( 表2-3 および図2-2 を参照)。

 

表2-3 復旧の割り込み

フェーズ
通常のプロンプト 1
復旧用のプロンプト 2
説明

BIOS

loader>

No bootable device

BIOS によって、電源投入時自己診断テスト、メモリ テスト、および他のオペレーティング システム アプリケーションが開始されます。BIOS 設定ユーティリティでネットブート オプションを使用するには、テストの進行中に Ctrl+C キーを押します。

ブート ローダ

Starting kickstart

loader>

ブート ローダでは、ロードされたソフトウェアの圧縮を解除し、そのファイル名を参照先として使用することでイメージを起動します。これらのイメージは、ブートフラッシュから起動できます。メモリ テストが完了したあとは、 Esc キーを押してブート ローダのプロンプトを開始します。

Kickstart

Uncompressing system

switch(boot)#

ブート ローダのフェーズが完了したあとは、 Ctrl+] 3 キーを押して(Ctrl キーと右角カッコ キーを同時に押す)、 switch(boot)# プロンプトを表示します。破損が原因でコンソールをこのプロンプトで停止させる場合は、システム イメージをコピーしてからスイッチを再起動します。

System

Login:

--

システム イメージでは、最後に保存された実行コンフィギュレーションのコンフィギュレーション ファイルをロードし、スイッチのログイン プロンプトに戻ります。

1.このプロンプトまたはメッセージは、各フェーズの最後に表示されます。

2.このプロンプトまたはメッセージは、スイッチが次のフェーズに進めないときに表示されます。

3.Telnet クライアントによっては、これらのキーが予約されていることがあるので、その場合はキーの割り当てを変更する必要があります。詳細については、Telnet クライアントに付属のマニュアルを参照してください。

図2-2 通常および復旧のシーケンス

 

スーパーバイザ モジュールの loader> プロンプトからの復旧


注意 この手順では、init system コマンドを使用しており、デバイスのファイル システムを再フォーマットします。この手順を開始する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。


loader> プロンプトは、通常の switch# プロンプトとは異なります。このプロンプトでは、CLI のコマンド補完機能は機能せず、不要なエラーの原因になることがあります。コマンドは、その全体を正確に入力する必要があります。



ヒント loader> プロンプトで使用できるコマンドのリストを表示したり、そのリストにある特定のコマンドに関する詳細な情報を取得したりするには、このプロンプトで help コマンドを実行してください。


シングル スーパーバイザ モジュール搭載スイッチで、破損したキックスタート イメージ(システム エラー状態)を復旧する手順は、次のとおりです。


ステップ 1 loader> プロンプトでスイッチのローカル IP アドレスを入力し、Enter キーを押します。

loader> net --ip=172.16.1.2
 

ステップ 2 サブネット マスクを指定します。

loader> net --nm= 255.255.255.0
 

ステップ 3 デフォルト ゲートウェイの IP アドレスを指定します。

loader> net --gw=172.16.1.1
 

ステップ 4 目的のサーバからキックスタート イメージ ファイルを起動します。

loader> boot tftp://172.16.10.100/n7000-s1-kickstart-4.0.bin

この例では、 172.16.10.100 が TFTP サーバの IP アドレスで、 n7000-sl-kickstart-3.0.bin がそのサーバに存在するキックスタート イメージ ファイル名です。

switch(boot)# プロンプトは、使用可能なキックスタート イメージがあることを示すものです。

ステップ 5 switch(boot)# プロンプトで、 init system コマンドを発行します。

switch(boot)# init system
 

注意 このコマンドを発行する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。

ステップ 6 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。


 

loader> プロンプトからの復旧


注意 この手順では、init system コマンドを使用しており、デバイスのファイル システムを再フォーマットします。この手順を開始する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。


loader> プロンプトは、通常の switch# プロンプトまたは switch(boot)# プロンプトとは異なります。このプロンプトでは、CLI のコマンド補完機能は機能せず、不要なエラーの原因になることがあります。コマンドは、その全体を正確に入力する必要があります。



ヒント loader> プロンプトで使用できるコマンドのリストを表示したり、そのリストにある特定のコマンドに関する詳細な情報を取得したりするには、このプロンプトで help コマンドを実行してください。


シングル スーパーバイザ モジュール搭載スイッチで、破損したキックスタート イメージ(システム エラー状態)を復旧する手順は、次のとおりです。


ステップ 1 loader> プロンプトでスイッチの IP アドレスおよびサブネット マスクを入力し、Enter キーを押します。

loader> ip address 172.16.1.2 255.255.255.0
Found Intel EtherExpressPro100 82559ER at 0xe800, ROM address 0xc000
Probing...[Intel EtherExpressPro100 82559ER]Ethernet addr: 00:05:30:00:52:27
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 0.0.0.0
 

ステップ 2 デフォルト ゲートウェイの IP アドレスを指定します。

loader> ip default-gateway 172.16.1.1
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 172.16.1.1
 

ステップ 3 目的のサーバからキックスタート イメージ ファイルを起動します。

loader> boot tftp://172.16.10.100/kickstart-image1
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 172.16.10.100
Gateway: 172.16.1.1
Booting: /kick-282 console=ttyS0,9600n8nn quiet loader_ver= “2.1(2)”....
............................................Image verification OK
Starting kernel...
INIT: version 2.78 booting
Checking all filesystems..... done.
Loading system software
INIT: Sending processes the TERM signal
Sending all processes the TERM signal... done.
Sending all processes the KILL signal... done.
Entering single-user mode...
INIT: Going single user
INIT: Sending processes the TERM signal
switch(boot)#
 

switch(boot)# プロンプトは、使用可能なキックスタート イメージがあることを示すものです。

ステップ 4 switch(boot)# プロンプトで、 init system コマンドを発行します。

switch(boot)# init system
 

注意 このコマンドを発行する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。

ステップ 5 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。


 

switch(boot)# プロンプトからの復旧

シングル スーパーバイザ モジュール搭載スイッチで、キックスタート イメージを使用してシステム イメージを復旧する手順は次のとおりです。


ステップ 1 設定モードへ移行し、mgmt0 インターフェイスの IP アドレスを設定します。

switch(boot)# config t
switch(boot)(config)# interface mgmt0
 

ステップ 2 init system コマンドを入力した場合は、このステップの手順に従います。それ以外の場合は、ステップ 3 に進みます。

a. ip address コマンドを入力して、スイッチのローカル IP アドレスおよびサブネット マスクを設定します。

switch(boot)(config-mgmt0)# ip address 172.16.1.2 255.255.255.0
 

b. ip default-gateway コマンドを入力して、デフォルト ゲートウェイの IP アドレスを設定します。

switch(boot)(config-mgmt0)# ip default-gateway 172.16.1.1
 

ステップ 3 no shutdown コマンドを入力して、スイッチ上の mgmt0 インターフェイスをイネーブルにします。

switch(boot)(config-mgmt0)# no shutdown
 

ステップ 4 end と入力して、EXEC モードに移行します。

switch(boot)(config-mgmt0)# end
 

ステップ 5 ファイル システムに問題があると考えられる場合は、 init system check-filesystem コマンドを入力します。このコマンドは、すべての内部ファイル システムを調べて、発見されたエラーをすべて修復します。処理が完了するまで長時間を要します。

switch(boot)# init system check-filesytem
 

ステップ 6 目的の TFTP サーバからシステム イメージをコピーします。

switch(boot)# copy tftp://172.16.10.100/system-image1 bootflash:system-image1
 

ステップ 7 目的の TFTP サーバからキックスタート イメージをコピーします。

switch(boot)# copy tftp://172.16.10.100/kickstart-image1 bootflash:kickstart-image1
 

ステップ 8 システム イメージ ファイルおよびキックスタート イメージ ファイルが bootflash: ファイル システムにコピーされたことを確認します。

switch(boot)# dir bootflash:
12456448 Jul 30 23:05:28 1980 kickstart-image1
12288 Jun 23 14:58:44 1980 lost+found/
27602159 Jul 30 23:05:16 1980 system-image1
 
Usage for bootflash://sup-local
135404544 bytes used
49155072 bytes free
184559616 bytes total
 

ステップ 9 システム イメージを bootflash: ファイル システムからロードします。

switch(boot)# load bootflash:system-image1
Uncompressing system image: bootflash:/system-image1
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
 
Would you like to enter the initial configuration mode? (yes/no): yes
 

no を入力した場合は、switch# ログイン プロンプトに戻るので、スイッチを手動で設定する必要があります。



 

デュアル スーパーバイザ モジュール搭載スイッチの復旧

ここでは、デュアル スーパーバイザ モジュール搭載スイッチの 1 つ または両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧手順について説明します。

1 つのスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

1 つのスーパーバイザ モジュールではブートフラッシュが機能し、またもう 1 つのスーパーバイザ モジュールではブートフラッシュが破損している場合の復旧手順は、次のとおりです。


ステップ 1 機能しているスーパーバイザ モジュールを起動し、スイッチにログインします。

ステップ 2 起動したスーパーバイザ モジュールの switch# プロンプトで、 reload module slot force-dnld コマンドを発行します。 slot は、破損したブートフラッシュがあるスーパーバイザ モジュールのスロット番号です。

破損したブートフラッシュがあるスーパーバイザ モジュールでは、ネットブートを実行し、ブートフラッシュの破損をチェックします。起動スクリプトによってブートフラッシュの破損が検出されると、スクリプトは、破損したブートフラッシュを修復する init system コマンド を生成します。スーパーバイザ モジュールは、HA Standby 状態で起動します。


注意 システムでアクティブ スーパーバイザ モジュールが正常に稼働している場合は、内蔵 bootflash: が破損するのを防止するために、スタンバイ スーパーバイザ モジュール上で init system コマンドを発行する前に、アクティブ スーパーバイザ モジュール上で system standby manual-boot コマンドを EXEC モードで発行する必要があります。スタンバイ スーパーバイザ モジュール上で init system コマンドが完了したあとは、アクティブ スーパーバイザ モジュール上で system no standby manual-boot コマンドを EXEC モードで発行します。


 

両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧手順は、次のとおりです。


ステップ 1 両方のスイッチを起動し、BIOS メモリ テストの完了後に Esc キーを押して、ブート ローダを中断します。


) 次のメッセージが表示されたら、すぐに Esc キーを押してください。
00000589K Low Memory Passed
00000000K Ext Memory Passed
Hit ^C if you want to run SETUP....
Wait.....
待機時間が長くなるようであれば、ブート ローダ フェーズを省略してキックスタート フェーズに入ります。


loader> プロンプトが表示されます。


注意 loader> プロンプトは、通常の switch# プロンプトまたは switch(boot)# プロンプトとは異なります。このプロンプトでは、CLI のコマンド補完機能は機能せず、不要なエラーの原因になることがあります。コマンドは、その全体を正確に入力する必要があります。

ヒント loader> プロンプトで使用できるコマンドのリストを表示したり、そのリストにある特定のコマンドに関する詳細な情報を取得したりするには、このプロンプトで help コマンドを実行してください。

ステップ 2 スイッチのローカル IP アドレスおよびサブネット マスクを指定します。

loader> ip address 172.16.1.2 255.255.255.0
Found Intel EtherExpressPro100 82559ER at 0xe800, ROM address 0xc000
Probing...[Intel EtherExpressPro100 82559ER]Ethernet addr: 00:05:30:00:52:27
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 0.0.0.0
 

ステップ 3 デフォルト ゲートウェイの IP アドレスを指定します。

loader> ip default-gateway 172.16.1.1
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 172.16.1.1
 

ステップ 4 目的のサーバからキックスタート イメージ ファイルを起動します。

loader> boot tftp://172.16.10.100/kickstart-latest
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 172.16.10.100
Gateway: 172.16.1.1
Booting: /kick-282 console=ttyS0,9600n8nn quiet loader_ver= “2.1(2)”....
............................................Image verification OK
Starting kernel...
INIT: version 2.78 booting
Checking all filesystems..... done.
Loading system software
INIT: Sending processes the TERM signal
Sending all processes the TERM signal... done.
Sending all processes the KILL signal... done.
Entering single-user mode...
INIT: Going single user
INIT: Sending processes the TERM signal
switch(boot)#
 

switch(boot)# プロンプトは、使用可能なキックスタート イメージがあることを示すものです。

ステップ 5 init system コマンドを発行し、ブートフラッシュのパーティションを再作成してフォーマットします。

ステップ 6 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。

ステップ 7 「1 つのスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧」で指示されている手順を実行して、もう 1 つのスーパーバイザ モジュールを復旧します。


 


) 起動が失敗したときに reload module コマンドを発行しなかった場合、失敗後の 3 ~ 6 分以内に、スーパーバイザ モジュールはスタンバイ スーパーバイザ モジュールを自動的にリロードします。


スイッチまたはプロセスのリセット

回復可能または回復不可能なエラーが発生すると、スイッチまたはスイッチ上のプロセスはリセットされることがあります。

現象 スイッチまたはスイッチ上のプロセスがリセットされる。

 

表2-4 スイッチまたはプロセスのリセット

問題
考えられる原因
解決方法

スイッチまたはスイッチ上のプロセスがリセットされる。

システムまたはシステム内のプロセスで、回復可能なエラーが発生した。

Cisco NX-OS では、このエラーから自動的に回復します。「回復可能なシステムの再起動」および「スイッチまたはプロセスのリセット」を参照してください。

システム上で回復不可能なエラーが発生した。

Cisco NX-OS では、このエラーから自動的に回復することはできません。原因の判別については、「回復不能なシステムの再起動」 を確認してください。

クロック モジュールが故障している。

クロック モジュールが故障しているかどうかを確認します。次のメンテナンス ウィンドウ内で、故障したクロック モジュールを交換します。

回復可能なシステムの再起動

プロセスが再起動すると、常に Syslog メッセージおよび Call Home イベントが生成されます。イベントがサービスに影響していない場合でも、以後の再起動によってサービスが中断される可能性があるので、ただちに状態を確認して解決してください。

回復可能なシステムの再起動時には、次の手順で対応してください。


ステップ 1 次のコマンドを入力して Syslog ファイルを調べ、再起動したプロセスとその原因を確認します。

switch# show log logfile | include error
 

各メッセージの内容の詳細については、『 Cisco NX-OS Family System Messages Reference 』を参照してください。

次に、システムの出力例を示します。

Sep 10 23:31:31 dot-6 % LOG_SYSMGR-3-SERVICE_TERMINATED: Service "sensor" (PID 704) has finished with error code SYSMGR_EXITCODE_SY.
switch# show logging logfile | include fail
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 0.0.0.0, in_classd=0 flags=1 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 127.0.0.1, in_classd=0 flags=0 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 127.1.1.1, in_classd=0 flags=1 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 172.22.93.88, in_classd=0 flags=1 fails: Address already in use
Jan 27 23:18:59 88 % LOG_PORT-5-IF_DOWN: Interface fc1/13 is down (Link failure
or not-connected)
Jan 27 23:18:59 88 % LOG_PORT-5-IF_DOWN: Interface fc1/14 is down (Link failure
or not-connected)
Jan 28 00:55:12 88 % LOG_PORT-5-IF_DOWN: Interface fc1/1 is down (Link failure o
r not-connected)
Jan 28 00:58:06 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 28 00:58:44 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 28 03:26:38 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 29 19:01:34 88 % LOG_PORT-5-IF_DOWN: Interface fc1/1 is down (Link failure o
r not-connected)
switch#
 

ステップ 2 次のコマンドを入力して、実行中のプロセスおよび各プロセスのステータスを確認します。

switch# show processes
 

システム出力では、各状態(プロセス状態)が次のコードで示されます。

D = 中断なしで休止(通常 I/O)

R = 実行可能(実行キュー上)

S = 休止中

T = 追跡または停止

Z = 存在しない(ゾンビ)プロセス

NR = 実行されていない

ER = 実行されているべきだが、現在は実行されていない


) ER は通常、再起動回数が多すぎたためにシステムにより障害とみなされ、ディセーブルにされたプロセスの状態です。


次に、システムの出力例を示します(出力は簡略化するために短縮されています)。

PID State PC Start_cnt TTY Process
----- ----- -------- ----------- ---- -------------
1 S 2ab8e33e 1 - init
2 S 0 1 - keventd
3 S 0 1 - ksoftirqd_CPU0
4 S 0 1 - kswapd
5 S 0 1 - bdflush
6 S 0 1 - kupdated
71 S 0 1 - kjournald
136 S 0 1 - kjournald
140 S 0 1 - kjournald
431 S 2abe333e 1 - httpd
443 S 2abfd33e 1 - xinetd
446 S 2ac1e33e 1 - sysmgr
452 S 2abe91a2 1 - httpd
453 S 2abe91a2 1 - httpd
456 S 2ac73419 1 S0 vsh
469 S 2abe91a2 1 - httpd
470 S 2abe91a2 1 - httpd
 

ステップ 3 次のコマンドを入力して、異常終了したプロセスを表示し、スタックトレースまたはコア ダンプが実行されているかどうかを確認します。

switch# show process log
Process PID Normal-exit Stack-trace Core Log-create-time
---------------- ------ ----------- ----------- ------- ---------------
ntp 919 N N N Jan 27 04:08
snsm 972 N Y N Jan 24 20:50
 

ステップ 4 次のコマンドを入力して、再起動した特定プロセスの詳細情報を表示します。

switch# show processes log pid 898
Service: idehsd
Description: ide hotswap handler Daemon
Started at Mon Sep 16 14:56:04 2002 (390923 us)
Stopped at Thu Sep 19 14:18:42 2002 (639239 us)
Uptime: 2 days 23 hours 22 minutes 22 seconds
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGTERM (3)
Exit code: signal 15 (no core)
CWD: /var/sysmgr/work
Virtual Memory:
CODE 08048000 - 0804D660
DATA 0804E660 - 0804E824
BRK 0804E9A0 - 08050000
STACK 7FFFFD10
Register Set:
EBX 00000003 ECX 0804E994 EDX 00000008
ESI 00000005 EDI 7FFFFC9C EBP 7FFFFCAC
EAX 00000008 XDS 0000002B XES 0000002B
EAX 00000003 (orig) EIP 2ABF5EF4 XCS 00000023
EFL 00000246 ESP 7FFFFC5C XSS 0000002B
Stack: 128 bytes. ESP 7FFFFC5C, TOP 7FFFFD10
0x7FFFFC5C: 0804F990 0804C416 00000003 0804E994 ................
0x7FFFFC6C: 00000008 0804BF95 2AC451E0 2AAC24A4 .........Q.*.$.*
0x7FFFFC7C: 7FFFFD14 2AC2C581 0804E6BC 7FFFFCA8 .......*........
0x7FFFFC8C: 7FFFFC94 00000003 00000001 00000003 ................
0x7FFFFC9C: 00000001 00000000 00000068 00000000 ........h.......
0x7FFFFCAC: 7FFFFCE8 2AB4F819 00000001 7FFFFD14 .......*........
0x7FFFFCBC: 7FFFFD1C 0804C470 00000000 7FFFFCE8 ....p...........
0x7FFFFCCC: 2AB4F7E9 2AAC1F00 00000001 08048A2C ...*...*....,...
PID: 898
SAP: 0
UUID: 0
switch#
 

ステップ 5 次のコマンドを入力して、再起動の発生時刻を確認します。

switch# show system uptime
Start Time: Fri Sep 13 12:38:39 2002
Up Time: 0 days, 1 hours, 16 minutes, 22 seconds
 

各再起動のタイムスタンプとシステムのアップタイムの長さを比較して、再起動が繰り返し行われているのか、または 1 回限りなのかを判別してください。

ステップ 6 次のコマンドを入力して、コア ファイルを表示します。

switch# show cores
Module-num Process-name PID Core-create-time
---------- ------------ --- ----------------
5 fspf 1524 Jan 9 03:11
6 fcc 919 Jan 9 03:09
8 acltcam 285 Jan 9 03:09
8 fib 283 Jan 9 03:08
 

この出力には、アクティブ スーパーバイザから現在アップロードできるすべてのコアが表示されます。module-num カラムは、コアが生成されたスロットの番号を示しています。前記の例では、スロット 5 のアクティブ スーパーバイザ モジュールで FSPF コアが生成され、スロット 6 のスタンバイ スーパーバイザ モジュールで FCC コアが生成されています。また、スロット 8 のラインカードで、ACLTCAM および FIB を含むコア ダンプが生成されています。

この例の FSPF コア ダンプを IP アドレスが 1.1.1.1 の TFTP サーバにコピーするには、次のコマンドを入力します。

switch# copy core://5/1524 tftp::/1.1.1.1/abcd
 

次のコマンドでは、 log ディレクトリにある zone_server_log.889 という名前のファイルが表示されます。

switch# show pro log pid 1473
======================================================
Service: ips
Description: IPS Manager
 
Started at Tue Jan 8 17:07:42 1980 (757583 us)
Stopped at Thu Jan 10 06:16:45 1980 (83451 us)
Uptime: 1 days 13 hours 9 minutes 9 seconds
 
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Exit code: signal 6 (core dumped)
CWD: /var/sysmgr/work
 
Virtual Memory:
 
CODE 08048000 - 080FB060
DATA 080FC060 - 080FCBA8
BRK 081795C0 - 081EC000
STACK 7FFFFCF0
TOTAL 20952 KB
 
Register Set:
 
EBX 000005C1 ECX 00000006 EDX 2AD721E0
ESI 2AD701A8 EDI 08109308 EBP 7FFFF2EC
EAX 00000000 XDS 0000002B XES 0000002B
EAX 00000025 (orig) EIP 2AC8CC71 XCS 00000023
EFL 00000207 ESP 7FFFF2C0 XSS 0000002B
 
Stack: 2608 bytes. ESP 7FFFF2C0, TOP 7FFFFCF0
 
0x7FFFF2C0: 2AC8C944 000005C1 00000006 2AC735E2 D..*.........5.*
0x7FFFF2D0: 2AC8C92C 2AD721E0 2AAB76F0 00000000 ,..*.!.*.v.*....
0x7FFFF2E0: 7FFFF320 2AC8C920 2AC513F8 7FFFF42C ... ..*...*,...
0x7FFFF2F0: 2AC8E0BB 00000006 7FFFF320 00000000 ...*.... .......
0x7FFFF300: 2AC8DFF8 2AD721E0 08109308 2AC65AFC ...*.!.*.....Z.*
0x7FFFF310: 00000393 2AC6A49C 2AC621CC 2AC513F8 .......*.!.*...*
0x7FFFF320: 00000020 00000000 00000000 00000000 ...............
0x7FFFF330: 00000000 00000000 00000000 00000000 ................
0x7FFFF340: 00000000 00000000 00000000 00000000 ................
0x7FFFF350: 00000000 00000000 00000000 00000000 ................
0x7FFFF360: 00000000 00000000 00000000 00000000 ................
0x7FFFF370: 00000000 00000000 00000000 00000000 ................
0x7FFFF380: 00000000 00000000 00000000 00000000 ................
0x7FFFF390: 00000000 00000000 00000000 00000000 ................
0x7FFFF3A0: 00000002 7FFFF3F4 2AAB752D 2AC5154C .
(テキスト出力は省略)
Stack: 128 bytes. ESP 7FFFF830, TOP 7FFFFCD0
 

ステップ 7 次のコマンドを入力し、スイッチから TFTP を使用して、TFTP サーバにコア ダンプを送信します。

system cores tftp: [ // servername ][ / path ]

 

このコマンドにより、スイッチに TFTP サーバへのコア ファイルの自動コピーが設定されます。たとえば、IP アドレスが 10.1.1.1 の TFTP サーバにコア ファイルを送信するには、次のコマンドを使用します。

switch(config)# system cores tftp://10.1.1.1/cores
 

次の条件が適用されます。

コア ファイルは 4 分ごとにコピーされます。この間隔は変更できません。

TFTP サーバへの特定のコア ファイルのコピーは手動でトリガーすることが可能です。次のコマンドを使用します。 copy core:// module# / pid# tftp:// tftp_ip_address / file_name

プロセス再起動回数の最大値は、プロセスの HA ポリシーに含まれています(このパラメータは変更できません)。プロセスが最大値を超えて再起動されると、古いコア ファイルが上書きされます。

プロセスで保存可能な最大コア ファイル数は、プロセスの HA ポリシーに含まれています(このパラメータは変更できず、3 に設定されています)。

ステップ 8 カスタマー サポート 担当者に連絡してコア ダンプの検査を依頼し、再起動の原因と解決方法を判別します。


 

回復不能なシステムの再起動

回復不能なシステムの再起動は、次の条件で発生することがあります。

重要なプロセスが失敗したために、再起動ができない場合

プロセス再起動がシステム設定で許可されているよりも多く行われている場合

プロセス再起動の回数がシステム設定の最大値を超えている場合

プロセス再起動の影響は、各プロセスに設定されたポリシーによって異なります。回復不能な再起動は、機能の喪失、アクティブ スーパーバイザの再起動、スーパーバイザのスイッチオーバー、またはスイッチの再起動の原因になります。

回復不能な再起動への対応については、「Cisco NX-OS ソフトウェア システム再起動のトラブルシューティング」を参照してください。

show system reset-reason CLI コマンドを使用すると、次の情報が表示されます。

スーパーバイザ モジュールに対して直近の 4 つのリセット原因コードが表示されます。いずれかのスロットにスーパーバイザ モジュールが装着されていない場合は、そのモジュールに対応するリセット原因コードは表示されません。

show system reset-reason module number コマンドを使用すると、指定したスロットにある特定のモジュールに対して、直近の 4 つのリセット原因コードが表示されます。スロットにスーパーバイザ モジュールが装着されていない場合、モジュールのリセット原因コードは表示されません。

予期されたリロードおよび予期されないリロードが発生した時期と理由の履歴をすべて検索します。

リセットまたはリロードが発生したときのタイムスタンプが表示されます。

モジュールのリセットまたはリロードの理由が表示されます。

リセットまたはリロードの原因になったサービスが表示されます(表示されない場合もあります)。

リセットまたはリロードが発生したときに稼働していたソフトウェアのバージョンが表示されます。

例2-2 show system reason-reset コマンドの出力

switch# show system reset-reason module 5
----- reset reason for module 5 -----
1) At 224801 usecs after Fri Jan 21 16:36:40 2005
Reason: Reset Requested by CLI command reload
Service:
Version: 2.1(2)
2) At 922828 usecs after Fri Jan 21 16:02:48 2005
Reason: Reset Requested by CLI command reload
Service:
Version: 2.1(2)
3) At 318034 usecs after Fri Jan 21 14:03:36 2005
Reason: Reset Requested by CLI command reload
Service:
Version:2.1(2)
4) At 255842 usecs after Wed Jan 19 00:07:49 2005
Reason: Reset Requested by CLI command reload
Service:
Version: 2.1(2)
 

管理パスワードの回復

管理パスワードを忘れてしまった場合は、 表2-5 の説明に従ってスイッチにアクセスすることができます。

現象 スイッチにアクセスするための管理パスワードを忘れた。

 

表2-5 管理者パスワードの回復

問題
解決方法

Cisco NX-OS にアクセスするための管理パスワードを忘れた。

パスワードは、ローカル コンソール接続を使用して回復できます。

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

http://www.cisco.com/en/US/products/hw/ps4159/ps4358/prod_password_recoveries_list.html