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

ビジネス推進本部 応用技術部
エンタープライズSDNチーム
平河内 竜樹

最終回では、マネジメントプレーンに着目した検証結果を紹介したいと思います。

連載インデックス

EVPNの設定管理

VPNの運用においては、ネットワークやユーザの追加などに応じた、機器の設定変更が発生します。具体的なタスクとして、「転送テーブルおよび収容ネットワークの新規作成」や「転送テーブル・収容ネットワーク間の関連付け」といった作業が挙げられます(図1)。レイヤ3を扱う場合、IPのアドレッシングやルーティングに関する設定も発生します。

図1
図1:VPNにおけるセグメント追加への対応

このような作業を手動で実施する場合、特に多数のエッジ機器が存在する環境・セグメントの追加が頻繁に行われる環境では、開通時間の長期化やヒューマンエラーの誘発といった形で影響を及ぼす可能性があります。これはEVPNにおいても該当し、例えばデータセンターのファブリックにEVPNを適用する際には、収容される物理セグメントや仮想ネットワークの変更頻度に応じて運用上の検討が必要となります。対策として、何かしらの形で管理点の一元化や変更操作の簡素化を提供できれば、作業工数の圧縮やオペレーションミスの抑制を実現することが可能になります。以降より、その具体的な方法について、試験結果を交えて紹介していきたいと思います。

今回はEVPN-VXLANを用いたファブリックの運用を想定し、試験環境としてCisco Systems社のNexus 5600シリーズを用意しました。まず図2のトポロジを対象にVLAN ID 2および3のセグメントが延伸される環境を事前に構築しておき、その後に延伸対象としてVLAN 4を追加する、というシナリオになります。これは以降紹介する三つの試験に共通した操作となります。参考として、事前設定情報の抜粋は表1の様になります。

図2
図2:EVPN-VXLAN経由でレイヤ2ネットワークを延伸する試験の構成図

表1:Nexus5600における設定の抜粋(VPN関連)

N5600#1
feature vn-segment-vlan-based
feature nv overlay
feature bgp
nv overlay evpn
hardware ethernet store-and-fwd-switching

vlan 2
  vn-segment 5002
vlan 3
  vn-segment 5003

interface nve1
  no shutdown
  source-interface loopback0
  host-reachability protocol bgp
  member vni 5002-5003
    mcast-group 239.1.1.1

router bgp 65001
  router-id 10.0.0.10
  neighbor 10.0.0.20
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community both

evpn
  vni 5002 l2
    rd auto
    route-target import auto
    route-target export auto
  vni 5003 l2
    rd auto
    route-target import auto
    route-target export auto

N5600#2
feature vn-segment-vlan-based
feature nv overlay
feature bgp
nv overlay evpn
hardware ethernet store-and-fwd-switching

vlan 2
  vn-segment 5002
vlan 3
  vn-segment 5003

interface nve1
  no shutdown
  source-interface loopback0
  host-reachability protocol bgp
  member vni 5002-5003
    mcast-group 239.1.1.1

router bgp 65001
  router-id 10.0.0.20
  neighbor 10.0.0.10
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community both

evpn
  vni 5002 l2
    rd auto
    route-target import auto
    route-target export auto
  vni 5003 l2
    rd auto
    route-target import auto
    route-target export auto

XMPPの活用

最初に、管理点の一元化を提供する手法の一つとして、XMPP (Extensible Messaging and Presence Protocol) の活用が挙げられます。XMPPはJabber等インスタントメッセージの分野で開発・利用されてきたプロトコルですが、昨今はネットワーク製品の中でも活用されています。形態によってはVPNシグナリングとして用いられることもありますが、ここでは同じグループに属する機器に対し共通のCLIコマンドを同時発行する用途に着目します(図3)。

図3
図3:XMPPによるCLI操作

本項の試験では、XMPPサーバに同社製品のDCNM (Data Center Network Manager)を準備し、CLI操作はグループに属する機器のうち任意の1台から実行する形式を取ります。この環境で対象のVLAN追加を行った場合、機器上の操作は図4の様になりました。参考として、この時のXMPPに関する設定情報の抜粋は表2の様になります。

図4
図4:XMPPを利用した設定例

表2:Nexus5600における設定の抜粋(XMPP関連)

N5600#1
hostname nxos01
ip host {XMPP_SERVER_NAME} {XMPP_SERVER_ADDRESS}
feature fabric access
fabric access server {XMPP_SERVER_NAME} vrf management password {PASSWORD}
fabric access group dcnm-fabric
N5600#2
hostname nxos02
ip host {XMPP_SERVER_NAME} {XMPP_SERVER_ADDRESS}
feature fabric access
fabric access server {XMPP_SERVER_NAME} vrf management password {PASSWORD}
fabric access group dcnm-fabric

