
- ライター:中嶋 太一
- 現在はCisco ASR9000/NCS5500(IOS-XR), Juniper Mist Wired/EX, Apstra/QFXの製品担当。
過去には、XOCにてCisco/Juniper社のルータやスイッチを始めとしたNI製品全般の障害対応業務や応用技術部にてCisco/Juniper社のルータの製品担当業務に従事。
保有資格:
CCIE RS, SP
JNCIP-DC, SP, ENT
JNCIS-MistAI-Wired
目次
こんにちは。
蝉の鳴き声も当たり前になった最近、テレワークをしながら、EVPN/VXLANの調査を進めております。
DCスイッチを持っているCisco社、Juniper社、Arista社、Extreme社(旧Brocade社)のドキュメントを確認いたしますと、L3 Fabricで利用するEVPN/VXLANのドキュメントが充実してきていると感じます。
案件としても、ちらほらと相談されることもあり、徐々に一般的な技術となるのも時間の問題かもしれません。
数年前にEVPNの標準化が完了し、各社の実装も進み、サービスプロバイダのネットワークだけでなく、データセンターのネットワークにおいても利用が検討されている状況と考えます。
データセンター内のネットワークにおいては、既存のL2ネットワークを実現するL2 FabricからL3 Fabricへと移行し始めていることが想定されます。
過去に掲載の下記ブログをもとにL2 Fabric、L3 Fabricに関して簡単に説明するのであれば、L2 Fabricは、STP、MC-LAGを利用したVLANベースのL2ネットワークの構成を指し、L3 Fabricは、VXLAN/EVPNを利用し、MACアドレスを経路として交換することでL3ネットワーク上にL2 Fabricを実現する構成を指します。
第3回 なぜデータセンタースイッチでないといけないのか? ~Fabricのすすめ~
さて、私が2019年度途中まで所属したXOC(弊社の障害対応を行う保守部門)での経験でお話しいたしますと、データセンターのネットワークは、まだまだ既存のL2 Fabricを構成していることが多く、L3 Fabricの構成はほとんどありませんでした。
一般的なネットワークシステムの工程では、設計は上流、運用/保守は下流に位置するため、運用/保守の場合、世に出たばかりの 新技術や新製品を目の当たりにするまでには時間がかかります。※XOCに障害問い合わせとしてくるということは、意図した通りに動作していないことが想定されるため、あまりよいことではないのですがね。
障害対応の際に確認できたL2 Fabricの各社(Cisco社、Juniper社、Arista社、Extreme社)の構成例を挙げるのであれば、Cisco社であれば、Nexus5000/9000とNexus2000を組み合わせたvPC/FEX構成やNexus7000のFabricPath構成、Juniper社であれば、QFX5000シリーズを利用したVCやVCF構成、Arista社であれば、DCSシリーズを利用したMLAG構成、Extreme社(旧Brocade社)であれば、VDXシリーズを利用したVCS構成となります。各社とも基本的にSpine/Leafの構成をとりますが、筐体冗長を含む論理構成は、前述の各社独自の機能になります。
※以下に登場する図の接続やシリーズはあくまでもイメージとなります。
図1. Cisco社 vPC/FEXやFabricPathの構成図


図2. Juniper社 VC/VCFの構成図

図3. Arista社のMLAGの構成図

図4. Extreme社のVCSの構成図

また、SDNを利用したネットワークもちらほらと確認できました。
大雑把なくくりではありますが、Cisco社のACI構成(APIC + Nexus9000)の構成やJuniper社のQfabricの構成が挙げられます。SDNとは、設定や管理画面などを提供するコントローラがDCスイッチを制御する構成となります。コントローラ側がコントロールプレーン、DCスイッチ側がデータプレーンとなります。
図5. Cisco社 ACIの構成図

図6. Juniper社 Qfabricの構成図

L3 Fabricに関しては、EVPN/VXLANを利用する構成ではありましたが、あいにく一部のみ確認しただけであり、詳細構成に関しては不明でした。
一般的なEVPN/VXLANの構成は、下図のようにSpine/Leaf間でEVPN/BGP接続を行い、LeafがVTEPとして動作することになります。
図7. EVPN/VXLANの一般的な構成図

