目录

• 相关概念
• • 一、Neutron网络项目
  • 二、Linux虚拟网络
  • 三、openstack网络基础服务
  • • 1、Neutron网络结构
    • 2、网络子网和端口
    • 3、网络拓扑类型
    • 4、网络基本架构
    • 5、Neutron-server
  • 四、Neutron主要插件、代理和服务
  • • 1、典型的主机节点部署
    • 2、ML2插件
    • 3、Linux Bridge代理
    • 4、Open vSwitch代理
    • 5、DHCP代理
    • 6、Linux网络名称空间（租户）
    • 7、Neutron路由器
    • 8、L3代理
    • • （1）路由（routing）
      • （2）通过网络名称空间支持网络重叠
      • （3）源地址转换（SNAT）
      • （4）目的地址转换（DNAT)
      • （5）安全组（Security Group）
    • 9、FWaas(虚拟防火墙)
  • 五、Neutron网络配置和管理
  • • 1、提供者网络
    • 2、自服务网络

相关概念

一、Neutron网络项目

• Neutron是openstack核心项目之一，提供云计算环境下的虚拟网络功能。
• Neutron为整个openstack环境提供软件定义网络支持
  • 主要功能包括二层交换、三层路由、防火墙、VPN, 以及负载均衡等。
• Neutron在由其他openstack服务 (如nova)管理的网络接口设备 (如虚拟网卡)之间提供网络连接即服务。

二、Linux虚拟网络

linux网络虚拟化
Neutron最核心的任务：对二层物理网络进行抽象和管理

传统物理网络与虚拟化网络的区别

• 传统物理网络
  • 使用多个物理服务器
  • 使用物理网络设置
• 虚拟化网络
  • 将多个虚拟机部署在一台物理服务器，减少了物理服务器的数量
    • 虚拟机由虚拟机管理器(Hypervisor)统一管理
    • 在Linux系统中Hypervisor通常采用kvm。
  • 网络虚拟化，减少了物理网络设置的数量
    • Hypervisor为虚拟机创建一个或多个虚拟网卡(vNIC)，虚拟网卡等同于虚拟机的物理网卡。
    • 物理交换机在虚拟网络中被虚拟为虚拟交换机(vSwitch)
    • 虚拟机的虚拟网卡连接到虚拟交换机上，虚拟机交换机再通过物理主机的物理网卡连接到外部网络。
• 对于物理网络来说,虚拟化的主要工作是对网卡和交换设备的虚拟化。

网络虚拟化中几个关键的组件

• 虚拟网桥（即虚拟交换机）
  • 网桥接口连着虚拟网卡，网桥接口名称通常以vnet开头；
    • 例：虚拟网卡1连接vnet0，虚拟网卡2连接vnet1，虚拟网卡3连接vnet2
  • 网桥接口连着虚拟网桥，虚拟网桥以br开头；
    • 例如vnet0和vnet1连接br1，vnet2连接br2
  • 虚拟网桥分别连着物理主机的物理网卡；
    • 例如br1连接物理网卡1，br2连着物理网卡2
• 虚拟局域网（即vlan）
  • 防止广播风暴的产生
  • 划分VLAN区域，一个VLAN含有多台虚拟机，一个VLAN的虚拟机相当于连接同一网桥
  • 虚拟化环境中，会将网桥划分到不同的VLAN中
  • VLAN的协议是802.1Q
• 开放虚拟交换机（open vSwitch）
  • 和硬件交换机拥有一样的特性，可以在不同虚拟平台上移植
  • 在虚拟交换机上使用open vSwitch技术，可以使虚拟网络的管理、网络状态和流量的监控更加的轻松
  • 可以在云环境中的虚拟化平台上实现分布式虚拟交换机
  • 也可以将不同主机上的open vSwitch交换机连接起来，形成一个大规模的虚拟网络

三、openstack网络基础服务

OpenStack网络服务提供一个API让用户在云中建立和定义网络连接。该网络服务的项目名称是Neutron。OpenStack网络负责创建和管理虚拟网络基础架构，包括网络、交换机、子网和路由器，这些设备由OpenStack计算服务Nova管理。同时，网络服务还提供防火墙和VPN这样的高级服务。可以将网络服务部署到特定主机上。OpenStack网络组件与身份服务、计算服务和仪表板等多个OpenStack组件进行整合

1、Neutron网络结构

一个简化的典型的Neutron网络结构，包括一个外部网络、一个内部网络和一个路由器。

