摘要：為了解決骨干網(wǎng)當前的問題，基礎網(wǎng)絡團隊在年下半年開始，對新一代骨干網(wǎng)架構進行重新設計硬件選型，在新一代骨干網(wǎng)架構設計中采用了當前比較流行的源路由即技術以下簡稱，在介紹新一代骨干網(wǎng)架構之前先給大家簡單介紹一下技術的基本概念。

前言

隨著網(wǎng)絡技術的發(fā)展和云計算業(yè)務的快速普及，當前各行各業(yè)的客戶都有迫切上云的需求，越來越多的關鍵業(yè)務，如：web前端、視頻會議、辦公應用、數(shù)據(jù)存儲等開始部署在云端；新的網(wǎng)絡架構設計特別是骨干網(wǎng)，必然要適應云計算和互聯(lián)網(wǎng)應用的發(fā)展，而傳統(tǒng)的MPLS骨干網(wǎng)不能適應這種變化，面臨如下諸多挑戰(zhàn)：

1、如何實現(xiàn)用戶云下與云上、云上VPC之間、云下不同物理位置之間業(yè)務的靈活開通；

2、如何利用本地專線和最后一公里互聯(lián)網(wǎng)線路構建混合組網(wǎng)能力；

3、如何確保關鍵業(yè)務的優(yōu)先級和服務質(zhì)量；

4、如何簡化開通流程、快速部署和統(tǒng)一策略管理；

5、如何提升專線帶寬利用率和流量可視化；

6、如何實現(xiàn)新一代骨干網(wǎng)智能、可靠、可調(diào)度。

本文將結合UCloud基礎網(wǎng)絡團隊新一代骨干網(wǎng)的架構演進過程，介紹Segment Routing技術在UCloud骨干網(wǎng)的落地細節(jié)，并詳細闡述當前骨干網(wǎng)如何通過SR-TE技術實現(xiàn)智能、可靠、可調(diào)度的新一代骨干網(wǎng)架構。

DCN網(wǎng)絡快速迭代

UCloud數(shù)據(jù)中心基礎架構網(wǎng)絡（以下簡稱DCN）在最近這幾年經(jīng)歷了野蠻式的快速發(fā)展階段，從北上廣三地的數(shù)個可用區(qū)發(fā)展到全球25個地域31個可用區(qū)；業(yè)務云化和分布式數(shù)據(jù)中心的建設，推動了城域網(wǎng)（以下簡稱MAN）和骨干網(wǎng)規(guī)劃建設，如下圖所示：

DCN網(wǎng)絡迭代過程如下：

1、同城單可用區(qū)升級至同城多可用區(qū)；

2、單Region多可用區(qū)升級至多Region多可用區(qū)。

DCN網(wǎng)絡快速迭代帶來的網(wǎng)絡挑戰(zhàn)：

1、MAN網(wǎng)絡高帶寬與可靠性要求：同城分布式DCN網(wǎng)絡建設帶來的問題是：客戶業(yè)務扁平化部署，導致同城跨可用區(qū)有大量的東西向業(yè)務互訪流量，對MAN網(wǎng)絡的帶寬和可靠性有嚴格的要求。

2、骨干網(wǎng)架構升級與流量工程要求：隨著UCloud全球節(jié)點DCN網(wǎng)絡的建設部署，跨地域客戶開始有業(yè)務互訪和跨域流量優(yōu)化需求，對骨干網(wǎng)規(guī)劃和流量工程提出了新的要求。

全球?qū)＞€資源布局

當前UCloud全球CDN節(jié)點有500+，25個地域，31個可用區(qū)；通過運營商專線打通全球25個地域，如下圖所示：

1、全球機房專線接入骨干網(wǎng)

骨干網(wǎng)依托UCloud全球DCN網(wǎng)絡以及專線資源，可為用戶提供全球范圍的就近接入，實現(xiàn)端到端網(wǎng)絡穩(wěn)定，解決跨域業(yè)務互訪丟包和高延遲問題。

2、全球節(jié)點靈活組網(wǎng)

為用戶提供基于本地專線和最后一公里互聯(lián)網(wǎng)接入，實現(xiàn)用戶的混合組網(wǎng)能力。

3、提供穩(wěn)定、可靠的基礎架構

