openstack网络架构

目录

• 1、网络架构
• 2、neutron模块
  • 2.1 plugin
  • 2.2 agent
  • 2.3 neutron的两种部署方式
  • 2.4 neutron server
    • 2.4.1 ML2 Core Plugin
    • 2.4.2 Service Plugin / Agent
    • 2.4.3 neutron架构的小结
  • 2.5 linux bridge实现neutron网络
    • 2.5.1 linux-bridge mechanism driver
    • 2.5.2 linux bridge中的几种网络设备和网络类型
    • 2.5.3 Local Netwrok
    • 2.5.4 Flat Network
    • 2.5.5 DHCP服务
    • 2.5.6 Linux Network NameSpace
    • 2.5.7 VLAN网络
    • 2.5.8 Routing
    • 2.5.9 VXLAN网络
    • 2.5.10 L2 Population
    • 2.5.11 Security Group
    • 2.5.12 Neutron FWaaS
    • 2.5.13 Neutorn LBaaS
  • 2.6 Open vSwitch
    • 2.6.1 Open vSwitch配置
    • 2.6.2 OVS中的网络设备类型
    • 2.6.3 Local Network
    • 2.6.4 Flat Network
    • 2.6.5 Vlan Network
    • 2.6.6 Routing
    • 2.6.7 Vxlan Network

转载自：https://blog.csdn.net/weixin_45537413/article/details/109439837

1、网络架构

openvswitch与linux-bridge相比较而言，openvswitch支持的网络类型更加丰富，应用也比较广泛，因此图示直接使用OVS。linux-bridge支持local, flat, vlan和vxlan 四种network type，目前不支持gre，相比较而言openvswitch支持GRE网络；

OpenStack 至少包含下面几类网络流量

• Management：节点之间 message queue 内部通信以及访问 database 服务；
• API：通过该网络向用户暴露 API 服务；（下图中API网络和管理网络合为一体）
• VM：VM 网络由 Neutron 配置和管理；
• External：External 网络指的是 VM 网络之外的网络，该网络不由 Neutron 管理；

管理网络：用户管理所有节点的网络；

内部网络：计算节点与网络节点通过内部网络通信，tenant network（租户网络，租户自己创建管理，网络之间可以重合）；

外部网络：内部的VM与外部物理网络间使用外部网络通信使用，一般由管理员创建并赋予相应属性，称为public network（或者叫provider network？）；

2、neutron模块

主要包含以下几个部分：

（1）neutron-server：可以理解为类似于nova-api那样的一个组件，一个专门用来接收neutron REST API调用的服务器。负责将不同的rest api发送到不同的neutron-plugin。接受和路由API请求到网络plug-in。一般部署在控制节点（controller），负责通过Neutron-server响应的API请求；

（2）neutron-plugin：可以理解为不同网络功能（例如创建端口（ports）、网络（Networks）、子网（Subnets）等）实现的入口，现在大部分都是软件定义网络，各个厂商都开发自己的plugin(插件)。neutron-plugin接收netron-server发过来的rest api，向neutron database完成一些信息注册（比如用户要建端口）。然后将具体要执行的业务操作和参数通知给自身对应的neutron-agent。Openstack的plug-ins一般支持Open vSwitch、Linux Bridging、思科物理/虚拟交换机等等。一般Core plugin 和service plugin已经集成到neutron-server中，不需要运行独立的plugin服务。

（3）agent：常见的agent包括L3、DHCP、plug-in agent；一般网络节点需要部署Core Plugin的代理和service Plugin的代理，计算节点也需要部署Core Plugin的代理，通过该代理才能建立二层连接。

（4）messaging queue：在neutron-server和agents之间路由信息，同时作为一个数据库存储plug-ins的网络状态；

模块之间调用关系：（此段为摘抄内容）

（5）Client（客户端）是指使用Neutron服务的应用程序，可以是命令行工具（脚本）、Horizon和Nova计算服务等；

（6）Neutron-database（数据库，默认使用MariaDB）用于存放OpenStack的网络状态信息，包括网络、子网、端口、路由器等；

（7）network provider：提供网络服务的物理或者虚拟网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机；

举列说明：创建一个Vlan 10虚拟网络的流程。

• 1、Neutron-server 收到创建网络(Network) 的请求，通过消息队列（RabbitMQ）通知已注册的Linux Bridge插件，这里架设网络提供者为Linux Bridge。
• 2、该插件将要创建的网络信息（如名称、ID值、VLANID等）保存到数据库中并通过消息队列通知运行在各个节点上的代理。
• 3、代理收到信息后会在节点上物理网卡上创建Vlan设备（比如物理接口的子接口 Eth1.10)，并创建一个网桥（比如brgXXX）来桥接网络设备。

2.1 plugin

几点说明：

1. plugin 解决的是 What 的问题，即网络要配置成什么样子？而至于如何配置 How 的工作则交由 agent 完成。
2. plugin，agent 和 network provider 是配套使用的，如果network provider用的linux bridge则使用对应的plugin和agent，若是使用的OVS则使用OVS的plugin和agent；
3. plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息。通过ML2（Modular Layer 2）plugin，各种 network provider 无需开发自己的 plugin，只需要针对 ML2 开发相应的 driver 就可以了；
4. plugin 按照功能分为两类： core plugin 和 service plugin。core plugin 维护 Neutron 的 netowrk, subnet 和 port 相关资源的信息，与 core plugin 对应的 agent 包括 linux bridge, OVS 等； service plugin 提供 routing, firewall, load balance 等服务，也有相应的 agent。

2.2 agent

neutron的agent及相应功能

agent	描述
L3 agent (neutron-l3-agent)	提供L3/NAT转发（路由器），提供租户不同vpc之间的访问以及提供外部网络访问，openstack queens 版本之前是集中式的（即 l3 agent 部署在网络节点上，把网络节点作为虚拟路由器），存在性能瓶颈，queens 版本开始支持分布式（即 l3 agent 运行在所有计算节点上，把计算节点作为分布式虚拟路由器）
dhcp agent (neutron-dhcp-agent)	为租户网络提供dhcp功能，dhcp-agent默认的dhcp driver由dnsmasq软件实现
metering agent (neutron-metering-agent)	提供L3数据流量的监控、计算
metadata agent	是提供一个机制给用户，可以设定每一个instance 的参数
OpenvSwitch agent	使用Open vSwitch来实现VLAN， GRE，VxLAN来实现网络的隔离，还包括了网络流量的转发控制
plug-in agent ( neutron-*-agent )	在每个hypervisor上运行以执行本地vSwitch配置。 这个插件是否运行取决于使用的插件，有些插件不需要代理。
neutron-lbaas-agent	提供LB的服务
neutron-firewall-agent	提供防火墙服务

2.3 neutron的两种部署方式

core plugin和service plugin都已集成到neutron server中，不需要单独部署。

方式一：控制节点+计算节点

