Neutron印象1:neutron简介

用最精炼语言介绍OpenStack网络代码演进的前世今生

在OpenStack世界中，网络组件最初叫nova-network，它混迹于计算节点nova的代码库中。nova-network可以单独部 署在一台机器上，为了高性能HA也可以和nova-compute一样部署在计算节点上（这也就是所谓的multi-host功能）。

nova- network实现简单，bug少，但性能可不弱哦，直接采用基于Linux内核的Linux网桥少了很多层抽象应该算强大的。不足之处是支持的插件少 （只支持Linux网桥），支持的网络拓扑少（只支持flat, vlan)。

 

       为了支持更多的插件，支持更多的网络拓扑，更灵活的与nova交互，于是有了quantum工程。quantum插件不仅支持Linux网桥，也支 持OpenvSwitch，一些SDN的插件以及其他商业公司的插件。在网络拓扑上，除了支持flat，vlan外，还支持gre, vxlan。但quantum不支持关键的multi-host特性。

 

quantum因为和一家公司的名称冲突，于是，改名为neutron。

 

       neutron继续演进，quantum之前的实现存在这么一个问题。我们说道说道。在quantum中，实现一种类型的插件一般包括两个部分，一 部分与数据库db打交道称之为plugin，一部分是调用具体的网络设备真正干活的称之为agent。

像plugin就有linux bridge plugin, opevswitch plugin, hyper-v plugin等，这些plugin因为都是与db打交道，变化的字段并不多，所以代码绝大部分是重复的。这样也就出来了一个公共的plugin叫ml2 plugin(具体的代码实现就是TypeDriver)。

 

      但这只是一个表象，ml2还有更大的作用，那就是它里面的MechanismDriver。

      我举个例子讲，之前没有ml2的时候，plugin只能 支持一种，用了linux bridge，就不能用openvswitch了，想要都用那怎么办，那就需要MechanismDriver上场，MechanismDriver的作 用是将agent的类型agent_type和vif_type关联，这样vif_type就可以直接通过扩展api灵活设置了，所以这时候你想用 linux bridge你在vif_type里直接将port绑定成linux bridge就行了，同理，想用openvswitch就将vif_type将port绑定成openvswitch就行。

      除了让openvswitch, linux bridge这些不同的插件共存之外，ml2还能让不同的拓扑如flat, vlan, gre, vxlan其乐融融和谐共存，直接在ml2_conf.ini这个配置文件里都配上即可。这样也就解决了一个问题，以前前端horizon中无法配置是用 flat还是vlan，因为你配了也没有用，那时候后端还不支持flat和vlan同时存在了，现在皆大欢喜了。

      上面的ml2解决的只是网络中L2层的问题，对于L3层的路由功能neturon又单独整出个l3-agent，对于dhcp功能又单独整出个 dhcp-agent，不过它们归根结底仍属于实际真正干功能活的，对于和数据库db打交道的那部分则是通过提供扩展api来实现的。

      那么现在我们想加更 多的网络服务该怎么办呢，如L4-L7层的FwaaS, VPNaaS, DNATaaS, DNSaaS，所以现在neutron又出来一个新的服务框架用于将所有这些除L2层以外的网络服务类似于上述ml2的思想在数据库这块一网打尽。并且这 些网络服务可能是有序的，例如可能需要先过FwaaS防火墙服务再过DNATaaS服务来提供浮动IP，所以也就有了service chain的概念。目前这块代码只进去了firewall, loadbalance, metering, vpn几块，但万变不离其宗，未来neutron就是朝这个思想继续往下做。想用哪些服务可以通过neutron.conf这个配置文件中的 service_provider项指定。

 

最后，需要一提的是，从性能角度讲，我认为目前neutron仍然不能用于大规模的生产环境，理由如下：
1)虽然增加了更多的插件，更多的网络服务，更多的网络拓扑，但它仍然不支持multi-host功能，对性能是极大影响
2)neutron-server不支持workers通过fork实现的利用cpu多核的多进程机制，仍然是单线程实现的，阻塞的话(python解释器是单进程的，使用greenlet保证每个线程在单进程下也是线性的），会延缓接受其他请求对性能产生影响。
3)neutron-server是无状态的服务，理论上讲是可以在多台机器上运行前端再加haproxy实现HA的，但实际代码中存在众多竞争条件的bug。当然这个问题不仅在neturon有，其他组件我看一样存在。
4)在遂道性能方面存在优化的可能，遂道如GRE,VXLAN等将虚拟L2层打通反而扩大了广播风暴的可能，实际上虚拟网桥或者hypervisor都是知道虚机的IP和MAC地址的映射的关系的，根本不需要仍使用传统的ARP广播方式来获得这种映射关系。
5)其他…

