Cisco MDS 9000 ファミリー トラブルシューティング ガイド Release 3.x
ハードウェアのトラブルシューティング
ハードウェアのトラブルシューティング
発行日;2012/01/13 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

ハードウェアのトラブルシューティング

概要

SNMP トラップ

ベスト プラクティス

スイッチの設置に関するベスト プラクティス

システムの初期化に関するベスト プラクティス

スーパーバイザ モジュールに関するベスト プラクティス

起動時の問題のトラブルシューティング

電源装置の問題のトラブルシューティング

電源装置の LED がすべて消灯

電源装置の INPUT OK LED がレッドで点灯

電源装置の OUTPUT FAIL LED が点灯

電源装置の FAN OK LED がレッドで点灯

電源装置のトラブルシューティング

ファンの問題のトラブルシューティング

ファンが回転しない

ファンは回転しているが FAN LED がレッドで点灯

Device Manager によるファンの問題のトラブルシューティング

CLI によるファンの問題のトラブルシューティング

温度しきい値超過

クロック モジュールの問題のトラブルシューティング

ハードウェアの他の問題に対するトラブルシューティング

スーパーバイザの問題のトラブルシューティング

アクティブ スーパーバイザが再起動

スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない

スタンバイ スーパーバイザの同期の失敗を CLI から確認

スタンバイ スーパーバイザが電源投入ステートで停止

スタンバイ スーパーバイザが電源投入ステートであることを Device Manager から確認

スタンバイ スーパーバイザが電源投入ステートであることを CLI から確認

スーパーバイザ モジュールのトラブルシューティング

スイッチング モジュールおよびサービス モジュールのトラブルシューティング

モジュール ステータスの概要

モジュールの初期化の概要

モジュールの起動

イメージのダウンロード

実行時診断

実行時コンフィギュレーション

オンラインおよび動作中

ログの分析

モジュールの問題のトラブルシューティング

電源が切断されるモジュールのトラブルシューティング

電源が切断されるモジュールの診断

リロードされるモジュールのトラブルシューティング

リロードされるモジュールの診断

未知の状態になったモジュールのトラブルシューティング

未知の状態になっているモジュールの診断

スーパーバイザによって検出されないモジュールのトラブルシューティング

スーパーバイザによって検出されないモジュールの診断

障害が発生したモジュールの Fabric Manager による再初期化

障害が発生したモジュールの CLI による再初期化

モジュールのリセット

ハードウェアのトラブルシューティング

この章では、Cisco MDS 9000 ファミリのハードウェア コンポーネントで発生する可能性がある問題を識別して解決する方法について説明しています。この章で説明する内容は、次のとおりです。

「概要」

「ベスト プラクティス」

「起動時の問題のトラブルシューティング」

「電源装置の問題のトラブルシューティング」

「ファンの問題のトラブルシューティング」

「温度しきい値超過」

「クロック モジュールの問題のトラブルシューティング」

「ハードウェアの他の問題に対するトラブルシューティング」

「スーパーバイザの問題のトラブルシューティング」

「スイッチング モジュールおよびサービス モジュールのトラブルシューティング」

概要

システム ハードウェアのトラブルシューティングでは、問題のあるシステム コンポーネントを特定することが重要です。まず最初に、システムの現在の状態と、本来あるべき状態とを比較します。起動時に発生する問題の多くは 1 つのコンポーネントが原因となっているので、システムの各コンポーネントを個別にトラブルシューティングするよりも、サブシステム単位で問題を特定する方が効率的です。

初回起動時の問題の多くは、モジュールがバックプレーンに正しく接続されていない、電源装置に電源コードが接続されていないなどの原因によって発生します。

また、過熱が原因でシステムに障害が起きることもありますが、通常は、システムをかなり長時間にわたって稼働し続けた場合だけです。過熱の原因として最も多いのは、ファン モジュールの故障です。

Cisco MDS 9000 ファミリは、ほとんどのシャーシ上にある次のサブシステムで構成されています。

電源装置 ― 電源用ファンが内蔵されています。

ファン モジュール ― システムの電源がオンになっているときは、シャーシのファン モジュールが常に動作している必要があります。ファンが動作しているかどうかを判別するには、FAN LED がグリーンで点灯し、動作音が聞こえることを確認します。FAN LED がレッドの場合は、ファン モジュールにある 1 つまたは複数のファンが動作していません。ただちにテクニカル サポート担当者に連絡してください( TAC へ問い合わせる前に実行する手順を参照)。初回起動時にファン モジュールが正常に動作しない場合、ユーザ側で調整することはできません。


) シスコのサポートをシスコのリセラーからご購入された場合は、リセラーに直接お問い合わせください。サポートをシスコシステムズから直接購入されている場合には、シスコ テクニカル サポートに次の Web サイトからお問い合わせください。
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtm


スーパーバイザ モジュール ― スーパーバイザ モジュールにはシステム オペレーティング ソフトウェアが組み込まれているので、システム ソフトウェアに問題がある場合は、スーパーバイザ モジュールを調べます。スーパーバイザ モジュールのステータス LED を調べ、スーパーバイザ モジュールでスイッチング モジュールまたはサービス モジュールを初期化できるかどうかを確認します。

冗長スーパーバイザ モジュールを搭載している場合は、冗長スーパーバイザ モジュールをオンラインにする方法およびソフトウェア イメージの取り扱い方法について、次の Web サイトにある最新の『 Cisco MDS 9000 Family Configuration Guide 』で確認してください。
http://www.cisco.com/univercd/cc/td/doc/product/sn5000/mds9000/index.htm

スイッチング モジュールまたはサービス モジュール ― 各モジュールの STATUS LED を調べ、スーパーバイザ モジュールによって初期化されているかどうかを確認します。モジュールがバックプレーンに完全に装着されていないことが原因で、システムが停止することがあります。

SNMP トラップ

本稼働している SAN に悪影響を与えることなく、ファン、電源、温度設定をモニタしたり Call Home アプリケーションをテストするように、SNMP トラップを設定できます。

以下のコマンドを使用して SNMP トラップを設定します。

test pfm test-SNMP-trap fan

test pfm test-SNMP-trap powersupply

test pfm test-SNMP-trap temp-sensor


) これらのトラップを生成するためにファンや電源装置を物理的に取り外したり温度を物理的に上昇させたりする必要はありません。


ベスト プラクティス

スイッチの設置、初期化、および運用を正しく行うには、ここで推奨されているベスト プラクティス について検討する必要があります。ここで説明する内容は、次のとおりです。

「スイッチの設置に関するベスト プラクティス」

「システムの初期化に関するベスト プラクティス」

「スーパーバイザ モジュールに関するベスト プラクティス」

スイッチの設置に関するベスト プラクティス

スイッチを設置する際には、次のベスト プラクティスに従います。

シャーシを設置する前に、設置場所の構成を検討して準備を整えます。

計画しているシャーシ構成に適した電源装置があることを確認します。

Cisco MDS 9000 ファミリ シャーシ用の ハードウェア インストレーション ガイドに記載されているラックおよびエアーフローのガイドラインに従って、シャーシを設置します。

シャーシが適切にアースされていることを確認します。

システムの初期化に関するベスト プラクティス

初回のシステム起動が完了したあとは、次のことを確認してください。

電源装置がシステムに電力を供給していることを確認します。詳細については、「電源装置の問題のトラブルシューティング」を参照してください。

システムのファン モジュールが動作していることを確認します。詳細については、「ファンの問題のトラブルシューティング」を参照してください。

システム ソフトウェアが正常に起動したことを確認します。システムの起動および初期設定作業については、次の Web サイトで Cisco MDS 9000 ファミリの最新のコンフィギュレーション ガイドを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/sn5000/mds9000/index.htm .

スーパーバイザ モジュールおよびすべてのスイッチング モジュールやサービス モジュールが正しく取り付けられ、各モジュールが問題なく初期化されていることを確認します。詳細については、「スーパーバイザの問題のトラブルシューティング」を参照してください。

これらの条件がすべて満たされて、ハードウェアの設置が完了した場合は、このマニュアルにある他の部分の説明を参照して、ソフトウェアに関する他の問題のトラブルシューティングを行ってください。

いずれかの条件が満たされていない場合には、この章で説明されている手順に従って問題を特定し、可能であればその問題を解決してください。

スーパーバイザ モジュールに関するベスト プラクティス

スーパーバイザ モジュールを正しく動作させるためのベスト プラクティスとして、次の操作を実施することを推奨します。

両方のスーパーバイザのフラッシュ メモリに、同じバージョンのキックスタート イメージおよびシステム イメージがロードされていることを確認してください。

同じコードを実行するために、アクティブ スーパーバイザおよびスタンバイ スーパーバイザに適切なブート ステートメントが設定されていることを確認してください。

アクティブ スーパーバイザ上でブート ステートメントが設定されたあとに、
copy running-config startup-config コマンド を発行してください。

安全なバックアップのため、実行コンフィギュレーションをコンパクト フラッシュにコピーしてください。

実行コンフィギュレーションを変更したあとは、必ず copy running-config startup-config CLI コマンドを発行して、システムが正しく動作していることを確認してください。

実行コンフィギュレーションとスタートアップ コンフィギュレーションおよび bootflash: に保管されているファイルがすべて消去されることに同意するまでは、init system CLI コマンドを使用しないでください。

実行中のキックスタート イメージおよびシステム イメージを、常にコンパクトフラッシュにバックアップしてください。

起動時の問題のトラブルシューティング

起動シーケンスにおけるシステム状態は、すべて LED によって表示されます。LED を確認すれば、起動シーケンスのどの時点で、どこにシステム障害が発生したかを判別できます。

起動時の問題を特定する手順は、次のとおりです。


ステップ 1 電源スイッチをオン(|)の位置にして、電源装置をオンにします。すぐに、システムのファン モジュールの動作音が聞こえるはずです。聞こえない場合は、「電源装置の問題のトラブルシューティング」を参照してください。

ステップ 2 電源装置が正常に動作しても、ファン モジュールが故障していると考えられる場合は、「ファンの問題のトラブルシューティング」を参照してください。

ステップ 3 スーパーバイザ モジュールの LED が次の状態であることを確認します。

a. STATUS LED はオレンジで 1 回点滅し、起動時診断テストの間はオレンジで点灯します。モジュールが動作可能(オンライン)になると、LED はグリーンになります。システム ソフトウェアが起動しない場合、この LED はオレンジのままです。

b. SYSTEM LED がグリーンで点灯します。この場合、シャーシのすべての環境モニタは、システムが動作可能であることを報告しています。1 つまたは複数の環境モニタから問題が報告されると、SYSTEM LED はオレンジまたはレッドになります。

c. ACTIVE LED がグリーンで点灯します。この場合、スーパーバイザ モジュールは動作可能でアクティブです。スーパーバイザ モジュールがスタンバイ モードになっていると、ACTIVE LED はオレンジになります。

d. 各 LINK LED はオレンジで 1 回点滅して、起動時診断テストの間はオレンジで点灯し、モジュールが動作可能(オンライン)になるとグリーンで点灯します。信号が検出されなければ、LINK LED は消灯したままになります。ポートに障害があると、LINK LED はオレンジで点滅します。

