Neutron（二）上层资源模型篇

阳光穿透心脏的1/2处 2022-09-05 05:16 287阅读 0赞

# 目录 #

### 文章目录 ###

*  [目录][Link 1]
 *  [Neutron 的资源模型][Neutron]
 *   *  [Network][]
     *   *  [运营商网络和租户网络][Link 2]
         *  [创建运营商网络][Link 3]
         *  [创建租户网络][Link 4]
         *  [创建外部网络][Link 5]
         *  [Network 小结][Network 1]
     *  [Subnet][]
     *   *  [IP 核心网络服务][IP]
         *  [SubnetPools 资源模型][SubnetPools]
         *  [Multi-Segments][]
         *  [创建 Subnet][Subnet 1]
         *  [Network 与 Subnet 的一对多关系][Network _ Subnet]
     *  [Port][]
     *   *  [Neutron 安全组（Security Group）][Neutron _Security Group]
         *  [可用地址对（Allowed address pairs）][Allowed address pairs]
         *  [创建一个 Port][Port 1]
         *  [挂载一个 Port][Port 2]
     *  [Router][]
     *   *  [外部网关][Link 6]
         *  [新建 Router 和外部网关端口][Router 1]
         *  [Router 的路由表][Router 2]
         *  [Floating IP][]

# Neutron 的资源模型 #

