Neutronプラグイン「MidoNet」の内部構造を解説した資料です。 2015/02/12 ver1.2 トンネルIDとVMポートの関係の説明を追加

1. ver1.2 中井悦司
Twitter @enakai00
オープンクラウド・キャンパス
完全分散エッジ処理で実現する
Neutron仮想ネットワーク

2. Open Cloud Campus2
完全分散エッジ処理で実現するNeutron仮想ネットワーク
自己紹介
 中井悦司（なかいえつじ）
– Twitter @enakai00
 日々の仕事
– Senior Solution Architect and
Cloud Evangelist at Red Hat K.K.
企業システムでオープンソースの活用を希望される
お客様を全力でご支援させていただきます。
 昔とった杵柄
– 素粒子論の研究（超弦理論とか）
– 予備校講師（物理担当）
– インフラエンジニア（Unix/Linux専門）
好評発売中！

3. Open Cloud Campus3
完全分散エッジ処理で実現するNeutron仮想ネットワーク
Contents
 OpenStackとNeutronの基礎
 エッジ処理方式の例 〜 OpenFlowを利用した実装アイデア
 MidoNetの概要
 MidoNetの実装方式
 外部ネットワークとの接続方法
 バックエンドデータベースについて

4. OpenStackとNeutronの基礎

5. Open Cloud Campus5
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OpenStackが提供するコンピューティングリソース
 OpenStackのユーザは、Webコンソール/APIを利用して、
次のようなコンピューティングリソースを利用します。
– 仮想ネットワーク
– 仮想マシンインスタンス
– ブロックボリューム
データ領域 ブロックボリューム
仮想ルータ
仮想スイッチ
外部ネットワーク
プロジェクト環境
OpenStackユーザ
OS領域
 各ユーザは特定の「プロジェクト」に
所属します。
– プロジェクト内でリソースを共有
– プロジェクト全体でのリソース使用
量の上限設定、リソース使用状況の
レポーティングなどが可能
仮想マシンインスタンス

6. Open Cloud Campus6
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OpenStackのアーキテクチャー
 各モジュールは、REST APIによりクライアントからの指示を受け付けます。
– プログラムコードからの呼び出しによる環境操作の自動化
 外部のSDN製品やストレージ装置とドライバー/プライグインで連携する仕組みを持ちます。
– 外部製品とのインテグレーションによりさまざまな要件に対応
仮想マシン
イメージ
Nova
Compute
Nova
Compute
Glance Horizon Neutron
管理ネットワーク
LUN
仮想ネットワーク作成
仮想マシン起動
ブロックボリューム提供
認証サーバ
テンプレート
イメージ保存
MySQL
Network
Node
Nova
Compute
Cinder
Keystone
Swift
メッセージキュー
パブリックネットワーク
クライアントPC
Webコンソールアクセス
テンプレート
イメージ検索
テンプレート
ダウンロード
QPID/
RabbitMQ
データベース
LUN
LUN
Nova
外部のSDN製品が構成する
仮想ネットワークと連携
外部のストレージ装置と連携

7. Open Cloud Campus7
完全分散エッジ処理で実現するNeutron仮想ネットワーク
Neutronによる仮想ネットワークの典型例
 プロジェクトごとに仮想ルータを用意して、その背後にプライベートなネットワーク環境
を構成します。
– ブロードバンドルータで家庭内LANをインターネットに接続するような感覚です。
 仮想スイッチを作成して、ルータに接続します。
– それぞれの仮想スイッチは、プライベートIPの独立したサブネットを持ちます。
 仮想マシンインスタンス起動時は、接続する仮想スイッチを選択します。
– DHCPでプライベートIPアドレスが割り当てられます。
– 同じプロジェクトの仮想マシンインスタンス間は、プライベートIPで通信できます。
仮想スイッチ
192.168.101.0/24
プロジェクトA
専用ルータ
外部ネットワーク
プロジェクトB
専用ルータ
仮想スイッチ
192.168.102.0/24

8. Open Cloud Campus8
完全分散エッジ処理で実現するNeutron仮想ネットワーク
フローティングIPの利用
 外部ネットワークと通信する際は、仮想マシンインスタンスに「フローティングIP」を割
