上一节创建了 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 的连通性。