• 外部网络：负责连接OpenStack项目之外的网络环境，又称公共网络。
  • 与其他网络不同，它不仅仅是一个虚拟网络，更重要的是，它表示OpenStack网络能被外部物理网络接入并访问。
  • 外部网络可能是企业的局域网(Intranet)，也可能是互联网(Internet) ，这类网络并不是由Neutron直接管理。
• 内部网络：完全由软件定义，又称私有网络。
  • 它是虚拟机实例所在的网络，能够直接连接到虚拟机。
  • 项目用户可以创建自己的内部网络。
  • 默认情况下，项目之间的内部网络是相互隔离的，不能共享。
  • 该网络由Neutron直接配置与管理。
• 路由器：用于将内部网络与外部网络连接起来，因此，要使虚拟机访问外部网络，必须创建一个路由器。

Neutron需要实现的主要是内部网络和路由器。内部网络是对二层(L2)网络的抽象，模拟物理网络的二层局域网，对于项目来说，它是私有的。路由器则是对三层(L3)网络的抽象，模拟物理路由器，为用户提供路由、NAT等服务。

2、网络子网和端口

• 网络：一个隔离的二层广播域，类似交换机中的VLAN。
  • Neutron支持多种类型的网络， 如FLAT、VLAN、VXLAN等。
• 子网：一个IPV4或者IPV6的地址段及其相关配置状态。
  • 虚拟机实例的IP地址从子网中分配。
  • 每个子网需要定义IP地址的范围和掩码(这个有点像DHCP中定义的作用域的概念)。
• 端口：连接设备的连接点，类似虚拟交换机上的一个网络端口。
  • 端口定义了MAC地址和IP地址，当虚拟机的虚拟网卡绑定到端口时，端口会将MAC和IP分配给该虚拟网卡。

通常可以创建和配置网络、子网和端口来为项目搭建虚拟网络。网络必须属于某个项目，一个项目中可以创建多个网络。一个子网只能属于某个网络，一个网络可以有多个子网。一个端口必须属于某个子网，一个子网可以有多个端口。

3、网络拓扑类型

• Local
  • Local网络与其他网络和节点隔离。
  • 该网络中的虚拟机实例只能与位于同一节点上同一网络的虚拟机实例通信，实际意义不大，主要用于测试环境。
  • 位于同一Local网络的实例之间可以通信，位于不同Local网络的示例之间无法通信。
  • 一个Local网络只能位于同一个物理节点上，无法跨节点部署。
• Flat
  • Flat是一种简单的扁平网络拓扑，所有的虚拟机实例都连接在同一网络中，能与位于同一网络的实例进行通信，并且可以跨多个节点。
  • 这种网络不使用VLAN，没有对数据包打VLAN标签，无法进行网络隔离。
  • Flat是基于不使用VLAN的物理网络实施的虚拟网络。
  • 每个物理网络最多只能实现一个虚拟网络。
• VLAN
  • VLAN是支持802.1q协议的虚拟局域网，使用VLAN标签标记数据包，实现网络隔离。
  • 同一VLAN网络中的实例可以通信，不同VLAN网络中的实例只能通过路由器来通信。
  • VLAN网络可以跨节点。
• VXLAN
  • VXLAN (虚拟扩展局域网)可以看作是VLAN的一种扩展，相比于VLAN，它有更大的扩展性和灵活性，是目前支持大规模多租房网络环境的解决方案。
  • 由于VLAN包头部限长是12位， 导致VLAN的数量限制是4096 (2¹²) 个，不能满足网络空间日益增长的需求。
  • 目前VXLAN的封包头部有24位用作VXLAN标识符(VNID)来区分VXLAN网段，最多可以支持16777216 (2²⁴) 个网段。
  • VXLAN使用STP防止环路，导致一半的网络路径被阻断。
  • VXLAN的数据包是封装到UDP通过三层传输和转发的，可以完整地利用三层路由，能克服VLAN和物理网络基础设施的限制，更好地利用已有的网络路径。
• GRE
  • GRE (通用路由封装)是用一种网络层协议去封装另一种网络层协议的隧道技术。
  • GRE的隧道由两端的源IP地址和目的IP地址定义，它允许用户使用IP封装IP等协议，并支持全部的路由协议。
  • 在OpenStack环境中使用GRE意味着"IP over IP”，GRE与VXLAN的主要区别在于，它是使用IP包而非UDP进行封装的。
