Cisco Nexus 5000 トラブルシューティング ガイド

一般的な SAN のトラブルシューティング手順

ステップ 1 ファブリック内の問題に関する情報を収集します。

ステップ 2 スイッチとエンド デバイス間の物理接続を確認します。

ステップ 3 すべての SAN 要素についてファブリックへの登録を確認します。

ステップ 4 エンド デバイス（ストレージ サブシステムおよびサーバ）の設定を確認します。

ステップ 5 エンドツーエンドの接続とファブリックの設定を確認します。

NPV エッジ スイッチの NP アップリンク ポートが初期化ステートでスタックしている

コア NPIV スイッチに接続された NP アップリンク ポートがオンラインにならず、初期化ステートでスタックしています。

考えられる原因

コア スイッチで NPIV がイネーブルになっていない可能性があります。

例：

解決方法

• NPV 外部インターフェイスのステータスを確認します。
コア スイッチで NPIV がイネーブルになっているかどうかを確認します。

例：

• NPIV がディセーブルの場合は、コア スイッチで NPIV をイネーブルにします。

例：

サーバ インターフェイスがアップせず、「NPV upstream port not available」メッセージが表示される

NPV エッジ スイッチに接続されたサーバ ポートがオンラインにならず、show interface コマンドを実行すると「NPV upstream port not available」のステータスが表示されます。

考えられる原因

NPV エッジ スイッチ上のアップストリーム NP_Port とダウンストリーム サーバ F_Port が同じ VSAN に属していない可能性があります。

例：

解決方法

• アップストリーム ポートとサーバ ポートの VSAN メンバーシップを確認します。

例：

• 上の例では、アップストリーム ポート（fc2/1-2）は VSAN 1 に属し、サーバ ポート（fc2/7-8）は VSAN 99 に属しています。
NPV エッジ上の NP ポートと NPIV コア上の F ポートをサーバ ポートと同じ VSAN に移動します。

例：

（注） あるいは、NPIV コア スイッチと NPV エッジ スイッチが F_Port トランキングに対応したスイッチである場合は、それが推奨されるコンフィギュレーションです。

NPV NP ポート間の不均等なロード バランシング

同じ VSAN のメンバーである NP アップストリーム ポートを調べると、ロード バランシングが不均等になっています。

考えられる原因

これは通常の状態で、N5000 Dee Why 4.2(1)N1 リリースよりも前のリリースで提供されているデフォルトの SID/DID ロード バランシングの直接の結果である可能性があります。

解決方法

アップストリーム スイッチが 4.1(3) 以上のコードを実行している MDS スイッチであり、なおかつ NPV F_Port トランキングに対応したスイッチである場合、推奨されるコンフィギュレーションは F_Port トランキング ポート チャネリング機能を実行することです。

例（NPIV コア）：

この例では、fc2/13 と fc2/19 がポートチャネル 100 に追加され、ディセーブルになります。ポートチャネルの相手側のスイッチでも同じ操作を行い、両方で「no shutdown」を実行して両インターフェイスを起動します。

例：

例（NPV エッジ）：

この例では、fc2/1 と fc2/2 がポートチャネル 1 に追加され、ディセーブルになります。ポートチャネルの相手側のスイッチでも同じ操作を行い、両方で「no shutdown」を実行して両インターフェイスを起動します。

例：

ダウンストリーム NPV エッジ スイッチ上のサーバがファブリックにログインしない

ダウンストリーム NPV エッジ スイッチに接続されたサーバがファブリックにログインしません。

考えられる原因

ダウンストリーム NPV エッジ スイッチ上のサーバがファブリックにログインしないか、「waiting for FLOGI」メッセージが表示されます（両方が起こる場合もあります）。

例：

解決方法

• NPV エッジ スイッチとコア スイッチの両方の設定を確認します。F_Port トランキング機能を実行していない場合は、VSAN の不一致がないこと、およびサーバ ポート、NPV NP ポート、NPIV コア F_Port、ストレージ ポートがすべて同じ VSAN に属していてオンラインになっていることを確認します。

• 設定が正しい場合は、問題の所在を突き止めるために Ethanalyzer トレースを収集して、Fabric Login（FLOGI）フレームが受信されていること、Fabric Discovery（FDISC）コマンドとして NPIV コアに送信されていることを確認できます。

Ethanalyzer トレースの例：

• NPV に接続されたサーバ ポートをフラップすることにより、問題を再現します。トレースがブートフラッシュに書き込まれるので、その内容を次のコマンドを使用してスイッチから別の場所にコピーします。

• トレースをコピーしたら、Wireshark を使用してトレースを開き、フローを検証します。

通常の NPV ログイン フローの例：

サーバが物理的に接続されている正確なポートの特定

NPIV スイッチからは、ダウンストリーム NPV 接続サーバが接続されている物理ポートはわかりません。次の手順を使用して、その物理ポートを特定できます。

考えられる原因

NPIV コア スイッチに複数のダウンストリーム NPV エッジ スイッチが接続されている場合、サーバが物理的に接続されている正確なポートを特定するには、次の手順を実行します。

解決方法

• サーバの PWWN と、それに対応するサーバの接続先スイッチを特定します。

例：

この例では、サーバは次の行によって特定されます。

スイッチは次の行によって特定されます。

• NPV エッジ スイッチの IP アドレスを特定します。

例：

• NPV エッジ スイッチに telnet します。

例：

• サーバの PWWN を特定します。

例：

• 上の例に示すようにインターフェイスが FCoE（VFC）インターフェイスである場合は、show interface vfc3 コマンドを使用して、VFC の物理的な宛先ポートを確認します。

4.2(1)N1 F_Port トランキング機能を設定した後、VSAN が初期化ステートでスタックしている

F_Port トランキング ポート チャネル、またはポート チャネルのトランキング メンバーに対して show interface コマンドを実行すると、特定の VSAN が初期化ステートにあり、オンラインになっていません。

考えられる原因

4.2(1)N1 F_Port トランキング機能を設定した後、トランク ポート上の VSAN が初期化ステートでスタックしているように見えます。

例：

Fabric Manager の [Trunk Failures] タブでも、トランク VSAN がリスト表示される場合があります。ただし、これは通常の状態である可能性があります。ある特定の VSAN にダウンストリーム デバイスが 1 つもログインしていない場合、その VSAN は初期化ステートにとどまります。

解決方法

次のコマンドを使用して、問題の VSAN にログインしているデバイスがあるかどうかを確認します。

例：

上の例では、VSAN 200 にログインしているデバイスはありません。

ゾーンセットをアクティブにできず、拡張ゾーン分割モードでゾーン分割を設定できない

ゾーンセットをアクティブにできず、拡張ゾーン分割モードでゾーン分割を設定できません。エラー メッセージ「Zoning database update in progress, command rejected」を受け取る場合があります。

考えられる原因

同じスイッチ上または別のスイッチ上の別のユーザが拡張ゾーン分割設定のロックを保持しています。

解決方法

一般的な方法は、ゾーン分割ロックを解放することです。

ステップ 1 ロックを保持しているスイッチ（ドメイン/IP アドレス）を特定します。

ステップ 2 そのスイッチ上のロックを保持しているユーザを特定します。

ステップ 3 そのスイッチ上のそのユーザのロックをクリアします。

• 同じスイッチで「show zone status vsan <vsan-id>」コマンドを実行して、ロックを保持しているユーザを特定します。

例：

この例では、IP アドレスが 171.165.98.20 のリモート スイッチがロックを保持しています。

• リモート スイッチに接続し、コマンド「show zone status vsan」を実行します。

例：

この例では、ユーザ「Remi」が拡張ゾーン分割のロックを保持しています。

• リモート スイッチ（上の例では N5K2）で、コマンド「no zone commit vsan <vsan-id>」を使用してロックを解放します。

• ロックがクリアされたことを確認するには、コマンド「show zone status vsan <vsan-id>」を実行します。

この時点で、session パラメータは「none」と表示されます。

• ロックがまだ残っている場合は、コマンド「clear zone lock」を使用して、ロックを保持しているスイッチからロックを解除します。

• それでもロックが残っている場合は、次のコマンドを使用して、詳細な分析に役立つ情報を収集します。

ホストがストレージと通信できない