成熟的路上漫漫其修远兮，这也正好给各位爱好openstack的童鞋们提供了大显身手的好机会：）

Havana 中boot虚机时, nova与neutron的交互（ML2 plugin）

在启动虚机时,nova会与neutron进行一系列交互，如下图所示。此图中启用了ML2，并且启用了ovs和Cisco两种机制。

注：

如果ML2没有启用Cisco插件，则没有第10步。

Neutron/ML2

1. Neutron ML2

模块层2(ml2)插件是一种允许OpenStack网络同时地利用在复杂现实数据中心发现的各种第二层网络技术的框架。目前它与存在的openvswitch、linuxbridge和hyperv L2代理共同存在，而且想要替换和否决与那些L2代理相关联的巨大插件。ml2框架也想要大大简化增加对新L2网络技术的支持，并且比那些要求添加新的巨大核心插件需要更少的初始和持续的努力。模块化代理可能作为后续开发工作。

1.1．        ML2驱动

ml2驱动分别实现可扩展的网络类型和访问那些类型网络机制的集合。与metaplugin不同的是，多种机制被同时地用于访问相同虚拟网络的不同端口。这些机制能通过RPC和/或使用驱动原理利用L2代理来与外部设备或者控制器相互联系。类型和进程驱动程序被加载为python入口点使用stevedore库。

1.1.1．   驱动类型

每个可用的网络类型被ml2驱动类型管理。驱动类型维持任何需要指定类型的网络状态，并且执行供应商网络验证和租户网络配置。Ml2插件同时包含本地、扁平、vlan、gre和vxlan网络类型的驱动程序。

1.1.2．   驱动机制

每个网络进程被ml2驱动机制管理。驱动机制对已建立的类型驱动获取的信息有责任，以及确保能够恰当的应用到所给的能工作的网络进程。

驱动机制接口同时支持创建、更新和删除网络和端口资源。对每个在资源上采取行动，进程驱动使用两种方法——ACTION_RESOURCE_precommit,一种称为数据库事务处理上下文和ACTION_RESOURCE_postcommit,称为数据库事务完成后。Precommit方法被驱动机制用于验证采取的行动和做任何需要改变驱动机制的私有数据库。Precommit方法不应该阻塞以及因此不能和任何外部Neutron通信。Postcommit方法负责适当推动改变资源的实体负责应用改变。例如，postcommit方法将推动一个外部网络控制器改变，那负责适当地更新网络资源基于这些改变。

支持驱动机制目前在先行版本Havana中是半成品，同时它的接口在Havana推行前会发生改变。在未来的版本中，驱动机制接口也被称为用来建立端口绑定，决定VIF类型和网段。

1.2.           多区段网络

虚拟网络有多段相同或者不同类型组成的。数据库决策和驱动程序APIs支持多区段网络，但是对于多区段网络的客户端APIs现在还没有实现。

 

2.　　　ML2配置

2.1.           在Devstack中使用ML2

ML2插件在Devstack中完全支持。支持配置VLAN、GRE和VXLAN网络模式。配置这些模式如下：

2.2.           用VLANs模式的ML2配置Devstack

为配置ML2使用控制和计算结点的localrc文件如下所述，用来运行VLANs模式的Devstack。这等价于运行OVS或者LinuxBridge插件在VLAN模式下。

如下在你的控制节点添加如下的localrc文件：

Q_PLUGIN=ml2 ENABLE_TENANT_VLANS=True ML2_VLAN_RANGES=mynetwork:100:200

为VLAN类型驱动程序设置指定的VLAN参数，在localrc下列变量被使用。这是一个空间独立的分配值列表：

Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS=(network_vlan_ranges=600:700)

2.3.           用隧道网络模式的ML2配置Devstack

一个控制和计算结点localrc文件显示在这里为了配置ML2运行隧道网络的Devstack。这是最基本的配置ML2的形式，而且等价于运行GRE隧道的OVS插件。

在控制节点localrc添加如下：

Q_PLUGIN=ml2 ENABLE_TENANT_TUNNELS=True

在计算结点，添加到你的localrc中：

Q_PLUGIN=ml2 ENABLE_TENANT_TUNNELS=True

改变GRE关键的范围使用隧道关键，添加到localrc：

