深度探索 OpenStack Neutron：Neutron 实现模型

此文章源于鄙人微信公众号“标哥说天下”

【上次发表了（1），这次就不发表（2）了，而是在（1）的基础上继续往下写。如果您已经看过（1），可以往下翻，从 4.2.3 小节开始看起，谢谢！】

2016.01.16 开始写下第一个字

2016.11.04 突破10万字，历时 294 天

2017.02.26 突破20万字，历时 114 天

第四章 Neutron 网络实现模型

Neutron 的模型有两种。

一种是抽象的逻辑模型，比如我们耳熟能详的“Network，Subnet，Port”等等，读者可以参考“https://developer.openstack.org/api-ref/networking/v2/”，有个直观认识。

另一种模型是这种抽象逻辑模型背后的实现模型。无论一个模型多抽象还是多具体，其归根到底总归要有一个实现它的载体。比如 CloudVPN，OPEN-O 这个开源组织，就通过一系列的网元和一定的组网来实现，如下图所示：

图１ OPEN-O CloudVPN 的实现模型

Neutron 实现它自身的抽象逻辑模型，也有它自己的一套方法，或者说叫实现模型。简单地说，这个实现模型包含相应的网元、组网以及网元上对应的配置。

本文两种模型都会讲述，笔者以为，我们需要先了解实现模型，再来看其抽象逻辑模型，这样的顺序会更加自然流畅，事半功倍。

本章，我们就着手讲述 Neutron 的实现模型。

【说明】阅读本章，您需要有相应的背景知识：tap, tun, veth pair, bridge, iptables, ovs, gre, vxlan, evpn 等等。您可以关注微信公众号“标哥说天下”，回复相应信息，以获取对应文章。

关键词	文章
EVPN2 evpn2	深度探索 OpenStack Neutron：EVPN（2）
EVPN1 evpn1	深度探索 OpenStack Neutron：EVPN（1）
VXLAN vxlan	深度探索 OpenStack Neutron：VXLAN
IPTABLES iptables	OpenStack Neutron 分析：iptables
GRE gre	OpenStack Neutron 分析：Tunnel/GRE
LVN4 lvn4	OpenStack Neutron 分析：Linux 虚拟网络知识（4）
LVN3 lvn3	OpenStack Neutron 分析：Linux 虚拟网络知识（3）
LVN2 lvn2	OpenStack Neutron 分析：Linux 虚拟网络知识（2）
LVN1 lvn1	OpenStack Neutron 分析：Linux 虚拟网络知识（1）

Neutron 网络实现模型相关背景知识

【版权统一申明】本章，统一参考借鉴了《深入理解Neutron(OpenStack网络实现).pdf》里面所讲述的知识。

4.1 Neutron 的三类节点

Neutron 在实际组网时，有三类节点，如下图所示：

图２ Neutron 的三类节点

关于这三类节点，我们在后面还会详细描述，或者说，整个这一章，都是围绕这三类节点进行展开讲述。这一小节，我们先有个简单的只管认识即可。

计算节点（Compute Node），这个最直观。整个 OpenStack 的三大组件：计算、存储和网络，没错，这里的计算节点，就是“计算”。而所谓“计算”，大白话就是虚拟机（VM）。所以，在上图中，我们看到，计算节点里画了一堆虚拟机。一个计算节点就是一个 Host。

其实，计算节点里还有 bridge，当然这个 bridge，不是我们把一个硬的 bridge 塞到一个 Host 里面去，而是 Linux 虚拟的 bridge。

图３ 我告诉你们，ATM 机里真的有人

不同 Host 的 VM 之间的二层通信，通过计算节点的 bridge，就可以完成。

但是，如果 VM 想要访问 Internet，就得通过 Router 先到达数据中心的网关（通过网关再出去），这个 Router 也是 Linux 虚拟出来的，它所在的位置就是网络节点（Network Node）。网络节点里还部署着 DHCP 等各种网络服务。一个计算节点，就是一个 Host，而一个网络节点，可以意味着是一个 Host 也可以意味着一个 VM。我们可以把 Router 及各种网络服务就部署在一个 Host/VM 中（这个时候仅有一个网络节点），也可以部署在多个 Host/VM 中（多个网络节点）。

说了这么多，好像没有 Neutron 什么事，^_^。Neutron 在这里其实扮演两种角色，一个角色是在各个计算节点、网络节点中运行着各种各样的 Agent（如果您不了解，可以忘掉这个概念，我们会在以后的章节讲述），另一个角色就是各种各样的 Neutron 服务，正如上图中所指出的那样，这些服务就是运行在控制节点（Control Node）中。与网络节点一样，一个控制节点意味着一个 Host/VM，这些 Neutron 服务可以部署在一个 Host/VM 中，也可以部署在多个 Host/VM 中。