SAN の初期導入時または SAN のトポロジ変更後に、一部のホストがストレージと通信できない場合があります。イニシエータが、ストレージ アレイ内のそれらのホスト用に割り当てられた LUN にアクセスできません。

考えられる原因

ホストとストレージが 2 つの異なるスイッチに接続している場合は、ISL リンク、つまり両方のスイッチに接続している xE ポートが分離されている可能性があります。

特定の VSAN 内で xE ポートが分離される原因としては、次が考えられます。

• ファブリック タイマーの設定ミス

• ポート パラメータの設定ミス

• ゾーン分割の不一致

解決方法

TE ポートでの VSAN 分離を解決する方法は次のとおりです。

• TE ポートで「show interface fc slot/port」コマンドを使用して、VSAN 番号を確認します。

分離された VSAN の番号は、ホストおよびストレージが接続している VSAN の番号と一致している必要があります。

コマンド出力で、「Trunk vsans (isolated) (Vsan <vsan-id>)」を確認します。

• 「show port internal info interface fc slot/port」コマンドを使用して、VSAN 分離の根本原因を突き止めます。

考えられる原因

ホストとストレージが同じ VSAN に属していません。

解決方法

• 「show vsan membership」コマンドを使用して、ホストとストレージの両方が同じ VSAN に属しているかどうかを確認します。

• ホストとストレージが異なる VSAN に属している場合は、コンフィギュレーション モードでコマンド「vsan database」と「vsan vsan-id interface fc slot/port」を使用して、ホストおよびストレージ デバイスに接続されたインターフェイスを同じ VSAN に移動します。

考えられる原因

ホストとストレージが同じゾーンに属していません。ゾーンがアクティブ ゾーンセットに含まれていません。アクティブ ゾーンセットが存在せず、デフォルトのゾーン ポリシーが拒否に設定されています。

解決方法

• コマンド「show zone status vsan-id」を使用して、デフォルトのゾーン ポリシーが拒否に設定されているかどうかを確認します。

例：

ステート「default zone policy permit」は、どのノードからも他のすべてのノードが見えることを意味します。deny は、明示的にゾーンに配置されていないノードはすべて分離されることを意味します。

ゾーン分割を使用していない場合は、「zone default-zone permit」を使用してデフォルトのゾーン ポリシーを変更できますが、これはベスト プラクティスではありません。

• ホストとストレージに対してコマンド「show zone member」を使用して、両者が同じゾーンに属しているかどうかを確認します。同じゾーンに属していない場合は、コマンド「zone name zonename vsan-id」を使用して、その VSAN 内にゾーンを作成します。

例：

コマンド「show zone vsan vsan-id」を使用して、ホストとストレージが同じゾーンに配置されたことを確認します。

• コマンド「show zoneset active vsan vsan-id」を使用して、アクティブ ゾーンセットの名前を確認します。

ホストとストレージを含むゾーンがアクティブ ゾーンセットに含まれていない場合は、コンフィギュレーション モードでコマンド「zoneset name」を使用してゾーンセット サブ モードに入り、「member」コマンドを使用してゾーンをアクティブ ゾーンセットに追加します。

例：

• 「zoneset activate」コマンドを使用して、ゾーンセットをアクティブにします。

例：

2 つのスイッチが E または TE ポートを使用して接続しているときにゾーン結合が失敗する

2 つのスイッチが E または TE ポートを使用して接続しているとき、ゾーン結合が失敗する場合があります。

「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

考えられる原因

2 つのスイッチが同じゾーンセット名とゾーン名を持っているにもかかわらず、それらのゾーン メンバーが異なっている可能性があります。

スイッチ ファブリックを結合するときは、両方のアクティブ ゾーン セットに含まれるゾーンの名前が重複していないか、同じ名前を持つゾーンが正確に同じメンバーを持つ必要があります。これらの条件がどちらも満たされない場合、2 つのファブリックを接続する E ポートは分離した状態になります。

スイッチ ファブリックを結合するプロセスは次のとおりです。

• ソフトウェアがプロトコル バージョンを比較します。プロトコル バージョンが異なる場合、ISL は分離されます。

• プロトコル バージョンが同じである場合、ゾーン ポリシーが比較されます。ゾーン ポリシーが異なる場合、ISL は分離されます。

• ゾーン結合オプションが同じである場合、結合制御設定に基づいて比較が行われます。

– 設定が「制限」の場合、アクティブ ゾーン セットとフル ゾーン セットが同じである必要があります。これらが同じでない場合、リンクは分離されます。

– 設定が「許可」の場合、結合ルールを使用して結合が行われます。ホストとストレージが同じゾーンに属していません。ゾーンがアクティブ ゾーンセットに含まれていません。アクティブ ゾーンセットが存在せず、デフォルトのゾーン ポリシーが「拒否」に設定されています。

解決方法

ゾーン結合が失敗した場合、この問題は次のいずれかの方法を使用して解決できます。

• 両方のゾーンセットのゾーン メンバーが一致するよう修正し、競合を解消します。

– 両方のスイッチで「show zoneset active vsan vsan-id」コマンドを使用して、ゾーンと各ゾーンのメンバーを比較します。

– いずれかのゾーンのメンバーシップを変更して、同じ名前を持つ他のゾーンに合わせます。

• いずれかのスイッチでゾーンセットを非アクティブにし、ゾーン結合プロセスをもう一度行います。

– 「no zoneset activate name zonesetname vsan-id」コマンドを使用して、いずれかのスイッチのゾーンセット設定を非アクティブにします。

– 「show zoneset active」コマンドを使用して、ゾーンセットが削除されたことを確認します。

– 「shutdown」コマンドを使用して結合するゾーンへの接続をシャットダウンしてから、「no shutdown」コマンドを使用して結合するゾーンへの接続を再びアクティブにします。

– 「show zoneset active vsan-id」を使用してすべてのメンバーが正しいことを確認し、「show interface fc slot/port」を使用して VSAN が分離されていないことを確認します。

• スイッチ間でゾーンセットを明示的にインポートまたはエクスポートして、両スイッチを同期します。

– 「zoneset import interface interface-number vsan vsan-id」コマンドまたは「zoneset export interface interface-number vsan vsan-id」コマンドを使用して、いずれかのスイッチでアクティブ ゾーンセットを上書きします。

– 「show interface fc slot/port」を使用して、この中断操作の後に VSAN が分離されていないことを確認します。

ゾーンセットのアクティブ化の失敗

ゾーンセットのアクティブ化が失敗したとき、「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

考えられる原因

ゾーン データベースのサイズが 2048 KB を超えているときに新しいスイッチがファブリックに加入した場合、ゾーンセットのアクティブ化が失敗することがあります。

解決方法

• 「show zone analysis active vsan vsan-id」コマンドを使用して、アクティブ ゾーンセット データベースを分析します。フォーマット サイズが 2048 KB を超えていないかどうかを確認します。

2048 KB の上限を超えている場合は、ゾーンまたはゾーン内のデバイスをいくつか削除する必要があります。

例：

• 「show zone internal change event-history vsan vsan-id」コマンドを使用して、ゾーンセット アクティブ化の問題があるかどうかを確認します。

• この問題をさらにトラブルシューティングするには、「show tech-support zone」コマンドと「show logging log」コマンドの出力をキャプチャします。

2 つのスイッチ間でのフル ゾーン データベース同期の失敗

2 つのスイッチが E または TE ポートを使用して接続していて、それらのスイッチが異なるゾーンセット配信ポリシーを持つとき、フル ゾーン データベース同期が失敗する場合があります。ファブリックの分離/結合の結果として、あるファブリックの実行コンフィギュレーションにフル ゾーンセット データベースが含まれないことがあります。

考えられる原因

ゾーンセットの配信は、隣接スイッチへの結合要求の送信時、またはゾーンセットのアクティブ化の際に行われます。

ゾーン配信ポリシーは 2 つのスイッチで異なるように設定できますが、そうすると同期が失敗する場合があります。

解決方法

「show zone status」コマンドを使用して、両方のスイッチの配信ポリシーを確認します。

例：

配信ポリシーが「active only」に設定されている場合は、アクティブ ゾーンセットが配信されます。また、配信ポリシーがフルに設定されていることも確認します。