TENANT_TUNNEL_RANGE=50:100

上面将启用OVS的GRE隧道。如果你想要使用OVS的VXLAN，确保你正在运行至少1.10版本的OVS，包括从上游领域的OVS项目中的Open vSwitch KLM。一旦你有了，下面就可以启用VXLAN隧道模式的ML2：

在控制节点上添加下列到localrc：

Q_PLUGIN=ml2 Q_ML2_TENANT_NETWORK_TYPE=vxlan

计算结点上添加下列代码到localrc中：

Q_PLUGIN=ml2 Q_ML2_TENANT_NETWORK_TYPE=vxlan

改变VXLAN VNIs的范围到使用，添加到localrc：

Q_ML2_PLUGIN_VXLAN_TYPE_OPTIONS=(vni_ranges=400:500)

2.4.           在Devstack中高级ML2配置

Devstack缺省运行OVS代理的ML2.使用不同的代理，在localrc中如下设置：

Q_AGENT=linuxbridge

ML2缺省不加载任何进程驱动程序，仅与OVS、LinuxBridge和Hyper-V代理共存。为了改变这个，在localrc中设置如下。有效参数是你想要使用的进程驱动程序的名字：

Q_ML2_PLUGIN_MECHANISM_DRIVERS=<list of MechansimDrivers>

默认地，所有的ML2类型驱动被加载。改变这个行为，在localrc设置如下。有效选项如下设置：local、flat、vlan、gre、vxlan。

Q_ML2_PLUGIN_TYPE_DRIVERS=vlan,gre

OpenStack网络组件Neutron的研究

本文将会涵盖如下几个部分：

- Openstack网络组件的发展历程

- Neutron的结构

- Neutron Server的结构

- Neutron的配置

1.1 nova-network

Openstack在2010年正式发布它的第一个版本Austin的时候，nova-network作为它的核心组件被包含其中。nova-network的功能主要有：

IP地址分配包含为虚拟主机分配私有（固定）和浮动IP地址。

网络模型与管理提供了虚拟网络使虚拟主机之间以及与外部网络通信。网络模型分为以下三种。这三种模型可以共存在一个云系统中，但是在一个计算节点上只能配备一种模型。

扁平网络 （FlatNetwork）：在创建虚拟主机时，nova-network会从指定子网中取一个空闲IP并将它写入此虚拟主机的配置文件。在一个子网内的虚拟主机可以通过创建Linux桥实现互通。

带DHCP功能的扁平网络 （Flat DHCPNetwork）：顾名思义，此种模式相对于扁平网络加入了DHCP功能。在创建虚拟主机时，nova-network会在指定的子网中为此虚拟主机分配IP和物理地址，并将这些信息告知DHCP服务器（默认是dnsmasq）。DHCP服务器会监听虚拟主机所在的桥。当有虚拟主机启动时，会自动从DHCP服务器获得IP。可以看到DHCP服务器只是按照nova-network给定的列表（IP和物理地址）分发IP，如何分配还是nova-network说了算。

VLAN网络 （VLANNetwork）：这是nova-network的默认模型。针对每个项目（Project，如今Openstack把项目改称租户 --Tenant），都会对应一个vlan。每个项目里的私有IP地址只能在本项目的vlan里访问。与项目对应的vlan需要子网，这个子网是由管理员动态分配给项目的。与带DHCP功能的扁平网络类似，子网内的IP地址也是通过DHCP服务器分发的。所有在一个子网内的虚拟主机都通过网桥互通。

安全控制主要通过ebtables和iptables来实现。

1.2 Quantum

Quantum是随Openstack的Folsom版本正式发布的，其实它已经作为试用组件包含在之前的Essex版本中。在Grizzly里功能得到了增强。

为什么引入Quantum？答案非常简单，Quantum功能更强大，满足更多需求。下面列几条主要功能。

- 提供面向租户的API，以便控制2层网络和管理IP地址

- 支持插件式网络组件，像Open vSwitch，Cisco，Linux Bridge，Nicira NVP等等

- 支持位于不同的2层网络的IP地址重叠

- 支持基本的3层转发和多路由器

- 支持隧道技术（Tunneling）

- 支持3层代理和DHCP代理的多节点部署，增强了扩展性和可靠性

- 提供负载均衡API （试用版本）

1.3 Neutron

因为商标侵权的原因，Openstack在Havana版本上将Quantum更名为Neutron，所以Neutron并不是什么新的东西。在Havana版里，Neutron也只增加和增强了少数功能。