当然，我们会有这样的疑问：Neutron 隶属于 OpenStack，而 OpenStack 就是搞基的，哦，说错了，就是搞虚拟机的（这么说，还是有点污，好吧，是搞云的......），在 OpenStack（含 Neutron）没有部署起来之前，哪来的虚拟机？呵呵，我们可以通过 vMWare 先创建几个虚拟机啊（一点不给 OpenStack 面子，^_^）。不过，话又说回来，就算我们真的创建了虚拟机，Neutron 也会认为它的控制节点和网络节点是创建在 Host 上的，骨气还是要有的！

以上就是我们对 Neutron 三类节点的简单解释，下面我们就会逐步展开介绍。

4.2 计算节点的实现模型

4.2.1 抽象模型

我们设想这样一个场景：两个主机（Host）位于一个机架（RACK）内，这两个主机分别虚拟出 N 个虚拟机（VM，Visual Machine）。从每个 Host 内调出若干个 VM，组成一个二层网络（可以先想象为一个 VLAN）。

这样一个场景，我们首先看看需要的物理设备有：机架、主机、TOR 交换机（top of rack，TOR 交换机顾名思义，就是位于机架顶端的交换机）。下图是一个数据中心的场景，您可以直观感受一下那一排排机架：

图４ 数据中心一排排机架

在我们这个场景中，我们忽略 Neutron 的控制节点，我们也不考虑场景中的虚拟机需要与外部网络（比如 Internet）通信（即也忽略网络节点），就是考虑计算节点之间的 VM 的二层通信。

我们基于这个忽略，所得出的计算节点的“抽象”模型如下：

图５ 计算节点的“抽象”模型

之所以把“抽象”模型的“抽象”二字，打个引号，是因为没有绝对的抽象，其中物理网络那部分没有抽象，还是引用了一个实际的设备“TOR”。

图中的 TOR 的外围的方框“(DC)Physical Network”是 Neutron 里面一个非常重要而且非常烦人的概念，不过这里我们只是画在那里，暂时搁置它。这个概念，我们留待后面的章节再解释。这里我们只须这样理解：从模型上讲，有这么一个名词；从概念上讲，先理解为一个 TOR 交换机（这么理解，不会对下面的模型讲述，造成困扰）。

图中有两个 Compute Node，每个 Node 都是一个 Host。这个很好理解，毕竟 OpenStack 就是为“云”而服务的，而所谓“云”，在一个 Host 内虚拟出若干个 VM 是基础。所以，我们在图中也看到，每一个 Compute Node 里面有若干个 VM。

图中，Security Layer，大白话就是实现 Firewall（防火墙）功能。Integration Layer，是实现综合网络功能（交换/路由）的一层。 （其实，防火墙也是网络功能的一部分，这里只是特意将防火墙功能专门列出来而已，并不是说，防火墙功能就不是网络功能的一部分。以下涉及名词“网络功能”时，有时候是包括防火墙功能的，这一点请您留意）

与“(DC) Physical Network”相对应的是，Security Layer 和 Integration Layer，它们的本质是“X86/Linux”实现。“X86/Linux”，是当前虚拟机的主流系统，指的是：硬件是 Intel X86 兼容硬件；软件是 Linux 操作系统。

OpenStack Neutron 仅仅是一个管理系统（或者说是一个控制系统），它本身并不能实现任何网络功能，它仅仅是“X86/Linux”相关功能做一个配置或者驱动而已。所以实际上，Security Layer 和 Integration Layer，它们的本质是“X86/Linux”实现。与之相对应的是，“(DC) Physical Network”是专有的实现，比如 华为生产的 TOR 交换机。

下面我们就来看看，OpenStack Neutron 是如何借用“X86/Linux”实现来表述网络功能的。

4.2.2 VLAN 实现模型

4.2.2.1 基本介绍

我们直接上图：

图６ 计算节点的 VLAN 实现模型

咋一看这个图，会直接崩溃，^_^。

所以，笔者再次强调：阅读本章，您需要有相应的背景知识：tap, tun, veth pair, bridge, iptables, ovs, gre, vxlan, evpn 等等。笔者这里假设，您已经具备这些知识。

下面笔者针对这个图，做一个介绍。

4.2.2.1.1 VM 及 VLANID

图中4个 VM，组成两个 VLAN，VLANID 分别为 10 和 20。这两个 VLANID 有一定的说法，即有内外之别。这里我们先讲解内外之别是什么，后面在讲述为什么需要这个内外之别。我们首先看图：

图７ 计算节点 VLAN 的简化的实现模型

