TechLeague

    Cisco

    Cisco Nexus 9000 VXLAN EVPN Multi-Siteをマスターする：2026年設計ガイド

    TechLeague Editorial··14 分で読了

    OTVやVPLSによる「ストレッチL2」ドメインの時代は終わりを告げました。マルチポッド接続のためにまだバックツーバックのvPCに依存している場合、そのブラストゾーンは刻々と時限爆弾と化しています。2026年において、分散した高性能データセンターを相互接続するための唯一防御可能なアーキテクチャは、Nexus 9000 VXLAN EVPN Multi-Siteモデルであり、ハードウェアベースのBorder Gateway (BGW)機能を利用して障害ドメインをローカライズしつつ、シームレスなワークロードモビリティを維持します。

    ストレッチファブリックの誤謬

    長年、ネットワークアーキテクトは、複数の物理サイトにまたがる単一の統合ファブリックという「聖杯」を追い求めてきました。このアプローチは、vMotionとIPの一貫性を理論的に単純化する一方で、脆弱な「運命共有」環境を生み出しました。サイトAでの単一のBUM（Broadcast, Unknown Unicast, Multicast）ストームは、サイトBとCを同時にダウンさせる可能性があり、実際にそうなりました。CiscoのNX-OS版VXLAN EVPN Multi-Siteは、サイト内プロトコルをサイト間ネットワーク（ISN）から分離することで、この問題を解決します。

    標準的なMulti-Site設計では、各サイトは独自の独立したBGP EVPNコントロールプレーンを運用します。Border Gateway (BGW)は、サイト内VXLANトンネルの終端点であり、サイト間トンネルの始点として機能します。従来のストレッチとは異なり、BGWはNext-Hopを書き換え、Route Targetを変更することで、MAC/IP学習が隔離されるようにします。サイトAでループが発生した場合、そのサイト内のスパニングツリーまたはストーム制御メカニズムが、高遅延のISNリンクを介して伝播する前にそれを捕捉します。

    ハードウェア選定：Cloud Scale必須

    初代Nexus 9300シリーズでMulti-Siteを稼働させようとしないでください。必要なVXLAN-to-VXLAN終端と、L3VNIおよびL2VNIマッピングに必要なTCAMエントリをサポートするには、Cloud Scale ASIC（EX, FX, FX2, FX3、または新しいGX/GX2シリーズ）が必要です。特にBorder Gatewayの役割では、Nexus 9364C-GXまたは9336C-FX2が、100G/400G密度における当社のゴールドスタンダードです。

    2026年には400Gバックボーンへの移行が進むため、9300-GXシリーズは特に重要です。これらは、高帯域幅の内部スパインから、帯域幅が低い可能性のあるISN回線に移行する際に発生するマイクロバーストを処理するために必要なディープバッファを提供します。複雑なEVPN Multi-Site展開においては、9200シリーズをBGWの役割に使用することは避けてください。機能の同等性が単純に不足しています。

    Border Gateway (BGW)のアーキテクチャ

    Border Gatewayは、この設計で最も重要なコンポーネントです。主な展開モデルは2つあります。分散型BGW（スパインがBGW）または専用型BGW（リーフがBGW）です。TechLeagueでは、大規模なエンタープライズ環境向けには、ほとんどの場合、専用型BGWモデル（Border Leaf）を推奨しています。スパインをBGWとして使用すると、ラックのRUスペースをいくらか節約できますが、スパインに外部向けの完全なBGPルーティングテーブルを維持させ、CPU負荷を増加させ、管理境界を複雑にします。

    高可用性：Anycast BGW vs. vPC BGW

    旧来のエンジニアは、BGWをvPCペアに配置しようとしますが、これは誤りです。VXLAN EVPN Multi-Siteは、Anycast BGW（仮想IP）モデルをサポートしています。この設定では、複数のBGWがVXLANトンネルエンドポイント（VTEP）に同じエニーキャストIPアドレスを共有します。Anycast BGWを使用することで、ISNを介した最大6または8wayのECMPパスが可能になり、2ノードのvPCクラスターよりもはるかに高いレジリエンスとスループットを提供します。

    
