neutron浅析-1
openstack环境如何使用neutron？
neutron是openstack管理网络的模块，horizon中创建一个网络之后，horizon会通过RESTAPI将请求发送给neutron。/etc/init.d/neutron-server接受这个请求，并将请求处理之后转发相应的plugin。
plugin有些可以自己处理这些请求，例如L3-agent，就是分配IP地址。有些plugin需要通过远端的Agent处理，例如L2或者firewall。plugin与agent之间的通信是jsonrpc。
Agent可以部署在网络节点，包括网络路径与VM。有些VM在网络底层使用的是OVS，网络路径上的节点可使很多不仅包括OVS。
horizon与neutron-server具体如何工作？
horizon类似于web-ovs的前端，neutron-server类似于web-ovs的后端，plugin类似于model文件夹，agent就是特工。horizon那边后面有机会在分析。可以从neutron-server那边看出来他能接受哪些RESTAPI，在（http://developer.openstack.org/api-ref-networking-v2.html）中显示了北向接口的API，这里列出了horizon所有的RESTAPI吧，不仅包括neutron。看到与web-ovs中定义的基本类似，上述API可以分为几类。
neutron-server接受RESTAPI，并通过plugin实现，有些需要下发给agent，有些不用。需要下发给特工的是通过jsonrpc下发配置实现的，类似于NSX控制器下发的配置。
L2-network RESTAPI有哪些功能？
与NSX控制器控制vxlan功能类似，上层都是通过控制DB内容实现配置，vxlan中并没有add flow，所以这里应该也不会下发flow。类比NSX控制器下发的配置，创建logical switch时候并没有太多的配置下发下去，而是绑定到VM的port的时候才是将大多数配置下发下去，可以参看NSX-integration。另外从JSON request中看出，RESTAPI也就是web界面只是发出请求，并不表明自己的具体请求，例如L3network中的请求中只有CIDR，而L2网络只有一个网络名称以及状态。
Neutron如何部署？
上图是Neutron的典型网络，其中internet是指外网，External Network是指外网直接访问Network Node。API Network是指通过REST API访问neutron server。Management Network是指neutron server通过RPC访问Agent。Data Network是指各个Compute节点间是传送与处理数据的网络，Network Node只是用于构建网络，将Compute Node组成不同的网络，例如私有网络。
Cloud Controller Node，就是Controller Node的集合，Cloud主要是灾备或者负载均衡，我们做的Controller也支持灾备（一般是主从模式灾备）。这里的Controller主要指neutron server，用于接收REST API的请求（http://developer.openstack.org/api-ref-networking-v2.html），例如创建网络（L2）、创建子网（L3）、创建路由器（主要用于L3网络的路由）、数据库操作（主要是将网络ID等内容写入数据库）。其中具体模块见后面分析。
Network Node，是处理网络相关请求的Agent的集合，网络请求由neutron server通过RPC下发。如上图，其中l3-agent用于处理路由相关操作（增删查改），例如虚拟路由器（虚拟路由实例，与xorplus中虚拟路由一样）、路由表（虚拟路由的路由表）、namespace（是指linux虚拟路由的命名空间，可以看mininet了解）、iptable规则（主要用于类似ACL的功能，另外NAT功能是否是这个实现的还要再看）。neutron-dhcp-agent用于创建于管理虚拟DHCP服务器，功能与DHCP一样，提供动态IP、发送接收dnsmasg、扩展一点功能是将MAC/IP地址写入公用的数据库，对于一些异常（例如下发的IP的机器挂了）其处理方式主要通过数据库操作，这些异常的处理后面详述。neutron-openvswitch-plugin-agent用于创建L2 switch，注意这个L2 switch存在于Data Network而不是Management Network（这个不保证正确性），虚拟路由会有一个interface连接到L2 switch，dhcp也会有一个interface连接到L2 switch，Compute Node's通过这两个interface与路由器和dhcp服务器通信。
Compute节点，主要用于处理计算请求，与网络关系不大，但是需要特定的网络功能。在Compute节点上也存在neutron-openvswitch-plugin-agent，用于创建L2 switch及其操作。后面讲述的多种网络结构都需要这里的L2 switch帮助，其操作就是openvswitch的操作（包括interface、flow、tunnel等），不过有些人用linux bridge或者其他专用的L2设备，就需要这些设备的agent。
Neutron网络有哪些类型？
Neutron网络的目的就是为Compute Node提供不同类型的网络，使得Compute Node之间不同机器互联，这是SDN的一个应用。传统网络互联的对象是物理机器，互联方式主要有L2连接、L3连接（包括VRF）、tunnel连接（包括VPN），类似的Neutron网络类型主要有五种。
VLAN Network：使用VLAN进行隔离的L2网络。
local network：不进行隔离的网络，使用路由访问。
Flat网络：不适用隔离的网络。
GRE network：使用GRE作为VPN的网络。
vxlan network：使用vxlan作为VPN的网络。
以VLAN模式为例介绍neutron虚拟网络？
在传统网络中，VLAN也是一种L2隔离的方法，主要用于运营商网络。如上图是neutron配置之后的网络拓扑，其中br-int用于内部网络，另外还有一个称为br-eth1的用于指向到eth1的网络，具体构造下一段详述。配置好网络之后，VM间的报文在经过Hypervisor时候进行push或者pop vlan操作（类比tunnel操作，加一个tunnel port然后加一条从tunnel port出去的flow，vlan操作只需要添加flow即可）。在外部网络使用VLAN报文进行传输，这些隔离的信息只有neutron掌握，存储在数据库。
如下图是配置之后，Compute节点上L2 switch的详细配置图。其中vm上的interface的配置通过Nove Compute配置，在vlan模式中，vm发出的报文也是带vlan-tag的，这样一是为了同一个hypervisor中的vlan隔离，也是方便br中通过vlan-mapping解决如何assign vlan tag的问题。vm中的这些功能通过TAP设备（linux内核功能）实现，L2 switch使用linux bridge，与ovs连接端口使用veth pair，注意的是无论TAP、linux bridge、ovs都是虚拟的软件设备。
br-int意思是internal bridge，用于内部网络VM之间的连接，在ovs中使用normal模式，意味着在没有flow的情况下做L2 switch 动作，所以VM间的互相访问通过FDB解决（注意normal模式的ovs同样关心vlan，同不同L2 switch行为一样，应该是IVL），这时vm（也称为tenant）间的访问隔离通过vm自带的vlan tag实现。
br-eth1是专门用于处理访问eth1物理端口的L2 switch，mod vlan的动作就是在这个switch中做（如何做参考上面所述），其中添加的flow通过L2 Agent下发，这时tenant间的访问隔离通过L2 Agent下发的flow决定，也就是openstack的用户决定。
在neutron的配置文件中，有如下几个关键配置：
CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=vlan，指定网络模式为vlan
CONFIG_NEUTRON_OVS_VLAN_RANGES=physnet1:100:200，设置vlan ID value为100~200
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1，设置将br-int映射到桥br-eth1（会自动创建phy-br-eth1和int-br-eth1来连接br-int和br-eth1）
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-eth1:eth1，设置eth0桥接到br-eth1上，即最后的网络流量从eth1流出 (会自动执行ovs-vsctl add br-eth1 eth1)
VLAN模式下内部vm如何访问外网？
如上图所示，br-ex用于外网的访问，br-eth1用于内网的访问。数据包从内网进入br-int时候做内部vlan mod，在br-int中，如果包最后决定还是内网，再做内部vlan mod回内网，如上节所述。如果这个包需要送外网，那么需要先做NAT，在送往br-ex，通过br-ex的eth0发出去。
L3 Agent负责NAT表的配置，通过iptables实现。qg-VVV、qr-YYY、qr-ZZZ这些internal-port 连接到NAT表中（也就是机器的内部协议栈，根据IP决定如何做NAT），这三个internal-port只是用于将数据包送到协议栈，自己不会做任何封装等操作。
另外这里也分析一下dns功能，在br-int上面通过TAP interface连接到dhcp-agent上，dhcp-server发来的dnsmesq需要TAP端口push vlan后发送到br-int中，这样不同dhcp-server就属于不同的subnet。
vm间跨子网如何通信？
vm间的通信主要分为同一个subnet中的通信（同一物理机或者不同物理机）、跨subnet通信、访问外网。同一物理机中同一subnet下通信在物理机的br-int中完成，不同物理机同一subnet下通信在br-eth1连接的L2网络中实现，如上节所述。
访问外网与跨subnet的通信需要借助路由实现，也就是需要network节点的帮助，始终要有一个概念，那就是compute节点上的ovs只能做两层和tunnel功能，没有路由功能，想要做路由（路由交换或者访问外网）必须通过network节点，但是compute节点自带外网访问interface的除外。
如下图是vm不同子网间的访问方法，通过network节点的路由表实现。在compute节点上，Q开始，为vm2发送的数据包push internal vlan（例如vlan101），依次通过qbr-YYY（ovs，实现ACL功能）、br-int（normal模式的ovs，只用于带vlan的L2交换）、br-ethx（这里做vlan mod到外网使用的vlan，例如vlan1）。在network节点上，包依次通过br-ethx（唯一动作是送到br-int）、br-int（这里很可能是ip-subnet为match域的flow，注意tap#MN这个interface在所有vlan中，报文通过这个port pop或者mod vlan然后送给本地协议栈做路由。我目前理解是这样的等找到openstack环境之后看一下其中的flow就能理解了）。在本地协议栈做路由之后，报文会发回br-int，这时通过不同的ip-subnet为match域做的vlan动作就与之前不同了（也就是assign不同的vlan ID）。br-int将assign不同vlan ID的包发回br-ethx，后面就是上面过程的相反，回到了vm1中。
如果vm2向public network发送报文，那么在network节点的路由表中就会将这个报文指向外网interface发往br-ex，br-ex发往外网。
DVR如何改进路由性能？
如上节所述，其vm间路由都通过network节点，这点很不好，我们通过DVR改进。在非 DVR 的情况，数据是要通过网络节点才能相互传递数据包；在 DVR 的情况，数据包是直接在两个计算节点上传递。
Q_DVR_MODE=legacy，router在网络节点。
Q_DVR_MODE=dvr_snat，用于网络节点的配置，表示compute节点没有IP时候，访问外网的route使用这里的route。
Q_DVR_MODE=dvr，用于compute节点的配置，表示compute节点有IP时候，访问外网的route使用compute节点的route。
系统中的流量可以分为南北向、东西向，其中南北向是指compute节点与外网的通信，东西向指compute节点之间的通信。在2、3这两个配置合作模式下，南北向的流量，如果有floating ip，流量就直接走计算节点。如果没有floating ip，则会走网络节点。东西向的流量， 流量会直接在计算节点之间传递。
Floating IP配置如何变化？
在创建、绑定、去绑定或者删除浮动IP时，neutron server 首先执行 DB 操作，然后调用 RPC通知指定的Router，设置该浮动IP对应的 iptables 规则。每个floating IP，在network节点增加三个规则。
-A neutron-l3-agent-PREROUTING -d -j DNAT --to-destination #从本机访问虚机，Dst IP 由浮动IP该为访问固定IP
-A neutron-l3-agent-OUTPUT -d -j DNAT --to #从别的机器上访问虚机，DST IP 由浮动IP改为固定IP
-A neutron-l3-agent-float-snat -s -j SNAT --to #虚机访问外网，将Src IP 由固定IP改为浮动IP
neutron是openstack管理网络的模块，horizon中创建一个网络之后，horizon会通过RESTAPI将请求发送给neutron。/etc/init.d/neutron-server接受这个请求，并将请求处理之后转发相应的plugin。
plugin有些可以自己处理这些请求，例如L3-agent，就是分配IP地址。有些plugin需要通过远端的Agent处理，例如L2或者firewall。plugin与agent之间的通信是jsonrpc。
Agent可以部署在网络节点，包括网络路径与VM。有些VM在网络底层使用的是OVS，网络路径上的节点可使很多不仅包括OVS。
horizon与neutron-server具体如何工作？
horizon类似于web-ovs的前端，neutron-server类似于web-ovs的后端，plugin类似于model文件夹，agent就是特工。horizon那边后面有机会在分析。可以从neutron-server那边看出来他能接受哪些RESTAPI，在（http://developer.openstack.org/api-ref-networking-v2.html）中显示了北向接口的API，这里列出了horizon所有的RESTAPI吧，不仅包括neutron。看到与web-ovs中定义的基本类似，上述API可以分为几类。
- API version
- L2-network
- L3-network
- ports
- service provoder
Extension<--!>
neutron-server接受RESTAPI，并通过plugin实现，有些需要下发给agent，有些不用。需要下发给特工的是通过jsonrpc下发配置实现的，类似于NSX控制器下发的配置。
L2-network RESTAPI有哪些功能？
与NSX控制器控制vxlan功能类似，上层都是通过控制DB内容实现配置，vxlan中并没有add flow，所以这里应该也不会下发flow。类比NSX控制器下发的配置，创建logical switch时候并没有太多的配置下发下去，而是绑定到VM的port的时候才是将大多数配置下发下去，可以参看NSX-integration。另外从JSON request中看出，RESTAPI也就是web界面只是发出请求，并不表明自己的具体请求，例如L3network中的请求中只有CIDR，而L2网络只有一个网络名称以及状态。
Neutron如何部署？
上图是Neutron的典型网络，其中internet是指外网，External Network是指外网直接访问Network Node。API Network是指通过REST API访问neutron server。Management Network是指neutron server通过RPC访问Agent。Data Network是指各个Compute节点间是传送与处理数据的网络，Network Node只是用于构建网络，将Compute Node组成不同的网络，例如私有网络。
Cloud Controller Node，就是Controller Node的集合，Cloud主要是灾备或者负载均衡，我们做的Controller也支持灾备（一般是主从模式灾备）。这里的Controller主要指neutron server，用于接收REST API的请求（http://developer.openstack.org/api-ref-networking-v2.html），例如创建网络（L2）、创建子网（L3）、创建路由器（主要用于L3网络的路由）、数据库操作（主要是将网络ID等内容写入数据库）。其中具体模块见后面分析。
Network Node，是处理网络相关请求的Agent的集合，网络请求由neutron server通过RPC下发。如上图，其中l3-agent用于处理路由相关操作（增删查改），例如虚拟路由器（虚拟路由实例，与xorplus中虚拟路由一样）、路由表（虚拟路由的路由表）、namespace（是指linux虚拟路由的命名空间，可以看mininet了解）、iptable规则（主要用于类似ACL的功能，另外NAT功能是否是这个实现的还要再看）。neutron-dhcp-agent用于创建于管理虚拟DHCP服务器，功能与DHCP一样，提供动态IP、发送接收dnsmasg、扩展一点功能是将MAC/IP地址写入公用的数据库，对于一些异常（例如下发的IP的机器挂了）其处理方式主要通过数据库操作，这些异常的处理后面详述。neutron-openvswitch-plugin-agent用于创建L2 switch，注意这个L2 switch存在于Data Network而不是Management Network（这个不保证正确性），虚拟路由会有一个interface连接到L2 switch，dhcp也会有一个interface连接到L2 switch，Compute Node's通过这两个interface与路由器和dhcp服务器通信。
Compute节点，主要用于处理计算请求，与网络关系不大，但是需要特定的网络功能。在Compute节点上也存在neutron-openvswitch-plugin-agent，用于创建L2 switch及其操作。后面讲述的多种网络结构都需要这里的L2 switch帮助，其操作就是openvswitch的操作（包括interface、flow、tunnel等），不过有些人用linux bridge或者其他专用的L2设备，就需要这些设备的agent。
Neutron网络有哪些类型？
Neutron网络的目的就是为Compute Node提供不同类型的网络，使得Compute Node之间不同机器互联，这是SDN的一个应用。传统网络互联的对象是物理机器，互联方式主要有L2连接、L3连接（包括VRF）、tunnel连接（包括VPN），类似的Neutron网络类型主要有五种。
以VLAN模式为例介绍neutron虚拟网络？
在传统网络中，VLAN也是一种L2隔离的方法，主要用于运营商网络。如上图是neutron配置之后的网络拓扑，其中br-int用于内部网络，另外还有一个称为br-eth1的用于指向到eth1的网络，具体构造下一段详述。配置好网络之后，VM间的报文在经过Hypervisor时候进行push或者pop vlan操作（类比tunnel操作，加一个tunnel port然后加一条从tunnel port出去的flow，vlan操作只需要添加flow即可）。在外部网络使用VLAN报文进行传输，这些隔离的信息只有neutron掌握，存储在数据库。
如下图是配置之后，Compute节点上L2 switch的详细配置图。其中vm上的interface的配置通过Nove Compute配置，在vlan模式中，vm发出的报文也是带vlan-tag的，这样一是为了同一个hypervisor中的vlan隔离，也是方便br中通过vlan-mapping解决如何assign vlan tag的问题。vm中的这些功能通过TAP设备（linux内核功能）实现，L2 switch使用linux bridge，与ovs连接端口使用veth pair，注意的是无论TAP、linux bridge、ovs都是虚拟的软件设备。
br-int意思是internal bridge，用于内部网络VM之间的连接，在ovs中使用normal模式，意味着在没有flow的情况下做L2 switch 动作，所以VM间的互相访问通过FDB解决（注意normal模式的ovs同样关心vlan，同不同L2 switch行为一样，应该是IVL），这时vm（也称为tenant）间的访问隔离通过vm自带的vlan tag实现。
br-eth1是专门用于处理访问eth1物理端口的L2 switch，mod vlan的动作就是在这个switch中做（如何做参考上面所述），其中添加的flow通过L2 Agent下发，这时tenant间的访问隔离通过L2 Agent下发的flow决定，也就是openstack的用户决定。
在neutron的配置文件中，有如下几个关键配置：
VLAN模式下内部vm如何访问外网？
如上图所示，br-ex用于外网的访问，br-eth1用于内网的访问。数据包从内网进入br-int时候做内部vlan mod，在br-int中，如果包最后决定还是内网，再做内部vlan mod回内网，如上节所述。如果这个包需要送外网，那么需要先做NAT，在送往br-ex，通过br-ex的eth0发出去。
L3 Agent负责NAT表的配置，通过iptables实现。qg-VVV、qr-YYY、qr-ZZZ这些internal-port 连接到NAT表中（也就是机器的内部协议栈，根据IP决定如何做NAT），这三个internal-port只是用于将数据包送到协议栈，自己不会做任何封装等操作。
另外这里也分析一下dns功能，在br-int上面通过TAP interface连接到dhcp-agent上，dhcp-server发来的dnsmesq需要TAP端口push vlan后发送到br-int中，这样不同dhcp-server就属于不同的subnet。
vm间跨子网如何通信？
vm间的通信主要分为同一个subnet中的通信（同一物理机或者不同物理机）、跨subnet通信、访问外网。同一物理机中同一subnet下通信在物理机的br-int中完成，不同物理机同一subnet下通信在br-eth1连接的L2网络中实现，如上节所述。
访问外网与跨subnet的通信需要借助路由实现，也就是需要network节点的帮助，始终要有一个概念，那就是compute节点上的ovs只能做两层和tunnel功能，没有路由功能，想要做路由（路由交换或者访问外网）必须通过network节点，但是compute节点自带外网访问interface的除外。
如下图是vm不同子网间的访问方法，通过network节点的路由表实现。在compute节点上，Q开始，为vm2发送的数据包push internal vlan（例如vlan101），依次通过qbr-YYY（ovs，实现ACL功能）、br-int（normal模式的ovs，只用于带vlan的L2交换）、br-ethx（这里做vlan mod到外网使用的vlan，例如vlan1）。在network节点上，包依次通过br-ethx（唯一动作是送到br-int）、br-int（这里很可能是ip-subnet为match域的flow，注意tap#MN这个interface在所有vlan中，报文通过这个port pop或者mod vlan然后送给本地协议栈做路由。我目前理解是这样的等找到openstack环境之后看一下其中的flow就能理解了）。在本地协议栈做路由之后，报文会发回br-int，这时通过不同的ip-subnet为match域做的vlan动作就与之前不同了（也就是assign不同的vlan ID）。br-int将assign不同vlan ID的包发回br-ethx，后面就是上面过程的相反，回到了vm1中。
如果vm2向public network发送报文，那么在network节点的路由表中就会将这个报文指向外网interface发往br-ex，br-ex发往外网。
DVR如何改进路由性能？
如上节所述，其vm间路由都通过network节点，这点很不好，我们通过DVR改进。在非 DVR 的情况，数据是要通过网络节点才能相互传递数据包；在 DVR 的情况，数据包是直接在两个计算节点上传递。
系统中的流量可以分为南北向、东西向，其中南北向是指compute节点与外网的通信，东西向指compute节点之间的通信。在2、3这两个配置合作模式下，南北向的流量，如果有floating ip，流量就直接走计算节点。如果没有floating ip，则会走网络节点。东西向的流量， 流量会直接在计算节点之间传递。
Floating IP配置如何变化？
在创建、绑定、去绑定或者删除浮动IP时，neutron server 首先执行 DB 操作，然后调用 RPC通知指定的Router，设置该浮动IP对应的 iptables 规则。每个floating IP，在network节点增加三个规则。
-A neutron-l3-agent-PREROUTING -d
-A neutron-l3-agent-OUTPUT -d
-A neutron-l3-agent-float-snat -s