上图是对前面的实现模型的一个更加简化的模型。我们继续忽略掉那些各种各样的 bridge，各种各样的 TAP，VETH pair 等等，就简单理解，一个 Host 内有一个 bridge。那么，两个 Host 内的每个 VM，其所属的 VLAN，如上图所示。这个是打开 Host，看每个虚机 VLAN 的视角，而从租户（tenant，OpenStack 讲究“tenant”这个词，这里我们先不纠结，就当作是一个用户/user 来理解）的视角来看，他是创建了两个 VLAN，如下图所示：

图８ 租户视角的两个 VLAN

从租户视角，他就是创建了两个 VLAN，VLANID 分别为 100 和 200。这样，VLANID 就存在了内外之别，如下表所示：

租户视角 VLANID （外部 VLAN）	Host1 视角 VLANID （内部 VLAN）	Host2 视角 VLANID （内部 VLAN）
100	10	30
200	20	40

表1 VLANID 的内外之别

为什么会有这样的内外之别，我们放在下一个小节来讲述。这里我们需要知道两点：（A）存在这样的内外之别；（B）这个内外之别需要做 VLANID 转换，而转换的功能，就是由 Host 内相应的 bridge 来实现（这个我们下面就会讲述）。

4.2.2.1.2 qbr 及 br-int

VM 与 qbr 之间通过 TAP 连接，qbr 与 br-int 之间，通过 VETH pair 连接。TAP， VETH pair，我们就讲述了，您可以参见相关章节。

qbr 与 br-int 都是 bridge。qbr 的实现载体是 Linux Bridge，就是我们说的“X86/Linux”原生实现。br-int 的实现载体，也是“X86/Linux”实现，只是不能算作“原生”实现，因为 br-int 的实现载体是 OVS（Open vSwitch），OVS 是在“X86/Linux”的基础上，又做了一层封装（可以用封装这个词，虽然它写了很多代码）。关于 OVS 笔者也写了相关文章，笔者这里就不再啰嗦。（其实，关于 OVS，我还没有写完，^_^）

这里强调一点，并不是绝对地说，qbr 就一定是 Linux Bridge，br-int 就一定是 OVS，您也可以用自己的实现方式来替换他们，只不过，这样的实现方式，是当前 OpenStack 解决方案的经典方式而已。在没有更好地实现方式之前，这个也可以说是唯一的实现方式。

qbr 这个缩写比较有意思，它是 Quantum Bridge 的缩写，而 OpenStack 网络组件的前一个商标名就是Quantum，只不过由于版权的原因，才改为 Neutron。从这个称呼我们也能看到 Neutron 里面 Quantum 的影子。

br-int，表示的是 Integration Bridge， 综合网桥。到底“综合”了哪些内容，我们这里先不纠结，我们就当作它是一个普通的 bridge，不过实现载体是 OVS 而已。

这里面有个问题：为什么需要两层 bridge？VM 先接 qbr（Linux Bridge），qbr 再接 br-int（OVS），为什么不是 VM 直接接入 br-int？这个原因是：

（1）如果只有一个 qbr，由于 qbr 仅仅是一个 Linux Bridge，它的功能不能满足实际场景的需求（具体哪些场景，我们在后面涉及到时会点到）。毕竟，br-int 的名号，不是瞎取的，^_^

（2）如果只有一个 br-int，由于 br-int 实际是一个 OVS，而 OVS 比较任性，它到现在竟然还不支持基于 iptables 规则的安全组功能，而 OpenStack 偏偏是要基 iptables 规则来实现安全组功能！

所以，OpenStack 引入 qbr，其目的主要就是辅助 iptables 来实现 security group功能（qbr 有时候也被称为安全网桥）;引入 br-int，才是真正为了实现一个综合网桥的功能。

4.2.2.1.3 br-ethx

br-ethx 也是一个 bridge，也是一个 OVS，它的含义是：Bridge, Ethernet, External。顾名思义，br-ethx 负责与“外”部通信，这里的“外”部指的是 Host 外部，但是属于一个 Network（这个 Network 指的是 Neutron 的概念）的内部，对于本小节而已，指的是 VLAN 内部。这非常关键，后面我们还会涉及到“外”部另外的概念。

值得注意的是，br-ethx 上的接口（图中是“G”），是一个真正的 Host 的网卡接口（NIC Interface， Interface in Network Interface Card）。网卡接口，是网卡物理口上的一个 Interface。确实也应该这样，不然，网络流量如何才能进出一个 Host 呢？

4.2.2.1.4 VLAN 转换

我们在“VM 及 VLANID”那一小节中，讲述了 VLANID 有内外之别，这里我们讲述一下这个内外 VLANID 的转换。如下图所示：

图９ 内外 VLANID 的转换

上图是 Neutron 的标准实现：对于进入的流，br-int 负责将外部 VLANID 转换为内部 VLANID；对于外出的流，br-ethx 负责将内部 VLANID 转换为外部 VLANID。