• GENEVE
  • GENEVE(通用网络虚拟封装)的目标宣称是仅定义封装数据格式，尽可能实现数据格式的弹性和扩展性。
  • GENEVE封装的包通过标准的网络设备传送，即通过单播或多播寻址，包从一个隧道端点传送到另一个或多个隧道端点。
  • GENEVE帧格式由一个封装在IPV4或IPV6的UDP里的简化的隧道头部组成。
  • GENEVE推出的主要目的是为了解决封装时添加的元数据信息问题(到底多少位，怎么用GENEVE自动识别与调整) ，以适应各种虚拟化场景。

小结：
随着目前互联网技术的发展，对于网络部分，使用虚拟化的方案，实现对传统网络（承载网络，Underlay）的扩展，利用叠加网络（Overlay ）的方式，常用的叠加网络VXLAN、GRE和GENEVE。
Overlay网络无须对基础网络进行大规模修改，不用关心这些底层实现，是实现云网融合的关键。

4、网络基本架构

• Neutron仅有一个主要服务进程neutron-server。
  • 它是运行在控制节点上的，对外提供Openstack网络API作为访问Neutron的入口，收到请求后调用插件进行处理，最终由计算节点和网络节点上的各种代理完成请求。
• 网络提供者是指提供OpenStack网络服务的虚拟或物理网络设备
  • 如Linux Bridge、Open vSwitch
  • 或者其他支持Neutron的物理交换机。
• 与其他服务一样，Neutron的各组件服务之间需要相互协调和通信
  • neutron-server、插件和代理之间通过消息队列进行通信和相互调用。
• 数据库用于存放OpenStack的网络状态信息
  • 例如：网络、子网、端口、路由器等。
• 客户端是指使用Neutron服务的应用程序，可以是命令行工具、Horizon和Nova计算服务等。

实例：以一个创建VLAN 100虚拟网络的流程为例说明这些组件如何协同工作。

• neutron-server收到创建网络的请求，通过消息队列通知已注册的Linux Bridge插件。(插件可以有很多，这里举例创建虚拟网络的插件是Linux Bridge插件)
• 该插件将要创建的网络信息(如名称、VLAN ID等)保存到数据库中，并通过消息队列通知运行在各节点上的代理
• 代理收到消息后会在节点上的物理网卡上创建VLAN设备(比如eth1.100)，并创建一个网桥(比如brqxxx)来桥接VLAN设备。

5、Neutron-server

• RESTful API：直接对客户端提供API服务，属于最前端的API，包括Core API和Extension API两种类型。
  • Core API提供管理网络、子网和端口核心资源的RESTful API;
  • Extension API则提供管理路由器、防火墙、负载均衡、安全组等扩展资源的RESTful API。
• Common Service:通用服务，负责对API请求进行检验、认证，并授权。
• Neutron Core:核心处理程序，调用相应的插件API来处理API请求。
• Plugin API:定义插件的抽象功能集合，提供调用插件的API接口，包括Core Plugin API 和 Extension Plugin API两种类型。
  • Neutron Core通过Core Plugin API调用相应的Core Plugin
  • Neutron Core通过Extension Plugin API调用相应的Service Plugin

四、Neutron主要插件、代理和服务

Neutron遵循OpenStack的设计原则，采用开放性架构，通过插件、代理和网络提供者的配合来实现各种网络功能。

• 插件是Neutron的一种API的后端实现，目的是增强扩展性。
• 插件按照功能可分为CorePlugin和Service Plugin两种类型。
  • Core Plugin提供基础二层虚拟机网络支持，实现网络、子网和端口核心资源的支持。
  • Service plugin是指Core Plugin之外的其他插件，提供路由器、防火墙、安全组、负载均衡等服务支持。
    • 直到OpenStack的Havana版本，Neutron才开始提供一个名为L3 RouterService Plugin的插件支持路由服务。
• 插件由Neutron-server 的Core Plugin API和Extension Plugin API调用
  • 用于确定具体的网络功能，要配什么样的网络
• 工作流程：插件处理Neutron-Server发来的请求
  • 主要职责是在数据库中维护Neutron网络的状态信息(更新Neutron数据库)，通知相应的代理实现具体的网络功能。
  • 每一个插件支持一组API资源并完成特定操作，这些操作最终由插件通过RPC调用相应的代理(Agent)来完成。
  • 代理处理插件转来的请求，负责在网络提供者上真正实现各种网络功能。
  • 代理使用物理网络设备或者虚拟化技术完成实际的操作任务，如用于路由具体操作L3 Agent。

