OpenStack Neutron中的DVR简介与OVS流表分析
作者：互联网
本文主要介绍DVR的概念，比较了DVR和非DVR情况下，数据在network节点上的流量变化。同时也介绍了在OpenStack里面如何配置DVR，比较详细地介绍了在DVR激活的情况下，数据包的流表情况。
DVR 简介DVR 提出的背景
在Neutron的网络环境中，跨子网的虚机通信是需要通过Neutron的路由器。这既包括不同子网的虚拟机之间的通信，又包括虚拟机与外网之间的通信。在DVR被提出之前，由于Neutron的legacy router只会部署在网络节点上，因此会造成网络节点的流量过大，从而产生了两个问题，其一是网络节点将成为整个Neutron网络的瓶颈，其二是网络节点单点失败的问题。在这样的背景下，OpenStack社区在Juno版本里正式引入了DVR(Distributed Virtual Router)。DVR，顾名思义就是Neutron的router将不单单部署在网络节点上，所有启动了Neutron L3 Agent的节点，都会在必要时在节点上创建Neutron router对应的 namepsace，并更新与DVR router相关的Openflow规则，从而完成DVR router在该节点上的部署。在计算节点上部署了DVR router后，E-W方向上的流量不再需要将数据包发送到网络节点后再转发，而是有本地的DVR router直接进行跨子网的转发；N-S方向上，对于绑定了floating IP的虚机，其与外网通信时的数据包也将直接通过本地的DVR router进行转发。从而，Neutron网络上的一些流量被分摊开，有效地减少了网络节点上的流量；通信不再必须通过网络节点，也提升了Neutron网络的抗单点失败的能力。
本文主要讲解的是E-W方向上的虚拟机通信情况。
非DVR和DVR情况下，网络节点流量对比这是在有相同数量的虚机的情况下的对比。
非DVR的情况，网络节点的流量情况
[root@test114 openvswitch]# ifstat
#kernel
Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate
RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate
lo 19090K 0 19090K 0 18446744071513M 0 18446744071513M 0
0 0 0 0 0 0 0 0
eth0 116688K 0 1737K 0 674575K 0 555880K 0
0 0 0 0 0 0 0 0
eth1 118480K 0 286 0 18446744070647M 0 71696 0
0 0 0 0 0 0 0 0
br-eth1 8650K 0 80 0 1580M 0 3360 0
0 1127 0 0 0 0 0 0
br-ex 10276K 0 1737K 0 18446744071533M 0 555877K 0
0 1127 0 0 0 0 0 0
在DVR enabled的情况下，网络节点的流量情况
[root@test114 ~]# ifstat
#kernel
Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate
RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate
lo 2155 0 2155 0 790717 0 790717 0
0 0 0 0 0 0 0 0
eth0 10461 0 213 0 2310K 0 88001 0
0 0 0 0 0 0 0 0
eth1 10683 0 0 0 2399K 0 0 0
0 0 0 0 0 0 0 0
br-eth1 528 0 0 0 90626 0 0 0
0 0 0 0 0 0 0 0
br-ex 800 0 213 0 173756 0 88001 0
0 0 0 0 0 0 0 0
在非DVR和DVR的情况下，数据包流经各节点的对比
DVR支持VLAN、GRE、VXLAN这几种网络类型，但因为方便起见（VLAN需要开启路由器的Trunk口），所以本文中，我们这就用 GRE作为环境的网络类型。我们这里的环境情况如下：
网络节点是test114.sce.ibm.com, 两个计算节点分别是test115.sce.ibm.com和test116.sce.ibm.com，两个私有网络分别是gre(192.168.11.0/24),gre1(192.168.12.0/24),都是GRE类型的，它们通过router相连，在两个计算节点上面分别有一台虚拟机,它们分属不同的网络。这里面VM1在test115.sce.ibm.com上，ip地址是192.168.11.3,VM2在 test116.sce.ibm.com 上,ip地址是192.168.12.4。
非DVR的情况：
图1 非DVR[root@test115 ~] tcpdump |grep -i "gre"
18:14:11.794450 IP test115.sce.ibm.com > test114.sce.ibm.com: GREv0, key=0x1, length 106:
IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 16641, seq 23588, length 64
18:14:11.794550 IP test114.sce.ibm.com > test116.sce.ibm.com: GREv0, key=0x2, length 106:
IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 16641, seq 23588, length 64
18:14:11.796136 IP test116.sce.ibm.com > test114.sce.ibm.com: GREv0, key=0x2, length 106:
IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 16641, seq 23588, length 64
18:14:11.796198 IP test114.sce.ibm.com > test115.sce.ibm.com: GREv0, key=0x1, length 106:
IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 16641, seq 23588, length 64
DVR的情况：
图2 DVR16:34:02.479531 IP test115.sce.ibm.com > test116.sce.ibm.com: GREv0, key=0x2, length 106:
IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 10241, seq 19852, length 64
16:34:02.482082 IP test116.sce.ibm.com > test115.sce.ibm.com: GREv0, key=0x1, length 106:
IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 10241, seq 19852, length 64
在非 DVR 的情况，数据是要通过网络节点才能相互传递数据包；在 DVR 的情况，数据包是直接在两个计算节点上传递。
配置DVR配置文件在网络节点和计算节点配置DVR:
网络节点：因为 DVR 是属于 l3-agent 的功能,并依赖于 l3-agent，所以我们在这里的改动应该默认为环境上的 l3-agent 是可以工作的。具体配置如下：
修改对应文件：
neutron.conf : router_distributed = True
l3_agent.ini : agent_mode = dvr_snat
ovs_neutron_plugin.ini : l2_population = True and enable_distributed_routing = True
ml2_conf.ini : mechanism_drivers = openvswitch,linuxbridge,l2population
重新启动 neutron-openvswitch-agent, netron-l3-agent, neutron-server 服务。
计算节点：考虑到 compute node 上可能在 enable DVR 之前是没有启动/配置 DVR 的，那么参照 network node 上的 l3_agent.ini 去配置 compute node，启动 l3-agent。同时把 l3-agent 配置成 DVR 模式。还需要在节点上配置 br-ex 这个 ovs bridge，如果节点上在 enable DVR 之前没有这个 ovs bridge，并且如果 compute node 上的虚机需要与外网通信，那么 compute node 上的 br-ex 就必须桥接到一个可以连接到外网的网卡上。具体配置如下：
把节点配置成 DVR 模式：
l3_agent.ini : agent_mode = dvr
ovs_neutron_plugin.ini : l2_population = True and enable_distributed_routing = True
重新启动neutron-openvswitch-agent, netron-l3-agent 服务。
建立br-ex网桥，使得eth0上的ip地址转移到br-ex上。具体操作如下：
建立br-ex: ovs-vsctl add-br br-ex
把eth0桥接到br-ex里面:ovs-vsctl add-port br-ex "eth0"
建立ifcfg-br-ex,ifcfg-eth0 is in /etc/sysconfig/network-scripts。
重新启动网络服务。使得配置生效。
迁移到 DVR 模式。使得新添加的 l3-agent 能够管理 router,（如果是先 enabled DVR,再建立网络和 router，忽略这一步），具体操作如下：
在网络节点上执行如下操作：
neutron router-update --admin_state_up=False ROUTER
neutron router-update --distributed=True ROUTER
neutron router-update --admin_state_up=True ROUTER
查看router是否已经和三个l3-agent对应
[root@test114 ~]# neutron l3-agent-list-hosting-router router2
+--------------------------------------+------------------
| id | host | admin_state_up | alive |
+--------------------------------------+------------------
|26a3a232-888b-4b6d-8f81-5bdd2b988414 | test114.sce.ibm.com | True | :-) |
|818537d8-903a-4ff9-a745-2d562ab82e54 | test115.sce.ibm.com | True | :-) |
|427b251d-b210-4782-9d96-858c30181dbe | test116.sce.ibm.com | True | :-) |
计算节点上的虚拟机的数据流的传递当在虚拟机VM1(test115.sce.ibm.com)里面去ping VM2的IP的时候，数据包先转到宿主机的网桥br-int上，数据先传到那个和VM1的port匹配的port端口上，转到网关所在的那个端口,再转到namespace里，找到网关所在的端口，再转回br-int，然后通过br-int上面的patch-tun端口传递到br-tun这个网桥上，在br-tun网桥上的对应的端口通过trunk传递数据包到VM2所在的宿主机（test116.sce.ibm.com）的br-tun上的对应端口，再通过patch-int传到br-int上的patch-tun，通过br-int上的与VM2对应的port端口，把数据传递给VM2,完成数据包的传递。简单的可以写成vm1->br-int->namespace->br-int>br-tun->tunnel>br-tun->br-int->vm2。
DVR环境下Openflow规则的分析OVS命令简介Open VSwitch(OVS)是一个虚拟交换机，可以用来组成虚拟网络。OpenStack Neutron里面也是应用了OVS,Neutrondd的router虽然是工作在网络3层的，看似与2层的OVS无关，但实际上Neutron router在转发不同子网之间的数据流量时，还是需要借助2层Openflow规则，并且Neutron router的namespace中的子网网关的端口设备等都是需要接在OVS的网桥br-int 上才能工作的。DVR作为Neutron router的一种特殊实现，本质上也是依赖于OVS的，这一点与Neutron legacy router并无差异。在前面DVR的配置中我们用到了一些OVS的命令，这里再介绍一下OVS的一些命令：
查看open vswitch的网络状态:ovs-vsctl show
查看网桥br-tun的接口状况：ovs-ofctl show br-tun
查看网桥br-tun的流表：ovs-ofctl dump-flows br-tun
添加网桥：#ovs-vsctl add-br br0
将物理网卡挂接到网桥：#ovs-vsctl add-port br0 eth0
我们这片文章里面主要用到了以上五个个 ovs 命令。我们在提一下其它的一些命令。
列出 open vswitch 中的所有网桥：#ovs-vsctl list-br
判断网桥是否存在：#ovs-vsctl br-exists br0
列出网桥中的所有端口：#ovs-vsctl list-ports br0
列出所有挂接到网卡的网桥：#ovs-vsctl port-to-br eth0
删除网桥上已经挂接的网口：#vs-vsctl del-port br0 eth0
删除网桥：#ovs-vsctl del-br br0
数据包在br-int和br-tun上的流表在前面的章节，大致描述了一下数据包的流动情况，在这里再来看一下 br-int 和 br-tun 上的流表，具体来看下数据包的传递。
当从VM1(192.168.11.14)去pingVM2(192.168.12.9), 数据包首先流到compute1（10.11.1.115）的br-int上，让我们先看看compute1上的网络状态。
[root@test115 ~]# ovs-vsctl show
1799e6ea-b3b0-4581-b42e-e1bfd8a5d96d
Bridge br-ex
Port "eth0"
Interface "eth0"
Port br-ex
Interface br-ex
type: internal
Bridge br-tun
fail_mode: secure
Port "gre-0a0b0174"
Interface "gre-0a0b0174"
type: gre
options:{df_default="true",in_key=flow, local_ip="10.11.1.115",
out_key= flow, remote_ip="10.11.1.116"}
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a0b0172"
Interface "gre-0a0b0172"
type: gre
options:{df_default="true",in_key=flow, local_ip="10.11.1.115",
out_key= flow, remote_ip="10.11.1.114"}
Bridge "br-eth1"
Port "eth1"
Interface "eth1"
Port "phy-br-eth1"
Interface "phy-br-eth1"
type: patch
options: {peer="int-br-eth1"}
Port "br-eth1"
Interface "br-eth1"
type: internal
Bridge br-int
fail_mode: secure
Port "qr-43fad9d6-53"
tag: 1
Interface "qr-43fad9d6-53"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qr-c669122c-11"
tag: 2
Interface "qr-c669122c-11"
type: internal
Port br-int
Interface br-int
type: internal
Port "qvof76ecb29-5d"
tag: 2
Interface "qvof76ecb29-5d"
Port "int-br-eth1"
Interface "int-br-eth1"
type: patch
options: {peer="phy-br-eth1"}
ovs_version: "2.3.0"
[root@test114 neutron]# neutron port-list
+--------------------------------------+------+-------------------+-----------
---------------------------------------------------------------------------+
| id | name | mac_address | fixed_ips |
+--------------------------------------+------+-------------------+----------
----------------------------------------------------------------------------+
| 3086e492-b9b2-416a-9140-f01258c34dda | | fa:16:3e:e5:b9:08 | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.2"} |
| ed6b11e8-05ea-4024-8d83-b080984f084e | | fa:16:3e:b4:76:32 | {"subnet_id":
"ffd2c101-35e5-4758-ba75-43409e58adaf", "ip_address": "10.11.2.14"} |
| cf9fa480-7fd4-4e4b-b8cf-7f6c26cffb2d | | fa:16:3e:02:b7:c7 | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.13"} |
| f76ecb29-5d9d-41fe-ae70-098502fda347 | | fa:16:3e:17:6b:a7 | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.14"} |
| 2bbd30d4-86d4-4ccb-930a-edb7be55b740 | | fa:16:3e:2a:34:19 | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.9"} |
| 43fad9d6-53d3-4664-8fc1-defcfa21d78a | | fa:16:3e:a3:95:c2 | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.1"} |
| da445e04-ab74-409b-b5df-1f5e8f7aa955 | | fa:16:3e:42:25:42 | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.2"} |
| 76bfd868-976d-4483-8352-89e0522e213d | | fa:16:3e:d4:4d:ff | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.10"} |
| 20f66057-a825-422c-9dfe-5bfa09292251 | | fa:16:3e:ee:70:14 | {"subnet_id":
"ffd2c101-35e5-4758-ba75-43409e58adaf", "ip_address": "10.11.2.10"} |
| c669122c-115f-42d5-b107-d346193cdb82 | | fa:16:3e:cd:50:8d | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.1"} |
+--------------------------------------+------+----------------
从VM1的port信息里面我们得知，数据是从qvof76ecb29-5d口进入br-int的。我们再看看br-int上的数据包，从上面的port信息我们查看到了相应的MAC地址，知道数据包是从VM1的MAC发到它gateway的MAC上的。然后在namespace里面通过VM2的gateway端口转发出来。
标签：OVS,ibm,sce,流表,192.168,br,OpenStack,节点,DVR 来源： https://blog.51cto.com/u_15127681/2823180