り当てます。
– 外部ネットワークのサブネット上で、フローティングIPとして利用可能なIPアドレスをプールして
おきます。
– 仮想ルータ上で、フローティングIPとプライベートIPのNATが行われます。
– フローティングIPを割り当てない場合でも、仮想マシンインスタンスから外部ネットワークへの接
続は可能です。（仮想ルータのIPアドレスを代表IPとして、マスカレード接続します。）
Webサーバー DBサーバー
プライベートIP プライベートIP
フローティングIP
外部ネットワークからは
フローティングIPで接続
インスタンス同士は
プライベートIPで接続

9. Open Cloud Campus9
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OVS Plugin実装方式の特徴
 Neutron標準のプラグイン
– オープンソース！
 仮想スイッチ／仮想ルーター／ファイアーウォールなど、それぞれの仮想ネットワークコ
ンポーネントを既存技術の組み合わせで個別に実装します。
– 仮想スイッチ : Open vSwitch + VLAN / GRE Tunnel
– 仮想ルーター : Linuxのパケットフォワーディング/NAT機能
– ファイアーウォール : Linuxのiptables
– DHCP : Linuxのdnsmasq
 仮想ネットワークトポロジーがそのままの形で実装されるので、仮想ネットワークが複雑
になると問題判別が難しくなります。（仮想ネットワーク上のパケットの流れをそのまま
追いかけていく必要があります。）
 Icehouseの実装では、仮想ルーターは、単一のネットワークノードに集約されるため、
ネットワークノードがSPOF/ボトルネックになります。
– Junoでは、「VRRPによるHA構成」と「DVRによる分散ルータ構成」が利用可能になり
ました。

10. Open Cloud Campus10
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OVS Pluginによる典型的なノード構成
 仮想ルーターがネットワークノードに集約されるので、仮想ルーターを経由する通信は、
すべてネットワークノードを経由します。
・・・
プライベートネットワーク
eth0 eth1 eth2
VM
NAT
br-int
br-ex
ネットワークノード
br-priv
eth0 eth1
br-int
br-priv
VM
eth0 eth1
br-int
br-priv
コンピュートノード
IP IP IP
パブリックネットワーク
eth0
IP
コントローラノード
Open vSwitch 仮想ルーター

11. Open Cloud Campus11
完全分散エッジ処理で実現するNeutron仮想ネットワーク
NeutronのPluginアーキテクチャー
 Neutron APIでユーザからのリクエストを受けたNeutron Serverは、メッセージキューを経
由して、各エージェントに仮想ネットワークコンポーネントの作成を指示します。
– 各エージェントの実装内容が、使用するPluginによって異なります。
・・・
eth0 eth1 eth2
VM
NAT
br-int
br-ex
ネットワークノード
br-priv
eth0 eth1
br-int
br-priv
VM
eth0 eth1
br-int
br-priv
コンピュートノード
IP IP IP
eth0
IP
コントローラノード
DHCP Agent L2 Agent L2 Agent
L2 Agent
L3 AgentNeutron
Server
APIリクエスト
仮想ネットワークコンポーネント作成指示

12. Open Cloud Campus12
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OVS Pluginによる仮想ネットワークの実装例 (1)
vm01 vm02 vm03 vm04
プロジェクトB
仮想ルータ
プロジェクトA
仮想ルータ
外部ネットワーク
仮想スイッチ
projectA
仮想スイッチ
projectB
 Open vSwitchプラグインを用いて、下図の仮想ネットワークを作成した際の具体的な実装
をコンピュートノード、ネットワークノードのそれぞれで示します。
– 2つのプロジェクトがそれぞれの仮想ルータを持っています。

13. Open Cloud Campus13
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OVS Pluginによる仮想ネットワークの実装例 (2)
br-priv
vm01
eth0
br-int
eth1
IP
phy-br-priv
int-br-priv
qvoXXX
vm02
eth0
IP
qvoYYY
ポートVLAN tag:1
qvoZZZ qvoWWW
ポートVLAN tag:2
vm04
eth0
IP
VLAN101
VLAN102
Nova Computeが構成
L2 Agentが構成
内部VLANと外部VLANを相互変換
・内部VLAN1⇔外部VLAN101
・内部VLAN2⇔外部VLAN102
仮想スイッチごとに異なる
「内部VLAN」を割り当てる
Open vSwitch
vm03
eth0
IP
 仮想スイッチごとに内部VLAN / 外部VLANを割り当てることでパケットを分離します。

