Flow Virtual Networkingでオーバーレイネットワークを作成してみる（NAT接続）【AOS 7.0 AHV 10.0／pc.2024.3】

※この記事は「AOS 7.0 AHV10.0 Prism Central pc.2024.3」時点の情報をもとに作成しています。その後の機能アップデートについてはメーカーの公開情報をご確認ください。

NutanixのFlow Virtual Networkingの連載については以下の記事にリンクをまとめています。ほかの記事にもこちらからアクセス可能です。

tomomartin.hateblo.jp

前回の記事では、FVNでVPC作成後のブリッジの設定を確認しました。今回は、オーバーレイネットワークを作成して、仮想マシンを接続してみます。

1.今回の環境

3ノードAHVクラスタ
AOS: 7.0.1
AHV: 10.0.1
Prism Central: pc.2024.3.1.1

環境は一般的なNutanixの3ノードクラスタです。Prism CentralはFVNで推奨となる3台構成としています。

▽Flow Virtual Networkingによる仮想プライベートクラウドのざっくりしたイメージ図は以下の通りです。クラスター上に独立した空間を作成して、そこにオーバーレイネットワークを作成する機能を指します。

▽今回の環境は以下の通りで、作成済みの「VPC」にオーバーレイネットワークを作成して、仮想マシンを接続してみます。

2. 「VPC」と「external subnet（NAT）」のおさらい

以前の記事で、「VPC」とそこから外部接続への出入口となる「external subnet」をNAT接続用として作成しました。

作成したVPCはこちら▽

VPC作成時に、外部接続の出入口としてAHVに作成しておいたNAT接続用の仮想ネットワーク（external subnet）を指定しました。▽以下のような設定です。

▽こちらを絵で表現すると以下のようになります。前回の記事で、「br0ブリッジ」と「brAtlasブリッジ」間にパッチポート（peer）が作成されることを確認しましたが、ここがVPCからexternal subnetを経て、外部への通信経路（ローカルネット）になります。

AHV03には、パッチポート（peer）と通信経路がないように見えますが、これは通常の動作であり、パッチポートはNAT接続にするか、NATなし接続にするかで、数が決まっていたり、台数を変更できたりするようです。

以下ドキュメントの「NAT Gateway」のあたりに、NATの場合は1ホストのみがゲートウェイとして機能する旨の記載がありますが、VPCを作成すると2つのホストにパッチポート（peer）が作成されたので、実際のところは通信をキャプチャして確認するしかなさそうですね。

Essential Concepts
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Flow-Virtual-Networking-Guide-vpc_2024_2:ear-flow-nw-vpc-concepts-pc-c.html

VPCを作成した時点で、パッチポート（peer）はデフォルトで2つ作成されるのかもしれません。なお、ブリッジ間で作成されたパッチポート（peer）の様子は、▽前回の記事で紹介しています。

3. オーバーレイネットワークの作成

ここからは、VPCにオーバーレイネットワークとなるサブネットを作成してみます。▽作成したVPCの画面で、「Create Subnet」をクリックします。

▽オーバーレイサブネットの情報を入力します。なお、オーバーレイタイプのサブネットでは、「IPAM」によるIPアドレスの自動割り当てが必須となります。作成するネットワーク内で自動割り当てのIPプールも設定します。

DNSは、このネットワークに接続した仮想マシンに割り当てられるDNSのIPですが、今回はインターネット上で名前解決ができるようにしておきます。入力できたら「Create」をクリックします。

▽作成されたオーバーレイサブネットは以下の通りです。

▽「Route」にも、情報が追加されています。

▽ここまでのイメージは以下の通りです。

4. 仮想マシンを接続

今回は、Windows 2022のVMを2台作成し、それぞれAHV01とAHV02に配置してオーバーレイサブネットに接続してみます。

▽以下2台のVMを使用します。

Prism Centralから、仮想マシンの設定画面を起動し、作成したオ－バーレイサブネットを接続して保存します。なお、オーバーレイサブネットの割り当ては、Prism Centralからの操作が必須です。

▽オーバーレイサブネット内のIPアドレスが割り当てられました。また、AHV01とAHV02で起動していることも確認できます。

▽作成したVM間で疎通確認もできました。

これで、今回の設定は完了です。▽作成したイメージは以下の通りです。

※ただし、このVM同士の疎通はパッチポートを経由しているわけではないです。詳しくは次回の記事で紹介します。

なお、AHV01で起動している仮想マシンが「brAtlasブリッジ」に接続されている様子も確認しておきます。

仮想マシンのvNICのインターフェースは、AHVから「tap」という名前で確認ができます。▽AHV01でコマンドで確認してみると、「tap2」というインターフェースが作成されていることが確認できます。（以下、不要な行は削除）

[root@ahv-01 ~]# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.22.1.61 netmask 255.255.255.0 broadcast 172.22.1.255
ether 00:62:0b:20:ef:00 txqueuelen 1000 (Ethernet)
RX packets 80726921 bytes 16303464490 (15.1 GiB)
RX errors 0 dropped 2121506 overruns 0 frame 0
TX packets 20411985 bytes 13478583384 (12.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

～～～～中略～～～～
tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
ether fe:6b:8d:45:5a:21 txqueuelen 1000 (Ethernet)
RX packets 512401 bytes 40090347 (38.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 688378 bytes 1004731653 (958.1 MiB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0

▽Prism Centralから対象の仮想マシンのNICを確認してみると、この「tap2」のMACアドレスだと考えられます。

PrismやaCLIからはNutanixのOUIである「50-6b-8d」が確認できるのですが、AHVのOVSからみると、OUIの第1オクテットだけ微妙に変更されて「fe-6b-8d」となっていますね。OVSのインターフェースとして作成する際に、何か内部的な仕様があるのかもしれません。

さらに、AHV01のOVSで確認すると、この「tap2」はFVNのVPCで使用される「brAtlasブリッジ」にポート（インターフェース）として作成されていることが分かります。

[root@ahv-01 ~]# ovs-vsctl show | grep -A 20 "Bridge brAtlas"
Bridge brAtlas
Controller "pssl:"
fail_mode: secure
datapath_type: system
Port ovn-daf4b9-0
Interface ovn-daf4b9-0
type: geneve
options: {csum="true", key=flow, remote_ip="172.22.1.63"}
Port patch-brAtlas-to-localnet_5fa630ca-b639-44d8-8335-f2febf653966
Interface patch-brAtlas-to-localnet_5fa630ca-b639-44d8-8335-f2febf653966
type: patch
options: {peer=patch-localnet_5fa630ca-b639-44d8-8335-f2febf653966-to-brAtlas}
Port brAtlas
Interface brAtlas
type: internal
Port ovn-ba3356-0
Interface ovn-ba3356-0
type: geneve
options: {csum="true", key=flow, remote_ip="172.22.1.62"}
Port tap2
Interface tap2

インターフェースを確認するコマンドでも、同様に「tap2」がofports=4で作成されていることが確認できました。

[root@ahv-01 ~]# ovs-vsctl list interface | grep -C5 tap2
lldp : {}
mac :
mac_in_use : "fe:6b:8d:45:5a:21"
mtu : 9000
mtu_request :
name : tap2
ofport : 4
ofport_request : []
options : {}
other_config : {}
statistics : {collisions=0, rx_bytes=40097764, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_missed_errors=0, rx_multicast_packets=0, rx_over_err=0, rx_packets=512445, tx_bytes=1004745118, tx_dropped=1, tx_errors=0, tx_packets=688423}