插件和代理与网络提供者配套使用，比如网络提供者是Linux Bridge，就需要使用LinuxBridge的插件和代理，如换成OpenySwitch,则需要改成相应的插件和代理。

1、典型的主机节点部署

Neutron与其他OpenStack服务组件系统工作，可以部署在多个物理主机节点上，主要涉及控制节点、网络节点计算节点，每个节点可以部署多个,典型的主机节点部署介绍如下
控制节点和计算节点的结合

控制节点上部署Neutron-service (API)、Core Plugin和Service Plugin的代理，这些代理包括neutron-plugin-agent、neutron-medadata-agent、neutron-dhcp-agnet、neutron-l3-agent、neutron-lbass-agent等。Core plugin和service plugin已经集成到neutron-server中，不需要运行独立的plugin服务。
计算节点上可以部署Core Plugin、Linux Bridge或Open vSwitch的代理，负责体提供二层网络功能。
控制节点和计算节点都需要部署Core Plugin的代理，因为控制节点与计算节点通过该代理，才能建立二层连接。

控制节点和网络节点的结合

可以通过增加网络节点承担更大的负载，该方案特别适合规模较大的OpenStack环境
控制节点部署Neutron-server服务，只负责通过Neutron-server响应的API请求。（水平扩展）
网络节点部署的服务包括Core Plugin的代理和service Plugin的代理。将所有的代理主键从上述控制节点分离出来，部署到独立的网络节点上，由独立的网络节点实现数据的交换，路由以及负责均衡等高级网络服务。

2、ML2插件

之前使用Neutron项目时，开发人员发现了两个突出的问题：

• 第一个问题：多种网络提供者无法共存
  • 一个Neutron网络只能由一个插件管理
  • Core Plugin负责管理和维护Neutron二层的虚拟网络的状态信息，Core Plugin插件与相应的代理是一一对应的
  • Linux Bridge插件，只能选择Linux Bridge代理,必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机。
• 第二个问题：开发插件的工作量太大
  • 所有传统的CorePlugin之间存在大量重复的代码(如数据库访问代码)

而从OpenStack的Havana 版本开始，Neutron 中出现一个插件ML2(Moduler Layer2)，ML2的出现取代了所有Core Plugin，允许在OpenStacks网络中同时使用多种二层的网络技术，不同的节点可以使用不同的网络实现机制，ML2能够与现在所有的代理无缝集成，以前使用费的代理无需变更，只要将传统的Core Plugin替换ML2。ML2使openstack对先的网络技术的支持更加简单，无需从头开发Core Plugin，只需开发相应的机制驱动，大大减少编写的代码。

ML2插件架构详解

ML2对二层的网络进行抽象，解锁了Neutron所支持的网络类型（Type）与访问这些网络类型的虚拟网络实现机制（Mechansim），并通过驱动的形式进行扩展，不同的网络类型对应不同的类型的驱动（Type Driver），由类型管理器（Type Manager）进行管理，不同的网络实现机制对应不同的机制驱动（Mechasiom Driver），由机制管理器（Mechasim Manager）进行管理。这种ML2实现框架具有弹性，易于扩展，能够能活支持多种网络类型和实现机制

类型驱动（Type Driver）

Neutron支持的每一种网络类型都有一个对应的ML2类型驱动，类型驱动负责维护网络类型的状态，执行验证、创建网络等工作。目前Neutron已经实现的网络类型包括Flat、Local、Vlan、Vxlan、Gre

机制驱动（Mechansim Driver）

Neutron支持的每一种网络机制都有一个对应的ML2机制驱动
机制驱动负责获取类型驱动维护的网络状态，确保在相应的网络设备（物理或者虚拟的）上正确实现这些状态

类型驱动vlan，机制驱动为Linux Bridge，如果创建vlan10，那么vlan的类型驱动会确保将vlan10的信息保存到Neutron数据库中，包括网络的名称、vlan ID等，而Linux bridge机制驱动会确保各个节点上Linux Bridge代理在物理网卡上创建ID为10的vlan设备和bridge设备，并且将二者进行桥接
Neutron的网络机制有3种类型
基于代理（Agent-based）：包括Linux bridge、Openvswitch
基于控制器（controller-based）：包括OpenStacDaylight、VMware NSX等
基于物理交换：Cisco Nexus、Arista、Mellanox等

扩展资源

ML2作为一个Core Plugin，在实现网络、子网和端口核心资源的同事，也实现了包括端口绑定（port Bindings）、安全组（Security Group）等部分扩展资源

3、Linux Bridge代理