14. Open Cloud Campus14
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OVS Pluginによる仮想ネットワークの実装例 (3)
dnsmasq
eth2
br-int
br-priv
phy-br-priv
int-br-priv
tapXXX qr-YYY
ポートVLAN tag:1
IP IP
qg-CCC
br-ex
eth1
qr-BBB
IP
dnsmasq
tapAAA
IP
IP
ポートVLAN tag:2
プライベートネットワーク用スイッチへ
パブリックネットワークへ
L2 Agentが構成
iptablesで
NAT&フィルタリング
内部VLANと外部VLANを相互変換
・内部VLAN1⇔外部VLAN101
・内部VLAN2⇔外部VLAN102
qg-VVV
IP
L3 Agentが構成
 複数の仮想ルータに対応して
iptablesによるパケット転送
のパスが複数用意されます。
DHCP Agentが構成

15. エッジ処理方式の例
OpenFlowを利用した実装アイデア

16. Open Cloud Campus16
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OpenFlowの仕組み
 OpenFlowスイッチは、ローカルのフローテーブルを参照して、個々のパケットの処理方法
を判断します。
– フローテーブルは、パケットのマッチング条件と対応するアクションの一覧表です。
 フローテーブルにマッチしないパケットが来た際は、OpenFlowコントローラーに処理方法
を問い合わせて、結果をフローテーブルに追加します。
– コントローラーのロジックはソフトウェアで実装されているので、（理論上は）どれだけ複雑な処
理でも実施することが可能です。
OpenFlowコントローラ
受信パケットの処理方法を
コントローラに問い合わせ
フローテーブル フローテーブル フローテーブル
問い合わせ結果を
フローテーブルに記録

17. Open Cloud Campus17
完全分散エッジ処理で実現するNeutron仮想ネットワーク
OpenFlowによる仮想ネットワークエミュレーション
 OpenFlowコントローラに仮想ネットワークの構成情報を持たせておき、仮想マシンから送
信されたパケットの行き先をコントローラで計算して、パケットの到達先を決定します。
– 仮想マシンからパケットを受け取ったOpen vSwitchは、コントローラの計算結果に基づいて、パ
ケットの内容を変更した後に、最終到達先のOpen vSwitchにパケットを転送します。
– 物理的なパケット転送はワンホップで済むので、問題判別はシンプルになります。（コントロー
ラーの計算にミスがない限り、ワンホップのパケット転送を追いかけるだけ。）
 ただし、単純に実装するとコントローラーの計算量が膨大になり、スケーラビリティに問
題が発生します。（コンピュートノードが増えると計算量はリニアに増加）
Open vSwitch
VM VM
Open vSwitch
VM VM
外部ネットワーク
普通のローカル
ネットワーク網
仮想ネットワーク
の論理構成
OpenFlow
コントローラー
パケットの
処理方法を指示

18. Open Cloud Campus18
完全分散エッジ処理で実現するNeutron仮想ネットワーク
MidoNetの完全分散アーキテクチャーによるアプローチ
 MidoNetは、パケット転送先の計算をコンピュートノード上のエージェントが行うことで、
コントローラーがボトルネックになることを回避します。
– 各エージェントは、自分が稼働するコンピュートノードだけを担当します。
– 計算結果はカーネル内部のフローテーブルに記録します。
Open vSwitch
VM VM
Open vSwitch
VM VM
OpenFlowコントローラー
構成データベース
Kernel Flowtable
VM VM
OpenFlowプロトコル
MidoNet Agent
Kernel Flowtable
VM VM
MidoNet Agent
データ参照
OpenFlowによる実装 MidoNetの実装

19. Open Cloud Campus19
完全分散エッジ処理で実現するNeutron仮想ネットワーク
「カーネル内部のフローテーブル」とは？
 Open vSwitchは、OpenFlow機能を提供するLinux上の仮想ネットワークスイッチです。
– OpenFlow機能を効率的に実現するために、パケット転送に使用するフローテーブルは、カーネル
モジュールとして実装されています。
– OpenFlowコントローラーとの通信やフローテーブルの書き換えは、ユーザーランドのモジュール
が行います。
 MidoNetでは、MidoNetエージェントが、パケットの転送先に合わせて、直接にカーネル
内部のフローテーブルを書き換えます。
– Linuxカーネルは、フローテーブルを見てパケット転送を行うので、実際の転送処理は、カーネル内
部で完結します。
OpenFlow
コントローラ
フローテーブル
Linuxカーネル
フローテーブル
ユーザーランド
モジュール
この組み合わせが
OVSの実体
Linuxカーネル
フローテーブル
MidoNet
エージェント
OpenFlowプロトコル
MidoNetエージェントが
フローテーブルを直接変更
カーネルモージュルは
OVSから借用

