It is the top of the page

Link for moving within the page
To text (c)

このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。
お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。詳細はこちら

The main part starts here.

  1. ナレッジセンター
  2. 匠コラム

EVPN で変わる・変えられるデータセンターネットワーク①

匠コラム
ネットワーク
データセンター

ビジネス推進本部 第1応用技術部
コアネットワークチーム
平河内 竜樹

近年EVPN(Ethernet VPN)と呼ばれる技術の注目度が高まると共に、実装も増えてきています。本稿ではEVPNがどのような特徴を持ち、どういった場面で活用されていくか、検証結果を交えながら紹介していきます。（前編）

連載インデックス

EVPNの登場と変遷

EVPNの仕様が初めてInternet-Draftとして公開された時期は、2010年まで遡ります。データセンター分野においてアプリケーションおよび仮想化技術の進展はネットワークインフラへの要求に変化をもたらし、2010年にはTRILLに代表される様なレイヤ2マルチパスを実装した商用製品がリリースされました（*1、*2）。一方WANの分野でもVPLSの課題やデータセンター間を接続する要求に対応すべく、VPNシグナリングとして新しいBGPアドレスファミリを定義し、レイヤ 2 VPNの抜本的な更新を図る提言が行われていました。具体的にはJuniper Networks社のMAC-VPN とCisco Systems社のRouted VPLSと呼ばれるものが挙げられ、VPN技術に関心のある方の中にはこちらの名称を聞いたことがある方もいらっしゃるのではないでしょうか。そして2010年のIETF 78で目的を共有するこれら二つの仕様を統合して議論することが示され、高度なレイヤ2 VPNを実現するBGP/MPLSの技術、『Ethernet VPN』として再出発を切りました（図1・図2）。その後L2VPN WGのWG Draftとなって議論が継続され、2014年5月に機能要求がRFC7209として、2015年2月に基本仕様がRFC7432としてそれぞれ発行されました（*3、*4）。

a
図1：EVPNの登場（IETFドキュメントから引用）
b
図2：EVPN登場当初に期待されていた事項

EVPNの基本仕様ではトランスポートにMPLSが想定され、RFC7432でもこれに基づいて記載されています。また同じ時間軸でPBBと連携させたPBB-EVPNも並行して議論され、2015年9月にはこちらもRFC7623となりました（*5）。現在EVPNに関する検討は主にBESS WGで行われており、VXLAN/NVGREと連携させLSPを排したIPトランスポートにEVPNを適用する、EVPN Overlayもその中に含まれています。VXLANとの連携（以降、EVPN-VXLAN）は既に実装も登場しており、EVPNは高度な制御を提供する次世代のコントロールプレーンという文脈で使われることも目立ってきました。本稿ではこの流れに沿い、MPLSをトランスポートとする場合は明示的にEVPN-MPLSと記載します。

*1：http://www.cisco.com/web/JP/news/pr/2010/037.html

*2：http://www.atmarkit.co.jp/news/201011/18/brocade.html

*3：https://datatracker.ietf.org/doc/html/rfc7209

*4：https://datatracker.ietf.org/doc/html/rfc7432

*5：https://datatracker.ietf.org/doc/html/rfc7623

EVPNは改版の過程で仕様の追加・変更・削除が進められ、またEVPNの用途を拡張する仕様および実装も登場しました。その結果、EVPNは当初の想定と比較してより広い領域で適用される、場合によってはSDNプロトコルとも呼ばれる様な技術として磨かれていきました。以降、代表的な変化をいくつか挙げてみたいと思います。

【レイヤ3の統合】

これまでのレイヤ2 VPNと比較した際の特徴的な事項として、同時にレイヤ3の情報を取り扱うことが可能になりました。EVPNでは収容するホストのMAC情報を保持することによってBUMトラフィックの伝搬を抑制する機構を備えていましたが、IP情報も同時に認識・交換することによってIPトポロジの全体像が全てのVPN エッジで把握できる様になりました。これによってAnycast Default Gateway（Distributed Routing、Anycast Layer 3 Gateway、Distributed Layer 3 Gateway等も同じ意味で用いられる単語です）と呼ばれる動作が可能になります。

通常、あるサブネットに対して設置されるデフォルトゲートウェイは一つだけですが、ホスト単位の経路情報を保持し個々のVPNエッジがそれぞれ同一のデフォルトゲートウェイとして振る舞うことによって、サブネットが延伸される環境においても常に最短ホップでサブネット間の転送を行うことが可能になります（図3）。

c
図3：レイヤ2転送と同時にレイヤ3転送を行うVPN

このような動作を実現するレイヤ3対応のEVPNを実装した製品の例として、Juniper Networks社のMXが挙げられます。

d
図4：レイヤ2転送と同時にレイヤ3転送を行う試験の構成図

図4に示すトポロジにおいてEVPNをIRB機能と共に有効にしました。その結果図5・図6・図7出力の様に、デフォルトゲートウェイとなる共通のアドレス（出力中では末尾の数字が254）が両側のエッジで保持される共に、収容ホストの情報を示すEVPN Route Type 2の情報がホストルートとしてinet.0およびinet6.0のテーブルに挿入されている様子を確認することができました。参考として、この時の設定情報の抜粋は表1の様になります。

e
図5：ホストのアドレス情報をBGPで交換
f
図6：inet.0出力の抜粋
g
図7：inet6.0出力の抜粋

表1：MXにおける設定の抜粋

