neutron的基本原理

落日映苍穹つ 2022-08-21 05:52 214阅读 0赞

neutron是openstack的一个重要模块，也是比较难以理解和debug的模块之一。

我这里安装如图安装了经典的三个节点的Havana的Openstack

[![openstack deployment][]][openstack deployment 1]

图1

分三个网络：

*  External Network/API Network，这个网络是连接外网的，无论是用户调用Openstack的API，还是创建出来的虚拟机要访问外网，或者外网要ssh到虚拟机，都需要通过这个网络
 *  Data Network，数据网络，虚拟机之间的数据传输通过这个网络来进行，比如一个虚拟机要连接另一个虚拟机，虚拟机要连接虚拟的路由都是通过这个网络来进行
 *  Management Network，管理网络，Openstack各个模块之间的交互，连接数据库，连接Message Queue都是通过这个网络来。

将这三个网络隔离，一方面是安全的原因，在虚拟机里面，无论采取什么手段，干扰的都紧紧是Data Network，都不可能访问到我的数据库，一方面是流量分离，Management Network的流量不是很大的，而且一般都会比较优雅的使用，而Data network和External Network就需要进行流量控制的策略。

我的这个网络结构有些奇怪，除了Controller节点是两张网卡之外，其他的都多了一张网卡连接到external network，这个网卡是用来做apt-get的，因为Compute Node按说是没有网卡连接到外网的，为了apt-get添加了eth0，Network Node虽然有一个网卡eth1是连接外网的，然而在neutron配置好之前，这个网卡通常是没有IP的，为了apt-get也添加了eth0，有人说可以通过添加route规则都通过Controller连接外网，但是对于初学的人，这个样比较容易操作。

neutron是用来创建虚拟网络的，所谓虚拟网络，就是虚拟机启动的时候会有一个虚拟网卡，虚拟网卡会连接到虚拟的switch上，虚拟的switch连接到虚拟的router上，虚拟的router最终和物理网卡联通，从而虚拟网络和物理网络联通起来。

neutron分成多个模块分布在三个节点上。

Controller节点：

*  neutron-server，用于接受API请求创建网络，子网，路由器等，然而创建的这些东西仅仅是一些数据结构在数据库里面

Network节点：

*  neutron-l3-agent，用于创建和管理虚拟路由器，当neutron-server将路由器的数据结构创建好，它是做具体的事情的，真正的调用命令行将虚拟路由器，路由表，namespace，iptables规则全部创建好
 *  neutron-dhcp-agent，用于创建和管理虚拟DHCP Server，每个虚拟网络都会有一个DHCP Server，这个DHCP Server为这个虚拟网络里面的虚拟机提供IP
 *  neutron-openvswith-plugin-agent，这个是用于创建虚拟的L2的switch的，在Network节点上，Router和DHCP Server都会连接到二层的switch上

Compute节点：

*  neutron-openvswith-plugin-agent，这个是用于创建虚拟的L2的switch的，在Compute节点上，虚拟机的网卡也是连接到二层的switch上

[![image][]][image 1]

图2

当我们搭建好了Openstack，然后创建好了tenant后，我们会为这个tenant创建一个网络。

\#!/bin/bash  
TENANT\_NAME="openstack"  
TENANT\_NETWORK\_NAME="openstack-net"  
TENANT\_SUBNET\_NAME="$\{TENANT\_NETWORK\_NAME\}-subnet"  
TENANT\_ROUTER\_NAME="openstack-router"  
FIXED\_RANGE="192.168.0.0/24"  
NETWORK\_GATEWAY="192.168.0.1"

PUBLIC\_GATEWAY="172.24.1.1"  
PUBLIC\_RANGE="172.24.1.0/24"  
PUBLIC\_START="172.24.1.100"  
PUBLIC\_END="172.24.1.200"

TENANT\_ID=$(keystone tenant-list | grep " $TENANT\_NAME " | awk '\{print $2\}')