20. MidoNetの概要

21. Open Cloud Campus21
完全分散エッジ処理で実現するNeutron仮想ネットワーク
MidoNetの特徴
 商用のNeutronプラグイン
– オープンソースではありません・・・。残念。
 仮想ネットワーク全体を独自の構造でデータ化して、構成データベースに保存します。
– 仮想ネットワーク内部のパケットの動きをMidoNetエージェントが計算して、最終的なパケットの
転送先を決定します。
 物理的なパケット転送は、すべてワンホップで行います。
– 実際の転送処理は、カーネル内部のフローテーブルを直接に使用します。（Open vSwitch /
OpenFlowは使用していません。）
– 1つの通信セッションに伴うパケットは、同じフローテーブルでまとめて処理するので、エージェ
ントによる計算が発生するのは、最初のパケット転送時のみです。
– 物理サーバー間のパケット転送は、GRE、もしくは、VXLANでカプセリングします。
 仮想スイッチ、仮想ルーター、セキュリティグループ、LBaaSなど、Neutronが提供する仮
想ネットワークコンポーネントをすべて提供します。
– エンドユーザーは、NeutronのAPIから操作するので、MidoNetの存在を意識する事はありません。

22. Open Cloud Campus22
完全分散エッジ処理で実現するNeutron仮想ネットワーク
MidoNetがオープンソースになりました！
https://github.com/midonet
http://www.midonet.org/

23. Open Cloud Campus23
完全分散エッジ処理で実現するNeutron仮想ネットワーク
典型的なサーバ構成
 外部ネットワークとの接続は、ゲートウェイノードを経由して行います。
– 複数のゲートウェイノードが論理的に1つのBGPルーターとして振る舞います。
VM VM
MidoNet Agent
VM VM
MidoNet Agent
MidoNet
Agent
MidoNet
Agent
外部ネットワーク
接続ルータ
・・・
・・・
DHCP Agent
L2 Agent
L3 Agent
MidoNet API サーバ
ゲートウェイノード
Nova Compute
Neutron Serverに対しては、
これがAgentとして振る舞う
Neutron Server
Neturonクライアント
からのAPIリクエスト
仮想ネットワーク
コンポーネント作成指示
NSDBサーバ

24. Open Cloud Campus24
完全分散エッジ処理で実現するNeutron仮想ネットワーク
本日のデモ環境
外部ネットワーク接続ルータ
（Vyatta）
OpenStackコントローラー
MidoNet APIサーバー
Nova Compute
NSDBサーバー
ゲートウェイノード
192.168.30.5
192.168.30.8192.168.30.7
192.168.30.6
192.168.30.10 192.168.30.11
119.67.1115.133
10.0.0.70
10.0.1.48
Neutronの仮想ネットワークからは、
ゲートウェイノードが
「external network」に相当する
論理ネットワーク

25. MidoNetの実装方式

26. Open Cloud Campus26
完全分散エッジ処理で実現するNeutron仮想ネットワーク
GREトンネルについて
 GREトンネルは、物理ネットワーク上にパケットを送出する際に、「GREヘッダー」でパ
ケットをカプセル化する仕組みです。
– 「トンネル」と言っていますが、VPNのように固定的なトンネルのセッションが張られているわけ
ではありません。
– GREヘッダー付きのパケットを受け取るように設定されたサーバーに対しては、いつでも自由に
GREパケットを送信することができます。
VM
10.0.0.19
192.168.30.7 192.168.30.8
VM
10.0.1.3
From 192.168.30.7
To 192.168.30.8
From 10.0.0.19
To 10.0.1.3
送信データ
From 10.0.0.19
To 10.0.1.3
送信データ

27. Open Cloud Campus27
完全分散エッジ処理で実現するNeutron仮想ネットワーク
# ovs-vsctl show
911ff1ca-590a-4efd-a066-568fbac8c6fb
[... Bridge br-int omitted ...]
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-2"
Interface "gre-2"
type: gre
options: {in_key=flow, local_ip="192.168.1.100", out_key=flow, remote_ip="192.168.1.101"}
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, local_ip="192.168.1.100", out_key=flow, remote_ip="192.168.1.102"}
OVSプラグインでのGREトンネルの取り扱い
 Neutron標準のOVSプラグインでGREトンネルを使用する際は、すべてのサーバー間でフル
