openstack-neutron模块详解

Neutron基本架构

与openstack其他服务和组件的设计思路一样，Neutron也采用分布式架构，由多个组件（服务）共同对外提供网络服务，Neutron架构非常灵活，层次多，一方面是为了支持各种现有或者将来会出现的先进网络技术，另一方面支持分布式部署，获得足够的拓展性。示意图如下：

Neutron仅有一个主要服务进程Neutron-server，它运行于控制节点上，对外提供openstack网络api作为访问Neutron的入口，收集请求后调用插件（plugin）进行处理，最终由计算节点和网络节点上的各种代理（agent）完成请求
网络提供者（network-provider）是指提供者openstack网络服务的虚拟机或者物理网络设备，如linux bridge、open vswitch或者其他支持neutron的物理交换机。与其他服务一样，neutron的各个组件服务之间需要相互协调通信，neutron-server、插件、代理之间通过消息队列（默认用RabbitMQ实现）进行通信和相互协调。
数据库（默认使用MariaDB）用于存放openstack的网络状态信息，包括网络、子网、端口、路由器等等。
客户端（Client）是指使用neutron服务的应用程序，可以是命令行工具（脚本）、horizon（openstack图形化操作界面）和nova计算服务等。
举例：创建一个vlan 10虚拟网络的流程
（1）neutron-server收到创建网络（network）的请求，通过消息队列（RabbitMQ）通知已注册的linux bridge插件（这里假设网络提供者为linux bridge）。
（2）该插件将要创建的网络信息（如名称、ID值、VLANID等）保存到数据库中并通过消息队列通知运行在各个节点上的代理。
（3）代理收到信息后会在节点上物理网卡创建vlan设备（比如物理接口的子接口Eth1.10），并创建一个网桥（比如brgxxx）来桥接网络设备

Neutron-server

neutron-server提供一组API来定义网络连接和IP地址，供Nova等客户端调用，它本身也是分层模型设计，其层次结构如下：

Neutron包括4个层次，自上而下依次说明如下：
（1）Resetful API：直接对客户端API服务，属于最前端的API，包括Core API和Extension API两种类型。Core API提供管理网络、子网和端口核心资源的Resetful API；Extension API提供给网络管理路由器、负载均衡、防火墙、安全组等扩展资源的Resetful API。
（2）Commnon Server：通过服务，负责对API请求进行检验、验证，并授权。
（3）Neutron core：核心处理程序，调用相应的插件API来处理API请求。
（4）Plugin API：定义插件的抽象功能集合，提供调用通用插件的API接口，包括Core Plugin API和Extension Plugin API两种类型，Neutron core通过Core Plugin API调用相应的Core Plugin，通过Extension Plugin API调用相应的Service Plugin。

插件、代理与网络提供者

neutron遵循openstack的设计原则，采用开放架构，通过插件、代理与网络提供者的配合来实现各种网络功能。
插件是neutron的一种API的后端实现，目的是增强扩展性，插件按照功能可分为Core Plugin和Service Plugin两种类型，Core Plugin提供基础二层虚拟机网络支持，实现网络、子网和端口核心资源的支持，Service Plugin是指Core Plugin之外的其他插件，提供路由器、防火墙、安全组、负载均衡等服务支持，值得一提的是，直到openstack的Havana版本，neutron才开始提供一个名为 L3 Router Service Plugin的插件支持路由服务。
插件由neutron-server的Core Plugin API和Extension Plugin API调用，用于确定具体的网络功能，即需要配什么样的网络，插件处理neutron-server发来的请求，主要职责是在数据库中维护neutron网络的状态信息（更新neutron数据库），通知相应的代理实现具体的网络功能，每一个插件支持一组API资源并完成特定操作，这些操作最终由插件通过RPC调用相应的代理（agent）来完成。
代理处理插件转来的请求，负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或者虚拟化技术来完成实际的操作任务，如用于路由具体操作L3 Agent
插件和代理与网络提供者配套使用，比如网络提供者是linux bridge，就需要使用linux bridge的插件和代理，如换成open vswitch则需要改成相应的插件和代理。