なぜL2 FabricからL3 Fabricへの移行なのか
では、なぜデータセンター内のネットワークは、L2 FabricからL3 Fabricへと移行する流れなのでしょうか。
L3 Fabric、すなわち、EVPN/VXLANを用いた構成を利用した際の技術的なメリットは何になるのでしょうか。
ベンダー(メーカー)資料やネットの情報を色々と確認し、個人的に解釈し、一部列挙しますと下記と考えます。
- EVPN/VXLANは、RFCで標準化され、マルチベンダーで利用可能
標準化され、マルチベンダーで相互接続可能となることで、機器選定の選択肢が広がります。
前述のL2 マルチベンダーの各社の構成を確認いただければわかりますが、ベンダーごとに筐体冗長を含む論理構成が独自になり、その構成に他社のスイッチを組みことはできません。
L3 Fabricを利用することで、例えば、Cisco社のNexusをSpine、Juniper社のQFXをLeafにするといったことも可能となります。
- セグメントの識別で利用するVLANの制限を大幅に上回るVXLANが利用可能
VLANを利用した場合、識別可能なセグメント数が4096でしたが、VXLANを利用することで、1600万以上が識別可能となります。
こちらの意味するところとして、データセンター内を複数の事業者が利用しますので、それぞれの事業者を識別するための識別子が増えた、すなわち、より多くのセグメントを分離できることになります。結果として、データセンター内の事業者の収容数の増加にもつながります。
- アンダーレイでマルチキャストを必ずしも利用する必要がない
ユニキャストの到達性のみで構成することができますので、マルチキャストの設計が不要となります。マルチキャストを得意とするエンジニアには当てはまらないかもしれませんが、一般的にマルチキャストに対しアレルギーを持つ人は多いのではないでしょうか。
- ARPフラッディングの抑制が可能
サーバ上のVMからDCスイッチが受信するARPブロードキャストは、DCスイッチにてフラッディング されておりました。ARPの動作として、フラッディングするのは仕方ありませんが、大量にVMが存在する場合、ARPブロードキャス トの量は無視できなくなる可能性があります。ARP suppressionを利用することで、余計なフラッディングを抑制することで、帯域の有効利用 ができます。
L3 Fabricの欠点と考えられる内容
L3 Fabricに関して、メーカー資料やネットで落ちている資料は、概ね良い点しか挙げられていないように見受けられます。本来であれば、良い点、悪い点の両方が明示されていればよいのですが、そこまで明確に記載されたものはあまり多くない印象です。個人的な視点で、EVPN/VXLANを利用した場合の欠点を大まかに考えてみました。
- 技術習得するための時間がかかる
新しい技術の全般に関して言えることではありますが、L3 Fabricも同様です。
EVPNは、BGPベースであるため、ある程度BGPを理解していないと挙動を把握することは難しいと考えます。
OSPFやEIGRPなどIGPであれば、最近のデータセンターエンジニア?であれば、容易に理解できるものとは思われますが、BGPは大規模エンタープライズやサービスプロバイダで利用されるため、理解することが難しいと感じられるかもしれません。
- 相互接続がうまくいかない場合あり
RFCに準拠しており、理論上は接続可能とはいっても、各社の実装の違いでうまく接続できないこともあるでしょう。
この点に関しては、導入前検証で確認すべきポイントになると思われます。
敢えて相互接続の注意点を1つ挙げるのであれば、異なるメーカーへの問い合わせとなります。
例えば、2台の異なるベンダーで相互接続している場合、それぞれのベンダーに問い合わせることになります。
仮に一方のベンダーが原因である、と判明すればよいのですが、両ベンダー共に仕様通りで問題ない、といった場合は厄介です。
双方のベンダーの回答を、それぞれのベンダーに対し、やりとりをする必要があり、煩雑になりやすいと考えます。
また、仕様の内容になった場合、RFCを持ち出して議論する必要がでてくるため、EVPN/VXLANのRFCを始めとした仕様をよく理解する必要があるかもしれません。
- 追加コストが発生する場合あり
既存製品のソフトウェアのバージョンアップのみでEVPN/VXLANを利用可能となれば問題ありませんが、そもそもハードウェア自体がサポートしていない場合は、買い替える必要があります。
- L2 FabricからL3 Fabricへの移行シナリオの入念な確認が必要
L3 Fabric自体が幅広く普及し、一般的とまではまだ言えないため、移行実績もそこまで多くないものと想定されます。そのため、移行のためのシナリオや検証を入念にする必要があると考えております。
マルチベンダー環境の相互接続試験に関して
ところで、巷で新しい技術がRFCでドラフトとして出始めると、メーカーは試しにその機能を実装することがあります。昔?からCisco社を始めとしたワールドワイドのメーカーは、それらの機能を確認するために、相互接続試験を実施する場合があります。
国内でよく聞くのは、Interopのshownetあたりでしょうか。
弊社としては、情報収集目的でそれらのイベントへの参加やWeb経由にて調査をすることがあります。
Web経由での調査の一例として、今回取り上げたEVPN/VXLANのマルチベンダーの試験情報を調べてみますと、2019年にEANTCが主催のEVPNの相互接続試験の内容が確認できました。また、ワールドワイドの主要なベンダーがこのイベントに参加し、各社の装置の相互接続試験が実施されました。
英文ではありますが、下記URL内のスライド7~12のEVPN Enhancementの個所でEVPN-VXLAN接続の結果が項目ごとにありました。
Proxy-ARPの個所では、どのベンダーかの明示はありませんが、うまくBGP接続できなかった記載も確認できました(One vendor did not establish the BGP session~)。気になる方は、詳細を読み込んでみましょう。
Multi-Vendor Interoperability Test_EANTC_White Paper 2019
まとめ
EVPN/VXLANの標準化が完了し、各ベンダの実装も進み、相互接続試験まで開始されていることを考慮いたしますと、L2 FabricからL3 Fabricへの移行は自然な流れと言えそうです。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。