1、 DOCPROPERTY PartNumber DOCPROPERTY Product&Project Name CloudFabric云數據中心網解決方案 DOCPROPERTY DocumentName 設計指南（業務鏈）目 錄 TOC h z t 標題 1,1,標題 2,2,標題 3,3, 標題 4,4, 標題 5,5, 標題 7,1, 標題 8,2, 標題 9,3, Heading1 No Number,1,Appendix heading 1,1,Appendix heading 2,2,Appendix heading 3,3,Appendix heading 4,4,Append

2、ix heading 5,5, Heading 1,1,Heading 2,2,Heading 3,3, Heading 4,4, Heading 5,5, Heading 7,1,Heading 8,2,Heading 9,3 HYPERLINK l _Toc55060086 1 CloudFabric業務鏈介紹 PAGEREF _Toc55060086 h 1 HYPERLINK l _Toc55060087 2 CloudFabric業務鏈應用場合 PAGEREF _Toc55060087 h 2 HYPERLINK l _Toc55060088 3 業務鏈模型 PAGEREF _Toc

3、55060088 h 4 HYPERLINK l _Toc55060089 3.1 業務鏈基本模型 PAGEREF _Toc55060089 h 4 HYPERLINK l _Toc55060090 3.2 業務鏈邏輯模型 PAGEREF _Toc55060090 h 5 HYPERLINK l _Toc55060091 3.3 業務鏈編排模型 PAGEREF _Toc55060091 h 5 HYPERLINK l _Toc55060092 3.3.1 PBR業務鏈編排模型 PAGEREF _Toc55060092 h 5 HYPERLINK l _Toc55060093 3.3.2 NSH

4、業務鏈編排模型 PAGEREF _Toc55060093 h 6 HYPERLINK l _Toc55060094 3.4 NSH協議介紹 PAGEREF _Toc55060094 h 7 HYPERLINK l _Toc55060095 3.5 PBR和NSH業務鏈對比 PAGEREF _Toc55060095 h 9 HYPERLINK l _Toc55060096 4 業務鏈方案架構 PAGEREF _Toc55060096 h 11 HYPERLINK l _Toc55060097 4.1 網絡虛擬化場景業務鏈方案架構 PAGEREF _Toc55060097 h 11 HYPERLI

5、NK l _Toc55060098 4.2 云網一體化場景業務鏈方案架構 PAGEREF _Toc55060098 h 12 HYPERLINK l _Toc55060099 5 業務鏈設計原則 PAGEREF _Toc55060099 h 13 HYPERLINK l _Toc55060100 5.1 業務鏈引流模型 PAGEREF _Toc55060100 h 13 HYPERLINK l _Toc55060101 5.1.1 Go-to引流模型 PAGEREF _Toc55060101 h 14 HYPERLINK l _Toc55060102 5.1.2 Go-through引流模型

6、PAGEREF _Toc55060102 h 14 HYPERLINK l _Toc55060103 5.1.3 One-Arm引流模型 PAGEREF _Toc55060103 h 15 HYPERLINK l _Toc55060104 5.2 VAS設備與Leaf設備連接設計 PAGEREF _Toc55060104 h 16 HYPERLINK l _Toc55060105 5.2.1 物理單臂設計模型 PAGEREF _Toc55060105 h 17 HYPERLINK l _Toc55060106 5.2.2 物理雙臂設計模型 PAGEREF _Toc55060106 h 18 H

7、YPERLINK l _Toc55060107 5.3 業務鏈高可用設計原則 PAGEREF _Toc55060107 h 18 HYPERLINK l _Toc55060108 5.3.1 VAS設備組高可用 PAGEREF _Toc55060108 h 18 HYPERLINK l _Toc55060109 5.3.2 設備和鏈路可靠性故障切換場景 PAGEREF _Toc55060109 h 20 HYPERLINK l _Toc55060110 6 CloudFabric基線組網 PAGEREF _Toc55060110 h 24 HYPERLINK l _Toc55060111 6.

8、1 Service Leaf和Border Leaf合設 PAGEREF _Toc55060111 h 24 HYPERLINK l _Toc55060112 6.2 Service Leaf和Border Leaf分設 PAGEREF _Toc55060112 h 26 HYPERLINK l _Toc55060113 7 業務鏈設計 PAGEREF _Toc55060113 h 28 HYPERLINK l _Toc55060114 7.1 參考拓撲 PAGEREF _Toc55060114 h 28 HYPERLINK l _Toc55060115 7.2 NSH業務鏈 PAGEREF

9、_Toc55060115 h 29 HYPERLINK l _Toc55060116 7.2.1 IPv4/IPv6 L2 VAS設計 PAGEREF _Toc55060116 h 29 HYPERLINK l _Toc55060117 7.2.2 IPv4/IPv6 L3 VAS設計（NSH-aware） PAGEREF _Toc55060117 h 29 HYPERLINK l _Toc55060118 7.2.3 IPv4/IPv6 L3 VAS設計（NSH-unaware） PAGEREF _Toc55060118 h 30 HYPERLINK l _Toc55060119 7.2.4