• Linux Bridge是成熟可靠的Neutron二层网络虚拟化技术，支持Local、Flat、vlan、Vxlan这四种网络类型
• Linux Bridge可以将一台主机上的多个网卡桥接起来，充当一台交换机，它可以桥接物理网卡，又可以是虚拟网卡。
  • 用于桥接虚拟网卡（虚拟机网卡）的是Tap接口，这是一个虚拟机出来的网络设备，称为Tap设备，作为网桥的一个端口。
  • tap接口在逻辑上与物理接口具有相同的功能，可以接收和发送数据包
• 若选择Linux Bridge代理，在计算节点上数据包从虚拟机发送到物理网卡需要经过以下设备
  • Tap接口（Tap interface）：用于网桥虚拟机的网卡，命令为tap XXX
  • Linux网桥（Linux bridge）：作为二层交换机，命令为brq XXXX
  • VLAN 接口（Vlan interface）：在vlan网络中用于连接网桥，命名为ethx.y(ethx为物理网卡名称，y为vlan ID)
  • VXLAN接口（VXLAN interface）：在vxlan网络中用于连接网桥，命名为vxlan-z（z是vlan ID）
  • 物理网络接口：用于连接到物理网络

4、Open vSwitch代理

与Linux Bridge相比，Open vSwitch（简称OVS）具有几种管控功能，而且性能更加优化，支持更多的功能，目前在Openstack领域为主流。

• OVS代理支持Local、flat、vlan、vxlan、GRE和GENEVE等网络类型
• OVS的设备类型
  • Tap设备：用于网桥连接虚拟机网卡
  • Linux网桥：桥接网络接口（包括虚拟接口）
  • VETH对（VETH Pair）：直接相连的一对虚拟机网络接口
    • 两个虚拟机网络接口一个接受一个发送
    • 用来连接两个虚拟网桥
  • OVS网桥：OVS的核心设备，包括一个OVS集成网桥和一个OVS物理连接网桥。
    • 两个OVS网桥一般通过VETH来对接

数据包流程（在计算节点上的数据包从虚拟机发送到物理网卡）

• Tap接口：用于网桥虚拟机的网卡，命名为tapxxx
• Linu网桥：与LInux bridge不同，命名为qbrxxx（其中编号xxx与tapxxx中相同）
• VETH对：两端分别命名为qvbxxx和qvoxxx（其中编号xxx与tapxxx中相同）
• OVS集成网桥：命名为br-int
  • OVS PATCH端口：两端分别命名为int-br-ethx和phy-br-ethx（x为物理网卡名称的编号）
    • 特殊端口类型，只能在Open vSwitch中使用
  • OVS物理连接网桥：分为两种类型
    • 在flat和vlan网络中使用OVS提供者网桥（provider bridge），命名为br-ethx（x为物理网卡名称的编号）
    • 在vxlan、GRE和GENEVE叠加网络中使用OVS隧道网桥（Tunnel Bridge），命名为Br-tun
    • 另外在local网络中不需要在OVS物理连接网桥
• 物理网路接口：用于连接到物理网络，命名为ethx（x 为物理网卡的名称中的编号）

OVS网络的逻辑结构

所有的虚拟机都连接到同一个网桥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-init网桥上的init-br-eth1端口收到一个vlan101标记的数据包时，会将其中的vlan101转让为vlan1

5、DHCP代理

openstack实例在启动过程中能够从Neutron提供的DHCP服务自动获取IP地址

• DHCP主要组件
  • DHCP代理（neutron-dhcp-agent）：为项目网络提供DHCP功能，提供元数据请求（Metadata request）服务
  • DHCP驱动：用于管理DHCP服务器，默认为DNSmasq，这是有一个提供DHCP和DNS服务的开源软件，提供DNS缓存和DHCP服务功能
  • DHCP代理调度器（Agent-Scheduler）：负责DHCP代理与网络（network）的调度

DHCP代理的主要任务

• ①定期报告DHCP代理的网络状态
  • 通过RPC报告给Neutron-server，然后通过Core Plugin报告给数据库并进行更新网络状态。
• ②启动dnsmasg进程
  • 检测qdhcp-xxx名称空间( Namespace)中的ns-xxx端口接收到DHCP DISCOVER请求

DHCP代理的配置文件
DHCP代理配置文件是/etc/neutron/dhcp_agent.ini

• interface_ driver：用来创建TAP设备的接口驱动
  • 如果使用Linux Bridge连接，该值设为neutron.agent.Linux.interface.BridgelnterfaceDriver
  • 如果选择Open Vswitch,该值为neutron.agnt.linux.interface.OVSInterfaceDriver
