如何在SDN GW上汇总虚拟机路由

在Tungsten Fabric中，每个虚拟网络都不过是vRouter上的一个VRF。这使得vRouter在经典的L3VPN场景中看起来像是一个PE节点。

每个虚拟网络都被分配了一个CIDR，例如10.10.10.0/24。vRouter有一个/32的路由指向连接到虚拟网络的每个虚拟机。

通过在虚拟网络上配置一个route-target，这些路由可以被通告到SDN GW。

这是一个PE-PE交互。那么这意味着什么？

SDN GW将接收这些路由，并将其存储在bgp.l3vpn.0表中。如果SDN GW有另一个MP-BGP会话，例如朝向骨干（backbone）路由反射器，那么这些路由将被发送到RR，并有可能到达网络中的任何其它远程PE。

由于通常Tungsten Fabric和SDN GW位于不同的自治系统中，我们处理的是一个经典的Inter-AS option B方案：来自TF的路由会按原样发送到骨干网。

这样很好，为了将目的地为虚拟机的流量发送到虚拟机运行的确切计算节点，需要拥有/32的路由。想象一下，只有一个/24的网络指向一个随机的计算节点的情况。端到端流量无论如何都会工作，但平均而言，由于虚拟机可能不在通用/24路由指向的计算节点上运行，需要额外的流量跳数。这将产生不必要的东西向流量。在SDN GW上拥有/32路由可以避免这种情况。

如果我们进一步将这些路由导出到远程PE，那么远程PE也知道正确的目的地来发送数据包。这一切都很好对吗？是，也不是。

想象一下，一个大规模的TF集群，有许多虚拟机和许多虚拟网络“暴露”在SDN GW上。这将意味着大量的/32在骨干网上旅行。这是可扩展的吗？也许不能！

另外，所有属于集群上配置的虚拟网络的虚拟机都位于同一个SDN GW的背后，所以拥有所有这些/32路由可能会被视为冗余信息：重要的是到达SDN GW，而SDN GW是唯一需要知道/32细节的。

其实，这并不完全正确。假设我们的VN有CIDR 10.10.10.0/24。远程PE将向SDN GW发送属于10.10.10.0/24的任何IP的流量，即使不存在具有该特定IP的虚拟机……所以，是的，有一些缺点，但还是可以接受的。

那么应该如何实现呢？需要SDN GW知道/32，但只通告相应的网络方面（例如/24）的路由。

这可以通过在SDN GW上配置一个VRF来实现。

该VRF将从Tungsten Fabric导入路由，匹配正确的路由目标。

set routing-instances s1 instance-type vrf
set routing-instances s1 route-distinguisher 2.2.2.100:1
set routing-instances s1 vrf-import s1-imp
set routing-instances s1 vrf-export s1-exp
set policy-options policy-statement s1-imp term contrail from protocol bgp
set policy-options policy-statement s1-imp term contrail from community s1-vn
set policy-options policy-statement s1-imp term contrail then accept
set policy-options community s1-vn members target:64520:100

这将导致/32路由被导入到VRF路由表中。

root@esto# run show route table s1.inet.0 10.10.10/24
 
s1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
10.10.10.10/32     *[<