10、 南北向業務鏈設計 PAGEREF _Toc55060119 h 30 HYPERLINK l _Toc55060120 7.3 PBR業務鏈 PAGEREF _Toc55060120 h 32 HYPERLINK l _Toc55060121 7.3.1 IPv4/IPv6 L2 VAS設計 PAGEREF _Toc55060121 h 32 HYPERLINK l _Toc55060122 7.3.2 IPv4/IPv6 L3 VAS設計 PAGEREF _Toc55060122 h 33 HYPERLINK l _Toc55060123 7.3.3 南北向業務鏈設計 PAGEREF _T

11、oc55060123 h 34 HYPERLINK l _Toc55060124 8 業務鏈高可用 PAGEREF _Toc55060124 h 35 HYPERLINK l _Toc55060125 8.1 健康性檢測 PAGEREF _Toc55060125 h 35 HYPERLINK l _Toc55060126 8.2 業務鏈逃生 PAGEREF _Toc55060126 h 35 HYPERLINK l _Toc55060127 8.2.1 參考拓撲 PAGEREF _Toc55060127 h 36 HYPERLINK l _Toc55060128 8.2.2 NSH業務鏈逃生(

12、NSH-aware) PAGEREF _Toc55060128 h 36 HYPERLINK l _Toc55060129 8.2.3 PBR業務鏈逃生 PAGEREF _Toc55060129 h 37 HYPERLINK l _Toc55060130 A 參考圖片 PAGEREF _Toc55060130 h 38CloudFabric業務鏈介紹CloudFabric數據中心網絡（以下簡稱“CloudFabric”）解決方案旨在為客戶構筑簡單、智慧、開放的云數據網絡中心，廣泛應用于運營商私有云、公有云、電信云等場景，幫助客戶加速數字化轉型。CloudFabric解決方案中，“業務鏈”技術可

13、以在業務轉發路徑中插入“增值服務設備”（以下簡稱“VAS設備”，如防火墻、負載均衡、深度檢測、入侵防御等設備），對業務流量進行增值服務。通過CloudFabric業務鏈，可以將業務流量重定向到防火墻和負載均衡等VAS設備，而無需VAS設備作為網關。通過CloudFabric業務鏈，可以有選擇的將流量轉發到VAS設備。通過CloudFabric業務鏈，VAS設備可以無需修改已有拓撲的方式插入CloudFabric。通過CloudFabric業務鏈，可以快速的橫向擴展VAS設備。CloudFabric解決方案業務鏈是一種有序的業務功能集，可以保證被選擇的流量有序的獲取增值服務。CloudFabri

14、c解決方案可以將網絡與增值業務統一部署，也可以分開部署，這取決于增值業務設備管理平臺和“iMaster NCE-Fabric”（CloudFabric解決方案的核心組件，實現對云數據中心網絡的統一管控和動態調度、自動化部署和彈性擴縮容，以下簡稱“控制器”）的對接程度。CloudFabric業務鏈應用場合業務鏈具備設備品牌多，功能復雜，引流形式多樣等特性，由于CloudFabric解決方案本身不提供VAS設備，所以需要根據控制器是否可以管理VAS設備，決定業務鏈模式。業界通常支持如下三種管理業務鏈模式：Service Policy模式：控制器負責Fabric和VAS設備之間互聯L2L3層網絡的編

15、排，并負責VAS設備所有L2L3層網絡編排和L4L7業務策略下發。Service Policy模式依賴控制器對接VAS設備（或其管理平臺）的能力，VAS設備整體被包含在CloudFabric解決方案中，VAS設備L2L7層業務編排屬于CloudFabric基礎框架的一部分。Service Manager模式：控制器負責Fabric和VAS設備之間互聯L2L3層網絡的編排，由第三方VAS設備管理平臺負責VAS設備L4L7層業務策略下發。Service Manager模式依賴控制器對接VAS設備（或其管理平臺）的能力，VAS設備部分業務被包含在CloudFabirc解決方案，VAS設備L2L3層業

16、務編排屬于CloudFabric基礎框架的一部分。Network Policy模式：控制器只負責Fabric側L2L3層網絡的編排，VAS設備L2L7層網絡和業務編排不在控制器管理范圍內。Network Policy模式不依賴控制器對接VAS設備（或其管理平臺）的能力，VAS設備整體被隔離CloudFabirc解決方案之外，VAS設備的L2L7業務編排依靠其第三方管理平臺或設備本身。華為CloudFabric解決方案中，目前三種業務鏈模式支持情況如下：Service Policy模式支持HW FWService Manager模式僅支持CheckPoint FW，Fortinet FW，Pal

17、oalto FW，F5 LB等VAS設備Network Policy模式支持其他第三方VAS設備在選用業務鏈模式時，需要考慮以下幾點：業務鏈配置是否會反復變更，變更業務鏈引流策略還是變更VAS設備業務配置？控制器是否可以管理VAS設備網絡和業務配置？業務鏈相關配置是否有專門業務管理員維護，還是由網絡管理員統一編排？帶著這些問題，結合下圖，可以找到適合的業務鏈模型。業務鏈模式的選擇指引業務鏈模型 HYPERLINK l _ZH-CN_TOPIC_0211121285 o 3.1 業務鏈基本模型 HYPERLINK l _ZH-CN_TOPIC_0211121286 o 3.2 業務鏈邏輯模型 H

