配置SDN网关:关于VRF、本地路由及inet-vpn路由



  • 上次谈到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?

    这里有两种可能的模式:
    dfb0c26f-0dfd-4f48-baa4-a12586571915-image.png
    第一种场景下,我们在SDN网关上配置了VRF。在这种情况下,SDN GW可以被看作是一个纯PE。选择这种方案可能有几个原因:例如,VRF允许路由汇总(不向核心发送VM /32路由,而只发送聚合路由),或者SDN GW使用PE-CE协议与另一个设备“对话”。

    相反,第二种场景是一种Inter-AS的情况,SDN GW作为ASBR,通过在MPLSoUDP和MPLSoMPLS隧道之间切换来转发流量。第二种场景可能比较简单,因为我不需要配置VRF和所有相关对象(例如策略)。

    本文将重点介绍第一种场景。具体来说,我们要看看在这样的场景下如何管理路由通告。为什么这件事值得一说呢?

    通常情况下,当涉及到VRF的时候,我们往往认为可以通过VRF导入/导出策略来控制路由通告。无论如何,这并不完全正确。

    请考虑以下几点:
    a054bd6a-7c63-46a1-b279-93c517255559-image.png
    我们的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发布广告。
    0943ffcf-038f-435e-b9f9-17fcaa20f114-image.png
    其实这就是路由汇总的实现方式!想象一下,多个虚拟机连接到一个虚拟网络。假设你有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。
    765a656f-d957-4c7a-ae23-3b2b2cdc8b35-image.png
    还有一个比较有趣的用例。假设一个虚拟网络被分配了路由目标X,在SDN网关上,我们配置了一个VRF,以便从Tungsten Fabric导入路由目标X。那个路由目标只具有本地意义,在骨干内部是完全不知道的。为了将这些路由与现有的VPN“集成”,必须使用另一个路由目标,比如说路由目标Y。这就需要一个所谓的路由目标转换。如何实现呢?答案应该很简单了!来自TF的路由是inet-vpn的,所以不能依靠VRF导出/导入策略。我们需要根据应用于会话的导出策略对RR(或远程PE)采取行动。在那里,将 TF 路由与路由目标 X 匹配,接受它们,并将community“设置”到路由目标 Y(这里“community设置”的意思是“删除所有现有的community并添加指定的community”)。
    c2032c2e-dfb7-4107-a4b2-610b51e582ba-image.png
    一旦你知道哪些策略可以控制哪些路由,就没那么难了,对吧?

    现在,你遇到的任何用例都应该没什么秘密了(我们知道总有一些奇怪的特例或非常好的请求)。设想一下:我们配置了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一致)



Log in to reply