Neutron的物理部署服务

neutron与其他openstack服务组件系统工作，可以部署在多个物理主机节点上，主要涉及控制节点、网络节点和计算节点，每个节点可以部署多个，典型的主机节点部署介绍如下：
（1）控制节点和计算节点
控制节点上部署neutron-server(API)、Core Plugin和Service Plugin的代理，这些代理包括neutron-plugin-agent、neutron-metadata-agent、neutron-dhcp-agent、neutron-l3-agent、neutron-lbaas-agent等。Core Plugin和Service Plugin已经集成到neutron-server中，不需要运行代理的plugin服务。
计算节点上可以部署Core Plugin、Linux Bridge或Open vSwitch的代理，负责提供三层的网络功能。
控制节点和计算节点上都需要部署Core Plugin的代理，因为控制节点与计算节点通过该代理才能进行二层连接。
（2）控制节点和网络节点
可以通过增加网络节点承担更大的负载，该方案特别适合规模较大的openstack环境
控制节点部署neutron-server服务，只负责通过neutron-server响应的API请求。
网络节点部署的服务包括Core Plugin的代理和Service Plugin的代理，将所有的代理从上述节点分离出来，部署到独立的网络节点上，由独立的网络节点实现数据的交换，路由以及负责均衡等高级网络服务。

Neutron的主要插件、代理与服务

Neutron插件、代理与服务层次结构如下图

ML2插件

neutron可以通过开发不同的插件和代理来支持不同的网络技术，这是一种相当于开发的架构。不过随着所支持的网络提供者种类的增加，开发人员发现两个突出的问题。一个问题是多种网络提供者无法共存，Core Plugin负责管理和维护neutron二层的虚拟网络的状态信息，一个neutron网络只能由一个插件管理，而Core Plugin插件与相应的代理是一一对应的，如果linux bridge插件，则只能选择linux bridge代理，必须在openstack的所有节点上使用linux bridge作为虚拟交换机；另外一个问题时开发插件的工作量太大，所有传统的Core Plugin之间存在大量重复的代码（如数据库访问代码）
为了解决这两个问题，从openstack的Havana版本开始，neutron实现了一个插件ML2（Moduler Layer2），为了取代所有Core Plugin，允许在openstack网络中同时使用多种二层的网络技术，不同的节点可以使用不同的网络实现机制，ML2能够与现在所有的代理无缝集成，以前使用的代理无需变更，只需要将传统的Core Plugin替换成ML2。ML2使得对新的网络技术支持更为简单，无须重新开发新的Core Plugin，只需要开发相应的机制驱动（Mechansion Driver），大大减少要编写和维护的代码。

ML2对二层的网络进行抽象，解锁了neutron所支持的网络类型（Type）与访问这些网络类型的虚拟网络实现机制（Mechansim），并通过驱动的形式进行拓展，不同的网络类型对应不同的网络类型的驱动（Type Driver），由类型管理器（Typer Manager）进行管理。不同的网络实现机制对应不同的机制驱动（Mechansiom Driver），由机制管理器（Mechansim Manager）进行管理。这种实现框架是ML2具有弹性，易于扩展，能够灵活支持多种网络类型和实现机制。
（1）类型驱动（Type Driver）
neutron支持的每一种网络类型都有一个对应的ML2类型驱动，类型驱动负责维护网络类型的状态，执行验证、创建网络等工作。目前neutron已经实现的网络类型包括flat、local、vlan、xvlan、gre
（2）机制驱动（Mechansim Driver）
neutron支持的每一种网络机制都有一个对应的ML2机制驱动。机制驱动负责获取类型网络驱动维护的网络状态，并确保在相应的网络设备（物理或虚拟的）上正确实现这些状态。
举例：类型驱动vlan，机制驱动linux bridge，如果创建vlan10，那么vlan的类驱动会确保将vlan10的信息保存到neutron数据库中，包括网络的名称、vlanID等，而linux bridge机制驱动会确保各个节点上的linux bridge代理在物理网卡上创建ID为10的vlan设备和bridge设备，并将二者进行桥接。
目前neutron已经实现的网络机制有三种类型：