初期化が完了しても、スーパーバイザ モジュール前面パネルにあるいずれかの LED がレッドまたはオレンジの場合には、「スーパーバイザの問題のトラブルシューティング」を参照してください。冗長スーパーバイザ モジュールを搭載している場合は、スーパーバイザ モジュールにある LED の説明、冗長スーパーバイザ モジュールをオンラインにする方法、およびソフトウェア イメージの取り扱い方法について、次の Web サイトにある最新の『 Cisco MDS 9000 Family Configuration Guide 』で確認してください。

http://www.cisco.com/univercd/cc/td/doc/product/sn5000/mds9000/index.htm

ステップ 4 スーパーバイザ モジュールの初期化完了後、スーパーバイザ モジュールおよび各スイッチング モジュールやサービス モジュールの STATUS LED がグリーンで点灯していることを確認します。この LED では、モジュールに電力が供給されていること、モジュールがスーパーバイザ モジュールによって認識されていること、およびモジュールが有効なバージョンのフラッシュ コードを含んでいることが示されます。この LED では、スイッチング モジュール上にある各インターフェイスの状態は示されません。STATUS LED がレッドまたはオレンジの場合は、「スーパーバイザの問題のトラブルシューティング」を参照してください。

ステップ 5 起動情報およびシステム バナーが表示されない場合には、端末が正しく設定され、スーパーバイザ モジュールのコンソール ポートに正しく接続されていることを確認します。


 

電源装置の問題のトラブルシューティング

ここでは、電源装置の問題について説明します。具体的な内容は、次のとおりです。

「電源装置の LED がすべて消灯」

「電源装置の INPUT OK LED がレッドで点灯」

「電源装置の OUTPUT FAIL LED が点灯」

「電源装置の FAN OK LED がレッドで点灯」

電源装置の LED がすべて消灯

現象 電源装置の LED が すべて消灯した状態になっている。

この症状が発生すると、次のシステム メッセージが生成されます。

エラー メッセージ PLATFORM-2-PS_FAIL: Power supply [dec] failed or shutdown (Serial No. [chars]).

説明 電源装置は故障しているか、またはすでにシャットダウンされています。

推奨処置 show environment power および show platform internal info CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。電源装置の容量を増減する方法、および電源装置を構成する方法の詳細については、関連するハードウェアのインストレーション ガイドにある電源装置関連の記述を参照してください。

エラー メッセージ PLATFORM-2-PS_MISMATCH: Detected power supply [chars]. This reduces the redundant power available to the system and can cause service disruptions (Serial No. [chars]).

説明 新しい電源装置の容量が既存の電源装置よりも小さいことが検出されました。

推奨処置 電源装置の容量を増減する方法、電源装置を構成する方法については、電源装置のマニュアルを参照してください。show environment power および show platform internal info CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。

エラー メッセージ PLATFORM-5-PS_REMOVE: Power supply [dec] removed (Serial No. [chars]).

説明 電源措置がすでに取り外されています。

推奨処置 対処不要です。

 

表4-1 電源装置の LED がすべて消灯

現象
考えられる原因
解決方法

電源装置の LED が すべて消灯した状態になっている。

電源装置がシャーシに正しく取り付けられていない。

電源装置をいったん取り外してから、再び取り付けます。シャーシについては、該当するハードウェアのインストレーション ガイドを参照してください。

電源装置がシャットダウンされている。

Device Manager で Physical > Power Supplies を選択して OperStatus を調べるか、または show environment power CLI コマンドを使用して、電源装置がシャットダウンされているかどうかを判別します。ステータスが shutdown になっている場合は、スーパーバイザがすでに電源装置をシャットダウンしています。冗長モードで電源装置の組み合わせがミスマッチになっていること、または併用モードから冗長モードに移行したことがスーパーバイザモジュールによって検出されると、スーパーバイザ モジュールは容量が小さい方の電源装置をシャットダウンします。両方の電源装置が同じ容量またはモードが併用モードになってい場合は、Cisco SAN-OS が電源装置をシャットダウンすることはありません。

電源装置が動作不能の状態になっている。

電源装置のトラブルシューティングを行います。詳細については、「電源装置のトラブルシューティング」を参照してください。

電源装置の INPUT OK LED がレッドで点灯

現象 電源装置の INPUT OK LED がレッドで点灯している。

 

表4-2 電源装置の INPUT OK LED がレッドで点灯

現象
考えられる原因
解決方法

電源装置の INPUT OK LED がレッドで点灯している。

電源装置がシャーシに正しく取り付けられていない。

電源装置をいったん取り外してから、再び取り付けます。シャーシについては、該当するハードウェアのインストレーション ガイドを参照してください。

Cisco MDS 9500 シリーズ シャーシ上の PEM が、正しく取り付けられていない。

電源装置の PEM をいったん取り外してから、再び取り付けます。シャーシについては、該当するハードウェアのインストレーション ガイドを参照してください。

外部電源が使用不能の状態になっている。

スイッチの電源を切り、外部電源を点検します。Cisco MDS 9500 シリーズ ディレクタの冗長電源装置ごとに、独立した電源装置を使用します。

電源装置が動作不能の状態になっている。

電源装置のトラブルシューティングを行います。詳細については、「電源装置のトラブルシューティング」を参照してください。

電源装置の OUTPUT FAIL LED が点灯

現象 電源装置の OUTPUT FAIL LED が点灯している。

 

表4-3 電源装置の OUTPUT FAIL LED が点灯

現象
考えられる原因
解決方法

電源装置の OUTPUT FAIL LED が点灯している。

電源装置が動作不能の状態になっている。

電源装置のトラブルシューティングを行います。詳細については、「電源装置のトラブルシューティング」を参照してください。

電源装置の FAN OK LED がレッドで点灯

現象 電源装置の FAN OK LED がレッドで点灯している。

この症状が発生すると、次のシステム メッセージが生成されます。

エラー メッセージ PLATFORM-2-PS_FANFAIL: Fan in Power supply [dec] failed.

説明 電源装置のファン モジュールが故障しました。

推奨処置 show environment power および show platform internal info CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。

対象 Cisco MDS SAN-OS Release 1.3(1)

 

表4-4 電源装置の FAN OK LED がレッドで点灯

現象
考えられる原因
解決方法

電源装置の FAN OK LED がレッドで点灯している。

電源装置のファンが故障した。

Device Manager で Physical > Temperature センサーを選択するか、または show environment temperature CLI コマンドを使用して、シャーシ温度が正常であることを確認します。マイナー しきい値に接近している温度センサーがないことを確認します。温度センサーがしきい値に接近またはそれを超えている場合は、電源装置を交換する必要があります。

電源装置が動作不能の状態になっている。

電源装置のトラブルシューティングを行います。詳細については、「電源装置のトラブルシューティング」を参照してください。

電源装置のトラブルシューティング

電源装置の問題を特定する手順は、次のとおりです。


ステップ 1 電源装置の INPUT OK LED がグリーンになっていることを確認します。INPUT OK LED がグリーンであれば、AC または DC 電源が使用可能で、電源装置は機能しています。

ステップ 2 INPUT OK LED が消灯している場合は、まず電源装置がシャーシ背面に対して水平になっていることを確認します。電源スイッチをオフにして、非脱落型ネジを締め、電源スイッチをもう一度オン(|)にします。それでも INPUT OK LED が点灯しない場合は、AC 電源、DC 電源、または電源コードの問題が考えられます。

a. 両方の電源スイッチをオフ(0)の位置にしてスイッチの電源を切り、電源コードを別の電源(ある場合)に接続して、電源スイッチをオンにします。この段階で INPUT OK LED がグリーンになった場合は、最初の電源に問題があります。

b. 新しい電源に電源装置を接続しても INPUT OK LED が点灯しない場合は、電源コードを交換してスイッチをオンにします。この時点で INPUT OK LED が点灯した場合には、最初の電源コードを返却して交換を依頼してください。

c. 新しい電源コードを使用して別の電源にスイッチを接続しても INPUT OK LED が点灯しない場合は、電源装置の故障が考えられます。第 2 電源装置を使用できる場合には、第 2 電源装置ベイに装着し、テクニカル サポート担当者に連絡して指示を受けてください。


) シスコのサポートをシスコのリセラーからご購入された場合は、リセラーに直接お問い合わせください。サポートをシスコから直接ご購入された場合は、次の URL にある Technical Assistance Center(TAC)にご連絡ください。
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtm


ステップ 3 2 台めの(冗長)電源装置がある場合は、ステップ 1 を繰り返します。

ステップ 4 Device Manager で Physical > Power Supplies を選択するか、または show environment power CLI コマンドを使用して、電源装置のステータスを確認します(例4-1 を参照)。

例4-1 show environment power コマンドの出力

switch# show environment power
-----------------------------------------------------
PS Model Power Power Status
(Watts) (Amp @42V)
-----------------------------------------------------
1 DS-CAC-1900W 1019.34 24.27 ok
2 DS-CAC-1900W 1019.34 24.27 ok
 
 
Mod Model Power Power Power Power Status
Requested Requested Allocated Allocated
(Watts) (Amp @42V) (Watts) (Amp @42V)
--- ------------------- ------- ---------- --------- ---------- ----------
3 DS-X9016 220.08 5.24 220.08 5.24 powered-up
4 DS-X9308-SMIP 210.00 5.00 210.00 5.00 powered-up
5 DS-X9530-SF1-K9 220.08 5.24 220.08 5.24 powered-up
 
 
Power Usage Summary:
------------------
Power Supply redundancy mode: redundant
 
Total Power Capacity 1019.34 W
 
Power reserved for Supervisor(s)[-] 440.16 W
Power reserved for Fan Module(s)[-] 126.00 W
Power currently used by Modules[-] 430.08 W
 

問題を解決できない場合、または電源装置とバックプレーン コネクタのどちらかに問題があることを確認した場合には、テクニカル サポート担当者に連絡してください。


 

ファンの問題のトラブルシューティング

ここでは、ファンの障害に関する問題について説明します。具体的な内容は、次のとおりです。

「ファンが回転しない」

「ファンは回転しているが FAN LED がレッドで点灯」

ファンが回転しない

現象 ファンが回転していない。

 

表4-5 ファンが回転しない

現象
考えられる原因
解決方法

ファンが回転していない。

ファンがシャーシに正しく取り付けられていない。

非脱落型ネジを緩めてファン モジュールを取り外し、正しく装着されるように再度取り付けます。すべての非脱落型ネジを締め、システムを再起動します。

電源装置が動作不能の状態になっている。

電源装置のトラブルシューティングを行います。詳細については、「電源装置の問題のトラブルシューティング」を参照してください。

ファンは回転しているが FAN LED がレッドで点灯

現象 ファンは回転しているが FAN LED がレッドで点灯している。

 

表4-6 ファンは回転しているが FAN LED がレッドで点灯

現象
考えられる原因
解決方法

ファンは回転しているが FAN LED がレッドで点灯している。

ファンがシャーシに正しく取り付けられていない。

非脱落型ネジを緩めてファン モジュールを取り外し、正しく装着されるように再度取り付けます。すべての非脱落型ネジを締め、システムを再起動します。

ファン モジュールが故障した。

ファン モジュールのトラブルシューティングを行います。詳細については、「CLI によるファンの問題のトラブルシューティング」を参照してください。

Device Manager によるファンの問題のトラブルシューティング

Device Manager を使用してファン モジュールの問題のトラブルシューティングを行う手順は、次のとおりです。


ステップ 1 Physical > Fan を選択します。Fan Status ダイアログボックスが表示されます。