18、YPERLINK l _ZH-CN_TOPIC_0211121287 o 3.3 業務鏈編排模型 HYPERLINK l _ZH-CN_TOPIC_0211122988 o 3.4 NSH協議介紹 HYPERLINK l _ZH-CN_TOPIC_0211124720 o 3.5 PBR和NSH業務鏈對比業務鏈基本模型業務鏈的基本概念模型如下圖所示。業務鏈基本概念EPG：可以基于externalNetwork、logic switch、logic Router定義，最小粒度為IP網段（subnet）。Policy rule set：策略規則集合，定義組間多個訪問控制策略規則。Policy ru

19、le：一條規則，代表一類業務流量和對應的業務鏈行為。Classifer：流分類器，支持基于五元組+TCP-flag/ICMP-type對流量進行分類。Action：規則中定義的的流動作，支持permit/deny/redirect。SFP：對應業務鏈的路徑，定義路徑包含VAS設備的數量、類型和經過VAS設備的順序，目前CloudFabric解決方案當前一條PBR方式SFP中最多可定義3個VAS設備。業務鏈邏輯模型業務鏈的基礎邏輯模型如下圖所示。業務鏈邏輯模型業務鏈邏輯模型中涉及到的幾個角色介紹如下。SC （Service Classifier，業務分類節點）：實現業務流識別（選擇流量重定向到業

20、務鏈）。SF （Service Function，業務功能節點） ：提供增值服務功能的節點，即VAS設備。SFF （Service Function Forwarder，業務轉發節點）：連接SF節點的交換機，可以識別要經過業務鏈的業務流量，轉發至SF節點。還可以識別SF節點處理后的業務流量，繼續重定向到后續業務鏈流程。業務鏈編排模型PBR業務鏈編排模型PBR類型的業務鏈的編排模型和業務過程如下圖所示。PBR業務鏈編排模型控制器向SC節點下發過濾和重定向策略，選擇性的將業務流量重定向到SF1，PBR方式不改變CONSUMER訪問PROVIDER的業務報文。控制器向SFF1節點下發隧道側和用戶側過

21、濾和重定向策略，SFF1節點選擇性將業務流量牽引至SF1、SF2。控制器向SFF2節點下發隧道側過濾和重定向策略，SFF2節點選擇性將業務流量牽引至SF3，最后將業務報文轉發給PROVIDER。NSH業務鏈編排模型NSH類型的業務鏈的編排模型和業務過程如下圖所示。NSH業務鏈編排模型控制器向SC節點下發過濾和重定向策略，選擇性將業務流量牽引至NSH轉發路徑，NSH方式會改變CONSUMER訪問PROVIDER的原始報文。控制器向SC節點和SFF節點下發NSH轉發表，牽引業務流量按照SFP路徑轉發。若SF是NSH-unaware類型，控制器還需要在SFF節點下發NSH代理配置（剝離NSH頭部轉發

22、），同時還需要下發過濾和重定向策略將經過SF處理的流量重新牽引至NSH轉發路徑。若SF是NSH-aware類型，控制器不需要在SFF節點下發NSH代理配置，SF節點處理業務流量時，會自行處理業務報文中NSH頭部字段且不會剝離NSH頭部。NSH協議介紹ITEF定義了一種新的數據面業務封裝格式NSH（Network Service Header），封裝頭包括業務路徑和MetaData信息等，使得業務鏈路徑上的各個節點能夠相互傳遞路徑信息，從而構建一個新業務平面，實現業務鏈可以對數據做動態靈活的策略處理。NSH協議標準可以參考RFC8300。承載NSH報文的網絡報文格式，如下所示。承載網為VxLAN

23、的NSH報文封裝格式如下圖所示：承載網為VLAN的NSH報文封裝格式如下圖所示：其中NSH header頭部格式如下所示。當MD Type值為0 x1時，報文格式如下：當MD Type值為0 x2時，報文格式如下：具體字段含義，請參考REF _table14861184813717 r h表3-1NSH報文格式中各個字段的說明字段描述VerNSH版本號當前支持版本號為0ONSH報文類型0：表示數據報文1：表示OAM維護報文U保留字段發送時NSH報文保留字段置0，接收NSH報文時忽略此字段TTL用于防環，默認值為63初始TTL值應該可以被控制面配置，一個TTL值可以被用在多個SFP每個SFF在轉

24、發NSH報文時，需要將TTL值減1后再查找NSH轉發表當TTL值減1后為0時，丟棄該NSH報文LengthNSH報文的總長度，該項的值代表4字節的整倍數如果MD type值為1，則Length必須是6，表示NSH報文長度位6*4字節如果MD type是2，則Length必須大于或等于2MD type（MetaData type）元數據域的格式類型0：保留值，暫不使用1：表示元數據域為固定長度16字節2：表示元數據域為可變長度。F：僅測試或實驗階段可以使用當前設備支持的MD類型為1Next ProtocolNSH封裝前的報文類型0 x1：IPv4報文0 x2：IPv6報文0 x3：Etherne