是 Neutron 确实就是这么实现的，还是我搞错了，我还会继续求证。现在假设 Neutron 就是这么实现的，那么笔者以为：Neutron 这样的实现，是有问题的。

笔者以为，正确的实现方式，应该如下图所示：

图１０ 笔者以为正确的内外 VLANID 转换方式

无论是进入的流还是外出的流，内外 VLANID 的转换，都应该是在 br-ethx 完成。至于为什么，笔者会在下文讲述。

【上次写到这里】

4.2.3 VXLAN 实现模型

我们直接上图：

图１1 VXLAN 实现模型

实现模型，VXLAN 与 VLAN 相比，从表面上来看，仅仅一个差别：VLAN 中对应的 br-ethx，换成 VXLAN 中的 br-tun。（br-tun，是一个混合单词的缩写：bridge, tunnel。此时这个 tunnel 是 VXLAN Tunnel。）

其实，br-ethx 是一个 OVS，br-tun 也是一个 OVS。所以说，两者的差别，还不是实现组件的差别，而是组件所执行的功能的差别。

VLAN 中的 br-ethx，所执行的功能是：VLAN 标签的转换（请参见上一小节）及报文的输入输出。

VXLAN 中的 br-tun，所承担的就是我们在 VXLAN 章节中所描述的 VTEP 的功能。我们重新贴一下 VXLAN 章节的那个关于 VTEP 的图：

图1２ VXLAN VTEP 功能示意图

图中的 L3 Network，也可以简化为一个 TOR 交换机，比如我们在 VXLAN 实现模型那张图中，两个 br-tun 所对应的接口 IP 分为：10.0.100.88 和 10.0.100.77，两者属于同一个网段，中间只须一个 TOR 交换机即可，不需要一个复杂的 L3 Network。

需要强调的是，br-tun 的那个接口（图中对应的是 G, H），与 VLAN 实现模型中的接口是一样的，是一个真正的 Host 的网卡接口（NIC Interface， Interface in Network Interface Card）。

4.2.3.1 VNI 与内部 VLANID 的转换

与 VLAN 网络类比，VXLAN 网络同样存在一个 VNI 与内部 VLANID 转换的过程。对于租户而言，他所看到的网络可能是 VNI 等于 100 的 VXLAN 网络，而对于一个 Host 内部而言，各个 VM 仍然是属于不同的 VLAN 网络即可，如下图所示：

图1３ VXLAN 网络的两个视角

图中，上半部分是 Host 内部视角，下半部分是租户视角。VNI 与内部 VLANID 的对应关系如下表所示：

租户视角 VNI	Host1 视角 VLANID （内部 VLAN）	Host2 视角 VLANID （内部 VLAN）
100	10	30
200	20	40

表1 VNI 与内部 VLANID 的对应关系

执行这个转换，当然也包括 VXLAN 封装及解封装功能的是 br-tun，如下图所示：

图1４ VXLAN 的封装与解封装及 VNI/VLANID 的转换

4.2.4 GRE 实现模型

GRE 的实现模型，与 VXLAN 的实现模型，一模一样，如下图所示：

 图1５ GRE 实现模型

所不同的是，VXLAN 的 br-tun 构建的是 VXLAN Tunnel，而 GRE 的 br-tun 构建的是 GRE Tunnel。

GRE 网络，虽然不象 VLAN、VXLAN 网络那样，对于租户有一个可见的网络 ID（VLANID/VNI），但是它内部的实现，仍然是有一个 Tunnel ID，这样就一样是存在这样的转换：内部 VLANID 与 Tunnel ID 之间的转换。这个转换，与前面小节介绍的内外 VLANID 转换，VNI/VLANID 转换等，原理一样，这里就不啰嗦了。

4.2.5 计算节点的实现模型

通过前面的介绍，我想，我们可以总结出计算节点的实现模型了，如下图所示：

图1６ 计算节点实现模型

如果我们把 VM 也算在内的话，计算节点一共分为三层：

l Tenant Network Layer：我相信很多人，对于 Tenant Network 这个词汇并不陌生。如果您暂时还不了解这个词汇也没关系，租户网络，就是我们前面章节说的（外部）VLAN 网络，VXLAN 网络，GRE 网络。对于这一层，其对应的组件是 OVS，这个 OVS 的功能是将租户网络与本地网络（Local Network）进行相互转换，比如我们前面介绍的：内外 VLANID 转换，VXLAN 封装与解封装及 VNI/VLANID 的转换，GRE 的封装与解封装及 Tunnel ID/VLANID 的转换。Tenant Network Layer 是对 Local Network Layer 的一个屏蔽，即不管 Tenant Network 采用什么技术（比如 VXLAN，GRE 等等），Local Network 永远感知的仅仅是一个技术：VLAN，一种网络 ID：Local Network ID（即前面章节里所描述的内部 VLANID）