(1) TENANT\_NET\_ID=$(neutron net-create --tenant\_id $TENANT\_ID $TENANT\_NETWORK\_NAME --provider:network\_type gre --provider:segmentation\_id 1 | grep " id " | awk '\{print $4\}')

(2) TENANT\_SUBNET\_ID=$(neutron subnet-create --tenant\_id $TENANT\_ID --ip\_version 4 --name $TENANT\_SUBNET\_NAME $TENANT\_NET\_ID $FIXED\_RANGE --gateway $NETWORK\_GATEWAY --dns\_nameservers list=true 8.8.8.8 | grep " id " | awk '\{print $4\}')

(3) ROUTER\_ID=$(neutron router-create --tenant\_id $TENANT\_ID $TENANT\_ROUTER\_NAME | grep " id " | awk '\{print $4\}')

(4) neutron router-interface-add $ROUTER\_ID $TENANT\_SUBNET\_ID

(5) neutron net-create public --router:external=True

(6) neutron subnet-create --ip\_version 4 --gateway $PUBLIC\_GATEWAY public $PUBLIC\_RANGE --allocation-pool start=$PUBLIC\_START,end=$PUBLIC\_END --disable-dhcp --name public-subnet

(7) neutron router-gateway-set $\{TENANT\_ROUTER\_NAME\} public

[![create network][]][create network 1]

图3

1.  为这个Tenant创建一个private network，不同的private network是需要通过VLAN tagging进行隔离的，互相之间broadcast不能到达，这里我们用的是GRE模式，也需要一个类似VLAN ID的东西，称为Segment ID
2.  创建一个private network的subnet，subnet才是真正配置IP网段的地方，对于私网，我们常常用192.168.0.0/24这个网段
3.  为这个Tenant创建一个Router，才能够访问外网
4.  将private network连接到Router上
5.  创建一个External Network
6.  创建一个Exernal Network的Subnet，这个外网逻辑上代表了我们数据中心的物理网络，通过这个物理网络，我们可以访问外网。因而PUBLIC\_GATEWAY应该设为数据中心里面的Gateway， PUBLIC\_RANGE也应该和数据中心的物理网络的CIDR一致，否则连不通，而之所以设置PUBLIC\_START和PUBLIC\_END，是因为在数据中心中，不可能所有的IP地址都给Openstack使用，另外可能搭建了VMware Vcenter，可能有物理机器，仅仅分配一个区间给Openstack来用。
7.  将Router连接到External Network

经过这个流程，从虚拟网络，到物理网络就逻辑上联通了。

创建完毕网络，如果不创建虚拟机，我们还是发现neutron的agent还是做了很多工作的，创建了很多的虚拟网卡和switch

在Compute节点上：

[root@ComputeNode][root_ComputeNode]:~\# ip addr  
1: eth0: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:49:5c:41 brd ff:ff:ff:ff:ff:ff  
inet 172.24.1.124/22 brd 172.24.1.255 scope global eth0  
2: eth2: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:8e:42:2c brd ff:ff:ff:ff:ff:ff  
inet 192.168.56.124/24 brd 192.168.56.255 scope global eth2  
3: eth3: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:68:92:ce brd ff:ff:ff:ff:ff:ff  
inet 10.10.10.124/24 brd 10.10.10.255 scope global eth3  
4: br-int: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether d6:2a:96:12:4a:49 brd ff:ff:ff:ff:ff:ff  
5: br-tun: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether a2:ee:75:bd:af:4a brd ff:ff:ff:ff:ff:ff  
6: qvof5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether c2:7e:50:de:8c:c5 brd ff:ff:ff:ff:ff:ff  
7: qvbf5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether c2:33:73:40:8f:e0 brd ff:ff:ff:ff:ff:ff