25、t報文0 x4：NSH報文0 x5：MPLS報文0 x60 xFD：未定義0 xFE0 xFF：Experimental當前設備僅支持IPv4報文SPI業務鏈路徑編號用于唯一標識一條業務鏈路徑SI業務功能索引用于標識SF節點在SFP中的位置Context Header元數據域當MD Type值為0 x0時，Context Header長度必須為0（基本不用）當MD Type值為0 x1時，Context Header固定長度為16字節當MD Type值為0 x2時，Context Header為變長字段，長度必須為4的整數倍PBR和NSH業務鏈對比PBR和NSH兩種業務鏈業務的對比參見下表。P

26、BR和NSH的對比對比點PBR業務鏈NSH業務鏈（NSH-aware）基本特點PBR業務鏈不需要改變原始報文（優）NSH業務鏈需要改變原始報文地址變換VAS（NAT和LB）NAT難度在于控制器編排和來回路徑NSH轉發平面可以減少NAT編排難度（優）MetaData信息不支持支持（優）Fabric設備要求無兼容性需求（優）有兼容性需求VAS設備要求無需求（優）需支持NSH需求業務鏈防環無防環能力（cisco能防環）無環（優）帶寬資源占用不增加協議頭部（優）增加協議頭部VAS節點規格受限ACL資源，IPv4最多3跳業務鏈受限ACL資源，IPv6最多1跳業務鏈最大支持255（優）單特性轉發轉發性能下

27、降不明顯（優）轉發性能下降明顯Bypass能力無Bypass能力（當SF為L3類型時，單跳業務鏈自帶逃生）當SF為L3類型時，支持逃生（優）流量可視無需適配（優）流量可視軟件支持NSH協議ACL資源消耗需要每跳用戶側或網絡側匹配只在SC節點匹配ACL，其他節點不消耗（優）NSH業務鏈只有當VAS設備支持NSH協議，對比PBR業務鏈才會具備明顯的優勢。目前華為NSH協議生態，包含廠商：迪普FW（雙棧）和山石FW （雙棧） ，其他3rd VAS設備作為NSH-unware引流。若對業務鏈需求高性能轉發，則推薦PBR業務鏈；若要求業務鏈組網豐富，則推薦NSH業務鏈。業務鏈方案架構 HYPERLINK

28、 l _ZH-CN_TOPIC_0211129258 o 4.1 網絡虛擬化場景業務鏈方案架構 HYPERLINK l _ZH-CN_TOPIC_0211129259 o 4.2 云網一體化場景業務鏈方案架構網絡虛擬化場景業務鏈方案架構如REF _fig1212333811528 r h圖4-1所示，在網絡虛擬化場景下，業務鏈的架構中各個組件的功能如下。網絡虛擬化中的SFC方案架構iMaster NCE-Fabric：實現租戶業務和編排，發放VPC/vRouter/Subnet等服務管理華為CE交換機L2/L3 Fabric網絡編排業務鏈路徑和引流策略負責華為VAS設備和L2/L3 Fabri

29、c雙向網絡開通和業務配置負責到第三方VAS的L2/L3 Fabric側的網絡開通SecoManager：管理華為VAS設備，控制器下發華為VAS設備業務配置至Seco ManagerHuawei VAS：華為VAS設備，提供FW、LB、IPS、EIP、SNAT、IPSec VPN等業務的實體3rd VAS：第三方VAS設備，提供FW、LB、IPS、EIP、SNAT、IPSec VPN等業務的實體3rd SF業務Portal：管理第三方VAS設備，開通相關業務和VAS設備側網絡云網一體化場景業務鏈方案架構如REF _fig1114018475540 r h圖4-2所示，在云網一體化場景下，業務鏈

30、的架構中各個組件的功能如下。云網一體化中的SFC方案架構OpenStack：實現租戶業務和編排，發放VPC/vRouter/Subnet等服務iMaster NCE-Fabric：實現租戶業務和編排，發放VPC/vRouter/Subnet等服務管理華為CE交換機L2/L3 Fabric網絡還原OpenStack網絡，二次編排業務鏈路徑和引流策略負責華為VAS設備和L2/L3 Fabric雙向網絡開通和業務配置負責到第三方VAS的L2/L3 Fabric側的網絡開通Seco Manager：管理華為VAS設備，VAS設備相關業務在Seco Manager編排配置Huawei VAS：華為VAS

31、設備，提供FW、EIP、SNAT、IPSec VPN等業務的實體3rd VAS：第三方VAS設備，提供FW、LB、IPS等業務的實體3rd SF業務Portal：管理第三方VAS設備，開通相關業務和VAS設備側L2/L3網絡業務鏈設計原則 HYPERLINK l _ZH-CN_TOPIC_0206741996 o 5.1 業務鏈引流模型 HYPERLINK l _ZH-CN_TOPIC_0206744181 o 5.2 VAS設備與Leaf設備連接設計 HYPERLINK l _ZH-CN_TOPIC_0213525378 o 5.3 業務鏈高可用設計原則業務鏈引流模型業務鏈的核心能力在于引流

32、，如何正確、均勻的將業務流量牽引至VAS設備是業務鏈的核心功能。在CloudFabric解決方案中，不同類型的VAS設備，引流方式有所不同。VAS設備類型總體來講，可以分為三種，分別為：L1類型設備、L2類型設備和L3類型設備。L1、L2和L3類型設備具體定義如下：L1類型設備無VLAN轉換能力所有的設備接口均屬于同一個VLAN業務流量經過設備不會二層或三層轉發通常采用接口對的形式，從一個接口進，從另一個接口出L2類型設備具備VLAN轉換能力設備接口VLAN可配置，不同接口可以配置不同VLAN業務流量經過設備會二層轉發設備接口具備MAC學習能力L3類型設備具備VLAN轉換能力設備接口VLAN可