メッシュになるように、GREパケット送受信用仮想ポートが用意されます。
– これは、OVSカーネルモジュールの「Port base tunneling」と呼ばれる機能です。
br-tun
gre-1
gre-2
br-tun
gre-1
gre-2
br-tun
gre-1
gre-2
ピア情報の
事前設定が必要

28. Open Cloud Campus28
完全分散エッジ処理で実現するNeutron仮想ネットワーク
# mm-dpctl --show-dp midonet
Datapath name : midonet
Datapath index : 24
Datapath Stats:
Flows :5
Hits :266505
Lost :0
Misses:428442
Port #0 "midonet" Internal Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0}
Port #1 "tngre-overlay" Gre Stats{rxPackets=507262, txPackets=183624, rxBytes=268582386, txBytes=17368575, rxErrors=0, txErrors=0,
rxDropped=0, txDropped=0}
Port #2 "tnvxlan-overlay" VXLan Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0,
txDropped=0}
Port #3 "tnvxlan-vtep" VXLan Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0}
Port #5 "tap2223188b-bb" NetDev Stats{rxPackets=644, txPackets=669, rxBytes=76522, txBytes=77884, rxErrors=0, txErrors=0,
rxDropped=0, txDropped=0}
MidoNetでのGREトンネルの取り扱い (1)
 MidoNetでは、OVSカーネルモジュールの「Flow base tunneling」機能を利用しており、
ピアを特定しない汎用のトンネルポートから、GREパケットを送信します。
– フローテーブルのアクションで、GREパケット送信先のアドレスを指定して送信します。
– この際、GREヘッダーに「トンネルID」の情報を付与できます。（これはパケットの種類を区別す
る単なるメタ情報で、利用方法はユーザーの自由です。）
midonet
tngre-overlay
tapXX tapYY
VMVM midonet
tngre-overlay
tapXX tapYY
midonet
tngre-overlay
tapXX tapYY
Port #1
Port #5

29. Open Cloud Campus29
完全分散エッジ処理で実現するNeutron仮想ネットワーク
MidoNetでのGREトンネルの取り扱い (2)
 MidoNetでは、個々のVM接続ポートにユニークなトンネルIDを割り当てることで、送信元
サーバーは、トンネルIDによって送信先VMを指定します。
– 新たなVMをポートに接続するタイミングで、MidoNetエージェントがトンネルIDを割り当てて、
データベースに登録します(*)
。
 送信側は、フローテーブルのアクションで次の処理を行います。
– 送信先サーバーのIPアドレスを FlowKey に指定します。
– 送信先VMポートに対応するトンネルIDを FlowKeyに指定します。
– GREトンネルポート（tngre-overlay）にパケットを転送します。
 受信側は、フローテーブルのアクションで次の処理を行います。
– トンネルIDでパケットをマッチします。
– マッチしたパケットをトンネルIDに対応するVMポートに転送します。
midonet
tngre-overlay
(*) MidoNetのソースを読んだ時の俺メモ http://d.hatena.ne.jp/enakai00/20141212/1418358009
tapXX
VM
midonet
tngre-overlay
tapXX
VM
トンネルIDに対応した
VMポートに転送
FlowKeyで指定された
IPにパケットを送信
送信先IPとトンネルID
をFlowKeyにセット

30. Open Cloud Campus30
完全分散エッジ処理で実現するNeutron仮想ネットワーク
Flow:
match keys:
FlowKeyInPort{portNo=5}
FlowKeyEthernet{eth_src=fa:16:3e:19:3b:90, eth_dst=ac:ca:ba:b9:bb:50}
FlowKeyEtherType{etherType=0x800}
FlowKeyIPv4{ipv4_src=10.0.0.19, ipv4_dst=10.0.1.3, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=64, ipv4_frag=0}
FlowKeyTCP{tcp_src=59373, tcp_dst=22}
actions:
FlowActionSetKey{flowKey=FlowKeyEthernet{eth_src=ac:ca:ba:c9:70:6f, eth_dst=fa:16:3e:04:a1:f9}}
FlowActionSetKey{flowKey=FlowKeyIPv4{ipv4_src=10.0.0.19, ipv4_dst=10.0.1.3, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=63, ipv4_frag=0}}
FlowActionSetKey{flowKey=FlowKeyTunnel{tun_id=116, ipv4_src=192.168.30.7, ipv4_dst=192.168.30.8, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1}}
FlowActionOutput{portNumber=1}
stats: FlowStats{n_packets=6, n_bytes=1787}
tcpFlags: PSH|ACK
GREトンネルを処理するフローテーブルの例
 次は、GREトンネルを経由してパケットを送受信するフローテーブルの例です。