ステップ 2 OperStatus が failure の場合は、1 つまたは複数のファンが動作していません。スイッチが過熱する前に、故障したファン モジュールを交換してください。スイッチのログには、次のシステム メッセージが記録されます。

エラー メッセージ PLATFORM-1-CASA_FAN_FAIL: Fan module [dec] Failed.

説明 ファン モジュールが故障したため、交換が必要です。放置すると、過熱して温度アラームが発生します。

推奨処置 show platform internal info コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。

ステップ 3 OperStatus が absent の場合は、ファン モジュールがすでに取り外されています。ファン モジュールが取り外されると、Cisco SAN-OS は 5 分間のカウントダウンを開始します。


注意 5 分以内にファン モジュールを再び取り付けなければ、スイッチ全体がシャットダウンされます。

ソフトウェアは SEEPROM 上のバイトを読み取り、ファン モジュールが存在しているかどうかを判別します。ファン モジュールの差し込みが不完全な場合、または何らかの理由でソフトウェアがファン モジュール上の SEEPROM にアクセスできない場合、Cisco SAN-OSは、実際にファン モジュールが取り外されているかどうかを判別できません。この状況では、スイッチは 5 分後にシャットダウンされます。次の重大度 0 の Syslog メッセージが 5 秒ごとに表示されます。

エラー メッセージ PLATFORM-0-FAIL_REMOVED: Fan module removed. Fan module has been absent for [dec] seconds.

説明 ファン モジュールが取り外されています。温度アラームが発生する可能性があります。

推奨処置 ファン モジュールをただちに交換してください。

ステップ 4 ファン モジュールを取り外し、再び取り付けるか、または交換します。それでも FAN LED がレッドで点灯している場合は、システムがファン モジュールの障害を検出しています。テクニカル サポート担当者に連絡して、指示を受けてください。


) シスコのサポートをシスコのリセラーからご購入された場合は、リセラーに直接お問い合わせください。サポートをシスコから直接ご購入された場合は、次の URL にある Technical Assistance Center(TAC)にご連絡ください。
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtm



 

CLI によるファンの問題のトラブルシューティング

CLI を使用してファン モジュールの問題のトラブルシューティングを行う手順は、次のとおりです。


ステップ 1 show environment fan コマンドを使用して、各ファン タイプのステータスを確認します(例4-2 を参照)。

例4-2 show environment fan コマンドの出力

switch# show environment fan
--------------------------------------------------------
Fan Model Hw Status
--------------------------------------------------------
Chassis DS-9SLOT-FAN 1.2 ok
PS-1 -- -- ok
PS-2 -- -- absent
 

ステップ 2 ファンのステータスが failure の場合は、1 つまたは複数のファンが動作していません。スイッチが過熱する前に、故障したファン モジュールを交換してください。スイッチのログには、次のシステム メッセージが記録されます。

エラー メッセージ PLATFORM-1-CASA_FAN_FAIL: Fan module [dec] Failed.

説明 ファン モジュールが故障したため、交換が必要です。放置すると、過熱して温度アラームが発生します。

推奨処置 show platform internal info コマンドを入力して、詳細な情報を収集します。

ステップ 3 ファンのステータスが absent の場合は、ファン モジュールがすでに取り外されています。ファン モジュールが取り外されると、Cisco SAN-OS は 5 分間のカウントダウンを開始します。


注意 5 分以内にファン モジュールを再び取り付けなければ、スイッチ全体がシャットダウンされます。

ソフトウェアは SEEPROM 上のバイトを読み取り、ファン モジュールが存在しているかどうかを判別します。ファン モジュールの差し込みが不完全な場合、または何らかの理由でソフトウェアがファン モジュール上の SEEPROM にアクセスできない場合、Cisco SAN-OSは、実際にファン モジュールが取り外されているかどうかを判別できません。この状況では、スイッチは 5 分後にシャットダウンされます。次の重大度 0 の Syslog メッセージが 5 秒ごとに表示されます。

エラー メッセージ PLATFORM-0-FAIL_REMOVED: Fan module removed. Fan module has been absent for [dec] seconds.

説明 ファン モジュールが取り外されています。温度アラームが発生する可能性があります。

推奨処置 ファン モジュールをただちに交換してください。

ステップ 4 ファン モジュールを取り外し、再び取り付けるか、または交換します。それでも FAN LED がレッドで点灯している場合は、システムがファン モジュールの障害を検出しています。テクニカル サポート担当者に連絡して、指示を受けてください。


) シスコのサポートをシスコのリセラーからご購入された場合は、リセラーに直接お問い合わせください。サポートをシスコから直接ご購入された場合は、次の URL にある Technical Assistance Center(TAC)にご連絡ください。
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtm



 

温度しきい値超過

シャーシ内の各モジュールには、少なくとも 2 個の温度センサーがあります。各温度センサーは、マイナーおよびメジャー しきい値で設定されています。例4-3 に、 show environment temperature CLI コマンドの出力例を示します。この例では、スイッチから温度情報を取得する方法が示されています。Device Manager で Physical > Temperature Sensors を選択しても、同様の出力が表示されます。

例4-3 show environment temperature コマンドの出力

switch# show environment temperature
---------------------------------------------------------------
Module Sensor MajorThresh MinorThres CurTemp Status
(Celsius) (Celsius) (Celsius)
---------------------------------------------------------------
4 Outlet 75 60 36 ok
4 Intake 65 50 29 ok
 
5 Outlet 75 60 35 ok
5 Intake 65 50 34 ok
 
6 Outlet 75 60 35 ok
6 Intake 65 50 34 ok
 
9 Outlet 75 60 45 ok
9 Intake 65 50 40 ok
 
 

モジュールの空気取り入れ口にある空気取り入れ口センサーは、モジュール温度の最も重要なインジケータです。温度が空気取り入れ口センサーのメジャー しきい値を超えたときは、Cisco SAN-OS のすべての操作が実行されます。

空気吹き出し口センサー側でマイナー しきい値またはメジャー しきい値の超過が発生すると、次のシステム メッセージが生成されます。

エラー メッセージ PLATFORM-0-MOD_TEMPMAJALRM: Module [dec] reported major temperature alarm.

説明 スロット内にあるモジュールの温度が、メジャー しきい値を超えています。

推奨処置 show environment temperature CLI コマンドを入力、または Device Manager で Physical > Temperature Sensors を選択して、詳細な情報を収集します。

また、この温度超過によって、Call Home イベントおよび SNMP 通知が生成されます。

モジュールの空気吹き出し口センサー側でメジャー しきい値の超過が発生すると、次のシステム メッセージが生成されます。

エラー メッセージ PLATFORM-0-MOD_TEMPSHUTDOWN: Module [dec] powered down due to major temperature alarm.

説明 温度がメジャー しきい値を超えたために、モジュールがシャットダウンされました。

推奨処置 show environment temperature CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。

冗長スーパーバイザの空気取り入れ口センサーで温度がメジャー しきい値を超過したことが Cisco SAN-OS によって検出されると、Cisco SAN-OS は冗長スーパーバイザをただちにシャットダウンします。これにより、しきい値を超過したスーパーバイザ モジュール応じて、スイッチオーバーまたはスタンバイ スーパーバイザ モジュールでのシャットダウンが実行されます。

スイッチ内の動作中のスーパーバイザだけで、空気取り入れ口センサーの温度がメジャー しきい値を超過したことが Cisco SAN-OS によって検出されると、120 秒のカウントダウンが開始されます。途中で温度がしきい値よりも下がった場合は、カウントダウンは中止されます。それ以外の場合は、スイッチの電源装置はシャットダウンされます。カウントダウン中は、次の Syslog メッセージが 5 秒ごとに表示されます。

エラー メッセージ PLATFORM-0-SYS_RESET: [chars] System shutdown in [dec] seconds.

説明 システムがシャットダウンされるまでの秒数は、エラー メッセージに表示されます。

推奨処置 show environment temperature CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。

温度センサーが故障することもあります。この状況では、次のシステム メッセージが生成されるだけで、明示的な操作は実行されません。

エラー メッセージ PLATFORM-5-MOD_TEMPFAIL: Module [dec] temperature sensor failed.

説明 モジュールに故障した温度センサーがあります。

推奨処置 show environment temperature CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、詳細な情報を収集します。

クロック モジュールの問題のトラブルシューティング

Cisco MDS 9500 シリーズ ディレクタには、A と B の 2 つのクロック モジュールがあります。show environment clock CLI コマンドを使用すると、クロック モジュールのステータスを表示できます(例4-4 を参照)。

例4-4 show environment clock コマンドの出力

switch# show environment clock
----------------------------------------------------------
Clock Model Hw Status
----------------------------------------------------------
A DS-C9500-CL 0.0 ok/active
B DS-C9500-CL 0.0 ok/standby
 

クロック モジュールが故障すると、システムは冗長クロック モジュールを自動的にスイッチオーバーします。また、これによって、スイッチのハードウェア リセットが実行されます。スイッチが再起動すると、システムは現在アクティブなクロック モジュールを表示します。スイッチの起動時に生成される次の Syslog メッセージに、現在アクティブなクロック モジュールが表示されます。

エラー メッセージ PLATFORM-0-CHASSIS_CLKSWRESET: Switch reset due to clock switch.

説明 シャーシのクロック ソースが故障したため、システムはリセットされます。システムは冗長クロック モジュールを使用して自動的に起動します。

推奨処置 次のメンテナンス ウィンドウ内で、故障したクロック モジュールを交換します。

通常は、クロック モジュール A がアクティブ クロックです。クロック モジュール A が故障すると、クロック モジュール B がアクティブ クロックになります。クロック モジュールの交換については、次の Web サイトで、使用しているプラットフォーム用のハードウェア インストレーション ガイドを参照してください。

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

ハードウェアの他の問題に対するトラブルシューティング


internal キーワードを含むコマンドを発行するには、network-admin グループのメンバになっているアカウントを使用する必要があります。


CLI を使用してモジュールを含むハードウェアの問題を識別する手順は、次のとおりです。


ステップ 1 show module internal exceptionlog コマンドを使用します。

例外ログは、各モジュールで発生したすべてのエラー条件および例外条件を記録する循環ログです。ある例外は致命的なもので、また一部の例外はモジュール上の特定のポートに部分的に影響し、さらにそれ以外の例外は警告を目的としています。ログの各エントリには、次のフィールドがあります。

device id ― ログに例外が記録されるデバイスの ID です。この情報は、テクニカル サポート担当者によって使用されます。

device errorcode ― デバイス上で発生したエラーのエラー コードです。この情報は、テクニカル サポート担当者によって使用されます。

error type ― エラーの重大度です。通常、ソフトウェアのエラーは、Minor エラーまたは Warning エラーになります。その他のエラーはすべて、ハードウェアの問題です。

Number Ports that failed ― モジュール上で動作不能の状態になっているポートの数です。

system time ― 問題の発生時刻を示すタイムスタンプです。

例外ログは、スーパーバイザ モジュールの NVRAM に保管されます。

ログに記録されている大多数のハードウェア エラーは、このコマンドの出力に表示されます。error type フィールドに Minor error または Warning error 以外が示されている場合は、ほとんどがハードウェア障害です(例4-5 を参照)。

例4-5 show module internal exceptionlog コマンドの出力

switch# show module internal exceptionlog
********* Exception info for module 6 ********
 