コンフィギュレーション モードで VSAN ごとにすべてのスイッチへのフル ゾーン セットおよびアクティブ ゾーン セットの配信をイネーブルにするには、「zoneset distribute full vsan vsan-id」コマンドを使用します。

VSAN 内のスイッチのデフォルト ゾーン ポリシーの不一致が原因で、ストレージへのアクセス時に予期しない結果が起こる

基本ゾーン モードで VSAN 内のすべてのスイッチのデフォルト ゾーン ポリシーが一致していない場合、ホストがストレージにアクセスするときに予期しない結果が起こる場合があります。

考えられる原因

デフォルト ゾーン ポリシーが「permit」に設定されていて、VSAN にアクティブ ゾーンセットがない場合は、その VSAN のどのメンバーからも他のすべてのノードが見えます。

解決方法

1 つの方法は、ゾーン運用モードを基本から拡張に移行することです。拡張ゾーン分割では、ゾーン設定が VSAN 内のすべてのスイッチ間で同期されます。これにより、デフォルト ゾーン ポリシーが一致しない可能性はなくなります。

• 「show zone status」コマンドを使用して、ゾーンのステータスを表示します。

• 「zone default-zone」コマンドを使用してデフォルト ゾーン ポリシーを設定し、「zone mode enhanced vsan-id」コマンドを使用して運用モードを拡張ゾーン分割モードに設定します。

解決方法

もう 1 つの方法を次に示します。

• VSAN 内のすべてのスイッチで「show zone status」を使用して、運用モードとデフォルトゾーン ポリシーを確認します。

• 「zone mode basic」コマンドを使用して、基本モードでないスイッチをすべて変更します。

• VSAN 内の各スイッチで「zone default-zone」コマンドを使用して、同じデフォルト ゾーン ポリシーを設定します。

スイッチを SAN PortChannel 経由で接続しようとするとファイバ チャネル ポートがダウンする

スイッチを SAN PortChannel 経由で接続しようとすると、ファイバ チャネル ポートがダウンします。

「show interface brief」コマンドを実行すると、次のように出力されます。

考えられる原因

コンフィギュレーションでいずれかの SAN ポートチャネル互換性パラメータの設定が間違っています。

互換性チェックでは、チャネルのすべての物理ポートで同一のパラメータ設定が確実に使用されるようにします。そうでない場合、ポートが PortChannel に所属できません。互換性チェックは、ポートを PortChannel に追加する前に実施します。

互換性チェックでは、PortChannel の両側で次のパラメータと設定が一致していることを確認します。

• 機能パラメータ
（インターフェイスのタイプ、両側ともギガビット イーサネットまたは両側ともファイバ チャネル）。

• 管理互換性パラメータ
（速度、モード、レート モード、ポート VSAN、許可 VSAN リスト、ポート セキュリティ）。

• 動作パラメータ
（リモート スイッチ WWN とトランキング モード）。

解決方法

• 「show san-port-channel compatibility-parameters」を使用して、コンフィギュレーションでチェックするパラメータを確認します。

一般に、コンフィギュレーションを修正して FC ポートを shut/no shut した場合、ポートは正常に回復します。

• 別のエラー メッセージが表示されて問題が解決しない場合は、次のいずれか、または複数のコマンドを実行してさらにデバッグします。

新しく追加したファイバチャネル インターフェイスが SAN PortChannel でオンラインにならない

新しいファイバチャネル インターフェイスを追加したとき、そのインターフェイスが SAN PortChannel でオンラインになりません。

設定操作時に次のエラー メッセージが表示される場合があります。

考えられる原因

ポート チャネル モードが「on」に設定されています。

スイッチ間の不整合な状態を防ぐため、およびスイッチ間の整合性を維持するためにデフォルトの ON モードを使用した場合、ポートはシャットダウンします。

解決方法

「no shutdown」を使用して、ポートを再び明示的にイネーブルにします。

考えられる原因

インターフェイス パラメータが既存の SAN PortChannel と互換性がありません。

解決方法

force オプションを使用して、物理インターフェイスに SAN PortChannel のパラメータを受け入れるよう強制します。インターフェイス サブ コンフィギュレーション モードで、「channel-group <channel-group number> force」コマンドを使用します。

トランキングを設定できない

インターフェイス コンフィギュレーション モードでトランキングを設定できません。

CLI 出力に次のエラー メッセージが表示される場合があります。

考えられる原因

トランキング プロトコルがディセーブルになっています。

解決方法

「trunk protocol enable CLI」コマンドを使用して、トランキングをイネーブルにします。

VSAN トラフィックがトランクを通過しない

VSAN トラフィックがトランクを通過できません。

ホストから、同じ VSAN に属していて、なおかつ TE ポートを使用して 2 つの異なるスイッチに接続されたターゲットにアクセスできません。VSAN トラフィックがトランクを通過できません。ホストからターゲットへのパスによっては、パフォーマンスが低下する場合や、どのディスクにもアクセスできない場合があります。

考えられる原因

VSAN が allowed-active VSAN リストに登録されていません。

解決方法

「switchport trunk allowed vsan CLI」コマンドを使用して、VSAN を allowed-active リストに追加します。

SAN PortChannel のインターフェイスの下にある特定の VSAN で xE ポートが分離される

SAN PortChannel のインターフェイスの下にある特定の VSAN で xE ポートが分離されます。

ロギング ログに次のエラー メッセージが表示される場合があります。

考えられる原因

特定の VSAN 内で xE ポートが分離される原因としては、次が考えられます。

• ファブリック タイマーの設定ミス

• ポート パラメータの設定ミス

• ゾーン分割の不一致

解決方法

TE ポートでの VSAN 分離を解決するには、TE ポートで「show interface fc slot/port」コマンドを使用して VSAN 番号を確認します。分離された VSAN の番号は、ホストおよびストレージが接続している VSAN の番号と一致している必要があります。

コマンドの出力で、「Trunk vsans (isolated) (Vsan <number>)」のような情報を探します。

「show port internal info interface san-port-channel <number>」コマンドを使用して、VSAN 分離の原因を突き止めます。

SAN ポートチャネル インターフェイスが作成できない

SAN ポートチャネル インターフェイスが作成できません。

コンフィギュレーション モード時に次のエラー メッセージが表示される場合があります。

考えられる原因

ユーザは次のメッセージを受け取ります。

（注） SAN ポートチャネルは最大 4 つ作成できます（NX-OS 4.2(1)N1(1) を含む）。これはソフトウェアの制限です。

解決方法

特定の番号を持つ SAN ポートチャネルを作成する場合に、4 つの SAN ポートチャネルがすでに設定されているときは、使用頻度の低いいずれかの SAN ポートチャネルを削除する必要があります。「no interface san-port-channel x」コマンドを使用して、いずれかの SAN ポートチャネルを削除します。

考えられる原因

ユーザは次のメッセージを受け取ります。

解決方法

SAN ポートチャネルを設定する際に 1 ～ 256 の範囲の別の番号を選択する必要があります。

「show port-channel usage」コマンドを使用して、既存のポートチャネルで使用されている番号を確認します。

例：

概要

ファイバ チャネル ファブリックは、そのクライアント（ファイバ チャネル ノード）に対して一連のサービスを提供します。各ノードはこれらのファイバ チャネル サービス（FC サービス）を使用してストレージ ネットワークとやり取りし、接続ステート、接続パラメータ、設定、トポロジ変更などの情報を交換します。

FC サービスには、Well Known Address（WKA; well-known アドレス）を持つポートへのログインを通じてアクセスできます。WKA は、ファブリックの内部使用（通常はファブリック サービス）のために予約されているポート FC ID です。

次の表に、well-known アドレスと各アドレスに関連するサービスを示します。
（出典：www.t11.org）

ファイバ チャネル ポートが初期化ステートにとどまる

ファイバ チャネル F タイプ ポートがオンラインにならず、初期化ステートでスタックしています。

「show interface fc slot/port」コマンドを実行すると、次のように出力されます。

ファイバ チャネル ポートは、リンク レベル初期化が正常に完了した後、初期化ステートに入ります。F タイプ ポートでは、次のステップは FLOGI（ファブリック ログイン）プロセスを完了することです。ポートは FLOGI プロセスが完了するまで初期化ステートにとどまります。