図4の通り、単一のCLI上で通常の変更操作と同一の手順を踏むことによって、目的の設定変更は達成されます。この時、入力するコマンドは必要とされる操作は通常のCLIで実行するものと同一であり、既存のオペレーションに習熟していればそのノウハウをそのまま踏襲することができます。図4の例では、対象のVLAN追加を行った後に、前後の差分確認にCisco NexusシリーズのOSとなるNX-OSのコマンドを活用していることが伺えます。留意点として、グループ内にプッシュされるコマンドは完全に共通のものとなります。VNIにマップするVLAN IDを変えたい場合などではVLAN空間を共有する単位でグループを作成する、ホスト側のインタフェースに対するVLAN関連設定は固定化・共通化できる様にしておく、といった方策が必要になります。

またXMPPは設定変更だけでなく日々のちょっとした確認を行う手段としても活用できます。図5はXMPPを利用し機器のバージョン情報とUptimeをshowコマンドで取得した例、図6は対象MACアドレスの収容機器を探索した例となります。SNMPでは確認する術が無い・OIDの調査に時間を要してしまうといったケースにも対応することができます。

図5
図5:XMPPを利用した状態情報の収集(インベントリ情報の採取)

図6
図6:XMPPを利用した状態情報の収集(該当エントリを持つ機器の探索)

ネットワーク機器におけるAPIの活用

二つ目のアプローチとしては、変更操作のプログラム化が挙げられます。これは、追加対象セグメントの識別子や設定対象の機器などの可変要素を外部に切り出す形でプログラムを記述し、運用中にパラメータを補足して実行するというものです。Telnet/SSH経由のコマンド実行をプログラムで制御する場合、ターミナルソフトウェアのスクリプト機能や開発用言語の対応ライブラリを利用することになります。

また、昨今のネットワーク機器では積極的なAPI対応が行われています。APIを活用すれば、処理結果の判断やデータの取り扱いが容易になるため、ネットワーク機器を操作するプログラムの堅牢性が向上します。本ケースの例として、VBAとREST APIを利用し、VLAN追加作業の自動化プログラムを作成しました。具体的なコードとして、VLAN IDを表示する処理部を図7に抜粋しました。参考として、この時のREST APIに関する機器側の設定情報は表3の様になります。

図7
図7:REST APIを利用したプログラムの抜粋:作成済VLAN ID表示部

表3:Nexus5600における設定の抜粋(REST API関連)

N5600#1 & N5600#2
feature nxapi
nxapi sandbox

まず、状態確認のために『最新の情報を取得』ボタンを押すと現在のVLAN情報が取得されました(図8)。

図8
図8:設定自動化プログラムの実行例(現在の状態情報取得)

次に、エクセル上のセルにVLAN IDを入力して『追加』ボタンを押すと、対象のVLANをVXLANファブリックに通すための設定が自動で行われました(図9)。この時、機器側のCLIから様子を観察すると、プログラム実行直後に設定変更のsyslogが出力され、その後に必要となる設定情報が反映されていることを確認できました。

図9
図9:設定自動化プログラムの実行例(設定の追加)

以下は、一連の操作を記録した動画となります。(クリックするとスタートします)
2016-09-30_0758_SDN_edited_caption+window
動画:設定自動化プログラムの実行例(全体)

上記の例ではホスト収容側のポートに対するVLANの追加・削除といった処理は考慮していませんが、これが可能になるまで作り込めば、「エクセル定義型ネットワーク」「Spreadsheet Defined Networking」などと呼べる位には活用できるものになるかもしれません。

当該プログラムを記述する際には、APIに関する機器固有の仕様を把握する必要があり、ネットワーク機器とコーディング双方のナレッジが要求されます。一方出来上がったプログラムを利用する分には、ネットワーク機器固有の文法などを意識する必要は無く、ネットワーク管理の専任外スタッフであっても操作は容易です。適切な管理の下に自動化プログラムへのアクセスを許可すれば、機器操作の固有性を隠蔽し公開対象を必要最低限に留めながら、設定変更の作業を移譲することも可能になります。

なお、オープン性の確保が特に必要とされる環境では、マネジメントプレーンにおいてもベンダーの固有性を排除したいという要件があるかもしれません。昨今各種コントロールプレーン / データプレーンに対するYANGの定義が盛んであり、各製品に設定用の共通データモデルと対応インタフェースが用意される様になれば、その範囲ではベンダーの固有性を意識せずに設定を行うことが可能になります。EVPNに関してもYANGの仕様は既にWG draftとして発行されており、具体的なパラメータの記載も進んでいます。今後EVPNの設定管理を、NETCONF / RESTCONFやgRPCなどを経由する形で、YANGに基づいて行うことが可能となればマネジメントプレーンに関してもオープン性を獲得できることが期待されます。

