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

VFC（FCoE）インターフェイスがオンラインにならない

考えられる原因

FCoE に接続したサーバが、FC または FCoE に接続したストレージに接続できず、このサーバのポートにマップした仮想ファイバ チャネル インターフェイスに対して show interface コマンドを実行すると、その VFC インターフェイスが稼動していないことが報告されます。

解決方法

• 「show running-config」コマンドを使用して設定を確認します。

例：

（注） VFC のデフォルト設定は停止していますが、次の例ではデフォルト設定をセットアップ スクリプトで変更しています。

• 該当のインターフェイスで LLDP の送受信がイネーブルになっていることを確認します。
「show lldp interface ethernet 1/4」コマンドを使用します。

例：

LLDP がディセーブルになっていると VFC はオンラインになりません。
「int ethernet 1/4」コマンドを使用すると、LLDP の送受信をイネーブルにできます。

• 該当のピアで LLDP がサポートされていることを確認します。
リモート ピアが存在するかどうかを確認します。ピアの LLDP TLV の値が存在するかどうかを確認します。
「show lldp interface ethernet 1/4」コマンドを使用します。

例：

• ピア（CNA）が DCBX をサポートしているかどうかを確認します。
「show system internal dcbx info interface ethernet 1/4」コマンドを使用します
（4.2(1)N1 よりも前のリリースでは、「sh platform software dcbx internal info interface ethernet x/y」コマンドを使用します）。

（注） 次の例では、DCBX がイネーブルでピアが CEE をサポートしています。

例：

• 「show system internal dcbx info interface ethernet 1/4」コマンドの実行結果で、各ピアの LLDP の値を確認します。
必須の LLDP 値が存在することを確認します。

例：

• 「show system internal dcbx info interface ethernet 1/4」コマンドの実行結果で、各ピアの DCBX TLV を確認します。
PFC TLV と FCoE TLV の間でネゴシエーションが意図したとおりに実行され、これらがイネーブルになっていること、そこでエラーが発生していないことを確認します。

例：

• ピアの PFC と FCoE のサブタイプを確認します。

「show system internal dcbx info interface ethernet 1/4」コマンドを使用します
（4.2(1)N1 よりも前のリリースでは、「sh platform software dcbx internal info interface ethernet x/y」コマンドを使用します）。

例：

• 「show system internal dcbx info interface ethernet 1/4」コマンドを実行して表示された結果の末尾にある DCBX カウンタを確認します。何らかのエラーが記録されていないか調べます。

例：

• FCoE の Data Center Bridging についても同様の値を確認し、ホストの CNA ソフトウェアで Type-Length-Value を確認します。

解決方法のまとめ

• 各機能のネゴシエーション結果を確認します。

「show system internal dcbx info interface ethernet 1/4」コマンドを使用します
（4.2(1)N1 よりも前のリリースでは、「sh platform software dcbx internal info interface ethernet x/y」コマンドを使用します）。

例：

• エラー

– ネゴシエーションのエラーが発生しています。

– CNA に接続するときに発生するとは考えられません。

– 2 台の Nexus 5000 スイッチをバックツーバックで接続している場合は、複数の異なる CoS 値に対して PFC をイネーブルにすると、ネゴシエーションのエラーが発生することがあります。

• 動作設定

– ネゴシエーションの結果を示します。

– 動作設定が存在しない場合は、ピアが DCBX TLV をサポートしていないか、ネゴシエーションのエラーが発生しています。

– 「remote_feature_tlv_present」は、リモート ピアがこの機能の TLV をサポートしているかどうかを示しています。

• 次の理由で、DCBX 機能が稼動していない可能性があります。

– ピアが LLDP プロトコルをサポートしていない。

– ピアが DCBX プロトコルをサポートしていない。

– ピアが一部の DCBX TLV をサポートしていない。

– DCBX のネゴシエーションで予期しない結果が得られた。

• インターフェイスに PFC モードを強制的に適用するオプションが用意されています。
PFC モードを強制的に適用するには、「switch(config)# int eth1/21」コマンドと「switch(config-if)# priority-flow-control mode ?」コマンドを使用します。

例：