考えられる原因

リンク パートナーがバイパス モードになったことが原因で、ポートがアップしています。

解決方法

「show hardware internal fc-mac <slot-number> port <port-number> statistics」コマンドを使用して、リンク初期化が正常に完了した後に Class-3 入力カウンタが増加しているかどうかを確認します。

例：

考えられる原因

FLOGI パケットが、FC-MAC から FLOGI サーバまでのデータ パス上のどこかでドロップされました。

解決方法

次の方法を検討します。

• 「show hardware internal fc-mac <slot-number> port <port-number> statistics」コマンドを使用して、Class-3 パケットのカウンタを確認します。

• 「show flogi internal all interface fc slot/port」コマンドの出力を分析し、パス上のどこで FLOGI パケットのドロップが起こり得るかを調べます。

• 「Fport server fault-injection」テーブルをチェックし、「Invalid」、「Drop」の FLOGI パケットがないかどうかを確認します。

• 「shut」CLI コマンド、「no shut」コマンドの順に入力して、FC スロット/ポートをいったんディセーブルにしてからイネーブルにします。

• これで問題が解決しない場合は、同じ FC モジュールの別のポートまたは他の FC モジュールのポートに接続を移動してみます。

• それでも問題が解決しない場合は、次のコマンドを使用して、詳細な分析に役立つ情報を収集します。

次のコマンドを使用して、debug flogi をキャプチャします。

特定の VSAN トラフィックが SAN ファブリック経由でルーティングされない

VSAN の実装では、設定された各 VSAN がそれぞれ異なるファブリック サービスのセットをサポートできます。そのようなサービスの 1 つに FSPF ルーティング プロトコルがあります。このプロトコルは VSAN ごとに個別に設定できます。不適切なトラフィック エンジニアリング機能が使用されている場合、特定の VSAN トラフィックがルーティングされないことがあります。

考えられる原因

FSPF hello 間隔が適切に設定されていません。

「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

解決方法

NX-OS CLI を使用して ISL 上の不適切な hello 間隔を解決するには、次の手順を実行します。

ステップ 1 「debug fspf all」コマンドを使用して不適切な hello 間隔のメッセージを探すか、
「show logging」ログの最後のメッセージをチェックしてエラー メッセージを探します。

デバッグ出力では、次のメッセージが生成されます。

ステップ 2 「undebug all」コマンドを使用して、デバッグをオフにします。

ヒント ヒント：いずれかのデバッグ コマンドを入力する前に、telnet または SSH セッションをもう 1 つ開きます。デバッグ出力で現在のセッションがあふれた場合は、2 番目のセッションを使用して「undebug all」コマンドを入力し、デバッグ メッセージの出力を停止します。

ステップ 3 「show fspf vsan <vsan-id> interface」コマンドを使用して、両方のスイッチで FSPF の設定を表示します。

例：

（注） この例では、

• 最初のスイッチでは、Hello タイマーがデフォルト（20 秒）に設定されていません。ネイバー スイッチ（Nexus 5000）の設定を確認して設定値を合わせます。

• FSPF が FULL ステートではありません。これは問題があることを示します。

ステップ 4 インターフェイス コンフィギュレーション モードで、両方のスイッチの fspf hello-interval が同じ値になるように変更します。

例：

ステップ 5 変更後、FSPF が FULL ステートになったことを確認します。

考えられる原因

FSPF デッド間隔が適切に設定されていません。

「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

解決方法

NX-OS CLI を使用して ISL 上のデッド間隔の不一致を特定するには、次の手順を実行します。

ステップ 1 「debug fspf all」コマンドを使用して不適切なデッド間隔のメッセージを探すか、
「show logging」ログの最後のメッセージをチェックしてエラー メッセージを探します。

デバッグ出力では、次のメッセージが生成されます。

ステップ 2 「undebug all」コマンドを使用して、デバッグをオフにします。

ヒント ヒント：いずれかのデバッグ コマンドを入力する前に、telnet または SSH セッションをもう 1 つ開きます。デバッグ出力で現在のセッションがあふれた場合は、2 番目のセッションを使用して「undebug all」コマンドを入力し、デバッグ メッセージの出力を停止します。

ステップ 3 「show fspf vsan <vsan-id> interface」コマンドを使用して、両方のスイッチで FSPF の設定を表示します。

例：

（注） この例では、

• 最初のスイッチでは、デッド タイマーがデフォルト（80 秒）に設定されていません。ネイバー スイッチ（MDS）の設定を確認して設定値を合わせます。

• FSPF が FULL ステートではありません。これは問題があることを示します。

ステップ 4 インターフェイス コンフィギュレーション モードで、両方のスイッチの fspf dead-interval が同じ値になるように変更します。

ステップ 5 変更後、FSPF が FULL ステートになったことを確認します。「show fspf internal route vsan <vsan-id>」コマンドを使用して、VSAN トラフィックのルートがあることを確認します。

例：

考えられる原因

スイッチにリージョンの不一致があります。

「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

解決方法

NX-OS CLI を使用してスイッチ上のリージョン不一致の問題を特定するには、次の手順を実行します。

ステップ 1 「show fspf vsan <vsan-id>」コマンドを使用して、VSAN に現在設定されているリージョンを表示します。

例（リージョン値は 2。デフォルトのリージョン値は 0）：

ステップ 2 「debug fspf all」コマンドを使用して、存在しないリージョンに関するメッセージを探します。

例：

ネイバー スイッチがアドバタイズしているリージョンは 0 です。FSPF は ISL ごとに INIT ステートにあります。

例：

ステップ 3 「undebug all」コマンドを使用して、デバッグをオフにします。

ステップ 4 「show fspf vsan <vsan-id>」コマンドを使用して FSPF の設定を表示し、自律リージョンを確認します。

例：

ステップ 5 「fspf config vsan」コマンドを使用して FSPF コンフィギュレーション モードに入り、「region」コマンドを使用してリージョンを変更します。リージョンは、VSAN 内のすべてのスイッチで一致する必要があります。

例：

無効な FLOGI が多すぎることが原因で、ファイバ チャネル ポートが一時停止する

NPV 機能がイネーブルになっている Cisco Nexus 5000、またはファブリック モードで動作している Cisco Nexus 5000 に接続されたファイバ チャネル ノードが、FLOGI 拒否が原因で SAN ファブリックにログインできません。

「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

インターフェイスのステータスは「invalidFlogis」を示します。

考えられる原因

その VSAN の FC ID 永続性テーブルがいっぱいになっている可能性があります。Nexus 5000 シリーズ スイッチが NPV エッジ スイッチとして設定されている場合は、NPV コア スイッチの FC ID 永続性テーブルがいっぱいになっている可能性があります。

FC ID：

Cisco Nexus 5000 シリーズ スイッチにログインした N ポートには、FC ID が割り当てられます。デフォルトでは、永続的 FC ID 機能はイネーブルです。この機能がディセーブルの場合は、次のようになります。

• N ポートが Cisco Nexus 5000 シリーズ スイッチにログインします。要求元 N ポートの WWN および割り当てられた FC ID が維持され、揮発性キャッシュに格納されます。揮発性キャッシュの内容は、再起動時に保存されません。

• スイッチは、FC ID と WWN のバインディングをベストエフォート方式で保持するように設計されています。たとえば、スイッチから 1 つの N ポートを切断したあとに、別のデバイスから FC ID が要求されると、この要求が許可されて、WWN と初期 FC ID の関連付けが解除されます。

• 揮発性キャッシュには、WWN と FC ID バインディング エントリを 4000 まで格納できます。このキャッシュが満杯になると、新しい（より最近の）エントリによって、キャッシュ内の最も古いエントリが上書きされます。この場合、最も古いエントリの対応する WWN と FC ID の関連付けが失われます。

• N ポートを取り外し、同じスイッチの任意のポートに接続すると、（このポートが同じ VSAN に属するかぎり）この N ポートには同じ FC ID が割り当てられます。

永続的 FC ID は、選択的に消去できます。現在使用中のスタティック エントリおよび FC ID は、削除できません。

解決方法

「show flogi internal」コマンドを使用して、FLOGI エラー メッセージを確認します。

例：