l Local Network Layer：

ü 由于 Tenant Network Layer 对这一层的屏蔽，Local Network Layer 就非常简单，仅仅是构建一个内部 VLAN 即可。同一个 Host 内的 VM，如果属于同一个 Tenant Network，那么在 Local Network 里，也属于同一个 VLAN。（当然，如果不属于同一个 Tenant Network，那么在 Local Network 里就不能属于同一个 VLAN。）

ü Local Network Layer 再分为两层。根据前面介绍，我们知道，qbr 仅仅是负责安全，所以我们称之为 Security Layer。而 br-int 则负责交换，所以我们称之为 bridge Layer。

l VM Layer：这个不用多解释，就是一坨虚拟机！

通过这个模型，我们再回忆一下，VLAN 网络那一小节中内外 VLANID 的转换，笔者认为 Neutron 的实现不合理，不知道您赞同笔者的观点吗？

最后强调一下，位于同一个 Host 的 Tenant Network 中的不同 VM，这些 VM 之间的通信，经过 Local Network Layer（即经过 br-int）即可完成，不需要再往外走到 Tenant Network Layer，如下图所示：

图1７ 同一 Host 内的同一 Tenant Network VM 之间的通信

VM1-1 与 VM1-3，在同一个 Host 内，同时也属于同一个 Tenant Network，那么它们之间的通信，只须经过 br-int 转发即可。

4.3 网络节点的实现模型

4.3.1 一个场景：VM 访问 Internet

我们看这样一个场景，如下图所示：

图1８ 一个 VM 访问 Internet

图中，一个虚拟机，VM1-1 期望访问 www.onap.org，我们看到，它必须要能到达数据中心（DC）的网关（GW，Gateway），才能访问 www.onap.org。

（做个广告：Linux 基金会旗下两大开源 MANO 工作组 OPEN-O 和 ECOMP 日前宣布正式合并为一个组织——开放网络自动化平台（ONAP，Open Network Automation Platform）。笔者以前在 OPEN-O 里工作，现在也自动在 ONAP 里工作）

那么，VM1-1 如何才能到达 GW 呢？我们不绕弯子，直接上图：

图1９ VM 访问 Internet 的组网

这里面涉及到了网络节点，我们暂时不看网络节点里面的内容，先当作一个 Host，当作一个黑盒看待，同样，计算节点我们也当作一个黑盒看待。

Neutron 是这样假设这个组网模型的：

（1）所有计算节点（里面的 VM），要访问 Internet，必须先经过网络节点，网络节点作为第一层网关。

（2）网络节点会连接到 DC 物理网络中的一个设备（或者是交换机，或者是路由器），通过这个设备再到达 DC 的网关。我们把这个设备称为第二层网关。当然，网络节点也可以直接对接 DC 网关，这时候，就没有第二层网关。

（3）DC 网关再连接到 Internet 上。

不过呢，上述第“2”点和第“3”点，对于 Neutron 来说，其实是一个浮云。因为对于 Neutron 来说，上图中的 GW2，DC External Network，GW3，都是不必管理的，那是 DC 运营商提前规划好的网络。所以，这些对于 Neutron 而言统统都称为“External Network”，或者“Public Network”（Neutron 创建的租户网络，称为“私有网络”）。

因此，对于 Neutron 而言，VM 访问 External Network（Public Network）的组网模型如下图所示：

图2０ VM 访问 External Network Model

这个图，把网络节点的细节进行了展开，我们会在下一小节讲述，这里暂时不必深究。可能您会问：计算节点访问 External Network，为什么要经过网络节点，直接从计算节点出去不可以吗？我们讲：（1）这是 Neutron 当前的设计，这个设计有一定的道理；（2）这个设计不是最优的，但是暂时还没有更好的方案。

下面我们就来讲述网络节点的模型，同时理解 Neutron 这么设计的合理性。

4.3.2 网络节点的实现模型

我们直接上图：

图2１ 网络节点模型

网络节点分为四层，前两层“Tenant Network Layer”与“Local Network Layer”与计算几点对应的两层，一模一样，笔者在这里就不再啰嗦。这里我们也再次看到了 Neutron 实现模型的思想：Tenant Network Layer 对租户网络的实现技术进行屏蔽，Local Network Layer 在一个 Host 内部完成普通的二层 VLAN 交换和租户隔离（租户隔离体现在计算节点）。

对于计算节点而言，有了上述两层，网络功能就完成了，剩下的就是虚拟机了，而对于网络节点呢，也是可以类比，剩下的就是网络服务了。

4.3.2.1 Network Service Layer

Network Service Layer 的典型服务就是 DHCP Service 和 Router Service。

