DVR 原理解析及OpenStack中应用流表分析

最新推荐文章于 2024-05-11 10:17:43 发布
置顶 最新推荐文章于 2024-05-11 10:17:43 发布
阅读量4.6k 收藏 9
点赞数 4
分类专栏： OpenStack
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010305706/article/details/80678671
版权

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.DVR
DVR

16: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, Neutron 的 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) 去 ping VM2(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 端口转发出来。


[root@test115 ~]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=16439.298s, table=0, n_packets=476, n_bytes=46648, idle_age=8917, 
priority=2,in_port=31,dl_src=fa:16:3f:ec:09:21 actions=resubmit(,1)
 cookie=0x0, duration=16439.451s, table=0, n_packets=0, n_bytes=0, idle_age=16439, 
priority=4,in_port=30,dl_src=fa:16:3f:ec:09:21 actions=resubmit(,2)
 cookie=0x0, duration=16439.645s, table=0, n_packets=0, n_bytes=0, idle_age=16439, 
priority=2,in_port=31,dl_src=fa:16:3f:1a:cf:03 actions=resubmit(,1)
 cookie=0x0, duration=16439.802s, table=0, n_packets=0, n_bytes=0, idle_age=16439, 
priority=4,in_port=30,dl_src=fa:16:3f:1a:cf:03 actions=resubmit(,2)
 cookie=0x0, duration=16440.644s, table=0, n_packets=1074, n_bytes=104318, idle_age=8917, 
priority=1 actions=NORMAL
 cookie=0x0, duration=16440.570s, table=0, n_packets=612165, n_bytes=339552066, idle_age=0, 
priority=2,in_port=30 actions=drop
 cookie=0x0, duration=16440.800s, table=1, n_packets=0, n_bytes=0, idle_age=16440, 
priority=1 actions=drop
 cookie=0x0, duration=16431.564s, table=1, n_packets=476, n_bytes=46648, idle_age=8917, 
priority=4,dl_vlan=2,dl_dst=fa:16:3e:17:6b:a7 
actions=strip_vlan,mod_dl_src:fa:16:3e:cd:50:8d,output:27
 cookie=0x0, duration=16440.720s, table=2, n_packets=0, n_bytes=0, idle_age=16440, 
priority=1 actions=drop
 cookie=0x0, duration=16440.874s, table=23, n_packets=0, n_bytes=0, idle_age=16440, 
priority=0 actions=drop

VM1 要 ping 的是 VM2,它们是在不同的网段上。通过 namespace,使得 192.168.12.1 和 192.168.11.1 这两个 gateway 能够联通，就把不同的两个网段联通起来。


[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ifconfig -a
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10<host>
loop  txqueuelen 0  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
qr-43fad9d6-53: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.12.1  netmask 255.255.255.0  broadcast 192.168.12.255
inet6 fe80::f816:3eff:fea3:95c2  prefixlen 64  scopeid 0x20<link>
ether fa:16:3e:a3:95:c2  txqueuelen 0  (Ethernet)
RX packets 2  bytes 140 (140.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2644  bytes 141732 (138.4 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
qr-c669122c-11: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.11.1  netmask 255.255.255.0  broadcast 192.168.11.255
inet6 fe80::f816:3eff:fecd:508d  prefixlen 64  scopeid 0x20<link>
ether fa:16:3e:cd:50:8d  txqueuelen 0  (Ethernet)
RX packets 4091  bytes 395426 (386.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 3564  bytes 420291 (410.4 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

192.168.11.0/24 和 192.168.12.0/24 这两个网段的通信是分别通过qr-c669122c-11和qr-43fad9d6-53两个端口，因为 namespace 的存在，它们本身是能够通信的。

[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ip route list table main
192.168.11.0/24 dev qr-c669122c-11  proto kernel  scope link  src 192.168.11.1
192.168.12.0/24 dev qr-43fad9d6-53  proto kernel  scope link  src 192.168.12.1

在 compute1 节点的 namespace 上能够得到 192.168.12.9 的 MAC 地址及状态。并且在 compute2 节点的 namespace 上能够得到 192.168.11.14 的 MAC 地址及状态。这些都保证了两台 VM 的顺利通信。

[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ip nei
fe80::f4ce:f9ff:fe73:ef0d dev qr-c669122c-11 lladdr f6:ce:f9:73:ef:0d STALE
fe80::f816:3eff:fe17:6ba7 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 STALE
192.168.12.10 dev qr-43fad9d6-53 lladdr fa:16:3e:d4:4d:ff PERMANENT
192.168.11.14 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 PERMANENT
192.168.12.9 dev qr-43fad9d6-53 lladdr fa:16:3e:2a:34:19 PERMANENT
192.168.11.13 dev qr-c669122c-11 lladdr fa:16:3e:02:b7:c7 PERMANENT

数据包流入 br-int 之后，打上了 tag 2 标志,接着 patch-tun 把 br-int 接入隧道桥 br-tun,我们看到，patch-tun 和 patch-int 是对应的端口，我们通过查看 br-tun 上的端口情况得知数据流是从 port 8 进入 br-tun 的。

[root@test115 ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x2): dpid:00007e2d16238847
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST 
SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 8(patch-int): addr:f6:78:56:1e:33:fa
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
 9(gre-0a0b0172): addr:d6:4a:8e:14:bc:63
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
 10(gre-0a0b0174): addr:8a:c7:68:16:44:d8
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-tun): addr:7e:2d:16:23:88:47
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max

OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
首先注意一下，数据流在进入 br-tun 之前，数据包已经转化成了从 VM1 的 MAC ping 192.168.12.1 的 MAC。我们查看一下数据在 br-tun 上的流表。数据首先流入 table0，流入端口是 port 8。接着进入 table1,流入地址就是 192.168.12.1 的 MAC 地址，它转变成了 compute1 的 MAC 地址, 这个 MAC 地址我们可以从 db2 里面得到。接着进入 table2, 因为 ping 用的协议是 ICMP,所以这里定位粗体字的这条数据流。接着进入 table20,从上面的 port list 表中，我们可以看到，数据流最终指向 VM2(192.168.12.9), 数据包从隧道 set_tunnel:0x2, port 10 流出。

[

root@test115 ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=108352.425s, table=0, n_packets=0, n_bytes=0, idle_age=65534, 
hard_age=65534, priority=0 actions=drop
 cookie=0x0, duration=108343.696s, table=0, n_packets=476, n_bytes=46648, idle_age=65534,
 hard_age=65534, priority=1,in_port=10 actions=resubmit(,3)
 cookie=0x0, duration=108351.277s, table=0, n_packets=496, n_bytes=49088,
 idle_age=2304, hard_age=65534, priority=1,in_port=8 actions=resubmit(,1)
 cookie=0x0, duration=108344.223s, table=0, n_packets=6, n_bytes=1236, idle_age=2304,
 hard_age=65534, priority=1,in_port=9 actions=resubmit(,3)
 cookie=0x0, duration=108351.106s, table=1, n_packets=12, n_bytes=1680, idle_age=2304,
 hard_age=65534, priority=0 actions=resubmit(,2)
 cookie=0x0, duration=108345.552s, table=1, n_packets=476, n_bytes=46648
, idle_age=65534, hard_age=65534, priority=1,dl_vlan=1,dl_src=fa:16:3e:a3:95:c2
 actions=mod_dl_src:fa:16:3f:97:87:a1,resubmit(,2)
 cookie=0x0, duration=108342.096s, table=1, n_packets=1, n_bytes=130, idle_age=65534, 
hard_age=65534, priority=1,dl_vlan=2,dl_src=fa:16:3e:cd:50:8d actions=mod_dl_src:fa:16:3f:97:87:a1,
resubmit(,2)
 ... ...
 cookie=0x0, duration=108352.344s, table=2, n_packets=490, n_bytes=48556, 
idle_age=2304, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 
actions=resubmit(,20)
 ...  ...
 cookie=0x0, duration=108343.543s, table=20, n_packets=476, n_bytes=46648, idle_age=65534, 
hard_age=65534, priority=2,dl_vlan=1,dl_dst=fa:16:3e:2a:34:19 actions=strip_vlan,
set_tunnel:0x2,output:10

这里是查看 host 的 MAC 地址。

db2 => select * from DVR_HOST_MACS

HOST MAC_ADDRESS
---------------------------------------------------------------
test114.sce.ibm.com fa:16:3f:1a:cf:03
test115.sce.ibm.comfa:16:3f:97:87:a1
test116.sce.ibm.com fa:16:3f:ec:09:21

compute1 是通过 gre-0a0b0174 与 compute2 连接起来的

[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"}

下面数据包已经来到了 compute2, 我们先查看一下 compute2 上的网络情况，在 compute2 上,是通过gre-0a0b0173端口与 compute1 传递数据流的。

[root@test116 ~]# ovs-vsctl show
590e4ede-0e3c-43c8-ad1c-153c3a101f75
Bridge br-ex
Port "eth0"
Interface "eth0"
Port br-ex
Interface br-ex
type: internal
Bridge br-tun
fail_mode: secure
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a0b0173"
Interface "gre-0a0b0173"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.116", out_key=flow, 
remote_ip="10.11.1.115"}
Port "gre-0a0b0172"
Interface "gre-0a0b0172"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.116", out_key=flow,
 remote_ip="10.11.1.114"}
Port br-tun
Interface br-tun
type: internal

数据进入 compute2,先进入隧道桥 br-tun。我们再来查看一下 br-tun 上的端口，它是通过 port 14 传入 br-tun 的。

[root@test116 ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x2): dpid:00008eab3df3f342
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC 
SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 9(patch-int): addr:a2:3b:1e:29:77:9e
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
 13(gre-0a0b0172): addr:b6:e7:f7:3f:f6:80
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
 14(gre-0a0b0173): addr:02:2c:97:51:29:f7
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-tun): addr:8e:ab:3d:f3:f3:42
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

下面查看一下 br-tun 上面的流表

数据先流入 table0，流入端口是 port 14,接着数据转入 table3,在这里把隧道转成了 vlan 号,这里的 tunnel 就是在 compute1 上的转换的那个 tunnel 号，接着数据流入 table9, 在这条流上显示流入地址是 compute1 host 的 MAC 地址，数据从这里流进 br-int。

[root@test116 ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1670640.753s, table=0, n_packets=0, n_bytes=0, idle_age=65534, 
hard_age=65534, priority=0 actions=drop
 cookie=0x0, duration=353441.887s, table=0, n_packets=29, n_bytes=4904, idle_age=7824, 
hard_age=65534, priority=1,in_port=13 actions=resubmit(,3)
 cookie=0x0, duration=352506.309s, table=0, n_packets=2630, n_bytes=142843, 
idle_age=65534, hard_age=65534, priority=1,in_port=14 actions=resubmit(,3)
 ... ...
 cookie=0x0, duration=353442.719s, table=3, n_packets=2648, n_bytes=144638, idle_age=7824, 
hard_age=65534, priority=1,tun_id=0x2actions=mod_vlan_vid:3,resubmit(,9)
 .... ...
 cookie=0x0, duration=1670637.758s, table=9, n_packets=3003, n_bytes=179397, idle_age=65534, 
hard_age=65534, priority=1,dl_src=fa:16:3f:97:87:a1 actions=output:9
... ...

数据包流入 br-int 先进入的是 table0, 数据的流入地址是 compute1 host 的 MAC 地址。接着数据进入 table1, 到达 VM2 的 MAC,流入地址是 192.168.12.1 的 MAC 地址，完成了从 gateway 到 VM 的数据转发。至此数据包完成了从 VM1 到 VM2 的传递，仅仅在 compute 节点之间没有经过 network 节点。

[root@test116 ~]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1676015.888s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, 
priority=4,in_port=36,dl_src=fa:16:3f:1a:cf:03 actions=resubmit(,2)
 cookie=0x0, duration=1676015.270s, table=0, n_packets=3003, n_bytes=179397, idle_age=65534, 
hard_age=65534, priority=2,in_port=37,dl_src=fa:16:3f:97:87:a1 actions=resubmit(,1)
 ... ...
 cookie=0x0, duration=357883.384s, table=1, n_packets=531, n_bytes=52038, idle_age=65534, 
hard_age=65534, priority=4,dl_vlan=3,dl_dst=fa:16:3e:2a:34:19 
actions=strip_vlan,mod_dl_src:fa:16:3e:a3:95:c2,output:38
 cookie=0x0, duration=1676017.088s, table=2, n_packets=0, n_bytes=0, idle_age=65534, 
hard_age=65534, priority=1 actions=drop
 cookie=0x0, duration=1676017.264s, table=23, n_packets=0, n_bytes=0, idle_age=65534, 
hard_age=65534, priority=0 actions=drop

在 compute1 节点的 namespace 上能够得到 192.168.12.9 的 MAC 地址及状态。其实在 compute2 节点的 namespace 上能够得到 192.168.11.14 的 MAC 地址及状态。这些都保证了两台 VM 的能够顺利的通信。

[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ip nei
fe80::f4ce:f9ff:fe73:ef0d dev qr-c669122c-11 lladdr f6:ce:f9:73:ef:0d STALE
fe80::f816:3eff:fe17:6ba7 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 STALE
192.168.12.10 dev qr-43fad9d6-53 lladdr fa:16:3e:d4:4d:ff PERMANENT
192.168.11.14 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 PERMANENT
192.168.12.9 dev qr-43fad9d6-53 lladdr fa:16:3e:2a:34:19 PERMANENT
192.168.11.13 dev qr-c669122c-11 lladdr fa:16:3e:02:b7:c7 PERMANENT
peach_li
关注
  • 4
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
初探Openstack Neutron DVR
Liping Mao's Blog
09-10 1万+
本文简单介绍了一下Neutron L3 DVR这个feature。
OpenStack 工作流workflows使用原理详细介绍
09-30
主要介绍了OpenStack 工作流workflows使用原理详细介绍的相关资料,需要的朋友可以参考下
neutron DVR
weixin_33763244的博客
04-12 420
DVR 简介 DVR 提出的背景 在 Neutron 的网络环境中，跨子网的虚机通信是需要通过 Neutron 的路由器。这既包括不同子网的虚拟机之间的通信，又包括虚拟机与外网之间的通信。在 DVR 被提出之前， 由于 Neutron 的 legacy router 只会部署在网络节点上，因此会造成网络节点的流量过大，从而产生了两个问题，其一是网络节点将成为整个 Neutron 网络的瓶颈，其...
Openstack原理及应用
最新发布
2301_77300090的博客
05-11 2511
在Dashboard[Horizon]上申请一台云虚拟机流程：Network[Neutron]提供网络，Block Storage[Cinder]提供卷，image[Glance]提供操作系统镜像（image不存储镜像，只存镜像目录，镜像实际存储在Object Storage[Swift]），然后交由Compute[Nova]创建虚拟机。在这个过程中Identity[Keystone]为各个独立的服务提供认证、鉴权服务。核心功能是对卷的管理，允许对卷、卷的类型、卷的快照、卷备份进行操作。
理解 OpenStack 高可用（HA）（3）：Neutron 分布式虚拟路由（Neutron Distributed Virtual Routing）...
weixin_33971130的博客
08-17 323
本系列会分析OpenStack 的高可用性（HA）概念和解决方案： （1）OpenStack 高可用方案概述 （2）Neutron L3 Agent HA - VRRP （虚拟路由冗余协议） （3）Neutron L3 Agent HA - DVR （分布式虚机路由器） （4）Pacemaker 和 OpenStack Resource Agent （RA） （5）RabbitMQ HA...
neutron之DVR(distributed virtual router)学习笔记
madmanvswarrior的博客
01-03 5695
在传统未使用DVR的情况下，存在以下不足： 1.网络流量集中在网络节点，东西南北流向都要流过network节点再转发，增加network的负载； 2.流量全集中在network节点，容易造成单点故障； 3.在大规模扩展compute节点的时候，network的网络瓶颈愈发明显，即传统neutron难以适应扩展性需求； 总结起来就是：流量集中，单点故障，难以扩展 使用DVR后： 1.东西流量分流到每一个compute节点上，不再经过network节点； 2.在使用floating的情况下，南北流量也分流到
Neutron DVR
weixin_34114823的博客
06-30 118
分布式路由器 OpenStack 用户可能会发现，按照 Neutron 原先的设计，所有网络服务都在网络节点上进行，这意味着大量的流量和处理，给网络节点带来了很大的压力。这些处理的核心是路由器服务。任何需要跨子网的访问都需要路由器进行路由。为了降低网络节点的负载，同时提高可扩展性，OpenStack 自 Juno 版本开始正式引入了分布式路由（Distributed Virtual...
OpenStack高可用核心架构分析
02-26
摘要：对任何一个分布式系统，高可用HA都是最核心的设计目标之一，而OpenStack这样一个复杂系统，高可用更是涉及到多个层面，本文重点解析了OpenStack各层次的HA设计。【编者按】本文从OpenStack架构入手，剖析了...
Docker与OpenStack应用场景分析.docx
10-11
在本文中，我们将深入分析 Docker 和 OpenStack 的应用场景，讨论它们之间的关系，以及如何将它们组合使用，以实现更好的云计算体验。 Docker 背景 Docker 是 Solomon Hykes 创立的，它提供了一种轻量级的容器化...
Openstack组件实现原理—Keystone认证功能
02-24
Keystone实现始终围绕着Keystone所实现的功能来展开，所以在理解其实现之前，建议大家尝试通过安装Keystone这一个过程来感受Keystone在Openstack架构中所充当的角色。下面给出了Keystone-M的安装过程。Keystone安装...
neutron的dvr
吴业亮的专栏
04-21 927
作者：【吴业亮】博客：http://blog.csdn.net/wylfengyujianchengOpenStack 用户可能会发现，按照 Neutron 原先的设计，所有网络服务都在网络节点上进行，这意味着大量的流量和处理，给网络节点带来了很大的压力。这些处理的核心是路由器服务。任何需要跨子网的访问都需要路由器进行路由。很自然，能否让计算节点上也运行路由器服务？这个设计思路无疑是更为合理的，但具
Neutron的dvr模式下br-int桥二、三层流量泛洪问题分析.pptx
03-20
neutron的dvr模式下的br-int泛洪问题分析，提出修复方法，并验证通过。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
Net_Dvr_中文
04-04
Net_Dvr_中文-注意事项 首先，感谢您选用我公司最新产品。 在使用本监控卡之前，请详细阅读本说明书所涉及的相关事项，熟悉硬件、软件各部分的功能后，方能使用，以确保该系统为您发挥最佳功能。否则一切后果自负。 本说明书将向您详细阐述全实时“视频监控系统”的安装、操作、设置和网络使用方法。 本系统工作主机供电电压为220V±10%，如果在电压不稳或者干扰大的场合，请您选用优质稳压电源（即UPS），保证系统正常良好的工作状态。 本系统在安装、拆卸视频采集卡时，必须将主机处于完全断电状态，否则主板上残留的电压将损坏采集卡。 本系统可切换D1与CIF分辨率，切换分辨率设置后，在主界面必须关闭通道视频，重新打开通道视频，设置才能生效。 本系统主机工作于常温(-10±3℃～55±2℃)、清洁的环境,并且保持良好的通风状态。 本系统软件属于我公司专有产品，未经同意，请勿复制，否则影响机器稳定概不负责，并将通过有关法律渠道追究盗版责任。
最新版DvrClient.rar
03-12
监控录像机海思方案专用PC客户端，支持域名、IP、序列号，等添加远程本地摄像机
Neutron - DVR配置
weixin_34357887的博客
12-23 357
DVR介绍dvr是distributed virtual router的缩写，目的是为了解决openstack neutron部署的扩展问题，分发网络节点的流量负载到计算节点上。如果实例绑定了floating ip，外网流量直接从计算节点出去，不经过网络节点。对于那些没绑定floating ip的实例外网流量还是走snat，要经过网络节点。DVR配置这里说明一下，我的cont...
OpenStack DVR 原理深入分析
OpenInfra的博客
12-28 2249
一、DVR实验环境 一套vlan模式的openstack环境，interface_driver使用openvswitch，并在计算节点添加br-ex，用于计算节点虚拟机出外网。 二、DVR配置 1、控制节点 a、编辑/etc/neutron/neutron.conf [DEFAULT] router_distributed = True b、重启neutron-server服务 2...
Neutron DVR实现multi-host特性打通东西南北流量提前看(by quqi99)
热门推荐
技术并艺术着
03-07 1万+
作者：张华 发表于：2014-03-07 版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 (http://blog.csdn.net/quqi99 ) Legacy Routing and Distributed Router in Neutron 先温习下l3-agent原理：l3-agent节点为所有subnet创建内部网关...
OpenStack Neutron 中的 DVR 简介与 OVS 流表分析
llxx1234的博客
01-08 680
https://www.ibm.com/developerworks/cn/cloud/library/1509_xuwei_dvr/
Openstack Neutron DVR 分布式路由
bule_sky
11-14 2073
转载地址：https://yq.aliyun.com/ziliao/65778 1. 背景 没有使用DVR的场景： 从图中可以明显看到东西向和南北向的流量会集中到网络节点，这会使网络节点成为瓶颈。 如果启用DVR，如下图： 对于东西向的流量， 流量会直接在计算节点之间传递。 对于南北向的流量，如果有floating ip，流量就直
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值