「show fcdomain address-allocation」コマンドを使用して FC ドメイン アドレス割り当てテーブルをチェックし、空き FC ID を確認します（NPV がイネーブルの場合は、NPV コア スイッチでこのコマンドを実行します）。

例：

自動エリアリストおよび永続的 FCID を検索するには、「show flogi auto-area-list」コマンドと「show fcdomain fcid persistent」コマンドを使用します。

例：

FCID が十分にない場合は、「purge fcdomain」コマンドを使用して、指定した VSAN のダイナミック FC ID と未使用の FC ID を消去できます。

例：

ポートはすぐにアップします。

また、HBA が S_ID != 0x0 でログインしようとしている可能性もあります。

これが起こった場合に、永続性テーブルに HBA の WWN に対応するエントリがないときは、HBA で使用されている S_ID をその HBA 自体に割り当ててみます。

S_ID がすでに使用されているか、間違ったドメインに属する場合は、fcdomain によって要求が拒否されます。数回再試行した後、ポートが一時停止します。

このモードになった HBA は、FCID 空間にあるすべての FCID（0x00.00.01 から、最大ですべての 0xDD.AA.PP 番号まで）を使用してログインを試みます。

この動作は「show flogi internal event-history msgs」で確認できます。

「show flogi internal event-history msgs」（HBA がさまざまな FCID を使用してログインを試みています）

例：

この場合の解決方法は、次の例に示すように、永続性テーブルに HBA の WWN に対応するエントリを手動で設定することです。その他に、デバイスの電源を再投入するという方法もあります。こうすると通常、HBA はまず S_ID=0x0 を使用した通常の FLOGI を実行します。

例：

それでも問題が解決しない場合は、次のコマンドを使用して、詳細な分析に役立つ情報を収集します。

ファイバ チャネル ノードの古い FCNS エントリがある

ファイバ チャネル ノードは SAN ファブリックにログイン（FLOGI）できますが、それらのノードの FCNS エントリが不完全です。サーバはそれらのターゲットに到達できません。

その結果、FCNS データベースで「fc4-types:fc4_features」が空になります。

考えられる原因

Nexus 5000 シリーズ スイッチが NPV コア（NPIV を装備）として設定され、レガシー ゲートウェイ スイッチに接続されたトポロジにおいて、ファイバ チャネル ノードが自身の FC4 タイプと FC4 機能を FCNS データベースに登録していない可能性があります。fc4-types:fc4_features を確認するには、次の例に示すように、「show fcns database detail」コマンドを使用します。

例：

レガシー ゲートウェイ スイッチの中には、スイッチの FCID のエリア部分と、そのポートを通じてログインされたすべてのブレードの FCID のエリア部分が同じでなければならないものがあります。

しかし、Qlogic HBA に関する古い問題が原因で、Cisco Nexus 5000 ドメイン サーバは、デフォルトである特定の OUI と一致する Qlogic HBA に対してそれぞれ異なるエリアを割り当てます。したがって、レガシー ゲートウェイの要件とシスコのドメイン割り当て方式の間に競合が起こります。シスコは、現場で使用されている既存の古い Qlogic HBA をサポートするため、引き続きこの方式をサポートします。

解決方法

まず、使用しているすべての Qlogic OUI について「no fcid-allocation area company <oui>」を設定します（今後、フラットな FCID 割り当てが行われるようにします）。次に、影響を受けるすべてのブレードを強制的にファブリックからログアウトさせ、すでに作成された永続的 FCID エントリを Nexus 5000 スイッチ コンフィギュレーションから削除します。最後に、ブレードに再度ログインさせます。

次の「show flogi database」の出力例では、すべてのデバイスが一意のエリア ID（x01、x08、x0c）を取得しています。

例：

レガシー スイッチに特有のエリア ID 要件のため、最後の 2 つのブレードもエリアを x01 にする必要があります。次の手順に従って、Qlogic アダプタを強制的に再ログインさせて 0x6201xx の範囲内の FCID が取得されるようにします。

ステップ 1 この状況にある OUI と一致するすべての WWN について、今後の FCID 割り当て方式がフラットになるよう設定（強制）します。

ステップ 2 再設定中の FCID を強制的にファブリックからログアウトさせます。

（注） 単に、そのサーバのプライマリ アップリンクとして機能している Nexus 5000 インターフェイスをシャットダウンするだけでは不十分です。そうすると、別のインターフェイスを通じてログインするだけです。適切な方法は、影響を受けるブレードをシャットダウンして、WWN の FLOGI を確実に消去することです。

ステップ 3 次の例に示すように、永続的 FCID 割り当てのために自動的に作成された設定エントリを削除します。

例：

ステップ 4 ブレードを起動して、適切な FCID が取得されるようにします。

例：

FC ドメイン ID の重複が原因でインターフェイスが分離される

xE ポート タイプを使用して FC スイッチに接続された（ファブリック モードの）Cisco Nexus 5000 のファイバ チャネル インターフェイスまたは SAN ポートチャネル インターフェイスが、ドメインの重複が原因で分離されます。「show logging」ログに表示される場合があるログ メッセージの例を次に示します。

例：

考えられる原因

2 つのスイッチ ファブリックが結合できない可能性があります。2 台以上のスイッチを含む 2 つのファブリックが接続されている場合に、それらのファブリックが共通の割り当て済みドメイン ID を少なくとも 1 つ持ち、さらに自動再設定オプションがディセーブルになっているとき（このオプションはデフォルトでディセーブルになっています）、2 つのファブリックの接続に使用される E ポートは、ドメイン ID の重複が原因で分離されます。

ファイバ チャネル ネットワークでは、新しいスイッチが既存のファブリックに追加されると、主要スイッチによってドメイン ID が割り当てられます。ただし、2 つのファブリックが結合するときは、主要スイッチ選出プロセスによって、既存のいずれのスイッチが結合ファブリックの主要スイッチになるかが決定されます。

新しい主要スイッチの選出は次のルールに従います。

• 空でないドメイン ID リストを持つスイッチの方が、空のドメイン ID リストを持つスイッチよりも優先されます。主要スイッチは、空でないドメイン ID リストを持つファブリック内のスイッチになります。

• 両方のファブリックがドメイン ID リストを持つ場合、2 台の主要スイッチ間の優先順位はスイッチ プライオリティの設定値によって決まります。これはユーザが設定可能なパラメータです。パラメータの値が小さいほど優先順位が高くなります。

• 上記の 2 つの基準によって主要スイッチを決定できない場合は、2 台のスイッチの WWN によって主要スイッチが決定されます。WWN の値が小さいほどスイッチ プライオリティが高くなります。

解決方法

FC ドメイン ID の重複を解決するには、分離されたスイッチ用の新しいスタティック ドメイン ID を手動で設定して重複するスタティック ドメイン ID を変更するか、スタティックなドメイン割り当てをディセーブルにして、ファブリック再設定後にスイッチが新しいドメイン ID を要求するようにします。

NX-OS CLI を使用してスタティック ドメイン ID を割り当てるには

VSAN 内のスイッチに接続されたデバイスはすべて、新しいドメイン ID が割り当てられるときに新しい FC ID を取得します。ホストまたはストレージ デバイスの FC ID が変更された場合、一部のホストまたはストレージ デバイスが期待どおりに機能しない可能性があります。

CLI を使用して FC ドメイン ID の重複を確認し、新しいドメイン ID を再割り当てするには、次の手順を実行します。

ステップ 1 「show interface fc <slot/port>」コマンドを実行して、E ポートの分離エラー メッセージを表示します。

例：

「show interface san-port-channel <channel-id>」コマンドを実行して、特定の VSAN の分離エラーを表示します。

例：

ステップ 2 「show fcdomain domain-list vsan <vsan-id>」コマンドを使用して、現在ファブリック内にあるドメインを表示します。

例（ドメイン ID 44 の重複が原因でスイッチが分離されています）：

SAN ポートチャネル インターフェイスの下の特定の VSAN で分離が発生している場合は、次の例に示すように、「show port internal info interface san-port-channel <channel-id> vsan <vsan-id>」を使用してエラーを表示できます。

例：

ステップ 3 「fcdomain domain domain-id [static | preferred] vsan vsan-id」コマンドを使用して、重複しているいずれかのドメイン ID のドメイン ID を変更します。