（注） 上記のコマンドのデフォルト設定は「auto」です。「no」オプションを指定すると、モードは「auto」に戻ります。

FIP の障害が原因で VFC が停止する

FIP に関連する TLV をホストがサポートしていません。

考えられる原因

接続先のホストが FIP をサポートしていない場合は、起動する VFC に応じて VLAN 検出の最初の手順が失敗します。FIP で必要となる 3 種類の基本的な TLV が、バインドしたインターフェイス経由で DCBX によって交換されていること、および FIP で FCOE-MGR がイネーブルになっていることを、以下のコマンドを使用して確認します。この 3 種類の TLV とは、FCoE TLV、PriGrp TLV、および PFC TLV です。ローカルとピアの両方について、これら 3 種類の TLV の値が存在していることを確認する必要があります。

次のコマンドを使用して TLV を確認します。

• 「show system internal dcbx info interface <bound-ethernet-interface-id>」

• 「show platform software fcoe_mgr info interface vfc<id>」

これらのコマンドの実行結果に「FIP Capable ?: TRUE」および「Triggered event: [FCOE_MGR_VFC_EV_FIP_VLAN_DISCOVERY]」が表示されているかどうかを確認します。

VFC は、これ以上進行しない状態となり、要求を受け取ることができません。

解決方法

FIP をサポートしている適切なファームウェアとドライバを CNA で使用していること、および FIP をサポートしているアダプタを使用していることを確認します。

FIP 要求の障害が原因で VFC が停止する

FIP 要求が失敗すると、VFC が停止します。

考えられる原因

FIP VLAN 検出の最初の手順が成功すると、ホストは FIP 要求を送信します。スイッチでは、この要求に対して詳細な FIP アドバタイズメントを使用して応答する必要があります。この応答を送信しなかった場合、または受信した要求に対してアドバタイズメントを返信しなかった場合、VFC は動作を開始しません。ホストは要求を継続しようとしますが、成功することはありません。

応答やアドバタイズメントが得られない理由として、以下が考えられます。

• アクティブなファブリックが提供する MAC アドレスが存在しない（FC マップが正しくない場合など）。

• FLOGI で使用できるファブリックが存在しない。

• MAC アドレス記述子が正しくない（これは、CNA が応答を送信するときに DMAC として使用するアドレスです）。

「show platform software fcoe_mgr info interface vfc<id>」コマンドを使用して、FIP 要求のステータスを表示します。

このコマンドの実行結果で、「Triggered event: [FCOE_MGR_VFC_EV_FIP_VLAN_DISCOVERY]」に続いて

「Triggered event: [FCOE_MGR_VFC_EV_FIP_SOLICITATION]」が表示されている部分を確認します。

要求が成功している場合は、これに続いて「Triggered event: [FCOE_MGR_VFC_EV_FIP_FLOGI]」が表示されています。

要求が失敗している場合は「Triggered event: [FCOE_MGR_VFC_EV_FIP_FLOGI]」が表示されず、これ以上の処理は行われません。

解決方法

VSAN がアクティブであること、メンバーシップが正しいこと、およびファブリックが使用可能であることを確認する必要があります。また、NPV モードで、アクティブな境界ポートや NP ポートが存在することを確認します。

VLAN からの応答を CNA で受信できないために VFC が停止する

スイッチからは VLAN 応答が送信されていますが、それが CNA で受信されません。これは VFC が動作していないためです。

考えられる原因

バインドしたインターフェイスのネイティブ VLAN ID は、FCoE VLAN のものではないことが必要です。この ID が FCoE VLAN のもので、ネイティブ VLAN がその FCoE VLAN に一致していると、送信される VLAN 応答はタグなしになります。一方、FIP アダプタではタグ付きのフレームを受信することを想定しています。したがって、トランク インターフェイス上のネイティブ VLAN は FCoE VLAN ではないことが必要になります。

解決方法

バインドしたイーサネット トランク インターフェイスの設定を調べ、ネイティブ VLAN が FCoE VLAN ではないでことを確認します。

バインドしたイーサネット インターフェイス上にアクティブな STP ポート ステートが存在しないために、VFC が停止する

