RFC7814基于BGP/MPLS IP VRF的子网扩展解决方案

1引言

随着业务不断发现，虚拟机（VM）跨数据中心的迁移已经是越来越普遍的需求，而迁移中IP的变更则变得复杂且代价高昂。如果支持VM在IP不变的情况下从一个数据中心迁移到另一个数据中心，就需要VM所在的子网必须是跨数据中心的。

为了实现同一子网能跨数据中心部署，以下要求和挑战是必须考虑到的：

1. VPN实例空间规模：在现代化云数据中心环境中，一张基础网络上可能承载了成千上万的租户。无论安全还是性能上考虑，租户之间是必须隔离的。
2. 转发表规模：在虚拟化部署方式下，一个云数据中心通常有数以百万计的VMs。这个数量对数据中心交换机的转发表项是一个不小的挑战。提供多数据中心二层互联，挑战更严峻。
3. ARP/ND缓存表规模：ARP/ND缓存表通常是默认网关维护，ARP/ND缓存表的规模大小也会随数据中心互联增加而增加。
4. ARP/ND和未知单播泛洪：众所周知ARP/ND广播/组播和未知单播在大二层网络中泛洪可能会影响网络和主机性能。当多数据中心数以百万计的VMs以二层互联，这样的影响会变得更加严峻。所以跨数据中心如何避免 ARP/ND广播/组播和未知单播泛洪变得非常重要。
5. 路径优化：一个子网通常会代表一个物理位置。然而当子网跨越多个数据中心，这一点不在适用。如果当一个特定用户访问一个服务时，流量可能会转到其它数据中心，然后再转到目标服务所在的数据中心。这样的次优路径很明显会消耗带宽资源。在传统的VPLS网络中，数据中心互联，由于配置了VRRP，服务器的返程流量可能会转到一个不在本地数据中心的默认网关。这同样也消耗了带宽资源。

本文档主要描述基于BGP/MPLS IP VPN的子网扩展方案，称为“虚拟子网”，用于应对上述提到的要求和挑战。这里的BGP/MPLS IP VPN 包含IPv4和IPv6 。另外虚拟子网基于成熟技术构建，如：BGP/MPLS IP VPN 和 ARP/ND proxy 。作为一个基础设施（IaaS）云提供商，能够依托现有的BGP/MPLS IP VPN基础设施和运营经验解决数据中心互联。
虽然虚拟子网是一种数据中心互联的解决方案，但是也可以用在数据中心内部。

注意：本文档描述的方案不能完全实现二层互联，所以不能完全支持二层互联的业务模型。这点在第四节会提到。

2术语

参考RFC4364

3方案描述

3.1单播

3.1.1子网内单播

如图Figure1，Host A 和 Host B属于同一子网192.0.2.0/24，但部署在不同数据中心。PE路由器互联两个数据中心，PE1 和 PE2 各自生成本地的主机路由192.0.2.2/32 和192.0.2.3/32，并通过BGP发布。同时PE相关链路上使能ARP proxy。

假设Host A 访问 Host B ，首先Host A发ARP 请求，PE-1 收到ARP 请求后会扮演ARP proxy的角色返回自己MAC 地址；然后Host A 发数据报文（目的MAC为PE-1）到PE-1 ；然后PE-1 隧道转发到PE-2；最后PE-2 转发报文到Host B，完成Host A 和 Host B通信。

3.1.2子网间单播

如图Fgure 2，只有一个数据中心部署了默认网关，与默认网关连接的PE-2需要配置或者学习到默认路由，下一跳到GW。同时这条默认路由需要发布给其它PEs。
假设Host A 访问子网外，首先发ARP 请求到GW，PE-1 收到ARP 请求后会扮演ARP proxy角色返回自己的MAC 地址；然后Host A 发数据报文（目的MAC为PE-1）到PE-1；然后PE-1 隧道转发报文到PE-2，因为从PE-2学到的默认路由；最后PE-2 转发报文给GW。

如图Figure3，每个数据中心部署了默认网关，主机将直接发给ARP 请求到本地的GW。

如图Figure4，如果PE有去往外部的路由，那么PE本身可以配置成GW。

3.2组播

同一子网内，Host组播方案和MVPN一致。由于还没遇到组播场景，所以暂不深入学习。

3.3主机发现