• 基于代理（agent-based）：包括linux bridge、opens vswitch
• 基于控制器（controller-based）：包括OpenStacDaylight、VMware NSX等
• 基于物理交换的：包括Cisco Nexus、Arista、Mellanox等

（3）扩展资源
ML2作为一个Core Plugin，在实现网络、子网和端口核心资源的同时，也实现了包括端口绑定（Port Bindings）、安全组（Security Group）等部分扩展资源。
目前ML2插件已经成为neutron的首选插件

Linux Bridge代理

linux bridge是成熟可靠的neutron二层网络虚拟化技术，支持local、flat、vlan、vxlan这四种类型网络，目前不支持gre
linux bridge可以将一台主机上的多个网卡桥接起来，充当一台交换机，它可以桥接物理网卡，又可以桥接虚拟网卡，用于桥接虚拟机网卡的是Tap接口，这是一个虚拟出来的网络设备，成为Tap设备，作为网桥的一个端口，Tap接口在逻辑上与物理接口具有相同的功能，可以接收和发送数据包。
如果选择linux bridge作为代理，在计算节点上数据包从虚拟机发送到物理网卡需要经过以下设备：

• Tap接口（Tap Interface）：用于网桥虚拟机的网卡，命名为tapxxx
• Linux网桥（Linux Bridge）：作为二层交换机，命名为brqxxxx
• VLAN接口（VLAN Interface）：在VLAN网络中用于连接网桥，命名为ethx.y（ethx为物理网卡名称，y为VLAN ID）
• VXLAN接口（VXLAN Interface）：在VXLAN网络中用于连接网桥，命名为vxlan-z（z是VNID）
• 物理网络接口：用于连接到物理网络。

计算节点上的linux bridge环境下的flat网络和vlan网络，下面两个图其中网桥是核心。vlan网络由两个vlan自己的网桥，实现了基于vlan的网络，如果改用vxlan，其中的vlan接口换成vxlan接口，可以命名为vxlan-101和vxlan-102

• 基于linux bridge的flat网络
  

• 基于linux bridge的vlan网络
  

Open VSwitch代理

与linux bridge相比，open vswitch（可简称为OVS）具有几种管控功能，而且性能更加优化，支持更多的功能，目前在openstack领域称为主流。它支持local、flat、vlan、vxlan、gre和geneve等所有的网络类型。
（1）open vswitch的设备类型

• Tap设备：用于网桥连接虚拟网卡
• Linux网桥：桥接网卡接口（包括虚拟接口）
• VETH对（VETH Pair）：直接相连的一对虚拟机网络接口，发送VETH对一端的数据包由另一端接收，在openstack中，它用来连接两个虚拟网桥。
• OVS网桥：open vswitch的核心设备，包括一个OVS集成网桥（Integration Bridge）和一个OVS屋里连接网桥。所有在计算节点上运行的虚拟机连接到集成网桥，neutron通过配置集成网桥上的端口来实现虚拟机网络隔离。物理机连接网络直接连接到物理网卡。这两个OVS网络通过一个VETH对连接，open vswitch的每个网桥都可以看做是一个真正的交换机，可以支持VLAN。

（2）Open VSwitch数据包流程
如果选择Open VSwitch代理，在计算节点上的数据包从虚拟机发送到物理网卡上需要依次经过一下设备。