點到點專線資源提供物理層的帶環(huán)保護，一方面通過SR-TE技術實現(xiàn)流級別調(diào)度和快速容災備份能力；另一方面基礎網(wǎng)絡提供一張1:1基于Internet級的備份骨干網(wǎng)，保證整個骨干網(wǎng)達到99.99%可用率。

UCloud骨干網(wǎng)架構演進歷史

01、2018年之前骨干網(wǎng)架構

UCloud基礎網(wǎng)絡團隊在2016年下半年開始規(guī)劃第一代骨干網(wǎng)（以下簡稱骨干網(wǎng)1.0），2017年底完成了骨干網(wǎng)1.0設計規(guī)劃，骨干網(wǎng)1.0架構規(guī)劃專線資源接入到各Region的MAN網(wǎng)絡核心設備（以下簡稱M-Core）各Region的M-Core之間通過供應商二層專線進行全球組網(wǎng)；M-Core之間運行ISIS協(xié)議，打通全球骨干網(wǎng)ISIS域，每個地域雙M-Core或者四M-Core和控制面RR建立IBGP鄰居關系，M-Core通過IBGP協(xié)議將本地域DCN網(wǎng)絡路由信息通告至RR，RR反射給全球所有M-Core節(jié)點；數(shù)據(jù)轉(zhuǎn)發(fā)面通過IBGP路由進行迭代，最終通過ISIS轉(zhuǎn)發(fā)至目標DCN網(wǎng)絡。為優(yōu)化骨干網(wǎng)流量轉(zhuǎn)發(fā)，在關鍵設備上開啟如下功能：

1、為實現(xiàn)骨干網(wǎng)等價路由（以下簡稱ECMP），必須在M-Core和RR上開啟BGP ADD-PATH屬性；

2、為保證IGP最短路徑轉(zhuǎn)發(fā)，跨域之間ISIS 開銷值設置為兩地域直連專線實際延遲*100，如：北京-上海專線延遲為30ms，那么北京-上海地域的ISIS開銷設置為3000。

骨干網(wǎng)1.0設計目標：

1、實現(xiàn)Region級別DCN網(wǎng)絡互通，提供云業(yè)務跨地域容災能力；

2、支持云上用戶通過UCloud高速通道產(chǎn)品UDPN打通跨域VPC資源。

骨干網(wǎng)1.0新挑戰(zhàn)：

1、MAN網(wǎng)絡與骨干網(wǎng)高度耦合，專線開通配置復雜，增加運維難度；

2、不支持客戶不同物理位置之間資源互通；云下資源到云上VPC之間資源開通復雜、周期冗長；

3、不支持跨地域級別的流量智能調(diào)度。

02、2020年之前骨干網(wǎng)架構

針對骨干網(wǎng)1.0所面臨的一些問題，2018年UCloud基礎網(wǎng)絡團隊設計規(guī)劃了第二代骨干網(wǎng)（下簡稱骨干網(wǎng)2.0）。在骨干網(wǎng)2.0中，我們新增了租戶隔離的特性，而要在骨干網(wǎng)上實現(xiàn)大規(guī)模的租戶隔離，MPLS-VPN技術最合適不過，但由于考慮到整體的部署成本以及部署難度，我們最終放棄了這個方案，借鑒了DCN網(wǎng)絡的租戶隔離思路，采用VXLAN二層網(wǎng)關方案來實現(xiàn)；

骨干網(wǎng)2.0整體架構分為兩層，Underlay和Overlay；Underlay使用VXLAN+BGP EVPN實現(xiàn)網(wǎng)絡大二層，在Overlay上實現(xiàn)骨干網(wǎng)1.0的架構需求；具體實現(xiàn)如下：

• Underlay層規(guī)劃

1、Underlay層主要由兩種設備組成：TBR和TER。TBR用于運營商二層專線資源接入，主要用于數(shù)據(jù)轉(zhuǎn)發(fā)，TER用于封裝VXLAN報文，即VTEP設備。全球節(jié)點的TBR和TER設備通過VXLAN+ BGP EVPN技術組建一張全球二層網(wǎng)絡，這張二層網(wǎng)絡提供全球任意跨域節(jié)點之間二層業(yè)務開通。