• dhcp_ driver：指定DHCP启动
  • 默认值为neutron.agent.linux.dhcp.Dnsmasq表示dnsmasq进程来实现DHCP服务

DHCP代理的工作机制

①创建实例时，Neutron 随机生成MAC并从配置数据中分配一个固定的 IP地址，一起保存到dnsmasg的hosts文件中，让dnsmasq进程做好准备。
②与此同时，Nova-compute 会设置Mac地址。
③实例启动，发出DHCP DISCOVER广播，该广播消息在整个网络中都可以被收到。
④广播消息到达dnsmasq监听Tap接口。dnsmasg收到后检查hosts文件，发现有对应项，它以DHCP OFFER消息将IP和网关IP发回到虚拟机实例。
⑤虚拟机实例发回DHCP REQUEST消息确认接收DHCP OFFER
⑥dnsmasq.发回确认消息DHCPACK，整个过程结束。

6、Linux网络名称空间（租户）

在介绍DHCP服务时提到的linux网络名称空间( Network Namespace简称netns )是linux提供的一种内核级别的网络环境隔离方法，Namespace也可以翻译称为命名空间或者叫名字空间。当前linux支持6种不同类型的名称空间，网络名称空间是其中一种，在二层网络上，VLAN可以将一个物理交换机分割几个独立的虚拟交换机。类似地，在三层网络上，Linux 网络名称空间可以将一个物理三层网络跟个成几个独立的虚拟三层网络。

Linux网络名称空间概述

在Linux中，网络空间可以被认为是隔离的拥有单独网络栈(网络接口、路由、iptables等)的环境，它经常来隔离网络资源(设备和服务)，只有拥有同样网络名称空间的设备才能批次访问。它还能提供了在玩过名称空间内运行进程的功能，后台进程可以运行不同名称空间内的相同端口上，用户还可以虚拟出一块网卡。
可以创建一个完全独立的全新网络环境，包括独立的网络接口、路由表、ARP 表，IP地址表、iptables 或ebtables等，与网络有关的组件都是独立的。

通常情况下可以使用ip netns add命令添加新的网络名称空间，使用ip netns list命令查看所有的网络名称空间。
执行以下命令进入指定的网络名称空间

ip netns exec netns 名称 命令
1

可以在指定的虚拟环境中运行任何命令，如下

ip netns exec net001 bash
1

为虚拟网路环境netns0的Eth0接口增加P地址，如下

ip netns exec netns0 ip address add 10.0.1.1/24 eth0
1

网络名称空间内部通信没有问题，但是被隔离的网络名称空间之间要进行通信，就必须采用特定方法，即VETH对，VETH对是一种成对出现的网络设备，他们像一根虚拟的网络线，可用于连接两个名称空间，向VETH对一端输入的数据将自动转发到另外一端。

例如创建两个网络名称空间的netns1和netns2并使他们之间通信，可以执行以下步骤
①创建两个网络名称空间

ip netns add netns1
ip netns add netns2
1
2