– 「トンネルID」を用いて、受信側でのパケットの処理を条件分岐していることが分かります。
– これらのフローテーブルは、各サーバーのMidoNetエージェントが作成・登録しています。
Flow:
match keys:
FlowKeyTunnel{tun_id=116, ipv4_src=192.168.30.7, ipv4_dst=192.168.30.8, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1}
FlowKeyInPort{portNo=1}
FlowKeyEthernet{eth_src=ac:ca:ba:c9:70:6f, eth_dst=fa:16:3e:04:a1:f9}
FlowKeyEtherType{etherType=0x800}
FlowKeyIPv4{ipv4_src=10.0.0.19, ipv4_dst=10.0.1.3, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=63, ipv4_frag=0}
FlowKeyTCP{tcp_src=59372, tcp_dst=22}
actions:
FlowActionOutput{portNumber=5}
stats: FlowStats{n_packets=8, n_bytes=1919}
tcpFlags: FIN|PSH|ACK
トンネルID=116と送信先サーバー192.168.30.8を指定
GREトンネルポートからパケットを送出
トンネルID=116で受信したパケットにマッチ
受け取り先のVMが接続したポートに転送
送信側のテーブル
受信側のテーブル

31. Open Cloud Campus31
完全分散エッジ処理で実現するNeutron仮想ネットワーク
パケット転送処理の具体例 (1)
 VM1からVM2にSSH接続する例で、具体的に考えます。
– ここでは、VM1でのARP解決は終わっているものとします。ARP解決については後述します。
 Node#1での処理
– VM1からVM２宛のSSHパケットが、Node#1の仮想スイッチ「midonet」に入ります。
– フローテーブルには、このパケットにマッチするエントリーが無いので、Node#1のMidoNetエー
ジェントに問い合わせが行きます。
– MidoNetエージェントは、仮想ネットワークトポロジーを参照して、最終到達先のポート（VM2が接
続したポート）を特定します。その後、ポートに対応したトンネルIDを付与して、Node#2にトンネ
ル経由でパケットを転送するエントリーをフローテーブルに作成します。
 Node#2での処理
– Node#1から受信したパケットは、フローテーブルにマッチするエントリーが無いので、Node#2の
MidoNetエージェントに問い合わせが行きます。
– MidoNetエージェントは、トンネルIDから対応するポートを判別して、このパケットを該当ポートに
転送するエントリーをフローテーブルに作成します。
midonet
tngre-overlay
tapXX tapYY
VM1
midonet
tngre-overlay
tapXX
VM2
tapYY
Node#1 Node#2

32. Open Cloud Campus32
完全分散エッジ処理で実現するNeutron仮想ネットワーク
パケット転送処理の具体例 (2)
 その後、SSH接続として続くパケットは、先に作られたフローテーブルのエントリーで処理
されるので、MidoNetエージェントによる計算は発生しません。カーネル内部で転送処理が
完結します。
– 裏を返すと、一発目のパケットだけは、転送に時間がかかります。
 VM1がVM2にSSH接続する場合、実際には、最初にVM1からARPパケットが送信されます。
MidoNetエージェントは、ARPパケットについては、仮想L2レイヤーのすべてのポートに転
送します。
– IPアドレスとMACアドレスの対応は、構成データベースに記録されているので、MidoNetが代理で返
答することも可能ですが、そのような実装はしていません。（それをやると、VM上のアプリケー
ションがARPパケットのブロードキャストを利用した処理をする場合に、うまく動かない恐れがあり
ます。）
 MidoNetでは、異なるテナント間でのパケット転送についても、すべてワンホップで直接に
転送します。
– 途中の仮想ルーターでNATが入る場合は、NAT変換を行った状態のパケットを送信します。具体例は
後で紹介します。

33. 外部ネットワークとの接続方法

34. Open Cloud Campus34
完全分散エッジ処理で実現するNeutron仮想ネットワーク
Neutronで定義した仮想ネットワーク
外部ネットワークとの接続方法 (1)
 外部ネットワークとの接続は、ゲートウェイノードを経由して行います。
– 複数のゲートウェイノードが論理的に1つのBGPルーターとして振る舞います。
VM VM
MidoNet Agent
VM VM
MidoNet Agent
MidoNet
Agent
MidoNet
Agent
物理的な意味での
外部ネットワーク
Neutronの定義上での
「外部ネットワーク」
・・・ BGPルーター
論理構成図
物理構成図

