Neutron/DynamicRouting/UseCases
目录
Neutron 动态路由用例
这是尝试列出 Neutron 中动态路由用例的一个简短尝试。然后我们将尝试找出用例之间的共同点，以了解可以在通用框架中进行抽象和共享代码的位置。
多归属 Openstack 云
一个多归属的 Openstack 云将针对每个上行链路网络提供商中的至少一个路由器运行路由协议（例如 BGP）。通过向这些对等体通告浮动 IP 前缀，Neutron 网络可以通过两条路径被互联网的其余部分访问。如果到上行链路提供商的链路中断，故障信息将传播到上游路由器，通过剩余的健康链路保持云的可访问性。同样，在这种情况下，Neutron 的 L3 路由器将从其转发表中删除通过故障链路学习到的路由，将所有云发起的流量通过健康链路重定向。
外部网络上的浮动 IP 的路由模型
此用例将允许具有大型公共 IP 空间的外部网络跨越多个 L2 网络。这可以提高可用区之间的规模和隔离性，同时保持大型外部网络的外观，在其中浮动 IP 和网络可以自由浮动。
此用例消除了为每个路由器分配来自浮动 IP 池的永久 IP 的一个原因。路由器将在私有路由网络上分配一个 IP 地址。仍然有一些原因需要分配这样的永久公共 IP。默认 SNAT、DNS 转发和代理元数据请求是其他原因。其中一些可以修改为也使用私有网络，但这超出了此用例的范围。
在 DVR 的情况下，此模型消除了为每个计算节点分配来自浮动 IP 池的公共 IP 的需要。
此用例还可能包括将 Neutron 路由器后面的公共网络通告给上游路由器。它不需要从上游路由器学习路由。
MPLS/BGP
注意：本节基于我对蓝图的理解。我希望得到反馈，以确保我理解正确。
此用例在其自身的 蓝图中描述。从蓝图中：“此 BP 实现了部分 RFC4364 BGP/MPLS IP 虚拟专用网络 (VPN) 支持，用于互连现有网络和 OpenStack 云。”
这在 Icehouse 会议上简要讨论过，作为 VPNaaS 的一部分。可以认为此用例是 VPNaaS 的一部分，而不是动态路由。
VPNaaS 目前对 IPSec 和 TLS 具有实验性实现。VPN 端点被插入到 neutron 路由器中。我假设此 VPNaaS 的实现将遵循相同的模型。
场景 1：Neutron 路由器是 CE
遵循其他 VPNaaS 实现的模式，neutron 路由器将扮演 CE 的角色。将建立到 PE 的 BGP 对等体，并且如 RFC 的第 4.3.1 节的最后一段所述，route_target / import_target / export_target 在 PE 之间进行交换。
这种类型的 VPN 不采用强大的端点身份验证或加密来确保网络的隐私。相反，它依赖于提供商和客户之间的已建立的关系，以及对两者之间连接在物理上是安全的保证。这对于将此引入云中，其中云提供商是不同于提供商和客户的第三方，具有一些影响。
例如，考虑将许多 neutron 路由器连接到同一外部网络的情况。现在，我们连接一个 PE 到该网络，目的是在充当 CE 的 neutron 路由器之一与 PE 之间建立 MPLS/BPG 链路。在这种情况下，提供商将如何安全地确定客户流量的适当 VRF？
如果我是客户，我会非常担心将此共享外部网络用作我的虚拟专用网络的“连接电路”。我会坚持使用仅我的租户可访问的私有外部网络。这是此 VPNaaS 实现的一个额外约束，其他实现没有此约束。它已经需要 Openstack 之外的一些配置，这降低了在 Openstack 内部实现所有这些的价值。
这种类型的 VPN 可能仅限于提供商网络，这些网络是租户私有的。这意味着需要允许路由器 将网关连接到提供商网络。
场景 2：虚拟机是 CE
此场景不遵循其他 VPNaaS 实现的模式。在此场景中，CE 是虚拟机本身，并且 PE 连接到相同的提供商网络。Neutron 系统与 PE 建立单个 BGP 连接，并将路由发布到网络上的所有已知 Neutron 端口。
