Neutron DVR環境でのパケット処理を探る

ネットワーク

技術解説

連載 :

OpenStack（RHEL-OSP6）で試す分散仮想ルータ

2015年6月17日(水)

工藤雄大

FIPなしでのPublic Network向けパケット処理

続いて、Public Network向けのパケット処理です。DVR環境では、FIP割り当ての有無によって処理が異なります。まず、FIP割り当てなしの状態でのパケット処理解析をします。

Compute Server1上のインスタンスtest220-1（IPアドレス192.168.220.11、DFG 192.168.220.1）から、Public Network上のIPアドレス10.0.0.1へpingを実行します。先ほどと同様に、パケット処理の大まかなあたりをつけるため、各サーバのTenant Networkのインタフェースでパケットをキャプチャします。

Controller + Networkのeth2でのパケットキャプチャ

# tcpdump -i eth2 -n
IP 192.168.20.102 > 192.168.20.101: GREv0, key=0xc, length 106: IP 192.168.220.11 > 10.0.0.1: ICMP echo request, id 1796, seq 1, length 64
IP 192.168.20.101 > 192.168.20.102: GREv0, key=0xc, length 106: IP 10.0.0.1 > 192.168.220.11: ICMP echo reply, id 1796, seq 1, length 64

Compute1のeth2でのパケットキャプチャ

# tcpdump -i eth2 -n
IP 192.168.20.102 > 192.168.20.101: GREv0, key=0xc, length 106: IP 192.168.220.11 > 10.0.0.1: ICMP echo request, id 1796, seq 1, length 64
IP 192.168.20.101 > 192.168.20.102: GREv0, key=0xc, length 106: IP 10.0.0.1 > 192.168.220.11: ICMP echo reply, id 1796, seq 1, length 64

Compute2でのeth2でのパケットキャプチャ

# tcpdump -i eth2 -n
（出力なし）

Compute Server1上のインスタンス test220-1から出たパケットは、Controller + Network Serverへ転送されていることがわかります。では、どの仮想ルータが処理を行っているのでしょうか。それを探るため、さらに各仮想ルータ用Namespace内でパケットキャプチャをします。

Controller + NetworkのSNAT用仮想ルータ用Namespace内で、Tenant用インタフェース（192.168.220.10）でのパケットキャプチャ

# ip netns exec snat-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i sg-7d59c9a4-4d -n
IP 192.168.220.11 > 10.0.0.1: ICMP echo request, id 33028, seq 1, length 64
IP 10.0.0.1 > 192.168.220.11: ICMP echo reply, id 33028, seq 1, length 64

Controller + NetworkのSNAT用仮想ルータ用Namespace内で、Public用インタフェース（10.0.0.10）でのパケットキャプチャ

# ip netns exec snat-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i qg-e74ea6e5-c8 -n
IP 10.0.0.10 > 10.0.0.1: ICMP echo request, id 33028, seq 1, length 64
IP 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 33028, seq 1, length 64

Controller + Networkの仮想ルータ用Namespace内での、全インタフェースパケットキャプチャ

# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i any -n
（出力なし）

Compute Server1の仮想ルータ用Namespace内でのパケットキャプチャ

# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f tcpdump -i qr-84e871c6-a4 -n
IP 192.168.220.11 > 10.0.0.1: ICMP echo request, id 33028, seq 1, length 64
IP 192.168.220.11 > 10.0.0.1: ICMP echo request, id 33028, seq 1, length 64

SNAT用仮想ルータが、インスタンスからPublic Networkへ向けたパケットの処理をしていることがわかります。

ここで疑問が出てきます。インスタンスtest220-1のDFGは、192.168.220.1です。特段にスタティックルートは入っていません。ではなぜ、192.168.220.10が割り当てられているSNAT用仮想ルータが処理できるのでしょうか。

その理由は、Compute Server1の仮想ルータ用Namespace内のルーティング情報にあります。

Compute Server1の仮想ルータ用Namespaceのルーティング情報

# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip rule ls
3232291841:     from 192.168.220.1/24 lookup 3232291841
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip route show table 3232291841
default via 192.168.220.10 dev qr-84e871c6-a4

Compute Server1の仮想ルータに、192.168.220.1/24のセグメントから来たパケットは、192.168.220.10へ転送する設定が入っていました。

つまり、パケットは図5のように処理されています。

