openstack网络（neutron）模式之GRE的基本原理

原文链接：http://www.uml.org.cn/yunjisuan/201501124.asp

neutron网络目的是为OpenStack云更灵活的划分网络，在多租户的环境下提供给每个租户独立的网络环境。

neutron混合实施了第二层的VLAN和第三层的路由服务，它可为支持的网络提供防火墙，负载均衡以及IPSec VPN等扩展功能。

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

一、分析经典的三个节点的Havana的OpenStack中网络

图1：三节点opens网络

分为三个网络：

1、External Network/API Network，这个网络是链接外网的，无论是用户调用OpenStack的API，还是创建出来的虚拟机要访问外网，或者外网要ssh到虚拟机，都需要通过这个网络

2、Data Network，数据网络，虚拟机之间的数据传输通过这个网络来进行，比如一个虚拟机要连接到另一个虚拟机，虚拟机要连接虚拟路由都是通过这个网络来进行

3、Management Network，管理网络，OpenStack各个模块之间的交互，连接数据库，连接Message Queue都是通过这个网络来进行。

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

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

二、neutron三个节点简介

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

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

1.Controller节点：

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

2.Network节点：

neutron-l3-agent，用于创建和管理虚拟路由器，当neutron-server将路由器的数据结构创建好，neutron-l3-agent是做具体事情的，真正的调用命令行将虚拟路由器，路由表，namespace，iptables规则全部创建好。

neutron-dhcp-agent，用于创建和管理虚拟DHCP server，每个虚拟网络都会有一个DHCP server，这个DHCP server为这个虚拟网络里面的虚拟机提供IP。

neutron-openvswitch-plugin-agent，这个是用于创建L2的switch的，在Network节点上，Router和DHCP Server都会连接到二层的switch上。

3.Compute节点：

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

三、租户网络创建过程

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

图2：租户网络创建过程

结合上图说明给一个租户创建网络的流程：

1、为这个Tenant创建一个private network，不同的private network是需要通过VLAN tagging进行隔离的，互相之间广播（broadcast）不能到达，这里我们我们用的是GRE模式，也需要一个类似VLANID的东西，称为Segment ID

2、为private network创建一个subnet，subnet才是真正配置IP网段的地方，对于私网，我们常常用192.168.0.0/24这个网段

3、为这个Tenant创建一个Router,才能够访问外网

4、将private network连接到Router上

5、创建一个External Network

6、创建一个External Network的Subnet,这个外网逻辑上代表了我们数据中心的物理网络，通过这个物理网络，我们可以访问外网。因而PUBLIC_GATEWAY应该设为数据中心里面的Gateway，PUBLCI_RANGE也应该和数据中心的物理网络的CIDR一致，否则连不通。之所以设置PUBLIC_START和PUBLIC_END，是因为在数据中心中，不可能所有的IP地址都给OpenStack使用，另外的可能搭建了VMware Vcenter，可能有物理机，所以仅仅分配一个区间给OpenStack来用。

7、将Router连接到External Network

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

代码流程如下：

#!/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

四、GRE模式下网络细节

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

在compute节点上：

root@ComputeNode:~# ip addr 【显示所有接口的IP信息】

1: eth0: 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 16.158.167.255 scope global eth0 2: eth2: 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: 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: mtu 1500 qdisc noqueue state UNKNOWN link/ether d6:2a:96:12:4a:49 brd ff:ff:ff:ff:ff:ff 5: br-tun: mtu 1500 qdisc noqueue state UNKNOWN link/ether a2:ee:75:bd:af:4a brd ff:ff:ff:ff:ff:ff 6: qvof5da998c-82: 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: 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:~# ovs-vsctl show 【查看open vswitch网桥】

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 节点上：

root@NetworkNode:~# ip addr 【显示所有接口的IP信息】

1: eth0: 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: 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: 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: 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: 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: mtu 1500 qdisc noqueue state UNKNOWN link/ether 22:fe:f1:9b:29:4b brd ff:ff:ff:ff:ff:ff 7: br-tun: mtu 1500 qdisc noqueue state UNKNOWN link/ether c6:ea:94:ff:23:41 brd ff:ff:ff:ff:ff:ff