• 控制节点：部署的服务包括：neutron server, core plugin 的 agent 和 service plugin 的 agent；
• 计算节点：部署 core plugin 的agent，负责提供二层网络功能；

说明：（1）控制节点和计算节点都需要部署 core plugin 的 agent，因为通过该 agent 控制节点与计算节点才能建立二层连接；（2）可以部署多个控制节点和计算节点；

方式二：控制节点+网络节点+计算节点

• 控制节点：部署的服务包括：neutron server；
• 网络节点：core plugin 的 agent 和 service plugin 的 agent；
• 计算节点：部署 core plugin 的agent，负责提供二层网络功能；

说明：方式二更适合大规模的openstack环境，控制与网络节点分离开，控制节点只通过neutron server响应API请求，然后调用网络节点的plugin插件；网络节点单独拿出来负责数据的交换，路由以及 load balance等高级网络服务。

2.4 neutron server

整体架构：neutron=API+plugin

• Core API：对外提供管理 network, subnet 和 port 的 RESTful API。
• Extension API：对外提供管理 router, load balance, firewall 等资源 的 RESTful API。
• Commnon Service：认证和校验 API 请求。
• Neutron Core：Neutron server 的核心处理程序，通过调用相应的 Plugin 处理请求。
• Core Plugin API：定义了 Core Plgin 的抽象功能集合，Neutron Core 通过该 API 调用相应的 Core Plgin。
• Extension Plugin API：定义了 Service Plgin 的抽象功能集合，Neutron Core 通过该 API 调用相应的 Service Plgin。
• Core Plugin：实现了 Core Plugin API，在数据库中维护 network, subnet 和 port 的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 network。
• Service Plugin：实现了 Extension Plugin API，在数据库中维护 router, load balance, security group 等资源的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 router。

调用关系：通过仪表盘/脚本/Nova调用plugin，plugin再调用对应的agent；

neutron网络的开放性：支持多种network provider。只需要不同的netwrok provider开发出对应的plugin和agent既可。但弊端是（1）只能在 OpenStack 中使用一种 core plugin；（2）不同plugin之间代码重复率高，开发难度大。ML2 Core Plugin解决了传统Core Plugin的这个问题。

2.4.1 ML2 Core Plugin

使用ML2 Core Plugin的需求是：（1）传统Core Plugin无法同时提供多种network provider；（2）开发工作量大。

采用 ML2 plugin 后，可以在不同节点上分别部署 linux bridge agent, open vswitch agent, hyper-v agent 或其他第三方 agent。ML2 不但支持异构部署方案，同时能够与现有的 agent 无缝集成：以前用的 agent 不需要变，只需要将 Neutron server 上的传统 core plugin 替换为 ML2。

ML2 对二层网络进行抽象和建模，引入了 type driver 和 mechansim driver。type driver 负责维护网络类型的状态，执行验证，创建网络等，支持vlan、vxlan、gre、flat、local网络；mechanism driver 负责获取由 type driver 维护的网络状态，并确保在相应的网络设备（物理或虚拟）上正确实现这些状态。

mechanism driver 有三种类型：（1）Agent-based：包括 linux bridge, open vswitch 等。（2）Controller-based：包括 OpenDaylight, VMWare NSX 等。（3）基于物理交换机；此外，涉及L2 population driver，其作用是优化和限制 overlay 网络中的广播流量。

2.4.2 Service Plugin / Agent

Core Plugin/Agent 负责管理核心实体：net, subnet 和 port。而对于更高级的网络服务（防火墙、router、LB等），则由 Service Plugin/Agent 管理。

• DHCP：dhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务；
• Routing：l3 agent 可以为 project（租户）创建 router；
• Firewall：l3 agent 可以在 router 上配置防火墙策略；
• Load Balance：Neutron 默认通过 HAProxy 为 project 中的多个 instance 提供 load balance 服务；

2.4.3 neutron架构的小结

如下图：

1. Neutron server 接收 api 请求。
2. plugin/agent 实现请求。
3. database 保存 neutron 网络状态。
4. message queue 实现组件之间通信。

更深入的理解：

1. Neutron 通过 plugin 和 agent 提供的网络服务。
2. plugin 位于 Neutron server，包括 core plugin 和 service plugin。
3. agent 位于各个节点，负责实现网络服务。
4. core plugin 提供 L2 功能，ML2 是推荐的 plugin。
5. 使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。
6. service plugin 和 agent 提供扩展功能，包括 dhcp, routing, load balance, firewall, vpn 等。

2.5 linux bridge实现neutron网络

2.5.1 linux-bridge mechanism driver

neutron默认使用ml2的service plugin，这个在配置文件有体现：

vi /etc/neutron/neutron.conf

[DEFAULT]
rpc_backend = rabbit
core_plugin = ml2
......

需要在控制节点与计算节点中指定的/etc/neutron/plugins/ml2/ml2_conf.ini的文件中将mechanism_drivers设定为openvswitch或者linux bridge，可以写多个，ML2 会负责加载

[ml2]
type_drivers = vlan,vxlan
tenant_network_types = vlan,vxlan
mechanism_drivers = ml2_h3c,openvswitch
......

2.5.2 linux bridge中的几种网络设备和网络类型

在 linux bridge 环境中，存在下面的网络设备类型（不同的网络里不一样）：

1. tap interface命名为 tapN (N 为 0, 1, 2, 3......)
2. linux bridge命名为 brqXXXX。
3. vlan interface命名为 ethX.Y（X 为 interface 的序号，Y 为 vlan id），存在vlan网络；
4. vxlan interface命名为 vxlan-Z（z 是 VNI），vxlan网络；
5. 物理 interface命名为 ethX（X 为 interface 的序号）

linux-bridge 支持 local, flat, vlan 和 vxlan 四种 network type，目前不支持 gre。

2.5.3 Local Netwrok

local network 的特点是不会与宿主机的任何物理网卡相连，因此该宿主机上的VM不能与宿主机外部的网络通信，完全隔离。对于每个 local netwrok，ML2 linux-bridge 会创建一个 bridge，instance 的 tap 设备会连接到 bridge。对于同一个bridge，其下的instance属于同一个Local network，每个instance通过各自的tap设备连接到bridge，从可以互相通信。不同bridge之间不能相互通信。网络架构如下图所示：

配置文件中需要配置type_drivers的类型有local，/etc/neutron/plugins/ml2/ml2_conf.ini，并设置普通租户创建的网络类型（admin用户可以指定网络类型）

[ml2]
type_drivers = vlan,vxlan
tenant_network_types = vlan,vxlan
mechanism_drivers = ml2_h3c,openvswitch
extension_drivers = ml2_extension_h3c
......

通过WEB GUI创建相应的虚机VM，会自动创建一个port，该port信息包含ip和mac。宿主机根据该port信息创建相应tap设备，tap会关联相应的bridge，同时映射成虚机的虚拟网卡（VIF）。