• Tap接口（Tap Interface）：用于网桥虚拟机的网卡，命名为tapxxx
• Linux网桥（Linux Bridge）：与Linux Bridge不同，命名为qbrxxx（其中编号xxx与tapxxx中的xxx相同）
• VETH对：两端分别命名为qvbxxx和qvoxxx（其中编号xxx与tapxxx中的xxx保持一致）
• OVS集成网桥：命名为br-int
• OVS PATCH端口：两端分别命名为int-br-ethx和phy-br-ethx（x为物理网卡的名称的编号）
• OVS物理连接网桥：分别为两种类型，在flat和vlan网络中使用OVS提供者网桥（Provider Bridge），命名为Br-ethx（x为物理网卡的名称的编号）；在vxlan、gre和geneve叠加网络中使用OVS隧道网桥（Tunnel Bridge），命名为Br-tun，另外在local网络中不需要任何OVS物理连接网桥。
• 物理网络接口：用于连接到物理网络，命名为ethx（x为物理网卡的名称中的编号）

（3）open vswitch网络的逻辑结构
与linux bridge代理不同，open vswitch代理不通过eth1.101、eth1.102等vlan接口隔离不同的vlan，所有的虚拟机都连接到一个网桥br-int，open vswitch通过配置br-int和br-ethx上的流规则（Flow rule）来进行vlan转换，进而实现vlan之间的隔离，例如内部标签分别为1和2，而物理网络的vlan标签是101和102，当br-eth1网桥上的phy-br-eth1端口接收到一个vlan1标记的数据包时，会将其中的vlan1转换为vlan101；当br-int网桥上的init-br-eth1端口收到一个vlan101标记的数据包时。会将其中的vlan101转换为vlan1.
下面是以vlan网络为例子open vswitch网络的逻辑结构：

DHCP代理

openstack的实例在启动过程中能够从neutron提供的DHCP服务自动获取IP地址
1、DHCP主要组件
（1）DHCP代理（neutron-dhcp-agent）：为项目提供DHCP功能，提供元数据请求（Metadata request）服务
（2）DHCP驱动：用于管理DHCP服务器，默认为DNSmasq，这是有1个提供DHCP和DNS服务的开源软件，提供DNS缓存和DHCP服务功能。
（3）DNCP代理调度器（Agent Scheduler）：负责DHCP代理与网络（Network）的调度
2、DHCP代理的主要任务
neutron DHCP提供两类REST API接口：Agent Managerment Extension API和Agent Scheduler Extension API，这两类API都是extension API DHCP代理，是核心组件，完成以下任务。
（1）定期报告DHCP代理的网络状态，通过RPC报告给neutron-server，然后通过Core Plugin报告给数据库并进行更新网络状态。
（2）启动dnsmasq进程，检测qdhcp-xxx名称（Namespace）中的ns-xxx端口接收到的DHCPDISCOVER请求，在启动dnsmasq进程过程中，决定是否需要创建名称空间中的ns-xxx端口，是否需要配置名称空间中的iptables，是否需要刷新dnsmasq进程所需的配置文件。
创建网络（network）并在子网（subnet）上启用DHCP时，网络节点上的DHCP代理会启动一个dnsmasq进程为网络提供DHCP服务。dnsmasq与网络（network）是一一对应关系，一个dnsmasq进程可为统一网络中所有启动DHCP的子网（subnet）提供服务
3、DHCP代理配置文件
DHCP代理配置文件是/etc/neutron/dhcp_ agent.ini，其中有重要的配置选项有两个。

[root@ct ~(keystone_ admin)]# grep -vE '^#|^$' /etc/neutron/dhcp_agent.ini
[DEFAULT]
interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver
resync_interval=30
enable_isolated_metadata=False
enable_metadata_network=False
debug=False
state_path=/var/lib/ neutron
root_helper=sudo neutron-rootwrap /etc/neutron/rootwrap.conf
[agent]
[ovs]

（1）interface_driver：用来创建Tap设备的接口驱动，如果使用linux bridge连接，该值设为neutron.agent.linux.interface.BridgeInterfaceDriver；如果选择open vswitch，该值设为neutron.agent.linux.interface.OVSInterfaceDriver
（2）dhcp_driver：指定DHCP启动，默认值为neutron.agent.linux.dhcp.Dnsmasq，表示dnsmasq进程来实现DHCP服务
4、DHCP代理工作机制
DHCP代理运行在网络节点上，DHCP为项目网络提供DHCP服务IP地址动态分配，另外还会提供源数据请求服务，工作机制如下：

