スイッチ : Cisco Nexus 7000 シリーズ スイッチ

Nexus 7000 vPC 自動リカバリ機能の設定例

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

このドキュメントでは、Nexus 7000 で仮想 PortChannel(vPC)の自動回復機能を設定する方法について説明します。

Cisco TAC エンジニア Viral Bhutta 著

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

背景説明

vPC 自動回復機能が必要な理由

この vPC 拡張機能が必要とされる主な理由は次の 2 つです。

  • データセンターの停止や停電が発生した場合、Nexus 7000 スイッチで構成された vPC ピアは両方ともオフになります。 まれに、ピアの片方だけを復元できることがあります。 もう一方の Nexus 7000 がまだオフであるため、vPC のピア リンクと vPC のピア キープアライブ リンクもオフになります。 このシナリオでは、すでにオンになった Nexus 7000 に対してさえ、vPC がオンになりません。 ポート チャネルを機能させるには、その Nexus 7000 のポート チャネルからすべての vPC 設定を削除する必要があります。 もう一方の Nexus 7000 がオンになったら、設定をもう一度変更して、すべての vPC の vPC 設定を含める必要があります。 リリース 5.0(2)以降では、この問題に対処するために vPC ドメイン設定の下で reload restore コマンドを設定できます。
  • 何らかの理由で、vPC ピア リンクがオフになるとします。 vPC ピア キープアライブがまだオンであるため、vPC セカンダリ ピア デバイスはデュアル アクティブ検出のためにすべての vPC メンバー ポートをオフにします。 その結果、すべてのトラフィックが vPC プライマリ スイッチを通過します。 何らかの理由で、vPC プライマリ スイッチもまたオフになるとします。 vPC プライマリ スイッチがオフになる前にデュアル アクティブが検出されたため、セカンダリ ピア デバイス上の vPC がまだオフになっているので、このスイッチの問題はトラフィックのブラック ホールとなります。

リリース 5.2(1)以降では、vPC 自動回復機能がこれら 2 つの拡張機能をマージしています。

設定

vPC 自動回復機能の設定は単純です。 両方の vPC ピアの vPC ドメインで自動回復機能を設定する必要があります。

次に設定例を示します。

スイッチ S1

S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc
Legend:
                (*) - local vPC is down, forwarding via vPC peer-link
vPC domain id                     : 1 
Peer status                       : peer adjacency formed ok    
vPC keep-alive status             : peer is alive
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : primary
Number of vPCs configured         : 5 
Peer Gateway                      : Enabled
Peer gateway excluded VLANs       : -
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Enabled (timeout = 240 seconds)

vPC Peer-link status
---------------------------------------------------------------------
id   Port   Status Active vlans  
--   ----   ------ --------------------------------------------------
1    Po1    up     1-112,114-120,800,810
                                
vPC status
-----------------------------------------------------------------------
id   Port   Status Consistency Reason                     Active vlans
--   ----   ------ ----------- ------                     ------------
10   Po40   up     success     success                    1-112,114-1
                                                          20,800,810    

スイッチ S2

S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2# show vpc
Legend:
               (*) - local vPC is down, forwarding via vPC peer-link
vPC domain id                     : 1 
Peer status                       : peer adjacency formed ok    
vPC keep-alive status             : peer is alive               
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : secondary
Number of vPCs configured         : 5 
Peer Gateway                      : Enabled
Peer gateway excluded VLANs       : -
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Enabled (timeout = 240 seconds)

vPC Peer-link status
---------------------------------------------------------------------
id   Port   Status Active vlans  
--   ----   ------ --------------------------------------------------
1    Po1    up     1-112,114-120,800,810
                                 
vPC status ----------------------------------------------------------------------
id   Port   Status Consistency Reason                     Active vlans
--   ----   ------ ----------- ------                     ------------
40   Po40   up     success     success                    1-112,114-1
                                                          20,800,810    

自動回復機能は実際にどのように機能するか