总结几点：

• 1. 位于同一 local network 的 instance 可以通信。
• 2. 位于不同 local network 的 instance 无法通信。
• 3. 一个 local network 只能位于一个物理节点，无法跨节点。

由于其只限制在单个宿主机中通信，无法跨网络和跨主机，在实际的应用中基本很少用到local network，可以仅作为后续学习复杂网络的基础。

2.5.4 Flat Network

flat network 是不带 tag 的网络，要求宿主机的物理网卡直接与 linux bridge 连接，并且flat network与网卡是一一对应的关系，网络架构如下图所示。

同样，配置文件中需要配置type_drivers的类型为flat网络，/etc/neutron/plugins/ml2/ml2_conf.ini，并设置普通租户创建的网络类型（admin用户可以指定网络类型）

[ml2]
type_drivers = flat
tenant_network_types = flat
......

此外还需要定义flat网络的标签（标签可以为任意字符串，需要保证控制和节点的命名保持一致，且后续在创建flat网络时也需要填写该标签），并制定标签与网卡之间的对应关系（各个计算节点的标签必须一致，但标签网卡对应关系可以不同。可以填写多个标签与各网卡之间一一对应，之间用逗号隔开，因此也就是对应多块网卡）：

2.5.5 DHCP服务

Neutron 提供 DHCP 服务的组件是 DHCP agent。DHCP agent 在网络节点运行上，默认通过 dnsmasq 实现 DHCP 功能。

DHCP agent 的配置文件位于 /etc/neutron/dhcp_agent.ini。（正常来说一般不需要什么特殊配置）

• dhcp_driver：使用 dnsmasq 实现 DHCP。
• interface_driver：使用 linux bridge 连接 DHCP namespace interface。

dnsmasq 是一个提供 DHCP 和 DNS 服务的开源软件。一般一个dnsmasp进程对应一个network，可以为该network内开启了dhcp服务的所有subnet提供服务。DHCP agent 会为每个 network 创建一个目录 /opt/stack/data/neutron/dhcp/，用于存放该 network 的 dnsmasq 配置文件。

dnsmasq 重要的启动参数：（1）--dhcp-hostsfile：存放 DHCP host 信息的文件，dnsmasq 从该文件获取 host 的 IP 与 MAC 的对应关系。 /opt/stack/data/neutron/dhcp/xxx（对应某个netwrok）/host下记录着DHCP、所有VM的Interface信息；（2）--interface：指定提供 DHCP 服务的 interface。dnsmasq 会在该 interface 上监听 instance 的 DHCP 请求；

2.5.6 Linux Network NameSpace

每个 namespace 都有自己独立的网络栈，包括 route table，firewall rule，network interface device 等。Neutron 通过 namespace 为每个 network 提供独立的 DHCP 和路由服务，从而允许租户创建重叠的网络。如果没有 namespace，网络就不能重叠，这样就失去了很多灵活性。

每个 dnsmasq 进程都位于独立的 namespace, 命名为 qdhcp-（每个dnsmasq进程又对应一个network）。ip netns list 命令可以列出所有的namespace。主机本身也有一个 namespace，叫 root namespace，拥有所有物理和虚拟 interface device。物理 interface 只能位于 root namespace。

veth pair：解决了dhcp的interface（tap设备）无法直接与 root namespace 中的 bridge 设备连接。dhcp的ns设备与tap设备被称为一对veth pair，用来将dhcp的namespace连接到root namespace 中的 bridge 设备，可以通过 ip netns exec 管理 namespace。连接关系如下图所示：

一台VM实例创建并启动dhcp获取到ip的过程如下：

1. 在dashboard上创建VM时，neutron会给VM分配一个port，该port包含ip/mac信息，这些信息会自动同步到dnsmasq的host文件，同时compute节点会给创建的VM分配该port对应的mac地址；
2. VM开机启动，发出 DHCP DISCOVER 广播，该广播消息在整个对应的network中（subnet的tap设备）都可以被收到；
3. dhcp广播报文到达DHCP的tap设备，然后传送给veth pair另一端ns设备。dnsmasq在ns设备上面进行侦听，dnsmasq收到其dhcp discover于是对比自己的host文件发现有对应项（应该是通过mac对比），从而将对应的ip地址、掩码、地址租期信息返回给VM
4. VM发送 DHCPREQUEST 消息确认接受此 DHCPOFFER；
5. dnsmasq 发送确认消息 DHCPACK，整个过程结束；

2.5.7 VLAN网络

vlan网络是待tag的网络类型，在实际应用中有较多使用。由于vlan数量有限制（4096），因此不能无限创建vlan。VM通过tap设备连接到对应的网桥上，网桥另一端连接网卡的子接口，数据流量到网卡子接口会被打上vlan tag并传送给网卡主接口，从而实现宿主机上vlan的网络隔离。（一个宿主机网卡可以有多个网卡子接口）

执行vi /etc/neutron/plugins/ml2/ml2_conf.ini配置文件，在ML2中将网络类型修改为vlan，定义标签default，指定普通用户创建网络的vlan范围（admin用户可以使用任意自己指定的vlan），并将标签与物理网卡对应起来。修改如下：（配置完成后重启neutron服务生效）

[ml2]
type_drivers = vlan
tenant_network_types = vlan
......

[ml2_type_vlan]
network_vlan_ranges =  default:1:4094

例如：创建2个vlan网络，同一个vlan内的vm可以相互通信，不同vlan内的vm是不能互相通信，若要使跨vlan通信就必须进行三层互通，这就涉及到Routing功能。对于相同网络vlan网络其在控制节点和计算节点的网桥名称都是一样的，可以从下图看出：

2.5.8 Routing

Neutron 的路由服务是由 l3 agent 提供的。 除此之外，l3_agent 通过 iptables 提供 firewall 和 floating ip 服务。

配置文件为 /etc/neutron/l3_agent.ini，如果 mechanism driver 是 linux bridge，则需要将interface_driver改为BridgeInterfaceDriver；若mechanism driver是OVS，则需要将interface_driver改为OVSInterfaceDriver。l3_agent运行在控制节点或者网络节点上。

当创建完成一个vrouter后，底层网桥会给vrouter的接口分配一个tap设备，TAP设备上不配置ip地址，l3 agent 会为每个 router 创建了一个 namespace（router 对应的 namespace 命名为 qrouter-。），通过 veth pair 与 TAP 相连，然后将 Gateway IP 配置在位于 namespace 里面的 veth interface 上，从而实现三层网络通信。网络架构如下图所示。

• 可以通过ip netns 查看 namespace；
• ip netns exec ip a查看namespace的veth interface地址配置；