バインドしたイーサネット インターフェイス上にアクティブな STP ポート ステートが存在しないために、VFC が停止します。

考えられる原因

ネイティブ VLAN と、アクティブな VSAN にマップしたメンバ FCoE VLAN の両方で、バインドしたインターフェイスは STP フォワーディング ステートにあることが必要です。STP のアクティブなポートが VLAN 上に存在しないと、バインドしたインターフェイスを介してその VLAN で受信した FIP パケットはすべてスイッチでドロップされます。その結果、FIP による VFC の起動が始まりません。

解決方法

FCoE ではないネイティブ VLAN と FCoE であるメンバ VLAN の両方で、バインドしたイーサネット トランク インターフェイス上の STP ポート ステートを確認します。STP ポート ステートが、ブロックした不整合なステートまたはエラー ディセーブル ステートにある場合は、それを修復してフォワーディング ステートに移行します。

FIP のキープアライブが欠落するために VFC が停止する

FIP のキープアライブが欠落するために VFC が停止します。

考えられる原因

FIP のキープアライブ（FKA）が 22 秒ほど欠落すると、ほぼ 3 回連続でホストから FKA が受信されていないことになります。FKA の欠落が発生する原因は、輻輳やリンク上の問題などさまざまです。

FKA のタイムアウトは、FKA の平均周期（FKA_adv_period）を 2.4 倍した値です。

FKA_adv_period は、要求に応答する FIP アドバタイズメントの際にホストの間で取り交わされ、合意されます。

次のコマンドの実行結果を検討して、FKA の欠落が発生しているかどうかを確認します。

• 「show platform software fcoe_mgr info interface vfc<id>」

• 「show platform software fcoe_mgr event-history errors」

• 「show platform software fcoe_mgr event-history lock」

• 「show platform software fcoe_mgr event-history msgs」

• 「show platform fwm info pif ethernet <bound-ethernet-interface-id>」

解決方法

輻輳が解消されると、VFC は復旧します。症状が継続する場合は、さらに分析が必要になります。その場合に考慮すべき点は次のとおりです。

• ホストが FKA の送信を停止している。

• 受信した FKA をスイッチがドロップしている。

CNA のベスト プラクティス トポロジ

直接接続した CNA のベスト プラクティス トポロジ

• SAN の各仮想ファブリック（VSAN）にトラフィックを伝送するように、すべての統合アクセス スイッチでそれぞれに専用の VLAN を設定する必要があります（VSAN 1 では VLAN 1002、VSAN 2 では VLAN 1003 など）。MSTP がイネーブルである場合、FCoE VLAN では独立した MST インスタンスを使用する必要があります。

• Unified Fabric（UF; 統合ファブリック）のリンクはトランク ポートとして設定する必要があります。FCoE VLAN は、ネイティブ VLAN として設定しないようにします。すべての FCoE VLAN は、UF リンクのメンバーとして設定する必要があります。これにより、VFC インターフェイスでの VF_Port トランキングと VSAN 管理のために FCoE VLAN を拡張できるようになります。

• UF リンクは、スパニングツリー エッジ ポートとして設定する必要があります。

• FCoE VLAN は、FCoE トラフィックの伝送用として指定していないイーサネット リンクのメンバーとして設定しないようにします。これにより、FCoE VLAN で使用するスパニングツリー プロトコルの範囲を UF リンクのみに制限できます。

• 統合アクセス スイッチを（それが存在する SAN ファブリックに関係なく）、LAN の代替パスを設定する目的でイーサネット経由の各リンクに接続する必要がある場合は、すべての FCoE VLAN をメンバーシップから除外するようにこれらのリンクを明示的に設定する必要があります。これにより、FCoE VLAN で使用するスパニングツリー プロトコルの範囲を UF リンクのみに制限できます。

• SAN-A および SAN-B の FCoE には別の FCoE VLAN を使用する必要があります。

リモート接続した CNA のベスト プラクティス トポロジ