- 提供稳定的负载均衡API

- 支持端到端的IPSec VPN

- 面向租户的防火墙服务

- 提供一个新的插件ML2，这个插件可以作为一个框架同时支持不同的2层网络

现在很多已部署的Openstack云还在继续使用nova-network，因为它简单，稳定，尤其是多节点部署的可扩展性和可靠性让人不愿割舍。但是我们必须考虑往Neutron上迁移了，最新版Icehouse（还未发布）中的nova-network将会被列为过期组件，虽然系统还支持，但不建议使用了。

接下来我们一起来看看Neutron，本人精力在咨询、架构和部署，所以对源码实现我们不会涉及。

Openstack的设计理念是把所有的组件当做服务来注册的。Neutron就是网络服务。它将网络、子网、端口和路由器抽象化，之后启动的虚拟主机就可以连接到这个虚拟网络上，最大的好处是这些都可视化的在Horizon里得到了实现，部署或者改变一个SDN变得非常简单，没有专业知识的人稍经培训也可以做到。

我们先通过如下一个简单的流程来了解客户机如何连接到网络上。

- 租户创建了一个网络，比方说mynet

- 租户为此网络分配一个子网，比如192.168.122.0/24

- 租户启动一个客户机，并指明一个网口连接到mynet

- Nova通知Neutron并在mynet上创建一个端口，如port1

- Neutron选择并分配一个IP给port1

- 客户机通过port1就连接到了mynet上

Neutron主要有以下几部分组成。

Neutron Server：这一部分包含守护进程neutron-server和各种插件neutron-*-plugin，它们既可以安装在控制节点也可以安装在网络节点。neutron-server提供API接口，并把对API的调用请求传给已经配置好的插件进行后续处理。插件需要访问数据库来维护各种配置数据和对应关系，例如路由器、网络、子网、端口、浮动IP、安全组等等。

插件代理 （Plugin Agent）：虚拟网络上的数据包的处理则是由这些插件代理来完成的。名字为neutron-*-agent。在每个计算节点和网络节点上运行。一般来说你选择了什么插件，就需要选择相应的代理。代理与NeutronServer及其插件的交互就通过消息队列来支持。

DHCP代理（DHCP Agent）：名字为neutron-dhcp-agent，为各个租户网络提供DHCP服务，部署在网络节点上，各个插件也是使用这一个代理。

3层代理 （L3 Agent）： 名字为neutron-l3-agent，为客户机访问外部网络提供3层转发服务。也部署在网络节点上。

下面这张图取自官网，很好的反映了Neutron内部各部分之间的关系。（SDN服务在这里是额外的外部功能，可以暂时略过。）

下面我们来细看一下Neutron Server的结构。

这张图中我们只看Quantum-common和Quantum Plugin部分，其实就是Neutron Server。

上面我们已提到，Neutron最重要的就是两部分：API和插件。

3.1 API

API又分为两个部分。

APICore：暂且称之为API核。它可以看做是插件功能的最小集合，即每个插件都必须有的功能，也就是对网络、子网和端口的查询、加删和更新操作等。

APIExtensions：暂称之为API扩展。它们一般是针对具体插件实现的，这样租户就可以利用这些插件独特的功能，比方说访问控制（ACL)和QoS。

需要提一下的是，现在API核具备的功能还都很简单，随着Neturon的不断成熟，它可能就会纳入一些API扩展中的功能。

当然API部分也负责Neutron服务的启动、客户请求和相应回复的打包和派发以及验证数据格式及其正确性。也有一些安全和稳定机制，比方说对API请求的限制以防止DOS攻击来保证服务在大负载下的可用性。

至于验证和授权功能，相信大家都已了解，就是与Keystone结合，进行用户或租户级的使用控制。

3.2 插件

下面我们再来看一下插件。

从功能上说，插件一般有以下内容。

- 存储当前逻辑网络的配置信息，这就需要一个数据库，比方说MySQL

- 判断和存储逻辑网络和物理网络的对应关系，比方说为一个逻辑网络选择一个vlan

- 与一种或多种交换机通信来实现这种对应关系。这一般通过宿主机上的插件代理来实现这种操作，或者远程登录到交换机上来配置。

以Open vSwitch为例，下面列出了插件需要访问的数据表。