図5：FIPなしでのPublic Network向け通信

FIPありでのPublic Network向けパケット処理

最後に、DVR環境下、FIP割り当てありの状態でのパケット処理を解析します。

Compute Server1上のインスタンスtest220-1（IPアドレス192.168.220.11、DFG 192.168.220.1）にFIP 10.0.0.11を割り当てます。そして、インスタンスtest220-1からPublic Network上のIPアドレス10.0.0.1へpingを実行します。先ほどと同様に、パケット処理の大まかなあたりをつけるため、各サーバのTenant Networkのインタフェースでパケットキャプチャをします。

28Controller + Networkのeth2でのパケットキャプチャ

# tcpdump -i eth2 -n
（出力なし）

Compute1のeth2でのパケットキャプチャ

# tcpdump -i eth2 -n
（出力なし）

Compute2でのeth2でのパケットキャプチャ

# tcpdump -i eth2 -n
（出力なし）

すべてのServerで、パケットは何もキャプチャされませんでした。つまりこのパケットは、Tenant Networkを流れていないということになります。

Tenant Networkにパケットが届いていないのであれば、Public Networkで処理されていると予想できます。そこで、Public Network用のインタフェースでパケットキャプチャをします。

Controller + Networkのeth0でのパケットキャプチャ

# tcpdump -i eth2 -n
（出力なし）

Compute1のeth0でのパケットキャプチャ

# tcpdump -i eth2 -n
IP 10.0.0.11 > 10.0.0.1: ICMP echo request, id 38660, seq 1, length 64
IP 10.0.0.1 > 10.0.0.11: ICMP echo reply, id 38660, seq 1, length 64

Compute2でのeth0でのパケットキャプチャ

# tcpdump -i eth2 -n
（出力なし）

すると、インスタンス test220-1が動作しているCompute Server1のPublic Networkからパケットが出ていることがわかりました。Compute Server1の仮想ルータ用Namespace内でさらにパケットキャプチャを試みようとしたところ、Compute Server1に、FIP割り当てなしの時には存在しなかったFIP処理用のNamespaceが出てきました。また、仮想ルータ用Namespaceにも新しいインタフェースが追加されています。FIP割り当てにより、OpenStack内部のネットワーク状態が変化したようなので、あらためて状態を把握してみます。

Compute Server1での、Namespace確認

# ip netns
fip-b79fc52b-76dc-4a75-806f-ab1401b6786d
qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f

Compute Server1での、FIP用Namespace内のインタフェース確認

# ip netns exec fip-b79fc52b-76dc-4a75-806f-ab1401b6786d ip a
2: fpr-dc03bb5f-7: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether fe:b3:6e:03:77:a9 brd ff:ff:ff:ff:ff:ff
    inet 169.254.31.29/31 scope global fpr-dc03bb5f-7
23: fg-972e3a99-25: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether fa:16:3e:86:f7:42 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.12/24 brd 10.0.0.255 scope global fg-972e3a99-25

Compute Server1での、仮想ルータ用Namespace内のインタフェース確認

# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip a
2: rfp-dc03bb5f-7: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether 26:67:3b:71:ef:02 brd ff:ff:ff:ff:ff:ff
    inet 169.254.31.28/31 scope global rfp-dc03bb5f-7
    inet 10.0.0.11/32 brd 10.0.0.11 scope global rfp-dc03bb5f-7
17: qr-84e871c6-a4: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether fa:16:3e:d0:dd:d0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.220.1/24 brd 192.168.220.255 scope global qr-84e871c6-a4
21: qr-bdc3d5ac-e6: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether fa:16:3e:30:cc:23 brd ff:ff:ff:ff:ff:ff
    inet 192.168.210.1/24 brd 192.168.210.255 scope global qr-bdc3d5ac-e6
    inet6 fe80::f816:3eff:fe30:cc23/64 scope link

Compute Server1での、仮想ルータ用Namespaceのルーティング情報

# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip rule ls
32768:  from 192.168.220.11 lookup 16
# ip netns exec qrouter-dc03bb5f-7a0e-4132-8b78-0fa2d35ca39f ip route show table 16
default via 169.254.31.29 dev rfp-dc03bb5f-7

この変更点を反映した構成図が図6です。インスタンスtest220-1からのパケットが、Compute Server1の仮想ルータ用Namespace 192.168.220.1へ届けば、Compute Server1上のPublic Network用インタフェースからパケットが外へ出ます。

