NutaNice Xperience

主にNutanix製品を検証したり触ったりした結果をつづっています。※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。実際に製品を使用される場合は、メーカードキュメントの手順に従い実施してください。

【AOS 7.0】Nutanix AHVの仮想スイッチを確認⑥ br0ブリッジで通信が処理される仕組み

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

この記事は、AHVにおけるOVSのブリッジチェーンの中身を確認する連載シリーズです。各記事には以下のリンクからアクセスできます。

 

前回の記事では、Nutanix AHVの仮想スイッチを構成するOVSで、br0ブリッジのOpenFlowルールについて確認しました。今回は、ブリッジ内で通信が処理される仕組みを確認してみます。

目次

1.今回の環境

3ノードAHVクラスタ
AOS: 7.0.1
AHV: 10.0.1
Prism Central: pc.2024.3.1.1
test-VMWindows Server 2022

環境は以下のイメージで、一般的なNutanixの3ノードクラスタです。

2. br0ブリッジでの通信処理の仕組み

今回は、例としてノード内のPrism CentralとCVM、および別ノードのCVMとの管理系通信を例にOVSでのFlowルールの処理を見てみます。イメージ図は、以下の通りです。

br0では、OVSの「Flowテーブル」とブリッジの「MACアドレステーブル(FDB)」が使用されていますが、それぞれの解説については以下の記事をご参照ください。

今回の環境のテーブル情報は以下の通りです。

▽「br0」のMACアドレステーブル

▽「br0」のFlowテーブル

Prism Central→CVM宛の通信

Prism Centralからの通信は「br0.u」ポートから受信します。仮にPrism Centralが宛先CVMのMACアドレスを知らない場合は、ARPリクエストでブロードキャストしますので、「br0.uポートから受信」したのち、Flowテーブルの行番号では「2」→「11」という処理になります。

Prism CentralがCVMのMACアドレスを学習している状態であれば、「br0.uポートから受信」したのち、Flowテーブルの行番号「2」→「14」の[NOMAL]処理となり、br0のL2でMACアドレステーブルを参照します。ローカルのCVM宛であればofport:5番「vnet0」、リモートのCVM宛であればofport:10番の「eth1」に転送されるというわけです。

リモートのCVM→Prism Central宛の通信

こちらも、同様でリモートのCVMが物理ネットワークを経由してローカルのPrism Central宛の通信を流した場合は、「eth1」から受信してFlowルールで処理され、NOMALの動作となるMACアドレステーブルを参照してPrism Centralがいる「br0.u」ポートにパケットを転送します。

おわりに

今回は、AHV環境のOVSブリッジで通信が処理される仕組みを紹介しました。Prism Centralが接続されているブリッジ「br0.local」と「br0」間の通信制御が気になる方もいらっしゃるかと思いますが、次回の記事で確認したいと思います。