基于 Segment Routing 技术构建新一代骨干网:智能、可靠、可调度(一)
![基于Segment Routing技术构建新一代骨干网:智能、可靠、可调度(一)](https://static001.geekbang.org/infoq/7a/7aaeafe7854aa57817c61831b33a7b5c.jpeg)
随着网络技术的发展和云计算业务的快速普及,当前各行各业的客户都有迫切上云的需求,越来越多的关键业务,如:web 前端、视频会议、办公应用、数据存储等开始部署在云端;新的网络架构设计特别是骨干网,必然要适应云计算和互联网应用的发展,而传统的 MPLS 骨干网不能适应这种变化,面临如下诸多挑战:
1、如何实现用户云下与云上、云上 VPC 之间、云下不同物理位置之间业务的灵活开通;
2、如何利用本地专线和最后一公里互联网线路构建混合组网能力;
3、如何确保关键业务的优先级和服务质量;
4、如何简化开通流程、快速部署和统一策略管理;
5、如何提升专线带宽利用率和流量可视化;
6、如何实现新一代骨干网智能、可靠、可调度。
本文将结合 UCloud 基础网络团队新一代骨干网的架构演进过程,介绍 Segment Routing 技术在 UCloud 骨干网的落地细节,并详细阐述当前骨干网如何通过 SR-TE 技术实现智能、可靠、可调度的新一代骨干网架构。
DCN 网络快速迭代
UCloud 数据中心基础架构网络(以下简称 DCN)在最近这几年经历了野蛮式的快速发展阶段,从北上广三地的数个可用区发展到全球 25 个地域 31 个可用区;业务云化和分布式数据中心的建设,推动了城域网(以下简称 MAN)和骨干网规划建设,如下图所示:
![](https://static001.geekbang.org/infoq/38/38a59aacb4a6bec19d55e2516aa3b889.png)
DCN 网络迭代过程如下:
1、同城单可用区升级至同城多可用区;
2、单 Region 多可用区升级至多 Region 多可用区。
DCN 网络快速迭代带来的网络挑战:
1、MAN 网络高带宽与可靠性要求:同城分布式 DCN 网络建设带来的问题是:客户业务扁平化部署,导致同城跨可用区有大量的东西向业务互访流量,对 MAN 网络的带宽和可靠性有严格的要求。
2、骨干网架构升级与流量工程要求:随着 UCloud 全球节点 DCN 网络的建设部署,跨地域客户开始有业务互访和跨域流量优化需求,对骨干网规划和流量工程提出了新的要求。
全球专线资源布局
当前 UCloud 全球 CDN 节点有 500+,25 个地域,31 个可用区;通过运营商专线打通全球 25 个地域,如下图所示:
![](https://static001.geekbang.org/infoq/4b/4bc853e33cd9b528e30c80dbd65592dc.png)
1、全球机房专线接入骨干网
骨干网依托 UCloud 全球 DCN 网络以及专线资源,可为用户提供全球范围的就近接入,实现端到端网络稳定,解决跨域业务互访丢包和高延迟问题。
2、全球节点灵活组网
为用户提供基于本地专线和最后一公里互联网接入,实现用户的混合组网能力。
3、提供稳定、可靠的基础架构
点到点专线资源提供物理层的带环保护,一方面通过 SR-TE 技术实现流级别调度和快速容灾备份能力;另一方面基础网络提供一张 1:1 基于 Internet 级的备份骨干网,保证整个骨干网达到 99.99%可用率。
UCloud 骨干网架构演进历史
01
2018 年之前骨干网架构
![](https://static001.geekbang.org/infoq/d7/d75333771359bbf2f7c1f633012acba4.png)
UCloud 基础网络团队在 2016 年下半年开始规划第一代骨干网(以下简称骨干网 1.0),2017 年底完成了骨干网 1.0 设计规划,骨干网 1.0 架构规划专线资源接入到各 Region 的 MAN 网络核心设备(以下简称 M-Core),各 Region 的 M-Core 之间通过供应商二层专线进行全球组网;M-Core 之间运行 ISIS 协议,打通全球骨干网 ISIS 域,每个地域双 M-Core 或者四 M-Core 和控制面 RR 建立 IBGP 邻居关系,M-Core 通过 IBGP 协议将本地域 DCN 网络路由信息通告至 RR,RR 反射给全球所有 M-Core 节点;数据转发面通过 IBGP 路由进行迭代,最终通过 ISIS 转发至目标 DCN 网络。为优化骨干网流量转发,在关键设备上开启如下功能:
1、为实现骨干网等价路由(以下简称 ECMP),必须在 M-Core 和 RR 上开启 BGP ADD-PATH 属性;
2、为保证 IGP 最短路径转发,跨域之间 ISIS 开销值设置为两地域直连专线实际延迟*100,如:北京-上海专线延迟为 30ms,那么北京-上海地域的 ISIS 开销设置为 3000。
骨干网 1.0 设计目标:
1、实现 Region 级别 DCN 网络互通,提供云业务跨地域容灾能力;
2、支持云上用户通过 UCloud 高速通道产品 UDPN 打通跨域 VPC 资源。
骨干网 1.0 新挑战:
1、MAN 网络与骨干网高度耦合,专线开通配置复杂,增加运维难度;
2、不支持客户不同物理位置之间资源互通;云下资源到云上 VPC 之间资源开通复杂、周期冗长;
3、不支持跨地域级别的流量智能调度。
02
2020 年之前骨干网架构
![](https://static001.geekbang.org/infoq/d1/d1debbc38f5b96a6d0874cd0e8a4503a.webp?x-oss-process=image/resize,p_80/format,jpg)
针对骨干网 1.0 所面临的一些问题,2018 年 UCloud 基础网络团队设计规划了第二代骨干网(下简称骨干网 2.0)。在骨干网 2.0 中,我们新增了租户隔离的特性,而要在骨干网上实现大规模的租户隔离,MPLS-VPN 技术最合适不过,但由于考虑到整体的部署成本以及部署难度,我们最终放弃了这个方案,借鉴了 DCN 网络的租户隔离思路,采用 VXLAN 二层网关方案来实现;
骨干网 2.0 整体架构分为两层,Underlay 和 Overlay;Underlay 使用 VXLAN+BGP EVPN 实现网络大二层,在 Overlay 上实现骨干网 1.0 的架构需求;具体实现如下:
Underlay 层规划
1、Underlay 层主要由两种设备组成:TBR 和 TER。TBR 用于运营商二层专线资源接入,主要用于数据转发,TER 用于封装 VXLAN 报文,即 VTEP 设备。全球节点的 TBR 和 TER 设备通过 VXLAN+ BGP EVPN 技术组建一张全球二层网络,这张二层网络提供全球任意跨域节点之间二层业务开通。
2、TBR 设备通过 ISIS 协议打通整个 IGP 域,TER 和控制面 TRR 建立 BGP EVPN 邻居关系,各个站点互相学习 MAC/IP 路由;转发面数据通过 VXLAN 封装转发,控制面信息通过 EVPN 学习同步。
3、用户线下 IDC 业务互访,以及线下 IDC 到云上业务之间通过 VXLAN 开通二层业务。
Overlay 层规划
跨域 M-Core 直连通过 VXLAN 开通,M-Core 之间运行 ISIS 协议,打通全球骨干网 ISIS 域,每个地域双 M-Core 或者四 M-Core 和控制面 RR 建立 IBGP 邻居关系,M-Core 通过 IBGP 协议将本地域 DCN 网络路由通告至 RR,RR 反射给全球所有 M-Core 节点,数据转发面通过 IBGP 路由进行迭代,最终通过 ISIS 转发至目标 DCN 网络。
骨干网 2.0 设计目标:
1、实现 MAN 网络和骨干网严格分层,提升运维效率;
2、通过 VXLAN+BGP EVPN 构建业务接入网,实现业务灵活就近上骨干;
3、实现客户云下不同物理位置、云下到云上之间资源快速开通。
骨干网 2.0 新挑战:
1、不支持骨干网流量智能调度;
2、本地接入只支持专线接入,组网方式不够灵活,增加网络运营成本;
3、VXLAN 包头开销过大,网络传输效率低下,专线结算成本上升;
4、不支持 L3VPN 客户接入场景。
为了解决骨干网 2.0 当前的问题,UCloud 基础网络团队在 2019 年下半年开始,对新一代骨干网架构进行重新设计、硬件选型,在新一代骨干网架构设计中采用了当前比较流行的源路由即 Segment Routing 技术(以下简称 SR),在介绍新一代骨干网架构之前先给大家简单介绍一下 SR 技术的基本概念。
Segment Routing 基本概念
01
Segment Routing
![](https://static001.geekbang.org/infoq/be/befa53fedfd279154db870df68287edf.png)
SR 架构基于源路由,节点(路由器、主机或设备)选择路径,并引导数据包沿着该路径通过网络,具体实现方式是在数据报头中插入带顺序的段列表(Segment-list),通过 Segment-list 指示收到这些数据包的节点怎么去处理和转发这些数据包。
由于源节点(头端节点)通过在数据包报文头中添加适当的指令(Segment-list)即可实现基于目标地址的引流(甚至可以基于单条流粒度的引流),且除了头端节点之外,其它节点都不需要存储和维护任何流状态信息,因此引流的决定权都在头端节点。通过这种方式 SR 可以在 IP 和 MPLS 网络中提供高级的流量引导能力。
02
常用标签类型
Prefix-SID
Prefix-SID 是由 ISIS 或者 OSPF 通告的全局 Segment,此 Segment 与 IGP 的前缀相关;Prefix-SID 代表一个路由指令,含义是:引导流量沿着支持 ECMP 的最短路径去往该 Segment 相关联的前缀。Prefix-SID 具有如下特性:
-全局 Segment,SR 域中的所有节点都知道如何处理 Prefix-SID。
-支持多跳,单个 Segment 跨越路径中的多跳,这样就减少了路径所需要的 Segment 数量,并允许跨多跳的等价路径。
-支持 ECMP,可以原生利用 IGP 的等价路径。
-Prefix-SID 一般是通过手工分配,也可使用控制器分配。
Node-SID
Node-SID 是一种特殊类型的 IGP Prefix Segment,是 Prefix Segment 的子类型,通常是某个节点环回口的 32 位前缀地址,这个地址一般是 IGP 的“路由器 ID”;Node-SID 指令是:引导流量沿着支持 ECMP 的最短路径去往该 Segment 相关联的前缀。其和 Prefix Segment 的指令是一致的。
Adjacency-SID
Adjacency-SID 是与单向邻接或者单向邻接集合相关联的 Segment,使用 Adj-SID 转发的流量将被引导至指定链路,而不管最短路径路由如何,一般情况下节点会通告它的本节点链路 Segment(Adj-SID);Adjacency-SID 指令是:“引导流量从与该 Segment 相关联的邻接链路转发出去”。Adjacency-SID 具有如下特性:
-本地 Segment,SR 域中的只有 Adjacency-SID 始发节点知道如何处理该 Segment。
-支持显式路径,任何路径都可以使用 Adjacency-SID 来表示。
-不依赖于 IGP 的动态路由计算,可以绕过 ECMP,走管理员指定的路径转发。
实际部署中应尽量少用 Adj-SID,因为其不支持 ECMP,且会增加 Segment-list 长度,因此建议多使用 Prefix-SID,即支持 ECMP,又可以减少 Segment-list 长度。
Anycast-SID
SR 域中多个节点上配置相同的单播前缀,那么该单播前缀就是一个 Anycast-SID,Anycast-SID 也是 Prefix-SID 的一个子类型。Anycast 集合的属性是去往 Anycast 地址的流量被路由到 Anycast 集合中距离最近(IGP 最短距离)的那个成员,如果开销相同,则流量会进行 ECMP,如果 Anycast 的成员发生故障,则由 Anycast 集合的其它成员来处理去往 Anycast-SID 的流量;Anycast-SID 指令是:引导流量沿着支持 ECMP 的最短路径去往该 Segment 相关联的前缀。其和 Prefix Segment 的指令是一致的。
Anycast-SID 具有如下特性:
-天生支持 ECMP
-支持高可用性
-支持流量工程
03
SR Policy 特性
SR-Policy
为了解决传统隧道接口体系存在的问题, SR Policy 完全抛弃了隧道接口的概念,SR Policy 通过 Segment 列表来实现流量工程;Segment 列表对数据包在网络中的任意转发路径进行编码。列表中的 Segment 可以是任何类型:IGP Segment 、 IGP Flex-Algo Segment(灵活算法) 、BGP Segment 等。
从本质上讲,SR Policy(SR-TE)是 Segment 列表,不是隧道接口。
SR Policy 由以下三元组标识:
头端(Headend):SR Policy 生成/实现的地方。
颜色(Color):任意的 32 位数值,用于区分同一头端和端点对之间的多条 SR Policy。
端点(Endpoint):SR Policy 的终结点,是一个 IPv4/IPv6 地址。
颜色是 SR Policy 的重要属性,通常代表意图,表示到达端点的特定方式(例如低延迟、低成本并排除特定属性链路等),Color 也是流量引流的重要参考属性。
SR Policy 生成的路径一般有两种:显式路径和动态路径
显式路径一般是通过 CLI/Netconf 方式人工规划或者通过控制器方式下发的路径信息,主要包括信息有 endpoint 地址、Color、Segment-List 等;显式路径的最大弊端是无法及时响应网络拓扑变化;为了能保证故障场景下 SR Policy 能够快速收敛,可以通过验证头端的 SR-TE 数据来进行收敛。
建议 Segment-List 使用描述符(IP)形式编写,头端默认会验证所有描述符;
一旦 SR Policy 候选路径不具有有效的 Segment 列表(描述符验证失败),则此候选路径变为无效;
当 SR Policy 所有候选路径都是无效的,则此 SR-Policy 无效。
如果 SR Policy 变为无效,则应用会失效;默认情况下 SR Policy 的转发条目被删除,流量回退到默认转发(SR-BE)路径。
2、动态路径
动态路径是由头端(路由器)或者 PCEP 根据头端的请求自动计算 SR Policy 候选路径:
动态路径主要表示为优化目标和一组约束条件,这两个因素指定了 SR-TE 的意图。
头端可以通过本地的 SR-TE 数据库算出路径,提供一个 Segment 列表或者一组 Segment 列表。
当头端不具备足够的拓扑信息时(跨域环境),头端可以将计算委托给控制器,由控制器自动算路。
当网络发生改变时,动态路径会自动进行重算以适应网络变化。
04
SR Policy 自动引流
![](https://static001.geekbang.org/infoq/92/929b18d3e4f38f3d1c31405927928235.png)
SR Policy 引流支持域内场景和跨域场景,整体的转发流程如下:
着色:出口 PE 在向入口 PE 通告 BGP 业务路由时,或者入口 PE 接收路由时对路由进行着色(标记路由 Color),Color 用于表示路由所需要的 SLA。
计算+引流:域内场景下,头端节点收到 BGP 路由后,通过头端 SR-TE 数据库自动算路完成引流;跨域场景下,头端向控制器发送有状态的 PCEP 路径计算请求,控制器计算去往远端端点的 SR-TE 跨域路径。
转发:数据包在头端完成引流,使用头端计算或者控制器下发的路径进行标签转发。
将 BGP 路由安装到 SR Policy 的动作称为自动引流,其原理主要是通过对 BGP 业务路由进行着色,将流量自动引导至 SR Policy;SR Policy 的自动引流不需要复杂和繁琐的引流配置,而且流量引导对转发性能没有影响,流量控制粒度更为精细。
SR/SR-TE or LDP/RSVP-TE ?
UCloud 基础网络团队在新一代骨干网设计中转发面统一使用 MPLS 封装转发,而控制面的选择经过慎重考虑,我们详细对比了 SR/SR-TE 和 LDP/RSVP-TE 后,最终选择了 SR/SR-TE,具体分析情况如下:
![](https://static001.geekbang.org/infoq/05/05a8d6c611d4af283f1be55a09add1b6.png)
![](https://static001.geekbang.org/infoq/5d/5dc43f90547f29407883c4ff29b844c7.webp?x-oss-process=image/resize,p_80/format,jpg)
总结
本篇分享了数据中心野蛮式增长给 MAN 网络和骨干网带来的极大挑战,以及 SR 部分技术原理。在过去几年里,UCloud 基础网络团队不断演进骨干网架构,从骨干网 1.0 升级到骨干网 2.0 架构,实现了用户云下资源之间、云下到云上资源的快速开通,但依然满足不了当前互联网客户的业务快速发展需求,例如:不支持智能流量调度、无法实现客户 L3VPN 接入需求,不支持最后一公里 Internet 线路接入等。
下一篇将重点介绍 UCloud 如何结合 Segment Routing 技术实现智能、可靠、可调度的新一代骨干网,助力用户分钟级构建多地域全球网络以及同城多可用区互访、多 Region 多可用区互联,实现 UCloud 与用户线上线下 IDC 无间隔互通,升化云网协同。
本文作者:唐玉柱,UCloud 高级网络架构师、UCloud 新一代骨干网架构规划项目负责人。拥有丰富的数据中心、骨干网架构设计和运维经验;目前主要负责 UCloud 全球数据中心、骨干网架构设备选型、架构设计和规划。
版权声明: 本文为 InfoQ 作者【UCloud技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/3f2b7bdd092cddd3017bbfd0e】。文章转载请联系作者。
评论