4.3.2.1.1 DHCP Service

图中画的是“DHCP”，严格来说，应该称为“DHCP Service”。什么叫 DHCP，笔者在这里就不啰嗦了。这里只强调几点：

（1）Neutron 的 DHCP Service，采用的是 dnsmasq 进程（轻量级服务进程，可以提供 dns、dhcp、tftp 等服务）

（2）一个子网（subnet）一个 DHCP Service

（3）由于存在多个 DHCP Service（多个 dnsmasq 进程），Neutron 采用的是 namespace 方法来隔离，即一个 DHCP Service 运行在一个 namespace 中。

4.3.2.1.2 Router Service

这个是 VM 访问 External Network 的关键。我们知道，Router Service 就是做路由转发，这个大家都很熟悉，笔者就不啰嗦了。

Neutron 实现 Router 功能，采取的是 iptables 方法。iptables 笔者在以前的章节讲过，这里就不再啰嗦，只是贴一个图，给大家一个直观感受：

图2２ iptables 实现原理

为了达到租户隔离的目的，一个租户至少需要一个 Router，这样在网络节点中，就会存在多个 Router。为了实现这些 Router 之间的隔离，Neutron 的实现方法是：每一个 Router 运行在一个 namespace 中。

有两个问题，我们需要澄清：

（1）VM 一般来说是私网 IP，它要访问 External Network，而 External Network 一般来说是公网 IP，那么这两者之间的通信，就要求 VM 需要做一个 NAT 转换，把私网 IP 转为公网 IP，这个 NAT 在哪里做？

Neutron 把这个 NAT 的功能，可以放在 Router 里做，也可以放在 br-ex 来做。

（2）假设 NAT 放在 Router里实现，那么，Router 直接绑定物理接口，出到 External 即可，为什么还需要连接到 br-ex，通过 br-ex 再出到 External Network？

我们讲，Router 是多个，而网络节点（Host）的物理接口是有限的，甚至只有一个。为了方便讲述，我们假设网络节点的物理接口只有一个，这样就会存在下面的场景：

图2３ 一个物理接口绑定到多个 Router

一个物理接口绑定到多个 Router 是不可以的！！！

所以，这个时候，br-ex，从某种意义上来说，起到的就是 Hub 的作用，如下图所示：

图2４ br-ex 起到的是 Hub 的作用

当然，说起到 Hub 的作用，只是一个比喻而已，br-ex 可是一个地地道道的 bridge！

4.3.2.2 External Network Layer

External Network Layer 中的组件就是 br-ex。br-ex，就是 bridge/external 的意思，它也是一个 OVS。

br-ex 的功能，前面已经介绍过，有两个：

（1）将各个 Router 桥接到 Host 的物理网口上

（2）承担 NAT 的功能，如果 Router 没有做 NAT 的话

4.4 控制节点的实现模型

我们直接上图：

图2５ 控制节点模型

上图中，不仅画出了控制节点，还画出了计算节点和网络节点，是想表明，Neutron 的所谓控制功能，不仅仅是体现在一个控制节点，在计算节点和网络节点中，还有各种各样的 Agent。控制节点中，仅仅是 Neutron 的各种服务。

本章节，我们不展开这些服务及 Agent，这些我们会放到另外的章节讲述，这里只须有个直观的认识即可。

这里想强调几点：

（1）控制节点，我们如果抛开里面的内容的话，抽象地看，就可以看作一个普通的 Web Server。所以我在图中，除了画出 OpenStack 的各种服务（Neutron，MySQL　等），还画了一个虚框。这个虚框里的内容，没有定论，取决于你的设计，比如可以放置一个　nginx service 等等。

（２）控制节点、计算节点、控制节点，这些节点本身，都是有管理接口（IP） 的。所以，控制节点中的各个 Service 与计算节点/网络节点中的 Agent 通信，就是通过管理接口进行互联的。

（3）控制节点对外提供 REST API 接口，CLI 接口，以及 GUI 接口（Dashboard ）,这些也是通过管理接口向外提供。

（4）这些管理接口，以及管理接口之间的互联网络（图中仅仅以一根线表示），管理接口与管理终端之间的互联网络，统统不是 Neutron 所关心的范围，这些需要人工提前配置好。

4.5 不考虑 DVR 的 Neutron 实现模型

DVR，Distributed Visual Router，分布式路由器。这里我们先忘记这个概念（我们会在下一小节讲述）。DVR 会对前面讲述的网络节点和结算节点，有一定的改变。在不考虑 DVR 的情况下，Neutron 实现模型如下图所示：

图2６ Neutron 实现模型（不考虑 DVR）

图中，除了画出了三个节点，还画出了相关的物理网络：DC Physical Network 和 Internet。这些我们统统称之为 External Network。

