Juniper MX240 × Proxmox SDN で作る EVPN/VXLAN ファブリック
Convivial Net（AS45689）では、仮想マシンの柔軟な配置と外部接続の冗長化を目的として、Juniper MX240 2台をスパインとした EVPN/VXLAN ファブリックを構築しました。本記事では、構成の全体像と設計上の工夫について紹介します。個別の設定詳細は別記事で取り上げる予定です。
なぜ EVPN/VXLAN を導入したか
Convivial Net では Proxmox VE 3ノードのクラスタでVMを運用しています。従来は VLAN ベースの L2 ネットワークに VRRP で冗長化したゲートウェイを置いていましたが、以下の課題がありました。
- VMを別ノードにライブマイグレーションすると、L2の延伸が必要になる
- ゲートウェイの冗長化が VRRP に依存しており、Active-Standby でしか動作しない
- サブネットを追加するたびに全スイッチの VLAN 設定を変更する必要がある
EVPN/VXLAN を導入することで、L2 ドメインをアンダーレイの上にオーバーレイとして構成でき、VMがどのノードに配置されていても同一セグメントに所属できるようになります。また、EVPN の Type-5 ルートを活用すれば、L3 のデフォルトルートもファブリック内で動的に配信できます。
ネットワーク構成の全体像
┌───────────────────────────────┐
│ Upstream / Transit │
│ HomeNOC, JCIX, ENTERNET, ... │
└──────────┬───────────────┬────┘
eBGP │ │ eBGP
┌──────────┴──┐ ┌──────┴──────────┐
│ bgp01 │ │ bgp02 │
│ (VyOS) │ │ (VyOS) │
└──────┬──────┘ └───────┬─────────┘
iBGP │ フルルート │ iBGP
┌───────────────┴────────────────────┴──────────────┐
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ core01 (MX240) │ │ core02 (MX240) │ │
│ │ RD: .160.1:2 │ │ RD: .160.2:2 │ │
│ │ EVPN-VRF │ │ EVPN-VRF │ │
│ │ + lt-0/2/0 │ │ + lt-0/2/0 │ │
│ └────────┬────────┘ └────────┬────────┘ │
└───────────┼────────────────────────┼──────────────┘
│ VXLAN overlay │
│ L2 VNI: 10170 │
│ L3 VNI: 20170 │
┌───────────┼─────────────────────────┼─────────────┐
│ ┌───────┴───┐ ┌─────────┐ ┌───┴───────┐ │
│ │ pve01 │ │ pve02 │ │ pve03 │ │
│ │ VTEP .21 │ │ VTEP .22│ │ VTEP .23 │ │
│ └─────┬─────┘ └────┬────┘ └─────┬─────┘ │
│ │ │ │ │
│ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │
│ │ VM │ │ VM │ │ VM │ │
│ │ GW: .1 │ │ GW: .1 │ │ GW: .1 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ Proxmox SDN │
└───────────────────────────────────────────────────┘構成は大きく4層に分かれています。
BGP-RT層（bgp01/bgp02）: VyOS で構成した BGP ルータで、上流トランジットや IX との eBGP セッションを持ち、フルルートを受信しています。
Core-RT層（core01/core02）: Juniper MX240 で構成したスパインルータです。iBGP の Route Reflector として動作し、BGP-RT 層からフルルートを受け取りつつ、Proxmox ノードとの EVPN セッションを持ちます。EVPN/VXLAN ファブリックの制御プレーンの中核です。
HV層（pve01/pve02/pve03）: Proxmox VE のハイパーバイザノードです。Proxmox SDN の EVPN コントローラが FRRouting（FRR）を自動設定し、VXLAN の VTEP として動作します。
VM層: 各 VM は Proxmox SDN が提供する anycast gateway（202.222.170.1）をデフォルトゲートウェイとして使用します。
設計のポイント
VM のデフォルトゲートウェイと MAC 学習
Proxmox SDN の EVPN 実装では、VM が起動してデフォルトゲートウェイ（202.222.170.1）に ARP を送ると、その VM の MAC アドレスが Linux カーネルの FDB に学習されます。FRR はこの MAC+IP ペアを EVPN Type-2 ルートとして MP-BGP で全ノードに広告します。
この仕組みにより、VM を立ち上げるだけで自動的にファブリック全体に存在が通知され、他のノードの VM やスパインルータからも到達可能になります。手動で何かを登録する必要はありません。
MX240 からのデフォルトルート配信（EVPN Type-5）
VM が外部と通信するためには、VRF 内にデフォルトルートが必要です。MX240 の EVPN-VRF（instance-type vrf）に 0.0.0.0/0 と ::/0 の static route を next-table inet.0 / next-table inet6.0 で設定し、これを EVPN Type-5 ルートとして全 Proxmox ノードに広告しています。
VM → Proxmox anycast GW (202.222.170.1)
→ VRF 内のデフォルトルート（Type-5 で MX240 から受信）
→ VXLAN でカプセル化 → MX240 → inet.0 のフルルートで最適経路へMX240 が2台あるので、PVE は両方からデフォルトルートを受信します。一方が障害で落ちても、BGP セッションのダウン検知により自動的にもう一方にフェイルオーバーします。
戻り経路の問題と lt- 論理トンネルによる解決
外向きのトラフィック（VM → 外部）は Type-5 のデフォルトルートで解決しますが、戻り（外部 → VM）には別の仕組みが必要です。上流ルータが 202.222.170.0/24 への経路を知っていなければ、応答パケットが返ってきません。
static route ... discard と iBGP の export policy を使って自網のプレフィックスを広告する方法もありますが、サブネットを追加するたびにルータの設定変更が必要になるのは運用上好ましくありません。
そこで採用したのが lt-（logical tunnel）インタフェースを使った BGP ルートリーク です。
Proxmox が Type-5 で 202.222.170.0/24 を広告
→ MX240 の EVPN-VRF.inet.0 に EVPN ルートとして着信
→ lt- 上の eBGP セッション（AS 64999 ↔ AS 64998）で inet.0 に注入
→ inet.0 に BGP learned route として格納
→ iBGP Route Reflector が bgp01/02 に自動再広告
→ bgp01/02 が上流に広告lt- インタフェースは MX240 の MPC（Trio チップ）が提供する仮想リンクで、同一ルータ内に2つの IP アドレスを持つ仮想的なポイントツーポイントリンクを作成できます。一方を EVPN-VRF に、もう一方を inet.0 に所属させ、その間で eBGP セッションを張ります。
local-as ... private no-prepend-global-as を使うことで、private AS（64999/64998）がリーク用の eBGP セッションでのみ使われ、iBGP で bgp01/02 に広告される際には影響を与えません。
この構成のメリット:
- Proxmox SDN でサブネットを追加するだけで、MX240 の設定変更なしに経路が自動的にファブリック外に広告される
- static discard も export policy も不要
- IRB インタフェースも不要（MX240 は L2 ドメインに参加しない）
IPv4/IPv6 デュアルスタック
IPv6 でも IPv4 と全く同じアーキテクチャを採用しています。lt- 上の BGP セッションは IPv4 と IPv6 で別々に張っています（IPv4 セッション経由で IPv6 プレフィックスを運ぶと、next-hop が IPv4-mapped IPv6 アドレスになり Junos が解決できないため）。
| IPv4 | IPv6 | |
|---|---|---|
| VM サブネット | 202.222.170.0/24 | 2001:df0:68:170::/64 |
| anycast GW | 202.222.170.1 | 2001:df0:68:170::1 |
| VRF デフォルト | 0.0.0.0/0 → inet.0 | ::/0 → inet6.0 |
| lt- リークセッション | 169.254.255.0/31 | fd00::/127 |
Proxmox SDN の役割
Proxmox SDN の EVPN コントローラが FRR の設定を自動生成するため、FRR を直接編集する必要はありません。SDN の GUI または設定ファイルで Zone、VNet、Subnet を定義して Apply するだけで、全ノードに同一の FRR 設定が展開されます。
SDN が生成する主な FRR 設定:
- iBGP ピアリング（MX240 の loopback 宛）
advertise-all-vni（L2 VNI の広告）advertise ipv4/ipv6 unicast（VRF の connected route を Type-5 で広告）redistribute connected（VRF 内の connected route を BGP に注入）route-target import（MX240 からの Type-5 を受け入れる）
使用機材
| 役割 | 機種 | 台数 |
|---|---|---|
| スパインルータ | Juniper MX240 (MPC Type 2 3D) | 2 |
| BGP ルータ | VyOS | 2 |
| ハイパーバイザ | Proxmox VE 9.1 | 3 |
| ストレージ | Ceph (Proxmox 統合) | 3ノード分散 |
ハマりどころ
構築中にいくつかのハマりどころがありました。別記事で詳細を書く予定ですが、概要だけ紹介します。
-
Junos の
instance-importは VPN インスタンスを参照できない: VRF から inet.0 へのルートリークにinstance-importを使おうとしましたが、Junos はこの機能で VPN タイプのインスタンスを参照することを許可していません。lt- BGP リークに切り替えることで解決しました。 -
next-tableのループ検出: VRF 内のroute 0.0.0.0/0 next-table inet.0と inet.0 側のroute 202.222.170.0/24 next-table EVPN-VRF.inet.0を同時に設定すると、Junos がルーティングループとして検出し commit を拒否します。片方向だけnext-tableを使い、逆方向は lt- BGP で解決しています。 -
local-as privateだけでは AS path にグローバル AS が残る: lt- BGP リークでlocal-as 64999 privateを設定しても、Junos はグローバル AS（45689）を AS path に追加します。no-prepend-global-asを付けないと、iBGP ピア（bgp01/02）がループ検出で経路を拒否します。 -
route-target の設定: Proxmox SDN の EVPN Zone は L2 VNI（10170）の RT（45689:10170）を自動設定しますが、L3 VNI（20170）の RT（45689:20170）は
rt-importで明示的に追加する必要があります。これがないと MX240 からの Type-5 デフォルトルートが VRF にインストールされません。 -
IPv4 BGP セッションで IPv6 プレフィックスを運ぶと next-hop が解決できない: IPv4 アドレスの BGP セッションで
family inet6 unicastをネゴすると、受信した IPv6 プレフィックスの next-hop が::ffff:169.254.255.0（IPv4-mapped IPv6）になり、Junos が経路を hidden にします。IPv4 と IPv6 で別々の BGP セッションを張ることで解決しました。
おわりに
Proxmox SDN の FRR 自動設定と Juniper MX240 の柔軟なルーティングインスタンス機能を組み合わせることで、運用負荷の低い EVPN/VXLAN ファブリックを構築できました。特に lt- 論理トンネルを使った BGP ルートリークは、static discard や export policy を一切使わずにファブリック内外の経路を動的に連携させる手法として、同様の構成を検討している方の参考になれば幸いです。