- ナレッジセンター
- 匠コラム
EVPN で変わる・変えられるデータセンターネットワーク⑤
- 匠コラム
- ネットワーク
- データセンター
ビジネス推進本部 応用技術部
エンタープライズSDNチーム
平河内 竜樹
今回はVXLANをデータプレーンとするEVPN-VXLANに着目し、スイッチ製品の検証結果を紹介したいと思います。
| 連載インデックス |
|---|
EVPN Anycast Default Gateway
EVPN-VXLANは、既に複数メーカーから対応のスイッチ製品がリリースされています。さらに2016年の1月から3月までの間だけでもJuniper Networks社がQFX10000シリーズでも対応OSをリリース（*1）・Brocade Communication社がVDXシリーズで同社初の対応OSをリリース（*2）・Cisco System社がNexus5600シリーズでの対応OSおよび対応可能な新機種をリリース（*3・*4）等の動向が挙げられ、今後も拡充されていくことが期待されます。
*1：http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/qfx-series/release-notes/qfx-series-junos-release-notes-15.1X53-D30-10000.pdf
*2：http://www.brocade.com/content/html/en/feature-support-matrix/nos-700-featuresupportmatrix/GUID-B1279CEC-F99A-4AF3-983B-2129144FF57F.html
*3：http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/release/notes/7x/Nexus5600_Release_Notes_7x.html
*4：http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/datasheet-c78-736608.html
対応製品の一つであるCisco Systems社 Nexus 9000シリーズは、2015年のEVPN正式リリース当初からARPの代理応答や第１回で挙げたAnycast Default Gatewayに対応しています。今回紹介するデータはNexus 9000 EVPN-VXLANを試験対象として、図1のトポロジにてホスト間の通信を想定し、基本的な疎通確認を実施した際の結果になります。参考として、この時の設定情報の抜粋は表1・表2の様になります。
結果、レイヤ2ネットワークの延伸と同時にサブネット間の転送が行われることを確認できました。標準のVXLANではBUM転送のためにIP Multicastを必要としますが、上記の構成ではUnicastのみ到達性がある状態で実現されています。
また今回の検証では、固定型モデルとなるNexus9300シリーズを利用しています。小型のボックススイッチにおいて、マルチプロトコルBGPが利用されている様子を改めて伺うことができました。EVPNはスイッチ実装において高度なファブリックを構成する技術として活用することが可能であり、とりわけオープン・スケーラブルといった要素が重視されるケースにおいて利点に映りやすいと考えられます。
なお、Nexus 9000 EVPN-VXLANの場合、VPNを経由するサブネット間通信ではレイヤ3用のVNIが利用されます。各エッジではIP-VRFにもVNIが割り当てられ、MAC/IP Advertisement RouteにはIP-VRFに対するRoute Targetが加えられます（図2）。
掘り下げて観察すると、MAC/IP Advertisement Routeを生成するための、ローカルでのアドレス学習はARPを介して行われていることが確認できました（*5）。それでは、何かしらの契機でARPキャッシュが構築される前に対象ホストへのサブネット間通信が発生した場合、通信は成立するのでしょうか（図3）。
レイヤ2の転送であればホストのMACアドレスは未学習の状態であってもフラッディングによって疎通することが期待されます。レイヤ3転送では原則unknown unicast floodingという概念は存在しませんが、ホスト単位でIP情報を保持してサブネット間転送を行うAnycast Default Gatewayにおいてホストルートの無い状態はブラックホールとならないのでしょうか。ホストルートの無い状態を再現し、対象のトラフィックを印加した際の挙動を確認した結果、以下の様になりました。
図1のキャプチャ箇所にて送出されているトラフィックを観察すると、まずローカルのVPNエッジを送信元とするARP Requestが宛先のセグメントに属するローカルのhost-facingインタフェースおよびVPNに送出されました（図4）。これは基本的なレイヤ3 転送の処理結果としてlongest matchで直接接続となるIRBインタフェース（今回の環境ではinterface Vlan）がLookupされ、生成されたARPがその後のレイヤ2転送によってフラッディングされた結果であると考えられます。
次に宛先のホストから発信されたARP ReplyはVPNを経由せず、代わりにリモートのVPNエッジからBGPのアップデートが送信されました（図5）。これはリモートのVPNエッジが、転送したARP Requestに対するReplyを自ら終端し、構築されたARPキャッシュを基にMAC/IP Advertisementを送信している動作と言えます。この直後より、対象のサブネット間通信は、レイヤ3転送用のセグメントを経由して疎通する様になりました。
上記より、対象ホストのホストルートが学習されていないタイミングにおいても、IP-VRF上に対応するPrefixが保持されていればそれを経由してサブネット間通信の到達性を確保することが可能となります。補足として、サブネット内通信でMACアドレスを学習していない場合、通常のレイヤ2転送と同じくフラッディングが行われ疎通することを確認しています。今回の試験によって、EVPNはMAC/IP Advertisementによって収容ホストの通信を最適化する機構を有しており、またホスト情報の未学習状態においても通信断は継続しないことが確認できました。全ての実装でこの通りに動作するとは限りませんが、EVPNにおいて一つの主要な挙動になると考えられます。関連して、第１回のMX EVPN-MPLSにおいても、ホスト情報の未学習時における挙動は同様となっていました。
なお、Nexus 9000のEVPN-VXLANはIP Prefix AdvertisementとなるEVPN Route Type 5に対応しています。この経路を受信するとIP-VRFにPrefixが挿入され、VPNに収容されるホストとはならない外部との通信をEVPN経由で制御できる様になる他、内部の宛先セグメントに対しローカルのIRBインタフェースが存在しない環境においても対象サブネットとの通信が可能になります。これは、IRB環境において、プロビジョニングやリソース利用効率の観点でプラスに働きます。
前述の検証環境において、片側のVPNエッジでinterface Vlanを無効にした場合も、IP-VRFには対象のPrefixがBGP経路としてエントリされることを確認しています（図6）。このケースで未学習のホストIPに対するサブネット間通信が発生した場合、対象の通信は経路に従ってVPN経由で転送され、ARPはEgressのエッジで送出されました。
EVPN Interoperability
Juniper Networks社のQFX5100シリーズにおいても、2015年にEVPN-VXLANをサポートした正式OSがリリースされています。前述の試験と同様に同一メーカーの製品間で接続する範囲においては、QFX 5100を対象とした試験でも、Multicastを省略したIP ネットワーク上でレイヤ2ネットワークの延伸を実現できることが確認できました。
異なるメーカーの製品間においても、共通のDraftに基づいているとすれば概して同じ動作を期待されますが、実際に差は生じてくるものなのでしょうか。そこで冗長化などは特に考慮せず、対象のVLANをVXLANで延伸するのみの単純な要件を想定して機器の設定を行い、中継網上でのミラーリングによってBGPトラフィックの比較を行いました。この試験ではJUNOS 14.1X53-D30.3・NX-OS 7.0(3)I2(1a)を利用しています。その結果、製品間でエンコーディングの異なる様子が確認されました（図7）。
EVPN Route Type 3を比較すると、Ethernet Tag IDが異なり、Nexus 9000ではゼロ・QFX5100ではVNIの値がエンコーディングされています。また、今回試した限りこの挙動を制御する術は発見されませんでした。これより、Nexus9000はセグメント単位でMAC-VRFを形成する「VLAN-base service」・QFX5100は一つのMAC-VRF上に複数のセグメントをマップする「VLAN-aware bundle service」の記載に沿った実装であることが伺えます（*6）。これはどちらが正しいという話ではなく、互いに異なる方式を選択している結果です。
*6：https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-overlay-02
相互接続環境においては、未定義範囲の存在や解釈の相違・独自実装部の混在等に起因して問題が発生することもありますが、「共通の仕様に則っている」ことが接続性確保の前提です。EVPNの場合、データプレーンの種類以外にも、MAC-VRFの生成単位・BUM配送の方式などに選択肢が存在します。機能として選択可能な製品であれば一方がもう一方に合わせることも可能ですが、互いに異なる動作しかサポートしない機器間で安定稼働を期待することは現実的ではありません。他の技術にも該当する内容となりますが、共通の仕様書に基づいていても、常に相互接続を実現できるとは限らない点には改めて注意が必要かもしれません。
製品の機能追加はビジネス上のニーズに因るところが大きく、また安定性は実際に利用されて成熟に至ることから、相互接続の現実性に関しては今後の進展次第と言えます。一方で、安定稼働や利用機能の制約などを踏まえると、何かしらの単位で製品は揃えるべきです。この観点では、EVPNのオープン性は、相互接続が可能であることよりネットワークの機能群としてベンダーロックインされない技術を採用できることが利点として映ると考えられます。
また、将来的に広く実装され技術としての成熟度も向上すれば、管理ドメインが分断される環境において相互接続用のプロトコルとして活用されるかもしれません。例えば外部とレイヤ2で接続するケースにおいて、互いにEVPN-VXLANを利用できれば、IPバックボーン上でエッジ冗長に対応した接続方式を選択することが可能になります。
まとめ
Cisco Systems社 Nexus 9000とJuniper Networks社のQFX 5100を対象としてEVPN-VXLANの基本的な疎通確認を行ったところ、Multicastを利用しないIPネットワーク上でレイヤ2ネットワークの延伸が可能となりました。またNexus 9000を対象として、Anycast Default Gatewayの動作、およびホスト情報が学習されていないタイミングにおいても通信可能となることが確認されました。
EVPNは選択肢の多様なVXLAN実装に対して高度な制御をオープンな形で提供し、この側面ではデータセンターのファブリックなどにおいて活用されることが期待されます。
執筆者プロフィール
平河内 竜樹
ネットワンシステムズ株式会社 ビジネス推進本部 応用技術部 エンタープライズSDNチーム
所属
ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事
- CCIE RS
- CCIE SP
Webからのお問い合わせはこちらから
ナレッジセンターを検索する
カテゴリーで検索
タグで検索