コントローラの活用

三点目は、コントローラ製品の利用です。これまでの手法と比較しライセンス費用などによってコストを要する傾向にありますが、Web等のUIを通じて、CLIを意識しない設定変更が可能となっています。また各製品では「VPNのトランスポートに必要となる初期設定の自動展開」「ネットワークに対する視認性の向上や健全性の確認」など、単純な設定追加に留まらない機能性が提供されます。加えてコントローラ自身が外部から操作するためのAPIに対応していれば、自動化プログラムとの親和性も期待できます。

本項で紹介する試験結果はCisco Systems社が提供するVTS (Virtual Topology System) を利用して実施したものです。まず、管理用のセグメントを経由して各機器と通信できることを確認した後、各機器へVTSの利用に必要となる機能をいくつか追加し、VTS上で各機器の登録作業を行いました。このVTSでは、機器の登録時にホスト収容側のインタフェースを含め、LLDP (Link Layer Discovery Protocol) 経由で何が接続されているかを認識し管理情報に反映することができます。

目的の設定変更を行う際には、GUIの案内に従って情報を入力し、ボタンを押すことによって必要な操作が完了します。図10は、追加対象のセグメントに対し関連付けるVLAN IDとホスト側のインタフェースを指定した時の、ブラウザ上の出力を抜粋したものです。

図10
図10:GUIの操作でVXLANのマッピング情報を指定(Cisco VTS GUI)

図10で示される様に、機器登録後の設定変更は、NX-OSのCLIを意識することなく操作が完了します。なお操作後、機器側では変更が設定情報に反映されます。図11は1台目の機器に着目しGUIでの操作前後における設定情報の差分を確認した結果となります。

図11
図11:バックグラウンドで追加された設定情報

また多くの製品では、仮想マシンのマネージャに対する操作やネットワーク情報を示すデータの受信をトリガとした、自動実行が可能となっています。ホスト側で形成されたネットワークを迅速に開通するためのコンポーネントが揃えられている点も、コントローラ製品を活用する利点と言えます。

おわりに

EVPNはBGP/MPLSベースのVPNであり、前提としてIP およびASの設計・設定が発生します。また、広大なテナント空間を提供可能な反面、VLANなどのEthernet Tagによるセグメント分離を、MPLS Label / PBB I-SID / NVO3 VNIに関連付ける作業が常に必要となります。

後者に対しては、例えば要件がシンプルなVLAN延伸であれば、そのルールに基づいて初期配置時に全てのマッピングを実施するなどの方策も選択肢の一つです。一方、セキュリティやスケーラビリティへの影響・利用者の要求に応じた接続性提供の要件などを想定すると、多くのケースでマッピング関係を動的に編集する仕組みが検討されることになると考えられます。

その際には様々な選択肢が存在するため、必要とされるスピード感・ネットワークの規模・蓄積されているナレッジと許容可能なギャップ・開発が可能な範囲・対象の設定以外に有用となる機能等の観点を踏まえて検討を行い、要件や環境に即した管理手法を選択することが効果的な運用の鍵となります。

まとめ

Cisco Systems社のNexus 5600におけるEVPN-VXLANを対象とし、運用中に延伸対象のセグメントを追加するシナリオに対して、以下の方法で実現を試みました。

・【XMPPの活用】:機器間で共有されるメッセージバスを用意する

・【ネットワーク機器におけるAPIの活用】:自動化プログラムを作成する

・【コントローラの活用】:提供されている管理製品を利用する

結果、上記いずれのパターンにおいても、複数のエッジ機器に対する設定変更が一箇所の操作で反映されることを確認できました。

EVPNでは、従来の技術と同様に、初期の構築時だけでなく運用においても設定作業の発生を考慮する必要があります。EVPNが実装された製品では、管理面においても新たな手法を選択できる傾向にあり、上手く活用することによって運用の効率を向上させることが可能になります。

関連記事

NETCONF / RESTCONF と YANG の標準化状況
https://www.youtube.com/watch?v=fb-uzQ2LJTk

執筆者プロフィール

平河内 竜樹
ネットワンシステムズ株式会社 ビジネス推進本部
応用技術部 エンタープライズSDNチーム
所属

ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事
・CCIE RS
・CCIE SP

イベント/レポート

pagetop