evpn multisite border-gateway 100
  delay-restore time 30
  provision-model anycast-gw
  multisite-id 1

    エニーキャストモデルを使用することで、ゲートウェイ間のvPC Peer-Linkの必要性がなくなります。これは、これまで収束に敏感な環境では障害点となっていました。1つのBGWが故障した場合、ISN上のBGP収束は、複雑なLACPネゴシエーションを必要とせずに、トラフィックを他のエニーキャストメンバーに再ルーティングします。

    サイト間ネットワーク (ISN)：複雑化をやめる

    ISNは、設計の中で最も誤解されやすい部分です。ISNはEVPNを話す必要はありません。実際、話すべきではありません。ISNは、BGW VTEP間のIP到達性を提供する純粋なトランスポート媒体です。MTU 1550+（50バイトのVXLANヘッダーに対応するため）をサポートし、OSPFやIS-ISのようなIGPを実行する必要があります。

    BGWはISNを介して、互いにMulti-Hop MP-BGP EVPNピーリングを確立します。特に3サイトを超えるスケールの場合、これらの接続を管理するためにBGP Peer Groupsを使用することを強く推奨します。以下は、ISNピーリングに関する典型的なBGW設定スニペットです。

    
router bgp 65001
  neighbor 10.255.255.10 remote-as 65002
    description Peer_to_Site_B_BGW
    update-source loopback1
    ebgp-multihop 5
    address-family l2vpn evpn
      send-community extended
      rewrite-evpn-rt-asn

    rewrite-evpn-rt-asnコマンドは非常に重要です。これにより、BGWはサイト間でRoute Targetを変換でき、ISNを通過するトラフィックでラベルが正しく解釈されることを保証します。

    L3マルチキャストとBUMトラフィック処理

    WANを溶かすことなくサイト間でBUMトラフィックを処理することは、ジュニアアドミンとシニアエンジニアを分ける違いです。選択肢は2つあります。Ingress Replication (IR)またはLocal-Bias Multicastです。2026年の設計では、非常に特定の高帯域幅マルチキャスト要件がない限り、Multi-Site最適化されたIngress Replicationが標準です。IRは、各リモートサイトに対してBUMパケットの個別のユニキャストコピーを作成しますが、BGWはリモートサイトに1つだけコピーを送信し、リモートBGWはそれをローカルでリーフに複製するほどスマートです。この「ヘッドエンドレプリケーション」により、ISN上の帯域幅負荷が大幅に軽減されます。

    コアでマルチキャストを使用する必要がある場合は、ISNがPIM-BSRまたはPIM-RPをサポートしていることを確認してください。ただし、複数の管理ドメインにわたるRPの管理の複雑さは、90%の企業にとって効率性よりもデメリットが大きいです。

    セキュリティとポリシー：グループベースポリシー（GBP）によるマイクロセグメンテーション

    標準的なVXLAN EVPNは、VNIとL2/L3情報のみを伝送します。サイト間でセキュリティ体制を維持したい場合は、VXLAN-GPO (Group-Based Policy)を実装する必要があります。これにより、SGT（Scalable Group Tags）をVXLANヘッダーに含めることができます。サイトAのユーザー（SGT 10）がサイトBのサーバーと通信する場合、BGWはそのタグを保持します。これにより、サイトBのファイアウォールまたはNexusリーフは、変更された可能性のあるIPアドレスではなくSGTに基づいてポリシーを適用できます。

    Nexus ACI vs. Standalone EVPNに関するガイドで詳述したように、NX-OSにおけるSGTの手動オーケストレーションは、顧客をACIに引き寄せる主な「ペインポイント」です。ただし、CLI優先のショップである場合、NX-OS Multi-Siteを使用することで、コントロールプレーンの可視性が向上し、APICの「ブラックボックス」的な性質を回避できます。

    検証と運用上の現実

    Multi-Siteのトラブルシューティングには、show nve multisiteコマンドの習熟が不可欠です。隣接関係を確認するだけでなく、BGWが実際に正しいサイトIDをアドバタイズしているかも確認します。一般的な障害点は、同じファブリック内のサイトIDの不一致であり、BGWがループを防ぐためにインターサイトVIPをシャットダウンしてしまいます。

    