通过DHCP获取IP地址过程如下
（1）创建实例时，Neutron随机生成MAC并从配置数据中分配一个固定的IP地址，一起保存到dnsmasq的hosts文件中，让dnsmasq进程做好准备。
（2）与此同时，Nova-compute会设置Mac地址。
（3）实例启动，发出DHCPDISCOVER广播，该广播消息在整个网络中都可以被收到。
（4）广播消息到达dnsmasq监听Tap接口，dnsmasg收到后检查hosts文件，发现有对应项，它以DHCPOFFER消息将IP和网关IP发回到虚拟机实例
（5）虛拟机实例发回DHCPREQUEST消息确认接收DHCPOFFER
（6）dnsmasq发回确认消息DHCPACK，整个过程结束。

Linux网络名称空间

在介绍DHCP服务时提到的linux网络名称空间（Network Namespace简称netns）是linux提供的一种内核级别的网络环境隔离方法，Namespace也可以翻译成为命名空间或者叫名字空间。当前linux支持6种不同类型的名称空间，网络名称空间是其中一种，在二层网络上，VLAN可以将一个屋里交换机分割几个独立的虚拟交换机。类似的，在三层网络上，Linux网络名称空间可以将一个物理三层网络分成几个独立的虚拟三层网络，作为一种资源虚拟机隔离机制。
1、Linux网络名称空间概述
在Linux中，网络空间可以被认为是隔离的拥有单独网线栈（网络接口、路由、iptables等）的环境，它经常来隔离网络资源（设备和服务），只有拥有同样网络名称空间的设备才能批次访问。它还能提供在名称空间内运行进程的功能，后台进程可以运行不同名称空间内的相同端口上，用户还可以虚拟出一块网卡。
可以创建一个完全独立的全新网络环境，包括独立的网络接口、路由表、ABR表，IP地址表、iptables或ebtables等，与网络有关的组件都是独立的。
通常情况下可以使用ip netns add命令添加新的网络名称空间，使用ip netns list命令查看所有的网络名称空间。
执行以下命令进入指定的网络名称空间
ip netns exec netns名称 命令
可以在指定的虚拟环境中运行任何命令，例如以下命令：
ip netns exec net001 bash
又如，为虚拟网络环境netns0的eth0接口增加IP地址
ip netns exec netns0 ip address add 10.0.1.1/24 eth0
网络名称空间内部通信没有问题，但是被隔离的网络名称空间之间要进行通信，就必须采用特定的方法，即VETH对，VETH对是一种成对出现的网络设备，它们像一根虚拟的网络线，可用于连接两个名称空间，向VETH对一端输入的数据将自动转发到另外一端。例如创建两个网络名称空间的netns1和netns2并使他们之间通信，可以执行以下步骤。
（1）创建两个网络名称空间
ip netns add netns1
ip netns add netns2
（2）创建一个VETH对
ip link add veth1 type veth peer name veth2
创建的一对VETH虚拟接口类似管道（pipe），发给veth1的数据包可以在veth2收到，发给veth2的数据包可以在veth1收到，相当于安装两个接口并用网线连接起来
（3）将上述两个VETH虚拟接口分别放置到另个网络名称空间中
ip link set veth1 netns netns1
ip link set veth1 netns netns2
这样两个VETH虚拟接口就分别出现在两个网络名称空间中，两个空间就联通了，其中对的设备就可以相互访问。
2、linux网络名称空间实现DHCP服务隔离
Neutron通过网络名称空间为每个网络提供独立的DHCP和路由服务，从而允许项目创建重叠的网络，如果没有这种隔离机制，网络就不能重叠，这样就失去了很多的灵活性
每个dnsmasq进程都位于独立的网络名称空间，命名为qdhcp-xxx
以创建flat网络为例，Neutron自动新建该网络对应的网桥brqxxx，以及DHCP的Tap设备tapxxx。物理主机本身也有一个网络名称空间，称为root，拥有一个回环设备（Loopback Device），如果DHCP的Tap虚拟接口放置到qdhcp-xxx名称空间，该Tap虚拟接口将无法直接与root名称空间中网桥设备brqxxx连接，为此，Neutron使用VETH对来解决这个问题，添加VETH对tapxxx与ns-xxx，让qdhcp-xxx连接到brqxxx
3、Linux网络名称空间实现路由器
Neutron允许在不同的网络中的子网CIDR和IP地址重叠，具有相同的IP地址的两个虚拟机也不会产生冲突，这是由于Neutron的路由器通过Linux网络名称空间实现的，每个路由器有自己独立的路由表。