• SAN の各仮想ファブリック（VSAN）にトラフィックを伝送するように、すべての統合アクセス スイッチおよびすべてのブレード スイッチでそれぞれに専用の VLAN を設定する必要があります（VSAN 1 では VLAN 1002、VSAN 2 では VLAN 1002 など）。MSTP がイネーブルである場合、FCoE VLAN では独立した MST インスタンスを使用する必要があります。

• Unified Fabric（UF; 統合ファブリック）のリンクはトランク ポートとして設定する必要があります。FCoE VLAN は、ネイティブ VLAN として設定しないようにします。すべての FCoE VLAN は、UF リンクのメンバとして設定する必要があります。これにより、VFC での VF_Port トランキングと VSAN 管理のために FCoE VLAN を拡張できるようになります。

• CNA とブレード スイッチ間の UF リンクは、スパニングツリー エッジ ポートとして設定する必要があります。

• 各ブレード スイッチを接続する統合アクセス スイッチは 1 台のみとする必要があります。新しいリンクやブレード スイッチのプロビジョニングなどで実行する STP の再コンバージェンスによって中断が発生しないように、可能な限り、この接続はイーサネット ポート チャネル経由とします。

ホスト ツールによるトラブルシューティング

以下は、ホストで使用するツールで CNA のトラブルシューティングを実行する際の注意事項です。

• Emulex

– Emulex には、Emulex の CNA を管理する「OneCommand」GUI ツールが用意されています。このツールの [CEE] タブには、DCB 設定の詳細および FC インターフェイスの FIP 設定の詳細が表示されます。

• Qlogic

– Qlogic には「SanSurfer」ツールが用意されています。このツールの [Data Center Bridging] タブには、スイッチから学習した、TLV 交換データのみの DCB 設定が表示されます。このツールの [DCE Statistics] タブには、イーサネットの統計情報が表示されます。

• Microsoft Windows

– Microsoft Windows には、数多くの CNA ベンダー製品の設定とレジスタを表示するツールが用意されています。

ホスト OS で CNA を認識できない

Converged Network Adapter（CNA; 統合ネットワーク アダプタ）はホストにインストールされていますが、その CNA を認識できません。

考えられる原因

インストールした CNA のモデルをサポートする適切なドライバがホストのオペレーティング システムに存在していない可能性があります。

解決方法

ステップ 1 1）次の情報を収集します。

a. ホストのオペレーティング システム。

b. インストールした CNA の具体的なモデル名。

ステップ 2 CNA モデルとホスト OS について、各ベンダーの適切なサポート ページを調べます。

ステップ 3 既存のドライバがホスト OS にインストールされているかどうかを確認します。

ステップ 4 CNA ベンダーのサポート ページまたはホスト OS のサポート ページから最新のドライバをインストールしていることを確認します。

標準ポーズ フレーム

Nexus 5000 では、CNA ではない標準のホスト接続を備えたポートに対して標準ポーズ フレームをサポートしています。この標準ポーズ フレームは、次の例にあるようにインターフェイスの設定でイネーブルにできます。

例：

標準ポーズ フレームを表示するには、「show interface flowcontrol」コマンドを使用します。

例：

PFC が FCoE 対応アダプタ（CNA）とネゴシエートしない

Priority Flow Control（PFC; プライオリティ フロー制御）が、FCoE 対応アダプタ（CNA）とネゴシエートしません。

その結果、サーバからの FCoE トラフィックにパケットのドロップが発生します。

考えられる原因

CNA が DCBX をサポートしていないために、PFC TLV がネゴシエートされていない可能性があります。

解決方法

次の手順を実行して、DCBX のサポート状況を調べ、PFC TLV がネゴシエートされていることを確認します。

• PFC のステータスを確認します。「show int ethx/x priority-flow-control」コマンドを使用します
（CNA に接続します）。

例：

• ピアでアドバタイズされた LLDP ネイバーまたは PFC/DCBX TLV が存在するかどうかを確認します。「show system internal dcbx info int ethx/x」コマンドを使用します。

例：

• ピアが DCBX をサポートしていない場合は、プライオリティ フロー制御のモード設定を「on」にして PFC をイネーブルにします。

CNA に接続したスイッチ インターフェイスで継続的なポーズ フレーム（PFC）が受信される