35. Open Cloud Campus35
完全分散エッジ処理で実現するNeutron仮想ネットワーク
外部ネットワークとの接続方法 (2)
 外部ネットワーク上のIPアドレスに向けたパケットは、コンピュートノードのMidoNetエー
ジェントが、ゲートウェイノードに転送した後、ゲートウェイノードのMidoNetエージェン
トが、外部ネットワークに送出します。
VM VM
MidoNet Agent
VM VM
MidoNet Agent
MidoNet
Agent
MidoNet
Agent
・・・
物理構成図
 パケットの送出については、複数のゲートウェイ
ノードで、パケット単位の負荷分散を行います。
– コンピュートノードのエージェントが転送先のゲー
トウェイノードをパケット単位で振り分けます。
 外部ネットワークからの受信については、外部
ルーター（BGPルーター）の設定で負荷分散する
ようにしておきます。
 ゲートウェイノードが停止（リンクダウン）した
際は、自動的に該当ノードの使用を停止します。
– コンピュートノードのエージェントは該当ノードへ
の転送を停止します。
– 外部ルーターの方でもリンクダウンした経路には転
送しないように設定しておきます。

36. Open Cloud Campus36
完全分散エッジ処理で実現するNeutron仮想ネットワーク
NATを伴う通信処理の例 (1)
 コンピュートノード上のVMから、テナントルーター（仮想ルーター）を経由して外部ネッ
トワークと通信する際は、仮想ルーター上でNAT処理が行われます。このような通信を
MidoNetエージェントは、次のように処理します。
– 例として、プライベートIP「10.0.0.5」とフローティングIP「119.67.115.133」を持ったVMから
グローバルIP「108.171.178.131」に接続します。
VM
プロジェクト用
仮想ルータ
外部ネットワーク
仮想スイッチ
VM
論理構成図
論理的には、ここで
プライベートIPと
フローティングIPを変換

37. Open Cloud Campus37
完全分散エッジ処理で実現するNeutron仮想ネットワーク
NATを伴う通信処理の例 (2)
 送信パケットの処理
– コンピュートノードでは、送信元IPを変換した後に、ゲートウェイノードに転送します。
– ゲートウェイノードでは、受け取ったパケットをそのまま外部ルータ接続ポートに送信します。
Flow:
match keys:
FlowKeyInPort{portNo=5}
FlowKeyEthernet{eth_src=fa:16:3e:19:3b:90, eth_dst=ac:ca:ba:b9:bb:50}
FlowKeyEtherType{etherType=0x800}
FlowKeyIPv4{ipv4_src=10.0.0.19, ipv4_dst=8.8.8.8, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=64, ipv4_frag=0}
FlowKeyTCP{tcp_src=38841, tcp_dst=22}
actions:
FlowActionSetKey{flowKey=FlowKeyEthernet{eth_src=fa:16:3e:9a:76:2c, eth_dst=fa:16:3e:fa:78:6a}}
FlowActionSetKey{flowKey=FlowKeyIPv4{ipv4_src=119.67.115.133, ipv4_dst=8.8.8.8, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=62,
ipv4_frag=0}}
FlowActionSetKey{flowKey=FlowKeyTunnel{tun_id=4, ipv4_src=192.168.30.7, ipv4_dst=192.168.30.10, tun_flag=0, ipv4_tos=0,
ipv4_ttl=-1}}
FlowActionOutput{portNumber=1}
Flow:
match keys:
FlowKeyTunnel{tun_id=4, ipv4_src=192.168.30.7, ipv4_dst=192.168.30.10, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1}
FlowKeyInPort{portNo=1}
FlowKeyEthernet{eth_src=fa:16:3e:9a:76:2c, eth_dst=fa:16:3e:fa:78:6a}
FlowKeyEtherType{etherType=0x800}
FlowKeyIPv4{ipv4_src=119.67.115.132, ipv4_dst=8.8.8.8, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=62, ipv4_frag=0}
FlowKeyTCP{tcp_src=28578, tcp_dst=22}
actions:
FlowActionOutput{portNumber=4}
送信元IPをフローティングIPに変換
トンネルIDでパケットを同定
外部ルータ接続ポートに送信

38. Open Cloud Campus38
完全分散エッジ処理で実現するNeutron仮想ネットワーク
NATを伴う通信処理の例 (3)
 受信パケットの処理