33、配置，不同接口可以配置不同VLAN業務流量經過設備會三層轉發設備接口具備MAC學習能力不同類型VAS設備對應不同的引流方式。L1/L2類型VAS設備本身無IP地址，需要通過Go-through方式引流；而L3類型VAS設備本身可以配置IP地址，通過Go-to方式引流。Go-to引流模型參考下圖，Go-to引流模型分為兩種情況：業務鏈VAS設備直接作為consumer的網關（CloudFabric當前方案暫不支持）。網絡設備BD接口地址作為consumer的網關，通過業務鏈重定向的方式將業務流量重定向到VAS設備。Go-to引流模型如下圖所示。Go-to引流模型示意圖consumer訪問prov

34、ider的流量會在Leaf設備重定向到VAS設備IP，由VAS設備通過靜態路由將業務流量處理后再轉發給Leaf設備，由Leaf設備繼續重定向或轉發給provider。在此引流模型中，一個VRF關聯兩個Bridge-Domain，兩者關系圖如下所示。兩個BD之間的關系示意圖Go-through引流模型參考下圖，Go-through引流模型指VAS設備橋接在consumer和provider之間，VAS設備本身不具備IP地址，流量不會在VAS設備L2/L3轉發。在CloudFabric解決方案中，需要業務流量重定向到L1/L2類型VAS設備時，通常采用Go-through引流模式部署業務鏈。Go-

35、through引流模式基本模型，如下圖所示。Go-through引流模型Consumer訪問provider的流量會在Leaf設備重定向到VAS設備，VRFA接口轉發業務報文的目的MAC為VRFB接口地址MAC。L1類型VAS設備會將業務報文直接與入接口同接口對的另一接口轉發；L2類型VAS設備會將業務報文二層轉發。在此引流模型，兩個VRF分別關聯一個Bridge-Domian，兩者關系圖如下所示。兩個VRF之間的關系示意圖One-Arm引流模型參考下圖，One-Arm模型指VAS設備和Leaf之間通過邏輯單臂互聯，指業務流量通過一個邏輯接口轉發。需要VAS設備支持此種引流模型。當前Cloud

36、Fabric解決方案中，同VPC內業務鏈通常采用這種業務鏈模型。One-Arm引流模型如下圖所示。One-Arm引流模型Consumer訪問provider的業務流量會在Leaf設備重定向到VAS設備，VAS設備轉發此業務流量給Leaf設備時，通過入接口轉發流量（需要VAS設備支持）。在此引流模型中，一個VRF關聯1個Bridge-Domain，兩者關系圖如下所示。VRF、BD間關系示意圖VAS設備與Leaf設備連接設計數據中心網絡中VAS設備和Leaf設備連接方式多種多樣，為了方便CloudFabric統一管理和編排，規劃了VAS設備與Leaf設備連接方法。VAS設備與Leaf互聯鏈路需要區

37、分鏈路角色，不同鏈路角色承載的流量不同。鏈路角色分為“內部鏈路”和“外部鏈路”。“內部鏈路”表示該鏈路只承載租戶router與租戶vsys的流量，“外部鏈路”表示該鏈路只承載外部網絡與ExtranetVsys的流量，“內外部鏈路”表示該物理鏈路既承載租戶router與租戶vsys的流量也承載外部網絡與ExtranetVsys的流量，租戶vsys和ExtranetVsys之間內部會進行路由轉發，從而實現租戶router和外部網絡的流量互通。若設定VAS與Leaf互聯物理鏈路角色為“內部鏈路”，則單臺VAS設備與M-LAG Leaf組通過一對子接口互通（承載在互聯鏈路上），此時為邏輯單臂。若設定V

38、AS與Leaf互聯物理鏈路角色為“內外部鏈路”，則單臺VAS設備與M-LAG Leaf組通過兩對子接口互通（承載在互聯鏈路上），此時為邏輯雙臂。若設定VAS與Leaf互聯物理鏈路角色分別為“內部鏈路”和“外部鏈路”，則單臺VAS設備與M-LAG Leaf組通過兩對子接口互通（承載在互聯鏈路上），此時為邏輯雙臂。其中，物理單臂、物理雙臂的說明如下：當邏輯單臂或邏輯雙臂由一條物理鏈路承載（一條單鏈路或聚合鏈路），為物理單臂。當邏輯雙臂由兩條物理鏈路承載（兩條單鏈路或聚合鏈路），為物理雙臂。同VPC內東西向業務鏈，當前版本推薦物理單臂配合邏輯單臂。南北向業務鏈，當前版本支持物理單臂配合邏輯雙臂和物理