CNA にスイッチ インターフェイスを接続すると、継続的なポーズ フレーム（PFC）が受信されます。

考えられる原因

Nexus 5000 スイッチを CNA に接続している場合は、その CNA からスイッチに Xon PFC フレームが送信されていることがあります。これにより、「show interface ethx/x」コマンドを発行するとポーズ カウンタの値が増加します。

この状況を確認するには、次の手順を実行します。

• 「show interface ethx/x」コマンドを数回実行し、「show interface ethx/x |grep - i pause」コマンドを使用して、ポーズ フレームのカウントが増加していることを確認します。

• 「show interface ethx/x」コマンドを数回実行し、「show interface ethx/x priority-flow-control」コマンドを使用して、PFC フレームのカウントが増加していることを確認します。

• 「show queuing interface ethx/x」コマンドを数回発行して、ポーズのステータスを確認します。

例：

「show interface ethx/x priority-flow-control」コマンドの実行結果で Rx（Inactive）とポーズ カウンタが時間とともに増加している場合、この問題の原因は CNA から送信される Xon フレームです。

考えられる原因

スイッチ ポートからのトラフィックを処理できない低速なサーバが Nexus 5000 と SNA との接続に関係している場合、そのサーバは、スイッチの動作速度を下げるために Xoff ポーズ フレームをスイッチに送信します。これにより、「show interface ethx/x」コマンドを使用するとポーズ カウンタの値が増加します。

この状況を確認するには、次の手順を実行します。

• 「show interface ethx/x |grep - i pause」コマンドを数回実行して、ポーズ フレームのカウントが増加していることを確認します。

• 「show interface ethx/x priority-flow-control」コマンドを数回実行して、PFC フレームのカウントが増加していることを確認します。

• 「show queuing interface ethx/x」コマンドを数回発行して、ポーズのステータスを確認します。

例：

「show interface ethx/x priority-flow-control」コマンドの実行結果で Rx（Active）とポーズ カウンタが増加している場合、この問題の原因はサーバから送信される Xoff フレームです。

解決方法

サーバから Xoff ポーズ フレームが送信されると、Nexus 5000 のインターフェイスが一時停止し、スイッチから CNA へのスループットが低下します。サーバの OS と PCI スロットを調べ、高速なサーバとして機能しているかどうかを確認します。サーバを、10G のスループットを実行できるものに入れ替えます。

スイッチがポーズ フレームを送信しているかどうか、または一時停止しているかどうかの確認

スイッチからポーズ フレームが送信されているために、サーバで FCoE のスループットがきわめて低くなっています。スイッチがポーズ フレームを送信しているかどうか、または一時停止しているかどうかの確認が必要です。

考えられる原因

出力 FC ポートで輻輳が発生していると、スイッチからサーバに PFC フレームが送信されます。FCoE のレートを下げ、パケットのドロップを避けるために PFC フレームが送信されます。サーバの処理速度が低下した場合やサーバに輻輳が発生した場合、サーバからスイッチ インターフェイスに PFC フレームが送信されます。

この状況を確認するには、次の手順を実行します。

• 「show interface ethx/x |grep - i pause」コマンドを数回実行して、ポーズ フレームのカウント（Rx/TX）が増加していることを確認します。

• 「show interface ethx/x priority-flow-control」コマンドを数回実行して、PFC フレームのカウント（RX/TX）が増加していることを確認します。

• 「show queuing interface ethx/x」コマンドを数回使用して、ポーズのステータスを確認します。

（注） PFC フレームは MAC レベル タイプのパケットなので、SPAN 機能では表示できません。回線で伝送されている実際の PFC フレームを確認するには、インラインのアナライザが必要です。

例：

「show interface ethx/x priority-flow-control」コマンドの実行結果で RX（Active）とポーズ RX カウンタが増加している場合、この問題の原因はサーバから送信される Xoff フレームです。

「show interface ethx/x priority-flow-control」コマンドの実行結果で Tx（Active）とポーズ TX カウンタが増加している場合、この問題の原因はスイッチによって転送される Xoff フレームです。

解決方法