②创建一个VETH对（创建的一-对VETH虚拟接口类似管道(pipe) ，发给veth1的数据包可以在veth2收到，发给veth2的数据包可以在veth1收到，相当于安装两个接[ 1并用网线连接起来）

ip link add veth1 type veth peer name veth2
1

③将上述两个VETH对虚拟接口分别放置到两个网络名称空间中

ip link set veth1 netns netns1
ip link set veth2 netns netns2
1
2

Linux网络名称空间实现DHCP服务隔离

Neutron通过网络名称空间为每个网络提供独立的DHCP和路由服务，从而允许项目创建重叠的网络，如果没有这种隔离机制，网络就不能重叠，这样就失去了很多灵活性
每个dnsmasq.进程都位于独立的网络名称空间，命名为qdhcpxx

以创建flat网络为例

• Neutron自动新建该网络对应的网桥brqfxxx，以及DHCP的Tap设备tapxxx。
• 物理主机本身也有一个网络名称空间，称为root，新创建的名称空间默认只拥有一个回环设备(LoopbackDevice)。
• 如果DHCP的Tap虚拟接口放置到gdhcp-xxx名称空间，该Tap虚拟接口将无法直接与root名称空间中网桥设备brqxxx连接。
• 为此，Neutron使用VETH对来解决这个问题，添加VETH对taxxx与ns-xxx i让gdhce xxx连接到brxxx.

Linux网络名称空间实现路由器

Neutron允许在不同的网络中的子网的CIDR和IP地址重叠，具有相同的IP地址的2个虚拟机也不会产生冲突，这是由于Neutron的路由器通过Linux网络名称空间实现的，每个路由器有自己的独立的路由表

7、Neutron路由器

Neutron路由器是-一个三层的(L3)的抽象，其模拟物理路由器，为用户提供路由、NAT等服务，在OpenStack网络中，不用子网之间的通信需要路由器，项目网络与外部网络之间的通信更需要路由器。

Neutron提供虚拟路由器，也支持物理路由器。例如，两个隔离的VLAN网络之间需要实现通信，可以通过物理路由器实现，由物理路由器提供相应的IP路由表，确保两个IP子网之间的通信，将两个VLAN网络中的虚拟机默认网关分别设置为路由路由器的接口A和B的IP地址。VLANA中的虚拟机要与VLAN B中的虚拟机通信时，数据包将通过VLAN A中的物理网卡到达路由器，由物理路由器转发到VLAN B中的物理网卡，再到达目的虚拟机。
Neutron的虚拟路由器使用软件模拟物理路由器，路由实现机制组网。Neutron的路由服务由L3代理提供

8、L3代理

在Neutron中L3代理(neutron-l3agent)具有相当重要的地位。它不仅提供虚拟机路由器，而且通过iptables提供地址转换(SNAT、DNAT)、浮动地址( Floating IP)和安全组(security group)功能，L3代理利用LInux IP栈、路由和iptables.来实现内部网络中不同网络的虚拟机实例之间的通信，以及虚拟机实例和外部网络之间的网络流量路由和转发，L3代理可以部署在控制节点或者网络节点上

（1）路由（routing）

L3代理提供的虚拟路由器通过虚拟接口连接到子网，一个子网对应一个接口，该接口的地址是该子网的网关地址。
L3代理会将每个路由器创建一个网络名称空间，通过VETH对于TAP相连，然后将网关IP配置在位于名称空间的VETH接口上，这样就能够提供路由。
网络节点如果不支持linux名称空间，则只能运行一个虚拟路由器

（2）通过网络名称空间支持网络重叠

在云环境下用户可以按照自己的规划创建网络，不同的项目( 租户)的网络IP地址可能会重叠，为实现此功能，L3 代理使用linux网络名称空间来提供隔离的转发上下文，隔离不同的项目(租户)的网络，每个L3代理运行在一个名称空间中，每个名称空间由quouter-命名

（3）源地址转换（SNAT）

L3代理通过在iptables表中增加POSTROUTING链来实现源地址转换，既内网计算机访问外网时，发起访问的内网IP地址(源IP地址)转换为外网网关的IP地址。这种功能让虚拟机实例能够直接访问外网。不过外网计算机还不能直接访问虚拟机实例，因为实例没有外网IP地址，而H的地址转化就能解决这一问题。

（4）目的地址转换（DNAT)

Neutron需要设置浮动IP地址支持从外网访问项目(租户)网络中的实例。
每个浮动IP唯一对应一个路由器，浮动IP–>关联的端口–>所在的子网–>包含该子网及外部子网路由器。创建浮动IP时，在Neutron分配IP地址后，通过RPC通知该浮动IP地址对应的路由器去设置该浮动IP对应的iptabels规则，从外网访问虚拟机实例时，目的IP地址为实例的浮动IP地址，因此必须由lptables将其转化成固定的IP地址，然后在将其路由到实例。
浮动IP地址是提供静态NAT功能，建立外网IP地址与实例所在的项目(租户网络) IP地址的一对一映射，浮动IP地址配置在路由器提供网关的外网接口上。

（5）安全组（Security Group）

安全组定义了那些进入的网络流量能被转发给虚拟机实例。安全组包含一些防火墙策略，称为安全组规则( Security Group nule) ,可以定义若干个安全组。每个安全组可以有若千调规则。可以给每个实例绑定若千个安全组
安全组的原理是通过iptables对是咧所在的计算机节点的网络流量进行过滤。安全组规则作用在实例的端口上，具体是在连接实例的计算节点上的linux网桥上实施。

9、FWaas(虚拟防火墙)