2、TBR設備通過ISIS協(xié)議打通整個IGP域，TER和控制面TRR建立BGP EVPN鄰居關系，各個站點互相學習MAC/IP路由；轉(zhuǎn)發(fā)面數(shù)據(jù)通過VXLAN封裝轉(zhuǎn)發(fā)，控制面信息通過EVPN學習同步。

3、用戶線下IDC業(yè)務互訪，以及線下IDC到云上業(yè)務之間通過VXLAN開通二層業(yè)務。

• Overlay層規(guī)劃

跨域M-Core直連通過VXLAN開通，M-Core之間運行ISIS協(xié)議，打通全球骨干網(wǎng)ISIS域，每個地域雙M-Core或者四M-Core和控制面RR建立IBGP鄰居關系，M-Core通過IBGP協(xié)議將本地域DCN網(wǎng)絡路由通告至RR，RR反射給全球所有M-Core節(jié)點，數(shù)據(jù)轉(zhuǎn)發(fā)面通過IBGP路由進行迭代，最終通過ISIS轉(zhuǎn)發(fā)至目標DCN網(wǎng)絡。

骨干網(wǎng)2.0設計目標：

1、實現(xiàn)MAN網(wǎng)絡和骨干網(wǎng)嚴格分層，提升運維效率；

2、通過VXLAN+BGP EVPN構建業(yè)務接入網(wǎng)，實現(xiàn)業(yè)務靈活就近上骨干；

3、實現(xiàn)客戶云下不同物理位置、云下到云上之間資源快速開通。

骨干網(wǎng)2.0新挑戰(zhàn)：

1、不支持骨干網(wǎng)流量智能調(diào)度；

2、本地接入只支持專線接入，組網(wǎng)方式不夠靈活，增加網(wǎng)絡運營成本；

3、VXLAN包頭開銷過大，網(wǎng)絡傳輸效率低下，專線結算成本上升；

4、不支持L3VPN客戶接入場景。

為了解決骨干網(wǎng)2.0當前的問題，UCloud基礎網(wǎng)絡團隊在2019年下半年開始，對新一代骨干網(wǎng)架構進行重新設計、硬件選型，在新一代骨干網(wǎng)架構設計中采用了當前比較流行的源路由即Segment Routing技術（以下簡稱SR），在介紹新一代骨干網(wǎng)架構之前先給大家簡單介紹一下SR技術的基本概念。

Segment Routing基本概念

01 Segment Routing

SR架構基于源路由，節(jié)點（路由器、主機或設備）選擇路徑，并引導數(shù)據(jù)包沿著該路徑通過網(wǎng)絡，具體實現(xiàn)方式是在數(shù)據(jù)報頭中插入帶順序的段列表（Segment-list），通過Segment-list指示收到這些數(shù)據(jù)包的節(jié)點怎么去處理和轉(zhuǎn)發(fā)這些數(shù)據(jù)包。

由于源節(jié)點（頭端節(jié)點）通過在數(shù)據(jù)包報文頭中添加適當?shù)闹噶睿⊿egment-list）即可實現(xiàn)基于目標地址的引流（甚至可以基于單條流粒度的引流），且除了頭端節(jié)點之外，其它節(jié)點都不需要存儲和維護任何流狀態(tài)信息，因此引流的決定權都在頭端節(jié)點。通過這種方式SR可以在IP和MPLS網(wǎng)絡中提供高級的流量引導能力。

02 常用標簽類型

• Prefix-SID

Prefix-SID是由ISIS或者OSPF通告的全局Segment，此Segment與IGP的前綴相關；Prefix-SID代表一個路由指令，含義是：引導流量沿著支持ECMP的最短路徑去往該Segment相關聯(lián)的前綴。Prefix-SID具有如下特性：

-全局Segment，SR域中的所有節(jié)點都知道如何處理Prefix-SID。

-支持多跳，單個Segment跨越路徑中的多跳，這樣就減少了路徑所需要的Segment數(shù)量，并允許跨多跳的等價路徑。

-支持ECMP，可以原生利用IGP的等價路徑。

-Prefix-SID一般是通過手工分配，也可使用控制器分配。

• Node-SID

