上一節創建了 OVS 本地網絡 first_local_net，今天我們會部署一個 instance 到該網絡並分析網絡結構。
launch 一個 instance，選擇 first_local_net 網絡
instance 部署成功，分配的 IP 地址為 172.16.1.3
底層網絡發生了什么變化？
對於 instance “cirros-vm1”，Neutron 會在 subnet 中創建一個 port，分配 IP 和 MAC 地址，並將 port 分配給 cirros-vm1。
如上圖所示，port 列表中增加了一個 port “(fc1c6ebb-719d)”，IP 為 172.16.1.3，點擊 port 名稱查看 MAC 信息。
我們可以先按照在 linux bridge driver 章節學到的知識推測一下： Open vSwitch driver 會如何將 cirros-vm1 連接到 first_local_net？
如果采用類似的實現方法，neutron-openvswitch-agent 會根據 port 信息創建 tap 設備 tapfc1c6ebb-71，並將其連接到 br-int 網橋，tapfc1c6ebb-71 就是 cirros-vm1 的虛擬網卡。
下面我們驗證一下事實是否如此：
cirros-vm1 部署到了控制節點，通過 ovs-vsctl show 查看 bridge 的配置：
非常遺憾，在 br-int 上並沒有看到 tapfc1c6ebb-71，而是多了一個 qvofc1c6ebb-71。 目前我們並不知道 qvofc1c6ebb-71 是什么，我們再用 brctl show 查看一下 linux bridge 的配置：
這里我們看到有一個新建的網橋 qbrfc1c6ebb-71，上面連接了兩個設備 qvbfc1c6ebb-71 和 tapfc1c6ebb-71。
從命名上看，他們都應該與 cirros-vm1 的虛擬網卡有關。
通過 virsh edit 查看 cirros-vm1 的配置：
確實 tapfc1c6ebb-71 是 cirros-vm1 的虛擬網卡。 那么 linux bridge qbrfc1c6ebb-71 上的 qvbfc1c6ebb-71 設備與 Open vSwitch br-int 上的 qvofc1c6ebb-71 是什么關系呢？
下面的內容稍微需要一些技巧了。 我們用 ethtool -S 分別查看 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 的 statistics。
原來 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 都是 veth 設備，它們對應的另一端 veth 設備 的 index 分別是 12 和 13。 通過 ip a 命令找到 index 12 和 13 的設備。
到這里，相信有同學已經看出來了：qvbfc1c6ebb-71 和 qvofc1c6ebb-71 組成了一個 veth pair。
我們之前介紹過，veth pair 是一種成對出現的特殊網絡設備，它們象一根虛擬的網線連接兩個網絡設備。
這里 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 的作用就是連接網橋 qbrfc1c6ebb-71 和 br-int。
文字描述往往是不夠直觀的，下面我們將前面梳理好的信息通過圖片展示出來。
由圖所示，tapfc1c6ebb-71 通過 qbrfc1c6ebb-71 間接連接到 br-int。
那問題來了，為什么 tapfc1c6ebb-71 不能像左邊的 DHCP 設備 tap7970bdcd-f2 那樣直接連接到 br-int 呢？
其原因是： Open vSwitch 目前還不支持將 iptables 規則放在與它直接相連的 tap 設備上。
如果做不到這一點，就無法實現 Security Group 功能。 為了支持 Security Group，不得不多引入一個 Linux Bridge 支持 iptables。
這樣的后果就是網絡結構更復雜了，路徑上多了一個 linux bridge 和 一對 veth pair 設備。
下節我們再部署一個 instance 到 first_local_network 並驗證兩個 instance 的連通性。