[root@ComputeNode][root_ComputeNode]:~\# ovs-vsctl show  
39f69272-17d4-42bf-9020-eecc9fe8cde6  
Bridge br-int  
Port patch-tun  
Interface patch-tun  
type: patch  
options: \{peer=patch-int\}  
Port br-int  
Interface br-int  
type: internal  
Bridge br-tun  
Port patch-int  
Interface patch-int  
type: patch  
options: \{peer=patch-tun\}  
Port "gre-1"  
Interface "gre-1"  
type: gre  
options: \{in\_key=flow, local\_ip="10.10.10.124", out\_key=flow, remote\_ip="10.10.10.121"\}  
Port br-tun  
Interface br-tun  
type: internal  
ovs\_version: "1.10.2"

在Network Node上：

[root@NetworkNode][root_NetworkNode]:~\# ip addr  
1: eth0: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:22:8a:7a brd ff:ff:ff:ff:ff:ff  
inet 172.24.1.121/22 brd 172.24.1.255 scope global eth0  
2: eth1: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:f1:31:81 brd ff:ff:ff:ff:ff:ff  
3: eth2: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:56:7b:8a brd ff:ff:ff:ff:ff:ff  
inet 192.168.56.121/24 brd 192.168.56.255 scope global eth2  
4: eth3: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether 08:00:27:26:bc:84 brd ff:ff:ff:ff:ff:ff  
inet 10.10.10.121/24 brd 10.10.10.255 scope global eth3  
5: br-ex: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether 08:00:27:f1:31:81 brd ff:ff:ff:ff:ff:ff  
inet 172.24.1.8/24 brd 172.24.1.255 scope global br-ex  
6: br-int: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether 22:fe:f1:9b:29:4b brd ff:ff:ff:ff:ff:ff  
7: br-tun: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether c6:ea:94:ff:23:41 brd ff:ff:ff:ff:ff:ff

[root@NetworkNode][root_NetworkNode]:~\# ip netns  
qrouter-b2510953-1ae4-4296-a628-1680735545ac  
qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b

[root@NetworkNode][root_NetworkNode]:~\# ip netns exec qrouter-b2510953-1ae4-4296-a628-1680735545ac ip addr  
8: qg-97040ca3-2c: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether fa:16:3e:26:57:e3 brd ff:ff:ff:ff:ff:ff  
inet 172.24.1.100/24 brd 172.24.1.255 scope global qg-97040ca3-2c  
11: qr-e8b97930-ac: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether fa:16:3e:43:ef:16 brd ff:ff:ff:ff:ff:ff  
inet 192.168.0.1/24 brd 192.168.0.255 scope global qr-e8b97930-ac

[root@NetworkNode][root_NetworkNode]:~\# ip netns exec qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b ip addr  
9: tapde5739e1-95: <BROADCAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UNKNOWN  
link/ether fa:16:3e:19:8c:67 brd ff:ff:ff:ff:ff:ff  
inet 192.168.0.2/24 brd 192.168.0.255 scope global tapde5739e1-95  
inet 169.254.169.254/16 brd 169.254.255.255 scope global tapde5739e1-95

[root@NetworkNode][root_NetworkNode]:~\# ovs-vsctl show  
d5d5847e-1c9e-4770-a68c-7a695b7b95cd  
Bridge br-ex  
Port "qg-97040ca3-2c"  
Interface "qg-97040ca3-2c"  
type: internal  
Port "eth1"  
Interface "eth1"  
Port br-ex  
Interface br-ex  
type: internal  
Bridge br-int  
Port patch-tun  
Interface patch-tun  
type: patch  
options: \{peer=patch-int\}  
Port "tapde5739e1-95"  
tag: 1  
Interface "tapde5739e1-95"  
type: internal  
Port br-int  
Interface br-int  
type: internal  
Port "qr-e8b97930-ac"  
tag: 1  
Interface "qr-e8b97930-ac"  
type: internal  
Bridge br-tun  
Port patch-int  
Interface patch-int  
type: patch  
options: \{peer=patch-tun\}  
Port "gre-2"  
Interface "gre-2"  
type: gre  
options: \{in\_key=flow, local\_ip="10.10.10.121", out\_key=flow, remote\_ip="10.10.10.124"\}  
Port br-tun  
Interface br-tun  
type: internal  
ovs\_version: "1.10.2"