讲到这里，需要思考一个问题？为什么vrouter不直接在tap设备上配置网关地址，而是要在namespace的veth接口上配置？-----答案是：在vrouter多做一层namespace可以起到各个租户之间的网络重叠的作用（每个namespace单独一张路由表），而直接在tap设备上配置IP相当于在root的namespace上添加subnet网段的路由（宿主机操作系统上加路由，查的是宿主机的全局路由表），这样的路由时没办法工作的。这个功能在某些特定场合下很重要。

既然已经通过vrouter实现了跨vlan网络的vm通信，那么如果实现vlan网络与外部网络通信呢？这里的外部网络是指的租户网络以外的网络。租户网络是由 Neutron 创建和维护的网络。外部网络不由 Neutron 创建，是已经存在的物理网络，一般都是flat型或者vlan型。

/etc/neutron/plugins/ml2/ml2_conf.ini 配置如下：

若是flat类型网络，需要如下配置：

若是vlan类型网络，则进行如下配置：

在dashboard页面上创建完外部网络并关联vrouter后，会对应创建外部网络的网桥和tap设备，同时也会在vrouter对应的namespace中创建对应于tap设备的veth设备。vrouter 的每个 interface 在 namespace 中都有对应的 veth。如果 veth 用于连接租户网络，命名格式为 qr-xxx，比如 qr-d568ba1a-74 和 qr-e17162c5-00。如果 veth 用于连接外部网络，命名格式为 qg-xxx，比如 qg-b8b32a88-03。整体网络架构如下：

当数据包从 router 连接外网的接口 qg-xxx发出的时候，会做一次 Source NAT，即将包的源地址修改为 router 的外网接口地址，这样就能够保证目的端能够将应答的包发回给 router，然后再转发回源端 instance。可以通过iptables命令查看SNAT的相关规则：

ip netns exec 对应router的namespace iptables -t nat -S

SNAT主要是作为内部VM访问外部网络使用，单外部网络无法直接访问内部VM，此时就需要浮动ip来进行DNAT的转换。

浮动ip必须要知道的几件事：

• floating IP 提供静态 NAT 功能，建立外网 IP 与 instance 租户网络 IP 的一对一映射；
• floating IP 是配置在 router 提供网关的外网 interface 上的，而非 instance 中；
• router 会根据通信的方向修改数据包的源或者目的地址（这句话意思是对于内访外，则修改数据包源地址为float ip；对于外访内，则修改数据包的目的ip为真实VM的ip）；

2.5.9 VXLAN网络

前期讲了flat 网络、vlan网络、local网络，还剩下VXLAN网络和GRE网络，这两种都是Overlay网络。overlay network 是指建立在其他网络上的网络。overlay network 中的节点可以看作通过虚拟（或逻辑）链路连接起来的，不需要关心底层的物理链路。vxlan网络相对于vlan有很强的灵活性和扩展性，主要提现在以下几个方面：

1. 支持更多的二层网段。vlan的使用12 bit标记vlan ID，最多支持4094个VLAN；Vxlan则用24bit标记vlan ID，最多能支持到 16777216二层网段；
2. 能更好的利用现有网络途径。vlan网络通过STP进行防环，一半路径被block；VXLAN则直接用MAC in UDP进行封装，利用三层网络进行转发；
3. 避免物理交换机 MAC 表耗尽。由于采用隧道机制，TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。（现在交换机的MAC规格都很大，不是啥问题）

vxlan报文封装格式如下：

VXLAN Tunnel Endpoint（VTEP）

VXLAN 使用 VXLAN tunnel endpoint (VTEP) 设备处理 VXLAN 的封装和解封。每个 VTEP 有一个 IP interface，配置了一个 IP 地址。VTEP 使用该 IP 封装 Layer 2 frame，并通过该 IP interface 传输和接收封装后的 VXLAN 数据包。VTEP既可以是软件设备（OpenvSwitch）也可以是硬件交换机，VTEP之间建立VXLAN隧道。VXLAN 独立于底层的网络拓扑；反过来，两个 VTEP 之间的底层 IP 网络也独立于 VXLAN。可以用一张图描述数据包在vxlan网络中的传输过程（具体细节就不再阐述，很简单，可以在单独去研究一下vxlan网络架构）：

目前比较成熟的 VTEP 软件实现包括：1. 带 VXLAN 内核模块的 Linux；2. Open vSwitch。第一种方式如下，第二种方式待后续讲解openvSwitch时详细说明。

1. Linux vxlan 创建一个 UDP Socket，默认在 8472 端口监听。
2. Linux vxlan 在 UDP socket 上接收到 vxlan 包后，解包，然后根据其中的 vxlan ID 将它转给某个 vxlan interface，然后再通过它所连接的 linux bridge 转给虚机。
3. Linux vxlan 在收到虚机发来的数据包后，将其封装为多播 UDP 包（同一个vxlan的都会收到），从网卡发出

vxlan网络的配置

需要在 /etc/neutron/plugins/ml2/ml2_conf.ini 设置 vxlan network 相关参数：

[ml2]
type_drivers = vlan,vxlan
tenant_network_types = vxlan
mechanism_drivers = linuxbridge,l2population
extension_drivers = port_security

[ml2_type_vxlan]
vni_ranges = 1:10000

还需要在ml2_conf.ini中设置vtep：

控制节点/网络节点：

计算节点上同样设置，local_ip即为VTEP的ip地址。注意：作为准备工作，这两个 VTEP IP 需要提前配置到节点的 eth1 上，Neutron 并不会帮我们分配这个 IP。并且，值得注意的是，vxlan网络配置中不会特意配置vxlan标签与网卡的对应关系，它是通过VTEP IP来找到要从哪块网卡出去的。

此时通过 brctl show可以知道底层网络的架构，相比于vlan网络而言，没有eth1.100这种子接口的概念，而是直接用vxlan interface来表示（linuxbridge、vxlan-100、eth1网卡可以对应起来，还会针对这个子网创建了一个DHCP的tap设备，也是连接该linuxbridge），可以ip -d link show dev vxlan-100（创建的vxlan网络名）查看vxlan interface的详细配置。架构如下图：

同一个vxlan内，同一个节点上，VM之前通过linuxbridge就可以直接通信，若是跨节点间，则是通过宿主机间vxlan隧道到达另一主机。

以上vxlan网络只是针对同一个二层网络内进行通信，对于跨vxlan以及vxlan网络到外部网络的通信也是需要依靠vrouter与浮动ip来实现，原理和vlan网络是类似的，此处不再继续阐述。

2.5.10 L2 Population

vxlan组网得环境就是一个大二层网络，如果避免在这种大二层网络中的广播报文占用带宽，就需要L2 Population来解决这个问题。L2 Population 是用来提高 VXLAN 网络 Scalability （可以理解为高效运转）。

如下图，VM A要想去访问其他HOST上的同vxlan的节点时会发送arp广播报文，这样整个网络环境里会存在大量的arp广播报文，从而占用网络带宽。此时L2 Population的出现解决了这个问题。

