この記事は富士通クラウドテクノロジーズ Advent Calendar 2018 14日目です。
- 13日目は@blue271828の「Redis Module 事始め」でした。
- 15日目は@YoshidaYの「gRPCのシナリオテスト用コードを生成するprotocプラグインを作ってみた」です。
はじめに
インフラデザイン部で主にネットワークの企画/設計/運用を担当しているid:foobaron です。
今回は、 EVPN-VXLAN All-Active Multihoming による拠点間の接続を試してみました。 ネットワーク機器にはJuniper NetworksのvMX仮想ルータ を利用しました。
想定する読み手
本記事は次の読者を想定しています。
- クラウドの閉域網接続に利用される技術を知りたい方
- JunosでEVPN-VXLANを動かしてみたい方
EVPNとは
EVPNの特徴
EVPNの登場以前からVPLS (Virtual Private LAN Service) といった従来のL2 VPN技術があります。 こうした技術と比べ、EVPN導入のメリットとして、次のようなものが挙げられます。
- EVPN網のエッジに存在する機器でのAll-Active Multihomingによる帯域利用効率向上
- Control planeによるBUM (Broadcast, Unknown unicast, Multicast) トラフィックの フラッディング抑制と最適化
- 高速な経路収束
従来は、MC-LAG (Multi-Chassis Link Aggregation Group) などのベンダー独自実装によって、 Multihomingを実現していました。 EVPNでのMultihomingはRFC 7432で標準化されており、 マルチベンダーで実現可能です。
またVXLANなどでは、BUMトラフィックに対しARP requestやNeighblor soliitationで フラッディングが発生しますが、EVPNではオーバレイでのIngress Replicationに対し、Split Horizonという仕組みを利用することでBUMトラフィックの抑制と最適化をします。
従来のL2VPNでは、障害発生により多数のMACアドレスへの到達性に影響がある場合に 経路収束が長期化する恐れがありますが、EVPNではこの問題に対処しています。
EVPNの概要
EVPNでは図のように、Control planeとData planeが分離されています。 VPLSなどがData planeでMACアドレスを学習するのに対し、 EVPNではControl planeでMACアドレスの学習を実現します。
EVPNでは、Control planeでの制御情報の交換にはMP-BGP (Multi Protocol BGP) を利用します。
そして、データの転送に利用するData planeとして、MPLS (Multi-Protocol Label Switching) や PBB (Provider Backbone Bridge)、NVO (Network Virtualization Overlay) であるVXLANやNVGRE等、の中から 選択することができます。 本記事では、Data planeとしてNVOの1つであるVXLANを利用する、EVPN-VXLANを動かしてみます。
EVPN-VXLANの構成要素と用語
まずはEVPN-VXLANの構成要素と用語について確認しておきます。 EVPN-VXLANの構成要素は図のとおりです。
EVPN-VXLANの構成要素
- Customer Edge (CE) device ：EVPN網のエッジに存在する機器です。 例：データセンタ内の物理/仮想マシン、ルータ、スイッチ等。
- Provider Edge (PE) router：コアネットワークのエッジルータです。 VXLANトンネルのエンドポイント（VTEP：VXLAN Tunnel End Point）となります。
- Provider (P) router：コアネットワークのコアルータです。 PE routerでカプセル化されたVXLANパケットを、対向のPE routerまで中継します。
EVPN-VXLANの用語
- EVPN Virtual Instance (EVI) ：PE router内に作成され、特定のEVPNに紐づくインスタンスです。 CE deviceを分離させたい単位でインスタンスを分けることもできます。
- MAC-VRF：PE上のEVIごとに持つ、MACアドレスのVRF (Virtual Routing and Forwarding) テーブルです。CE deviceのMACアドレス情報を保持します。
- Route Distinguisher (RD) ：MAC-VRFごとに一意の識別子です。CEに対して適切なMAC-VRFを選択するために使用します。
- Route Target (RT) ：EVI上のMAC-VRFが、必要なMP-BGPの経路情報のみを受け取るために使用する属性値です。複数のRT値を付与して経路広告することができます。
- Ethernet Segment (ES) ：CE deviceがPE routerに接続するL2セグメントです。CE deviceがMultihomingで複数のPEに接続している場合にも、ESは1つなのでESIも1つです。
- Ethernet Segment Identifier (ESI) : CE deviceがPE routerに接続するL2セグメントの、一意の識別子です。CE deviceがMultihomingをする際に、接続先のPE routerのインタフェースに対して同一の値を設定しておきます。
EVPN-VXLANのControl planeとData plane
ノードの種類と用語について整理したので、次はControl planeとData planeについて見ていきます。
EVPN-VXLANでは、
- PE router同士の制御情報の交換
- CE deviceへのL2/L3の到達性の情報の交換
といった制御情報の交換をControl planeのMP-BGPによって行います。 そして、データの転送を司るData planeにはVXLANを使います。
Control plane：MP-BGP
PE routerはMP-BGPによりCE device間の到達性を実現します。 EVPN-VXLANでは、CE deviceからのトラフィックはVXLANでカプセル化されて、 対向のCE deviceが接続されているPE routerまで転送されます。
EVPNでは、PE router上にEVPNの仮想インスタンス（EVI）を作成し、その中にMAC-VRFを保持します。 上の図では2つのEVIが作成されているという想定です。
テナント（CE device）ごとにMAC-VRFがありますが、PE routerではそれをテナントごとに区別して使う必要があります。 そのため、テナントが利用しているIPアドレスプレフィックスの先頭にRDを結合した VPNプレフィックス というものを広告し、 PE routerがMP-BGPテーブル上で参照すべきMAC-VRFを決定します（上図）。 重複するIPアドレスプレフィックスを利用しているCEであっても、 RD値を参照することで MAC-VRFを一意に識別 できます。
これにより、PE routerはテナントごとに適切なMAC-VRFを選択してアドレス解決できます。
ですがRDは、あくまでテナントごとにMAC-VRFを選択するための識別子です。 リモートのPE routerからMP-BGPによる経路広告を受信するローカルのPE routerでは、 どのローカルMAC-VRFに経路情報を追加すべきか、RD値からは判断できません。
そこで、経路情報の送信側であるリモートPE routerでは、Route Target (RT) を付与して、 VPNプレフィックスを広報します。 受信側のローカルPE roouterでは、RT値とMAC-VRFを対応付けています。 広報されたVPNプレフィックスのRT値を見て、 一致するRT値に対応付けられているローカルMAC-VRFを更新します。 なお、リモートPE routerが広告するVPNプレフィックスに対して、複数のRT値を付与することも可能です。
Data plane：VXLAN
EVPN-VXLANにおけるVXLANは、Data planeでのパケットのカプセル化に利用されます。 エッジとなるVTEP間において、L2のフレームはVXLANヘッダでカプセル化され、IP/UDPによって転送されます。 VXLANでは、24ビットのVNI (Virtual Network Identifier) という識別子を用いて、L2ネットワークを分離します。
VNIとVLANのマッピング
従来のVLANを使っている既存のネットワークがあり、そのVLANをVXLANで延伸したいといった場合など、 VXLANのVNIは、VLAN IDに1:1でマッピングされて使われて使われることが多いと思います。 本記事でも、EVPN-VXLANを動かして、CEに割り当てたVLANをVXLANで延伸します。 VNIとVLANのマッピングをPE router上のEVIで利用するため、EVIとVNIを対応付けておく必要があります。 CE <-> VLAN <-> VNI <-> EVI という対応関係があるため、EVIとVNIがマッピングさえわかれば 問題ありません。
これまで見てきたMP-BGPの経路広告・学習の動作では一例として CustomerごとにMAC-VRF（すなわちMAC-VRFを持つEVI）を分けていました。 図のTenant-A、Tenant-Bそれぞれに異なるVLANを割り当て、 EVIは共通で1つのものを使用し、VLANでCustomerを一意に識別することも可能です。
EVPNのData planeとしてVXLANを使う場合、VNIとEVIのマッピング方法は次の2通りです。
- EVI:VNI = 1:1
1つ目の方法では、EVIにつき1つのVNI（で表される1つのサブネット）がマッピングされます。 そのため、特定のEVIのMAC-VRFのみに、経路広報先を絞ることができます。 また、MAC-VRFは、RTとVNIの組み合わせによって一意に識別できます。 なお、EVIにつきRD/RTを割り当てる必要があるため、 自動化しない限り、その管理が煩雑になってしまいます。
- EVI: VNI = 1:多
2つ目の方法では、EVIに対して複数のVNI（で表されるサブネット）がマッピングされます。 この方法では、特定のVNIを利用しないPE routerにも経路情報が学習されてしまいます。 MAC-VRFはRTによって一意に識別可能です。 MAC-VRFにおける特定のブリッジテーブルは、VNIによって一意に識別できます。
本記事では各PE Routerでそれぞれ1つのみEVIを作成し、各EVIに共通のRT値を設定しますが、
複数作成する場合にはどちらの方法を使うか選択する必要があります。
Junosでは、1の方法では routing-instance を分け、2の方法では1つの routing-instance 内の bridge-domain に複数のVNIを収容します。
スケーラビリティを考慮すると、特定のRTを持つEVIでのみMACアドレスを学習する、1の方法が一般的だと思います。
EVPN-VXLANを動かしてみる
PE router, P routerとしてJuniper NetworksのvMX仮想ルータを使用し、 CE deviceとしてLinuxマシンを使用して、検証環境を図のとおりに構築しました。
AS 65000：拠点間を接続する閉域網 (VXLAN網)AS 65001：CEを収容する拠点
P routerが属するVXLAN網でAS 65000、複数拠点に存在するPE routerは同一でAS 65001を使ってみます。 VXLANを構築するアンダーレイネットワークとして、 CE deviceに対するエッジルータであるPE routerが同一ASに所属する構成を取ることにします。
CE deviceがAll-ActiveのMulihomingを使えるよう、CE deviceに対して2台のPE routerを接続しています。
全てのノードを、仮想マシンとして1台のVMWare ESXiホスト上で稼働させました。
CE deviceとPE routerの間はVLANによって分けられています。 両端のCE deviceが使うVLANは異なっていても構いませんが、 VLANを延伸するVXLANのVNIは共通のものを使用する必要があります。
今回EVPN-VXLANを動かすために使った技術
- VLAN
- OSPF
- iBGP
- eBGP
- MP-iBGP
- VXLAN
今回は、拠点AS 65001にあるPE router同士でMP-iBGPのピアを確立しました。 なお、PEごとにAS番号を分け、MP-eBGPのピアを確立することも可能です。 構築が容易であることを踏まえ、今回はMP-iBGPを採用しました。
MP-iBGPのアンダーレイでの到達性を確保
このAS 65000を中継してAS 65001のPE router同士がMP-iBGPのピアを確立する必要があります。 Customer Edgeの経路情報の広報には、前述のとおりMP-iBGPを利用します。 MP-iBGPのピアを確立するために、まずはアンダーレイネットワークで到達性を確保します。
拠点間の閉域網：AS 65000内
AS 65000の閉域網では、AS内での各P router間の到達性を確保するためにOSPFを動かしています。 この後、AS 65000内のP routerはiBGPのピアを確立する必要があります （iBGPの必要性については後述します）。 iBGPでは、BGPセッションにてloopbackインタフェースのIPアドレスを利用する必要があるため、 そこへの到達性も、このOSPFで確保します。
P routerのOSPFの設定は次のとおりです。
P-Router# show protocols ospf`
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.0;
}
AS内のリンクを結ぶインタフェースおよびloopbackインタフェースを OSPFのエリアに所属させます。
その上でiBGPを動かしておきます。 iBGPの設定は次のとおりです。
P-Router# show protocols bgp group ibgp-core
type internal;
local-address <LOOPBACK_IP_ADDR>;
family inet-vpn {
any;
}
neighbor <NEIGHBOR-P_LOOPBACK_IP_ADDR_0>;
neighbor <NEIGHBOR-P_LOOPBACK_IP_ADDR_1>;
AS 65000内ではiBGPを走らせていますが、 VXLANオーバレイではiBGPによるベストパスが採用されます。 そのため、閉域網内でTraffic Engineering (TE) を実現するには、 OSPFの上でMPLSやSegment Routingを動かすとよいでしょう。
拠点：AS 65001間
MP-iBGPのピアを確立するために、PE routerはBGPセッションでloopbackインタフェースのIPアドレスを利用します。 アンダーレイでは、PE routerが他のPE routerのloopbackインタフェースのIPアドレスに対して 疎通できるようにしておきます。 AS 65001 <- eBGP -> AS 650000 <- eBGP -> AS 65001 という形で対向の同一AS番号のAS 65001に対して loopbackインタフェースの経路情報を学習させます。 AS 65000が、一方のAS 65001からの経路広告をAS 65001に伝搬するためにiBGPを使います。 先ほど、AS 65000内でiBGPを走らせたのはこのためです。
通常は、 AS_PATH に自身のAS番号が含まれている経路広告は、ループ防止のために学習しません。
PE routerが所属するASが同一になるため、ルーティングのループを防止しつつ通信できるように設定をします。
同一のAS番号を持つAS間の到達性をeBGPで確保する方法は、
Juniperのドキュメント
を参考にしました。
各PE routerに設定する、自身と同一のAS番号から広告された経路を学習するための設定は次のとおりです。
PE-Router# show protocols bgp group ebgp-underlay
group ebgp-underlay {
type external;
family inet {
unicast {
loops 2;
}
}
}
参考：loops (BGP Address Family) - TechLibrary - Juniper Networks
loops 2 により、 AS_PATH で自身と同じAS番号を2回以上検出した場合のみ経路を破棄します。
同じAS番号のASからの経路情報には、自身と同じAS番号は1つしか含まれていないため、その経路は学習されます。
今回、PE router間でMP-iBGPのために到達性を確保したいのはloopbackインタフェースのみです。
ですので、loopbackインタフェースのIPアドレスのみを広告することにします。
loopbackインタフェースには /32 のIPプレフィックスが割り当てられるので、 /32 の経路だけをPE routerが広告するようにします。
PE-Router# show policy-statement policy-export-loopback
from {
family inet;
protocol direct;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then accept;
作成したポリシーをPE routerのeBGPの設定に適用します。
PE-Router# show protocols bgp group ebgp-underlay export export policy-export-loopback;
以上の設定により、MP-iBGPを使うのに必要なPE router同士の到達性を確保できるようになりました。 これから、MP-iBGPの設定をして、PE同士が各拠点にあるCE deviceのMACアドレスを学習できるようにします。
MP-iBGPの設定
MP-iBGP ではEVPN-VXLAN網内のP router (AS 65000) は、 VTEPであるPE routerでVXLAN化されたパケットを伝送していくだけです。 PE router間のみでMP-iBGPのピアを確立すれば問題ありません。 これにより、 P routerがCE deviceへの経路を保持することなく 、 CE device間のEnd-to-Endで到達性のあるネットワークを構築できます。
PE routerのMP-iBGPの設定は次のとおりです。
PE-Router# show protocols bgp group mp-ibgp-overlay
group mp-ibgp-overlay {
type internal;
<LOOPBACK_IP_ADDR>;
family evpn {
signaling;
}
neighbor <<NEIGHBOR-PE_LOOPBACK_IP_ADDR_0>;
neighbor <<NEIGHBOR-PE_LOOPBACK_IP_ADDR_1>;
}
EVIの設定
EVPNでは、PE routerのEVIがMAC-VRFと対応付けられます。 そのために、PE router上でEVIを作成します。
PE-Router# show routing-instances evpn
vtep-source-interface lo0.0;
instance-type virtual-switch;
interface ae0.0;
route-distinguisher 65001:1;
vrf-target target:65001:1;
protocols {
evpn {
encapsulation vxlan;
extended-vni-list all;
multicast-mode ingress-replication;
}
}
bridge-domains {
<VNI_NAME> {
domain-type bridge;
vlan-id <VLAN_ID>;
vxlan {
vni <VNI>;
}
}
}
Junosでは、 virtual-switch の routing-instance としてEVIを作成します。
同一のRT値を設定したEVIからの経路を、対向のEVIのMAC-VRFでも学習します。
今回はVLANをVXLANで延伸するため、VLAN <-> VNIのマッピングを定義しておきます。
Multihomingの設定
最後に、Multihomingの設定をしておきます。 PE routerおよびCE deviceでLACP (Link Aggregation Control Protocol：IEEE 802.3ad) を使うことで、 CE deviceが複数のPE routerを使ってリンクアグリゲーションすることができます。 EVPNでは、LACPを設定したい複数のPE routerのインタフェース同士に同じESIを設定しておくことで、 PE router同士が直接接続されていない場合でも、互いを識別しMultihomingを実現します。
PE routerの設定
LACPを組むPE routerそれぞれに対して同じESIを設定します。 PE routerの設定は次のとおりです。
PE-Router# show interfaces
ge-0/0/0 {
gigether-options {
802.3ad ae0;
}
}
ae0 {
flexible-vlan-tagging;
esi {
<ESI>;
all-active;
}
aggregated-ether-options {
lacp {
active;
periodic fast;
}
}
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list <VLAN_ID>;
}
}
}
JunosでLACPを使うために、まずは使用するインタフェース ge-0/0/0 に対して
Aggregated Ethernet Interface ae0 を対応付け、 ae0 で lacp active を設定します。
また、作成したLACP用のインタフェースにESIを割り当て、All-ActiveでMultihomingするために、
esi all-active を設定しておきます。
この設定を、LACPを組みたいPE router全てに対して行います。
ESI値は、CE deviceと同じL2セグメントに接続されているPE routerに共通の値を設定します。
CE deviceの設定
今回はCE deviceとしてUbuntu 18.04を利用しました。 2台のPE routerの接続するため、2つのインタフェースを用意し、 それらでbondingインタフェースを作成しました。 束ねた2つのインタフェースをCEに接続しています。
netplanの設定は次のとおりです。
$ cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
renderer: networkd
ethernets:
ens192:
optional: true
ens224:
optional: true
bonds:
bond0:
interfaces:
- ens192
- ens224
parameters:
mode: 802.3ad
mii-monitor-interval: 1
transmit-hash-policy: layer2+3
optional: true
vlans:
<VLAN_IF>:
id: <VLAN_ID>
link: bond0
addresses:
- <IP_ADDR>
optional: true
長かった設定もこれで完了です。 これにより、EVPN-VXLANでCE間のVLANを延伸することができました。 最後に、疎通確認の結果を見てみます。
疎通と経路情報の確認
CE間の疎通確認
まずはじめに、CE間で疎通確認をしてみます。 CE-01, CE-02のIPアドレスは次のとおりです。
CE-01:# ip address show dev bond0.901
6: bond0.901@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
inet 10.255.1.1/24 brd 10.255.1.255 scope global bond0.901
valid_lft forever preferred_lft forever
inet6 fe80::509a:d7ff:fede:978c/64 scope link
valid_lft forever preferred_lft forever
CE-02:# ip address show dev bond0.907
6: bond0.907@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether ae:bc:7b:16:a8:dc brd ff:ff:ff:ff:ff:ff
inet 10.255.1.2/24 brd 10.255.1.255 scope global bond0.907
valid_lft forever preferred_lft forever
inet6 fe80::acbc:7bff:fe16:a8dc/64 scope link
valid_lft forever preferred_lft forever
なお、LACPにより束ねたインタフェースのMACアドレスは同じになっています。
CE-01:# ip link show
3: ens192: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
4: ens224: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
6: bond0.901@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
ひとまず、 CE-01からCE-02に ping と traceroute してみます。
CE-01:# ping 10.255.1.2 PING 10.255.1.2 (10.255.1.2) 56(84) bytes of data. 64 bytes from 10.255.1.2: icmp_seq=1 ttl=64 time=5.37 ms
CE-01:# traceroute 10.255.1.2 traceroute to 10.255.1.2 (10.255.1.2), 30 hops max, 60 byte packets 1 10.255.1.2 (10.255.1.2) 5.921 ms 5.800 ms 5.751 ms
VXLANによってL2を VLAN 901 <-> VNI 10901 <-> VLAN 907 間で延伸し、 L3では1hopで対向のCEに到達することを確認できました。
EVPNの経路情報
PE-01> show route advertising-protocol bgp 10.1.4.1 table vtep.evpn.0 detail
により、PE-03 ( 10.1.4.1 ) へ広告した経路情報を確認します。
Route Type-2 (MAC)
* 2:10.1.1.1:1::10901::52:9a:d7:de:97:8c/304 MAC/IP (1 entry, 1 announced)
BGP group overlay type Internal
Route Distinguisher: 10.1.1.1:1
Route Label: 10901
ESI: 00:00:00:00:00:00:00:01:00:64
Nexthop: Self
Localpref: 100
AS path: [65001] I
Communities: target:65001:1 encapsulation:vxlan(0x8)
Route Type-2 (MAC/IP)
* 2:10.1.1.1:1::10901::52:9a:d7:de:97:8c::10.255.1.1/304 MAC/IP (1 entry, 1 announced)
BGP group overlay type Internal
Route Distinguisher: 10.1.1.1:1
Route Label: 10901
ESI: 00:00:00:00:00:00:00:01:00:64
Nexthop: Self
Localpref: 100
AS path: [65001] I
Communities: target:65001:1 encapsulation:vxlan(0x8)
Route Type-3
* 3:10.1.1.1:1::10901::10.1.1.1/248 IM (1 entry, 1 announced)
BGP group overlay type Internal
Route Distinguisher: 10.1.1.1:1
Route Label: 10901
PMSI: Flags 0x0: Label 10901: Type INGRESS-REPLICATION 10.1.1.1
Nexthop: Self
Localpref: 100
AS path: [65001] I
Communities: target:65001:1 encapsulation:vxlan(0x8)
PMSI: Flags 0x0: Label 681: Type INGRESS-REPLICATION 10.1.1.1
PE-01にてPE-01 ( 10.1.1.1 ) , PE-03 ( 10.1.4.1 ) で経路情報を確認すると、MP-iBGPによる経路情報が載っていることがわかります。
PE-01> show route table vtep.evpn.0
2:10.1.1.1:1::10901::52:9a:d7:de:97:8c::10.255.1.1/304 MAC/IP
*[EVPN/170] 00:00:30
Indirect
2:10.1.4.1:1::10901::ae:bc:7b:16:a8:dc::10.255.1.2/304 MAC/IP
*[BGP/170] 00:21:53, localpref 100, from 10.1.4.1
AS path: I, validation-state: unverified
> to 192.168.0.7 via ge-0/0/1.0
MAC-VRFのimportポリシー
PE-01のMAC-VRFのimportポリシーを確認してみます。
PE-01> show policy __vrf-import-evpn-internal__
Policy __vrf-import-evpn-internal__:
Term unnamed:
from community __vrf-community-vtep-common-internal__ [target:65001:1 ]
then accept
Term unnamed:
then reject
vrf-target target:65001:1 のみを設定しておくと、デフォルトで、
指定したコミュニティで経路を受け入れるようになります。
対向のCEでも同様です。
ブリッジテーブル
PE-01のブリッジテーブルを確認してみます。
PE-01> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vtep
Bridging domain : vni10901, VLAN : 901
MAC MAC Logical Active
address flags interface source
52:9a:d7:de:97:8c DL ae0.0
ae:bc:7b:16:a8:dc DR esi.605 00:00:00:00:00:00:00:02:00:64
PE-01がCE-01のMACアドレス 52:9a:d7:de:97:8c および CE-02のMACアドレス ae:bc:7b:16:a8:dc を学習しています。
また、CE-02が接続するPE-03, PE-04のESIが 00:00:00:00:00:00:00:02:00:64 であることも学習しています。
終わりに
今回は、Juniper NetworksのvMX仮想ルータとOSPFやiBGP、eBGP、MP-iBGP、VXLANといった様々な技術を組み合わせることで、 EVPN-VXLANによりVLANを延伸できることを検証しました。
富士通クラウドテクノロジーズでは、ニフクラのデータセンタ内およびデータセンタ間のネットワークを支えるため、 こうした新しいネットワーク技術の導入を進めています。