+---------------------------+
| Tables_in_neutron         |
+---------------------------+
| agents                    |
| allowedaddresspairs       |
| dnsnameservers            |
| externalnetworks          |
| extradhcpopts             |
| floatingips               |
| ipallocationpools         |
| ipallocations             |
| ipavailabilityranges      |
| networkdhcpagentbindings  |
| networks                  |
| ovs_network_bindings      |
| ovs_tunnel_allocations    |
| ovs_tunnel_endpoints      |
| ovs_vlan_allocations      |
| portbindingports          |
| ports                     |
| quotas                    |
| routerl3agentbindings     |
| routerroutes              |
| routers                   |
| securitygroupportbindings |
| securitygrouprules        |
| securitygroups            |
| subnetroutes              |
| subnets                   |
+---------------------------+

Neutron的配置应该说是比Openstack的其他组件复杂一点。

常用的配置模型有两种，

 把Neutron Server放在控制节点上，DHCP和L3代理放在网络节点上，可参考一下官图。

 把Neutron的所有部分放在单独的网络节点上。这种方式就是把上图部署在控制节点中的neutron-server放到网络节点上。

因为网络配置不像网络使用那么频繁，所以通常建议使用第一种方案，没有必要单独把neutron-server拿出来。因为neutron-server是可单独部署的，我们就拿第二种方案作为例子。

系统使用ubuntu12.04，软件的安装我们就不说了，这里我们采用Open vSwitch插件。（针对虚拟交换机OpenvSwitch，Neutron建议是使用ML2插件的，但这里我们为了加深对插件和插件代理的理解，还是沿用了OpenvSwitch插件）。

4.1 计算节点的配置

安装完软件包以后，计算节点应该就有OpenvSwitch的代理在运行，使用ps命令可以看到如下进程。

/usr/bin/python /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
这里我们可以看到代理读取了2个配置文件。

neutron.conf主要需要设置如下几项：

core_plugin = neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2 //插件类型
auth_strategy = keystone  // 授权方式
rabbit_host = 192.168.122.1       //处理消息队列的主机地址
[keystone_authtoken]      //keystone信息，这里只是我的例子信息
auth_host = 192.168.122.1
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = neutron
admin_password = neutron
auth_url = http://192.168.122.1:35357/v2.0
connection =  mysql://neutron:neutron@192.168.122.100/neutron      //DB信息

neutron.conf会默认包含另一个配置文件api-paste.ini，对它只需添加keystone信息。

auth_host=192.168.122.1
admin_user=neutron
admin_tenant_name=service
admin_password=neutron
ovs_neutron_plugin.init主要需要设置以下几项，以vlan为例：
tenant_network_type = vlan       //网络类型，例如vlan，gre
network_vlan_ranges = physnet1:1000:2999  //vlanID
bridge_mappings = physnet1:br-int //用于计算节点上客户机内部网络的网桥
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
4.2 网络节点的配置

安装完软件后，网络节点应该会有如下进程在运行。

/usr/bin/python /usr/bin/neutron-dhcp-agent--config-file=/etc/neutron/neutron.conf--config-file=/etc/neutron/dhcp_agent.ini /usr/bin/python/usr/bin/neutron-metadata-agent--config-file=/etc/neutron/neutron.conf--config-file=/etc/neutron/metadata_agent.ini /usr/bin/python/usr/bin/neutron-l3-agent --config-file=/etc/neutron/neutron.conf--config-file=/etc/neutron/l3_agent.ini /usr/bin/python/usr/bin/neutron-server --config-file /etc/neutron/neutron.conf--config-file/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
/usr/bin/python /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
你会看到每个部分会用到哪个配置文件。

neutron.conf和api-paste.ini的配置与计算节点上是一样的。

dhcp_agent.ini的主要设置以下几项。看内容可理解其意义。

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
metadata_agent.ini的设置主要是keystone相关的。
auth_url = http://192.168.122.1:5000/v2.0
auth_region = regionOne
admin_tenant_name = service
admin_user = neutron
admin_password = neutron
nova_metadata_ip = 192.168.122.1
metadata_proxy_shared_secret = meta       //proxy的密码，个人设置
l3_agent.init的设置。
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

ovs_neutron_plugin.ini的配置和计算节点上的一样。

4.3 节点上OVS的配置

计算节点和网络节点的NIC配置非常相似，我们都是用第二个NIC（eth1）作为内部网络的通讯。以网络节点为例。eth1不能设置IP地址，而是把IP地址给虚拟桥。

auto eth1
iface eth1 inet manual
        up ifconfig $IFACE 0.0.0.0 up
        down ip link set $IFACE down