Neutron 资源模型官方文档：[https://developer.openstack.org/api-ref/network/v2/index.html][https_developer.openstack.org_api-ref_network_v2_index.html]

## Network ##

**Network** 是 Network Connectivity as s Service 的 “根” 操作对象，是 Neutron 对二层网络的抽象，包含了用户对「大二层」网络的一切想象，支持 Local、 Flat、 VLAN、 VXLAN、 GRE、 Geneve 等多种网络类型并不断扩充。如果将 Network 映射到现实世界的话，它就相当于一个巨大的交换机：从介质的角度，它拥有许多端口；从网络的角度，它划分广播域；从功能的角度，它提供了 “隔离” 和 “转发”。

在《[Networking 基本术语/概念][Networking]》一文中，我们已经记录了关于大二层网络的介绍，这里不再赘述。  
![在这里插入图片描述][24dd40043837fbd37c1a9004c7d44e34.png]  
![在这里插入图片描述][ced035e2cf5b97d43e78caa7016ea08e.png]  
Neutron 网络概念的定义和类型花样之多，令人眼花缭乱。我们姑且从几个不同的方面对 “网络” 做一个分类归纳，区分理解。

**从网络实现模型分层的角度看**：

*  本地网络（br-int）
 *  租户网络（br-ethX/br-tun）
 *  外部网络（br-ex）

**从网络实现技术的角度看**：

*  非隧道网络（Local、Flat、VLAN）
 *  隧道网络（VxLAN、GRE、Geneve）

**从网络从属关系的角度看**：

*  运营商（物理）网络
 *  租户网络

从 Neutron 所追求的「多租户隔离多平面网络」实现来看，我们可以感受到每一个 Network 都应该具有以下 3 个核心要素，我将其称之为 “核心三要素”：

*  Network Type
 *  VID Range
 *  Physical Network Mapping

接下来的内容，主要就是围绕这核心三要素展开的。

### 运营商网络和租户网络 ###

本章节我们要使用的就是第三种视角。所谓 “从属” 即是 “属于谁”：由 Neutron 创建的，属于 Neutron 管理范畴的网络，我们称之为租户网络（Tenant Network）；属于运营商（e.g. OpenStack 平台的运营者）原有的，Neutron 无法管理、只能映射（记录）的网络，称之为运营商网络（ Provider Network）。两种网络都采用了 Network 资源模型，从模型的角度来看，两者的区别在于是否会持久化下列三个字段属性值（运营商网络具有，租户网络反之）：

*  provider:network\_ type (string) — The type of physical network that this network is mapped to.
 *  provider:physical\_network (string) — The physical network where this network is implemented.
 *  provider:segmentation\_id (int) — The ID of the isolated segment on the physical network.

首先需要提出的问题是：**为什么要区分租户网络和运营商网络**？这是因为单存的 Neutron（虚拟网络）本身只是一座孤岛，如果希望与外界取得联系，就需要依赖于公共设施（e.g. 移动通信网络、桥梁）的支持。虽然 Neutron 对这些公共设施没有控制权，但却可以使用（e.g. 购买手机号码）它们，所以 Neutron 要创建一个 Network 资源对象来存储这些（运营商网络）信息。而存储的地方就是上述的 3 个字段了。

举例说明运营商网络的应用场景：用户希望 OpenStack 中的 VMs 与产品部（VLAN 10=100）的若干台个人电脑处于同一个二层网络，那么用户可以为这些 VMs 创建一个 VLAN ID=100 的运营商网络 p-network1，并且填入下列字段的值。

*  provider:network\_ type ==> VLAN
 *  provider:physical\_network ==> “产品部网络”
 *  provider:segmentation\_id ==> 100

**NOTE**：以上只是举例，实际这三个字段的值并非如此。  
![在这里插入图片描述][9f554cba50e246484a159975a36aad77.png]  
**需要注意的是，上述例子中无论是 VLAN 类型的网络，还是 VLAN ID=100 都并非是 Neutron 创建的，而是运营商本来就已经存在的网络，Neutron 只是创建了一个 Network 资源类型并记录下这些运营商网络的信息，继而进一步使用这个运营商网络的特性而已**。  
![在这里插入图片描述][9e2dbcdd79e5308d4df42972ce2c3290.png]  
**简而言之，运营商网络的作用就是为了让 Neutron 内部的虚拟网络可以与物理网络连接起来。运营商网络是运营商的某个物理网络在 Neutron 上的延伸，Neutron 租户无法管理这个物理网络的生命周期**。

### 创建运营商网络 ###

创建运营商网络有两个要点：一是只能有管理员创建，二是需要手动填写 “核心三要素”。  
![在这里插入图片描述][90ab517dee7e1b3cc34583710485b8c9.png]  
上图为通过 admin 创建一个 VLAN 类型的运营商网络，填写的三个表单就对应了 “核心三要素” 并存储到数据库中 networks 表的 provider:network\_ type、provider:physical\_network、provider:segmentation\_id 字段中。“核心三要素” 中的 Network Type 和 VID Range 很好理解，两者描述了运营商网络的特征。但 Physical Network Mapping 的意义你或许会感到迷惑，其实它描述的是 Neutron Network 应该如何接入运营商实际的物理网络。直白的说，就是 Neutron Network 要通过哪一张 “网卡” 来接入到实际的运营商网络中。

但为什么上图 “物理网络” 表单项填写的 “网卡” 名称是 “public” 呢？其实 “public” 是 Neutron 实现的一种 Label 机制，本质是一个 Key-Value Mapping，将便于人类理解的 Label Name 与实际的 Physical Network 隐射起来，这就是所谓的 Physical Network Mapping。几乎所有的物理网络是使用 Label 的方式来标的。而这个 Physical Network Mapping 就定义在 Neutron OvS（本文以 OvS 为例）的配置文件中。e.g.

# /etc/neutron/plugins/ml2/openvswitch_agent.ini
    
    bridge_mappings = physnet1:br-ethx1, physnet2:br-ethx2

那为什么 Lable “public” 对应的 Physical Network 是 “br-ethx1” 而不是一张具体的物理网卡名称（e.g. eth0）呢？这个问题其实我们在 Neutron 的网络实现模型已经提到过，因为 OvS Bridge 会将物理服务器上的物理网卡挂载到 OvS br-ethX（IP 地址也在此），所以 Physical Network 填入的是 br-ethX 而不是 eth0。

![在这里插入图片描述][44ad2a7e51ac9501a5764926a0eccbf3.png]  
上图为创建一个 VxLAN 类型的运营商网络。奇怪的是为什么没有了 “物理网络” 这个表单项呢？这还是要说到 Physical Network Mapping（provider:physical\_network）描述的是 Neutron Network 应该如何接入到实际的运营商网络，由于 Flat、VLAN 等非隧道网络类型本质是一个二层网络，所以需要指定 “网卡” 才能让二层的数据帧流入运营商网络。但像 VxLAN、GRE 之类的隧道网络类型的实现原理是基于三层 IP 协议的，所以隧道网络能否与运营商网络互通的关键是隧道外层封装 IP 地址是否填写正确，而非一张 “网卡”。

再次强调一下创建运营商网络的要点：

*  **只能由管理员创建**
 *  **需要手动填写 “核心三要素”，并持久化到数据库中**
    
     *  **非隧道网络类型**：需要传入 Physical Network Mapping（provider:physical\_network）字段值，描述 Neutron Network 接入运营商网络的 “网卡（br-ethX）”。
     *  **隧道网络类型**：只需要保证节点上已经定义好了与运营商网络对应的 Tunnel 端口 IP 地址并且三层网络通信无障碍即可。

![在这里插入图片描述][7d82ce6b58479174e74a5e1d1a849750.png]  
上图为创建一个 Flat 类型的运营商网络。Flat（扁平）类型网络是没有 VID 的，不想 VLAN 类型在网络包从 Bridge 发出前还是打 VLAN tag 并进行内外 VID 转换。Flat 的网络包就是一个 Untag 网络包，直接接入物理网络，只需要告诉它用哪一张 “网卡（物理网络）” 即可。

### 创建租户网络 ###

![在这里插入图片描述][a456d95e4ab9512306840a53c214731c.png]  
上图为创建一个租户网络，可见并没有填入 “核心三要素” 的表单项。这是因为 Neutron 认为：对于租户创建自己的网络而言，租户希望得到的只是一个二层网络，至于这个二层网络是由 VLAN 提供的或由 VxLAN 提供的并无所谓，VID 是多少也并无所谓，Physical Network 是怎么 Mapping 的就更无所谓了。

一言以蔽之，**租户无需关心这个 Network（二层网络）的底层实现细节**。Neutron 只有做到了这一点，才能称之为 “服务”！这不禁让我想起柯达公司的一句经典广告语 —— 你只管快门，其余我来！

但话又说回来，租户自然是不必操心这些细节，但云平台管理员可不行。云平台管理员是可以通过 Neutron 的配置文件来声明定义 “核心三要素” 的。e.g.

[ml2]
    ...
    tenant_network_types = vlan,vxlan
    mechanism_drivers = openvswitch,linuxbridge
    
    [securitygroup]
    firewall_driver = openvswitch
    
    [ovs]
    datapath_type = system
    bridge_mappings = public:br-ex,
    tunnel_bridge = br-tun
    local_ip = 172.18.22.200
    
    [ml2_type_flat]
    flat_networks = public,
    
    [ml2_type_vlan]
    network_vlan_ranges = public:3001:4000,
    
    [ml2_type_geneve]
    vni_ranges = 1:1000
    
    [ml2_type_gre]
    tunnel_id_ranges = 1:1000
    
    [ml2_type_vxlan]
    vni_ranges = 1:1000

所以，就租户网络而言，其 “核心三要素” 是不需要持久化到数据库中的，也就不具有 provider:network\_ type、provider:physical\_network、provider:segmentation\_id 这三个字段值了。再一个就是从配置中可以看出，只有非隧道类型是需要填写 “物理网络” Lable 的。

### 创建外部网络 ###

创建外部网络（能够访问公网的网络）属于运营商网络的另一种应用场景。

![在这里插入图片描述][3ee96372b4134a20b41f6783c6929cec.png]

实际上所谓的外部网络和运营商网络的底层实现并无区别，不同之处在于外部网络具有分配 Floating IP 的功能，即外部网络在网络节点的 qrouter-XXX namespace 中配置的 iptables 的 NAT（SNAT/DNAT）功能，使得内部虚拟机得以访问到外部公网。

### Network 小结 ###

Network 是 Neutron 的二层网络资源模型，对外提供二层网络的服务接口（创建、删除二层网络）。租户可以通过这个接口来创建专属于自己的租户网络，管理员可以通过这个接口来创建（对接）Neutron 所无法管理的运营商的物理网络与外部网络。

从资源的角度来看，租户网络和运营商网络的主要区别在于「可控性」：租户网络是 Neutron 完全可控的，基于 Neutron 网络实现模型支撑的多租户隔离多平面网络需求，租户网络的 “核心三要素” 由云管人员通过 Neutron 的 ML2 配置文件定义；而运营商网络却是 Neutron 所无法管理的运营商的物理网络在 Neutron 上的一种延伸，其 “核心三要素” 只是对运营商物理网络信息的一个记录，并无管理性质。

运营商网络的两种典型应用场景：一是打通 Neutron Network 与运营商内部的物理网络，使得两者之间的虚拟机可以互相通信；再一个是打通 Neutron Network 与 Internet，使得 Neutron Network 中的虚拟机可以访问公网。第二种应用场景也就是 Neutron 的 Floating IP 功能，是通过网络节点上 qrouter-XXX 中的 iptables NAT 实现的。

## Subnet ##

**Subnet** 下属于 Network，是 Neutron 对三层子网的抽象，它作为一个具体网段（CIDR）的 IP 地址池，同时为使用接入到该子网的 VMs 提供 IP 核心网络服务，还负责保证三层网络之间的路由互通。在通常情况下，Subnet 符合人们对 “子网” 的常规理解。

*  IP VERSION
 *  IPADDR
 *  NETMASK
 *  GATEWAY
 *  ROUTE
 *  DNS
 *  DHCP
 *  IPAM

**NOTE**：在某些特定的应用场景中（e.g. Multi-Segments），Subnet 被赋予了更加深厚的含义，这里我们暂且不谈。  
![在这里插入图片描述][204507946e808841080befdd4e2327a4.png]  
![在这里插入图片描述][3131df388179eea0fc34e1b3ea4606e1.png]

### IP 核心网络服务 ###

IP 核心网络服务（IP CoreNetwork Services），又称 DDI（DNS、DHCP、IPAM）服务。

*  DNS — Domain Name System，域名系统
 *  DHCP — Dynamic Host Configuration Protocol，动态主机设置协议
 *  IPAM — IP Address Manager，IP 地址管理

DNS 和 DHCP 相信大家不会陌生，这里介绍一下 IPAM 服务。IPAM 用于发现、监视、审核和管理企业网络上使用的 IP 地址空间，IPAM 还可以对运行的 DHCP 和 DNS 服务器进行管理和监视。**简而言之，IPAM 就是一种 IP 地址的管理手段，目的是让 IP 地址的分配、使用更加便利**。

**Subnet 资源模型中与 DDI 服务相关的字段**：  
![在这里插入图片描述][e16f7226b427d1ef28945c2ab333656b.png]  
**enable\_dhcp**：布尔类型，表示是否为 Subnet 启用 DHCP 服务，若启用，再会在 qdhcp-XXX namesapce 中启动 dnsmasq 服务进程。

**allocation\_pools**：是一个数组，表示 DHCP 服务可分配的 IP 地址池列表，每个地址池的格式为 `[start IP, end IP]`。若没有配置则以 Subnet 的 cidr 作为地址池。

**dns\_nameservers**：是一个数组，用于指定一批 DNS Server 的地址。这里仅记录地址，实际的 DNS 服务并不由 Neutron 提供。

**subnetpool\_id**：是 tables subnetpools 的外键，指向 SubnetPools 资源模型。

**NOTE**：SubnetPools 与 allocation\_pools 是两个 “同类不同源” 的功能。两者均为 IP 地址的资源池，而前者是对后者的一种优化，在 Kilo 版本引入，为了更好的管理子网网络资源池（e.g. 提供访问接口）。

小结一下，IP 核心网络服务（DNS、DHCP、IPAM）是 Subnet 资源模型提供的服务，而服务的对象是使用该 Subnet 的 VMs。可见，Subnet 不仅仅是一个抽象资源接口，其具有一定的管理功能。这一点非常重要，因为我们在启动虚拟机时，时常选择的是一个 Network 而非 Subnet。e.g.

$ openstack server create -h
    ...
    [--nic <net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid,auto,none>]

这会让我们产生一种错觉，虚拟机网络来自于 Network，从表面看并没有问题，也是 Neutron 有意为之（对用户隐藏复杂细节的表现）。但对于开发者而言，如果带着这种认知去阅读源码就难免会产生疑惑，IP 核心网络服务的代码逻辑处理对象实际是 Subnet 而非 Network，这一点完全契合 Subnet 的资源模型设计。**所以再次强调，Network 是 NaaS 的根操作对象，表示一个二层网络；而 Subnet 下属于 Network，为 Network 中的 VMs 提供 IP 核心服务**。

### SubnetPools 资源模型 ###

你是否考虑过，用户真的需要关心一个 Subnet 的网段是 192.X、还是 172.X、还是 10.X 吗？用户要关心的仅仅是这个 Subnet 可以提供多少个 IP 地址而已！出于这样的需求，Network 引入了 SubnetPools 资源模型，通过 subnetpool\_id 字段与 Subnet 关联。SubnetPools 和 Sunbet 的关系就相当于：前者定义了一个大的（不重复的）网段，后者从中分配了一个小的网段。e.g.

$ openstack subnet create -h
    ...
    [--subnet-pool <subnet-pool> | --use-prefix-delegation USE_PREFIX_DELEGATION | --use-default-subnet-pool]

**NOTE**：在较新的版本（Rocky）中，配合 OpenStack Placement Project，SubnetPools 还可以被一个第三方的网络软件提供的外部 IP 资源池代替。

![在这里插入图片描述][b3f0ab1ba2e37e117ad892faa614e056.png]

# 记录了一个 SubnetPool 的子网网段划分规则
    MariaDB [neutron]>  select * from subnetpools\G;
    *************************** 1. row ***************************
           project_id: 031cec3e2df143259d302aa1993fd410
                   id: 5bbd5cab-c6a0-4851-b2d7-1137742e6adf
                 name: shared-default-subnetpool-v4
           ip_version: 4
    default_prefixlen: 26
        min_prefixlen: 8
        max_prefixlen: 32
               shared: 1
        default_quota: NULL
                 hash: 27e49575-31f7-4012-b57b-55c990cb6d82
     address_scope_id: NULL
           is_default: 1
     standard_attr_id: 1
     
    # 记录了一个 SubnetPool 的子网网段信息
    MariaDB [neutron]> select * from  subnetpoolprefixes;
    +----------------+--------------------------------------+
    | cidr           | subnetpool_id                        |
    +----------------+--------------------------------------+
    | 192.168.1.0/24 | 5bbd5cab-c6a0-4851-b2d7-1137742e6adf |
    +----------------+--------------------------------------+

### Multi-Segments ###

在上文中我们反复提到，Network 是一个二层网络的抽象，Subnet 是一个三层子网的抽象。这是大多数 SDN 软件设计的常规定义，创建一个 Network 就相当于获得了一个广播域，创建一个 Subnet 就相当于获得了一个三层 IP 地址池。对用户的理解非常友好。

不过在实际的生产需求中 Neutron 面临一个问题：如果一个 Network 内的 VMs/Hosts 数量太多，就会出现诸如二层广播风暴、网络内交换机 ARP 表项容量不足等情况。**简单来说，这就是 Network 作为云计算平台中的大二层网络却无法支撑起 “无限” 多个 VMs 的问题**。为了满足这一需求 Neutron 引入了 Multi-Segments 设计。

Multi-Segments 解决这一问题的办法就是将 Network 的定义进一步升级为 “多个二层网络的容器”，同时也将 Subnet 的定义进一步升级为 “一个二层网络以及基于此的三层子网”，Subnet 之间通过三层路由互通。

![在这里插入图片描述][4e7b851230cc13d3cb7531c1388d1ba1.png]  
![在这里插入图片描述][d1109125df5a5991efbf3e7a25ceb71d.png]  
Multi-Segments 顾名思义是一个 Network 具有多个 Segments，而一个 Segment 其实是一个运营商网络，这一点可以从 Segment 资源模型看出（每条 Segment 记录都包含一个运营商网络的 “核心三要素”）。  
![在这里插入图片描述][bf7a461c481434efe392854f1122aacf.png]  
显然，天下没有免费的午餐，Multi-Segments 的设计实际上具有非常大的局限性 —— 需要规划整个物理、虚拟网络拓扑。它是一种通过 “物理手段” 来完成的 “Network 升级”。比如：Routed Network 应用场景。  
![在这里插入图片描述][31bf745481fe026fde6d654a1ab0d553.png]  
所谓 Routed Network，就是一个 Network 内的 Subnet（对应运营商的物理网络）之间使用物理路由器连通，Subnet 的 gateway\_ip 指向物理路由器直连网口的 IP 地址。在现实机房中，一个机柜接入物理路由器的网口基本固定，网口的 IP 地址也不会轻易改动，这意味着 Subnet 的三层子网需要与该物理路由器网口的 IP 处于同一个网段，否则无法通信。也就是说，使用 Routed Network 要求管理员提前做好物理、虚拟网络、每个机柜的网关 IP、DHCP Server 的全盘规划。

Multi-Segments 的应用场景除了 Routed Network 还有「VTEP 位于 TOR 交换机上」这一场景，暂不作介绍。可以感受到 Multi-Segments 的应用大多需要结合实际的物理网络拓扑对机房网络进行全盘规划，虽然都并非是一种通用的方案，但 Multi-Segments 的存在也的确让 Neutron 落地物理机房多了一些更加灵活的配置选项。不过，很可惜的是，至今为止笔者依然没有碰见过在生产环境中落地的案例，有时候难免让人怀疑 Multi-Segments 存在的必要性，这是一个大家都对其 “讳莫如深” 的话题。在本章节中提出也只是为了作一个了解而已。

Routed provider networks 官方示例文档：[https://docs.openstack.org/newton/networking-guide/config-routed-networks.html][https_docs.openstack.org_newton_networking-guide_config-routed-networks.html]

**NOTE**：有趣的是，经过上述文档的实验发现 Multi-Segments 无法实现预期的 Segments（Subnets）之间的二层隔离，这是因为 VMs 虽然在不同 Segments（Subnets）上，但 VMs 连接到同一个（计算节点的）OvS br-int 上的 qvo-XXX 却具有相同的 Tag ID，自然就无法进行隔离了。由于 Multi-Segments 的场景实在少见，笔者也就不再深究了，只是做出提醒，了解就好。

### 创建 Subnet ###

![在这里插入图片描述][a937767662bc39ac2645a190d5427929.png]  
创建 Subnet 可以手动输入你预期的网段，也可以应用 SubnetPools 资源模型，直接选择一个 IP 地址资源池。显然后者要来的更加简便一些，只需要通过 “网络掩码” 表单来描述你想要的 IP 地址数量即可（e.g. NETMASK=24 即 2\*\*8 == 256 个 IP 地址）。  
![在这里插入图片描述][ac71634eec0bd470ecb36045ca04d4ad.png]  
创建 Subnet 时你还可以 “手动输入网络地址”，该表单对应 Subnet 资源模型的 allocation\_pools 属性，所以 “手动输入网络地址” 是无法和 SubnetPools 共存的，只有通过手动指定网段的方式才可以使用。“主机路由” 对应 host\_routes 属性，格式正如上文所说：`[目标网络, 下一跳 IP 地址]`。“DNS 服务器” 对应 dns\_nameservers 属性，是一个数值类型，填入 DNS Server 的 IP 地址。

**NOTE**：同一个 Network 不可以同时具有从资源池中分配（SubnetPools）和手动输入网络地址（allocation\_pools）两种类型的 Subnet — *Subnets hosted on the same network must be allocated from the same subnet pool.*

### Network 与 Subnet 的一对多关系 ###

Network 和 Subnet 是一对多的关系，这跟应用了 Multi-Segments 与否无关。Network 下属的 Subnets 可以有不同的 IP 网段（CIDR）且不能重叠，但不同 Networks 的 Subnets 之间可以具有相同的 CIDR。这得益于 Neutron L3 Router 应用了 qrouter-XXX network namespace，解决了 Networks 之间 CIDR 冲突的问题。对于不同 Networks 的 Subnets 之间具有相同 CIDR 时，会有以下两种情况：

1.  若两个 Subnets 通过同一个 Router 路由，根据 Router 的配置，只有指定的一个 Subnet 可被路由。
2.  若两个 Subnets 通过不同的 Router 路由，因为 Router 的路由表隔离，所以两个 Subnets 都可以被路由。

我们知道常规的 Network 就是二层广播域，那么你是否想过，为什么 Network 与 Subnet 的聚合关系被设计成一对多？为什么 Neutron 允许在同一个二层广播域之上可以配置多个不同的子网？其实这并非出于什么特殊的意图，只是一对多的关系使得 Neutron 的网络应用更加灵活。通常情况下，用户大概率只会在一个 Network 下创建一个 Subnet，让它们尽可能维护一个 “表面上” 的一比一关系。但总有特殊的情况，例如：一个 Subnet 的 IP 地址用完了；例如：我要启用 Multi-Segments。无论从操作层面还是从架构设计层面上看，Network 与 Subnet 的一对多关系都让 Neutron 变得更加灵活。

那么选定一个具有多个 Subnets 的 Network 来启动一个虚拟机时 Neutron 会怎么处理呢（Nova 不支持选定 Subnet 来启动虚拟机）？Neutron 会按照 Subnets 的顺序选定第一个可用的 Subnet 来给虚拟机使用，知道该 Subnet 的 IP 被分配完毕为止。由此可以感受到，如果不是有特殊需求，还是尽量让 Network 与 Subnet 维持 “表面上” 的一比一关系吧。  
![在这里插入图片描述][18b1f0ac66dd2ce31c6dabdd40f7c7e1.png]

**NOTE**：虽然 Network 下属有多个 Subnet，但为整个 Network 服务的 DHCP 仍然只有一个。e.g.  
![在这里插入图片描述][c872643a52a337dc883d3cb2e4e7f848.png]

## Port ##

Network 是二层网络的抽象，Subnet 是三层子网的抽象，Port 就是网卡（NIC）的抽象，是连接 Nova 虚拟机与 Neutron Subnet 的桥梁，也是 Subnet 接入 L3 Router 的桥梁。

直白的说，Port 就是一个虚拟网卡（vNIC），Port 的关键属性就是 IP 地址和 MAC 地址。虚拟机需要绑定 Port，路由器也要绑定 Port。  
![在这里插入图片描述][5c6d6ae3ab64a7c84f81f55d5ad177d4.png]  
![在这里插入图片描述][e5de18483c9cf11f6185b5c505136055.png]  
Port 与 Subnet 一样下属于 Network，Port 与 Subnet 的关系是水平的，为多对多。Port 的 IP 地址来源于 Subnet，也就是说一个 Port 可以具有多个 IP 地址。不过通常情况下，Port 有且只有一个 MAC 地址，对应 Port 资源模型的 mac\_address 属性。

**Port 与 Network、Subnet 的关系如下图**：  
![在这里插入图片描述][348540773c72b611a4b0b15762559ede.png]

### Neutron 安全组（Security Group） ###

Neutron 提供了 Security Group 和 FWaaS 两种安全机制，前者的作用域是单个虚拟机或 Port，后者的作用域是一个具体的网络。而 Security Group 又分为 Nova Security Group 和 Neutron Security Group，这里我们主要讨论的是 Neutron（Port）Security Group。

![在这里插入图片描述][e967a0d62dd64df1bc6f0812367a4216.png]

当用户将一个 Port 挂载到虚拟机时，底层逻辑会在该虚拟机所处的计算节点上创建一个 Tap 设备并将 Port 的特征信息隐射到这个 Tap 设备，从而实现了为虚拟机添上一张虚拟网卡（vNIC）。我们在 Neutron 网络实现模型的章节中提到过，虚拟机的 vNIC（Tap 设备）并非是直连到 OvS br-int（综合网桥）的，之间还存在一个安全网桥（Linux Bridge qbr-XXX）层。e.g.  
![在这里插入图片描述][e002872b9c1baae3170b6b9788171384.png]  
如上图，**Linux Bridge qbr-XXX 就是 Neutron Security Group 的底层支撑**。当用户为指定 Port 设定一系列 Security Group Rules 时，Neutron 实际上是通过 CLI 方式调用操作系统的 iptables 指令为 qbr-xxx 上的 Tap 设备配置了相应的 iptables rules。这就是所谓的 “安全层”。

那么问题来了：为什么不能直接在 OvS br-int 上为虚拟机 Port（Tap 设备）设定安全组规则？非得莫名的增加一个安全层？这是因为 OvS Bridge 本身不支持对连接到其自身的 Tap 设备使用 iptables。

直到，OvS 2.5 提出了 “基于流表” 的 Security Group 特性，它应用 Linux 内核的 conntrack（CT）模块实现了对网络连接状态识别和处理。OpenStack 则从 M 版开始应用 OvS 这一新特性，支持 openvswitch securitygroup driver，支持使用 OvS 来实现 “有状态防火墙” 功能。可以通过修改 Neutron 的 ML2 配置文件来选择 Neutron Security Group 的驱动类型。

# /etc/neutron/plugins/ml2/ml2_conf.ini
    
    [securitygroup]
    firewall_driver = openvswitch

当然了，如果选择了 openvswitch securitygroup driver，那么 Neutron 的网络实现模型就不再需要 qbr-XXX 安全层了。相应了少了一层转发之后，网络性能也会有所提高，尤其在安全组规则数量巨大的时候。  
![在这里插入图片描述][4050b0c4da4cf75320c97fcb75a63f01.png]  
![在这里插入图片描述][6b03a405d12160c05fb65fcfe6e1110c.png]  
关于 OvS Security Group 的实现细节，这里暂不作过多讨论，感兴趣的小伙伴可以浏览《[OVS实现安全组，你需要知道这些！][OVS]》

### 可用地址对（Allowed address pairs） ###

Neutron Security Group 不仅仅只会一味的按照安全组规则来对虚拟机进行保护，Security Group 本身的存在（启用）就已经设定了一些安全策略，例如：为了防止虚拟机被 ARP Spoofing（ARP 欺诈）、 DHCP Spoofing 的 Port IP/MAC 地址绑定安全策略。由此，默认情况下，一个 Port 的 IP 地址和 MAC 地址是一一对应且绑定，也就是说对这个 Port 的 IP 地址进行添加、修改、删除都会被 Neutron Security Group 判定为非法行为。这也是之所以在 Neutron 网络环境中无法直接使用 Keepalived 来做虚拟机高可用的原因，这是一个无处安放的 VIP 的问题。  
![在这里插入图片描述][4b5ec0938d0d26d6d8cf37eabd9beca0.png]  
**NOTE**：ARP 反欺诈有很多方案，将 IP/MAC 地址一一绑定是最直接简单的办法。

但就像上文提到的 Keepalived 例子，一个 Port 具有多个 IP 地址的情况总是存在需求的，Port 资源模型的 fixed\_ips 属性就被设计为一个数组类型（Port 可具有多个 IP 地址，1 个 MAC 地址）。针对这样的场景一般有两个办法：关闭 Port Security（port\_security\_enabled，不建议使用）或使用 Allowed address pairs（allowed\_address\_pairs）机制。  
![在这里插入图片描述][9484d908a2d3bd82e26c74a81f5cf9f9.png]  
每个 Port 都具有自己的 allowed\_address\_pairs 数组，它记录了若干对合法的 IP/MAC 地址映射，以此来支持允许多个 IP 与 Port 连通，从而满足一个 Port 具有多个 IP 地址的需求。

更多可用地址对的详情请浏览官方介绍：[https://docs.openstack.org/developer/dragonflow/specs/allowed\_address\_pairs.html][https_docs.openstack.org_developer_dragonflow_specs_allowed_address_pairs.html]

### 创建一个 Port ###

NOTE：Port 是依托于 Network 的，所以首先需要创建一个 Network。  
![在这里插入图片描述][2cc1242c1b9da461954c492dfb953634.png]  
上图创建了一个简单的 Port：

*  Port 的 Fixed IP 地址会从 Subnet1 的 IP 地址池中随机分配，对应 fixed\_ips 属性。
 *  开启了 Port Security，现在 Port 的 IP/MAC 地址一一绑定，对应 port\_security\_enabled 属性。
 *  VNIC 类型为正常（normal），对应 binding:vnic\_type 属性。
 *  没有指定 “设备 ID（device\_id）” 和 “设备所属者（device\_owner）”，所以现在设备的 binding\_vif\_type 状态为 unbound。binding:vif\_type 除了用来标识 Port 的绑定状态（unbound，bound\_failed）之外，还用于标识这个 Port 的 Mechanism 类型（e.g. ovs、bridge、macvtap）。
 *  在创建 Port 的同时可以指定这个 Port 的安全组规则

这里强调一下 “设备 ID（device\_id）” 和 “设备所属者（device\_owner）” 两个字段，它们共同标识了 Port 的绑定实体。比如：Port 绑定到了一台虚拟机，那么 `device_id=<instance_uuid>`，`device_owner=compute:nova`。常见的 device\_owner 还有：

*  network:dhcp — Neutron DHCP Agent 使用的端口，为 Network 提供 DHCP 服务
 *  network:router\_interface — Neutron L3 Router Agent 使用的端口，将 Subnet 接入路由器
 *  network:router\_gateway — Neutron L3 Router Agent 使用的接口，外部网络接入路由器的网管接口

还需要强调一下的是 Port 的类型，Neutron 支持多种类型的 Port，不同类型的 Port 底层可能由不同的 Agent 实现（e.g. ovs-agent、sriov-agent）。  
![在这里插入图片描述][3d5443a417c797b6ad97c6a3344797c0.png]  
只需要提供用户预期的 IP/MAC 地址，即可为 Port 添加可用地址对。在可用地址对清单中的 IP/MAC 都可以通过自动或手动的方式应用到这个 Port 所对应的 vNIC（Tap 设备）上。  
![在这里插入图片描述][365f0b8d377763e30154b02776db2e4a.png]

还需要注意一点，fixe\_ips 属性是一个数值类型，就是说加入一个 Network 下属具有多个 Subnet，那么这个 Port 就可以从多个 Subnets 中获取多个 IP 地址。e.g.

### 挂载一个 Port ###

**使用 Port 来启动一个虚拟机**：

openstack server create --flavor cirros256 --image cirros-0.3.4-x86_64-disk --port Port1 VM1

![在这里插入图片描述][7df3ed6cd35024147744b9ea4b11c7e5.png]  
需要注意的是，即便 Port 具有多个可用地址对，但虚拟机网卡原生的 IP/MAC 依旧是 Port 的原生 fixed\_ips/mac\_address。可用地址对的含义是可以被 Port 使用的 IP/MAC，而非一定会被使用的 IP/MAC。

**Port 挂载到虚拟机之后，其自身的信息也会被更新**：

*  binding\_vif\_type — 从 unbound 变成 ovs，表示底层使用的是 OvS Mechanism Driver。
 *  binding\_host\_id — Port 对应的 Tap 设备所在的主机，也就是 VM 所在的计算节点。
 *  binding\_vif\_details — 记录了一些 Port 挂载后的信息，例如 Tap 设备加入的 OvS Bridge 名称，OvS Bridge 的类型。
 *  device\_id & device\_owner — 指定绑定 Port 的实体对象（虚拟机）和类型（compute:nova）。

**NOTE**：从上述信息可以看出，Port 对应的 Tap 设备实际上实在 “绑定” 之后再创建的，Tap 设备的命名规则为 `tap[port-uuid]`。e.g.

[root@localhost ~]# ovs-vsctl show
    ccb13b70-cffb-4a64-97b1-734bf9040abc
        Manager "ptcp:6640:127.0.0.1"
            is_connected: true
    ...
        Bridge br-int
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
    ...
            Port "tap07995f4e-b6"
                tag: 5
                Interface "tap07995f4e-b6"
    ...            
        ovs_version: "2.9.0"

**使用具有多个 fixed\_ips 的 Port 来启动一个虚拟机**：

[root@localhost ~]# openstack server create --flavor cirros256 --image cirros-0.3.4-x86_64-disk --port Port2-1 VM2

![在这里插入图片描述][865ba1a551b3244dd33b15a3020f6148.png]  
![在这里插入图片描述][7f43b3758e036676a1bba4ac4178fb56.png]  
奇怪为什么 Port 和虚拟机明明有两个 IP 地址，但 GuestOS 起来后却只看见了一个？其实虚拟机启动获取 IP 地址时是随机挑选一个的，不会把 Port 的所有 IP 都配置上去，当然你也可以手动的将两个 IP 地址配置上去。总的来说这种做法和应用可用地址对的效果差不多，如果你只是单纯的希望虚拟机具有多个 IP，还是建议你使用可用地址对。但如果你希望虚拟机可以实现跨网段中断，那么就可以使用具有多个 Subnet IP 的 Port。

## Router ##

Router 是 Neutron 实现的路由器抽象。

需要注意的是，Router 只是 Neutron 对 Linux 服务器路由功能的抽象，而非 Neutron 实现了一个完整的 vRouter 软件。这之间有着巨大的区别。Neutron Router 对 Linux 路由功能进行了封装，并由 L3 Agent 服务进程负责处理。通常的，L3 Agent 只运行在网络节点中，所以所有的跨网段访问流量、公网访问流量都会流经网络节点。由此，网络节点成为了 Neutron 三层网络的性能瓶颈，为了解决这个问题，Neutron 提出了 DVR（分布式路由器）机制，让每个计算节点都具有三层网络功能。

简而言之，对于上层应用而言，只需要关注 Router 的 **端口**、**网关**、**路由表** 即可。

NOTE：关于 Linux 路由功能在《[Linux 的路由功能][Linux]》一文中已经介绍过，这里不再赘述。

![在这里插入图片描述][009ddf556e0f3d573684a8f7fabcae2f.png]  
![在这里插入图片描述][de863568af5865dba67750c035d5e434.png]

### 外部网关 ###

Neutron 语义环境中的 “外部网关” 有两重含义：

*  实际的外部网关（下文称为物理外部网关），在 Neutron 的管理范畴之外。如下图的 Router\_2 上的 Port2。
 *  Neutron 的外部网关（下文成为 Neutron 外部网关，以作区别），在 Neutron 的管理范畴之内。如下图 Router\_1 上的 Port1。

我们思考一个问题：为什么 Neutron 内部网络需要通过 Router\_1 再与 Router\_2 进行连接？而不将内部网络直连 Router\_2 然后访问公网呢？首先明确一点，下图中 “Neutron 管理的内部网络” 指的是租户网络而非运营商网络。运营商网络当然可以映射到一个直连物理外部网关的物理网络，这是因为云管人员手动的为运营商网络提供了物理网络的 “核心三要素”。同理，如果租户网络希望直连到物理外部网关，那么就需要云管人员提供连接到物理外部网关的 “核心要素（e.g. 外部网关的 IP 地址）”。但是，让云管人员为每个租户网络都手动的 “填入”（实际上并非填入，而是获取） “核心要素” 显然是不明智的，再者物理路由器很可能没有足够的接口数量供租户网络使用。

![在这里插入图片描述][b67ab79fbff3501c6790517e57b4d5b3.png]  
出于这样的前提，Neutron 在租户网络和外部网关之间引入了一个内部路由层。每个租户都可以创建专属的内部路由层，包含若干个 L3 Router 实例对象。租户可以随意的将租户网络接入内部路由层，然后再由内部路由层统一对接物理外部网关。这样物理路由器的端口就能得到更高效的利用。  
![在这里插入图片描述][25828095b86369a55afd0dfe3e16a8b8.png]  
**NOTE**：创建多个 L3 Router 实例对象并非是说需要多个 Linux 服务器，Neutron 通过 qrouter-XXX network namespace 在网络节点上隔离出了多个 “虚拟路由器”。每创建一个 Router，运行在网络节点的 L3 Agent 就会新建一个 qrouter-XXX。由于 qrouter-XXX 具有自己独立的路由表，所以同一租户下不同的 Network 之间允许具有相同 IP 网段（CIDR）的 Subnet，只要这些 Subnet 只要不连接到同一个 Router 上就不会出现 IP 地址重叠的问题。

如上图，Router\_1 对接 Router\_2 的方式很简单，只需在 Router\_1 添加一条路由表项即可。e.g.

destination          next_hop     out_interface
    104.20.110.0/24  182.24.4.1   Port1(182.21.4.6)

这条路由表项的关键信息有三：物理外部网关 IP（182.24.4.1）、Neutron 外部网关 IP（182.21.4.6）以及隐藏信息 —— 运营商网络（外部网络）182.24.4.0/24。

**NOTE**：此处的运营商网络（外部网络）182.24.4.0/24 不是上图中的外部网络（公网），而是勾选了 “外部网络” 的运营商网络。

![在这里插入图片描述][6afeb9a7feabaf6e8374a2b81d9dd5b9.png]

可见，Neutron 内部网络要想连接公网，关键在于如何获取上述 3 个关键信息。办法很简单，只需要创建一个运营商网络（外部网络）即可，例如：182.24.4.0/24。物理外部网关 IP（182.24.4.1）就是运营商网络（外部网络）对应的 Subnet 的 gateway\_ip 属性，而 Neutron 外部网关 IP（182.21.4.6）就是该 Subnet 分配的一个子网 IP 地址。存放这些信息的 Router 资源模型属性就是 external\_gateway\_info：

{
    	"external_gateway_info": {
    		"enable_snat": true,
    		"external_fixed_ips": [{
    			"ip_address": "182.24.4.6",
    			"subnet_id": "b930d7f6-ceb7-40a0-8b81-a425dd994ccf"
    		}],
    		"network_id": "ae34051f-aa6c-4c75-abf5-50dc9ac99ef3"
    	}
    }

*  network\_id — 运营商网络（外部网络）
 *  subnet\_id — 运营商网络（外部网络）的 Subnet（其 gateway\_ip 就是物理外部网关 IP 地址）
 *  ip\_address — Neutron 外部网关 IP 地址
 *  enable\_snat — Neutron 外部网关端口是否开启 SNAT 功能

如果开启了 SNAT，Neutron 就会在 qroute-XXX namespace 中添加这样的一条 iptables rule，所有从 qg-426c2bcd-f4（如上图 Port 1）出去的数据包，无论你来自哪里（源 IP 地址）或者要去哪里（目的 IP 地址），数据包的源 IP 地址都会被转换为 172.18.22.210。

[root@localhost ~]# ip netns exec qrouter-a1adb970-dba9-49f0-ba4b-4294f0d07f6f iptables -nvL -t nat
    ...
    
    Chain neutron-l3-agent-snat (1 references)
     pkts bytes target     prot opt in     out     source               destination
        2   142 neutron-l3-agent-float-snat  all  --  *      *       0.0.0.0/0            0.0.0.0/0
        2   142 SNAT       all  --  *      qg-426c2bcd-f4  0.0.0.0/0            0.0.0.0/0            to:172.18.22.210
        0     0 SNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match ! 0x2/0xffff ctstate DNAT to:172.18.22.210

NOTE：添加这条 SNAT 的原因是，Linux 作为路由器时仅仅开启了内核的路由转发功能是不够的，还需要添加这么一条 SNAT。那为什么不需要添加 DNAT 呢？因为作为路由器而言，所有的数据包都只是 SNAT（送出去）而已。

### 新建 Router 和外部网关端口 ###

从上文可一直，当我们希望 Neutron 内部网络连通公网时，就创建一个运营商网络（外部网络），然后使用 L3 Router 将内部网络与运营商网络（外部网络）直连起来即可。e.g.

*  新建 Router。如果此时用户选择了 “外部网络”，那么 Neutron 会自动的创建 Router1 与 public 直连的外部网关端口。需要注意的是，只有这一种情况下 Neutron 会自动创建路由端口，否则都需要用户手动创建。  
    ![在这里插入图片描述][5286301b5ef17bee240c49d55e01d974.png]
 *  内部网络 Net1 和运营商网络（外部网络）public 通过 Router 直连  
    ![在这里插入图片描述][4ab80f7c49df22dbb316da993df2ae69.png]
 *  public 有一个端口连接到 Router，类型为 `network:router_gateway`，IP 为 172.18.22.210（Neutron 外部网关 IP）。  
    ![在这里插入图片描述][5f67627d5b2707270fdfafcb1054c24d.png]
 *  public 的 Subnet public-subnet 具有物理外部网关 IP 地址 172.18.22.1。

*  Router 具有两个端口，一个连接 Net1，IP 地址是 Net1 的网关 IP 192.168.1.1；另一个连接 public，IP 是 Neutron 外部网关 IP 172.18.22.210。  
    ![在这里插入图片描述][1919018887bd2d158508ab6f6f0c6209.png]
 *  Router1 的路由表和网络设备：

[root@localhost ~]# ip netns exec qrouter-a1adb970-dba9-49f0-ba4b-4294f0d07f6f ifconfig
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    qg-426c2bcd-f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 172.18.22.210  netmask 255.255.255.0  broadcast 172.18.22.255
            inet6 fe80::f816:3eff:fe0b:c722  prefixlen 64  scopeid 0x20<link>
            ether fa:16:3e:0b:c7:22  txqueuelen 1000  (Ethernet)
            RX packets 765265  bytes 36064217 (34.3 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 90  bytes 5316 (5.1 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    qr-cf018461-bc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.1.1  netmask 255.255.255.0  broadcast 192.168.1.255
            inet6 fe80::f816:3eff:fea5:b2bb  prefixlen 64  scopeid 0x20<link>
            ether fa:16:3e:a5:b2:bb  txqueuelen 1000  (Ethernet)
            RX packets 216  bytes 18796 (18.3 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 139  bytes 13870 (13.5 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    [root@localhost ~]# ip netns exec qrouter-a1adb970-dba9-49f0-ba4b-4294f0d07f6f route -nne
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    0.0.0.0         172.18.22.1     0.0.0.0         UG        0 0          0 qg-426c2bcd-f4
    172.18.22.0     0.0.0.0         255.255.255.0   U         0 0          0 qg-426c2bcd-f4
    192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 qr-cf018461-bc

其中 qr-XXX 和 qg-YYY 在 qroute-XXX namespace 中用于连接 br-int 和 br-ex，从第二、三条路由表项是由链路层协议发现并创建的，分别是 Net1 和 public 子网的直连路由，由设备 qr-XXX 和 qg-YYY 转发。而第一条路由表项，则是由 Neutron 添加的默认静态路由，Neutron 从 public 的 gateway\_ip 获取到物理外部网关 IP 地址，所有非直连路由的子网访问流量，都会使用默认静态路由进行转发。

### Router 的路由表 ###

我们知道路由器的路由表项分配静态路由和动态路由，Neutron 中所有的路由表项均为静态路由（不遵循动态路由协议），又细分为：

*  静态路由
 *  静态默认路由
 *  直连路由

其中只有 “静态路由” 一种类型会被 Neutron 记录在 Router 资源模型的 routes（数值类型）属性中。

后面两种路由表项类型为什么不被持久化呢？因为静态默认路由的信息来自外部网络的 gateway\_ip 属性，而直连路由则由链路层协议自动发现、创建。所以不需要额外的持久化。

那么静态路由又是什么路由，为什么要持久化呢？  
![在这里插入图片描述][9b71628b016ac49eee234ff1d90e4ee7.png]

+----------------+-------------+--------------------------------------+
    | destination    | nexthop     | router_id                            |
    +----------------+-------------+--------------------------------------+
    | 192.168.1.2/32 | 172.18.22.1 | a1adb970-dba9-49f0-ba4b-4294f0d07f6f |
    +----------------+-------------+--------------------------------------+

如上，Router 的静态路由其实就是常规的主机路由或网络路由，使用户自定义的路由表项。但需要注意的是，“下一跳” 表单不能随意乱填，而是限制在 Router 够得着的子网 IP 地址。否则就会 *the nexthop is not connected with router*。

**NOTE**：在讲述 Subnet 资源模型的章节中你或许会对 Subnet 的 gateway\_ip 和 host\_routes 属性感到疑惑，通本章的举例，或许你能够更好的理解这些字段所具有的功能和含义。

### Floating IP ###

从功能的角度可以将 Neutron 的 IP 分为：

*  **Fixed IP**：由租户网络 Subnet 分配，用于虚拟机的内部通讯，创建虚拟机时自动分配。
 *  **Floating IP**：有外部网络分配，用于虚拟机访问公网，需要手动分配。

前文中我们提到过，一般的运营商网络和勾选了 “外部网络” 的运营商网络的主要区别在于后者可以分配 Floating IP，实现的原理就是内部网络与外部网络之间的 Router（qroute-XXX）的 NAT（SNAT&DNAT）功能。  
![在这里插入图片描述][6b08a5d01923abb6b72b25dd3a2d19ba.png]  
上图可见，外部网络 public 成为了一个 Floating IP 地址池。创建一个 Floating IP 会相应的创建一条数据库记录：

MariaDB [neutron]> select * from floatingips\G;
    *************************** 1. row ***************************
              project_id: 031cec3e2df143259d302aa1993fd410
                      id: 67272b76-493a-4a60-b63a-22e5aefebfc0
     floating_ip_address: 172.18.22.204
     floating_network_id: 282e146e-6948-436f-992c-f2d50588e357
        floating_port_id: 04aceef8-a3b2-46e4-a815-3104a2031ed7
           fixed_port_id: NULL
        fixed_ip_address: NULL
               router_id: NULL
    last_known_router_id: NULL
                  status: DOWN
        standard_attr_id: 82
    1 row in set (0.01 sec)

![在这里插入图片描述][9394e4d1cb119cb2cf840b450ce6ed07.png]  
![在这里插入图片描述][07255497b8b56990e444d95dcad1be87.png]  
为虚拟机绑定这个 Floating IP 之后，数据库记录会被更改：

MariaDB [neutron]> select * from floatingips\G;
    *************************** 1. row ***************************
              project_id: 031cec3e2df143259d302aa1993fd410
                      id: 67272b76-493a-4a60-b63a-22e5aefebfc0
     floating_ip_address: 172.18.22.204
     floating_network_id: 282e146e-6948-436f-992c-f2d50588e357
        floating_port_id: 04aceef8-a3b2-46e4-a815-3104a2031ed7
           fixed_port_id: 07995f4e-b6b2-493f-9ce5-b1d945a13807
        fixed_ip_address: 192.168.1.27
               router_id: a1adb970-dba9-49f0-ba4b-4294f0d07f6f
    last_known_router_id: NULL
                  status: ACTIVE
        standard_attr_id: 82
    1 row in set (0.00 sec)

qroute-XXX 中的 iptables rules 也会相同的添加 SNAT、DNAT 规则：

[root@localhost ~]# ip netns exec qrouter-a1adb970-dba9-49f0-ba4b-4294f0d07f6f iptables -nvL -t nat
    ...
    
    # 到目的 IP 地址 172.18.22.204 的数据包 DNAT 至 192.168.1.27
    Chain neutron-l3-agent-PREROUTING (1 references)
     pkts bytes target     prot opt in     out     source               destination
        ...
        0     0 DNAT       all  --  *      *       0.0.0.0/0            172.18.22.204        to:192.168.1.27
    ...
    
    # 从源 IP 地址 192.168.1.27 来的数据包 SNAT 至 172.18.22.204
    Chain neutron-l3-agent-float-snat (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 SNAT       all  --  *      *       192.168.1.27         0.0.0.0/0            to:172.18.22.204
    ...

这一切都发生在 qroute-XXX network namespace 中，实现了不同 Router 之间的网络隔离。

转载请注明作者：JmilkFan 范桂飓

[Link 1]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_0
[Neutron]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Neutron__2
[Network]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Network_6
[Link 2]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_35
[Link 3]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_57
[Link 4]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_85
[Link 5]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_124
[Network 1]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Network__131
[Subnet]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Subnet_139
[IP]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#IP__155
[SubnetPools]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#SubnetPools__185
[Multi-Segments]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#MultiSegments_224
[Subnet 1]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_Subnet_245
[Network _ Subnet]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Network__Subnet__253
[Port]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Port_266
[Neutron _Security Group]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Neutron_Security_Group_276
[Allowed address pairs]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Allowed_address_pairs_299
[Port 1]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_Port_310
[Port 2]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_Port_415
[Router]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Router_498
[Link 6]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_510
[Router 1]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#_Router__565
[Router 2]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Router__647
[Floating IP]: https://www.cnblogs.com/jmilkfan-fanguiju/p/10589718.html#Floating_IP_680
[https_developer.openstack.org_api-ref_network_v2_index.html]: https://developer.openstack.org/api-ref/network/v2/index.html
[Networking]: https://blog.csdn.net/Jmilk/article/details/85169871
[24dd40043837fbd37c1a9004c7d44e34.png]: /images/20220829/d62caf6c4fea489484b2723e80adb54c.png
[ced035e2cf5b97d43e78caa7016ea08e.png]: /images/20220829/821213d110bf43279b0431d2e7dc9229.png
[9f554cba50e246484a159975a36aad77.png]: /images/20220829/b31f94e31af347169fdcf15a027a88ec.png
[9e2dbcdd79e5308d4df42972ce2c3290.png]: /images/20220829/1841e48d33fd458d8c5682f28169fe15.png
[90ab517dee7e1b3cc34583710485b8c9.png]: /images/20220829/aede55bdc6db44409c2ba56c5e011485.png
[44ad2a7e51ac9501a5764926a0eccbf3.png]: /images/20220829/9946fade50f043a58dadc48edba7de7a.png
[7d82ce6b58479174e74a5e1d1a849750.png]: /images/20220829/a815386b2d90498cbdf5edc8eb3ca88d.png
[a456d95e4ab9512306840a53c214731c.png]: /images/20220829/385c27c09613460c8d1d8206f05bfa28.png
[3ee96372b4134a20b41f6783c6929cec.png]: /images/20220829/b75a5796bbaf47cd8f15d8207481d1e5.png
[204507946e808841080befdd4e2327a4.png]: /images/20220829/5523772987be4d828c62b35de5cf3eb5.png
[3131df388179eea0fc34e1b3ea4606e1.png]: /images/20220829/d437b073a71846079f19aef9733d6add.png
[e16f7226b427d1ef28945c2ab333656b.png]: /images/20220829/9cbe483e269e4608938774592dae1e26.png
[b3f0ab1ba2e37e117ad892faa614e056.png]: /images/20220829/5f335ad751ee4b15ba3c183f434e6b93.png
[4e7b851230cc13d3cb7531c1388d1ba1.png]: /images/20220829/3ff081945c2846ebb213efd5b2e87a3c.png
[d1109125df5a5991efbf3e7a25ceb71d.png]: /images/20220829/bc1889b1e1074ea597700a857a9312d3.png
[bf7a461c481434efe392854f1122aacf.png]: /images/20220829/9ac3335f50f44af4be2255783c4b8450.png
[31bf745481fe026fde6d654a1ab0d553.png]: /images/20220829/d92ad631df4445628d940f73464aea20.png
[https_docs.openstack.org_newton_networking-guide_config-routed-networks.html]: https://docs.openstack.org/newton/networking-guide/config-routed-networks.html
[a937767662bc39ac2645a190d5427929.png]: /images/20220829/03a3368d433e499690a99a9d49b69c58.png
[ac71634eec0bd470ecb36045ca04d4ad.png]: /images/20220829/9029888fde0b48319ba9e1cf0fdeb540.png
[18b1f0ac66dd2ce31c6dabdd40f7c7e1.png]: /images/20220829/fcaf03f3513641178dae096dd6f0ccd8.png
[c872643a52a337dc883d3cb2e4e7f848.png]: /images/20220829/0edfd3c171e34b348d4df1192dbe8ecf.png
[5c6d6ae3ab64a7c84f81f55d5ad177d4.png]: /images/20220829/3adc6a4c484246b59c527d40571ff1a3.png
[e5de18483c9cf11f6185b5c505136055.png]: /images/20220829/f990c3c9d67947199ba529774125d518.png
[348540773c72b611a4b0b15762559ede.png]: /images/20220829/29a52b27c019484584b921d82209fffb.png
[e967a0d62dd64df1bc6f0812367a4216.png]: /images/20220829/bc259054ecc046139418823582b3b1f0.png
[e002872b9c1baae3170b6b9788171384.png]: /images/20220829/35d33da695ab4430a1da487cfb349b3e.png
[4050b0c4da4cf75320c97fcb75a63f01.png]: /images/20220829/78172d363a8844efab9f0ee24e2395a1.png
[6b03a405d12160c05fb65fcfe6e1110c.png]: /images/20220829/a78bdd9170194f56807f6eefe86547da.png
[OVS]: https://mp.weixin.qq.com/s/PC25WlplxerxYlSTnqPkqw
[4b5ec0938d0d26d6d8cf37eabd9beca0.png]: /images/20220829/d80ece953066441eb1e79d30a0870c0f.png
[9484d908a2d3bd82e26c74a81f5cf9f9.png]: /images/20220829/06aa9d01a11848f1b55a4991c58f3fa8.png
[https_docs.openstack.org_developer_dragonflow_specs_allowed_address_pairs.html]: https://docs.openstack.org/developer/dragonflow/specs/allowed_address_pairs.html
[2cc1242c1b9da461954c492dfb953634.png]: /images/20220829/4625951feb804b92b550ff751c0e814f.png
[3d5443a417c797b6ad97c6a3344797c0.png]: /images/20220829/00e1304827034505adc13fda5965f0c3.png
[365f0b8d377763e30154b02776db2e4a.png]: /images/20220829/31f5d01427e44611836ed836c3943137.png
[7df3ed6cd35024147744b9ea4b11c7e5.png]: /images/20220829/734defb580d74fc7bbc28b232f1412e4.png
[865ba1a551b3244dd33b15a3020f6148.png]: /images/20220829/b71f34a7d3314d3281eba836339d08a2.png
[7f43b3758e036676a1bba4ac4178fb56.png]: /images/20220829/0e69f3c617c846678a96b39ef81f8fdd.png
[Linux]: https://blog.csdn.net/Jmilk/article/details/86632193
[009ddf556e0f3d573684a8f7fabcae2f.png]: /images/20220829/bc5e451ac930428a8eb5666ccfd6eba3.png
[de863568af5865dba67750c035d5e434.png]: /images/20220829/616b6153f4c6494a9e21926e69ac74c5.png
[b67ab79fbff3501c6790517e57b4d5b3.png]: /images/20220829/1a31ef419c80416e9649539dae6516a0.png
[25828095b86369a55afd0dfe3e16a8b8.png]: /images/20220829/6a7c159777314969ab1749cb21ae3e5b.png
[6afeb9a7feabaf6e8374a2b81d9dd5b9.png]: /images/20220829/3390f61198e641dba619929313f97ce3.png
[5286301b5ef17bee240c49d55e01d974.png]: /images/20220829/d19c9ba3f38e4249bb3991005458e9c7.png
[4ab80f7c49df22dbb316da993df2ae69.png]: /images/20220829/b97ddb12c5bd4574b85db9d2fdb45835.png
[5f67627d5b2707270fdfafcb1054c24d.png]: /images/20220829/6c109d806c134d6cbeae7329e76a405f.png
[1919018887bd2d158508ab6f6f0c6209.png]: /images/20220829/0f34d334434443e8b1d9bfe852bc2f22.png
[9b71628b016ac49eee234ff1d90e4ee7.png]: /images/20220829/2d919cea471f4b96872461ab64f233f5.png
[6b08a5d01923abb6b72b25dd3a2d19ba.png]: /images/20220829/8024dc0e33484f269c67500b7c4436a6.png
[9394e4d1cb119cb2cf840b450ce6ed07.png]: /images/20220829/94547aa218d4467ab8f040c42e8fbaa2.png
[07255497b8b56990e444d95dcad1be87.png]: /images/20220829/8d56f8adf22a4e61ba4bafe8967e61b0.png