39、雙臂配合邏輯雙臂方式實現。物理單臂設計模型物理單臂可以包含邏輯單臂和邏輯雙臂兩種模型，如下：邏輯單臂組網：VAS組成員設備與Leaf設備組（M-LAG）通過聚合鏈路互聯，consumer和provider之間業務鏈通過內部鏈路轉發報文。主設備和備設備都存在一條邏輯鏈路，當主設備邏輯鏈路故障，備設備邏輯鏈路生效（可靠性高）。邏輯單臂組網示意圖邏輯雙臂組網：VAS組成員設備與Leaf設備組（M-LAG）通過聚合鏈路互聯，主設備和備設備通過聚合鏈路與Leaf設備組互聯，consumer和provider之間業務鏈通過兩條邏輯鏈路轉發報文。主設備和備設備都存在兩條邏輯鏈路，當主設備物理鏈路故障，備設備

40、物理鏈路生效（可靠性高）。邏輯雙臂組網示意圖物理雙臂設計模型物理雙臂僅包含邏輯雙臂一種模型：VAS設備組與Leaf設備組（M-LAG）通過兩條聚合鏈路互聯，邏輯鏈路被承載在不同的聚合鏈路（可靠性高）。下圖備VAS備設備與主設備接線方式一致，防止圖片畫線過多，故省略。物理雙臂組網示意圖業務鏈高可用設計原則CloudFabric業務鏈高可用可以從兩個維度闡明：VAS設備高可靠和業務鏈路徑高可靠（SC節點、SFF節點），如下表所示。項目VAS設備可靠性SC節點可靠性SFF節點可靠性冗余方式主備/主備鏡像/負載分擔MLAG雙活MLAG雙活故障檢測方式VAS設備之間心跳線MLAG雙主心跳檢測MLAG雙主

41、心跳檢測故障切換方法VAS設備主動切換BGP收斂BGP收斂VAS設備組高可用VAS設備高可用，可以通過主備、主備鏡像、負載分擔等方式實現。主備：VAS設備組成員統一通過VIP地址對外提供服務，成員間通過參數比較選出主成員，主成員負責所有業務處理，將配置同步給備成員，備成員隨時準備接替主成員（當前版本不支持）主備鏡像：VAS設備組成員統一通過VIP地址對外提供服務，成員間通過參數比較選出主成員，主成員負責所有業務處理，將配置和會話同步給備成員，備成員隨時準備接替主成員負載分擔：VAS設備組成員統一通過VIP地址對外提供服務，成員均對外提供服務，配置會下發給所有成員（當前版本不支持）通常通過VAS

42、集群提供以上高可用功能，集群會配置一個VIP（不同廠商稱呼不同，還有類似Virtual IP等稱呼，華為iMaster NCE-Fabric中稱作shareIP）統一對外提供服務。主備鏡像高可用連接方案主備集群VAS設備組成員通過M-LAG聚合鏈路與Leaf設備組互聯，VAS設備組成員間通過直連鏈路檢測成員心跳和配置同步，Leaf設備組之間通過peer-link鏈路和心跳鏈路實現設備同步表項和雙活。Leaf設備組統一對外提供相同的VTEP IP地址，VAS設備組成員統一對外提供相同的VIP地址，Leaf設備組下發多條目的為VIP的靜態路由，靜態路由對應的nexthop分別指向VAS設備組成員，

43、VAS設備組成員主備通過靜態路由優先級體現。VAS設備組（主備/主備鏡像）高可用連接方案如下圖所示。主備/主備鏡像高可用連接示意圖負載分擔高可用連接方案負載分擔集群VAS設備組成員通過M-LAG聚合鏈路與Leaf設備組互聯，VAS設備組成員間通過直連鏈路檢測成員心跳和配置同步，Leaf設備組之間通過peer-link鏈路和心跳鏈路實現設備雙活和同步表項。Leaf設備組統一對外提供相同的VTEP IP地址，VAS設備組成員統一對外提供相同的VIP地址，控制器為Leaf設備組下發多條目的為VIP的靜態路由，靜態路由對應的nexthop分別指向VAS設備組成員，靜態路由無需配置優先級，通過ECMP實

44、現負載分擔。負載分擔對往返路徑一致性有要求，所以正向流量和反向流量在hash時應忽略方向性。VAS設備（負載分擔）高可用連接方案如下圖所示。負載分擔高可用連接示意圖設備和鏈路可靠性故障切換場景上述高可用方案可以覆蓋鏈路故障場景和設備故障場景。主備鏡像VAS組正常業務，任意一臺Leaf設備組成員都可以將業務流量本地轉發到VAS設備組主成員。正常時的流量轉發當Leaf設備與VAS組主成員鏈路故障時，業務流量可以從MLAG成員設備通過peerlink鏈路轉發到另一個MLAG成員設備，再轉發到VAS組主成員。Leaf與VAS組主成員鏈路故障時的流量轉發當VAS組主成員故障時，Leaf設備組從VAS組備

45、成員學習到VAS組VIP的MAC，后續流量轉發給VAS組備成員。VAS組主成員故障時的流量轉發負載均衡模式VAS組（當前版本不支持）正常業務，任意一臺Leaf設備組成員都可以將業務流量本地轉發到VAS設備組所有成員。正常時的流量轉發當Leaf設備與某個VAS成員鏈路故障時，業務流量可以從M-LAG成員設備通過peerl-ink鏈路轉發到另一個MLAG成員設備，再轉發到VAS設備。Leaf與VAS組某個成員部分鏈路故障時的流量轉發當某個VAS設備故障時，Leaf設備組會收斂下一跳為故障VAS設備的VIP靜態路由，其他成員的靜態路由無影響。VAS組某個成員故障時的流量轉發CloudFabric基線