L2 Population可以让HOST开启一个ARP Proxcy的功能，本地的arp广播报文则由本地HOST主机直接响应其arp请求，并使得VTEP能够预先获知 VXLAN 网络的相关信息：（1）VM的IP/MAC信息；（2）VM--VTEP的对应关系。如下图：

那么此时另一个问题又来了，VTEP 是如何提前获知 IP -- MAC -- VTEP 相关信息的呢？答案如下：

1. Neutron 知道每一个 port 的状态和信息； port 保存了 IP，MAC 相关数据。
2. instance 启动时，其 port 状态变化过程为：down -> build -> active。
3. 每当 port 状态发生变化时，Neutron 都会通过 RPC 消息通知各节点上的 Neutron agent，使得 VTEP 能够更新 VM 和 port 的相关信息。

从而每个VTEP都知道了其他（VTEP）HOST上都有哪些VM，这样就大大减少了网络中arp广播报文的带宽占用。

L2 Population的配置参见vxlan中的相关部分。需要在 /etc/neutron/plugins/ml2/ml2_conf.ini 设置 mechanism_drivers = linuxbridge,l2population，l2_population = Ture；

可以通过bridge fdb show dev vxlan-100（vxlan名称）查看节点上的 forwarding database（保存的其他VTEP的地址以及其他VM的MAC）；

2.5.11 Security Group

Neutron 为 instance 提供了两种管理网络安全的方法：安全组（Security Group）和虚拟防火墙。安全组的原理是通过 iptables 对 instance 所在计算节点的网络流量进行过滤。虚拟防火墙则由 Neutron Firewall as a Service（FWaaS）高级服务提供。其底层也是使用 iptables，在 Neutron Router 上对网络包进行过滤。

“default” 安全组有四条规则，其作用是：允许所有外出（Egress）的流量，但禁止所有进入（Ingress）的流量。创建VM时如果没有选择其他安全组，则默认强制使用default安全组。安全组功能可理解就是白名单的服务。具体可以在节点上iptables-save 命令查看相关规则，iptables 的规则是应用在 Neutron port 上的，也就是VM的虚拟网卡TAP设备上。

总结下来，安全组特性如下：

1. 通过宿主机上 iptables 规则控制进出 instance 的流量。
2. 安全组作用在 instance 的 port 上。
3. 安全组的规则都是 allow，不能定义 deny 的规则。
4. instance 可应用多个安全组叠加使用这些安全组中的规则。

2.5.12 Neutron FWaaS

Firewall as a Service（FWaaS）是 Neutron 的一个高级服务。用户可以用它来创建和管理防火墙，在 subnet 边界上对 layer 3 和 layer 4 的流量进行过滤。FWaaS 有三个重要概念：Firewall、Policy 和 Rule。

• Firewall：租户能够创建和管理的逻辑防火墙资源。Firewall 必须关联某个 Policy，因此必须先创建 Policy。
• Firewall Policy：Policy 是 Rule 的集合，Firewall 会按顺序应用 Policy 中的每一条 Rule。
• Firewall Rule：Rule 是访问控制规则，由源与目的子网 IP、源与目的端口、协议、allow 或 deny 动作组成。

防火墙与安全组的区别。可以理解为防火墙的最小作用单元是subnet级别的防护，而安全组则是针对instance的防护。 /etc/neutron/fwaas_driver.ini 文件中设置 FWaaS 使用的 driver：(新版防火墙没有这个driver配置)

还需要在 /etc/neutron/neutron.conf 中启用 FWaaS plugin：

具体可以通过 ip netns <namespace名称> iptables-save查看对应router的防火墙规则状态。最后，FWaaS 用于加强 Neutron 网络的安全性，与安全组可以配合使用，防火墙与安全组的异同点总结如下：

相同点：

• 1. 底层都是通过 iptables 实现

不同点：

• 1. FWaaS 的 iptables 规则应用在 router 上，保护整个租户网络；安全组则应用在虚拟网卡上，保护单个 instance。
• 2. FWaaS 可以定义 allow 或者 deny 规则；安全组只能定义 allow 规则。

2.5.13 Neutorn LBaaS

LBaaS 有三个主要的概念： Pool Member，Pool 和 Virtual IP。

1. Pool Member：Pool Member 是 layer 4 的实体，拥有 IP 地址并通过监听端口对外提供服务。
2. Pool：Pool 由一组 Pool Member 组成。
3. Virtual IP：Virtual IP 也称作 VIP，是定义在 load balancer 上的 IP 地址

OpenStack Neutron 目前默认通过 HAProxy 软件来实现 LBaaS。 HAProxy 是一个流行的开源 load balancer。 Neutron 也支持其他一些第三方 load balancer。实现方式如下图所示：

配置LB：（最新版本的配置可能与下面有差异，按官网最新版本安装步骤来）

/etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini。定义 interface_driver：

interface_driver 的作用是设置 load balancer 的网络接口驱动，可以有两个选项：

Linux Bridge

interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver

Open vSwitch

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

/etc/neutron/neutron.conf 中设置启用 LBaaS plugin：

在 /etc/neutron/neutron_lbaas.conf 中设置 service provider：

除了默认的 HAProxy，Neutron 也支持第三方 provider，比如 radware，VMWareEdge 等等。

LB的几种负载分担算法：

• ROUND_ROUBIN：如果采用 round robin 算法，load balancer 按固定的顺序从 pool 中选择 member 相应 client 的连接请求。这种方法的不足是缺乏机制检查 member 是否负载过重。有可能出现某些 member 由于处理能力弱而不得不继续处理新连接的情况。
• LEAST_CONNECTIONS：如果采用 least connections 算法，load balancer 会挑选当前连接数最少的 pool member。这是一种动态的算法，需要实时监控每个 member 的连接数量和状态。
• SOURCE_IP：如果采用 source IP 算法，具有相同 sourSession Persistencece IP 的连接会被分发到同一个 pool member。source IP 算法对于像购物车这种需要保存状态的应用特别有用；

Session Persistence（会话保持）：

• SOURCE_IP：这种方式与前面 load balance 的 SOURCE_IP 效果一样。初始连接建立后，后续来自相同 source IP 的 client 请求会发送给同一个 member；
• HTTP_COOKIE：当 client 第一次连接到 VIP 时，HAProxy 从 pool 中挑选出一个 member。当此 member 响应请求时，HAProxy 会在应答报文中注入命名为 “SRV” 的 cookie，这个 cookie 包含了该 member 的唯一标识。client 的后续请求都会包含这个 “SRV” cookie。HAProxy 会分析 cookie 的内容，并将请求转发给同一个 member。HTTP_COOKIE 优于 SOURCE_IP，因为它不依赖 client 的 IP。
• APP_COOKIE：app cookie 依赖于服务器端应用定义的 cookie。比如 app 可以通过在 session 中创建 cookie 来区分不同的 client。HAProxy 会查看报文中的 app cookie，确保将包含 app cookie 的请求发送到同一个 member。