auto br-int
iface br-int inet static
        address 10.100.1.2
        netmask 255.255.255.0
OVS中把eth1放到虚拟桥上。
    Bridge br-int
        Port "eth1"
            Interface "eth1"
        Port br-int
            Interface br-int
                type: internal

Neutron是openstack的方向，我们有必要花点时间研究一下它。目前对它的担心还是有的，比方说稳定性、可用性，还有性能（以后有机会探讨），但它的灵活性、多功能性是无可比拟的。

因为工作原因，断断续续花了很长时间写这篇博客，只为抛砖引玉，内容也有不全面和错误的地方，希望与大家交流。

OpenStack的网络组件已经从Quantum更名为Neutron了。之前Quantum就有一个安全组的实现，它运行在每一个计算节点上，能够做到：

1）过滤进入到计算节点上虚机的流量

2）过滤从虚机出来的流量（nova-network并不能实现这一点）

3）过滤虚机之间的流量

        安全组的一般用法及实现框图如下：

$nova secgroup-create mygroup description

$nova secgroup-add-rule mygroup tcp 22 22 192.168.1.0/24

$nova boot –flavor 1 –image f16f1d2d-71d6-41b7-98a5-319f142d61f5–security_groups mygroup i1

 

         上述一个安全组由一系列的iptable rule组成，rule都是针对soure/dest ip及tcp port的，它不能像下一代的防火墙一样来表达应用特性像audited rules，也不能提供边缘防火墙的特性。所以在Neutron提供L4/L7层框架之际，也将推出了FWaaS服务(https://docs.google.com/document/d/1PJaKvsX2MzMRlLGfR0fBkrMraHYF0flvl0sqyZ704tA/edit?pli=1)。

         在FWaaS中，tenant可以创建多个Firewall instances,而每一个virtual firewall instance和多个Firewall Policies关联，每个firewall policies由多个Firewall rules按序组成。不能直接应用一个rule，它必须先加入到一个policy中，因为它需要先审计。如下图：

 

         多层防火墙的应用场景如下图：

 

       Neutron L3 agent运行在gateway host上，它通过linux的namespace特性实例化多个neutron router，一个tenant能用多个router。见下图,router中的qr-XXX虚拟接口用于和tenant网络相连，qg-XXX虚拟接口用于跟外部网络相连，防火墙服务应该是过滤出入tenant网络的所有流量，所以firewallpolicy应该是应用在qr-XXX虚拟接口上（iptables出口rule中添加”-oqr-+” a即可，入口规则添加”-iqr-+”即可），如果对所以tenant网络都适用的话可以运用在qg-XXX接口上(但havana的这一版本不会实现这一点，并且也不会实现Zones的概念，一组像上面的qr-XXX接口可以组成一个Zone，也不会检查address sppofing）。所以防火墙规则不仅应该像之前的安全组那个运用到计算节点上，也应该运用在相应的tenant’srouter的主机相应的namespace下（这即是所谓的边缘防火墙规则）.

参考实现将会有4个chains，出和入各一个，ipv4和ipv6各一个。：

        所以相应地在FWaaSAgent中会有几个方法：

1. create_firewall(apply_list, fireall),fireall是指一组上面的防火墙规则，apply_list指一些networknamespace
2. update_firewall(apply_list, fireall)
3. delete_firewall(apply_list, fireall)

      关于将上面的firewallinstance在哪里应用到VM应涉及到L4/L7服务框架了。以前Neutron只有一级插件结构（像OVS插件，像LinuxBridge插件），但现在引入了L4/L7层服务框架之后变成了两层，即实现了在一个核心插件（像OVS插件）下再能添加若干个服务（像LBaaS,像FWaaS）。可参见：https://docs.google.com/document/d/1iLzieNKxM7xip_lRidmalAhF_6-Yf1b_cePF4yeAnkQ/edit?pli=1,

       相关进阶的代码和BP：

1）Firewallas a Service (FWaaS) APIs and DB Model,https://review.openstack.org/29004

2)  FwaaS agent,https://blueprints.launchpad.net/quantum/+spec/quantum-fwaas-agent

3)  FwaaS Plugin, https://blueprints.launchpad.net/quantum/+spec/quantum-fwaas-plugin  
4)  FwaaS ip tables driver https://blueprints.launchpad.net/quantum/+spec/quantum-fwaas-iptables-driver  

文章来源：http://blog.csdn.net/quqi99/article/details/9163469
文章作者：张华 http://blog.csdn.net/quqi99