这时候如果我们创建一个虚拟机在这个网络里面，在Compute Node多了下面的网卡：

13: qvof5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether c2:7e:50:de:8c:c5 brd ff:ff:ff:ff:ff:ff  
14: qvbf5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether c2:33:73:40:8f:e0 brd ff:ff:ff:ff:ff:ff  
15: qbr591d8cc4-df: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc noqueue state UP  
link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff  
16: qvo591d8cc4-df: <BROADCAST,MULTICAST,PROMISC,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast state UP qlen 1000  
link/ether e2:58:d4:dc:b5:16 brd ff:ff:ff:ff:ff:ff  
17: qvb591d8cc4-df: <BROADCAST,MULTICAST,PROMISC,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast master qbr591d8cc4-df state UP qlen 1000  
link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff  
18: tap591d8cc4-df: <BROADCAST,MULTICAST,UP,LOWER\_UP> mtu 1500 qdisc pfifo\_fast master qbr591d8cc4-df state UNKNOWN qlen 500  
link/ether fe:16:3e:6e:ba:d0 brd ff:ff:ff:ff:ff:ff

如果我们按照ovs-vsctl show的网卡桥接关系，变可以画出下面的图

[![gre tunnel][]][gre tunnel 1]

图4

当然如果你配的不是GRE而是VLAN的话，便有下面这个著名的复杂的图。

在network Node上：

[![under-the-hood-scenario-1-ovs-network][]][under-the-hood-scenario-1-ovs-network 1]

图5

在Compute Node上：

[![under-the-hood-scenario-1-ovs-compute][]][under-the-hood-scenario-1-ovs-compute 1]

图6

当看到这里，很多人脑袋就大了，openstack为什么要创建这么多的虚拟网卡，他们之间什么关系，这些dl\_vlan, mod\_vlan\_vid都是什么东东啊？

这些网卡看起来复杂，却是各有用处，这种虚拟网络拓扑，正是我们经常使用的物理网络的拓扑结构。

我们先来回到一个最最熟悉不过的场景，我们的大学寝室，当时我们还买不起路由器，所以一般采取的方法如下图所示：

寝室长的机器上弄两张网卡，寝室买一个HUB，其他人的电脑都接到HUB上，寝室长的电脑的两张网卡一张对外连接网络，一张对内连接HUB。寝室长的电脑其实充当的便是路由器的作用。

后来条件好了，路由器也便宜了，所以很多家庭也是类似的拓扑结构，只不过将Computer1和switch合起来，变成了一个路由器，路由器也是有多个口一个连接WLAN，一个连接LAN。

[![qinshi][]][qinshi 1]

图7

现在我们想象一个寝室变成了一台物理机Hypervisor，所有的电脑都变成了虚拟机，就成了下面的样子。

[![single node][]][single node 1]

图8

我们先忽略qbr和DHCP Server，以及namespace。

br-int就是寝室里面的HUB，所有虚拟机都会连接到这个switch上，虚拟机之间的相互通信就是通过br-int来的。

Router就是你们寝室长的电脑，一边接在br-int上，一边接在对外的网口上，br-ex/eth0外面就是我们的物理网络。

为什么会有个DHCP Server呢，是同一个private network里的虚拟机得到IP都是通过这个DHCP Server来的，这个DHCP Server也是连接到br-int上和虚拟机进行通信。

为什么会有qbr呢，这是和security group的概念有关，openstack中的security group开通哪些端口，屏蔽哪些端口是用iptables来实现的，然而br-int这些虚拟bridge都是openvswitch创建的，openvswitch的kernel mode和netfilter的kernel mode不兼容，一个IP包进来要么走iptables的规则进行处理，要么走openvswitch的规则进行处理，通过上面的复杂的图我们可以看到，br-int上面有很多openvswitch的规则，比如vlan tag等，所以iptables必须要另外建立一个linux bridge来做，因而有了qbr，在了解拓扑结构的时候，可以将qbr忽略，看成VM直接连接到br-int上就可以了。