• static オプションを指定すると、スイッチはその特定のドメイン ID を要求します。その特定のアドレスを取得できない場合は、ファブリックから分離されます。

• preferred オプションを指定すると、スイッチは指定されたドメイン ID を要求します。その ID を取得できない場合は、別の ID を受け入れます。

ステップ 4 「fcdomain restart vsan」コマンドを使用して、Domain Manager を再起動します。

static オプションは、中断再起動または非中断再起動後の実行時に適用できますが、preferred オプションは中断再起動後の実行時にだけ適用できます。

（注） ドメイン ID の再起動は中断的です。そのドメインにログインしていたファイバ チャネル ノードはいったんログアウトし、再びログインします。中断再設定が発生すると、データ トラフィックが影響を受けることがあります。

ファブリック再設定後にダイナミック ドメイン ID を割り当てるには

ファブリック再設定を使用してドメイン ID を再割り当てし、ドメイン ID の重複を解決できます。ファブリックを接続する前に両方のスイッチで auto-reconfigure オプションをイネーブルにした場合、中断再設定（RCF）が発生します。RCF が発生すると、新しい主要スイッチ選出が自動的に強制実行され、新しいドメイン ID が異なるスイッチに割り当てられます。

NX-OS CLI でファブリック再設定を使用して特定の VSAN 用のドメイン ID を再割り当てするには、次の手順を実行します。

ステップ 1 「show fcdomain domain-list」コマンドを使用して、スイッチにドメイン ID がスタティックに割り当てられているかどうかを確認します。

ステップ 2 ドメイン ID がスタティックに割り当てられている場合は、「no fcdomain domain」コマンドを使用してスタティックな割り当てを解除します。

ステップ 3 「show fcdomain vsan <vsan-id>」コマンドを使用して、RCF 拒否オプションがイネーブルになっているかどうかを確認します。

例：

ステップ 4 rcf-reject オプションがイネーブルになっている場合は、interface コマンドを使用してから、インターフェイス モードで「no fcdomain rcf-reject vsan <vsan-id>」コマンドを使用します。

例：

ステップ 5 両方のスイッチで、EXEC モードで「fcdomain auto-reconfigure vsan <vsan-id>」コマンドを使用して、Domain Manager の再起動後に auto-reconfiguration がイネーブルになるようにします。

ステップ 6 「fcdomain restart vsan <vsan-id>」コマンドを使用して、Domain Manager を再起動します。

これは中断操作/中断再設定であり、データ トラフィックが影響を受けることがあります。

概要

CFS の問題をトラブルシューティングする際は、まず次のことを確認します。

• 影響を受けるすべてのスイッチで、同じアプリケーションについて CFS がイネーブルになっていることを確認します。

• 影響を受けるすべてのスイッチで、同じアプリケーションについて CFS 配信がイネーブルになっていることを確認します。

CFS リージョン機能を使用している場合は、影響を受けるすべてのスイッチでアプリケーションが同じリージョンにあることを確認します。

• アプリケーションの保留中の変更がないこと、および CFS がイネーブルになっているアプリケーションのすべての設定変更について CFS コミットが発行されたことを確認します。

• 予期しない CFS ロック済みセッションがないことを確認します。

予期しないロック済みセッションがある場合はクリアします。

CLI を使用した CFS の確認

CLI を使用して CFS を確認するには、次の手順を実行します。

ステップ 1 デフォルトでは、CFS 配信はイネーブルに設定されています。アプリケーションは、ファブリック内のアプリケーションが存在するすべての CFS 対応スイッチにデータと設定情報を配信できます。これが通常の動作モードです。スイッチでの CFS 配信のステートを確認するには、「show cfs status」コマンドを実行します。

例：

ステップ 2 アプリケーションが一覧表示され、イネーブルになっていることを確認するには、すべてのスイッチで「show cfs application」コマンドを実行します。

例：

（注） Physical スコープは、そのアプリケーションの設定がスイッチ全体に適用されることを意味します。Logical スコープは、そのアプリケーションの設定が特定の VSAN に適用されることを意味します。

ステップ 3 ある特定のアプリケーションが CFS に登録されているスイッチのセットを確認します。物理スコープ アプリケーションでは「show cfs peers name application-name」コマンドを使用し、論理スコープ アプリケーションでは「show cfs peers name application-name vsan vsan-id」コマンドを使用します。

例：

（注） 論理アプリケーションに対して「show cfs peers name application-name」コマンドを実行すると、すべての VSAN のピアが表示されます。

例：

ステップ 4 ファブリック内のすべてのスイッチが 1 つの CFS ファブリックを構成するか、または多数の分割された CFS ファブリックを構成するかを確認するには、「show cfs merge status name application-name」コマンドと「show cfs peers name application-name」コマンドを実行して出力を比較します。2 つの出力に示されるスイッチのリストが同じである場合は、スイッチのセット全体が 1 つの CFS ファブリックを構成しています。この場合、結合ステータスはすべてのスイッチで常に「成功」になります。

例：

「show cfs merge status name」コマンドの出力に示されるスイッチのリストが「show cfs peers name」コマンドの出力よりも短い場合、ファブリックは複数の CFS ファブリックに分割されていて、結合ステータスが「失敗」、「保留中」、「待機中」のいずれかになる場合があります。

結合の失敗のトラブルシューティング

結合時、結合するファブリック内の結合マネージャは相互にコンフィギュレーション データベースを交換します。いずれかのファブリックのアプリケーションが情報を結合し、結合が成功したかどうかを判断して、結合されたファブリック内のすべてのスイッチに結合ステータスを通知します。

結合が成功した場合、結合されたデータベースが結合ファブリック内のすべてのスイッチに配信され、新規ファブリック全体が一貫したステートになります。結合の失敗は、結合するファブリックに結合できない不整合データが含まれることを示します。

新しいスイッチをファブリックに追加した場合に、あるアプリケーションの結合ステータスが長時間「In Progress」を示すときは、いずれかのスイッチにそのアプリケーションのアクティブなセッションが存在する可能性があります。「show cfs lock」コマンドを使用して、すべてのスイッチでそのアプリケーションのロック ステータスを確認します。ロックが存在する場合、結合プロセスは進みません。変更をコミットするかセッションのロックをクリアして、結合プロセスを進めます。

（注） 結合の失敗は正しく分析する必要があります。ブランク コミットを行うスイッチを選ぶときは注意してください。小さいコンフィギュレーションによって大きいコンフィギュレーションが消去される場合があります。

CLI を使用した結合の失敗からの回復

CLI を使用して結合の失敗から回復するには、次の手順を実行します。

ステップ 1 結合の失敗を示すスイッチを特定するには、「show cfs merge status name application-name」コマンドを実行します。

例：

ステップ 2 結合の失敗の詳細な説明を表示するには、「show cfs internal session-history name application name detail」コマンドを実行します。

例：

ステップ 3 コンフィギュレーション モードに入り、「application-name commit command」コマンドを実行してファブリック内のすべてのピアを同じコンフィギュレーション データベースに戻します。

例：

ロックの失敗のトラブルシューティング

ファブリック内で設定を配信するためには、まずファブリック内のすべてのスイッチでロックを取得する必要があります。ロックが取得されたら、コミットを実行してファブリック内のすべてのスイッチにデータを配信できます。その後でロックが解放されます。

別のアプリケーション ピアによってすでにロックが取得されている場合は、新しい設定変更をコミットできません。これは通常の状況であり、ロックが解放されるまでアプリケーションの変更を延期する必要があります。この項のトラブルシューティング手順を実行するのは、ロックが適切に解放されていないと確信される場合に限ります。

ロックは、管理者が CFS イネーブル アプリケーションの変更を設定するときに発生します。2 人の管理者が同じスイッチで同じアプリケーションを設定しようとした場合は、一方の管理者のみにロックが与えられます。もう一方の管理者は、最初の管理者が変更をコミットまたは廃棄するまで、そのアプリケーションに変更を加えることはできません。アプリケーションのロックを保持している管理者の名前を確認するには、「show cfs lock name」コマンドを使用します。ロックをクリアする前に、その管理者を確認してください。

