在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导入路由，匹配正确的路由目标。
代码语言：javascript复制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路由表中。
代码语言：javascript复制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 *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
AS path: 64520 64500 I, validation-state: unverified
> via gr-0/0/10.0, Push 299856
10.10.10.11/32 *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
AS path: 64520 64500 I, validation-state: unverified
> via gr-0/0/10.0, Push 299856
10.10.10.12/32 *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
AS path: 64520 64500 I, validation-state: unverified
> via gr-0/0/10.0, Push 299856下一跳是MPLSoGRE隧道，朝向Tungsten Fabric方向。
现在，我们在VRF上配置一个聚合路由：
代码语言：javascript复制set routing-instances s1 routing-options aggregate route 10.10.10.0/24 discard最后，需要将该聚合路由朝向路由反射器发布通告。这是通过vrf-export策略完成的：
代码语言：javascript复制set policy-options policy-statement s1-exp term agg from protocol aggregate
set policy-options policy-statement s1-exp term agg then community add s1-vn
set policy-options policy-statement s1-exp term agg then accept
set policy-options policy-statement s1-exp then reject因此，我们现在向骨干网通告的是聚合路由：
代码语言：javascript复制root@esto# run show route advertising-protocol bgp 3.3.3.3 10.10.10.0/24 exact
s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.10.0/24 Self 100 64520 64500 I这样就够了吗？还不够！
我们来查看一下所有的通告路由：
代码语言：javascript复制root@esto# run show route advertising-protocol bgp 3.3.3.3 10.10.10/24
s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.10.0/24 Self 100 64520 64500 I
bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
1.1.1.100:1:10.10.10.10/32
* Self 100 64520 64500 I
1.1.1.100:1:10.10.10.11/32
* Self 100 64520 64500 I
1.1.1.100:1:10.10.10.12/32
* Self 100 64520 64500 I
2.2.2.100:1:10.10.10.0/24
* Self 100 64520 64500 I我们也在通告/32路由。为什么会这样？细节决定成败。请记住，这是一个Inter-AS option B的方案，我们收到的/32路由是来自另一个PE，而不是来自CE，它们是作为MP-BGP路由接收的，而不是标准的BGP。
Vrf-export策略只适用于从CE协议（bgp、bfd、isis、static等）学到的路由。因此，vrf-export策略对/32路由没有任何影响！我们不能在vrf-export策略中停止它们，不能在VRF级别上阻止它们。
至少有两种方法来解决这个问题。
第一个办法是在SDN GW和Tungsten Fabric之间的BGP会话上配置一个导入策略。这个导入策略只是根据route target匹配/32路由，并将no-advertise community添加其中：
代码语言：javascript复制root@esto# show policy-options policy-statement imp-contrail | display set
set policy-options policy-statement imp-contrail term a1-32 from community s1-vn
set policy-options policy-statement imp-contrail term a1-32 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement imp-contrail term a1-32 then community add no-advertise
set policy-options policy-statement imp-contrail term a1-32 then accept
[edit]
root@esto# show protocols bgp group contrail import | display set
set protocols bgp group contrail import imp-contrail现在的结果是预期的结果：
代码语言：javascript复制root@esto# run show route advertising-protocol bgp 3.3.3.3 10.10.10/24
s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.10.0/24 Self 100 64520 64500 I
bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
2.2.2.100:1:10.10.10.0/24
* Self 100 64520 64500 I另一种解决办法是：
代码语言：javascript复制root@esto# show policy-options policy-statement rr | display set
set policy-options policy-statement rr term s1-32 from community s1-vn
set policy-options policy-statement rr term s1-32 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement rr term s1-32 then reject
[edit]
root@esto# show protocols bgp group rr export | display set
set protocols bgp group rr export rr这次我们是在SDN GW和RR之间的BGP会话上配置一个导出策略。我们只是根据route target拒绝/32路由。
两种解决方案得到的结果是一样的，选哪个由你决定。
作者：Umberto Manferdini 译者：TF编译组 原文链接：https://iosonounrouter.wordpress.com/2020/05/15/summarizingvm-routes-at-the-sdn-gw/