PE 路由器应该能动态地发现和及时更新主机列表，以确保主机路由正确可达。PE路由器发现本地主机仍然时依赖传统的ARP或者ND机制。

3.4ARP/ND Proxy

PE 路由器作为ARP proxy，在相关联的VRF中有目标主机的最佳路由，最佳路由的出接口不同于ARP 请求/ND，PE路由器只要代替目标主机响应ARP 请求/ND。
在PE是多归属场景，VRRP通常在PE上配置。这时这有VRRP Master扮演ARP/ND Proxy角色。

3.5主机 Mobility

在VM迁移过程中，原先的PE收到VM脱离通知后撤销该主机路由；新的PE路由器接收到VM的迁入通知（如：免费ARP）后创建相应的主机路由。
下面这段没有看太懂，以后再体会体会。
（Meanwhile, the latter PErouter could optionally broadcast a gratuitous ARP or send an unsolicited NA message on behalf of that host with the source MAC address being one of its own. In this way, the ARP/ND entry of this host that moved and that has been cached on any local host would be updated accordingly. ）

在VM脱离消息机制的情况下，PE有以下检测机制：在第一次从远端PE学到一个主机路由时，PE立即检查本地路由是否正常工作（例如：ARP，Ping）。确保每个数据中心的默认网关配置相同的MAC地址和IP非常重要，因为VM可能持续在向默认网关发送数据报文。网关VRRP场景，确保网关使用相同的虚MAC和虚IP。

3.6数据中心交换机的转发表规模

在虚拟子网环境，跨数据中心的子网被分割成若干段，每一段局限于一个数据中心内。因此，数据中心交换机只需要学习本地的MAC地址，而不是所有数据中心的MAC地址。

3.7默认网关的ARP/ND 表项规模

当默认网关设置在PE上，如图Figure4，ARP/ND 表只需要缓存本地主机的。因此ARP/ND 表的大小不会随数据中心互联的增加而增加。

3.8ARP/ND 未知单播泛洪避免

在虚拟子网环境，跨数据中心的子网被分割成若干段，每一段局限于一个数据中心。因此，泛洪的影响范围也被限制在每个数据中心内。

3.9路径优化

如图Figure4，PE扮演默认网关生产本地的主机路由，发布到远端PEs。依靠主机路由选路，一个云用户到数据中心服务器的流量可以直接达到目标服务器所在的数据中心；反过来，依据路由最长匹配原则，数据中心服务器到云用户的流量也是走最佳路径。

4限制

4.1不支持非IP流量

虽然现在数据中心的大部分流量都是IP流量，但仍然有一些历史遗留的应用服务集群是非IP流量（如：集群节点间的heartbeat消息）因为虚拟子网是基于三层转发，所以不能支持这些非IP流量。为了支持这些非IP流量，可以采用“route all IP traffic,bridge non-IP traffic”的办法。也就是说，无论是子网内还是子网间的IP流量采用虚拟子网设计的路由方式转发，而非IP流量采用二层转发。一个统一的L2/L3 VPN 部署在ingress PE路由器，区分数据报文做相应的L2/L3 转发。

4.2不支持IP广播和Link-Local组播

前面提到的，在虚拟子网的方案里子网内流量是经PE做三层转发的，所以IP广播和Link-Local组播不能经过PE转发。为了支持IP广播和Link-Local组播，可以考虑L2/L3 overlay的方式。这样，IP广播和Link-Local组播做二层转发，IP流量做路由转发。

4.3TTL和Traceroute

前面提到的，子网内的流量是做三层转发。因为不需要对BGP/MPLS IP VPN 的TTL机制做改变，当从一个主机Traceroute另一个主机时，假设两个主机属于一个子网，但是在不同数据中心，Traceroute的输出结果显示是通过虚拟子网连接，而不是二层连接，因为PE路由器会显示Taceroute输出。另外任何应用产生的子网内流量TTL如果设置为１，应用可能不会正常工作。

５安全

因为BGP/MPLS IP VPN的安全方面描述可以参考RFC4364 。
跨数据中心的流量携带的敏感信息经常在承载上更上层，不直接配PE所感知。例如VM的密钥、敏感配置信息。可能未来会有MPLS层的保护。

6参考

https://datatracker.ietf.org/doc/html/rfc7814