# EVPN ## 定義 EVPN(Ethernet VPN)は、BGP を制御プレーンとして用いるマルチテナント L2 VPN 技術(RFC 7432)であり、[[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]](RFC 8365)はこれを VXLAN・NVGRE・MPLS over GRE といったデータプレーンカプセル化の上に載せることで、マルチテナントデータセンター向けの Network Virtualization Overlay(NVO)ソリューションへ転用する。EVPN の核心は、MAC/IP アドレス学習をデータプレーンのフラッディング(unknown unicast・ARP)ではなく BGP による制御プレーン学習で行う点にあり、これによって Route Reflector を介したフルメッシュ BGP セッションの削減、Route Target による経路の限定配布、単一ルート撤回による mass withdrawal(高速収束)、All-Active 多重接続といった、BGP/MPLS VPN(RFC 4364)の系譜が持つスケーラビリティの資産を、データセンター仮想化のユースケースへ持ち込める。(Source: RFC 8365 §4) EVPN のルート・属性体系(RFC 7432 由来)は、MAC/IP Advertisement Route・Inclusive Multicast Ethernet Tag(IMET)Route・Ethernet A-D per ES Route・Ethernet A-D per EVI Route・Ethernet Segment Route の5種類を中心に構成される。ノードが NVE 1台のみに単一ホーミングされるハイパーバイザー常駐シナリオでは、このうち多重接続関連の3種類(Ethernet A-D per ES/EVI、Ethernet Segment Route)が不要になり、必要なルート・手続きが大きく縮小される。逆に ToR スイッチに NVE が常駐し、サーバが複数 NVE へ多重接続されるシナリオでは、RFC 7432 の多重接続機能一式——自動検出・高速収束/mass withdrawal・スプリットホライズン・Aliasing/Backup Path・DF(Designated Forwarder)選出——がフルに必要になる。(Source: RFC 8365 §7, §8) ## RFC 7432(基礎仕様)の中核機構 EVPN の基礎仕様である RFC 7432(2015年2月、IETF Standards Track、編集者 Ali Sajassi)は、MPLS を P-tunnel として使う場合の EVPN を規定する。マルチホーム接続されたサイトは Ethernet Segment(ES)という単位で扱われ、10 オクテットの Ethernet Segment Identifier(ESI、6種類の Type で符号化方式が異なる)で一意に識別される。EVPN NLRI(AFI=25 L2VPN、SAFI=70 EVPN)は 4 種類の Route Type を定義する: Ethernet Auto-discovery(A-D)ルート(ES 単位/EVI 単位、高速収束と Aliasing/Backup Path に使う)、MAC/IP Advertisement ルート(中核となる MAC/IP 到達性広告)、Inclusive Multicast Ethernet Tag ルート(BUM トラフィック用 P-tunnel の識別)、Ethernet Segment ルート(PE の自動発見と DF 選出)。(Source: [[@2015__RFC__BGP MPLS-Based Ethernet VPN]]) Designated Forwarder(DF)選出は既定で <ES, VLAN> の粒度で行う service carving 方式を採り、PE の IP アドレス順に割り当てた序数 i が `(VLAN mod N) = i` を満たす PE がその VLAN の DF になることで、同一 ES 上で VLAN ごとに異なる PE が DF となり負荷分散が実現する。MAC Mobility(MAC アドレスの ES 間移動)はシーケンス番号を持つ MAC Mobility 拡張コミュニティで安全に収束させ、M秒間(既定180秒)にN回(既定5回)の移動を検知すると重複 MAC の誤検知とみなして操作者へ警告し広告を停止する。(Source: [[@2015__RFC__BGP MPLS-Based Ethernet VPN]]) ## 横断的知見 - **EVPN の多重接続機能のうち、VXLAN/NVGRE カプセル化によって実質的な影響を受けるのはスプリットホライズンフィルタリングだけである**: RFC 7432 が定義する多重接続機能(自動検出・高速収束/mass withdrawal・Aliasing/Backup Path・DF 選出・スプリットホライズン)は本来 MPLS クライアント層(ESI ラベル)を前提に設計されている。RFC 8365 は、これらのうち Aliasing/Backup Path は Ethernet A-D per EVI ルートのフィールド設定を変えるだけで VXLAN/NVGRE でも同様に機能する一方、スプリットホライズンだけは ESI ラベルという MPLS 固有の機構に依存するため、VXLAN/NVGRE 用に「Local Bias」という別方式(ソース IP アドレスに基づくフィルタリング)を新規に定義する必要があったと明示する。これは EVPN という同一の制御プレーン仕様が、データプレーンのカプセル化次第で一部の手続きだけ作り替えを要するという、制御プレーンとデータプレーンの分離が不完全にしか成立しない具体例である。(Source: RFC 8365 §8.1, §8.3.1) - **EVPN の mass withdrawal 機構は、DCI(データセンター間接続)を ASBR 方式(inter-AS Option B)で構成すると per-ES 粒度から per-EVI 粒度へ後退する**: RFC 8365 は、ASBR が BGP ネクストホップを自身へ書き換えて EVPN ルートを中継する際、Ethernet A-D per ES ルート(mass withdrawal に使う)は originating PE の識別情報を失い正しく機能しなくなる一方、Ethernet A-D per EVI ルート(Aliasing に使う)は RD/RT による経路解決の一意性が保たれるため機能し続けると具体例(Figure 3, PE1/PE2 → ASBR1/ASBR2 → PE3)で示す。結果として、同一 AS 内の PE から受信した mass withdrawal は per-ES ルートで処理できるが、異なる AS 間(inter-AS Option B 経由)で受信した場合は per-EVI ルートの撤回に基づく粗い粒度でしか収束できない。これは [[MPLS]] が既に記録する inter-AS Option B の一般的な性質(ASBR によるネクストホップ書き換えが next-hop 起点の識別情報を失わせる)が、EVPN という別のプロトコルスタックにも同型の帰結をもたらすことを示す——BGP/MPLS VPN(RFC 4364)の inter-AS 接続方式が抱えるトレードオフは、単一のプロトコルに固有の問題ではなく、ASBR によるネクストホップ書き換えという設計パターンそのものに由来する構造的な限界である可能性を示唆する。(Source: RFC 8365 §10.2.2, [[MPLS]]) - **RFC 9161(Proxy ARP/ND の運用面)の重複IP検知は、RFC 7432 の MAC Mobility 重複検知(M秒内にN回移動でMAC重複とみなす)と同一の既定値(M=180秒・N=5回)・同一の検知アルゴリズムの骨格を IP アドレス版へ転用したものである**: RFC 7432 は MAC アドレスが Ethernet Segment 間を移動する現象(MAC Mobility)をシーケンス番号付き拡張コミュニティで検知し、M秒間にN回の移動で重複 MAC の誤検知とみなして操作者へ警告する。RFC 9161 の Proxy ARP/ND テーブルにおける重複IP検知は、検知対象が MAC ではなく IP→MAC エントリの変化である点を除けば、同じ「M秒間にN回」という閾値ベースの検知アルゴリズムと同じ既定パラメータ値をそのまま踏襲する。EVPN の設計者は L2(MAC 到達性)と L3/ARP(IP→MAC 束縛)という異なるレイヤーに、同一の検知アルゴリズムの骨格を繰り返し適用している。詳細は [[EVPNにおけるProxy ARP-ND]] を参照。(Source: [[@2022__IETF__RFC 9161 - Operational Aspects of Proxy ARP-ND in Ethernet Virtual Private Networks]] 本文§3.7, [[@2015__RFC__BGP MPLS-Based Ethernet VPN]]) ## 未解決の問い - RFC 8365 は GENEVE への適用が「別文書([EVPN-GENEVE])で扱う追加作業が必要」と述べるにとどまり、具体的にどの手続きが GENEVE 固有の作業を要するのかは本文書からは分からない。[[オーバーレイネットワーク]] ページが既に記録する GENEVE(VXLAN の可変長オプションによる後継カプセル化)の EVPN 対応状況は、本 wiki ではまだ EVPN-GENEVE ドラフト自体を ingest していないため未確認。 - EVPN の「Local Bias」スプリットホライズン方式は、NVE あたり ES 数ではなく NVE あたり1つの IP アドレスで済むという利点を持つ一方、イングレス NVE が DF 選出状態に関わらず全直結 ES へレプリケーションを強制される。この強制レプリケーションが大規模 All-Active 環境で帯域・処理コストにどの程度の追加負荷をもたらすかは、本文書には定量的な記述がない。 - Nicira/NSX 系のソフトウェア定義ネットワーク仮想化([[ネットワーク仮想化]] が記録する Popek-Goldberg 的「効率的で隔離された複製」)と、EVPN が体現する BGP/MPLS VPN 系譜のネットワーク仮想化は、同じ NVO という目的に対して制御プレーンの設計思想(集中コントローラ vs 分散 BGP)がどう異なるのか、両者を直接比較した文献は本 wiki にまだない。 ## 関連 - 概念: [[VXLAN]](本文書が分析する主要データプレーンカプセル化) / [[MPLS]](MPLS over GRE カプセル化、および inter-AS Option B との構造的類似) / [[VPLS]](EVPN が置き換えるデータプレーン学習方式の前身 L2VPN) / [[ネットワーク仮想化]](NVO の要件定義元、RFC 7364/7365) / [[オーバーレイネットワーク]](VXLAN/NVGRE による L2-over-IP オーバーレイの制御プレーンとしての位置づけ) / [[EVPNにおけるProxy ARP-ND]](RFC 9161、RFC 7432 の運用面の更新) - 実体: [[Cisco]] / [[Juniper Networks]] / [[Nokia]] / [[AT&T]] / [[Ali Sajassi]] / [[John Drake]] / [[Jorge Rabadan]] / [[IETF]] ## 出典 - [[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]](RFC 8365、全文) - [[@2015__RFC__BGP MPLS-Based Ethernet VPN]](RFC 7432、全文)