exception information --- exception instance 1 ----
device id: 85
device errorcode: 0xc550120c
system time: (1127748710 ticks) Mon Sep 26 15:31:50 2005
 
error type: Minor error
Number Ports went bad: none
 
********* Exception info for module 8 ******** <---障害の可能性のあるモジュール
 
exception information --- exception instance 1 ----
device id: 12
device errorcode: 0x80000080
system time: (1127843531 ticks) Tue Sep 27 17:52:11 2005
 
error type: FATAL error <------------------- error type フィールド
Number Ports went bad:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
 

ステップ 2 show hardware internal errors コマンドの出力で、エラー統計情報を確認します。

FC-MAC に報告されるエラー統計情報は、必ずしもエラーとは限りませんが、ポートが使用可能な状態であれば、通常これらのカウンタの値は増加しません。

ステップ 3 show hardware internal errors コマンドの出力で、割り込みカウントを確認します。

次のことに注意してください。

一部の割り込みは、必ずしもエラーによる割り込みではありません。

一部の割り込みには、対象ポートの障害を判断するためのしきい値が設定されています。割り込みカウントが発生していても、ハードウェアの障害であるとは限りません。ただし、これらのコマンドは、テクニカル サポート担当者が問題のデバッグを行うときに役立ちます。

スーパーバイザの 1 つを取り外したり、再起動した場合には、UP-XBAR ASIC および DOWN-XBAR ASIC に一部の割り込みカウントが報告されることがあります。


 

スーパーバイザの問題のトラブルシューティング

スーパーバイザの開始プロセスは、冗長スーパーバイザの有無によって異なります。2 つのスーパーバイザがあるシステムで電源を投入すると、1 つのスーパーバイザがアクティブになり、もう 1 つのスーパーバイザはスタンバイ状態になります。アクティブ スーパーバイザの初期化は、スタンバイ スーパーバイザとは異なります。

システムにアクティブ スーパーバイザがない場合は、最初に起動したスーパーバイザが、デフォルトのアクティブ スーパーバイザになります。システムにアクティブ スーパーバイザがある場合は、起動したスーパーバイザは、デフォルトのスタンバイ スーパーバイザになります。スタンバイ スーパーバイザには、アクティブ スーパーバイザの状態が複製される必要があります。スタンバイ スーパーバイザにあるすべてのコンポーネントがアクティブ スーパーバイザのコンポーネントと同期化されると、スタンバイ スーパーバイザは作動状態になります。

Cisco SAN-OS では、実行時のデバッグ情報が維持されます。スーパーバイザが再起動すると、デバッグ情報の大部分は失われます。ただし、重大な情報はすべて NVRAM に保管されるので、障害の再現に使用できます。アクティブ スーパーバイザが再起動すると、そのスーパーバイザが再び作動状態になるまで、NVRAM に保管されている情報は取得できなくなります。スーパーバイザの再起動が完了したあとは、次の CLI コマンドを使用して永続ログを表示できます。

show logging nvram

show system reset-reason

show module internal exception-log

ここでは、アクティブ スーパーバイザまたはスタンバイ スーパーバイザの初期化が失敗したときの診断手順について説明します。ここで説明する内容は、次のとおりです。

「アクティブ スーパーバイザが再起動」

「スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない」

「スタンバイ スーパーバイザが電源投入ステートで停止」

アクティブ スーパーバイザが再起動

現象 アクティブ スーパーバイザが再起動する。

 

表4-7 アクティブ スーパーバイザが再起動

現象
考えられる原因
解決方法

アクティブ スーパーバイザが再起動する。

スーパーバイザのプロセスがクラッシュしたために、スーパーバイザのリロードが発生した。

スーパーバイザの再起動が完了したあと、show system reset-reason CLI コマンドを使用してリセットの原因を表示します(例4-6 を参照)。スタンバイ スーパーバイザがある場合は、そのスーパーバイザがアクティブ スーパーバイザになります。スタンバイ スーパーバイザ上のシステム メッセージ ログを表示して、同じ情報があることを確認します(例4-7 を参照)。

show process log CLI コマンドを使用して、再起動したプロセスのリストを表示します。

実行時診断で障害が検出された。

スーパーバイザの再起動が完了したあと、スタンバイ スーパーバイザ上で show module internal exceptionlog CLI コマンドを使用して、リセットの原因を表示します(例4-8 を参照)。スタンバイ スーパーバイザがある場合は、そのスーパーバイザがアクティブ スーパーバイザになります。スタンバイ スーパーバイザ上のシステム メッセージ ログを表示して、同じ情報があることを確認します(例4-9 を参照)。オプションとして、スーパーバイザの再起動が完了したあとに
show system reset-reason CLI コマンドを使用して、同じ情報を表示することもできます。

また、「Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング」も参照してください。

例4-6 には、プロセスがクラッシュしてスーパーバイザ モジュールが再起動したときのリセット理由が示されています。

例4-6 プロセスが失敗して再起動したスーパーバイザのリセット理由

switch# show system reset-reason
----- reset reason for module 6 -----
1) At 94009 usecs after Tue Sep 27 18:52:13 2005
Reason: Reset triggered due to HA policy of Reset
Service: Service "xbar" <------------------ 再起動の原因となったプロセス
Version: 2.1(2)
 

例4-7 には、プロセスがクラッシュしてスーパーバイザ モジュールが再起動したときにスタンバイ スーパーバイザ モジュールで記録された、システム メッセージが示されています。

例4-7 プロセスが失敗して再起動したスーパーバイザのシステム メッセージ

Switch# show logging
2005 Sep 27 18:58:05 172.20.150.204 %SYSMGR-3-SERVICE_CRASHED: Service "xbar" (PID 1225) hasn't caught signal 9 (no core).
2005 Sep 27 18:58:06 172.20.150.204 %SYSMGR-3-SERVICE_CRASHED: Service "xbar" (PID 2349) hasn't caught signal 9 (no core).
2005 Sep 27 18:58:06 172.20.150.204 %SYSMGR-3-SERVICE_CRASHED: Service "xbar" (PID 2352) hasn't caught signal 9 (no core).
 

例4-8 には、実行時診断で障害が検出されたため、スーパーバイザ モジュールが再起動したときに記録される例外ログが示されています。

例4-8 実行時診断で障害が検出されて再起動したスーパーバイザの例外ログ

switch# show module internal exceptionlog module 6
********* Exception info for module 6 ********
 
exception information --- exception instance 1 ----
device id: 12
device errorcode: 0x80000020
system time: (1127917068 ticks) Wed Sep 28 14:17:48 2005
 
error type: FATAL error <--------------------- 再起動の原因となった例外
Number Ports went bad:
1,2,3,4,5,6
 
exception information --- exception instance 2 ----
device id: 12
device errorcode: 0x00060a02
system time: (1127917067 ticks) Wed Sep 28 14:17:47 2005
 
error type: Warning
Number Ports went bad:
1,2,3,4,5,6
 

例4-9 には、実行時診断で障害が検出されたため、スーパーバイザ モジュールが再起動したときにスタンバイ スーパーバイザ モジュールで記録されたシステム メッセージが示されています。

例4-9 実行時診断で障害が検出されて再起動したスーパーバイザのシステム メッセージ

Switch# show logging
2005 Sep 28 14:17:47 172.20.150.204 %XBAR-5-XBAR_STATUS_REPORT: Module 6 reported status for component 12 code 0x60a02.
2005 Sep 28 14:17:59 172.20.150.204 %PORT-5-IF_UP: Interface mgmt0 on slot 5 is up
2005 Sep 28 14:18:00 172.20.150.204 %CALLHOME-2-EVENT: SUP_FAILURE
 

スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない

現象 スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない。

 

表4-8 スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない

現象
考えられる原因
解決方法

スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない。

スタンバイ スーパーバイザが、アクティブ スーパーバイザと正しく同期していない。

問題の確認については、「スタンバイ スーパーバイザがアクティブ スーパーバイザによって認識されない」 を確認してください。起動プロセスを観察して、正常な起動シーケンスに従って LED が点灯していること、またスタンバイ スーパーバイザの電源投入、初期化、およびテストの各フェーズが正しく実行されていることを確認します。スタンバイ スーパーバイザで loader> プロンプトが表示されている場合は、アクティブ スーパーバイザから reload module 6 force-dlnd コマンドを使用して、強制的にスタンバイ スーパーバイザをアクティブ スーパーバイザからネットブートするようにします。

スタンバイ スーパーバイザの同期の失敗を CLI から確認

スタンバイ スーパーバイザがアクティブ スーパーバイザと同期していないことを CLI を使用して確認する手順は、次のとおりです。


ステップ 1 アクティブ スーパーバイザ上で show module コマンドを使用して、アクティブ スーパーバイザがスタンバイ スーパーバイザを検出していないことを確認します(例4-10 を参照)。

例4-10 show module コマンドの出力

switch# show module
Mod Ports Module-Type Model Status
--- ----- -------------------------------- ------------------ ------------
5 0 Supervisor/Fabric-1 DS-X9530-SF1-K9 active *
8 8 IP Storage Services Module powered-dn
 
Mod Sw Hw World-Wide-Name(s) (WWN)
--- ----------- ------ --------------------------------------------------
5 2.1(2) 1.1 --
 
 
Mod MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
5 00-0b-be-f7-4d-1c to 00-0b-be-f7-4d-20 JAB070307XG
 
* this terminal session
 

ステップ 2 スタンバイ スーパーバイザのコンソール ポートに Telnet で接続し、そのスーパーバイザがスタンバイ モードになっていることを確認します(例4-11 を参照)。

例4-11 スタンバイ スーパーバイザのモードの確認

runlog>telnet sw4-ts 2004
Trying 172.22.22.55...
Connected to sw4-ts.cisco.com (172.22.22.55).
Escape character is '^]'.
 
MDS Switch
login: admin
Password:
Cisco Storage Area Networking Operating System (SAN-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2005, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
switch(standby)#
 

ステップ 3 アクティブ スーパーバイザ上で show system redundancy status を使用して、スタンバイ スーパーバイザがアクティブ スーパーバイザとの同期フェーズを完了していなかったことを確認します。

switch# show system redundancy status
Redundancy mode
---------------
administrative: HA
operational: None
 
This supervisor (sup-1)
-----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby
 
Other supervisor (sup-2)
------------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA synchronization in progress
 

同期が失敗する理由のほとんどは、スタンバイ スーパーバイザ上にあるソフトウェア コンポーネントの 1 つが、その状態をアクティブ スーパーバイザと同期できなかったことによります。

ステップ 4 アクティブ スーパーバイザ上で show system internal sysmgr gsyncstats コマンドを使用して、スタンバイ スーパーバイザ上で同期していなかったプロセスを判別します。

switch# show system internal sysmgr gsyncstats
Name Gsync done Gsync time(sec)
---------------- ---------- -------------
aaa 1 0
ExceptionLog 1 0
platform 1 1
radius 1 0
securityd 1 0
SystemHealth 1 0
tacacs 0 N/A
acl 1 0
ascii-cfg 1 1
bios_daemon 0 N/A
bootvar 1 0
callhome 1 0
capability 1 0
cdp 1 0
cfs 1 0
cimserver 1 0
cimxmlserver 0 N/A
confcheck 1 0
core-dmon 1 0
core-client 0 N/A
device-alias 1 0
dpvm 0 N/A
dstats 1 0
epld_upgrade 0 N/A
epp 1 1
 

ステップ 5 スタンバイ スーパーバイザ上で show system internal sysmgr service all コマンドを使用して、再起動が多すぎるプロセスがあるかどうかを判別します(例4-12 を参照)。


) スタンバイ スーパーバイザで loader> プロンプトが表示されている場合は、このコマンドを使用できないことがあります。


