NFV 的 VLAN trunking 网络¶
https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks
问题描述¶
许多常用的 Neutron 插件配置创建的网络不允许 VLAN 标记流量通过网络。这包括使用 OVS 驱动程序或 VLAN 驱动程序时的 ML2。相反，有些插件可以很好地传递所有形式的以太网帧。无法通过 API 确定正在使用哪种配置，也无法指示插件需要哪种类型的网络。
VLAN 对于许多 NFV 功能是必需的。本规范建议提供一种请求 VLAN 透明网络的方法——即，VLAN 标记流量将被转发到其他主机——在请求时，并确认网络实际上是 trunk 网络。
NFV 虚拟机的一个常见要求是通过许多单独的 L2 通道进行通信。通道数量远远超过虚拟机拥有的端口数量，并且可以随时间变化。VLAN 标签通常用于分隔这些通道，以便在保持端口数量静态的同时，仍然允许通道数量的灵活性。
在 Neutron 中，不同的网络插件创建具有不同属性的网络，并且没有“网络”一词的具体定义。大多数情况下，但并非总是如此，网络是具有学习交换行为的 L2 广播域，尽管只要反欺骗过滤器到位，网络就可以实现为 L2 或 L3 域。通常，只要网络满足 IPv4 和 IPv6 单播流量、ARP 和 ND 正常工作的最低要求，就不会有人批评插件。VLAN 透明性并非此当前最低要求的一部分，并且有些插件由于疏忽或设计原因，不允许 VLAN 数据包流动。无法通过 API 控制此行为或检测到它，本提案旨在改变这一点。
(其他蓝图提出了将 trunk 分解为单个 VLAN 的网络解决方案、trunk 网络的地址管理等。这不尝试解决除了网络的简单 L2 属性之外的任何问题。本规范解决了与 Openstack 管理端口不同的用例——具体来说，是两个 VLAN 感知虚拟机希望通过多个 VLAN 进行通信的情况，这些 VLAN 可能随时间变化，并且无需在每个阶段告知 Openstack 使用哪些 VLAN 和地址。）
提议的变更¶
本提案建议实施一种请求-发现机制，以便
现有的能够传递 VLAN 标记流量的插件可以识别自己
现有的无法传递 VLAN 标记流量的插件也可以识别自己
可以识别尚未适应报告其行为的旧插件
未来的插件可以具有选择性行为，网络可能或可能不传递 VLAN 流量，具体取决于用户请求——这允许插件在不需要该功能时做出有利于效率的决策（例如使用 L3 域）。
此外，端口防火墙行为——当前未为 VLAN 标记数据包定义——将被定义为一致地应用于数据包的最外层封装。也就是说，详细说明匹配 IP 端口的反欺骗和安全组将应用于具有 IP 以太网类型的包，但不会应用于包含 IP 以太网类型的 VLAN 以太网类型的包。这是因为 VLAN 极不可能具有与 VM 在同一 vNIC 上的未标记接口相同的地址并提供相同的服务，因此使用相同的过滤几乎肯定会使 VLAN 标记对于实际用途毫无用处。
请求¶
在 net-create 期间，用户可以选择请求创建一个 VLAN 透明 trunk 网络，方法是在 net-create 请求中传递一个“vlan-transparent”布尔属性，将其设置为“true”。（将属性设置为“false”等效于在下面的描述中不指定该属性。）
尚未适应以理解该属性的插件将忽略此标志并无论如何创建网络。
了解该属性的含义但无法理解该标志，或无法提供 VLAN 透明 trunk 网络的插件将拒绝创建网络并向用户返回适当的错误。
了解此标志并能够提供 VLAN 透明网络的插件将这样做。
插件可以根据此标志更改行为
如果设置了该标志，它们可以创建一个 VLAN 透明网络（可能以更高的资源成本），并且在未设置该标志时节省资源
它们可能拒绝将某些类型的端口附加到网络（例如，某些外部附加端口本身可能不是 VLAN 透明的，因此不应附加到透明网络）
插件也可能仅实现一种类型的网络，即透明或不透明，并在请求控制器无法实现的网络时拒绝创建网络。
如果缺少该标志，则了解的插件没有义务提供 VLAN 透明网络（并且未知的插件自然会忽略其缺失）；返回的网络可能或可能不透明。
请注意，该标志无法通过 net-update 更改。VLAN 透明性必须在创建时声明，并且在此之后无法更改，因为这可能会影响网络的放置甚至 VM 连接到的端点选择。
响应¶
网络创建后，网络可能具有一个属性“vlan-transparent”。
如果不存在此属性，则插件是旧插件，无法确定网络是否能够传递 VLAN 标记数据包。
如果属性存在并且标志设置为 true，则插件是 VLAN 感知插件，并且（无论请求如何）已创建能够传递 VLAN 标记数据包的网络。
如果属性存在并且标志设置为 false，则插件是 VLAN 感知插件，请求未传递“vlan-transparent”标志，并且出于自身原因，插件选择创建一个没有 VLAN 透明性的网络（通常是因为它正在提高效率或它根本无法做到）。
如“请求”中的描述，正确的响应可能是指示无法执行请求的错误。
防火墙¶
VLAN 标记将被视为不透明的封装。
VLAN 标记数据包将不会被安全组或其他基于端口的安全措施（例如反欺骗）进行防火墙保护，因为该数据包不是 IP 数据包。（对于能够传递 VLAN 标记数据包的驱动程序，这至少有时是行为的改变。）这是一个故意的选择：安全组通常会过滤它们理解的数据包并传递它们不理解的数据包，因此它是一致的（IP-in-MPLS 的行为将是这样的），并且 IP-in-VLAN 数据包极有可能具有与同一接口上的未标记地址不同的地址，并且彼此不同，因此 Openstack 端口安全将不会起到任何有用的作用。
这需要在 IPTables 防火墙驱动程序中进行验证，以确保这是当前看到的行为。
备选方案¶
存在一个基于端口的 VLAN 规范，允许将一组网络作为 VLAN trunk 提供给指定的端口。它解决了其他用例，并且不是直接替代方案。
数据模型影响¶
将“vlan-transparent”属性添加到网络，一个三态布尔值。
REST API 影响¶
在网络上
属性名称 |
类型 |
访问 |
默认值 |
验证/转换 |
|---|---|---|---|---|
vlan-transparent |
三态 |
在创建时写入，之后全部只读，全部 |
缺失 |
布尔值或缺失 |
安全影响¶
在当前通过 VLAN 的实现中，标记数据包的内容会被防火墙保护。这没有明确记录，但用户可能会合理地期望这种行为。
此更改建议将 VLAN 标签视为不透明的封装，因此 VLAN 标记数据包将不会被其内容进行防火墙保护。此外，安全组仅提供基于 IP 的防火墙，因此不可能阻止 VLAN 标记数据包。也就是说，可以预期来宾操作系统在未配置接收 VLAN 时会忽略标记数据包，因此不应产生任何影响。
这与对其他非 IP 数据包类型的行为保持一致。
通知影响¶
无
IPv6 影响¶
无
其他最终用户影响¶
python-neutronclient 应进行调整，以考虑 net-create 的新选项以及 net-show 中的新属性。
性能影响¶
可能会使某些插件更有效地使用网络资源。
其他部署者影响¶
无。
开发人员影响¶
无。
社区影响¶
无。
实现¶
负责人¶
ijw-ubuntu
工作项¶
实现新的 net-create 参数
实现新的网络属性，包括数据库迁移脚本
更改一些插件的采样，包括 ML2 插件，以实现属性的使用
在 ML2 驱动程序上实现一个新的属性，指示当驱动程序在使用中并可能负责网络的某个部分时，是否能够在该网络上传递 VLAN 数据包。驱动程序可以实现 true 或 false 设置，或者属性可以在旧驱动程序中缺失。如果任何驱动程序没有该属性或该属性设置为 false，ML2 将拒绝创建 VLAN 透明网络。
在核心驱动程序中，VLAN 和 OVS 驱动程序将被标记为不支持 VLAN 透明网络，而 LB、VXLAN 和 GRE 驱动程序将被标记为支持 VLAN 透明网络。其他驱动程序将具有旧行为。
其他插件将具有旧行为，直到更新，并且不需要对其进行任何更改。
这不是在更改任何驱动程序实现，而只是报告现有驱动程序的已知行为。因此，代理不受影响。
依赖项¶
无
测试¶
Tempest 测试¶
Tempest 应确认对于已知的良好网络设置，可以从 ML2 请求 VLAN 透明网络，并且它们可以工作。此类测试应理想情况下是主机到主机，以测试软件交换机和硬件配置。
API 测试¶
API 测试应确认属性在 net-create、net-update 和 net-show 上表现如描述的那样。
功能测试¶
功能测试应确认 ML2 正确批准和拒绝创建。
文档影响¶
用户文档¶
需要记录新的标志。
开发人员文档¶
需要记录插件和 MechanismDriver 行为以及支持 VLAN 透明网络的要求。