Fwaas（firewall-as-a-service)是一种基于Neutron L3 Agent的虚拟防火墙，是Neutron的一个高级服务。通过它，OpenStack 可以将防火墙应用到项目(租户)、路由器、路由器端口和虚拟机端口，在子网边界上对三层和四层的流量进行过滤。
传统的网络中的防火墙一般在网关上,用来控制子网之间的访问。FWaas的原理也是一样，在Neutron路由上应用防火墙规则，控制进出项目(租户)网络的数据。防火墙必须关联某个策略(Policy) 。
FWaas 的应用对象是虑报路由器，可以在安全组之前控制从外部传入的流量，但是对于同一个子网内的流量不做限制，安全组保护的是实例，而FWaas保护的是子网，两者互为补允，通常部客FWaas和安全组来实现双重防护。
补充：
策略是规则(rule) 的集合，防火墙会按顺序因公策略中的每一条规则。规则是访问控制的规则，由源于日的子网IP、源于日的端口、协议、允许Allow)和拒绝(Deny)动作组成
安全组是最早的网络安全模块，其应用对象是虚拟网卡，在计算机节点上通过iptables.规则控制进出实例虑积网卡的流量。

FW版本（FWaasV1与FWaasV2）

• FWaaSv1是传统方后墙方案，对路由器提供保护，将防火墙应用到路由器时，该路由器的所有内部端口受到保护，其中虚拟机2进出的数据流都会得到防火墙保护。
• FWaaSv2提供了更具细粒度的安全服务，FWaaSv2防火墙的概念防火墙组(firewallgroup)代替，一个防火城包括两项策略：入口策略(ingress polie)和出口(egress poliy)。
  • 防火墙组不在用于路由器级(路由器全部端口)，而是路由器端口。
  • 注意，FWaas v2的配置仅提供命令行工具，不支持dashboard图形页面。

五、Neutron网络配置和管理

虚拟网络类型：提供者网络和自服务网络

1、提供者网络

• 提供者网络选项以最简单的方式部署OpenStack网络服务，包括二层服务(桥/交换机)服务、VLAN网络分段。
• 本质上，它建立虚拟网络到物理网络的桥，依靠物理网络基础设施提供三层服务(路由)。
• 提供者网络默认有管理员创建，实际上，就是与物理网络有直接映射关系的虚拟网络，要使用物理网络直接连接虚拟机实例，必须在openstack中将物理网络定义为提供者网络。
• 这种网络可以在多个项目之间共享。
• 虽然可以创建VXLAN或GRE类型的提供者网络，但是只有Flat或VLAN类型的网络拓扑才对提供者网络具有实际意义。
• 提供者网络和物理网络的某个网段直接映射，因此需要预先在物理网络中做好相应的配置。物理网络的每个网段最多只能实现一个提供者网络.

2、自服务网络

• 自服务网络主要目的：让非特权的普通项目自行管理网络，无需管理员介入。
• 这种网络完全是虚拟的。需要通过虚拟焰由器与提供者网络和像Internet这样的外部网络通信。自服务网络也对实例提供DHCP服务和元数据服务。
• 绝大多数情况下，自服务网络使用像VXLAN或GRE这样的Overlay协议，因此这些协议要比使用VLAN标记的二层网终分段支持更多的网络，而且VLAN通常还要求物理网络设施的额外配置
• IPV4自服务网络通过虚拟路由器上的源NAT与提供者网络进行交互进行通信(内部)，浮动IP地址则通过虚拟路由器上的目的NAT让来自提供者网络的用户访问虚拟机实例(外部)。
• 网络服务使用L3代理实现路由器，L3代理至少要部署在一个网络节点上。自服务网络必须有一个L3代理。不过，一个L3代理或网络节点的过载或故障就能影响一大批自服务网络和使用它们的实例。实际部署痍要提供高可用功能来增加冗余，提高自服务网络的性能。
• 用户可以为项目中的连创建项目网络，也就是自服务网络。默认情况下自服务网络被完全隔离，OpenStack网络支持的网络隔离和覆盖技术包括Flat、VLAN、GRE和VLAN等。
• 一个典型自服务网络包括三层路由服务、DHCP服务、不能提供LBaas和FWaas这样高级服务。
  • 虽然自服务网络可以选择Local、Flat、VLAN、VXLAN或GRE等类型，但是Flat和VLAN类型的自服务网络本质上对应于一个实际的物理网段，因此真正有意义的是VXLAN或GRE类型，因为这类Overlay网络本身不依赖于具体的物理网络，只要物理网络能够提供IP多播支持即可。
• 这种虚拟网络中包括自服务网络（作为内部网络）和提供者网络（作为外部网络)，也可以使用
  这两种网络为虚拟机实例提供网络连接。