MX#1
interfaces {
ge-1/2/0 {
mtu 9192;
unit 0 {
family inet {
address 172.16.10.10/24;
}
family mpls;
}
}
ge-1/2/1 {
mtu 9192;
unit 0 {
family inet {
address 172.17.10.10/24;
}
family mpls;
}
}
ge-1/2/2 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
}
unit 3 {
encapsulation vlan-bridge;
vlan-id 3;
}
}
irb {
unit 2 {
family inet {
address 10.68.2.254/24;
}
family inet6 {
address 2001:db8:1068:2::254/64;
}
mac 00:11:22:33:44:55;
}
unit 3 {
family inet {
address 10.68.3.254/24;
}
family inet6 {
address 2001:db8:1068:3::254/64;
}
mac 00:22:44:66:88:00;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.10/32;
}
}
}
}
routing-options {
router-id 10.0.0.10;
autonomous-system 65001;
forwarding-table {
chained-composite-next-hop {
ingress {
evpn;
}
}
}
}
protocols {
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group IBGP {
type internal;
local-address 10.0.0.10;
family evpn {
signaling;
}
neighbor 10.0.0.20;
}
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
ldp {
interface all;
interface fxp0.0 {
disable;
}
}
}
routing-instances {
IP-VRF-0001 {
instance-type vrf;
interface irb.2;
interface irb.3;
route-distinguisher 10.0.0.10:1;
vrf-target target:65001:1;
vrf-table-label;
}
MAC-VRF-0002 {
instance-type evpn;
vlan-id 2;
interface ge-1/2/2.2;
routing-interface irb.2;
route-distinguisher 10.0.0.10:2;
vrf-target target:65001:2;
protocols {
evpn {
mac-table-size {
524287;
}
interface-mac-limit {
131071;
}
interface ge-1/2/2.2;
}
}
}
MAC-VRF-0003 {
instance-type evpn;
vlan-id 3;
interface ge-1/2/2.3;
routing-interface irb.3;
route-distinguisher 10.0.0.10:3;
vrf-target target:65001:3;
protocols {
evpn {
mac-table-size {
524287;
}
interface-mac-limit {
131071;
}
interface ge-1/2/2.3;
}
}
}
}
MX#2
interfaces {
ge-1/1/2 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
}
unit 3 {
encapsulation vlan-bridge;
vlan-id 3;
}
}
ge-1/3/0 {
mtu 9192;
unit 0 {
family inet {
address 172.16.20.20/24;
}
family mpls;
}
}
ge-1/3/1 {
mtu 9192;
unit 0 {
family inet {
address 172.17.20.20/24;
}
family mpls;
}
}
irb {
unit 2 {
family inet {
address 10.68.2.254/24;
}
family inet6 {
address 2001:db8:1068:2::254/64;
}
mac 00:11:22:33:44:55;
}
unit 3 {
family inet {
address 10.68.3.254/24;
}
family inet6 {
address 2001:db8:1068:3::254/64;
}
mac 00:22:44:66:88:00;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.20/32;
}
}
}
}
routing-options {
router-id 10.0.0.20;
autonomous-system 65001;
forwarding-table {
chained-composite-next-hop {
ingress {
evpn;
}
}
}
}
protocols {
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group IBGP {
type internal;
local-address 10.0.0.20;
family evpn {
signaling;
}
neighbor 10.0.0.10;
}
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
ldp {
interface all;
interface fxp0.0 {
disable;
}
}
}
routing-instances {
IP-VRF-0001 {
instance-type vrf;
interface irb.2;
interface irb.3;
route-distinguisher 10.0.0.20:1;
vrf-target target:65001:1;
vrf-table-label;
}
MAC-VRF-0002 {
instance-type evpn;
vlan-id 2;
interface ge-1/1/2.2;
routing-interface irb.2;
route-distinguisher 10.0.0.20:2;
vrf-target target:65001:2;
protocols {
evpn {
mac-table-size {
524287;
}
interface-mac-limit {
131071;
}
interface ge-1/1/2.2;
}
}
}
MAC-VRF-0003 {
instance-type evpn;
vlan-id 3;
interface ge-1/1/2.3;
routing-interface irb.3;
route-distinguisher 10.0.0.20:3;
vrf-target target:65001:3;
protocols {
evpn {
mac-table-size {
524287;
}
interface-mac-limit {
131071;
}
interface ge-1/1/2.3;
}
}
}
}

この状態で図3に示した通信に沿ってトラフィックを印加しました。もしデフォルトゲートウェイが1箇所にしか存在しない場合、各サイト内で行われるサブネット間通信（図3：濃い緑色の線）のうちどちらかは別サイトを経由して行われることになります。試験の結果、サイト内で行われるサブネット間通信のレートはVPNのコア側では観測されず、それぞれエッジで折り返して転送されることを確認できました。

この動作は、セグメントを広く伸ばし仮想マシンのマイグレーションやサーバの物理的な移設を行う環境において、常に最適なパス選出を可能にする効果があります。VPNがホストとして認識しない外部との通信に対してはCPEを含めた制御や名前解決での対応等さらに広い範囲での検討が必要となりますが、VPN配下にあるホスト間の通信は最短ホップの伝送が保証されます。

（後編に続く）

執筆者プロフィール

平河内 竜樹
 ネットワンシステムズ株式会社 ビジネス推進本部 第1応用技術部 コアネットワークチーム
所属
ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事

  • CCIE RS
  • CCIE SP

Webからのお問い合わせはこちらから

お問い合わせ窓口へ

ナレッジセンターを検索する

カテゴリーで検索

タグで検索