Node-SID是一種特殊類型的IGP Prefix Segment，是Prefix Segment的子類型，通常是某個節(jié)點環(huán)回口的32位前綴地址，這個地址一般是IGP的“路由器ID”；Node-SID指令是：引導流量沿著支持ECMP的最短路徑去往該Segment相關聯(lián)的前綴。其和Prefix Segment的指令是一致的。

• Adjacency-SID

Adjacency-SID是與單向鄰接或者單向鄰接集合相關聯(lián)的Segment，使用Adj-SID轉(zhuǎn)發(fā)的流量將被引導至指定鏈路，而不管最短路徑路由如何，一般情況下節(jié)點會通告它的本節(jié)點鏈路Segment（Adj-SID）；Adjacency-SID指令是：“引導流量從與該Segment相關聯(lián)的鄰接鏈路轉(zhuǎn)發(fā)出去”。Adjacency-SID具有如下特性：

-本地Segment，SR域中的只有Adjacency-SID始發(fā)節(jié)點知道如何處理該Segment。

-支持顯式路徑，任何路徑都可以使用Adjacency-SID來表示。

-不依賴于IGP的動態(tài)路由計算，可以繞過ECMP，走管理員指定的路徑轉(zhuǎn)發(fā)。

實際部署中應盡量少用Adj-SID，因為其不支持ECMP，且會增加Segment-list長度，因此建議多使用Prefix-SID，即支持ECMP，又可以減少Segment-list長度。

• Anycast-SID

SR域中多個節(jié)點上配置相同的單播前綴，那么該單播前綴就是一個Anycast-SID，Anycast-SID也是Prefix-SID的一個子類型。Anycast集合的屬性是去往Anycast地址的流量被路由到Anycast集合中距離最近（IGP 最短距離）的那個成員，如果開銷相同，則流量會進行ECMP，如果Anycast的成員發(fā)生故障，則由Anycast集合的其它成員來處理去往Anycast-SID的流量；Anycast-SID指令是：引導流量沿著支持ECMP的最短路徑去往該Segment相關聯(lián)的前綴。其和Prefix Segment的指令是一致的。

Anycast-SID具有如下特性：

-全局Segment

-天生支持ECMP

-支持高可用性

-支持流量工程

注意：所有節(jié)點必須配置相同的SRGB，才可以通告相同的Anycast Prefix-SID。

03 SR Policy特性

SR-Policy

為了解決傳統(tǒng)隧道接口體系存在的問題 SR Policy 完全拋棄了隧道接口的概念，SR Policy 通過Segment 列表來實現(xiàn)流量工程；Segment 列表對數(shù)據(jù)包在網(wǎng)絡中的任意轉(zhuǎn)發(fā)路徑進行編碼。列表中的 Segment 可以是任何類型：IGP Segment 、 IGP Flex-Algo Segment（靈活算法） 、BGP Segment 等。

從本質(zhì)上講，SR Policy（SR-TE）是 Segment 列表，不是隧道接口。

SR Policy 由以下三元組標識：

頭端（Headend）：SR Policy 生成/實現(xiàn)的地方。

顏色（Color）：任意的 32 位數(shù)值，用于區(qū)分同一頭端和端點對之間的多條 SR Policy。

端點（Endpoint）：SR Policy 的終結點，是一個 IPv4/IPv6 地址。

顏色是 SR Policy 的重要屬性，通常代表意圖，表示到達端點的特定方式（例如低延遲、低成本并排除特定屬性鏈路等），Color也是流量引流的重要參考屬性。

SR Policy生成的路徑一般有兩種：顯式路徑和動態(tài)路徑

1、顯式路徑

顯式路徑一般是通過CLI/Netconf方式人工規(guī)劃或者通過控制器方式下發(fā)的路徑信息，主要包括信息有 endpoint地址、Color、Segment-List等；顯式路徑的最大弊端是無法及時響應網(wǎng)絡拓撲變化；為了能保證故障場景下SR Policy能夠快速收斂，可以通過驗證頭端的SR-TE數(shù)據(jù)來進行收斂。

建議Segment-List使用描述符（IP）形式編寫，頭端默認會驗證所有描述符；

• 一旦SR Policy候選路徑不具有有效的Segment列表（描述符驗證失敗），則此候選路徑變?yōu)闊o效；
• 當SR Policy 所有候選路徑都是無效的，則此SR-Policy無效。

