まず、VXLANでのトンネルの張り方を説明する。例えば図1のように、VXLAN ID 10001が239.1.1.1のマルチキャストアドレスにひも付いている場合、VXLAN ID 10001に所属している仮想マシンが起動すると、VTEP（VXLAN Tunnel End Point：VXLAN終端ポイント）から、239.1.1.1のIGMP reportが送出される。VMwareの場合、VTEPはVMkernel（ハイパーバイザー）になる。

図1 VXLANの概要

　このとき、上位のスイッチでIGMP snoopingがdisable（無効）だとVXLANのパケットがフラッディングされてしまうため、IGMP snoopingをenable（有効）にする必要がある。

　起動した仮想マシンが通信を開始したとき、送信元の仮想マシンが配置されているハイパーバイザーの仮想スイッチでは、どのホストのハイパーバイザーに配置された仮想スイッチとトンネルを張る必要があるのか把握することができない。

　現在リリースされているVXLANでは、通信を行うべき対象を見つけるためにマルチキャストを使用しており、VXLAN IDとマルチキャストアドレスがひも付いている。1つのマルチキャストアドレスに複数のVXLAN IDを所属させることも可能だが、ホストは不必要なマルチキャストパケットを受信する環境となるため、1対1で割り当てる設計が望ましい。また、これによりVXLANのトラブルシューティングも容易となる。

マルチキャストの使われ方

　マルチキャストが使われるのは、対向のVTEPを探すときのみであり、その後はユニキャストの通信になる。

　まず、VXLAN ID 10001の仮想マシンがARPリクエストを送出すると、ARPリクエストをVXLANでカプセル化したマルチキャストパケットが、VTEPから送出され、VXLAN ID 10001を保持する全てのホストに届く。このパケットを受け取ったホストは、VTEPでVXLANのカプセル化を解き、ARPリクエストを仮想マシンに送信する。仮想マシンは、自分宛てのARPリクエストであればARPリプライを送信し、違う場合は破棄する。

　次に、VTEPからARPリプライをVXLANでカプセル化したユニキャストパケットを送信する。VXLANヘッダのカプセル化とカプセル化解除は、VTEPで行われるため、仮想マシン自体はVXLANを認識する必要はない。VTEPからVXLANでカプセル化したarpリプライを送出するとき、送信元IPアドレスは、自身のVMkernelのIPアドレスとなり、宛先IPアドレスは、ARPリクエストを送信した VTEPのIPアドレスになる。

　このように、VXLANではマルチキャストの機能を使ってARP解決を行うため、マルチキャストルーティングを使ったネットワークを構築する必要がある。つまりデータセンター全体でVXLANを使用する場合、データセンターネットワーク全域で、マルチキャストの設計・構築が必要になる。特に、データセンター間通信で WANを越える場合には、さらに複雑な環境となるため、設計に十分な注意が必要となる。

VXLANのフレームフォーマット

　次にVXLANのフレームフォーマットについて、各ヘッダの内容を踏まえながら説明する。

図2　VXLANのフレームフォーマット《クリックで拡大》