例4-12 過度の再起動を発見

switch(standby)# show system internal sysmgr service all
Name UUID PID SAP state Start count
------------ -------- ------ ----- ----- -----------
aaa 0x000000B5 1458 111 s0009 1
ExceptionLog 0x00000050 [NA] [NA] s0002 None
platform 0x00000018 1064 39 s0009 1
radius 0x000000B7 1457 113 s0009 1
securityd 0x0000002A 1456 55 s0009 1
vsan 0x00000029 1436 15 s0009 1
vshd 0x00000028 1408 37 s0009 1
wwn 0x00000030 1435 114 s0009 1
xbar 0x00000017 [NA] [NA] s0017 23
xbar_client 0x00000049 1434 917 s0009 1
 

例4-12 で取り上げられているスタンバイ スーパーバイザでは、クロスバー(xbar)ソフトウェア コンポーネントがすでに 23 回再起動していることがわかります。これは、スタンバイ スーパーバイザの正常な初期化を妨げていると考えられます。

ステップ 6 reload module コマンドを使用して、スーパーバイザ モジュールを再起動します。再起動が失敗する場合は、アクティブ スーパーバイザから reload module 6 force-dlnd コマンドを使用して、強制的にスタンバイ スーパーバイザをアクティブ スーパーバイザからネットブートするようにします。


 

スタンバイ スーパーバイザが電源投入ステートで停止

現象 スタンバイ スーパーバイザが電源投入ステートで停止する。

 

表4-9

現象
考えられる原因
解決方法

スタンバイ スーパーバイザが電源投入ステートで停止する。

スタンバイ スーパーバイザが、アクティブ スーパーバイザと正しく同期していない。

詳細については、「スタンバイ スーパーバイザが電源投入ステートであることを Device Manager から確認」および「スタンバイ スーパーバイザが電源投入ステートであることを CLI から確認」を参照してください。

スタンバイ スーパーバイザが電源投入ステートであることを Device Manager から確認

スタンバイ スーパーバイザが電源投入ステートであることを Device Manager を使用して確認する手順は、次のとおりです。


ステップ 1 Physical > Modules.... を選択し、スタンバイ スーパーバイザの動作ステータス(OperStatus)が PoweredUp になっていることを確認します。

ステップ 2 スタンバイ スーパーバイザを右クリックし、ドロップダウン メニューから Reset を選択してスタンバイ スーパーバイザを再起動します。


 

スタンバイ スーパーバイザが電源投入ステートであることを CLI から確認

スタンバイ スーパーバイザが電源投入ステートであることを CLI を使用して確認する手順は、次のとおりです。


ステップ 1 アクティブ スーパーバイザ上で show module コマンドを使用して、スタンバイ スーパーバイザが電源投入ステートになっていることを確認します(例4-13 を参照)。

例4-13 show module コマンドの出力

switch# show module
Mod Ports Module-Type Model Status
--- ----- -------------------------------- ------------------ ------------
5 0 Supervisor/Fabric-1 DS-X9530-SF1-K9 active *
6 0 Supervisor/Fabric-1 powered-up
8 8 IP Storage Services Module powered-dn
 
Mod Sw Hw World-Wide-Name(s) (WWN)
--- ----------- ------ --------------------------------------------------
5 2.1(2) 1.1 --
 
 
Mod MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
5 00-0b-be-f7-4d-1c to 00-0b-be-f7-4d-20 JAB070307XG
 
* this terminal session
 

ステップ 2 show module internal event-history module コマンドを使用して、失敗した可能性のあるコンポーネントを判別します。

ステップ 3 reload module コマンドを使用して、スーパーバイザ モジュールを再起動します。


 

スーパーバイザ モジュールのトラブルシューティング


) 装着されているスーパーバイザ モジュールが 1 つだけの場合には、他のモジュールに対する作業を行う前に 自動同期機能がオフになっていることを確認してください。これは、スイッチに、使用できないモジュールへのフェールオーバーを実行させないためです。


ここでは、特定の条件下でスーパーバイザに障害が発生した場合の対処方法について説明します。問題および対処方法を説明するために、状況の一例を示します。

この事例では、スタンバイ スーパーバイザのリロード時、または新規のスーパーバイザとの交換時に、スーパーバイザで障害が発生しました。障害が発生したスーパーバイザでは、コード バージョンが変更されたか、または保存されたアクティブ スーパーバイザの実行コンフィギュレーションに不正なブート パラメータが含まれていることが検出されました。いずれの場合も、アクティブ スーパーバイザとスタンバイ スーパーバイザのコードの不一致が問題です。コードの不一致を見つける手がかりとなったのは、アクティブ スーパーバイザのハートビートエラーでした。このエラーにより、アクティブ スーパーバイザからスタンバイ スーパーバイザに現在のフラッシュ イメージをコピーできていませんでした。

対処方法は、イメージをコンパクトフラッシュにコピーし、コンソールを切り替えて、コンパクト フラッシュから 2 番めのスーパーバイザにコードをロードすることでした。2 番めのスーパーバイザには、ブート ステートメントの欠落を示す loader プロンプトが表示されました。 dir slot0: CLI コマンドを入力しても、イメージは表示されません。これは、2 つのスーパーバイザのイメージが一致していないか、スーパーバイザのフラッシュ メモリに現在のイメージが存在しないことが原因です。 copy slot0: bootflash: CLI コマンドを入力すると、イメージがコピーされます。2 番めのスーパーバイザにイメージがロードされ、ブート ステートメントの確認とアクティブ スーパーバイザ上への保存が完了したあと、スーパーバイザはロードされて standby-ha モードになりました。

スイッチング モジュールおよびサービス モジュールのトラブルシューティング

ここでは、スイッチング モジュールおよびサービス モジュールの問題について説明します。具体的な内容は、次のとおりです。

「モジュール ステータスの概要」

「モジュールの初期化の概要」

「電源が切断されるモジュールのトラブルシューティング」

「リロードされるモジュールのトラブルシューティング」

「未知の状態になったモジュールのトラブルシューティング」

「スーパーバイザによって検出されないモジュールのトラブルシューティング」

「障害が発生したモジュールの Fabric Manager による再初期化」

「障害が発生したモジュールの CLI による再初期化」

「モジュールのリセット」

モジュール ステータスの概要

Device Manager で Physical > Modules... を選択するか、または show module CLI コマンドを使用して、スイッチに装着されているモジュールのステータスを表示します(例4-14 を参照)。

例4-14 show module コマンドの出力

switch# show module 8
Mod Ports Module-Type Model Status
--- ----- -------------------------------- ------------------ ------------
8 8 IP Storage Services Module DS-X9308-SMIP ok
 
Mod Sw Hw World-Wide-Name(s) (WWN)
--- ----------- ------ --------------------------------------------------
8 2.1(2) 0.206 21:c1:00:05:30:00:8f:5e to 21:c8:00:05:30:00:8f:5e
 
 
Mod MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
8 00-05-30-00-9e-fa to 00-05-30-00-9f-06 JAB064704LH
 

モジュール ステータスは、モジュールの状態を示します。 表4-10 に、モジュールが取る可能性のあるすべての状態、および各状態の簡単な説明を示します。

 

表4-10 モジュール ステータス

モジュール ステータス
説明
モジュール ステータスが示す状態

OK

モジュールは起動および稼働しています。

正常

powered-down

ユーザの設定またはエラーが原因で、モジュールの電源が切断されました。show running-config | include poweroff CLI コマンドを使用して、モジュールが電源切断の状態に設定されているかどうかを判別します。設定されていない場合、モジュールの電源切断の原因はエラーです。

モジュールから重大エラーが報告された場合、スーパーバイザは例外をログに記録してモジュールを再起動します。エラーが原因でスーパーバイザが 1 時間に 3 回起動すると、スーパーバイザはモジュールを永続的に電源切断の状態にします。

正常

err-pwd-dn

障害発生

pwr-denied

シャーシに、モジュールの電源投入に必要な電力を供給する余力がありません。show environment power CLI コマンドを使用して、スイッチの現在の電源ステータスを表示します。

障害発生

powered-up

モジュールの電源が投入され、スーパーバイザはモジュールの初期化完了を待機しています。

過渡状態

pwr-cycled

モジュールはリロードされています。

過渡状態

testing

モジュールの電源投入が完了し、実行時診断が実行されています。

過渡状態

initializing

モジュールは、スーパーバイザからコンフィギュレーションを受信しています。

過渡状態

upgrading

モジュールは、中断なしのアップグレードの処理中です。

過渡状態

failure

モジュールで障害が発生しましたが、デバッグ フラグが設定されていたために電源の再投入はまだ実行されていません。テクニカル サポート担当者の要求に応じて、デバッグ フラグを使用してデバッグ情報をモジュールから収集します。必要なデータがすべて収集されたあとは、reload module CLI コマンドを使用してモジュールをリロードします。

障害発生

モジュールの初期化の概要

モジュールがスイッチに挿入されると、そのモジュールに対して初回起動シーケンスが実行されます。このシーケンスでは、モジュールがオンラインかどうかを判断するために、モジュールを既知の正常状態にします。初期化シーケンスは、次のステップで構成されています。

「モジュールの起動」

「イメージのダウンロード」

「実行時診断」

「実行時コンフィギュレーション」

「オンラインおよび動作中」

このモジュールに関連する障害(モジュールの起動不能、モジュールのリロードの発生など)のほとんどは、スイッチに保管されているログを調べると分析できます。この情報を表示するには、次の CLI コマンドを使用します。

show system reset-reason module

show version

show logging

show module internal exception-log

show module internal event-history module

show module internal event-history errors

show platform internal event-history errors

show platform internal event-history module

モジュールの起動

モジュールがスイッチに挿入されると、スーパーバイザはそのモジュールを電源投入(powered-up)ステートにします。この状態では、スーパーバイザは、モジュールが起動してその識別情報をアクティブ スーパーバイザに送信するまで待機します。

指定された時間内に、モジュールからの登録メッセージをスーパーバイザが受信しなかった場合、スーパーバイザはモジュールの電源を再投入します。このエラーは、起動エラーと呼ばれます。起動エラーのエラー コードは、show platform internal event-history errors CLI コマンドを使用して取得できます(例4-15 を参照)。

例4-15 起動エラーのエラー コードの表示

switch# show platform internal event-history errors
The following error codes are defined
No Boot Device = 0xF1
Boot Failed = 0xC0
Net Boot Failed = 0xD0
Unknown Status = 0x1B
 

イメージのダウンロード

スーパーバイザが登録メッセージを受信すると、スーパーバイザはイメージの互換性マトリックスをチェックします。イメージの互換性チェックでは、スーパーバイザ上で実行されているコードのバージョンと、モジュール上で実行されているコードのバージョンに互換性があるかどうかを調べます。バージョンが一致しない場合、モジュールはアップデートされたバージョンのコードをダウンロードしてから再起動し、アップデートされたパラメータが含まれる登録メッセージを再び送信します。

モジュールがコードをダウンロードできない場合は、スーパーバイザによって次のシステム メッセージが生成されます。

