Cisco NX-OS トラブルシューティング ガイド Release 4.0

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

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

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

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

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

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

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

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

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）。

–このコマンドの進捗状況は、コンソール、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 failure-reason コマンドを入力して、アップグレードを続行できない理由を識別してください。

何らかの理由（保存ランタイム状態障害やラインカード アップグレード障害など）で障害がある場合、アップグレードがすでに進行中のときには、変更をロールバックできないため、アップグレードの途中でスイッチが再起動されます。そのような場合、アップグレードは失敗します。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 ソフトウェアのインストール

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• D = 中断なしで休止（通常 I/O）

• R = 実行可能（実行キュー上）

• S = 休止中

• T = 追跡または停止

• Z = 存在しない（ゾンビ）プロセス

• NR = 実行されていない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• コア ファイルは 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 コマンドの出力