Key Pairs

对于一些登陆密码随机的image，可以使用key pairs的功能来进行免密登陆。 通过ssh-keygen -t rsa -f xx.key生成 Key Pair，会生成两个文件一个是xx.key。另一个是xx.key.pub。其中 cloud.key.pub 是公钥，需要添加到 instance 的 ~/.ssh/authorized_keys 文件中。 cloud.key 是私钥，用于访问 instance。将公钥cloud.key.pub的内容复制到openstack导入界面中即可，完成导入。然后就可以通过ssh -i指定私钥进行登陆VM了。

健康检查

需要注意，在LB中配置健康检查的目的是周期性探测WEB Server的活动状态，防止server挂了业务流还持续往故障机器发送；

Neutron中LB的底层实现原理

对于每创建一个pool地址池，Neutron 都会创建新的 namespace qlbaas-xxx，该 namespace 对应我们创建的 pool “web servers”。其命名格式为 qlbaas-< pool ID>。对于每一个 pool，Neutron 都会启动一个 haproxy 进程提供 load balancering 功能。也就是说：一个pool地址池-----namespace-----一个haprocxy进程。haproxy 配置文件保存在 /opt/stack/data/neutron/lbaas/< pool ID>/conf 中。

总结一下：（1）LBaaS 为租户提供了横向扩展应用的能力，租户之间是隔离的。（2）租户可以将外部请求 balancing 到多个 instance 上，并通过 monitor 实现应用的高可用。

至此linux-bridge部分实现neutron网络暂告一段落，后续具体细节部分再针对性的讲解！

2.6 Open vSwitch

2.6.1 Open vSwitch配置

相对linux-bridge，首先需要安装openstack-neutron-openvswitch。然后对应将ML2 的配置文件 /etc/neutron/plugins/ml2/ml2_conf.ini中的mechanism driver设置为openvswitch。组网方式其实与linux-bridge相差无几，可以通过 neutron agent-list 命令查看到 neutron-openvswitch-agent在节点上的运行情况。

2.6.2 OVS中的网络设备类型

Neutron默认在网络节点（此处网络节点与控制节点合一）上创建三个网桥：br-ex，br-int 和 br-tun。计算节点上也有 br-int 和 br-tun（没有br-ex网桥）。

• br-ex：连接外部（external）网络的网桥。
• br-int：集成（integration）网桥，所有 instance 的虚拟网卡和其他虚拟网络设备都将连接到该网桥。
• br-tun：隧道（tunnel）网桥，基于隧道技术的 VxLAN 和 GRE 网络将使用该网桥进行通信。

这些网桥需要用 Open vSwitch 的命令 ovs-vsctl show进行查看，如下所示：

在 Open vSwitch 环境中，一个数据包从 instance 发送到物理网卡大致会经过下面几个类型的设备：

1、tap interface：命名为 tapXXXX；2、linux bridge：命名为qbrXXXX；3、veth pair：命名为 qvbXXXX, qvoXXXX；4、OVS integration bridge：命名为 br-int；5、OVS patch ports：命名为 int-br-ethX 和 phy-br-ethX（X 为 interface 的序号）；6、OVS provider bridge：命名为 br-ethX（X 为 interface 的序号）；7、物理 interface：命名为 ethX（X 为 interface 的序号）；8、OVS tunnel bridge：命名为 br-tun。

其中，OVS provider bridge 会在 flat 和 vlan 网络中使用；OVS tunnel bridge 则会在 vxlan 和 gre 网络中使用；

2.6.3 Local Network

对于一个local类型的网络，其DHCP的TAP设备是直接关联到br-int网桥的，通过veth连接到dhcp的namesapce，在namespace里查看网卡名称也是tapXX的描述。这点在linux-bridge既有相同之处，也有不同之处，两者的实现方式还是不同的。区别在于，对于linux-bridge实现方式，一端连接的tap设备，另一端是连接的对应namespace的ns设备。

值得注意的是，brctl show主要是对于linux-bridge环境下查看网桥的配置信息，对于Open vSwitch则是用ovs-vsctl show 查看 bridge 的配置。当新建一个VM实例时，通过ovs-vsctl show查看网桥下br-int下增加一个qvoxxx类型的设备，而通过brctl show查看会发现新建了一个qbrxx网桥，关联tapxx设备与qvb设备。其中qvb设备与qvo设备之间组成了一对veth pair（可以通过ethtool -S查看设备veth pair的对应索引关系statistics），相当于实例VM首先与新建的qbrxx网桥上的tapxx设备互联，qbrxx再通过veth pair与br-int网桥互联，总体结构如下图。从而，VM实例的tapxx设备（虚拟网卡）则间接连接到了br-int网桥。这点相对之前linux-bridge实现方式----直接通过tap设备与新建的网桥关联，结构上要相对复杂。

增加qbrxx这个网桥的原因主要是： Open vSwitch 目前还不支持将 iptables 规则放在与它直接相连的 tap 设备上。如果做不到这一点，就无法实现 Security Group 功能。对于不同的local network网络，所有的VM实例间接都连接到同一个br-int网桥，Open vSwitch是怎么进行不同local网络的隔离呢？-----答案就是：通过vlan进行隔离。先看下面一张图：

其中qvo设备可以看成不同实例VM连接网桥br-int的接口，tap设备为不同local 网络的dhcp设备，tag其实就是vlan tag（与物理交换机上的vlan无关，虚拟交换机的vlan区分），不同local网络的VM之间的隔离就是靠tag进行区分和隔离。结构如下：

2.6.4 Flat Network

由Open vSwitch实现的Flat网络与linux-bridge的实现方式很类似，都是每个flat网络都会占用一块物理网卡，linux-bridge中直接是通过flat物理标签与宿主机物理网卡一一对应，而Open vSwitch中则是通过网络标签与创建的网桥进行对应，网桥与宿主机的物理网卡进行一一对应。基本配置与linux-bridge类似，如下：

修改租户网络类型：

设置网络标签：

设置ovs mapping中标签与网桥对应关系，注意此处对应的网桥是后续需要创建的

网桥创建命令：ovs-ovctl，ovs-ovctl add-br [网桥名称] 表示创建网桥，ovs-ovctl add-port [网桥名称] [网卡]。当创建多个标签时，之间用逗号隔开，同时在映射关系上也对应多个网桥，每个网桥对应不同网卡。ovs-vsctl show可以看到：

对于 ovs bridge “br-eth1” 和其上桥接的 port “eth1” 我们应该不会感到意外，这是前面配置的结果。然而除此之外，br-int 和 br-eth1 分别多了一个 port “int-br-eth1” 和 “phy-br-eth1”，而且这两个 port 都是 “patch” 类型，同时通过 “peer” 指向对方。这表明：br-int 与 br-eth1 这两个网桥通过 int-br-eth1 和 phy-br-eth1 连接在一起了。其网络结构如下图所示：