Neutron路由器

Neutron路由器是一个三层的（L3）网络的抽象，其模拟物理路由器，为用户提供路由、NAT等服务，在openstack网络中，不同子网之间的通信需要路由器，项目网络与外部网络之间的通信更需要路由器。
Neutron提供虚拟路由器，也支持物理路由器。例如，两个隔离的VLAN网络之间需要实现通信，可以通过物理路由实现，由物理路由器提供相应的IP路由表，确保两个IP子网之间的通信，将两个VLAN网络中的虚拟机默认网关分别设置为路由器接口A和B的IP地址。VLAN A中的虚拟机要与VLAN B中的虚拟机通信时，数据包将通过VLAN A中的物理网卡到达路由器，由物理路由器转发到VLAN B中的物理网卡，再到目的虚拟机。

Neutron的虚拟路由器使用软件模拟物理路由器，路由器实现机制相同 。Neutron的路由服务由L3代理提供。

L3代理

在Neutron中L3代理(neutron-l3agent)具有相当重要的地位。他不仅提供虚拟机路由器，而且通过iptables提供地址转换(SNAT DNAT)、浮动地址(Floating IP)和安全组(security group)功能，L3代理利用Linux IP栈、路由和iptables来实现内部网络中不同网络的虚拟机实例之间的通信，以及虚拟机实例和外部网络之间的网络流量路由和转发，L3代理可以部署在控制节点或者网络节点上
1、路由(Routing)
L3代理提供的虚拟机路由器通过虚拟接口连接到子网，一个子网一一个接口，该接口的地址是该子网的网关地址，虚拟机的IP地址栈如果发现数据包的目的IP地址不在本网段，则会将其发到路由器上对应其子网的虚拟机接口,然后，虚拟机路由器根据配置的路由规则和目的IP地址将包转发到目的端口发出。
L3代理会将每个路由器创建一个网络名称空间，通过VETH对与Tap相连，然后将网关IP配置在位于名称空间的VETH接口上，这样就能够提供路由，网络节点如果不支持linux名称空间，则只能运行一个虚拟路由器。
2、通过网络名称空间支持网络重叠
在云环境下用户可以按照自己的规划创建网络，不同的项目(租户)的网络IP地址可能会重叠，为实现此功能，L3 代理使用linux网络名称空间来提供隔离的转发上下文，隔离不同的项目(租户)的网络，每个L3代理运行在一个名称空间中。
每个名称空间由： *grouter-*命名
3、源地址转换（Source Network Address Translation，SNAT）
L3代理通过在iptables表中增加POSTROUTING链来实现源地址转换，既内网计算机访问外网时，发起访问的内网IP地址(源IP地址)转换为外网网关的IP地址。这种功能让虚拟机实例能够直接访问外网。不过外网计算机还不能直接访问虚拟机实例，因为实例没有外网IP地址，而目的地址转化就能解决这一问题。
项目(租户)网络连接到Neutron路由器，通常将路由器作为默认的网关，当路由器收到实例的数据包并将其转发到外网时。路由器会将数据包的源地址修改成自己的外网地址，确保数据包转发到外网，并能够从外网返回，路由器修改返回的数据包，并转发之前发起访问的实例。
4、目的地址转换（Destination Network Address Translation，DNAT） 与浮动IP地址
Neutron需要设置浮动IP地址支持从外网访问项目(租户)网络中的实例。每个浮动IP唯一对应一个路由器；浮动IP到关联的端口，在到所在的子网，最后到包含该子网及外部子网路由器。创建浮动IP时。在Neutron分配IP地址后，通过RPC通知该浮动IP地址对应的路由器去设置该浮动IP对应的iptabels规则，从外网访问虚拟机实例时，目的IP地址为实例的浮动IP地址，因此必须由lptables将其转化成固定的IP地址，然后在将其路由到实例。L3 代理通过在iptables表中增加POSTROUTING链来实现地址转换。
浮动IP地址是提供静态NAT功能，建立外网IP地址与实例所在的项目(租户网络) IP地址的一对一映射，浮动IP地址配置在路由器提供网关的外网接口上，而不是在实例中，路由器会根据通信的方向修改数据包的源或者是目的地址，这是通过在路由器上应用iptables的NAT规则实现的。
一旦设置浮动IP地址后，源地址转换就不在使用外网关的IP地址了，而是直接使用对应的浮动IP地址，虽然相关的NAT规则依然存在，但是neutron-l3-agent-float-snat比neutron-l3-agent-snat更早执行。
5、安全组（Security Group）
安全组定义了哪些进入的网络流量能被转发给虚拟机实例。安全组包含一些防火墙策略，称为安全组规则（Security Grouprule） ,可以定义若干个安全组。每个安全组可以有若干条规则。可以给每个实例绑定若干个安全组。
安全组的原理是通过iptables对所在的计算机节点的网络流量进行过滤。安全组规则作用在实例的端口上，具体是在连接实例的计算节点上的linux网桥上实施。