各个节点所连接的物理交换机，我们稍微抽象一点，就不称之为 TOR 了，直接称为 SW（交换机，Switcher）。

图中没有画出控制节点/计算节点内部各组件之间的接口（TAP，Veth Pair 等等），仅仅是画出了各节点的物理接口。

我们把图中的 External 那些图标去掉，以一个稍微抽象的方式描述，如下图所示：

图2７ Neutron 实现模型2（不考虑 DVR）

图中的四个网络（Manage Network，Data Network，External Network，API Network），仅仅是指物理网口及相应的连线。实际上我们知道，这些网络，还包括节点中的各个相关组件及接口。因为这并不是什么严格的名词定义，所以笔者这样描述，是期望能方便您记忆和理解：先抓住粗粒度的概念，再细究内部元素。

Manage Network 与 API Network，我们在“控制节点实现模型”那一小节有过描述（而且也不是重点），这里就不啰嗦了。

Data Network，指的是数据节点之间的数据通信或者数据节点与网络节点之间的通信。

而 External Network，从 Neutron 视角而言，仅仅是一个物理接口，这个接口所连接的就是一个外部网络。这跟人生是一样的，外面的世界，对你来说，就是意味着一扇门。门开了，外面的世界就扑面而来；门关了，外面的世界也就消失了。

这一小节，我描述的比较简单，真正的内容，需要结合前面几个小节一起掌握。

4.6 具备 DVR特性的 Neutron的实现模型

DVR，Distributed Visual Router，分布式路由器，是 OpenStack Juno 版本引入的特性。在讲述 DVR 之前，我们先看看在没有 DVR 的情形下，Neutron 网络的流量走向情况。

（1）计算节点之间的二层通信

图2８ 计算节点之间的二层通信

计算节点之间的二层通信，不需要经过网络节点，这个不会产生性能瓶颈。

（2）计算节点访问 External Network

图2９ 计算节点访问 External Network

我们看到，所有的计算节点访问 External Network，都需要经过 Network Node，这个时候，Network Node 就成为了瓶颈点。

（3）计算节点之间的三层通信

图3０ 计算节点之间的三层通信

计算节点之间的三层通信的场景有：同一租户下不同 subnet 的 VM 之间的通信。图中红色虚线画的是逻辑链路，实际两个 VM 还是要经过 Network Node 中的 Router 进行转发。这个时候，Network Node 仍然是成为了瓶颈点。

为了解决这个问题，Neutron 引入了 DVR。关于 DVR 本身的原理，这个跟其他概念（VPN，OVS，TAP/TUN，iptables 等等）是一样的，我们会放在专门的章节中讲述，这里只需要如此简单理解：

（1）就简单理解为一个 router，有路由转发功能，也有 NAT 功能等。

（2）每一个计算节点都可以启用 多个 DVR（简单理解为 router），每个 DVR 运行在一个 namespace 中。

我们在本章节，重点讲述，在计算节点部署了 DVR 的情况下，网络的流量走向情况。

4.6.1 几个概念的澄清

4.6.1.1 SNAT，DNAT

SNAT, DNAT，我们在 iptables 那一章中讲述过，这里简单重复一下：

SNAT 是 Source NAT 的缩写，源 NAT（源地址转换） 的意思；DNAT 是 Destination NAT 的缩写，目的 NAT（目的地址转换） 的意思。

要区分这两个功能可以简单的由连接发起者是谁来区分：

l 内部地址要访问公网上的服务时（如web访问），内部地址会主动发起连接，由路由器或者防火墙上的网关对内部地址做个地址转换，将内部地址的私有IP转换为公网的公有IP，网关的这个地址转换称为SNAT，主要用于内部共享IP访问外部。

l 当内部需要提供对外服务时（如对外发布web网站），外部地址发起主动连接，由路由器或者防火墙上的网关接收这个连接，然后将连接转换到内部，此过程是由带有公网IP的网关替代内部服务来接收外部的连接，然后在内部做地址转换，此转换称为DNAT，主要用于内部服务对外发布。

下面我们举个例子，再讲述一下 SNAT 和 DNAT。

先看看 SNAT，如下图所示：

图3１ SNAT 举例图

图中，VM 本身是一个私网 IP，它要访问一个公网 IP（www.onap.org），显然，一个私网 IP 和一个公网 IP 是无法通信的。这个时候，SNAT 会先将 VM 的私网 IP 转换为一个公网IP（图中的“公网 IP1”），然后再将报文转发出去（SNAT 同时承担路由的功能），这样，双方才能通信。

再看看DNAT，如下图所示：

图3２ DNAT 举例图