このセクションでは、「背景説明」セクションで示したそれぞれの動作について個別に説明します。 ここでは、スイッチ S1 と S2 の両方で vPC 自動回復機能が設定されていて、スタートアップ コンフィギュレーションに保存されていると想定します。

  1. 停電により、両方の Nexus 7000 vPC ピアが同時にシャットダウンされ、一方のスイッチだけをオンにすることができるとします。
    116187-configure-vPC-01.jpg
    • S1 および S2 は両方ともオンです。 vPC はピア リンクとピア キープアライブで正しく形成されています。
    • S1 と S2 の両方が同時に電源オフになります。
    • ここで、一方のスイッチだけをオンにすることができます。 たとえば、電源オンになる唯一のスイッチが S2 であるとします。
    • vPC peer-link または peer-keepalive ステータスがオンになっていることを確認するために、S2 は vPC 自動回復機能タイムアウトを待機します。そのデフォルトは 240 秒ですが、auto-recovery reload-delay x コマンドでこれを設定できます(x は 240~3600 秒の範囲)。 これらのリンクのいずれかがオンであると(peer-link または peer-keepalive ステータス)、自動回復機能はトリガーされません。
    • タイムアウト後、両方のリンクがまだオフである場合(peer-link および peer-keepalive ステータス)、vPC 自動回復機能がイネーブルになり、S2 がプライマリになって、ローカル vPC をオンにするために開始します。 ピアがないため、整合性検査はバイパスされます。
    • ここで S1 がオンになります。 この時点で、S2 がプライマリ ロールを保持して S1 はセカンダリ ロールになります。整合性検査が実行され、適切なアクションが取られます。
  2. 最初に vPC ピア リンクがオフになり、次にプライマリ vPC ピアがオフになります。
    116187-configure-vPC-02.jpg
    • S1 および S2 は両方ともオンで、vPC はピア リンクとピア キープアライブで正しく形成されています。
    • 何らかの理由で、vPC ピア リンクが最初にオフになるとします。
    • vPC ピア キープアライブがまだオンであるため、デュアル アクティブが検出されます。 vPC セカンダリ S2 は、すべてのローカル vPC をオフにします。
    • ここで vPC プライマリ S1 がオフになるか、リロードします。
    • この停止により、vPC のピア キープアライブ リンクもオフになります。
    • S2 は、連続する 3 つのピア キープアライブ メッセージが失われるのを待機します。 何らかの理由で、vPC ピア リンクがオンになるか、または S2 がピア キープアライブ メッセージを受信して、自動回復機能はイネーブルになりません。
    • ただし、ピア リンクがオフのままで、連続する 3 つのピア キープアライブ メッセージが失われた場合、vPC 自動回復機能がイネーブルになります。
    • S2 はプライマリ ロールを引き継ぎ、ローカル vPC をイネーブルにして整合性検査がバイパスされます。
    • S1 がリロードを完了すると、S2 はプライマリ ロールを保持して S1 がセカンダリになります。整合性検査が実行され、適切なアクションが取られます。

: 両方のシナリオで説明されているように、vPC 自動回復機能で vPC ロールの一時停止を解除するスイッチは、ピア リンクがオンになった後でも、引き続きプライマリです。 もう一方のピアはセカンダリ ロールになり、整合性検査が完了するまでは自分の vPC を一時停止します。

次に、例を示します。

S1 の電源がオフになります。 想定どおりに S2 が運用上のプライマリになります。 ピア リンクとピア キープアライブ、およびすべての vPC リンクが S1 から切断されます。 S1 の電源は入っていません。 S1 は完全に分離されているため、(物理リンクは切断されていても)自動回復機能によって vPC がオンになり、プライマリ ロールを引き継ぎます。 ここで、S1 と S2 間のでピア リンクまたはピア キープアライブが接続される場合、S1 はプライマリ ロールを維持し、S2 はセカンダリになります。 この設定により、vPC ピア リンクとピアキープアライブの両方がオンになって整合性検査が完了するまでは、S2 が vPC を一時停止します。 このシナリオでは、S2 vPC がセカンダリで、S1 物理リンクがオフになっているため、トラフィックがブラック ホールに入る原因になります。

vPC 自動回復機能をイネーブルにすべきかどうか

vPC 環境で自動回復機能をイネーブルにすることを推奨します。

vPC 自動回復機能によってデュアル アクティブ シナリオが生じる可能性がわずかにあります。 たとえば、最初にピア リンクを失い、次にピア キープアライブを失った場合、デュアル アクティブ シナリオになります。

この状況で、各 vPC メンバー ポートは、デュアル アクティブ障害の前にアドバタイズしたのと同じリンク集約制御プロトコル ID をアドバタイズし続けます。

デュアル アクティブ シナリオが発生しても、ループに陥らないよう vPC トポロジによって実質的に保護されます。 最悪のシナリオとして、重複フレームがあります。 この状況でも、ループ防止メカニズムとして、各スイッチは vPC デュアル アクティブ障害の発生前と同じ BPDU ブリッジ ID を使用して、ブリッジ プロトコル データ ユニット(BPDU)を転送します。

直観的ではありませんが、必要なすべてのホストについて Cisco Nexus 7000 シリーズ ピアの両方でアドレス解決プロトコル(ARP)テーブルに値がすでに入っているならば、現在のトラフィック フローでのドロップなしにアクセス レイヤから集約レイヤにトラフィックを転送し続けることが依然として可能であり、それが適切でもあります。

ARP テーブルが新しい MAC アドレスを学習する必要がある場合には、問題が生じる可能性があります。 問題が生じる原因は、サーバからの ARP 応答が一方の Cisco Nexus 7000 シリーズ デバイスにハッシュされ、他方にはハッシュされない可能性があり、その場合はトラフィックが正しく流れることができないためです。

ただし、このような状況で障害が発生する前は、正しい PortChannel と Equal Cost Multipath(ECMP)設定によって両方の Cisco Nexus 7000 シリーズ デバイスにトラフィックが均等に分配されたていたと仮定しましょう。 この場合、サーバ間およびクライアントからサーバへのトラフィックは続行されますが、(ピア リンクの欠如のため)Cisco Nexus 7000 シリーズに直接接続された単一接続ホストが通信できなくなるという警告が表示されます。 また、1 台の Cisco Nexus 7000 シリーズで学習された新しい MAC アドレスを、そのピアで学習させることはできません。そのようにした場合、ピア Cisco Nexus 7000 シリーズ デバイスに到達するリターン トラフィックがあふれるためです。

詳細については、「Cisco NX-OS Software Virtual PortChannel: 基本概念」の 19 ページを参照してください。

確認

現在、この設定に使用できる確認手順はありません。

トラブルシューティング

現在のところ、この設定に関する特定のトラブルシューティング情報はありません。

関連情報


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 116187