ファブリック内の別のスイッチが CFS ロックを保持している場合もあります。「show cfs peers name」コマンドを使用して、アプリケーションの CFS 配信に参加しているすべてのスイッチを確認します。次に、各スイッチで「show cfs lock name」コマンドを使用して、そのアプリケーションの CFS ロックを所有している管理者を確認します。ロックをクリアする前に、その管理者を確認してください。CFS abort オプションを使用すると、データをファブリックに配信せずにロックが解放されます。

CLI を使用したロックの失敗に関する問題の解決

CLI を使用してロックの失敗を解決するには、次の手順を実行します。

ステップ 1 「show cfs lock name」コマンドを使用して、ロック保持者を確認します。

例：

ステップ 2 ロックの失敗の詳細な説明を表示するには、「show cfs internal session-history name application name detail」コマンドを実行します。

例：

ステップ 3 リモート ピアがロックを保持している場合は、そのスイッチで「application-name commit」コマンドまたは「application-name abort」コマンドを実行する必要があります。

例：

application-name commit コマンドの例を次に示します。

例：

application-name abort コマンドの例を次に示します。

システム ステートが不整合で、ロックが保持されている

不整合なシステム ステートは次のいずれかの場合に起こります。

• ファブリック内のすべてのスイッチでロックが保持されていない場合。

• ファブリック内のすべてのスイッチでロックが保持されているが、スイッチを保持しているロックを持つセッションが存在しない場合。

どちらの場合でも、clear オプションを使用してロックを解放する必要があります。

CLI を使用したロックのクリア

リモート ピアでロックが保持されていて、「application-name commit」コマンドまたは「application-name abort」コマンドを実行してもロックがクリアされないときは、「clear application-name session」コマンドを使用してファブリック内のすべてのロックをクリアします。すべてのロックがクリアされた後、ファブリック内のすべてのスイッチを同じステートに戻すために新しい配信を開始する必要があります。

例：

配信ステータスの確認

アプリケーションを設定して変更をコミットした後、ファブリックまたは VSAN 全体に設定変更が配信されたかどうかを確認できます。

CLI を使用した配信の確認

「show cfs lock name application-name」コマンドを使用して、ファブリックで配信が進行中であるかどうかを確認します。該当するアプリケーションが出力に表示されない場合、配信は完了しています。

例：

CFS リージョンのトラブルシューティング

CFS リージョンには次のルールが適用されます。

• CFS リージョンを使用しているとき、特定のスイッチ上のアプリケーションは同時に 1 つのリージョンにのみ属することができます。

• CFS リージョンは、物理スコープ内のアプリケーションにのみ適用できます。アプリケーションの論理スコープで CFS リージョンを作成することはできません。

• アプリケーションへのリージョンの割り当ては、配信においてその初期物理スコープよりも優先されます。

• CFS リージョンの設定は、登録解除されたアプリケーション（条件付きサービス）または現在ロックされている物理スコープ アプリケーションについてはサポートされません。

• ユーザ設定に使用できるリージョンの範囲は 1 ～ 200 です。201 ～ 255 のリージョンは予約されており、ユーザ設定には使用できません。

配信の失敗

ある CFS リージョンにおけるすべてのスイッチへの設定配信の失敗を解決するには、次の手順を実行します。

ステップ 1 アプリケーションの配信がイネーブルになっていることを確認します。詳細については、「概要」を参照してください。

ステップ 2 すべてのスイッチで、アプリケーションが同じリージョンにあることを確認します。

各スイッチで CLI を使用して、「show cfs application name application-name」コマンドを実行します。

例（device-alias アプリケーションの場合）：

例（アプリケーションが結合可能で、デフォルト リージョンにある場合）：

例（アプリケーションが結合可能で、リージョン 1 にある場合）：

条件付きサービスのリージョン

条件付きサービスがダウンすると（CFS から登録解除されると）、そのリージョン設定が失われます。同じ条件付きサービスが再起動されると、自動的にデフォルト リージョンに配置されます。この状況を回避するには、条件付きサービスを再起動する前に適切なリージョン情報を再設定します。

リージョンの変更

アプリケーションをあるリージョンから別のリージョンに移動した場合、結合しようとしたときにデータベースの不一致が起こることがあります。この不一致を特定して解決するには、「結合の失敗のトラブルシューティング」を参照してください。

（注） アプリケーションをあるリージョンから別のリージョン（デフォルト リージョンを含む）に移動すると、そのアプリケーションのすべての履歴が失われます。

概要

VSAN に関するほとんどの問題は、VSAN 実装のベスト プラクティスに従うことで回避できます。

ただし、必要であれば、Fabric Manager のファブリック分析ツールを使用して、VSAN、ゾーン分割、FCdomain、管理に関する問題、スイッチ固有の問題、ファブリック固有の問題などのさまざまなカテゴリの問題を確認できます。

Fabric Manager にはコンフィギュレーション整合性チェック ツールがあります。

[Fabric Configuration] オプションを使用してスイッチのコンフィギュレーションを分析するには、次の手順を実行します。

ステップ 1 Fabric Manager のツール メニューから、[Health] > [Fabric Configuration] をクリックします。

[Fabric Configuration Analysis] ダイアログボックスが表示されます。

ステップ 2 選択したスイッチを別のスイッチと比較するか、またはポリシー ファイルと比較するかを決定します。

• 選択したスイッチを別のスイッチと比較するには、[Policy Switch] を選択し、スイッチのドロップダウン リストからスイッチを選択します。

• ポリシー ファイルと比較するには、[Policy File] を選択し、右側のボタンをクリックしてファイル システム上のポリシー ファイル（*.XML）を選択します。

ステップ 3 [Rules] をクリックし、Fabric Configuration Analysis ツールの実行時に適用するルールを設定します。

[Rules] ウィンドウが表示されます。

ステップ 4 必要に応じて既存のルールを変更し、[OK] をクリックします。

ステップ 5 [Compare] をクリックし、コンフィギュレーションを比較します。

分析結果が表示されます。

ステップ 6 [Resolve] 列で、解決する問題をクリックします。

ステップ 7 [Resolve Issues] をクリックし、特定された問題を解決します。

ステップ 8 [Clear] をクリックし、ウィンドウの内容を消去します。

ステップ 9 [Close] をクリックし、操作を終了してウィンドウを閉じます。

コンフィギュレーション整合性チェック ツールの詳細については、『 Cisco MDS 9000 Family Fabric Manager Configuration Guide, Release 5.x 』を参照してください。

（注） VSAN を一時停止または削除するときは、一度に 1 つの VSAN を一時停止および一時停止解除するよう注意してください。vsan suspend コマンドを実行した後、別のコンフィギュレーション コマンドを実行するときは、60 秒以上待ってください。60 秒以上待たないと、一部のファイバ チャネル インターフェイス、または PortChannel のメンバー ポートが一時停止または errdisable になる場合があります。

SAN の問題のトラブルシューティングでは、個々のデバイスの設定と接続、および SAN ファブリック全体のステータスに関する情報を収集する必要があります。

VSAN のトラブルシューティング操作

Fabric Manager でよく使うトラブルシューティング ツール

Fabric Manager で VSAN を確認するには、次の手順を実行します。

• [Information] ペインに VSAN の設定を表示するには、

[Fabricxx] > [VSANxx] を選択します。

• VSAN のメンバーを表示するには、[Fabricxx] > [VSANxx] を選択してから、

[Information] ペインの [Host] または [Storage] タブを選択します。

• [Information] ペインに FC ドメインの設定を表示するには、

[Fabricxx] > [VSANxx] > [Domain Manager] を選択します。

トラブルシューティングによく使う CLI コマンド

VSAN、FC ドメイン、および FSPF の情報を表示するには、次の CLI コマンドを使用します。

チェックリスト

次のことを確認します。

• VSAN 内のスイッチのドメイン パラメータを確認します。

• 問題のあるポートまたは VSAN の物理接続を確認します。

• 両方のデバイスがネーム サーバにあることを確認します。

• 両方のエンド デバイスが同じ VSAN にあることを確認します。

• 両方のエンド デバイスが同じゾーンにあることを確認します。

Nexus 5000 トランク ポートがアップストリーム SAN スイッチに接続しない

Nexus 5000 トランク ポートがアップストリーム SAN スイッチに接続しないことを示す状況は、次のとおりです。