oot@NetworkNode:~# ip netns 【列出网络命名空间】

qrouter-b2510953-1ae4-4296-a628-1680735545ac qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b

oot@NetworkNode:~# ip netns exec qrouter-b2510953-1ae4-4296-a628-1680735545ac ip addr 【利用网络命名空间进行操作】

8: qg-97040ca3-2c: 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: 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:~# ip netns exec qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b ip addr 【利用网络命名空间进行操作】

9: tapde5739e1-95: 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:~# ovs-vsctl show 【查看open vswitch的网络状态】

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: 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: 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: mtu 1500 qdisc noqueue state UP link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff 16: qvo591d8cc4-df: 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: 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: 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的网卡桥接关系，便可以画出下面的图

图3：GRE网络

GRE网络原理：

假设虚拟机VM0网卡eth0有网络数据包向外网发送，那么数据会依次经过qbr Linux Bridge设备，qvb和qvo虚拟网络设备，到达OVS网桥br-int上，br-int将数据包attach到OVS网桥br-tun上，数据包再从compute节点OVS网桥的br-tun和network节点OVS网桥br-tun构成的GRE隧道穿过，交付到Network节点的OVS网桥br-int上；网络节点的br-int通过qr设备借助Linux命名空间qrouter连通到br-ex上的qg设备，将数据包交付到OVS网桥br-ex上，最后br-ex通过网络节点的外部武力端口eth1把数据包传送到外部路由器的网关。

五、通过例子理解GRE网络

openstack为什么要创建这么多的虚拟网卡？

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

下面通过一个非常容易理解的例子来逐步分析gre网络。

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

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

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

图4

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

图5：单节点的openstack的网络结构

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

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

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

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

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

六、GRE网络原理进一步理解

以下内容可对比图3来理解

（1）DHCP

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

（2）qbr

既然qbr和br-int都是网桥，为什么不直接连到br-int，还要通过qbr,qvb,qvo岂不是多余，为什么会有qbr呢？这是和security group的概念有关。简单说就是OVS网桥br-int没有设置iptables规则的功能，但openstack又要提供安全组服务，就借助了Linux bridge(qbr)的功能，虽然OVS的br-int和linux bridge (qbr)都是二层网桥，但是为了功能互补就同时出现了。具体了解，openstack中的security group开通哪些端口，屏蔽哪些端口是用iptables来实现的，然而br-int这些虚拟bridge都是openvswitch创建的，openstack的Kernel mode和netfilter的kernel mode不兼容。一个IP包进来要么走iptables规则进行处理，要么走openvswitch的规则进行处理，br-int上有很多openvswitch的规则，比如vlan tag等，所以iptables必须要另外建立一个linux bridge（qbr）来做，因而就有了qbr，在了解拓扑结构的时候，可以将qbr忽略，看到VM直接连接到br-int上就可以了。

（3）namespace

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

（4）OVS一体化网桥br-int

每个机器上都有了自己的br-int，但是对于虚拟机和虚拟router来说，它们仍然觉得自己连接到了一个大的L2的br-int上，通过这个br-int相互通信的，它们感受不到br-int下面的虚拟网卡br-tun。所以对于多节点结构，我们可以想象br-int是一个大的，横跨所有compute和network节点的二层switch，虚拟机之间的通信以及虚拟机和Router的通信，就像在一个寝室一样的。这是一种很重要的抽象思维，好像openstack环境中所有虚拟机都连接到了一个巨型的虚拟交换机上。

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

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

（5）OVS通道网桥br-tun

br-tun也是OVS创建的虚拟网桥，它是一个中间层，接收br-int的网络数据，然后在通过特定网络协议与各个节点的br-tun相连构成一个通道层。如果所有的br-int构成的抽象层定义为虚拟二层网络，那么所有的br-tun构成的抽象层边上虚拟三层网络了。

（6）网络数据包隔离

如果有不同的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上实现。