如果SR Policy變?yōu)闊o效，則應用會失效；默認情況下SR Policy的轉(zhuǎn)發(fā)條目被刪除，流量回退到默認轉(zhuǎn)發(fā)（SR-BE）路徑。

2、動態(tài)路徑

動態(tài)路徑是由頭端（路由器）或者PCEP根據(jù)頭端的請求自動計算SR Policy候選路徑：

• 動態(tài)路徑主要表示為優(yōu)化目標和一組約束條件，這兩個因素指定了SR-TE的意圖。
• 頭端可以通過本地的SR-TE數(shù)據(jù)庫算出路徑，提供一個Segment列表或者一組Segment列表。
• 當頭端不具備足夠的拓撲信息時（跨域環(huán)境），頭端可以將計算委托給控制器，由控制器自動算路。
• 當網(wǎng)絡發(fā)生改變時，動態(tài)路徑會自動進行重算以適應網(wǎng)絡變化。

04SR Policy 自動引流

SR Policy引流支持域內(nèi)場景和跨域場景，整體的轉(zhuǎn)發(fā)流程如下：

• 著色：出口PE在向入口PE通告BGP業(yè)務路由時，或者入口PE接收路由時對路由進行著色（標記路由Color），Color用于表示路由所需要的SLA。
• 計算+引流：域內(nèi)場景下，頭端節(jié)點收到BGP路由后，通過頭端SR-TE數(shù)據(jù)庫自動算路完成引流；跨域場景下，頭端向控制器發(fā)送有狀態(tài)的PCEP路徑計算請求，控制器計算去往遠端端點的SR-TE跨域路徑。
• 轉(zhuǎn)發(fā)：數(shù)據(jù)包在頭端完成引流，使用頭端計算或者控制器下發(fā)的路徑進行標簽轉(zhuǎn)發(fā)。

將 BGP 路由安裝到 SR Policy 的動作稱為自動引流，其原理主要是通過對BGP業(yè)務路由進行著色，將流量自動引導至 SR Policy；SR Policy的自動引流不需要復雜和繁瑣的引流配置，而且流量引導對轉(zhuǎn)發(fā)性能沒有影響，流量控制粒度更為精細。

SR/SR-TE or LDP/RSVP-TE ?

UCloud基礎網(wǎng)絡團隊在新一代骨干網(wǎng)設計中轉(zhuǎn)發(fā)面統(tǒng)一使用MPLS封裝轉(zhuǎn)發(fā)，而控制面的選擇經(jīng)過慎重考慮，我們詳細對比了SR/SR-TE和LDP/RSVP-TE后，最終選擇了SR/SR-TE，具體分析情況如下：

總結

本篇分享了數(shù)據(jù)中心野蠻式增長給MAN網(wǎng)絡和骨干網(wǎng)帶來的極大挑戰(zhàn)，以及SR部分技術原理。在過去幾年里，UCloud基礎網(wǎng)絡團隊不斷演進骨干網(wǎng)架構，從骨干網(wǎng)1.0升級到骨干網(wǎng)2.0架構，實現(xiàn)了用戶云下資源之間、云下到云上資源的快速開通，但依然滿足不了當前互聯(lián)網(wǎng)客戶的業(yè)務快速發(fā)展需求，例如：不支持智能流量調(diào)度、無法實現(xiàn)客戶L3VPN接入需求，不支持最后一公里Internet線路接入等。

下一篇將重點介紹UCloud如何結合Segment Routing技術實現(xiàn)智能、可靠、可調(diào)度的新一代骨干網(wǎng)，助力用戶分鐘級構建多地域全球網(wǎng)絡以及同城多可用區(qū)互訪、多Region多可用區(qū)互聯(lián)，實現(xiàn)UCloud與用戶線上線下IDC無間隔互通，升化云網(wǎng)協(xié)同。

本文作者：唐玉柱，UCloud 高級網(wǎng)絡架構師、UCloud新一代骨干網(wǎng)架構規(guī)劃項目負責人。擁有豐富的數(shù)據(jù)中心、骨干網(wǎng)架構設計和運維經(jīng)驗；目前主要負責UCloud全球數(shù)據(jù)中心、骨干網(wǎng)架構設備選型、架構設計和規(guī)劃。