エラー メッセージ MODULE-2-MOD_DNLD_FAIL: Image download failed for module [dec].

説明 モジュールで、新しいイメージのスーパーバイザ モジュールからのダウンロードが失敗しました。

推奨処置 show module internal all module <dec> コマンドを入力して、モジュールの情報を収集します。

さらに、モジュールでは、イメージのダウンロードが失敗した正確な理由を示すシステム メッセージが生成されます。

エラー メッセージ IMAGE_DNLD-SLOT#-2-ADDON_IMG_DNLD_FAILED: Module image download process failed. [chars].

説明 障害が発生したモジュールに、追加イメージをダウンロードします。追加イメージが正常にインストールされるまで、このモジュールは機能しません。

推奨処置 モジュール イメージの位置とバージョンを確認します。install module CLI コマンドを入力、または Fabric Manager や Device Manager の類似のコマンドを使用して、新しいモジュール イメージをダウンロードします。

イメージのダウンロードが失敗した場合、スーパーバイザはモジュールの電源を再投入します。エラー メッセージを表示するには、Device Manager で Logs > Switch Resident > Syslog > Since Reboot を選択するか、または show logging CLI コマンドを使用します。

実行時診断

モジュールがスーパーバイザに正常に登録されると、モジュールはハードウェアをチェックします。ハードウェアのチェックで障害が検出された場合、モジュールはスーパーバイザにエラーを報告し、スーパーバイザは次のシステム メッセージを生成します。

エラー メッセージ MODULE-2-MOD_DIAG_FAIL: Module [dec] reported failure on ports [dec]/[dec]-[dec]/[dec] ([chars]) due to [chars] in device [dec] (device error [hex]).

説明 モジュールから、実行時診断で障害を検出したことが報告されました。Module Manager がモジュールの電源を再投入します。

推奨処置 show module internal all module CLI コマンドを入力して、モジュールの情報を収集します。

さらに、この情報は例外ログに保管されます(再起動後も維持されます)。その後、スーパーバイザはモジュールの電源を再投入します。Device Manager で Logs > Switch Resident > Syslog > Since Reboot を選択するか、または show logging と show module internal exception-log module CLI コマンドを使用すると、障害に関する情報を取得できます。

実行時コンフィギュレーション

実行時診断が正常に完了すると、モジュールは、コンフィギュレーションの準備ができたことをスーパーバイザに通知します。モジュールは個別のスーパーバイザ コンポーネントによって設定されます。このステージでいずれかのコンポーネントから問題が報告されると、スーパーバイザはモジュールを再起動します。show module internal event-history module CLI コマンドを使用して、問題を報告したコンポーネントを判別します。

オンラインおよび動作中

すべてのスーパーバイザ コンポーネントがモジュールの設定を完了すると、モジュールは稼働(OK)ステートになります。この状態では、モジュールはオンラインおよび動作中になっています。スーパーバイザでは、モジュールが正常に動作していることを確認するために、定期的なモニタを継続します。モニタされるイベントは、次のとおりです。

ハートビート メッセージ ― モジュールが稼働していることを確認するために、スーパーバイザとモジュールの間で送信されます。

オンライン ヘルス管理(OHMS) ― トラフィックが正しく伝送されていることを確認するために、スーパーバイザからモジュールのすべてのポートに送信されます。

さらに、モジュールではモジュール自体をモニタし、異常状態を検出すると例外を生成します。例外が重大エラーの場合、モジュールは電源の再投入を実行します。次の CLI コマンドを使用すると、問題が発生したときの状況を確認できます。

show logging

show module diag

show module internal exception-log module

show module internal event-history module

show hardware internal errors

ログの分析

状況によっては、その他の内部ログを調べて、問題の原因を特定することが必要になる場合もあります。その場合は、状態遷移ログおよびエラー ログを使用できます。これらのログには、モジュールとスーパーバイザの間の相互作用が記録されているので、システム メッセージ ログまたは例外ログにはない情報が保持されている可能性があります。状態遷移ログの情報は昇順で保管されています(したがって、最新のステートはログの末尾に追加されます)。エラー ログの情報は降順で保管されています(したがって、最新のエラーはログの先頭に追加されます)。

モジュールの状態遷移ログを表示するには、show module internal event-history module CLI コマンドを使用します。エラー ログを表示するには、show module internal event-history errors CLI コマンドを使用します。

状態遷移ログでは、指定されたモジュールの現在のステートが表示されます(例4-16 を参照)。状態遷移ログの各要素には、次の情報が含まれています。

タイムスタンプ

状態遷移を開始させたノード

遷移する前のモジュール ステート

発生したイベント

モジュールの現在のステート

例4-16 状態遷移ログ

7) FSM:<ID(2): Slot 8, node 0x0800> Transition at 14258 usecs after Mon Sep 26 17:50:56 2005
Previous state: [LCM_ST_LC_POWERED_UP]
Triggered event: [LCM_EV_PFM_LC_STATUS_POWERED_DOWN]
Next state: [LCM_ST_LC_NOT_PRESENT]
 

前記のステート遷移に関する情報から、いつモジュールが電源投入(powered-up)状態になり、またどの時点でモジュールの電源を切断するイベントが PFM によって生成されたかを推測できます。ステート マシンは「存在しない」状態になるのは、このイベント生成が原因です。

モジュールの問題のトラブルシューティング

モジュールの問題を特定する手順は、次のとおりです。


ステップ 1 すべての STATUS LED がグリーンで点灯していることを確認します。いずれかの STATUS LED がレッドで点灯しているか、または消灯している場合は、モジュールがスロットに正しく装着されていない可能性があります。

ステップ 2 モジュールを取り付け直し、両方のイジェクト レバーがシャーシの背面に対して直角になるようにしてください。

ステップ 3 モジュール前面パネルの左右にある非脱落型ネジを締めます。

ステップ 4 システムを再起動します。

スイッチング モジュールの STATUS LED がオレンジで点灯している場合、モジュールが使用中か、ディセーブルになっていることが考えられます。インターフェイスの設定およびイネーブル化については、次の Web サイトで Cisco MDS 9000 ファミリの最新のコンフィギュレーション ガイドを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/sn5000/mds9000/index.htm.
システムがインターフェイスを再度初期化したあと、モジュール上のステータス LED がグリーンになるはずです。

ステップ 5 モジュールがオンライン状態に遷移しない場合は、この項に記載されている症状を参照してください。

起動時の問題を解決できない場合は、 付録A「テクニカル サポートへ問い合わせる前の準備」 で説明されている情報を収集してから、「マニュアルの入手方法、テクニカル サポート、およびシスコのセキュリティ ガイドライン」に記載されている指示に従ってテクニカル サポート担当者に連絡し、サポートを依頼してください。


 

電源が切断されるモジュールのトラブルシューティング

現象 モジュールが電源切断(powered-down)ステートになる。

モジュールが電源投入に失敗すると、次のシステム メッセージが表示されることがあります。

エラー メッセージ PLATFORM-2-PFM_LC_BOOT_DEV_ABSENT: No bootflash found in Module [dec].

説明 ブートフラッシュがありません。

推奨処置 ブートフラッシュをモジュールに装着してから、再び電源を投入します。

エラー メッセージ PLATFORM-2-PFM_LC_BOOT_DEV_FAIL: BAD Bootflash found in Module [dec].

説明 ブートフラッシュの不良です。

推奨処置 モジュールのブートフラッシュを交換してから、再び電源を投入します。

エラー メッセージ PLATFORM-2-PFM_LC_NETBOOT_FAIL: Netboot for Module [dec] failed.

説明 ネットブートは失敗しました。

推奨処置 モジュールの BIOS を交換します。詳細については、「Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング」を参照してください。

エラー メッセージ PLATFORM-2-PFM_LC_REGISTRATION_FAIL: Could not register with Module [dec].

説明 モジュールの登録は失敗しました。

推奨処置 モジュールを交換します。

エラー メッセージ PLATFORM-2-PFM_LC_STATUS: Module [dec] powered up with [dec] status.

説明 登録できなかったモジュールのステータスです。

推奨処置 モジュールを交換します。

エラー メッセージ PLATFORM-3-MOD_PWRFAIL: Module [dec] failed to power up (Serial No. [chars]).

説明 モジュールは電源投入に失敗しました。

推奨処置 show platform internal all module [dec] CLI コマンドを入力して、詳細な情報を収集します。

対象 Cisco MDS SAN-OS Release 1.2(2a)

エラー メッセージ PLATFORM-3-MOD_PWRIDPROMFAIL: Module [dec] failed to power up due to idprom read error.

説明 IDPROM の読み取りエラーが原因で、モジュールの電源を投入できません。

推奨処置 show platform internal all module [dec] および show module internal all module [dec] show sprom module [dec][dec] CLI コマンドを入力してモジュールの IDPROM の内容を読み取り、詳細な情報を収集します。

エラー メッセージ PLATFORM-5-MOD_PWRDN: Module [dec] powered down (Serial No. [chars]).

説明 モジュールの電源が切断されました。

エラーが原因でモジュールの電源が切断されたと考えられる場合は、show module、show platform internal all module[dec]、および show module internal all module [dec] CLI コマンドを入力して、詳細な情報を収集します。

 

表4-11 モジュールが電源切断(powered-down)ステート

現象
考えられる原因
解決方法

モジュールが電源切断(powered-down)ステートになる。

モジュールが起動に失敗した。

Device Manager で Logs > Switch Resident > Syslog > Server Events を選択するか、または show logging CLI コマンドを使用して、起動の問題を確認します。Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

モジュールがスーパーバイザへの登録に失敗した。

モジュールが登録されなかったことを確認するには、show module internal event-history module CLI コマンドを使用して、次のイベントを探します。

Triggered event:[LCM_EV_LCP_REGISTRATION_TIMEOUT]

Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

モジュールがファブリックへの接続に失敗した。

モジュールがファブリックに接続できなかったことを確認するには、 show system internal xbar internal event-history module CLI コマンドを使用して、次のイベントを探します。

Triggered event:[XBM_MOD_EV_SYNC_FAILED]

Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

スーパーバイザが、モジュールの設定に失敗した。

障害の原因を確認します。詳細については、「電源が切断されるモジュールの診断」を参照してください。Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

電源が切断されるモジュールの診断

モジュールの電源切断の理由を CLI を使用して診断する手順は、次のとおりです。


ステップ 1 show system reset-reason module コマンドを使用して、モジュールが最後にリロードされたときの理由を表示します。

ステップ 2 show module コマンドを使用して、モジュールのステータスを確認します。

switch# show module
Mod Ports Module-Type Model Status
--- ----- -------------------------------- ------------------ ------------
5 0 Supervisor/Fabric-1 DS-X9530-SF1-K9 ha-standby
6 0 Supervisor/Fabric-1 DS-X9530-SF1-K9 active *
8 8 IP Storage Services Module powered-dn
 
Mod Sw Hw World-Wide-Name(s) (WWN)
--- ----------- ------ ------------------------------------
5 2.1(2) 1.1 --
6 2.1(2) 0.602 --
 
 
Mod MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
5 00-0b-be-f7-4d-1c to 00-0b-be-f7-4d-20 JAB070307XG
6 00-05-30-00-93-7e to 00-05-30-00-93-82 JAB0637059v
 

ステップ 3 show logging コマンドを使用して、このモジュールでどのようなイベントが発生したかを調べます。

