NutaNice Xperience

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

【AOS 7.0】Nutanix AHVの仮想スイッチを確認⑤ Flowテーブルの確認

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

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

 

前回の記事では、Nutanix AHVの仮想スイッチを構成するOVSで、br0ブリッジのMACアドレステーブルを確認しました。今回は、OVSでのネットワーク制御の仕組みである、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. Flowテーブルについて

OVSでは、パケット処理のルールを定義した「Flowテーブル」というエントリを作成することが可能です。このFlowテーブルに定義された条件に従って、ブリッジ内に入ってきた通信が処理されます。

Flowテーブルを確認するコマンドは、AHVから実行できます。

ovs-ofctl dump-flows <ブリッジ名>

今回の環境で、br0ブリッジに定義されているFlowテーブルは以下の通りです。

[root@ahv-01 ~]# ovs-ofctl dump-flows br0
 cookie=0x0, duration=515487.871s, table=0, n_packets=0, n_bytes=0, priority=42,dl_type=0x9000 actions=drop
 cookie=0x0, duration=515487.872s, table=0, n_packets=189454864, n_bytes=95981606492, priority=41,in_port="br0.u" actions=resubmit(,3)
 cookie=0x0, duration=515480.923s, table=0, n_packets=8494256, n_bytes=721149369, priority=41,in_port=eth0,dl_dst=ff:ff:ff:ff:ff:ff actions=resubmit(,10)
 cookie=0x0, duration=515480.923s, table=0, n_packets=8459479, n_bytes=718932506, priority=41,in_port=eth1,dl_dst=ff:ff:ff:ff:ff:ff actions=resubmit(,10)
 cookie=0x0, duration=515480.923s, table=0, n_packets=0, n_bytes=0, priority=41,icmp,in_port=eth0,dl_dst=02:62:0b:20:ef:xx,nw_src=169.254.2.3,nw_dst=169.254.2.4 actions=resubmit(,10)
 cookie=0x0, duration=515480.922s, table=0, n_packets=0, n_bytes=0, priority=41,icmp,in_port=eth1,dl_dst=02:62:0b:20:ef:xx,nw_src=169.254.2.3,nw_dst=169.254.2.4 actions=resubmit(,10)
 cookie=0x0, duration=515487.872s, table=0, n_packets=1258654900, n_bytes=1526241807488, priority=40 actions=resubmit(,3)
 cookie=0x0, duration=501388.497s, table=3, n_packets=17, n_bytes=5842, priority=2,pkt_mark=0x300,udp,in_port="br0.u",vlan_tci=0x089d/0x0fff,dl_dst=ff:ff:ff:ff:ff:ff,tp_dst=67 actions=output:"br0-dhcp"
 cookie=0x0, duration=501388.497s, table=3, n_packets=2, n_bytes=704, priority=2,udp,in_port="br0-dhcp",vlan_tci=0x089d/0x0fff,dl_dst=50:6b:8d:c3:d5:xx,tp_dst=68 actions=output:"br0.u"
 cookie=0x0, duration=501388.496s, table=3, n_packets=2, n_bytes=92, priority=2,arp,in_port="br0-dhcp",vlan_tci=0x089d/0x0fff,dl_src=50:6b:8d:c3:d5:xx,dl_dst=ff:ff:ff:ff:ff:ff actions=FLOOD
 cookie=0x0, duration=515487.871s, table=3, n_packets=47322, n_bytes=1987524, priority=1,arp,in_port="br0.u" actions=NORMAL,output:"br0-arp"
 cookie=0x0, duration=515487.871s, table=3, n_packets=0, n_bytes=0, priority=1,udp,in_port="br0.u",tp_dst=67 actions=NORMAL,output:"br0-arp"
 cookie=0x0, duration=515487.871s, table=3, n_packets=1238, n_bytes=428598, priority=1,udp,tp_dst=68 actions=NORMAL,output:"br0-arp"
 cookie=0x0, duration=515487.872s, table=3, n_packets=1465015210, n_bytes=1623661096343, priority=0 actions=NORMAL
 cookie=0x0, duration=515480.923s, table=10, n_packets=16953735, n_bytes=1440081875, priority=100 actions=learn(table=11,hard_timeout=1800,priority=100,delete_learned,NXM_OF_IN_PORT[],NXM_OF_VLAN_TCI[0..11]),resubmit(,3)
 cookie=0x0, duration=515480.579s, table=11, n_packets=0, n_bytes=0, hard_timeout=1800, priority=100,in_port=eth0,vlan_tci=0x0961/0x0fff actions=drop
 cookie=0x0, duration=515480.579s, table=11, n_packets=0, n_bytes=0, hard_timeout=1800, priority=100,in_port=eth1,vlan_tci=0x0961/0x0fff actions=drop
~~以降省略~~

実行結果からわかるように、各エントリの行にはテーブル番号が設定されており、パケットはテーブル番号の順に処理されます(同じテーブル番号であれば優先度の値が大きい順に)。このエントリをわかりやすく表現すると、以下の表のようになります。コマンドの実行結果と照らし合わせてみてください。

このように、Flowテーブルでは受信ポートや送信ポート、パケットの種類など、様々な条件が定義されており、ブリッジを流れる通信を制御する仕組みとなっています。

これらのエントリの中でポイントとなるのは「action=NOMAL」という項目です。これは、「通常のL2スイッチの動作で処理する」という意味で、OVSのブリッジの「MACアドレステーブル(FDB)」を参照して通信が処理されることになります。

OVSのブリッジのMACアドレステーブルについては、以下の記事で紹介していますので、併せてご参照ください。

今回は、AHV環境でのOVSブリッジ「br0」のFlowテーブルを確認してみました。次回は、特定の仮想マシンからのパケットなどを例にして、ブリッジを流れる通信を紹介したいと思います。