服务器如果部署在云里，它仍然是一个私网 IP，只是它对外发布时，体现为一个公网 IP 而已。外部 Client 如果要访问这个服务器，他会访问那个服务对外发布的公网 IP。这个时候，如果要能做到正确访问，DNAT 必须把这个对外发布的公网 IP（图中为“公网 IP1”）转换为私网 IP。

（自恋一下，图中那个小伙，我一直以为跟我年轻的时候很象。那个显示器所代表的年代也很相符，^_^）

这个时候，不知道您是否有疑问，无论是 SNAT 还是 DNAT，它其实都要做两件事情：把私网 IP 转换为公网 IP + 把公网 IP 转换为私网 IP，如下图所示：

图3３ SNAT/DNAT 都是做私网/公网 IP 的转换

既然 SNAT 与 DNAT 做的事情都是一样，还这样定义两个概念，是否有必要。个人觉得必要性不大，除了显得好像有学问的样子（装逼），没啥意义。

不过呢，SNAT 与 DNAT 在实际应用中，还是有点区别。

一般来说，SNAT 的私网 IP 数量远大于公网 IP 数量。比如 VM 有 100 个，分配了 100 个私网 IP，但是这 100 个虚拟机并不是同时都需要访问 Internet，所以给他们分配 10 个公网 IP 做 SNAT 应该就够用了。

而 DNAT，如果我们不叠加负载均衡模块（系统），那么它所对应的私网 IP 与公网 IP 之比，一般来说，是 1 : 1。

如下图所示：

图3４ SNAT vs. DNAT

4.6.1.2 Floating IP

在 Neutron 的定义里，Floating IP 就是 DNAT，而且，私网 IP 数量 ：公网 IP 数量 = 1 ： 1。

4.6.1.3 东西流量 & 南北流量

不同的语境，关于东西流量和南北流量还是稍有差异，不过基本差不多。在 Neutron 的世界里：东西流量指的是同一个租户下不同 subnet 的 VM 之间的通信流量；南北流量指的是 VM 与 External 之间的通信流量。如下图所示：

图3５ 东西南北流量示意图

我们看到，并没有把不同 VM 之间的二层通信算作东西流量，这没有关系，这只是不同语境下的一个定义而已。（在另外的语境下，VM 之间的二层通信，也可以算作东西流量）

4.6.2 东西南北流量的走向

4.6.2.1 不同 Host 的东西流量走向

我们直接上图：

图3６ 不同 Host 的东西流量走向

图中，红色曲线表达的是从 VM1 到达 VM2 的流量走向。如果 VM2 访问 VM1，则经过 Router2 再返回。

图中的 Router1 和 Router2，实际上就是 DVR，不是传统的路由器。不过关于 DVR 的原理，我们需要放到另外的章节讲述，这里就当作一个普通的 Router 理解流量走向，也问题不大。

4.6.2.2 同一 Host 的东西流量走向

直接上图：

图3７ 同一 Host 东西流量走向

同一 Host 东西流量走向，不需要再往 br-ethx/br-tun 组件里面走。图中的 Router1 仍然是 DVR。

4.6.2.3 DNAT 南北流量走向

直接上图：

图3８ DNAT 南北流量走向

图中的 Router1 是 DVR。在图中，笔者把路由功能和 DNAT 功能，画在了一起，有人是分开画，这没有关系，都可以。

4.6.2.4 SNAT 南北向流量走向

直接上图：

图3９ SNAT 南北向流量走向

很熟悉？是的，SNAT 南北向流量，没有从计算节点直接出去，还是经过了网络节点。不要问为什么，Neutron 当前就是这么实现的。不排除，将来 Neutron 会改变这个实现，只需要从计算节点直接出去，不必经过网络节点。

此时，网络节点中的 Router 是不是 DVR，对不起，笔者正在求证中......

4.6.2.5 流量走向小结

直接上表：

场景	流量走向	备注
同一计算节点之间 VM 之间二层流量	计算节点内 br-int 转发	二层通信
不同计算节点之间 VM 之间二层流量	计算节点之间通信，经过 br-ethx/br-tun	二层通信
同一计算节点之间东西流量	计算节点之内通信，通过 br-int，DVR	三层通信
不同计算节点之间东西流量	计算节点之间通信，经过 br-ethx/br-tun，通过 DVR	三层通信
DNAT 南北向流量	计算节点直接与 External Network 通信，通过 DVR，br-ex	三层通信
DNAT 南北向流量	计算节点经过网络节点，与 External Network 通信	三层通信
DHCP	计算节点与网络节点之间通信	DHCP 还是部署在网络节点上

表2 具备 DVR 特性的流量走向小节

4.6.3 具备 DVR 特性的 Neutron 的实现模型

直接上图：

图4０ 具备 DVR 特性的 Neutron 实现模型

由于前面已经做了很多讲述，这个图就不解释了。