上次谈到SDN网关及其在Tungsten Fabric集群中的作用，简单地说，SDN网关是Tungsten Fabric和网络其它部分之间的“胶水”。
它通过终结源自计算节点的overlay隧道来实现这一功能。一旦隧道在SDN网关上被终结，那么流量就可以进一步去往任何目的地。在这个环节上，可以使用任何解决方案/技术：MPLS、IP等等。
在这里，我们将专注于使用MPLS传输的网络，这是一个“经典”的MPLS骨干网。这意味着来自计算节点上运行的虚拟机的流量通过MPLSoUDP隧道（或MPLSoGRE、VXLAN）到达SDN网关。在那里，正如刚才所说，MPLSoUDP隧道被终止，“原始流量”（由虚拟机发起的流量）通过众所周知的MPLS传输（vpn服务标签 rsvp/ldp传输标签），跨越网络核心，被进一步发送出去。
换句话说，流量来自MPLSoUDP隧道内的计算节点，并通过熟悉的MPLSoMPLS隧道发送到骨干网。
毕竟，Tungsten Fabric的工作原理就像一个VPN！虚拟网络是分配了路由目标的VRF。控制节点将MPLS标签（服务标签）分配给路由（例如通向虚拟机的路由）。底层传输是IP（或者更好的是UDP），因为IP Fabric（DC中的底层元素）只支持IP而非MPLS（在IP Fabric中没有rsvp/ldp）。
换句话说，把TF - SDN网关的交互看作是标准的PE-PE交互，它们之间有IP传输。
配置了VRF，就能控制路由通告吗？
现在，我们毕竟是在VPN中……另一个问题开始出现了。“到底要不要用VRF？”换句话说，我们到底要不要在SDN网关上配置VRF？
这里有两种可能的模式：
第一种场景下，我们在SDN网关上配置了VRF。在这种情况下，SDN GW可以被看作是一个纯PE。选择这种方案可能有几个原因：例如，VRF允许路由汇总（不向核心发送VM /32路由，而只发送聚合路由），或者SDN GW使用PE-CE协议与另一个设备“对话”。
相反，第二种场景是一种Inter-AS的情况，SDN GW作为ASBR，通过在MPLSoUDP和MPLSoMPLS隧道之间切换来转发流量。第二种场景可能比较简单，因为我不需要配置VRF和所有相关对象（例如策略）。
本文将重点介绍第一种场景。具体来说，我们要看看在这样的场景下如何管理路由通告。为什么这件事值得一说呢？
通常情况下，当涉及到VRF的时候，我们往往认为可以通过VRF导入/导出策略来控制路由通告。无论如何，这并不完全正确。
请考虑以下几点：
我们的SDN网关有一个配置了路由目标X的VRF，该路由目标与Tungsten Fabric虚拟网络上配置的路由目标一致。在该虚拟网络上，有一个虚拟机在运行。通向虚拟机的/32路由被导入到VRF中。这是一个来自TF的inet-vpn，由SDN GW导入到VRF中。SDN网关和计算节点之间的数据平面是MPLSoUDP。然后，这条相同的路由通过iBGP（通常是通过路由反射器route reflector）以inet-vpn nlri的形式向核心重新通告。这也是最早来自TF的路由。这里的数据平面是MPLSoMPLS。
SDN网关上的VRF也有一条本地0/0静态路由。这个路由是通向TF的通告，也就是说SDN网关要把它翻译成inet-vpn路由。SDN网关还与另一个路由器传递OSPF。在这种情况下，另一个路由器可以看作是CE，而OSPF可以看作是PE-CE协议。同样的本地静态0/0也是以OSPF路由的方式向CE发布通告。
正如你所看到的，这个场景几乎什么都有：来自TF的VPN路由，本地路由导出到TF，VPN路由向远程PE发布通告。
正如已经预料到的那样，VRF导入/导出策略不足以控制一切。这是因为我们有inet-vpn、静态、PE-CE路由，而SDN GW必须通告inet路由，并重新通告inet-vpn路由（从TF到RR）。
都有哪些策略？分别控制什么路由？
为了更好地理解如何控制路由通告，我们需要看一些Tungsten Fabric的“细节”。
首先要回答的问题是：VRF导入/导出策略的范围是什么？
VRF导入策略是用来决定哪些inet-vpn路由必须导入到VRF中。这意味着它控制了哪些来自于TF或远程PE的路由，将被复制到VRF中。
另一方面，导出策略控制哪些路由必须从VRF向PE（或RR）导出。
显然，VRF导出策略做了一切：它查看VRF内的路由，并决定接受什么（并且作为inet-vpn路由发送给PE/RR），以及拒绝什么。不过，这并不完全正确。VRF导出策略对本地静态定义的路由和PE-CE协议的路由有控制能力。这意味着VRF导出策略可以用来导出0/0静态路由或从CE学习的路由（在这种情况下是通过ospf……但也可以是isis、rip、bgp等）。然而，该策略无法控制已经是inet-vpn路由的路由：这里是指TF路由。
这些路由首先以inet-vpn路由的形式从Tungsten Fabric来，并存储到bgp.l3vpn.0中。然后，根据VRF导入策略，将该路由“复制”到VRF中。VRF是该路由的二级表，路由只从主表（bgp.l3vpn.0）导出。
我们来看一下VM路由。这条路由最初由Tungsten Fabric以inet-vpn路由的形式向SDN网关发布通告。SDN网关根据VRF导入策略将该路由导入到VRF中。现在，VRF导出策略告诉阻止该路由向远程PE发布通过。但是，该路由还是向远程PE做了通告。这是因为该路由已经是inet-vpn的路由，它不是本地静态路由，也不是通过PE-CE协议学习的路由，因此VRF导出策略，如前所述，对其没有任何作用。
这是一个很小、但很基础的细节！了解VRF策略的范围，以及如何处理属于不同家族的路由（inet或inet-vpn）是至关重要的。
如何控制来自TF的路由？
然而，仍有一个悬而未决的问题：如何控制来自TF的路由向RR/PE发布通告的行为？由于VRF导出策略无法控制这些路由，我们需要在管理inet-vpn路由的层面采取行动：SDN网关和PE/RR之间的BGP会话。在该会话上，我们可以使用导出策略来阻止VM路由向RR发布广告。
其实这就是路由汇总的实现方式！想象一下，多个虚拟机连接到一个虚拟网络。假设你有IP为192.168.101.11/32的VM1，IP为192.168.101.12/32的VM2，以此类推。你可能希望只向RR（192.168.101.0/24）发送一个集合。如何实现这个目标呢？
首先，你在VRF内部配置一个聚合路由，并通过VRF导出策略发布通告（这是一条以VRF为主表的路由，所以VRF-export策略对它有控制权）。接下来，我们对RR应用一个导出策略。这个策略可能很简单：它根据路由目标匹配inet-vpn /32路由，并拒绝它们。
其实，这并不是唯一的选择。我们还可以在SDN网关和Tungsten Fabric之间的会话中使用一个导入策略。正如我们所知道的，就是会话所携带的inet-vpn路由。这里的想法是匹配那些/32路由，接受它们，并设置众所周知的community属性为no-advertise。这样一来，路由将被导入到VRF中，但不会导出到RR。
还有一个比较有趣的用例。假设一个虚拟网络被分配了路由目标X，在SDN网关上，我们配置了一个VRF，以便从Tungsten Fabric导入路由目标X。那个路由目标只具有本地意义，在骨干内部是完全不知道的。为了将这些路由与现有的VPN“集成”，必须使用另一个路由目标，比如说路由目标Y。这就需要一个所谓的路由目标转换。如何实现呢？答案应该很简单了！来自TF的路由是inet-vpn的，所以不能依靠VRF导出/导入策略。我们需要根据应用于会话的导出策略对RR（或远程PE）采取行动。在那里，将 TF 路由与路由目标 X 匹配，接受它们，并将community“设置”到路由目标 Y（这里“community设置”的意思是“删除所有现有的community并添加指定的community”）。
一旦你知道哪些策略可以控制哪些路由，就没那么难了，对吧？
现在，你遇到的任何用例都应该没什么秘密了（我们知道总有一些奇怪的特例或非常好的请求）。设想一下：我们配置了VRF导出策略，这样就可以通告/导出在VRF中定义的静态路由。该路由将被通告到所有的远程PE/RR，更一般的情况是，通告到所有的inet-vpn对等点上。从我们的SDN网关来看，就是将该静态路由同时向TF和远程PE/RR做通告。假设你只想把该路由通告给TF。很简单！配置对RR的导出策略，使其匹配“静态路由A来自VRF XXX”并拒绝它！
就是这样，利用很少的“模块”你就可以建立任何你想要的东西！
作者：Umberto Manferdini 译者：TF编译组
原文链接：https://iosonounrouter.wordpress.com/2020/09/08/1279/
（注：原文为Contrail，在本系列文章中，Tungsten Fabric的功能与Contrail一致）