这里可以看到网桥br-int 与 br-eth1之间是通过patch port 连接在一起，而不是veth pair。总的看来，patch port 是 ovs bridge 自己特有的 port 类型，只能在 ovs 中使用。如果是连接两个 ovs bridge，优先使用 patch port，因为性能更好。对于ovs网桥之间可以使用patch port，性能更好，除外其他情况一般只能使用veth pair进行网桥连接。

通过对比flat网络类型与local网络类型可以发现，flat网络类型相对而言只是多了一个自己创建的网桥（对应某块物理网卡），DHCP的TAP设备都是挂在br-int这个默认集成网桥上，OVS网桥通过patch port与br-int网桥进行连接，br-int网桥再通过veth pair与关联实例tap设备的qbr网桥连接。从而完成了VM实例间接连接到了br-xxx网桥（创建的对应物理网卡的网桥）。其网络结构图如下所示：

2.6.5 Vlan Network

在 Open vSwitch 实现方式下，不同 vlan instance 的虚拟网卡都接到 br-int （集成网桥）上。这一点与 linux bridge 非常不同，linux bridge 是不同 vlan （类似网卡子接口如eth1.100等）接到不同的网桥上。配置方式上，Open vSwitch方式是对应网桥（如下），而linux-bridge是对应物理网卡，另外OVS还需要通过ovs-ovctl创建网桥，并在网桥关联相应网卡。其他配置基本都一样，就不再展开说了。

通过创建网络、实例VM，通过ovs-ovctl查看可以发现这种网络其实和local网络也比较类似，创建的DHCP的TAP设备与VM的port都带有tag，每创建一个VM都会对应创建一个linux-bridge网桥，VM通过网桥间的veth-pair间接连接到br-int。这点很相似。

网络结构如下：

针对不同的vlan网络，vlan网络之间是怎么进行隔离的呢？其实实现原理主要是通过Open vSwitch的flow rule（流规则）进行控制。不同vlan网络的网络架构如下图所示：

相对于Linux Bridge driver用eth1.xx的vlan接口实现vlan网络隔离。open vswitch则是用flow rule来对进出br-int的集成网桥、br-ethxx网桥等进行流量控制，可以对相应进出端口的流量进行加vlan标签、修改vlan标签、剥vlan标签，从而完成vlan网络的隔离。查看 flow rule 的命令是 ovs-ofctl dump-flow ，首先查看计算节点 br-eth1 的 flow rule:

可以看到，每条 rule 有不少属性，其中比较重要的属性有：

• priority：rule 的优先级，值越大优先级越高。Open vSwitch 会按照优先级从高到低应用规则；
• in_port：inbound 端口编号，每个 port 在 Open vSwitch 中会有一个内部的编号。可以通过命令 ovs-ofctl show 查看 port 编号。比如 br-eth1：

• dl_vlan：数据包原始的 VLAN ID；
• actions：对数据包进行的操作；

首先分析一下br-eth1的flow rule的关键信息，ovs-ofctl show br-eth1查看：

priority=4,in_port=2,dl_vlan=1 actions=mod_vlan_vid:100,NORMAL
priority=4,in_port=2,dl_vlan=5 actions=mod_vlan_vid:101,NORMAL

第一条的含义是：从 br-eth1 的端口 phy-br-eth1（in_port=2）接收进来的包（其实就是VM的数量包由br-int的int-br-eth1端口发送给的phy-br-eth1端口的包），如果 VLAN ID 是 1（dl_vlan=1），那么需要将 VLAN ID 改为 100（actions=mod_vlan_vid:100）

怎么理解将 VLAN ID 1 改为 VLAN ID 100 呢？

通过ovs-vsctl show命令查看节点的open vswitch网桥配置：

可以看到，br-int网桥下不同的port的带有不同的tag标签，这个tag可以看作是节点内部的vlan标签，通过这种内部的vlan标签来隔离port，内部的vlan tag对应不同的vlan网络，该对应关系由neutron进行维护，并将转换规则配置在 flow rule 中。该内部vlan tag只在br-int有效，与外部网络的vlan无关，不同于物理网络的vlan。总的来看，进入br-ethxx网桥phy-br-ethxx端口的报文，flow rule是将原来的内部vlan转换成对应配置的vlan tag；而进入br-int网桥的int-br-ethxx则是将物理vlan替换回int-br的内部vlan。从而完成了vlan网络的隔离。

2.6.6 Routing

Routing主要是由L3 agent提供服务，L3 agent需要正确配置才能工作，配置文件为 /etc/neutron/l3_agent.ini。大部分情况下默认配置已经帮我们配置好了，不需要再单独配置。需要注意：

如果 mechanism driver 是 open vswitch，则：

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

如果选用 linux bridge，则：

interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver

L3 agent运行在网络节点或者控制节点（如果网络节点与控制节点合一，如果是分布式则运行在计算节点）

对于routing的底层实现，可以进一步分析来看。创建两个vlan网络vlan 100、vlan 101。底层上在br-int对应增加了两个port（分别对应两个vlan）。与 linux bridge 实现方式一样， router_100_101 运行在自己的 namespace 中。与linux-bridge不同的地方在于，router的qrxx端口在ovs中是直接作为br-int网桥上的Port存在的，没有linux-bridge的veth pair线路将qrxxx设备与网桥上的tap设备互联。此外，可以看到br-int网桥上的router的port也是带tag的，对应vlan在br-int网桥上的内部vlan。

整体的网络结构参加下图：

以上讲解了neutron网络内跨vlan网络的互访情况，那么对于外部外部网络的访问，是如何实现呢？首先 需要设置外部网络的标签，例如标签label命名为 “external”，网桥为 br-ex。

如果类型为 flat，控制节点 /etc/neutron/plugins/ml2/ml2_conf.ini 配置如下：

如果类型为 vlan，配置如下：

此外，我们还需要在节点上通过ovs-vsctl add-br br-ex命令创建网桥，然后由ovs-vsctl add-port br-ex xxx命令将xxx网卡关联到br-ex网桥。总的来说，当外部网络为flat网络时，每个flat网络对应一块物理网卡，如果有多个外部网络则需要多块物理网卡与之对应；当外部网络为vlan网络时，多个不同vlan的flat网络可以对应一块网卡。创建完成外部网络，可以查看到底层网桥上br-int与br-ex之间通过int-br-ex与phy-br-ex的patch port连接起来。

创建完成外部网络的子网后，neutron会自动在br-ex网桥上分配一个port（qgxxx）。router interface 的命名规则如下： 1. 如果 interface 用于连接租户网络，命名格式为 qr-xxx（关联br-int网桥）；2. 如果 interface 用于连接外部网络，命名格式为 qg-xxx（关联br-ex网桥）。br-int与br-ex之间也是由一对patch port连接起来，主要用来承载VM进出外部网络的流量。网络架构整体描述如下：

