前言
本文从整体上介绍 Neutron 的部署架构、网络实现模型、上层资源模型、底层技术支撑、设计意图以及实践案例。目的是从鸟瞰的视角掌握 Neutron 的全局。本文参考和引用了大量的文献与书籍，尤其是《深入理解 OpenStack Neutron》一书，于文末附有链接，感谢知识的分享（传播）者们。
传统网络到虚拟化网络的演进
传统网络：
虚拟网络：
分布式虚拟网络：
Neutron 简述
Neutron 是为 OpenStack 提供 Network Connectivity as s Service 的项目，当然 Neutron 也可以脱离 Keystone 体系作为一个独立的 SDN 中间件。
作为 OpenStack 组件：为 OpenStack 虚拟机、裸机、容器提供网络服务。
作为 SDN 中间件：北向提供统一抽象资源接口，南向对接异构 SDN 控制器。
Neutron 所追求的目标 —— 云计算时代的分布式虚拟化网络与多租户隔离私有的多平面网络。
从软件实现的角度来看，对 Neutron 熟悉的开发者不难察觉：Neutron 团队肯定首先设计好 Core API Models（核心资源模型）然后再往下实现的。这也是很多 OpenStack 项目的实现风格，值得我们学习。在设计软件架构时，不要急于撸代码，而是首先思考清楚 「XXX as a Service」中 Service 的含义，即 “什么是服务、为谁服务、提供什么服务、如何提供”？Neutron 提供的网络即服务的精髓就在于租户只需关心服务，不必关心实现细节，而服务的内容就是资源类型（API）的定义。只有稳定、兼容、平滑过渡的 API 才能引发 APIs 经济（围绕开放式 API 的生态圈），让软件得以在残酷的开源市场中存活下来。
而且 Neutron 的设计初衷是纯粹的 “软件定义”，无需设计新的硬件，而是对现有硬件的协同，这是一个务实的设计思想，通过 Plugin-Driver 的方式来调用底层物理/虚拟网元功能，为上层服务提供支撑。这一特点使 Neutron 得以在业界收到广泛的关注。
Neutron 的网络实现模型
在了解 Neutron 网络实现模型的过程中，我们主要弄明白三个问题：
- Neutron 是怎么支持多类型网络的（e.g. VLAN、VxLAN）？
- 同一个租户网络内的跨计算节点虚拟机之间是怎么通信的？
- 虚拟机是怎么访问外网的？
Neutron 的网络实现模型概览：
计算节点网络实现模型
介绍计算机节点上的虚拟机流量是如何被送出计算节点的，并在过程中插入介绍相关的虚拟网络设备于工作机理。
Step 1. 流量经由虚拟机内核 TCP/IP Stack 交给虚拟网卡 vNIC 处理，vNIC 是一个 Tap 设备，它允许用户态程序（这里指 GuestOS，一个 qemu 进程）向内核 TCP/IP 协议栈注入数据。Tap 设备可以运行在 GuestOS 上，提供与物理 NIC 完全相同的功能。
Step 2. 虚拟机的 vNIC（Tap 设备）没有直连到 OvS Bridge 上，而是通过 Linux Bridge 中继到 OvS br-int（Integrated bridge，综合网桥）。为什么 vNIC 不直连 br-int？这是因为 OvS 在 v2.5 以前只有静态防火墙规则，并不支持有状态的防火墙规则。这些规则是 Neutron Security Group 的底层支撑，为虚拟机提供针对端口（vNIC）级别的安全防护，所以引入了 Linux Bridge 作为安全层，应用 iptables 对有状态的数据包进行过滤。其中 Linux Bridge qbr 是 quantum bridge 的缩写。
Step 3. Linux Bridge 与 OvS Bridge 之间通过 veth pair （虚拟网线）设备连接，“网线” 的一端命名为 qvb（quantum veth bridge）另一端命名为 qvo（quantum veth ovs）。veth pair 设备总是成对存在的，用于连接两个虚拟网络设备，模拟虚拟设备间的数据收发。veth pair 设备的工作原理是反转通讯数据的方向，需要发送的数据会被转换成需要收到的数据重新送入内核 TCP/IP 协议栈进行处理，最终重定向到目标设备（“网线” 的另一端）。
Step 4. OvS br-int 是一个综合网桥，作为计算节点本地（Local）虚拟交换设备，完成虚拟机流量在本地的处理 —— Tenant flows are separated by internally assigned VLAN ID.（Tenant 网络的 Local VLAN ID 由 内部分配）虚拟机发出的流量在 br-int 打上 Local VLAN tag，传输到虚拟机的流量在 br-int 被去掉 Local VLAN tag。本地虚拟机之间的 2 层流量直接在 br-int 转发，被同 VLAN tag 的端口接收。
Step 5. 从本地虚拟机传输到远端虚拟机（或网关）的流量由 OvS br-int 上的 int-br-eth1（ovs patch peer 设备）端口送到 OvS br-ethX 上。需要注意的是，br-ethX 并未是一成不变的：当网络类型为 Flat、VLAN 时，使用 br-ethX；当网络类型为 Tunnel（e.g. VxLAN、GRE）时，br-ethX 就会被 br-tun 替换。上图示例为 VLAN 网络。我们将 br-ethX、br-tun 统称为租户网络层网桥设备（TNB），以便于叙述。
NOTE：qbr-xxx 与 OvS br-int 之间使用 veth pair 设备相连，br-int 与 br-ethx/br-tun 之间使用 patch peer 设备相连。两种都是类似的虚拟 “网线”，区别在于前者是 Linux 虚拟网络设备，后者是 OvS 实现的虚拟网络设备。
NOTE：如果租户网桥是 br-tun 而不是 br-ethX，那么在 br-tun 上会有 port:patch-int，br-int 上会有 port:patch-tun，通过 patch-int 和 patch-tun 实现租户网桥 br-tun 和本地网桥 br-int 之间的通信。
Step 6. 当虚拟机流量流经 OvS br-int 与 OvS br-ethX 之间时，需要进行一个至关重要且非常复杂的动作 —— 内外 VID 转换。这是一种 “分层兼容” 的设计理念，让我想起了：所有计算机问题都可以通过引入一个中间层来解决。而 Neutron 面对的这个问题就是 —— 支持多种租户网络类型（Flat、VLAN、VxLAN、GRE）。
Step 7. 最后虚拟机流量通过挂载到 TNB（br-ethX/br-tun）上的物理网卡 ethX 发出到物理网络。OvS br-int 与 OvS br-ethX 之间也是通过 veth pair 设备实现。
Step 8. 虚拟机的流量进入到物理网络之后，剩下的就是传统网络的那一套了。网络包被交换机或其他桥接设备转发到其他计算、网络节点（PS：这取决于具体的部署网络拓扑，一般虚拟机流量只会被同处 Internal Network 的计算节点）接收到。