为什么会有namespace呢，java的namespace是为了相同的类名，不同的namespace，显然是不同的类。openstack也想做到这一点，不同的tenant都想创建自己的router和private network，彼此不知道别人指定了哪些网段，很有可能两个tenant都指定了192.168.0.0/24，这样不同的private network的路由表，DHCP Server就需要隔离，不然就乱了，因而有了namespace。

上面的图其实就是单节点的openstack的网络结构，虽然复杂，但是就是把我们家里的，或者寝室里面的物理机搬到一个Hypervisor上了，其结构就不难理解了。

当然单节点的openstack不过是个测试环境，compute节点和network节点也是要分开的，如图4，每个机器上都有了自己的br-int。

但是对于虚拟机和虚拟Router来讲，他们仍然觉得他们是连接到了一个大的L2的br-int上，通过这个br-int相互通信的，他们感受不到br-int下面的虚拟网卡br-tun。所以对于多节点结构，我们可以想象br-int是一个大的，横跨所有的compute和network节点的二层switch，虚拟机之间的通信以及虚拟机和Router的通信，就像在一个寝室一样的。

然而br-int毕竟被物理的割开了，需要有一种方式将他们串联起来，openstack提供了多种方式，图4中是用GRE tunnel将不同机器的br-int连接起来，图5图6是通过VLAN将br-int连接起来，当然还可以使用vxlan。

这就是为什么openstack有了br-int这个bridge，但是不把所有的openvswitch的规则都在它上面实现。就是为了提供这种灵活性，对于虚拟机来讲，看到的是一大整个br-int，不同机器的br-int可以有多种方式连接，这在br-int下面的网卡上面实现。

如果有不同的Tenant，创建了不同的private network，为了在data network上对包进行隔离，创建private network的时候，需要指定vlanid或者segmentid。

从ovs-vsctl show我们可以看到，不同的tenant的private network上创建的虚拟机，连接到br-int上的时候是带tag的，所以不同tenant的虚拟机，即便连接到同一个br-int上，因为tag不同，也是不能相互通信的，然而同一个机器上的tag的计数是仅在本机有效的，并不使用我们创建private network的时候指定的全局唯一的vlanid或者segmentid，一个compute节点上的br-int上的tag 1和另一台compute节点上的br-int的tag1很可能是两码事。全局的vlanid和segmentid仅仅在br-int以下的虚拟网卡和物理网络中使用，虚拟机所有能看到的东西，到br-int为止，看不到打通br-int所要使用的vlanid和segmentid。

从局部有效的taging到全局有效的vlanid或者segmentid的转换，都是通过openvswitch的规则，在br-tun或者br-eth1上实现。

我们可以用下面的命令看一下这个规则:

在Compute节点上：

private network “openstack-net”的tag在这台机器上是2，而我们创建的时候的segmentid设定的是1

Bridge br-int  
Port patch-tun  
Interface patch-tun  
type: patch  
options: \{peer=patch-int\}  
Port br-int  
Interface br-int  
type: internal  
Port "qvo591d8cc4-df"  
**tag: 2**  
Interface "qvo591d8cc4-df"

root@ComputeNodeCliu8:~\# ovs-ofctl dump-flows br-tun  
NXST\_FLOW reply (xid=0x4):

**//in\_port=1是指包是从patch-int，也即是从虚拟机来的，所以是发送规则，跳转到table1**  
cookie=0x0, duration=77419.191s, table=0, n\_packets=22, n\_bytes=2136, idle\_age=6862, hard\_age=65534, priority=1,in\_port=1 actions=resubmit(,1)