# BGWステータスの確認
show nve multisite border-gateway
# リモートサイトの到達性確認
show bgp l2vpn evpn summary
# サイト間のVNIマッピングの確認
show nve vni

    ISNの遅延がBGP収束に影響することを想定してください。keepaliveとholdtimeタイマーを調整しますが、専用のダークファイバーリンクがない限り、秒以下にするのは避けてください。標準的な10ms-20msのWANトランジットでは、3秒のキープアライブが、小さなジッタイベント中のフラッピングを防ぐための「スイートスポット」です。

    結論

    Cisco Nexus 9000 VXLAN EVPN Multi-Siteは、巨大でフラットなL2ドメインのリスクを継承することなく、最新のデータセンターをスケーリングするための唯一の方法です。Anycast BGWとCloud Scale ASICを使用することで、2026年の高速要求をサポートする、回復力のあるマルチホーム環境を構築できます。現在の設計がストレッチvPCや複雑なOTVオーバーレイに依存している場合、リプラットフォームの時期です。ファブリック設計の専門家によるレビューをご希望の場合、または展開のためにTier-3エンジニアリングチームを導入したい場合は、techleague.ioの料金ページをご覧になり、インフラストのモダナイゼーションを加速する方法をご確認ください。

    よくある質問

    単一のストレッチVXLANファブリックよりもMulti-Siteが推奨される理由は何ですか？+

    BGWがデータプレーンの「フィルター」として機能し、ローカルVNIをリモートVNIに変換し、ローカルカプセル化を解除するためです。これにより、あるサイトでのブロードキャストループやスパニングツリー障害が、別のサイトのCP/DPに影響を及ぼすのを防ぎます。

    旧世代の9300シリーズ（非EX/FX）スイッチをBorder Gatewayとして使用できますか？+

    FX2やGXのようなCloud Scale ASICは、BGWに必要なVXLAN-to-VXLANの「ダブルルックアップ」をサポートするため必須です。旧世代のASICでは、必要なカプセル化と非カプセル化をラインレートで一度に実行できません。

    Border Gatewayの高可用性にvPCは必須ですか？+

    Anycast BGWはスケーラビリティが大幅に優れています。複数のBGWが仮想IPを共有することで、サイト間トラフィックのL3 ECMPが可能になり、vPC Peer-Linkの独自性な制限と障害ドメインのリスクを回避できます。

    サイト間ネットワーク（ISN）の具体的な要件は何ですか？+

    ISNはIP到達性を提供し、少なくとも1550バイトのMTUをサポートするだけで十分です。ISNはVXLAN認識やEVPN認識である必要はなく、BGW VTEP間でカプセル化されたパケットをルーティングするだけです。

    'rewrite-evpn-rt-asn'コマンドの実際の機能は何ですか？+

    'rewrite-evpn-rt-asn'コマンドは、BGWが自身のAS番号でEVPNルートを再生成できるようにします。これは、Route Targetが独立したBGPドメイン間で正しくマッピングされる必要があるマルチAS設計では非常に重要です。

    サイト間のBUMトラフィックにはIngress Replicationとマルチキャストのどちらを使用すべきですか？+

    ほとんどの企業では、Ingress Replication（IR）が推奨される方法です。これは、BGWを使用してBUMトラフィックをユニキャストとしてリモートサイトに複製することでISNの設定を簡素化し、コアでのPIMやRPの必要性を排除します。