– ゲートウェイノードでは、宛先IPを変換した後に、コンピュートノードに転送します。
– コンピュートノードでは、受け取ったパケットをそのままVM接続ポートに送信します。（フロー
テーブルは省略）
Flow:
match keys:
FlowKeyInPort{portNo=4}
FlowKeyEthernet{eth_src=fa:16:3e:fa:78:6a, eth_dst=fa:16:3e:9a:76:2c}
FlowKeyEtherType{etherType=0x800}
FlowKeyIPv4{ipv4_src=8.8.8.8, ipv4_dst=119.67.115.133, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=64, ipv4_frag=0}
FlowKeyTCP{tcp_src=22, tcp_dst=38841}
actions:
FlowActionSetKey{flowKey=FlowKeyEthernet{eth_src=ac:ca:ba:b9:bb:50, eth_dst=fa:16:3e:19:3b:90}}
FlowActionSetKey{flowKey=FlowKeyIPv4{ipv4_src=8.8.8.8, ipv4_dst=10.0.0.19, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=62,
ipv4_frag=0}}
FlowActionSetKey{flowKey=FlowKeyTunnel{tun_id=79, ipv4_src=192.168.30.10, ipv4_dst=192.168.30.7, tun_flag=0, ipv4_tos=0,
ipv4_ttl=-1}}
FlowActionOutput{portNumber=1}
stats: FlowStats{n_packets=7, n_bytes=2159}
tcpFlags: PSH|ACK
lastUsedTime: 5650190955
送信元IPをプライベートIPに変換

39. Open Cloud Campus39
完全分散エッジ処理で実現するNeutron仮想ネットワーク
NATを伴う通信処理の例 (4)
 このようなアドレス変換のタイミングの違いは、コンピュートノードとゲートウェイノー
ドの間のGREパケットをtcpdumpで観察すると分かります。
 この例から、NATテーブルのような動的なステータス情報が、MidoNetエージェント間で共
有されていることが分かります。
02:33:29.844465 IP 192.168.30.7 > 192.168.30.10: GREv0, key=0x4, length 113: IP 119.67.115.133.38841 > 8.8.8.8.ssh: Flags [P.],
seq 50412351:50412390, ack 1175296680, win 4374, options [nop,nop,TS val 797740 ecr 565001338], length 39
02:33:29.845022 IP 192.168.30.10 > 192.168.30.7: GREv0, key=0x4f, length 74: IP 8.8.8.8.ssh > 10.0.0.19.38841: Flags [.], ack
50412390, win 110, options [nop,nop,TS val 565001338 ecr 797740], length 0
送信パケットは、ゲートウェイノードに行く段階で、
送信元IPがフローティングIPになっている
受信パケットは、コンピュートノードに行く段階で、
宛先IPがプライベートIPになっている
コンピュートノードからゲートウェイノードへの
GREパケット
ゲートウェイノードからコンピュートノードへの
GREパケット

40. バックエンドデータベースについて

41. Open Cloud Campus41
完全分散エッジ処理で実現するNeutron仮想ネットワーク
MidoNetのバックエンドデータベース
 MidoNetでは、バックエンドデータベースとして、ZooKeeperとCassandraを使用します。
– ZooKeeper : 仮想ネットワーク構成など静的な情報を保存
– Cassandra : NAT変換テーブルなど動的な情報を保存
 ZooKeeperは、分散処理マネージャーの機能を持っており、エージェント間での分散ロック
機能の提供や、構成変更に伴うエージェントへの通知処理なども行います。
– エンドユーザーがNeutron APIで仮想ネットワークを変更すると、Neutronデータベースの更新に合
わせて、ZooKeeper上の構成情報が更新されます。
– この時、仮想ネットワークの変更に影響を受けるノード上のエージェントに対して、ZooKeeperから
通知が行われます。
 ちなみに、各エージェントは、ScalaのActorモデル（Akka）で非同期連携しています。
– 各エージェント（Actor）が個別のメッセージ受信キューを持って、メッセージ交換による非同期並
列処理を行います。
– 各エージェントは、ゴシッププロトコルでクラスター情報を共有します。
 ZooKeeper内部のデータ構造とか、エージェント内部の計算ロジックとか、Akkaによる非同
期連携の詳細とか、だれか、ソース読んで教えてください！！！

42. 中井悦司
Twitter @enakai00
オープンクラウド・キャンパス
MidoNetで分散ネットワーク
アーキテクチャーを学びましょう！