**//in\_port=2是指包是从GRE来的，也即是从物理网络来的，所以是接收规则，跳转到table2**  
cookie=0x0, duration=77402.19s, table=0, n\_packets=3, n\_bytes=778, idle\_age=6867, hard\_age=65534, priority=1,in\_port=2 actions=resubmit(,2)  
cookie=0x0, duration=77418.403s, table=0, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

**//multicast，跳转到table21**  
cookie=0x0, duration=77416.63s, table=1, n\_packets=21, n\_bytes=2094, idle\_age=6862, hard\_age=65534, priority=0,dl\_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21)

**//broadcast，跳转到table 20**  
cookie=0x0, duration=77417.389s, table=1, n\_packets=1, n\_bytes=42, idle\_age=6867, hard\_age=65534, priority=0,dl\_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)

**//这是接收规则的延续，如果接收的tun\_id=0x1则转换为本地的tag，mod\_vlan\_vid:2，跳转到table 10  
cookie=0x0, duration=6882.254s, table=2, n\_packets=3, n\_bytes=778, idle\_age=6867, priority=1,tun\_id=0x1 actions=mod\_vlan\_vid:2,resubmit(,10)**

cookie=0x0, duration=77415.638s, table=2, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

cookie=0x0, duration=77414.432s, table=3, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

cookie=0x0, duration=77412.825s, table=10, n\_packets=3, n\_bytes=778, idle\_age=6867, hard\_age=65534, priority=1 actions=learn(table=20,hard\_timeout=300,priority=1,NXM\_OF\_VLAN\_TCI\[0..11\],NXM\_OF\_ETH\_DST\[\]=NXM\_OF\_ETH\_SRC\[\],load:0->NXM\_OF\_VLAN\_TCI\[\],load:NXM\_NX\_TUN\_ID\[\]->NXM\_NX\_TUN\_ID\[\],output:NXM\_OF\_IN\_PORT\[\]),output:1

cookie=0x0, duration=77411.549s, table=20, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=resubmit(,21)

**//这是发送规则的延续，如果接收到的dl\_vlan=2，则转换为物理网络的segmentid=1，set\_tunnel:0x1  
cookie=0x0, duration=6883.119s, table=21, n\_packets=10, n\_bytes=1264, idle\_age=6862, priority=1,dl\_vlan=2 actions=strip\_vlan,set\_tunnel:0x1,output:2**

cookie=0x0, duration=77410.56s, table=21, n\_packets=11, n\_bytes=830, idle\_age=6885, hard\_age=65534, priority=0 actions=drop

在Network节点上：

Bridge br-int  
Port patch-tun  
Interface patch-tun  
type: patch  
options: \{peer=patch-int\}  
Port "tapde5739e1-95"  
**tag: 1**  
Interface "tapde5739e1-95"  
type: internal  
Port br-int  
Interface br-int  
type: internal  
Port "qr-e8b97930-ac"  
**tag: 1**  
Interface "qr-e8b97930-ac"  
type: internal

非常相似的规则。

root@NetworkNodeCliu8:~\# ovs-ofctl dump-flows br-tun  
NXST\_FLOW reply (xid=0x4):

**//in\_port=1是指包是从patch-int，也即是从虚拟机来的，所以是发送规则，跳转到table1**  
cookie=0x0, duration=73932.142s, table=0, n\_packets=12, n\_bytes=1476, idle\_age=3380, hard\_age=65534, priority=1,in\_port=1 actions=resubmit(,1)

**//in\_port=2是指包是从GRE来的，也即是从物理网络来的，所以是接收规则，跳转到table2**  
cookie=0x0, duration=73914.323s, table=0, n\_packets=9, n\_bytes=1166, idle\_age=3376, hard\_age=65534, priority=1,in\_port=2 actions=resubmit(,2)

cookie=0x0, duration=73930.934s, table=0, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

**//multicast，跳转到table21**  
cookie=0x0, duration=73928.59s, table=1, n\_packets=6, n\_bytes=468, idle\_age=65534, hard\_age=65534, priority=0,dl\_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21)