Switch# show logging
 
2005 Sep 27 15:26:02 172.20.150.204 %PLATFORM-5-MOD_DETECT: Module 8 detected (Serial number JAB064704LH)
2005 Sep 27 15:26:02 172.20.150.204 %PLATFORM-5-MOD_PWRUP: Module 8 powered up (
Serial number JAB064704LH)
2005 Sep 27 15:27:03 172.20.150.204 %MODULE-5-MOD_REINIT: Re-initializing module 8
2005 Sep 27 15:27:09 172.20.150.204 %PLATFORM-5-MOD_DETECT: Module 8 detected (Serial number JAB064704LH)
2005 Sep 27 15:27:09 172.20.150.204 %PLATFORM-5-MOD_PWRUP: Module 8 powered up (
Serial number JAB064704LH)
2005 Sep 27 15:28:10 172.20.150.204 %MODULE-5-MOD_REINIT: Re-initializing module 8
2005 Sep 27 15:28:15 172.20.150.204 %PLATFORM-5-MOD_DETECT: Module 8 detected (Serial number JAB064704LH)
2005 Sep 27 15:28:15 172.20.150.204 %PLATFORM-5-MOD_PWRUP: Module 8 powered up (
Serial number JAB064704LH)
2005 Sep 27 15:29:16 172.20.150.204 %MODULE-5-MOD_REINIT: Re-initializing module 8
2005 Sep 27 15:29:22 172.20.150.204 %PLATFORM-5-MOD_DETECT: Module 8 detected (Serial number JAB064704LH)
 

モジュール 8 で電源投入と再初期化が 3 回行われたことに注目してください。これは、モジュールをオンラインにできなかったことを表しています。スーパーバイザにより、モジュールの電源は切断されました。

ステップ 4 show module internal exception module コマンドを使用して、例外ログを表示します。

switch# show module internal exceptionlog module 8
********* Exception info for module 8 ********
 
exception information --- exception instance 1 ----
device id: 8
device errorcode: 0x40000002
system time: (1127835023 ticks) Tue Sep 27 15:30:23 2005
 
error type: Warning
Number Ports went bad: none
 
exception information --- exception instance 2 ----
device id: 8
device errorcode: 0x40000002
system time: (1127834956 ticks) Tue Sep 27 15:29:16 2005
 
error type: Warning
Number Ports went bad: none
 
exception information --- exception instance 3 ----
device id: 8
device errorcode: 0x40000002
system time: (1127834890 ticks) Tue Sep 27 15:28:10 2005
 
error type: Warning
Number Ports went bad: none
 
exception information --- exception instance 4 ----
device id: 8
device errorcode: 0x40000002
system time: (1127834823 ticks) Tue Sep 27 15:27:03 2005
 

モジュールが再初期化された時刻(システム メッセージから)および例外が発生した時刻(例外ログから)の相関性に注目してください。これは、デバイス ID:8 のモジュールが作動状態に移行する途中で、エラーが発生したことを意味しています。

ステップ 5 show module internal activity module および show module internal event-history module コマンドを使用して、詳細な情報を収集します。

Switch# show module internal event-history module 8
79) Event:ESQ_START length:32, at 665931 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x2710, Ret:success
Seq Type:SERIAL
 
80) Event:ESQ_REQ length:32, at 667362 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x1, Ret:success
[E_MTS_TX] Dst:MTS_SAP_ILC_HELPER(125), Opc:MTS_OPC_LC_IS_MODULE_SAME(2810)
 
81) Event:ESQ_REQ length:32, at 667643 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x2, Ret:success
[E_MTS_TX] Dst:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_INSERTED(1081)
 
82) Event:ESQ_RSP length:32, at 673004 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x2, Ret:success
[E_MTS_RX] Src:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_INSERTED(1081)
 
83) Event:ESQ_REQ length:32, at 673265 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x3, Ret:success
[E_MTS_TX] Dst:MTS_SAP_XBAR_MANAGER(48), Opc:MTS_OPC_LC_INSERTED(1081)
 
85) Event:ESQ_RSP length:32, at 692394 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x3, Ret:(null)
[E_MTS_RX] Src:MTS_SAP_XBAR_MANAGER(48), Opc:MTS_OPC_LC_INSERTED(1081)
 
86) FSM:<ID(3): Slot 8, node 0x0802> Transition at 692410 usecs after Tue Sep 27
15:30:23 2005
Previous state: [LCM_ST_CHECK_INSERT_SEQUENCE]
Triggered event: [LCM_EV_LC_INSERTED_SEQ_FAILED]
Next state: [LCM_ST_CHECK_REMOVAL_SEQUENCE]
 
87) Event:ESQ_START length:32, at 692688 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x2710, Ret:success
Seq Type:SERIAL
 
88) Event:ESQ_REQ length:32, at 696483 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x1, Ret:success
[E_MTS_TX] Dst:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_REMOVED(1082)
 
89) Event:ESQ_RSP length:32, at 698390 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x1, Ret:success
[E_MTS_RX] Src:MTS_SAP_MIGUTILS_DAEMON(949), Opc:MTS_OPC_LC_REMOVED(1082)
 
108) Event:ESQ_REQ length:32, at 715171 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0xc, Ret:success
[E_MTS_TX] Dst:MTS_SAP_XBAR_MANAGER(48), Opc:MTS_OPC_LC_REMOVED(1082)
 
109) Event:ESQ_RSP length:32, at 716623 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0xc, Ret:success
[E_MTS_RX] Src:MTS_SAP_XBAR_MANAGER(48), Opc:MTS_OPC_LC_REMOVED(1082)
 
110) FSM:<ID(3): Slot 8, node 0x0802> Transition at 716643 usecs after Tue Sep 2
7 15:30:23 2005
Previous state: [LCM_ST_CHECK_REMOVAL_SEQUENCE]
Triggered event: [LCM_EV_ALL_LC_REMOVED_RESP_RECEIVED]
Next state: [LCM_ST_LC_FAILURE]
 
111) FSM:<ID(3): Slot 8, node 0x0802> Transition at 716886 usecs after Tue Sep 2
7 15:30:23 2005
Previous state: [LCM_ST_LC_FAILURE]
Triggered event: [LCM_EV_LC_INSERTED_SEQ_FAILED]
Next state: [LCM_ST_LC_FAILURE]
 
112) FSM:<ID(3): Slot 8, node 0x0802> Transition at 717250 usecs after Tue Sep 2
7 15:30:23 2005
Previous state: [LCM_ST_LC_FAILURE]
Triggered event: [LCM_EV_FAILED_MORE3TIMES]
Next state: [LCM_ST_LC_NOT_PRESENT]
 
113) FSM:<ID(3): Slot 8, node 0x0802> Transition at 21633 usecs after Tue Sep 27
15:30:24 2005
Previous state: [LCM_ST_LC_NOT_PRESENT]
Triggered event: [LCM_EV_MODULE_POWERED_DOWN]
Next state: [LCM_ST_LC_NOT_PRESENT]
 
 
Curr state: [LCM_ST_LC_NOT_PRESENT]
 

ステップ 6 この例では、最も新しい時刻(ログの末尾)から逆方向に移動しながらエントリを見ていくと、次のことが推測できます。

Curr state: [LCM_ST_LC_NOT_PRESENT]<---- Indicates that the module is not present.
 
Index 112) Triggered event: [LCM_EV_FAILED_MORE3TIMES] <----Indicates that the module failed repeatedly.
 
Index 111) Triggered event: [LCM_EV_LC_INSERTED_SEQ_FAILED] <---Indicates that the insertion sequence failed.
 
Index 86) Previous state: [LCM_ST_CHECK_INSERT_SEQUENCE]
Triggered event: [LCM_EV_LC_INSERTED_SEQ_FAILED]
Next state: [LCM_ST_CHECK_REMOVAL_SEQUENCE] <---- Indicate that when module was being inserted, the insertion failed and the module was removed.
 
Index 85) Event:ESQ_RSP length:32, at 692394 usecs after Tue Sep 27 15:30:23 2005
Instance:3, Seq Id:0x3, Ret:(null)
[E_MTS_RX] Src:MTS_SAP_XBAR_MANAGER(48),
Opc:MTS_OPC_LC_INSERTED(1081) <---Indicates the event that caused the module insertion to fail. This indicates that xbar_manager failed.
 

この例では、モジュールの挿入中にXBAR Manager が失敗したために、モジュールが起動しなかったことがわかります。


 

リロードされるモジュールのトラブルシューティング

現象 モジュールが自動的にリロードされる。

モジュールがリロードされると、次のシステム メッセージが表示されることがあります。

エラー メッセージ MODULE-2-MOD_NOT_ALIVE: Module [dec] not responding... resetting.

説明 モジュールが hello メッセージに応答していません。モジュールは、Module Manager によってリセットされます。

推奨処置 対処不要です。

エラー メッセージ MODULE-2-MOD_SOMEPORTS_FAILED: Module [dec] reported failure on ports [dec]/[dec]-[dec]/[dec] ([chars]) due to [chars] in device [dec] (error [hex]).

説明 モジュールから、実行時診断で障害を検出したことが報告されました。原因は、一部のポートの障害です。

推奨処置 show module internal all module CLI コマンドを入力して、モジュールの情報を収集します。

エラー メッセージ MODULE-2-MOD_DIAG_FAIL: Module [dec] reported failure on ports [dec]/[dec]-[dec]/[dec] ([chars]) due to [chars] in device [dec] (device error [hex]).

説明 モジュールから、実行時診断で障害を検出したことが報告されました。Module Manager がモジュールの電源を再投入します。

推奨処置 show module internal all module CLI コマンドを入力して、モジュールの情報を収集します。

エラー メッセージ SYSTEMHEALTH-2-OHMS_MOD_PORT_LB_TEST_FAILED: Module [dec] Port [dec] has failed loop back tests.

説明 ポート ループバック テストで、障害が検出されました。

推奨処置 対処不要です。

エラー メッセージ SYSTEMHEALTH-2-OHMS_MOD_SNAKE_TEST_FAILED: Module [dec] has failed snake loopback tests.

説明 SNAKE テストで、障害が検出されました。

推奨処置 対処不要です。

 

表4-12 モジュールが自動的にリロード

現象
考えられる原因
解決方法

モジュールが自動的にリロードされる。

モジュールで、ハートビートのエラーが発生した。

Device Manager で Logs > Switch Resident > Syslog > Server Events を選択するか、または show logging CLI コマンドを使用して、起動の問題を確認します。

モジュールがハートビート要求に応答しなかったことを確認するには、show module internal event-history module CLI コマンドを使用して、次のイベントを探します。

Triggered event: [LCM_EV_LCP_ALIVE_TIMEOUT]

Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

モジュールの実行時診断で障害が検出された。

障害の原因を確認します。詳細については、「リロードされるモジュールの診断」を参照してください。Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

モジュールとファブリックの同期が失われた。

モジュールとファイブリックの同期が失われたことを確認するには、show system internal xbar internal event-history errors CLI コマンドを使用して、
Rx MTS_OPC_SSA_LOST_SYNC_SERIAL slot 8 fabric 0 link 0 と類似したイベントを探します。Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

リロードされるモジュールの診断

モジュールがリロードされる理由を診断する手順は、次のとおりです。


ステップ 1 Device Manager でモジュールを右クリックして Module を選択するか、または show module CLI コマンドを使用して、モジュールのステータスを確認します。