FWaas

1、概述
FWaas（Firewall-as- a-Service）是一种基于Neutron L3 Agent的虚拟防火墙，是Neutron的一个高级服务。通过他，OpenStack可以将防火墙应用到项目(租户)、路由器、路由器端口和虚拟机端口，在子网边界上对三层和四层的流量进行过滤。
传统的网络中的防火墙一般在网关上，用来控制子网之间的访问。FWaas的原理也是一样，在Neutron路由上应用防火墙规则，控制进出项目(租户)网络的数据。防火墙必须关联某个策略（Policy） 。策略是规则（rule） 的集合，防火墙会按顺序执行策略中的每一条规则。规则是访问控制的规则，由源目的子网IP、源目的端口、协议、允许(Allow)和拒绝(Deny) 动作组成。
安全组是最早的网络安全模块，其应用对象是虚拟网卡，在计算机节点上通过iptables规则控制进出实例虚拟网卡的流量。FWaas的应用对象是虚拟路由器，可以在安全组之前控制从外部传入的流量，但是对于同一个子网内的流量不做限制。安全组保护的是实例，而FWaas保护的是子网，两者互为补充，通常部署FWaas和安全组来实现双重防护。
2、两个版本：FWaasV1与FWaas V2
FWaas V1是传统方防火墙方案，对路由器提供保护，将防火墙应用到路由器时，该路由器的所有内部端口受到保护，其中虚拟机2进出的数据流都会得到防火墙保护。
新的版本的FWaasV2提供了更具细粒度的安全服务，防火墙的概念防火墙组(firewall group)代替，一个防火墙包括两项策略：入口策略（ingress policy）和出口（egress policy）。防火墙组不再用于路由器级（路由器全部端口）而是路由器端口，注意，FWaas V2的配置仅提供命令行工具，不支持dashboard图形页面。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hUXZxRDA-1583737752277)(C:\Users\Larry\AppData\Roaming\Typora\typora-user-images\1583410124114.png)]

的数据流都会得到防火墙保护。
新的版本的FWaasV2提供了更具细粒度的安全服务，防火墙的概念防火墙组(firewall group)代替，一个防火墙包括两项策略：入口策略（ingress policy）和出口（egress policy）。防火墙组不再用于路由器级（路由器全部端口）而是路由器端口，注意，FWaas V2的配置仅提供命令行工具，不支持dashboard图形页面。