Dest MAC (宛先MACアドレス）とDest IP（宛先IPアドレス）

　先に説明した通り、通信相手の仮想マシンが接続されているホストのVTEPを探すときにはマルチキャストが使用されるため、通常のマルチキャスト通信と同様、Dest MAC（宛先MACアドレス）は 01-00-5e-xx-xx-xx になり、Dest IP（宛先IPアドレス）はマルチキャストアドレスになる。

　例えば、VXLAN ID 10001が 239.1.1.1 にひも付いている場合、Dest MACは01-00-5e-01-01-01になり、Dest IPは 239.1.1.1 になる。その後、同セグメントのときの Dest MACは対向のVMkernelのアドレスになり、Dest IPも対向のVMkernelのアドレスになる。

　マルチキャストルーティングをするときのDest MACは、レイヤー3デバイスのアドレスになる。

IEEE 802.1Q（オプショナル）

　IEEE 802.1Qはオプショナルではあるが、VXLANの通信を管理用の通信などと分離するために使うことがある。

図3 VMkernelのVLAN

　IEEE 802.1Qを使う場合、VXLANで使われるVMkernelが設定されているポートグループのVLAN IDが入る。つまり、VXLANに必要なVLANは、VXLANで使われるVMkernelのVLANだけということだ。この点は、従来の環境と比べて大きな利点となる。

　従来は、仮想化環境に接続されていた物理ネットワークでは、仮想化環境側でVLANを追加した際に、物理ネットワーク側でVLANの追加作業が発生した。物理ネットワーク側にVLANを追加するためには多くの場合で時間を要するため、ソフトウェア側の担当者には不満があった。また、ネットワーク全体でVLANの追加作業が必要になることから、1台のスイッチでVLANの追加漏れがあると、ネットワーク全体に影響を与えることにもなる。

　これらのことを踏まえて、仮想化環境に接続されている物理スイッチには、事前に全てのVLANに対して通信許可の設定を行う場合がある。全てのVLANに対して事前に通信許可設定を行えば、運用上は楽になる。しかし、一部のベンダーのスイッチでは、スイッチで処理できるVLAN数の合計（1000個のVLANを20ポートでトランクした場合、合計2万になる）に制限があり、全てのVLANをトランクすると、すぐにこの制限に達してしまう。

　この課題に対してVXLANでは、必要なVLANは1つであるため、VLAN数の合計を意識する必要はなくなっている。さらに、物理ネットワーク側がマルチキャストルーティングに対応していれば、VXLAN IDを追加したときに、物理ネットワーク側で設定変更の必要がないため、新たに追加したVXLAN IDの仮想マシンはすぐに通信が可能になり、ソフトウェア担当者の不満もなくなる。

Source MAC（送信元MACアドレス）とSource IP（送信元IPアドレス）

　Source MACとSource IPには、VTEP（VMkernel）のアドレスが入る。上位のスイッチは、仮想マシンごとのMACアドレスを学習するのではなく、VTEP（VMkernel）のMACアドレスだけを学習することになり、ネットワーク全体で学習するMACアドレスの数を削減できる。

UDPヘッダ

　VXLANにはUDPヘッダがあるため、CiscoのFabricPathやBrocade NetworksのVCSなどのファブリック・ネットワーク環境において、VXLANでカプセル化されたフレームの負荷分散が可能になる。これによって、ネットワーク全体を効率的に使用できるようになり、一部の経路が輻輳（ふくそう）する可能性も低くなる。

VXLANヘッダ

　VXLANヘッダには、VNI（VXLAN Network Identifier）フィールドがある。VNIは 24ビットあるため、論理的には最大約1677万のIDが作成可能だ。現在問題になっている VLAN ID不足を解消できる。一方、VLAN IDは12ビットのため、最大4096までしか作成できない。実際には予約されている VLAN IDもあるため、使えるVLAN IDはさらに少なくなってしまっている。

VXLANフレーム全体

　VXLANのフレームフォーマットを見ると分かるように、ジャンボフレームとなっている。ジャンボフレームに対応する手法として、パケットを送出する際にデータ部分を小さくする方法もあるが、パフォーマンスが犠牲となってしまう。そのため、現実的には物理ネットワークをジャンボフレーム対応にする検討が必要である。

　ただし、ジャンボフレームがWANを越える際にはフラグメントが必要となることから、ルータの性能によってはパフォーマンスが問題になる可能性がある。

Original Ethernet Payload

　VXLANのドラフトでは、内部のVLANタグは破棄すべきと記載されている。

これからのVXLAN普及に向けた課題

　まず、VXLANゲートウェイ機能への対応が挙げられる。VXLANの通信を行うためには、VTEPが必要となり、このVTEPは仮想化環境上のVMkernelで構成される。つまり、多くの場合、VXLANの通信は仮想化環境間での通信となる。では、VXLANを用いた仮想化されていない物理サーバとの通信は、どのように実施できるのか。

　物理サーバはVXLAN ではなくVLANで接続されているため、VXLANをVLANに変換するVXLANゲートウェイ機能が必要になる。VXLANゲートウェイに関しては、一部ベンダーのハードウェアスイッチや、ソフトウェアでの対応が始まっている。今後も対応製品が増えていくと思われる。

　次に、VXLANと同様のオーバレイテクノロジーである STT（Stateless Transport Tunneling）とのパフォーマンス比較も普及への課題として挙げられる。STTはVXLANよりパフォーマンスが優れている、という意見があるからだ。この意見の根拠は、STTはTCPの通信として見せかける仕組みを保持しており、サーバに搭載されたNICにTSO（TCP Segmentation Offload）機能が搭載されている場合、STTの通信をNICの機能によりオフロードし、パフォーマンスを向上できるという点だ。

　しかし、VXLANでもサーバに搭載されたNICへのオフロードの仕組みが検討されており、最終的にはどちらの方式のパフォーマンスが優れているかは、実際に検証をして確認する必要がある。

　最後に、これまで説明してきたように、VXLANを使用するためには、マルチキャストルーティングが必要になってしまう点も課題だ。これを克服するために、ユニキャストバージョンのVXLANもリリースされた。

このように、幾つかの設計上の課題や注意点は存在するものの、複数のベンダーでのサポート等にも後押しされ、今後浸透していくテクノロジーがVXLANであると考えている。

　次回は、Cisco Nexus 1000Vでサポートされたユニキャストバージョンの VXLANの動作と、VMware vCloud Directorのネットワークの今後の展開について説明する。