図6：FIP用Namespace

ただし、インスタンス test220-1から見たDFGの192.168.220.1は、Controller + Network Server、Compute Server2にもあります。パケットキャプチャの結果から、他のサーバへは届いていないことは確認しまたが、ではなぜ届かなかったのでしょうか。

図6より、Compute Server1上のインスタンス test220-1から出たパケットが他のサーバへ届くためには、「br-int→br-tun→gre-XXX→eth2」という経路を通る必要があります。実は、br-tunで他サーバの192.168.220.1宛のパケットがDropされているのです。これは、br-tunのOVSのフローテーブルを参照するとわかります。

Compute Server1での、br-tunのポート番号確認。br-intとの接続ポート番号が1

# ovs-ofctl show br-tun
1(patch-int): addr:fe:f0:4d:00:37:95

Compute Server1での、br-tunのOVS flow table確認

# ovs-ofctl dump-flows br-tun
 (略)
 cookie=0x0, duration=45463.840s, table=0, n_packets=1126, n_bytes=89873, idle_age=3184, priority=1,in_port=1 actions=resubmit(,1)
(略)
 cookie=0x0, duration=20370.441s, table=1, n_packets=0, n_bytes=0, idle_age=20370, priority=2,dl_vlan=3,dl_dst=fa:16:3e:d0:dd:d0 actions=drop
(略)
 cookie=0x0, duration=20370.492s, table=1, n_packets=13, n_bytes=546, idle_age=3184, priority=3,arp,dl_vlan=3,arp_tpa=192.168.220.1 actions=drop

インスタンス test220-1から出て、br-intを経由してbr-tunへ到達したパケットのうち、他Server上の192.168.220.1のMAC Addressであるfa:16:3e:d0:dd:d0宛パケット、他Server上の192.168.220.1宛arp確認パケットは、br-tun上でDropされていることがわかります。

このパケットDropは、FIPなしのインスタンスで問題が発生しそうに思えますが、FIPなしでのPublic Network向けパケット処理の箇所で説明したとおり、FIPなしのインスタンスは、自分が動作しているCompute Serverの仮想ルータ宛にパケットを投げています。そして、そこからController + Network ServerのSNAT用仮想ルータのインタフェース192.168.220.10へと転送されます。つまり、他サーバ上の192.168.220.1あてのパケットがDropされていてもPublic Networkへ到達することができます。

これにより、インスタンスからPublic Network向けへのパケットは、Compute Server1内部だけで処理されます。つまり、実際のパケット処理は図7のように行われています。

図7：FIPなしでのPublic Network向け通信

おわりに

3回にわたり、Neutron DVRについて解説してきました。OpenStackは進化が非常に速く、将来のリリースでは挙動が変わる可能性もありますが、今回説明した解析手法は今後も活用できると思いますので、お役立ていただければ幸いです。

また、先日もOpenStack Summit Vancouverが開催され大変な盛り上がりをみせましたが、今年の10月には、ついに日本でOpenStack Summit Tokyoが開催されます。それに先駆けて、OpenStack Summit Tokyoに関する各種情報や、OpenStack Summit Vancouverの話題等を詳しく解説する特別イベント、「5周年特別企画：OpenStack Summitの歩き方」も7月13日に開催されますので、あわせて是非ご参加ください。

5周年特別企画： OpenStack Summitの歩き方

http://eventregist.com/e/openstack

最後になりましたが、本記事執筆にあたり、OSCA™技術分科会メンバーの皆様、日本OpenStackユーザ会の皆様、Blogで情報公開いただいた皆様に、多大なるご協力をいただきました。心より感謝いたします。

Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
OpenStack®の文字表記とOpenStackのロゴは，米国とその他の国におけるOpenStack Foundationの登録商標/サービスマークまたは商標/サービスマークのいずれかであり、OpenStack Foundationの許諾を得て使用しています。日立製作所は，OpenStack FoundationやOpenStackコミュニティの関連企業ではなく、また支援や出資を受けていません
OSCA™（Open Standard Cloud Association）は、デル株式会社の登録商標です。
Red Hat および Red Hat をベースとしたすべての商標とロゴは、米国とその他の国におけるRed Hat, Inc. の登録商標もしくは商標です
その他、記載の商標やロゴは、各社の商標または登録商標です。