专栏首页Tungsten Fabric中文社区配置SDN网关:关于VRF、本地路由及inet-vpn路由

配置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?

这里有两种可能的模式:

第一种场景下,我们在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一致)


原文链接:https://iosonounrouter.wordpress.com/2020/09/08/1279/

原文作者:Umberto Manferdini

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何设置TF SDN网关,并与Tungsten Fabric协同工作

    Tungsten Fabric并不是“vanilla”(意为完美的)Openstack与OVS。

    Tungsten Fabric
  • Tungsten Fabric解决方案指南-Gateway MX

    本指南介绍如何使用MX作为网关(gateway),为Tungsten Fabric(编者按:原文为Contrail,其开源版已更名为Tungsten Fabri...

    Tungsten Fabric
  • TF功能指南 | 使用Device Manager管理TF物理路由器

    原文链接:https://www.juniper.net/documentation/en_US/contrail5.0/topics/concept/usin...

    Tungsten Fabric
  • Tungsten Fabric架构解析丨TF如何连接到物理网络?

    在任何一个数据中心中,都需要一些VM访问外部IP地址,并且数据中心外部的用户,也需要通过公共IP地址访问某些VM。为此,Tungsten Fabric提供了几种...

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

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

    Tungsten Fabric
  • Juniper瞻博网络路由实例,收藏!

    在瞻博网络交换机或路由器上,我们可以创建额外的虚拟路由表,称为 routing-instances,这些类似于 Cisco 路由器上的 VRF。

    网络技术联盟站
  • Frank Wu:当OpenStack遇到Tungsten Fabric

    https://tungstenfabric.org.cn/assets/uploads/files/tf-live3-mcp-openstack-tungst...

    Tungsten Fabric
  • Tungsten Fabric如何支撑大规模云平台丨TF Meetup演讲实录

    本文所有相关资料https://tungstenfabric.org.cn/assets/uploads/files/large-scale-cloud-yy....

    Tungsten Fabric
  • 杨雨:Tungsten Fabric如何增强Kubernetes的网络性能

    在混合多云的世界里,Kubernetes是如此流行,已经成为应用统一部署和管理的事实标准,而Tungsten Fabric与Kubernetes的集成,更增强了...

    Tungsten Fabric
  • pps数据无法回答“哪种SDN解决方案更好”,你需要考虑这些

    最近我参与了一个项目,我们在Tungsten Fabric(注:原文为Contrail,本文将以功能一致的Tungsten Fabric替换)集群中部署了虚拟移...

    Tungsten Fabric
  • 拍案叫绝!一文带你了解MPLS多协议标签交换技术

    MPLS技术的全称是多协议标签交换技术,是在 Cisco公司所提出来的TagSwitching 技术基础上发展起来的,属于第三层交换技术,它引入了基于标签的机制...

    网络技术联盟站
  • 基于Segment Routing技术构建新一代骨干网:智能、可靠、可调度(二)

    作者:唐玉柱,UCloud 高级网络架构师、UCloud新一代骨干网架构规划项目负责人。拥有丰富的数据中心、骨干网架构设计和运维经验;目前主要负责UCloud全...

    SDNLAB
  • 为OpenStack和K8s集群提供无缝虚拟网络

    现实情况下,可能会发生虚拟机和容器需要相互“交谈”的情况。如果是这样,我们需要以某种方式实现两个独立集群之间的通信。

    Tungsten Fabric
  • openstack网络设计-(一)试探

    openstack的api只能扩展并且向前兼容,不能影响已经开发的云管和监控等业务。

    惠伟
  • Tungsten Fabric入门宝典丨关于服务链、BGPaaS及其它

    Tungsten Fabric入门宝典系列文章,来自技术大牛倾囊相授的实践经验,由TF中文社区为您编译呈现,旨在帮助新手深入理解TF的运行、安装、集成、调试等全...

    Tungsten Fabric
  • SDN在云数据中心的应用——架构篇

    前言 SDN概念一直如火如荼,若是要谈到概念落地及大规模应用,一定离不开SDN在云计算数据中心的实践应用。云数据中心对网络提出了灵活、按需、动态和隔离的需求,S...

    SDNLAB
  • 「数据中心」脊叶网络架构:Cisco VXLAN MP-BGP EVPN脊叶网络

    在RFC 7348定义的VXLAN泛洪学习模式下,终端主机信息学习和VTEP发现都是基于数据平面的,没有控制协议在VTEP之间分配终端主机可达性信息。为了克服f...

    首席架构师智库
  • 海纳百川,有容乃大 ——云网络SDN控制系统演进之路

    VPC提供给客户在云端创建自定义的网络服务,用户可以自定义在云端VPC的子网、IP规划等网络参数,将VPC抽象成用户在云端的数据中心。VPC对等连接方案解决了...

    鹅厂网事
  • vxlan转发原理

    很多年之前部门很多人调去做ovs,领导让我匆忙接手vxlan三层分布式网关项目,当时还没有evpn,对isis做修改同步mac和ip,我做isis的修改,对转发...

    惠伟

扫码关注云+社区

领取腾讯云代金券