輻輳の発生源を突き止め、FC の帯域幅を引き上げるか、サーバを高性能なものに入れ替えることで、輻輳を解決します。輻輳の発生が予想される場合は、FCoE トラフィックにポーズが発生すると考えるべきです。

ポーズ レートの限度によってスイッチ ポートが err-disabled になる

ポーズ レートに限度があることから、スイッチ ポートが err-disable ステートになります。

考えられる原因

スイッチ インターフェイスがサーバから過剰な Xoff ポーズ フレームを受信すると、ポーズ フレームのレートが高すぎるためにそのスイッチのポートが error-disabled ステートになります。通常は、10G ポートでの送信速度が 5mbps を下回っている場合にのみ、ポーズ フレームによってポートが err-disable ステートになります。これは、サーバの処理速度が大幅に低下し、大量のポーズ フレームがスイッチのポートに送信されている状態です。

この状況を確認するには「show int eth1/14 brief」コマンドを使用します。

例：

• RX ポーズ カウントが大きな値になっていることを確認します。「show interface ethx/x」コマンドを使用してポーズ カウンタを表示します。

• 「show hardware internal gatos event-history errors |grep -i err」コマンドを使用して、ポーズの err-disable ログを確認します。

解決方法

次のような一時的な条件によってポートが err-disabled になっている場合は、ポーズの err-disable 回復をイネーブルにして、ポートをこのステートから解放できます。

次の一時的な条件によってポートが err-disabled になっている場合は、ポーズの err-disable 回復をイネーブルにして、ポートをこのステートから解放できます。

• err-disable 回復によってポーズ レート限度が発生している。

• err-disable 回復の間隔が 30 である。

ポーズ レートの限度によってポートが一貫して err-disabled ステートになっている場合は、低速なサーバが問題であるかどうかを判断します。低速なサーバを高速なサーバに入れ替えます。

DCBX 対応デバイスに接続したスイッチでリンク ポーズ（フロー制御）をイネーブルにする方法

サーバに接続したスイッチのポートでリンク ポーズがイネーブルになりません。DCBX 対応デバイスに接続した Nexus 5000 スイッチではリンク ポーズ（フロー制御）がイネーブルであることが必要です。

考えられる原因

ピアが DCBX で PFC TLV をサポートしている場合は、「flowcontrol send on」および「flowcontrol receive on」を設定するとリンク ポーズがイネーブルになりません。該当のインターフェイス上で DCBX が送信する PFC TLV をディセーブルにする必要があります。

この状況を確認するには、次のいずれかの手順を実行します。

• 「show interface ethx/y flowcontrol」コマンドを使用して、動作ステートがオフであるかどうかを確認します。

• 「show interface ethx/y priority-flow-control」コマンドを使用して、動作ステートがオンであるかどうかを確認します。

解決方法

「interface ethx/y」で次のコマンドを使用して、DCBX 対応デバイスで PFC の代わりにリンク ポーズをイネーブルにします。

• 「no priority-flow-control mode on」

• 「flowcontrol receive on」

• 「flowcontrol send on」

PFC カウンタをクリアする方法

プライオリティ フロー カウンタをクリアする方法。

考えられる原因

現在のところ、PFC フレームをクリアする CLI コマンドはありません（バグ ID CSCtg08068）。

解決方法

PFC カウンタをクリアする CLI コマンドはありませんが、クリアする方法はあります。インターフェイス カウンタをクリアしてから「show interface ethx/x flowcontrol」コマンドを発行すると、PFC フレームのカウントを表示できます。

（注） 「show int ethx/x flowcontrol」コマンドを使用すると PFC フレームのカウントが増加します。これは既知のバグです。

インターフェイス レベルのエラー

インターフェイス レベルのエラーを表示するには「show interface counters errors」コマンドを使用します。

例：

パケットのバイト数

パケットのバイト数を表示するには「show interface counters detailed」コマンドを使用します。

例：

SNMP 読み取りの検証

SNMP 読み取りの検証を表示するには「sh interface ethernet 1/11 counters snmp」コマンドを使用します。

例：

トラフィック レート

トラフィック レートを表示するには「sh interface ethernet 1/11 counters brief」コマンドを使用します。

例：