46、組網在目前CloudFabric基線組網中，業務鏈能力局限在VPC內，應用場景共3種：外網和VPC通過業務鏈互訪：業務鏈支持路徑包含VAS設備或不包含VAS設備，不過VAS設備時由交換機實現業務隔離。VPC內不同子網通過業務鏈互訪：業務鏈支持路徑包含VAS設備或不包含VAS設備，不過VAS設備時由交換機實現業務隔離。VPC內同子網通過業務鏈互訪：業務鏈將流量牽引至VAS設備進行安全控制，Network Overlay網絡虛擬化組網需要虛擬交換機（VMware&Microsoft）通過PVLAN，將流量牽引至交換機，通過交換機業務鏈按需隔離 HYPERLINK l _ZH-CN_TOPIC_02

47、06742515 o 6.1 Service Leaf和Border Leaf合設 HYPERLINK l _ZH-CN_TOPIC_0206742516 o 6.2 Service Leaf和Border Leaf分設Service Leaf和Border Leaf合設Service Leaf和Border Leaf合設的組網基線如下圖所示。Service Leaf和Border Leaf合設的組網示意圖本章業務鏈的3種應用場景，控制器將重定向策略在源端Server Leaf下發，將業務流量牽引至VAS設備處理，南北向業務鏈最后一跳VAS設備通過靜態路由的方式轉發業務流量，對應轉發邏輯如下圖

48、所示。南北向業務鏈轉發路徑示意圖Service Leaf和Border Leaf分設Service Leaf和Border Leaf分設的組網基線如下圖所示。Service Leaf和Border Leaf分設的組網示意圖業務鏈的3種應用場景，重定向策略在源端Server Leaf下發，將業務流量牽引至VAS設備處理（同子網與不同子網引流類似，不予贅述），南北向業務鏈最后一跳VAS設備通過路由引流的方式轉發業務流量，對應轉發邏輯如下圖所示。南北向業務鏈轉發路徑示意圖業務鏈設計 HYPERLINK l _ZH-CN_TOPIC_0214647087 o 7.1 參考拓撲 HYPERLINK l

49、_ZH-CN_TOPIC_0214647088 o 7.2 NSH業務鏈 HYPERLINK l _ZH-CN_TOPIC_0214647113 o 7.3 PBR業務鏈參考拓撲如下圖所示，是業務鏈設計舉例參考拓撲圖。業務鏈設計舉例參考拓撲圖Network Overlay 網絡虛擬化組網VM1、VM2、VM3均是同VPC虛機SF1、SF2、SF3是東西向業務鏈SF節點SF4是南北向業務鏈SF節點假定租戶VRF名稱為Tenant_VRFNSH業務鏈IPv4/IPv6 L2 VAS設計暫不支持IPv4/IPv6 L3 VAS設計（NSH-aware）東西向NSH業務鏈L3類型SF配置模型如下圖所示

50、。東西向NSH業務鏈L3類型SF配置模型VM1-VM3業務鏈方案（VM3-VM1引流類似，不予贅述）：ServerLeaf1配置MQC重定向策略到vbdif1，vbdif是VM1上線對應的邏輯口，將業務流量牽引至NSH轉發平面，通過NSH轉發平面，將業務流量轉發至ServiceLeaf1；ServiceLeaf1全局下發NSH轉發表，業務流量按照NSH報文頭部信息轉發至SF1、SF2節點，SF1和SF2節點支持NSH協議，每經過一個SF節點，SI值減1；ServiceLeaf2全局下發NSH轉發表，業務流量按照NSH報文頭部信息轉發至SF3節點，最后由ServiceLeaf2剝離NSH頭部，通

51、過自然轉發至VM3。IPv4/IPv6 L3 VAS設計（NSH-unaware）東西向NSH業務鏈L3類型SF配置模型如下圖所示。東西向NSH業務鏈L3類型SF配置模型VM1-VM3業務鏈方案（VM3-VM1引流類似，不予贅述）：ServerLeaf1配置MQC重定向策略到vbdif1，vbdif是VM1上線對應的邏輯口，通過策略將業務流量牽引至NSH轉發平面，通過NSH轉發平面，將業務流量轉發至ServiceLeaf1；ServiceLeaf1全局下發NSH轉發表，業務流量按照NSH報文頭部信息轉發至SF1節點，由于SF1節點為NSH-unaware類型所以轉發前需要將NSH報文頭部剝離后

52、轉發到SF1節點；SF1節點對流量處理完畢后，入ServiceLeaf1時需要重新MQC引流，將業務流量重新牽引至NSH轉發平面，ServiceLeaf1繼續按照NSH轉發表轉發業務流量；ServiceLeaf2全局下發NSH轉發表，業務流量按照NSH報文頭部信息轉發至SF2節點，由于SF2節點為NSH-unaware類型所以轉發前需要將NSH報文頭部剝離后轉發到SF2節點；SF2節點增值業務處理完畢后，入ServiceLeaf2時需要重新MQC引流，將業務流量重新牽引至NSH轉發平面，ServiceLeaf2會剝離NSH報文頭部信息自然轉發業務流量至VM3。南北向業務鏈設計NSH業務鏈，南北