**//broadcast，跳转到table20**  
cookie=0x0, duration=73929.695s, table=1, n\_packets=3, n\_bytes=778, idle\_age=3380, hard\_age=65534, priority=0,dl\_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)

**//这是接收规则的延续，如果接收的tun\_id=0x1则转换为本地的tag，mod\_vlan\_vid:1，跳转到table 10  
cookie=0x0, duration=73906.864s, table=2, n\_packets=9, n\_bytes=1166, idle\_age=3376, hard\_age=65534, priority=1,tun\_id=0x1 actions=mod\_vlan\_vid:1,resubmit(,10)**

cookie=0x0, duration=73927.542s, table=2, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

cookie=0x0, duration=73926.403s, table=3, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

cookie=0x0, duration=73925.611s, table=10, n\_packets=9, n\_bytes=1166, idle\_age=3376, hard\_age=65534, priority=1 actions=learn(table=20,hard\_timeout=300,priority=1,NXM\_OF\_VLAN\_TCI\[0..11\],NXM\_OF\_ETH\_DST\[\]=NXM\_OF\_ETH\_SRC\[\],load:0->NXM\_OF\_VLAN\_TCI\[\],load:NXM\_NX\_TUN\_ID\[\]->NXM\_NX\_TUN\_ID\[\],output:NXM\_OF\_IN\_PORT\[\]),output:1

cookie=0x0, duration=73924.858s, table=20, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=0 actions=resubmit(,21)

**//这是发送规则的延续，如果接收到的dl\_vlan=1，则转换为物理网络的segmentid=1，set\_tunnel:0x1  
cookie=0x0, duration=73907.657s, table=21, n\_packets=0, n\_bytes=0, idle\_age=65534, hard\_age=65534, priority=1,dl\_vlan=1 actions=strip\_vlan,set\_tunnel:0x1,output:2**

cookie=0x0, duration=73924.117s, table=21, n\_packets=6, n\_bytes=468, idle\_age=65534, hard\_age=65534, priority=0 actions=drop

原文：http://www.kuqin.com/shuoit/20140525/340126.html

[openstack deployment]: http://img.kuqin.com/upimg/allimg/140525/113053D91-0.png
[openstack deployment 1]: http://images.cnitblog.com/blog/103165/201405/231722080901421.png
[image]: http://img.kuqin.com/upimg/allimg/140525/1130532H4-1.png
[image 1]: http://images.cnitblog.com/blog/103165/201405/231722098878605.png
[create network]: http://img.kuqin.com/upimg/allimg/140525/1130531N4-2.png
[create network 1]: http://images.cnitblog.com/blog/103165/201405/231722122938203.png
[root_ComputeNode]: mailto:root@ComputeNode
[root_NetworkNode]: mailto:root@NetworkNode
[gre tunnel]: http://img.kuqin.com/upimg/allimg/140525/1130532111-3.png
[gre tunnel 1]: http://images.cnitblog.com/blog/103165/201405/231722136379459.png
[under-the-hood-scenario-1-ovs-network]: http://img.kuqin.com/upimg/allimg/140525/1130535009-4.png
[under-the-hood-scenario-1-ovs-network 1]: http://images.cnitblog.com/blog/103165/201405/231722161528556.png
[under-the-hood-scenario-1-ovs-compute]: http://img.kuqin.com/upimg/allimg/140525/11305334V-5.png
[under-the-hood-scenario-1-ovs-compute 1]: http://images.cnitblog.com/blog/103165/201405/231722206682011.png
[qinshi]: http://img.kuqin.com/upimg/allimg/140525/1130536093-6.png
[qinshi 1]: http://images.cnitblog.com/blog/103165/201405/231722230741609.png
[single node]: http://img.kuqin.com/upimg/allimg/140525/1130536417-7.png
[single node 1]: http://images.cnitblog.com/blog/103165/201405/231722240596909.png