通过图上可以看出，一台VM想要访问外部网络，经过的路径为：qvbxxx（接口，存在vm自身tap设备关联的网桥上qbrxxx）→qvoxxx（接口，br-int网桥上）→qrxx接口（router接口）→int-br-ex（br-int网桥上）→phy-br-ex（br-ex网桥上）→qgxxx（br-ex网桥）→外部网络。qrxx与qgxx接口之间并不是直接通过router过来的，而是需要通过int-br-ex与phy-br-ex这对patch port间通过。其出网过程中，与linux-bridge实现方式一样，会进行SNAT转换，入网则用float ip模式进行DNAT转换。

2.6.7 Vxlan Network

配置准备：在/etc/neutron/plugins/ml2/ml2_conf.ini配置文件中使能vxlan、l2population，指定租户vxlan网络的配置范围。

设置租户创建网络类型为vxlan：

设置vxlan的范围：

设置agent的类型为vxlan。使能l2_population（目的是减少vxlan内隧道里的arp泛洪报文）

ovs中配置local_ip地址和对应网桥，没有指定网卡对应关系，通过对应的ip查找路由选择对应从哪块网卡出去（这点与linux-bridge的方法比较类似）：

其网络架构的网桥桥接模式与vlan网络比较类似，br-int网桥与br-tun网桥之间通过patch port互联（patch-tun~patch int）（如下）：

通过比较其底层的网络结构，与vlan网络大部分都比较类似，相对而言vxlan网络在br-tun网桥下会多创建一个port vxlanxxx（上面记录了本端与对端的VTEP IP），用来在控制节点与计算节点之间建立vxlan隧道。控制节点上：

计算节点上：

其网络结构如下所示：

隧道建立起来了，VM之间的数据流量在整个过程是怎么转发呢？------这主要是依靠flow rule来指导进行转发，该部分也是很复杂的一部分内容，按照之前的例子分别查看br-int、br-tun的流表。

br-int的flow rule：

br-int 的 rule 看上去虽然多，其实逻辑很简单，br-int 被当作一个二层交换机，其重要的 rule 是下面这条：

cookie=0xaaa0e760a7848ec3, duration=52798.625s, table=0, n_packets=143, n_bytes=14594, idle_age=9415, priority=0 actions=NORMAL

此规则的含义是：根据 vlan 和 mac 进行转发。

br-tun 的 flow rule：（主要）

这些才是真正处理 VXLAN 数据包的 rule，其流程如下：

上图各方块中的数字对应 rule 中 table 的序号，下面分析各个table的功能与作用。

table 0：

cookie=0xaaa0e760a7848ec3, duration=76707.867s, table=0, n_packets=70, n_bytes=6600, idle_age=33324, hard_age=65534, priority=1,in_port=1 actions=resubmit(,2)

cookie=0xaaa0e760a7848ec3, duration=76543.287s, table=0, n_packets=56, n_bytes=4948, idle_age=33324, hard_age=65534, priority=1,in_port=2 actions=resubmit(,4)

cookie=0xaaa0e760a7848ec3, duration=76707.867s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

结合如下port编号：

table 0 flow rule 的含义为：（即第一条 rule 处理来自内部 br-int（这上面挂载着所有的网络服务，包括路由、DHCP 等）的数据；第二条 rule 处理来自外部 VXLAN 隧道的数据。）

1. 从 port 1（patch-int）进来的包，扔给 table 2 处理：actions=resubmit(,2)
2. 从 port 2（vxlan-a642100b）进来的包，扔给 table 4 处理：actions=resubmit(,4)

table 4：

cookie=0xaaa0e760a7848ec3, duration=76647.039s, table=4, n_packets=56, n_bytes=4948, idle_age=33324, hard_age=65534, priority=1,tun_id=0x64 actions=mod_vlan_vid:1,resubmit(,10)

table 4 flow rule 的含义为： 如果数据包的 VXLAN tunnel ID 为 100（tun_id=0x64），action 是添加内部 VLAN ID 1（tag=1），然后扔给 table 10 去学习。

table 10：

cookie=0xaaa0e760a7848ec3, duration=76707.865s, table=10, n_packets=56, n_bytes=4948, idle_age=33324, hard_age=65534, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xaaa0e760a7848ec3,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1

table 10 flow rule 的含义为： 学习外部（从 tunnel）进来的包，往 table 20 中添加对返程包的正常转发规则，然后从 port 1（patch-int）扔给 br-int。

rule 中下面的内容为学习规则，这里就不详细讨论了。

NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]

table 2：

cookie=0xaaa0e760a7848ec3, duration=76707.866s, table=2, n_packets=28, n_bytes=3180, idle_age=33324, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
cookie=0xaaa0e760a7848ec3, duration=76707.866s, table=2, n_packets=42, n_bytes=3420, idle_age=33379, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)

table 2 flow rule 的含义为：

1. br-int 发过来数据如果是单播包，扔给 table 20 处理：resubmit(,20)
2. br-int 发过来数据如果是多播或广播包，扔 table 22 处理：resubmit(,22)

table 20：

cookie=0xaaa0e760a7848ec3, duration=76543.287s, table=20, n_packets=28, n_bytes=3180, idle_age=33324, hard_age=65534, priority=2,dl_vlan=1,dl_dst=fa:16:3e:fd:8a:ed actions=strip_vlan,set_tunnel:0x64,output:2

cookie=0xaaa0e760a7848ec3, duration=76707.865s, table=20, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=resubmit(,22)

table 20 flow rule 的含义为：

1. 第一条规则就是 table 10 学习来的结果。内部 VLAN 号为 1（tag=1），目标 MAC 是 fa:16:3e:fd:8a:ed（virros-vm2）的数据包，即发送给 virros-vm2 的包，action 是去掉 VLAN 号，添加 VXLAN tunnel ID 100(十六进制 0x64)，并从 port 2 (tunnel 端口 vxlan-a642100b) 发出。
2. 对于没学习到规则的数据包，则扔给 table 22 处理。

table 22：

cookie=0xaaa0e760a7848ec3, duration=76543.282s, table=22, n_packets=2, n_bytes=84, idle_age=33379, hard_age=65534, dl_vlan=1 actions=strip_vlan,set_tunnel:0x64,output:2

cookie=0xaaa0e760a7848ec3, duration=76707.82s, table=22, n_packets=40, n_bytes=3336, idle_age=65534, hard_age=65534, priority=0 actions=drop

table 22 flow rule 的含义为： 如果数据包的内部 VLAN 号为 1（tag=1），action 是去掉 VLAN 号，添加 VXLAN tunnel ID 100(十六进制 0x64)，并从 port 2 (tunnel 端口 vxlan-a642100b) 发出。匹配不上就丢弃。

以上简单对流表进行了分析，可以看出是很复杂的，也是neutron学习过程中很烧脑的部分。此外，vxlan的float ip和routing和vlan网络类似，不再讲解。