• アップストリーム スイッチに接続されたトランク ポートのステータスが「isolated」になります。

• スイッチポート トランク モードは両側でイネーブルになっています。

• 物理的なケーブル配線には問題はありません。

• ポートは両方のスイッチでアップしています。

次の例に示すように、インターフェイスのステートを調べ、インターフェイスの状況を照会することで、この問題が明らかになります。

例：

考えられる原因

両方のインターフェイスの VSAN 許可リストが同じではありません。具体的には、両方のインターフェイスで許可されている共通の VSAN がありません。

これは次のことが原因で起こる場合があります。

• 両方のスイッチに共通の VSAN がない。

• トランクで許可されている VSAN のメンバーに共通のメンバーが含まれていない。

この例では、Nexus 5000 と MDS の FC インターフェイス上のトランク VSAN 許可リストが一致していません。

解決方法

接続されたポートを確認し、両方の FC インターフェイスについてトランクで許可される VSAN を解決します。

例：

Nexus 5000 E ポート（非トランキング）がアップストリーム SAN スイッチに接続しない

Nexus 5000 E ポートがアップストリーム SAN スイッチに接続しないことを示す状況は、次のとおりです。

• 相互接続された非トランキング E ポートのステータスを調べると、ステータスはアップになっています。ただし、すべてのファイバ チャネル サービスがスイッチ間で機能していません。

• どちらのスイッチでも、同じ VSAN 内のデバイスが FCNS データベースに表示されません。

• show topology コマンドでピア スイッチ情報が表示されません。

• ゾーンでは、メンバーがログインしていないと表示されます。

例：

FC トポロジは有効なピア インターフェイスを示しません。

例：

ストレージとホストは正しい VSAN に属しています。

例：

考えられる原因

このエラーは、「show interface brief」コマンドと「show vsan membership」コマンドによって表示されます。これらのコマンドは、一方のスイッチの E ポートが間違った VSAN に属していることを示します。

一方のスイッチの非トランキング E ポートが間違った VSAN に属しています（VSAN 100 が正しい VSAN です）。

例：

解決方法

非トランキング E ポートを VSAN 100 に移動します。

例：

これでゾーンセットがアクティブになり、FC トポロジが正しくなります。

例：

ホストとストレージ デバイス間の通信の問題

ホストとストレージ デバイス間の通信の問題を示す状況は、次のとおりです。

• ゾーンはアクティブです。

• ホストとストレージの両方が SAN にログインしています。

• ストレージ ポートがアクティブ ゾーンセットにログインしていません。

例：

考えられる原因

ホストまたはストレージ ポートが間違った VSAN に属しています。

例：

解決方法

ストレージ ポートを正しい VSAN に移動します（この例では、VSAN 100 が正しい VSAN です）。

例：

スイッチ間の VSAN がダウンしている

スイッチ間の VSAN がダウンしている問題を示す状況は、次のとおりです。

• 両方のスイッチで VSAN が設定されています。

• トランク許可リストによってその VSAN が許可されています。

• VSAN がダウンしている（初期化ステート）と報告されます。

• ゾーンはアクティブです。

• ホストとストレージの両方が SAN にログインしています。

この障害では、ストレージ ポートがアクティブ ゾーンセットにログインしていません。

次の例に示すように、インターフェイスを調べるとエラーが表示されます。

例：

考えられる原因

複数の VSAN に同じスタティック DomainID が設定されている可能性があります。

例：

解決方法

いずれかの VSAN の DomainID を変更します。

例：

物理層の問題の特定

ファイバ チャネル SFP 光ファイバに関する物理層の問題をトラブルシューティングするには、次のコマンドを使用します。

次の例では、サポートされている速度、公称ビット レート、SFP でサポートされているリンク長などの有用な情報がコマンドの結果に含まれていることがわかります。

例：

このコマンドは、詳細な SFP 診断情報と警告およびアラーム（存在する場合）も出力します。

例：

次に、このコマンドの出力例を 2 つ示します。最初の例は、RX 電力の下限アラームを示します。2 番目の例は、TX、RX、および電流の下限アラームを示します。2 番目の例の問題となっているインターフェイスは、ビット エラー レートが高すぎることが原因で「Error Disabled」ステートになっていました。

RX 電力の下限アラーム

電流、TX 電力、および RX 電力の下限アラーム

次の例では、Twinax（銅）の詳細なトランシーバ情報は示されていないことに注意してください。

FcoE にバインドされたイーサネット インターフェイスのカウンタの表示

「show interface ethernet」コマンドには簡易版と詳細版の 2 種類があります。それぞれの例を次に示します。

簡易版

例：

（注） ジャンボ フレームが増えていることと、RX または TX ポーズ フレーム カウンタ（存在する場合）を確認してください。後者は輻輳の問題を示す場合があります。

詳細版

次の例では、「show interface ethernet」コマンドの詳細版の出力を分けて示しています。これには、通常トラフィックのカウンタと物理層およびプロトコル エラーのカウンタがどちらも含まれます。接続やパフォーマンスの問題があるときは常にこれらのカウンタをモニタしてください。

例：

ファイバ チャネル インターフェイスのカウンタについて

「show interface」コマンドは、ファイバ チャネル インターフェイスに関する物理層またはパフォーマンスの問題をトラブルシューティングするときに非常に便利です。

このコマンドの出力では、入力/出力カウンタと入力/出力の廃棄またはエラーに注意します。

入力廃棄が増えるときは、Forwarding Information Base（FIB; 転送情報ベース）内にその FC パケットの有効なルートがありません。ルートを持たないパケットはすべて廃棄と見なされ、スーパーバイザに送信されます。これらのパケットはドロップされないことに注意してください。ただし、スーパーバイザに送信される前にポリシングされます。また、MAC ASIC にエラーがないかチェックする必要があります。

出力廃棄が増えるときは、出力が遅すぎるためにパケットが出力でタイムアウトしています。接続先のデバイスが、バッファ クレジットに応答しない、またはバッファ クレジットを補充しない低速ドレイン レシーバである可能性があるため、接続先のデバイスを確認します。この場合は、Nexus 5000 FC インターフェイスでバック プレッシャが起こります。

例：

ファイバ チャネルの MAC に関する問題のトラブルシューティング

「show hardware」コマンドは、FC の物理層の問題をトラブルシューティングするときに非常に便利です。

このコマンドの出力には、次の有用な情報が含まれます。

• 物理層の情報

• パフォーマンスの情報

• クラス 3 通常トラフィックのカウンタ

• ファイバ チャネルのプリミティブ シーケンス

例：

FC のパフォーマンスの問題をトラブルシューティングするときは、R_RDY、Link Reset、Link Reset Response の各カウンタを調べます。これらのカウンタは、パフォーマンスの問題を引き起こす可能性があるバッファ ツー バッファ クレジットの問題を判別するのに役立ちます。

ファイバ チャネルの転送に関する問題のトラブルシューティング

ファイバ チャネルの転送に関する問題をトラブルシューティングするには、N5K に GATOS という MAC/転送 ASIC が搭載されていることを知っておくことが重要です。ここでは、この ASIC 専用のコマンドについて説明します。

各ファイバ チャネル インターフェイスには GATOS 番号が割り当てられるので、転送の問題を理解するには、問題になっている FC インターフェイスの GATOS 番号を特定する必要があります。

次の例について考えます。

この例の次の部分で、gatos_num 13 がファイバ チャネル インターフェイス 2/1 の GATOS インスタンスであることがわかります。

この例の次の部分で、転送のドロップおよび廃棄情報も出力されていることがわかります。

また、問題の FC インターフェイスに対応する GATOS インスタンスの GATOS エラーを表示することもできます。この例の次の部分で、このコマンドではゼロでないカウンタのみが表示されることがわかります。

上の 2 つの部分の最初の方に、ドロップと廃棄が示されています。vethernet および VFC インターフェイスではドロップ カウンタと廃棄カウンタは分かれていることに注意してください。2 番目の例の出力を見ると、ドロップの理由を関連付けるのに役立ちます。

この例の次の部分の 2 行目にドロップが示されています。

この例の次の部分で、FcoE カウンタが分かれていることがわかります。

この例の次の部分で、このコマンドがドロップの原因の特定に役立つことがわかります。