53、向最后一跳必須按照NSH-unaware類型SF節點處理，南北向NSH業務鏈SF配置模型如下圖所示。南北向NSH業務鏈SF配置模型（由內網到外網）VM1-External Network引流要點：ServerLeaf配置重定向策略到vbdif1(vbdif1是VM1上線對應的邏輯口)，將業務流量牽引至NSH轉發平面，通過NSH轉發平面，將業務流量重定向至ServiceLeaf1；ServiceLeaf1全局下發NSH轉發表，業務流量按照NSH報文頭部信息轉發至SF1節點，SF1節點支持NSH協議，經過SF1節點，SI值減1；ServiceLeaf&BorderLeaf全局下發NSH轉發表，業務

54、流量按照NSH報文頭部信息轉發至SF2節點，無論SF2節點類型，ServiceLeaf&BorderLeaf均按NSH-unaware轉發業務流量。南北向NSH業務鏈SF配置模型（由外到內）External Network-VM1引流要點：External Network流量在ServiceLeaf&BorderLeaf的External_VRF自然轉發給SF2，SF2在通過自然轉發給ServiceLeaf&BorderLeaf；在ServiceLeaf&BorderLeaf的Tenant_VRF的vbdif2(vbdif2是SF2與ServiceLeaf&BorderLeaf互聯的邏輯接口)

55、接口配置重定向策略，將業務流量牽引至NSH轉發平面，通過NSH轉發平面，將業務流量重定向至ServiceLeaf1；ServiceLeaf1全局下發NSH轉發表，業務流量按照NSH header轉發至SF1節點（SF1節點支持NSH協議，經過SF1節點，SI值減1）；SF1節點轉發給ServiceLeaf1后重新根據NSH報文頭部信息，匹配service-index 254轉發條目，剝離NSH頭部自然轉發到ServerLeaf1；ServerLeaf1自然轉發到VM1。PBR業務鏈IPv4/IPv6 L2 VAS設計IPv4 PBR業務鏈支持L2 VAS，IPv6 PBR業務鏈暫不支持。東西向

56、PBR業務鏈(支持源目EPG為網段)L2類型SF配置模型如下圖所示。東西向PBR業務鏈(支持同網段)L2類型SF配置模型VM1-VM3業務鏈方案（VM3-VM1引流類似，不予贅述）：IP1、IP2、IP3、IP4屬于同網段，ServiceLeaf1和ServiceLeaf2配置VRF1和VRF2，用于對L2類型SF引流；ServerLeaf1配置PBR重定向策略到vbdif1，將業務流量牽引至租戶VRF的IP2地址；ServiceLeaf1在租戶VRF中配置IP2的靜態路由（ip route-static tenant_vrf IP2 32 nexthop vrf1 IP2），通過EVPN t

57、ype5路由發布到全網。VRF2配置默認路由將業務流量牽引回租戶VRF；ServiceLeaf1配置PBR重定向策略到全局和vbdif2，全局PBR重定向策略用于匹配隧道側流量（需結合VxLAN VNI）并重定向到tenant_vrf IP2，并迭代出去往tenant_vrf IP2的具體目的MAC和出接口。vbdif2業務鏈策略將業務流量重定向到IP4，通過VRF2配置的靜態路由迭代，將業務流量牽引至租戶VRF業務平面，重定向到遠端IP4；ServiceLeaf2在租戶VRF中配置IP4的靜態路由（ip route-static tenant_vrf IP4 32 nexthop vrf1

58、IP4），通過EVPN type5路由發布到全網。VRF2下發默認路由將業務流量牽引回租戶VRF；ServiceLeaf2配置PBR重定向策略到全局，全局業務鏈策略用于匹配隧道側流量（需結合VxLAN VNI）并重定向到tenant_vrf IP4，tenant_vrf IP4可以通過靜態路由迭代出目的MAC和出接口。vbdif2接口屬于VRF2，通過VRF2配置的靜態路由迭代（ip route-static vrf2 0.0.0.0 0 tenant_vrf）將業務流量牽引至租戶VRF業務平面，自然轉發到VM3。IPv4/IPv6 L3 VAS設計IPv6 PBR業務鏈僅支持permit和d

59、eny動作，不支持redirect動作，IPv4 PBR業務鏈最多3跳。東西向PBR業務鏈L3類型SF邏輯模型如下圖所示。東西向PBR業務鏈L3類型SF邏輯模型VM1-VM3業務鏈方案（VM3-VM1引流類似，不予贅述）：ServerLeaf1配置PBR重定向策略到vbdif1，vbdif是VM1上線對應的邏輯口，將業務流量牽引至SF1節點；ServiceLeaf1配置PBR重定向策略到全局、vbdif1、vbdif2，全局業務鏈策略用于匹配隧道側流量（需結合VxLAN VNI）并重定向到SF1節點，vbdif1和vbdif2業務鏈策略分別將SF1和SF2處理后的業務流量牽引至下一跳SF節點；ServiceLeaf2配置PBR重定向策略到全局，全局業務鏈策略用于匹配隧道側流量（需結合VxLAN VNI）并重定向到SF3節點，SF3節點處理后，業務流量由ServiceLeaf2轉發到VM3；PBR業務鏈重定向到本地下一跳時，traffic behavior動作為redirect ne