ステップ 2 Device Manager で Logs > Switch Resident > Syslog > Server Events を選択するか、または show logging CLI コマンドを使用して、一般的なリロードの問題を探します。

ステップ 3 show module internal exception module CLI コマンドを使用して、例外ログを表示します。

switch# show module internal exceptionlog module 8
********* Exception info for module 8 ********
exception information --- exception instance 3 ----
device id: 0
device errorcode: 0x40730017
system time: (1127843486 ticks) Tue Sep 27 17:51:26 2005
 
error type: FATAL error
Number Ports went bad:
1,2,3,4,5,6,7,8
 
exception information --- exception instance 4 ----
device id: 5
device errorcode: 0x40730019
system time: (1127843486 ticks) Tue Sep 27 17:51:26 2005
 
error type: Minor error
Number Ports went bad:
8
 

ステップ 4 show module internal event-history module CLI コマンドを使用して、詳細な情報を収集します。

Switch# show module internal event-history module 8
84) FSM:<ID(3): Slot 8, node 0x0802> Transition at 755101 usecs after Tue Sep 27
17:51:26 2005
Previous state: [LCM_ST_LC_ONLINE]
Triggered event: [LCM_EV_LCP_RUNTIME_DIAG_FAILURE]
Next state: [LCM_ST_CHECK_REMOVAL_SEQUENCE]
 
85) Event:ESQ_START length:32, at 755279 usecs after Tue Sep 27 17:51:26 2005
Instance:3, Seq Id:0x2710, Ret:success
Seq Type:SERIAL
 


 

未知の状態になったモジュールのトラブルシューティング

現象 モジュールが未知の状態になっている。

 

表4-13 モジュールが未知の状態

現象
考えられる原因
解決方法

モジュールが未知の状態になっている。

モジュールで、SPROM の障害が発生した。

障害の原因を確認します。詳細については、「未知の状態になっているモジュールの診断」を参照してください。Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

未知の状態になっているモジュールの診断

モジュールが未知の状態になる理由を診断する手順は、次のとおりです。


ステップ 1 Device Manager でモジュールを右クリックして Module を選択するか、または show module CLI コマンドを使用して、モジュールのステータスを確認します。

ステップ 2 Device Manager で Logs > Switch Resident > Syslog > Server Events を選択するか、または show logging CLI コマンドを使用して、一般的な問題を探します。

ステップ 3 未知の状態の考えられる原因を表示するには、show platform internal event-history errors CLI コマンドを使用します。

switch# show platform internal event-history errors
1) Event:E_DEBUG, length:37, at 370073 usecs after Thu Sep 29 17:22:48 2005
[103] unable to init lc sprom 0 mod 8
 
switch# show platform internal event-history module 8
Inside pfm_show_eventlog
Index 1 TOKEN ID: 927
Index 2 TOKEN ID: 910
Module number 0x8
>>>>FSM: <Slot 8> has 2 logged transitions<<<<<
 
1) FSM:<Slot 8> Transition at 500219 usecs after Thu Sep 29 17:22:43 2005
Previous state: [PLTFRM_STATE_MODULE_ABSENT]
Triggered event: [PLTFRM_EVENT_MODULE_INSERTED]
Next state: [PLTFRM_STATE_MODULE_PRESENT]
 
2) FSM:<Slot 8> Transition at 370112 usecs after Thu Sep 29 17:22:48 2005
Previous state: [PLTFRM_STATE_MODULE_PRESENT]
Triggered event: [PLTFRM_EVENT_MODULE_BOOTUP_ERROR]
Next state: [PLTFRM_STATE_MODULE_UNRECOVERABLE_ERROR]
 
 
Curr state: [PLTFRM_STATE_MODULE_UNRECOVERABLE_ERROR]
 


 

スーパーバイザによって検出されないモジュールのトラブルシューティング

現象 モジュールがスーパーバイザによって認識されない。

 

表4-14 モジュールがスーパーバイザによって認識されない

現象
考えられる原因
解決方法

モジュールがスーパーバイザによって認識されない。

モジュールで、SPROM の障害が発生した。

障害の原因を確認します。Device Manager でモジュールを右クリックして Reset を選択するか、または reload module CLI コマンドを使用して、モジュールを再起動します。詳細については、「障害が発生したモジュールの Fabric Manager による再初期化」および「障害が発生したモジュールの CLI による再初期化」を参照してください。

スイッチ上で稼働している Cisco SAN-OS の現在のバージョンでは、このモジュールがサポートされていない。

スイッチ上のソフトウェアのバージョンをアップグレードします。詳細については、「Fabric Manager を使用した SAN-OS ソフトウェアのインストール」および「Cisco SAN-OS ソフトウェアの CLI からのインストール」を参照してください。

スーパーバイザによって検出されないモジュールの診断

モジュールがスーパーバイザによって検出されなかった理由を診断する手順は、次のとおりです。


ステップ 1 Device Manager でモジュールを右クリックして Module を選択するか、または show module CLI コマンドを使用して、モジュールのステータスを確認します。

ステップ 2 Device Manager で Logs > Switch Resident > Syslog > Server Events を選択するか、または show logging CLI コマンドを使用して、一般的な問題を探します。

ステップ 3 考えられる原因を表示するには、show platform internal event-history errors CLI コマンドを使用します。

switch# show platform internal event-history errors
1) Event:E_DEBUG, length:42, at 703984 usecs after Thu Sep 29 17:46:20 2005
[103] Module 8 pwr mgmt I/O cntrl reg 0x74
2) Event:E_DEBUG, length:69, at 703888 usecs after Thu Sep 29 17:46:20 2005
[103] Module 8 pwr mgmt rev reg 0x74 brd present but power ok not set
 
switch# show platform internal event-history module 8
Inside pfm_show_eventlog
Index 1 TOKEN ID: 927
Index 2 TOKEN ID: 910
Module number 0x8
 
>>>>FSM: <Slot 8> has 10 logged transitions<<<<<
 
1) FSM:<Slot 8> Transition at 370299 usecs after Thu Sep 29 17:46:12 2005
Previous state: [PLTFRM_STATE_MODULE_ABSENT]
Triggered event: [PLTFRM_EVENT_MODULE_INSERTED]
Next state: [PLTFRM_STATE_MODULE_PRESENT]
 
2) FSM:<Slot 8> Transition at 698894 usecs after Thu Sep 29 17:46:17 2005
Previous state: [PLTFRM_STATE_MODULE_PRESENT]
Triggered event: [PLTFRM_EVENT_MODULE_SPROM_READ]
Next state: [PLTFRM_STATE_MODULE_POWER_EVAL]
 
3) FSM:<Slot 8> Transition at 705551 usecs after Thu Sep 29 17:46:17 2005
Previous state: [PLTFRM_STATE_MODULE_POWER_EVAL]
Triggered event: [PLTFRM_EVENT_MOD_START_POWER_UP]
Next state: [PLTFRM_STATE_MODULE_START_POWER_UP]
 
4) FSM:<Slot 8> Transition at 110120 usecs after Thu Sep 29 17:46:20 2005
Previous state: [PLTFRM_STATE_MODULE_START_POWER_UP]
Triggered event: [PLTFRM_EVENT_MOD_END_POWER_UP]
Next state: [PLTFRM_STATE_MODULE_POWERED_UP]
 
5) FSM:<Slot 8> Transition at 704067 usecs after Thu Sep 29 17:46:20 2005
Previous state: [PLTFRM_STATE_MODULE_POWERED_UP]
Triggered event: [PLTFRM_EVENT_MODULE_REMOVED]
Next state: [PLTFRM_STATE_MODULE_ABSENT]
 


 

モジュールがスイッチに挿入されると、スーパーバイザ モジュールはそのモジュールの SPROM の内容を読み取ります。モジュールが現在のバージョンの Cisco SAN-OS でサポートされていない場合、モジュールの電源投入はスーパーバイザ モジュールによって行われます。モジュールの電源投入が正常に完了したことを電源ステータスが示さない場合は、モジュール情報がスーパーバイザに伝達されていません。

障害が発生したモジュールの Fabric Manager による再初期化

障害が発生したモジュールを Fabric Manager を使用して再初期化する手順は、次のとおりです。


ステップ 1 Switches > Copy Configuration を選択して、実行コンフィギュレーションをスタートアップ コンフィギュレーションに保存します。

ステップ 2 Switches > Hardware を選択します。次に、Information ペインで Module Status タブを選択し、Reset チェックボックスをオンにして、モジュールのリロードを実行することを指定します。Apply Changes アイコンをクリックします。

ステップ 3 モジュールが起動しない場合は、Switches > Hardware を選択し、S/W Rev カラムを選択してモジュール上にあるソフトウェア イメージのバージョンを確認します。

ステップ 4 モジュール上のソフトウェア イメージが最新バージョンではない場合は、Tools > Other > Software Install を選択して、最新のイメージをスーパーバイザのブートフラッシュ メモリにダウンロードします。

ステップ 5 CLI を使用して、ソフトウェア イメージをスーパーバイザからモジュールへ強制的にダウンロードします。

switch# reload module 2 force-dnld
 

ステップ 6 モジュールが起動しない場合は、Switches > Hardware を選択し、Power Admin カラムを調べてモジュールの電源ステータスを確認します。

ステップ 7 モジュールの電源を投入できない場合は、モジュールをいったん取り外してから再び装着し、Power Admin ドロップダウン メニューから on を選択してモジュールの電源を投入します。

ステップ 8 依然としてモジュールが動作していない場合は、Map ペインでスイッチを右クリックし、Reset を選択してスイッチ全体をリロードします。


 

障害が発生したモジュールの CLI による再初期化

障害が発生したモジュールを CLI を使用して再初期化する手順は、次のとおりです。


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

switch# copy running-config start-config
 

ステップ 2 モジュールをリロードします。

switch# reload module 2
 

ステップ 3 モジュールが動作していない場合は、モジュール上にあるソフトウェア イメージのバージョンを確認します。

switch# show module
 

ステップ 4 モジュール上のソフトウェア イメージが最新バージョンではない場合は、最新のイメージをスーパーバイザのブートフラッシュ メモリにダウンロードします。

switch# copy tftp: bootflash:
 

ステップ 5 ソフトウェア イメージをスーパーバイザからモジュールへ強制的にダウンロードします。

switch# reload module 2 force-dnld
 

ステップ 6 依然としてモジュールが動作していない場合は、モジュールの電源ステータスを確認します。

switch# show environment power
 

ステップ 7 モジュールの電源を投入できない場合は、モジュールをいったん取り外してから再び装着し、続いてモジュールの電源を投入します。

switch# config t
switch(config)# no poweroff module 2
switch(config)# exit
switch#
 

ステップ 8 依然としてモジュールが動作していない場合は、スイッチ全体をリロードします。

switch# reload
 


 

モジュールのリセット

モジュールのリセットおよび再起動の詳細は、「Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング」で説明されています。module reset-reason CLI を実行したときの出力で、リセット理由が「unknown」になっている場合は、ハードウェアの問題を示している可能性があります。この問題は、次のような状況で発生することがあります。

スイッチで電源がリセットされた。これは、電源装置のリセットまたは停電や障害が原因になることがあります。

スーパーバイザ モジュールの前面パネルにあるリセット ボタンが押された。

プロセッサ、ダイナミック メモリ、または I/O をリセットまたはハングアップさせるハードウェア障害が発生した。