Neutron DVR環境でのパケット処理を探る
第3回では、DVR環境でのパケット処理を解析してみます。少しだけ難しいですが、興味深い挙動がわかるので、最後までおつきあいください。
解析のためのコマンド
第2回で構築した手順では、NeutronのML2 pluginとしてOVS（Open vSwitch）を選択しています。この場合、仮想ルータの実態はNamespace（Linux Namespace）、iptables、OVSの組み合わせで構成されています。これを前提に、今回の解析で使うコマンドを以下に示します。なお出力結果は大量となるので、必要な箇所以外は適宜省略しています。
インタフェース、ブリッジ名確認
# ip addr
パケットキャプチャ方法
# tcpdump -i <インタフェース名> -n
OVSの構成確認
# ovs-vsctl show
ルーティング情報確認
# ip rule ls # ip route show table <テーブル名>
OVSのフローテーブル確認
# ovs-ofctl dump-flows <ブリッジ名>
Namespace確認
# ip netns
Namespace内でのコマンド実行
# ip netns exec <Namespace> <コマンド>
ネットワークの状態を把握する
パケット処理解析の前に、現在のOpenStack内部のネットワークがどのようになっているかを把握します。各テナントで、それぞれインスタンス（VM）を起動します。ネットワークトポロジー上では図1のようになっています。
図1：ネットワークトポロジー
最初にインタフェースやブリッジ等のネットワーク周りの状態を確認します。まずは、Controller + Network Serverの状態を確認します。
インタフェース名、ブリッジ名は、以下の手順で確認します。
インタフェース、ブリッジ名確認
# ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.10.101/24 brd 192.168.10.255 scope global eth1
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.20.101/24 brd 192.168.20.255 scope global eth2
6: ovs-system: <BROADCAST,MULTICAST>
7: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP>
8: br-int: <BROADCAST,MULTICAST>
10: br-tun: <BROADCAST,MULTICAST>
次にNamespaceと、Namespace内のインタフェースを確認します。
Namespace確認
# ip netns snat-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f
SNAT用Namespace内のインタフェース確認
# ip netns exec snat-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip addr
11: qg-e74ea6e5-c8: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 10.0.0.10/24 brd 10.0.0.255 scope global qg-e74ea6e5-c8
13: sg-cab3bcca-30: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.210.10/24 brd 192.168.210.255 scope global sg-cab3bcca-30
15: sg-7d59c9a4-4d: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.220.10/24 brd 192.168.220.255 scope global sg-7d59c9a4-4d
仮想ルータ用Namespace内のインタフェース確認
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip addr
12: qr-bdc3d5ac-e6: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.210.1/24 brd 192.168.210.255 scope global qr-bdc3d5ac-e6
14: qr-84e871c6-a4: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.220.1/24 brd 192.168.220.255 scope global qr-84e871c6-a4
続いて、OVSの構成確認をします。
# ovs-vsctl show
Bridge br-tun
Port "gre-c0a81466"
options: {(略) remote_ip="192.168.20.102"}
Port patch-int
options: {peer=patch-tun}
Port br-tun
Port "gre-c0a81467"
options: {(略) remote_ip="192.168.20.103"}
Bridge br-ex
Port "qg-e74ea6e5-c8"
Port phy-br-ex
Port "eth0"
Port br-ex
Bridge br-int
Port "qr-bdc3d5ac-e6"
Port "sg-7d59c9a4-4d"
Port int-br-ex
Port br-int
Port patch-tun
options: {peer=patch-int}
Port "sg-cab3bcca-30"
Port "qr-84e871c6-a4"
以上の結果から判明したインタフェース、ブリッジ、IPアドレスを関連付けて図示すると、図2のようになります。
図2：Controller + Network Serverの状態
同様に、Compute Server1、2も調査します。今回の検証環境では、図3のようになっていることを確認しました（図が複雑なので、Management Network用のeth1は省略しています）。注目していただきたいのは、仮想ルータ用Namespaceをすべてのノードが同じ名前、同じインタフェース、同じIPアドレスで有している点です（図3の赤い点線部分）。
図3：全体の状態
これで、現在の状態がわかりました。それでは、実際にパケット処理を解析します。「別テナント上のインスタンス向けパケット」、「FIP（Floating IP）なしでのPublic Network向けパケット」、「FIPありでのPublic Network向けパケット」の順で解析していきます。
別テナント（セグメント）上のインスタンス向けパケット処理
非DVR環境では、別テナント向けの通信も、Network Server上の仮想ルータを経由していました。では、DVR環境下ではどうなっているのでしょうか。
Compute Server1上のインスタンスtest220-1（IPアドレス192.168.220.11、DFG 192.168.220.1）から、Compute Server2上のインスタンスtest210-1（IPアドレス192.168.210.14、DFG 192.168.210.1）へpingを実行します。パケット処理の大まかなあたりをつけるため、各サーバのTenant Networkのインタフェースでパケットをキャプチャします。
Controller + Networkのeth2でのパケットキャプチャ
# tcpdump -i eth2 -n （出力なし）
Compute1のeth2でのパケットキャプチャ
# tcpdump -i eth2 -n IP 192.168.20.102 > 192.168.20.103: GREv0, key=0xb, length 106: IP 192.168.220.11 > 192.168.210.14: ICMP echo request, id 15364, seq 1, length 64 IP 192.168.20.103 > 192.168.20.102: GREv0, key=0xc, length 106: IP 192.168.210.14 > 192.168.220.11: ICMP echo reply, id 15364, seq 1, length 64
Compute2でのeth2でのパケットキャプチャ
# tcpdump -i eth2 -n IP 192.168.20.102 > 192.168.20.103: GREv0, key=0xb, length 106: IP 192.168.220.11 > 192.168.210.14: ICMP echo request, id 15364, seq 1, length 64 IP 192.168.20.103 > 192.168.20.102: GREv0, key=0xc, length 106: IP 192.168.210.14 > 192.168.220.11: ICMP echo reply, id 15364, seq 1, length 64
Controller + Network Serverでは処理が行われず、Compute Server1、2だけで完結しています。Compute Server1、2は、それぞれ一つずつ仮想ルータを有しており、両テナント用のインタフェースを有しています。どの仮想ルータのインタフェースで処理されているかを確認するため、今度は仮想ルータ用Namespace内でパケットキャプチャをします。
Compute Server1の仮想ルータ用Namespace内で、送信側インタフェース（192.168.220.1）でのパケットキャプチャ
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i qr-84e871c6-a4 -n IP 192.168.220.11 > 192.168.210.14: ICMP echo request, id 19204, seq 1, length 64
Compute Server1の仮想ルータ用Namespace内で、受信側インタフェース（192.168.210.1）でのパケットキャプチャ
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i qr-bdc3d5ac-e6 -n IP 192.168.220.11 > 192.168.210.14: ICMP echo request, id 19204, seq 1, length 64
Compute Server2の仮想ルータ用Namespace内で、送信側インタフェース（192.168.220.1）でのパケットキャプチャ
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i qr-84e871c6-a4 -n IP 192.168.210.14 > 192.168.220.11: ICMP echo reply, id 19204, seq 1, length 64
Compute Server2の仮想ルータ用Namespace内で、受信側インタフェース（192.168.210.1）でのパケットキャプチャ
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i qr-bdc3d5ac-e6 -n IP 192.168.210.14 > 192.168.220.11: ICMP echo reply, id 19204, seq 1, length 64
ICMP echo requestはCompute Server1だけで、replyはCompute Server2だけで処理されていることがわかります。これを図示すると、図4のようになります。
図4：別テナント上のインスタンス向け通信
このようにDVR環境下では、別テナント上のインスタンス向け通信は、それぞれのインスタンスが動作しているCompute Server上の仮想ルータのみで処理されていることがわかります。
