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分成多个模块分布在三个节点上。
Controller节点：
neutron-server，用于接受API请求创建网络，子网，路由器等，然而创建的这些东西仅仅是一些数据结构在数据库里面
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上。
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
Portpatch-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
root@NetworkNode:~#ip netns 【列出网络命名空间】
qrouter-b2510953-1ae4-4296-a628-1680735545ac
qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b
root@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
Portpatch-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有网络数据包向外网发送，那么数据会依次经过qbrLinux 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上实现。
本文参考下文并做修改方便自己理解：
