CloudFabric云數(shù)據(jù)中心網(wǎng)解決方案業(yè)務(wù)鏈設(shè)計指南

1、CloudFabric云數(shù)據(jù)中心網(wǎng)解決方案設(shè)計指南（業(yè)務(wù)鏈）o TOC o 1-5 h z HYPERLINK l bookmark0 o Current Document h CloudFabric 業(yè)務(wù)鏈介紹1 HYPERLINK l bookmark2 o Current Document h CloudFabric 業(yè)務(wù)鏈應(yīng)用場合23業(yè)務(wù)鏈模型4 HYPERLINK l bookmark4 o Current Document h 3.1業(yè)務(wù)鏈基本模型4 HYPERLINK l bookmark6 o Current Document h 3.2業(yè)務(wù)鏈邏輯模型5 HYPERLINK l

2、 bookmark8 o Current Document h 3.3業(yè)務(wù)鏈編排模型5 HYPERLINK l bookmark10 o Current Document h PBR業(yè)務(wù)鏈編排模型5 HYPERLINK l bookmark12 o Current Document h NSH業(yè)務(wù)鏈編排模型6 HYPERLINK l bookmark14 o Current Document h NSH協(xié)議介紹7 HYPERLINK l bookmark22 o Current Document h PBR和NSH業(yè)務(wù)鏈對比94業(yè)務(wù)鏈方案架構(gòu)11 HYPERLINK l bookmark24

3、o Current Document h 4.1網(wǎng)絡(luò)虛擬化場景業(yè)務(wù)鏈方案架構(gòu)11 HYPERLINK l bookmark26 o Current Document h 4.2云網(wǎng)一體化場景業(yè)務(wù)鏈方案架構(gòu)125業(yè)務(wù)鏈設(shè)計原則13 HYPERLINK l bookmark28 o Current Document h 5.1業(yè)務(wù)鏈引流模型13 HYPERLINK l bookmark30 o Current Document h Go-to 引流模型14 HYPERLINK l bookmark32 o Current Document h Go-through 弓丨流模型15 HYPERLIN

4、K l bookmark34 o Current Document h One-Arm 引流模型15 HYPERLINK l bookmark36 o Current Document h 5.2 VAS設(shè)備與Leaf設(shè)備連接設(shè)計16 HYPERLINK l bookmark38 o Current Document h 5.2.1物理單臂設(shè)計模型17 HYPERLINK l bookmark40 o Current Document h 5.2.2物理雙臂設(shè)計模型18 HYPERLINK l bookmark42 o Current Document h 5.3業(yè)務(wù)鏈高可用設(shè)計原則18 HY

5、PERLINK l bookmark44 o Current Document h VAS設(shè)備組高可用18 HYPERLINK l bookmark54 o Current Document h 5.3.2設(shè)備和鏈路可靠性故障切換場景206 CloudFabric 基線組網(wǎng)24 HYPERLINK l bookmark94 o Current Document h Service Leaf 和 Border Leaf 合設(shè)24 HYPERLINK l bookmark96 o Current Document h Service Leaf 和 Border Leaf 分設(shè)267業(yè)務(wù)鏈設(shè)計28

6、HYPERLINK l bookmark98 o Current Document h 7.1參考拓撲28 HYPERLINK l bookmark102 o Current Document h NSH業(yè)務(wù)鏈29 HYPERLINK l bookmark104 o Current Document h IPv4/IPv6 L2 VAS 設(shè)計29 HYPERLINK l bookmark106 o Current Document h IPv4/IPv6 L3 VAS 設(shè)計(NSH-aware) 29 HYPERLINK l bookmark108 o Current Document h I

7、Pv4/IPv6 L3 VAS 設(shè)計(NSH-unaware) 30 HYPERLINK l bookmark110 o Current Document h 7.2.4南北向業(yè)務(wù)鏈設(shè)計30 HYPERLINK l bookmark112 o Current Document h PBR業(yè)務(wù)鏈32 HYPERLINK l bookmark114 o Current Document h IPv4/IPv6 L2 VAS 設(shè)計32 HYPERLINK l bookmark116 o Current Document h IPv4/IPv6 L3 VAS 設(shè)計33 HYPERLINK l book

8、mark118 o Current Document h 7.3.3南北向業(yè)務(wù)鏈設(shè)計348業(yè)務(wù)鏈高可用35 HYPERLINK l bookmark120 o Current Document h 8.1健康性檢測35 HYPERLINK l bookmark122 o Current Document h 8.2業(yè)務(wù)鏈逃生358.2.1參考拓撲36 HYPERLINK l bookmark124 o Current Document h NSH 業(yè)務(wù)鏈逃生(NSH-aware)36 HYPERLINK l bookmark126 o Current Document h PBR業(yè)務(wù)鏈逃生37

9、A參考圖片381. CloudFabric業(yè)務(wù)鏈介紹CloudFabric數(shù)據(jù)中心網(wǎng)絡(luò)（以下簡稱CloudFabric”）解決方案旨在為客戶構(gòu)筑簡單、 智慧、開放的云數(shù)據(jù)網(wǎng)絡(luò)中心，廣泛應(yīng)用于運營商私有云、公有云、電信云等場景， 幫助客戶加速數(shù)字化轉(zhuǎn)型。CloudFabric解決方案中，“業(yè)務(wù)鏈”技術(shù)可以在業(yè)務(wù)轉(zhuǎn)發(fā)路 徑中插入“增值服務(wù)設(shè)備”（以下簡稱“VAS設(shè)備”，如防火墻、負載均衡、深度檢 測、入侵防御等設(shè)備），對業(yè)務(wù)流量進行增值服務(wù)。通過CloudFabric業(yè)務(wù)鏈，可以將業(yè)務(wù)流量重定向到防火墻和負載均衡等VAS設(shè) 備，而無需VAS設(shè)備作為網(wǎng)關(guān)。通過CloudFabric業(yè)務(wù)鏈，可以有選擇

10、的將流量轉(zhuǎn)發(fā)到VAS設(shè)備。通過CloudFabric業(yè)務(wù)鏈，VAS設(shè)備可以無需修改已有拓撲的方式插入 CloudFabric。通過CloudFabric業(yè)務(wù)鏈，可以快速的橫向擴展VAS設(shè)備。CloudFabric解決方案業(yè)務(wù)鏈是一種有序的業(yè)務(wù)功能集，可以保證被選擇的流量有序的 獲取增值服務(wù)。CloudFabric解決方案可以將網(wǎng)絡(luò)與增值業(yè)務(wù)統(tǒng)一部署，也可以分開部 署，這取決于增值業(yè)務(wù)設(shè)備管理平臺和“iMasterNCE-Fabric” （CloudFabric解決方案 的核心組件，實現(xiàn)對云數(shù)據(jù)中心網(wǎng)絡(luò)的統(tǒng)一管控和動態(tài)調(diào)度、自動化部署和彈性擴縮 容，以下簡稱“控制器”）的對接程度。CloudFa

11、bric業(yè)務(wù)鏈應(yīng)用場合業(yè)務(wù)鏈具備設(shè)備品牌多，功能復(fù)雜，引流形式多樣等特性，由于CloudFabric解決方案 本身不提供VAS設(shè)備，所以需要根據(jù)控制器是否可以管理VAS設(shè)備，決定業(yè)務(wù)鏈模 式。業(yè)界通常支持如下三種管理業(yè)務(wù)鏈模式：Service Policy模式：控制器負責(zé)Fabric和VAS設(shè)備之間互聯(lián)L2L3層網(wǎng)絡(luò)的編 排，并負責(zé)VAS設(shè)備所有L2L3層網(wǎng)絡(luò)編排和L4L7業(yè)務(wù)策略下發(fā)。Service Policy模式依賴控制器對接VAS設(shè)備（或其管理平臺）的能力，VAS設(shè)備 整體被包含在CloudFabric解決方案中，VAS設(shè)備L2L7層業(yè)務(wù)編排屬于 CloudFabric基礎(chǔ)框架的一部分

12、。Service Manager模式：控制器負責(zé)Fabric和VAS設(shè)備之間互聯(lián)L2L3層網(wǎng)絡(luò)的編 排，由第三方VAS設(shè)備管理平臺負責(zé)VAS設(shè)備L4L7層業(yè)務(wù)策略下發(fā)。Service Manager模式依賴控制器對接VAS設(shè)備（或其管理平臺）的能力，VAS設(shè) 備部分業(yè)務(wù)被包含在CloudFabirc解決方案，VAS設(shè)備L2L3層業(yè)務(wù)編排屬于 CloudFabric基礎(chǔ)框架的一部分。Network Policy模式：控制器只負責(zé)Fabric側(cè)L2L3層網(wǎng)絡(luò)的編排，VAS設(shè)備 L2L7層網(wǎng)絡(luò)和業(yè)務(wù)編排不在控制器管理范圍內(nèi)。Network Policy模式不依賴控制器對接VAS設(shè)備（或其管理平臺）的

13、能力，VAS 設(shè)備整體被隔離CloudFabirc解決方案之外，VAS設(shè)備的L2L7業(yè)務(wù)編排依靠其 第三方管理平臺或設(shè)備本身。華為CloudFabric解決方案中，目前三種業(yè)務(wù)鏈模式支持情況如下：Service Policy 模式支持 HW FWService Manager 模式僅支持 Checkpoint FW, Fortinet FW, Paloalto FW, F5 LB 等 VAS設(shè)備Network Policy模式支持其他第三方VAS設(shè)備在選用業(yè)務(wù)鏈模式時，需要考慮以下幾點：業(yè)務(wù)鏈配置是否會反復(fù)變更，變更業(yè)務(wù)鏈引流策略還是變更VAS設(shè)備業(yè)務(wù)配置？控制器是否可以管理VAS設(shè)備網(wǎng)絡(luò)和業(yè)

14、務(wù)配置？業(yè)務(wù)鏈相關(guān)配置是否有專門業(yè)務(wù)管理員維護，還是由網(wǎng)絡(luò)管理員統(tǒng)一編排？帶著這些問題，結(jié)合下圖，可以找到適合的業(yè)務(wù)鏈模型。帶著這些問題，結(jié)合下圖，可以找到適合的業(yè)務(wù)鏈模型。圖2-1業(yè)務(wù)鏈模式的選擇指引業(yè)務(wù)鏈模型3.1業(yè)務(wù)鏈基本模型3.2業(yè)務(wù)鏈邏輯模型3.3業(yè)務(wù)鏈編排模型NSH協(xié)議介紹PBR和NSH業(yè)務(wù)鏈對比3.1業(yè)務(wù)鏈基本模型業(yè)務(wù)鏈的基本概念模型如下圖所示0圖3-1業(yè)務(wù)鏈基本概念Logic Switch (Subnets)External Network .(Subnets)Logic Router(Subne ts)Policy ruleClassifier= SEffl+TCP- Fla

15、g/ICMP- TypeAction =Forward、 Deny、 RedirectPolicy rule setEPG：可以基于 extemalNetwork logic switch logic Router 定義，最小粒度為 IP 網(wǎng)段（subnet）。Policy rule set：策略規(guī)則集合，定義組間多個訪問控制策略規(guī)則。Policy rule： 一條規(guī)則，代表一類業(yè)務(wù)流量和對應(yīng)的業(yè)務(wù)鏈行為。Classifer：流分類器，支持基于五元組+TCP-flag/ICMPtype對流量進行分類。Action：規(guī)則中定義的的流動作，支持permit/deny/redirectoSFP：對應(yīng)

16、業(yè)務(wù)鏈的路徑，定義路徑包含VAS設(shè)備的數(shù)量、類型和經(jīng)過VAS設(shè)備 的順序，目前CloudFabric解決方案當(dāng)前一條PBR方式SFP中最多可定義3個 VAS設(shè)備。3.2業(yè)務(wù)鏈邏輯模型業(yè)務(wù)鏈的基礎(chǔ)邏輯模型如下圖所示。圖3-2業(yè)務(wù)鏈邏輯模型應(yīng)用B業(yè)務(wù)鏈邏輯模型中涉及到的幾個角色介紹如下。SC （Service Classifier,業(yè)務(wù)分類節(jié)點）：實現(xiàn)業(yè)務(wù)流識別（選擇流量重定向到業(yè) 務(wù)鏈）。SF （Service Function,業(yè)務(wù)功能節(jié)點）：提供增值服務(wù)功能的節(jié)點，即VAS設(shè) 備。SFF （Service Function Forwarder,業(yè)務(wù)轉(zhuǎn)發(fā)節(jié)點）：連接SF節(jié)點的交換機，可以 識別

17、要經(jīng)過業(yè)務(wù)鏈的業(yè)務(wù)流量，轉(zhuǎn)發(fā)至SF節(jié)點。還可以識別SF節(jié)點處理后的業(yè) 務(wù)流量，繼續(xù)重定向到后續(xù)業(yè)務(wù)鏈流程。3.3業(yè)務(wù)鏈編排模型3.3.1 PBR業(yè)務(wù)鏈編排模型PBR類型的業(yè)務(wù)鏈的編排模型和業(yè)務(wù)過程如下圖所示。圖3-3 PBR業(yè)務(wù)鏈編排模型iMaster NCE-Fabric 引流點 訪問流量i Master nce控制器向SC節(jié)點下發(fā)過濾和重定向策略，選擇性的將業(yè)務(wù)流量重定向到SF1, PBR方式不改變CONSUMER訪問PROVIDER的業(yè)務(wù)報文。控制器向SFF1節(jié)點下發(fā)隧道側(cè)和用戶側(cè)過濾和重定向策略，SFF1節(jié)點選擇性將 業(yè)務(wù)流量牽引至SF1、SF2O控制器向SFF2節(jié)點下發(fā)隧道側(cè)過濾和重

18、定向策略，SFF2節(jié)點選擇性將業(yè)務(wù)流量 牽引至SF3,最后將業(yè)務(wù)報文轉(zhuǎn)發(fā)給PROVIDERo3.3.2 NSH業(yè)務(wù)鏈編排模型NSH類型的業(yè)務(wù)鏈的編排模型和業(yè)務(wù)過程如下圖所示。圖3-4 NSH業(yè)務(wù)鏈編排模型下發(fā)NSH轉(zhuǎn)發(fā)表存77 %SFF2CONSUMERPROVIDERSF2SF1 引流點=NSH轉(zhuǎn)發(fā)表訪冋流量I匸 VXLAN轉(zhuǎn)發(fā)璉道iMaster nceSF3iMaster NCE-Fabric控制器向SC節(jié)點下發(fā)過濾和重定向策略，選擇性將業(yè)務(wù)流量牽引至NSH轉(zhuǎn)發(fā)路 徑，NSH方式會改變CONSUMER訪問PROVIDER的原始報文?？刂破飨騍C節(jié)點和SFF節(jié)點下發(fā)NSH轉(zhuǎn)發(fā)表，牽引業(yè)務(wù)流量

19、按照SFP路徑轉(zhuǎn) 發(fā)。若SF是NSHimawaw類型，控制器還需要在SFF節(jié)點下發(fā)NSH代理配置(剝離 NSH頭部轉(zhuǎn)發(fā))，同時還需要下發(fā)過濾和重定向策略將經(jīng)過SF處理的流量重新牽 引至NSH轉(zhuǎn)發(fā)路徑。若SF是NSH-aware類型，控制器不需要在SFF節(jié)點下發(fā)NSH代理配置，SF節(jié) 點處理業(yè)務(wù)流量時，會自行處理業(yè)務(wù)報文中NSH頭部字段且不會剝離NSH頭 部。3.4 NSH協(xié)議介紹ITEF定義了一種新的數(shù)據(jù)面業(yè)務(wù)封裝格式NSH (Network Service Header),封裝頭包 括業(yè)務(wù)路徑和MetaData信息等，使得業(yè)務(wù)鏈路徑上的各個節(jié)點能夠相互傳遞路徑信 息，從而構(gòu)建一個新業(yè)務(wù)平面，

20、實現(xiàn)業(yè)務(wù)鏈可以對數(shù)據(jù)做動態(tài)靈活的策略處理。NSH 協(xié)議標準可以參考RFC8300o承載NSH報文的網(wǎng)絡(luò)報文格式，如下所示。 承載網(wǎng)為VxLAN的NSH報文封裝格式如下圖所示:UDP header VXLAN headerPayload=IP PacketVXLAN + NSH 封裝瘵COuter Ethernet header Outer IP header 承載網(wǎng)為VLAN的NSH報文封裝格式如下圖所示:ETH + NSH 封 1Outer Ethernet header802.1 Q header Eth-Type=0 x894FPayload=IP Packet其中NSH header頭

21、部格式如下所示。 當(dāng)MD Type值為0 x1時，報文格式如下：0 1 2 3 4 56 789 0 1 2 34 567 8 9 0 1 2 34 56 78 90 1|Ver|O|U| TTL | Length |U|U|U|U|MD Type | Next Protocol | +-+|Service Path Identifier (SPI)| Service Index |II|Fixed-Length Con text Header+*+*+-+*+-+ 當(dāng)MD Type值為0 x2時，報文格式如下：0 1 2 34 56 789 0 1 2 345 678 9012 34 56

22、789 01|Ver|O|U| TTL | Length |U|U|U|U|MD Type | Next Protocol | +令+*+-+|Service Path Identifier (SPI)| Service Index |+* +*+* + TOC o 1-5 h z IIVariable-Length Context Headers (opt.)*II*+*+*令+具體字段含義，請參考表31表3-1 NSH報文格式中各個字段的說明字段描述VerNSH版本號當(dāng)前支持版本號為0ONSH報文類型0：表示數(shù)據(jù)報文1：表示0AM維護報文U保留字段發(fā)送時NSH報文保留字段置0,接收NSH報

23、文時忽略此字段TTL用于防環(huán)，默認值為63初始TTL值應(yīng)該可以被控制面配置，一個TTL值可以被用在多個SFP 每個SFF在轉(zhuǎn)發(fā)NSH報文時，需要將TTL值減1后再查找NSH轉(zhuǎn)發(fā) 表當(dāng)TTL值減1后為0時，丟棄該NSH報文LengthNSH報文的總長度，該項的值代表4字節(jié)的整倍數(shù)如果MD type值為1,則Length必須是6,表示NSH報文長度位6*4字段描述字節(jié)如果MD type是2,則Length必須大于或等于2MD type (MetaDat a type)元數(shù)據(jù)域的格式類型0：保留值，暫不使用1：表示元數(shù)據(jù)域為固定長度16字節(jié)2：表示元數(shù)據(jù)域為可變長度。F：僅測試或?qū)嶒炿A段可以使用當(dāng)前

24、設(shè)備支持的MD類型為1Next ProtocolNSH封裝前的報文類型0 x1： IPv4 報文0 x2： IPv6 報文0 x3: Ethernet 報文0 x4： NSH 報文0 x5： MPLS 報文0 x6OxFD：未定義OxFE OxFF： Experimental 當(dāng)前設(shè)備僅支持IPv4報文SPI業(yè)務(wù)鏈路徑編號用于唯一標識一條業(yè)務(wù)鏈路徑SI業(yè)務(wù)功能索引用于標識SF節(jié)點在SFP中的位置Context Header元數(shù)據(jù)域當(dāng)MD Type值為0 x0時,Context Header長度必須為0 （基本不用）當(dāng)MD Type值為0 x1時，Context Header固定長度為16字節(jié)當(dāng)

25、MD Type值為0 x2時，Context Header為變長字段，長度必須為4的 整數(shù)倍3.5 PBR和NSH業(yè)務(wù)鏈對比PBR和NSH兩種業(yè)務(wù)鏈業(yè)務(wù)的對比參見下表。表3-2 PBR和NSH的對比對比點PBR業(yè)務(wù)鏈NSH 業(yè)務(wù)鏈(NSHaware)基本特點PBR業(yè)務(wù)鏈不需要改變原始 報文（優(yōu)）NSH業(yè)務(wù)鏈需要改變原始報文地址變換VAS （NAT 和 LB）NAT難度在于控制器編排和 來回路徑NSH轉(zhuǎn)發(fā)平面可以減少NAT 編排難度（優(yōu)）MetaData 信息不支持支持（優(yōu)）Fabric設(shè)備要求無兼容性需求（優(yōu)）有兼容性需求VAS設(shè)備要求無需求（優(yōu)）需支持NSH需求業(yè)務(wù)鏈防環(huán)無防環(huán)能力（cisc

26、o能防環(huán)）無環(huán)（優(yōu)）帶寬資源占用不增加協(xié)議頭部（優(yōu)）增加協(xié)議頭部VAS節(jié)點規(guī)格受限ACL資源，IPv4最多3 跳業(yè)務(wù)鏈受限ACL資源，IPv6最多1 跳業(yè)務(wù)鏈最大支持255 （優(yōu)）單特性轉(zhuǎn)發(fā)轉(zhuǎn)發(fā)性能下降不明顯（優(yōu)）轉(zhuǎn)發(fā)性能下降明顯Bypass能力無Bypass能力（當(dāng)SF為L3 類型時，單跳業(yè)務(wù)鏈自帶逃 生）當(dāng)SF為L3類型時，支持逃生 （優(yōu)）流量可視無需適配（優(yōu)）流量可視軟件支持NSH協(xié)議ACL資源消耗需要每跳用戶側(cè)或網(wǎng)絡(luò)側(cè)匹 配只在SC節(jié)點匹配ACL,其他 節(jié)點不消耗（優(yōu)）NSH業(yè)務(wù)鏈只有當(dāng)VAS設(shè)備支持NSH協(xié)議，對比PBR業(yè)務(wù)鏈才會具備明顯的優(yōu)勢。 目前華為NSH協(xié)議生態(tài)，包含廠商：迪

27、普FW （雙棧）和山石FW （雙棧）,其他 3rd VAS設(shè)備作為NSHunware引流。若對業(yè)務(wù)鏈需求高性能轉(zhuǎn)發(fā)，則推薦PBR業(yè)務(wù)鏈；若要求業(yè)務(wù)鏈組網(wǎng)豐富，則推薦NSH業(yè)務(wù)鏈。業(yè)務(wù)鏈方案架構(gòu)業(yè)務(wù)鏈設(shè)計原則4.1網(wǎng)絡(luò)虛擬化場景業(yè)務(wù)鏈方案架構(gòu)4.2云網(wǎng)一體化場景業(yè)務(wù)鏈方案架構(gòu)4.1網(wǎng)絡(luò)虛擬化場景業(yè)務(wù)鏈方案架構(gòu)如圖4-1所示，在網(wǎng)絡(luò)虛擬化場景下，業(yè)務(wù)鏈的架構(gòu)中各個組件的功能如下。圖牛1網(wǎng)絡(luò)虛擬化中的SFC方案架構(gòu) iMaster NCE-Fabric:實現(xiàn)租戶業(yè)務(wù)和編排，發(fā)放VPC/vRouter/Subnet等服務(wù)管理華為CE交換機L2/L3 Fabric網(wǎng)絡(luò)編排業(yè)務(wù)鏈路徑和引流策略負責(zé)華為VA

28、S設(shè)備和L2/L3 Fabric雙向網(wǎng)絡(luò)開通和業(yè)務(wù)配置負責(zé)到第三方VAS的L2/L3 Fabric側(cè)的網(wǎng)絡(luò)開通SecoManager：管理華為VAS設(shè)備，控制器下發(fā)華為VAS設(shè)備業(yè)務(wù)配置至Seco ManagerHuawei VAS：華為 VAS 設(shè)備，提供 FW、LB、IPS、EIP、SNAT、IPSec VPN 等 業(yè)務(wù)的實體3rd VAS：第三方 VAS 設(shè)備，提供 FW、LB、IPS、EIP、SNAT、IPSec VPN 等業(yè) 務(wù)的實體3rd SF業(yè)務(wù)Portal：管理第三方VAS設(shè)備，開通相關(guān)業(yè)務(wù)和VAS設(shè)備側(cè)網(wǎng)絡(luò)4.2云網(wǎng)一體化場景業(yè)務(wù)鏈方案架構(gòu)如圖4-2所示，在云網(wǎng)一體化場景下，

29、業(yè)務(wù)鏈的架構(gòu)中各個組件的功能如下。圖4-2云網(wǎng)一體化中的SFC方案架構(gòu)OpenStack：實現(xiàn)租戶業(yè)務(wù)和編排，發(fā)放VPC/vRouter/Subnet等服務(wù)iMaster NCE-Fabric:實現(xiàn)租戶業(yè)務(wù)和編排，發(fā)放VPC/vRouter/Subnet等服務(wù)管理華為CE交換機L2/L3 Fabric網(wǎng)絡(luò)還原OpenStack網(wǎng)絡(luò)，二次編排業(yè)務(wù)鏈路徑和引流策略負責(zé)華為VAS設(shè)備和L2/L3 Fabric雙向網(wǎng)絡(luò)開通和業(yè)務(wù)配置負責(zé)到第三方VAS的L2/L3 Fabric側(cè)的網(wǎng)絡(luò)開通Seco Manager：管理華為VAS設(shè)備，VAS設(shè)備相關(guān)業(yè)務(wù)在Seco Manager編排配置Huawei VA

30、S：華為VAS設(shè)備，提供FW、EIP、SNAT、IPSec VPN等業(yè)務(wù)的實體3rdVAS：第三方VAS設(shè)備，提供FW、LB、IPS等業(yè)務(wù)的實體3rd SF業(yè)務(wù)Portal：管理第三方VAS設(shè)備，開通相關(guān)業(yè)務(wù)和VAS設(shè)備側(cè)L2/L3網(wǎng) 絡(luò)5.1業(yè)務(wù)鏈引流模型5.2 VAS設(shè)備與Leaf設(shè)備連接設(shè)計5.3業(yè)務(wù)鏈高可用設(shè)計原則5.1業(yè)務(wù)鏈引流模型業(yè)務(wù)鏈的核心能力在于引流，如何正確、均勻的將業(yè)務(wù)流量牽引至VAS設(shè)備是業(yè)務(wù)鏈 的核心功能。在CloudFabric解決方案中，不同類型的VAS設(shè)備，引流方式有所不 同。VAS設(shè)備類型總體來講，可以分為三種，分別為：L1類型設(shè)備、L2類型設(shè)備和 L3類型設(shè)備

31、。LI、L2和L3類型設(shè)備具體定義如下：L1類型設(shè)備無VLAN轉(zhuǎn)換能力所有的設(shè)備接口均屬于同一個VLAN業(yè)務(wù)流量經(jīng)過設(shè)備不會二層或三層轉(zhuǎn)發(fā)通常采用接口對的形式，從一個接口進，從另一個接口出L2類型設(shè)備具備VLAN轉(zhuǎn)換能力設(shè)備接口 VLAN可配置，不同接口可以配置不同VLAN業(yè)務(wù)流量經(jīng)過設(shè)備會二層轉(zhuǎn)發(fā)設(shè)備接口具備MAC學(xué)習(xí)能力L3類型設(shè)備具備VLAN轉(zhuǎn)換能力設(shè)備接口 VLAN可配置，不同接口可以配置不同VLAN業(yè)務(wù)流量經(jīng)過設(shè)備會三層轉(zhuǎn)發(fā)設(shè)備接口具備MAC學(xué)習(xí)能力不同類型VAS設(shè)備對應(yīng)不同的引流方式。L1/L2類型VAS設(shè)備本身無IP地址，需要 通過Go-through方式引流；而L3類型VAS設(shè)

32、備本身可以配置IP地址，通過Go-to方 式引流。Go-to引流模型參考下圖，Go-to引流模型分為兩種情況：業(yè)務(wù)鏈VAS設(shè)備直接作為consumer的網(wǎng)關(guān)（CloudFabric當(dāng)前方案暫不支持）。網(wǎng)絡(luò)設(shè)備BD接口地址作為consumer的網(wǎng)關(guān)，通過業(yè)務(wù)鏈重定向的方式將業(yè)務(wù)流 量重定向到VAS設(shè)備。Goto引流模型如下圖所示。圖5-1 Goto引流模型示意圖Leafconsumer ）. miwm providerBD1/BD2VASGo-to modeconsumer訪問provider的流量會在Leaf設(shè)備重定向到VAS設(shè)備IP,由VAS設(shè)備通過 靜態(tài)路由將業(yè)務(wù)流量處理后再轉(zhuǎn)發(fā)給Leaf

33、設(shè)備，由Leaf設(shè)備繼續(xù)重定向或轉(zhuǎn)發(fā)給 provider o在此引流模型中，一個VRF關(guān)聯(lián)兩個Bridge-Domain,兩者關(guān)系圖如下所示。圖5-2兩個BD之間的關(guān)系示意圖VRFBD1VASBD2VRFAVRFBGo-through 引流模型參考下圖，Go-through引流模型指VAS設(shè)備橋接在consumer和provider之間,VAS設(shè) 備本身不具備IP地址，流量不會在VAS設(shè)備L2/L3轉(zhuǎn)發(fā)。在CloudFabric解決方案中，需要業(yè)務(wù)流量重定向到L1/L2類型VAS設(shè)備時，通常采 用Go-through引流模式部署業(yè)務(wù)鏈。Go-through引流模式基本模型，如下圖所示。圖5-3

34、 Go-through引流模型LeafproviderconsumerBD1BD2VASGo through modeConsumer訪問provider的流量會在Leaf設(shè)備重定向到VAS設(shè)備,VRFA接口轉(zhuǎn)發(fā)業(yè)務(wù) 報文的目的MAC為VRFB接口地址MACo L1類型VAS設(shè)備會將業(yè)務(wù)報文直接與入 接口同接口對的另一接口轉(zhuǎn)發(fā)；L2類型VAS設(shè)備會將業(yè)務(wù)報文二層轉(zhuǎn)發(fā)。在此引流模型，兩個VRF分別關(guān)聯(lián)一個Bridge-Domian,兩者關(guān)系圖如下所示。圖5-4兩個VRF之間的關(guān)系示意圖VASBD2One-Arm引流模型參考下圖，OneArm模型指VAS設(shè)備和Leaf之間通過邏輯單臂互聯(lián)，指業(yè)務(wù)流

35、量通過 一個邏輯接口轉(zhuǎn)發(fā)。需要VAS設(shè)備支持此種引流模型。當(dāng)前CloudFabric解決方案中，同VPC內(nèi)業(yè)務(wù)鏈通常采用這種業(yè)務(wù)鏈模型。One-Arm引流模型如下圖所示。圖5-5 OneArm引流模型providerLeaf consumer BD1VASOne Arm modeConsumer訪問provider的業(yè)務(wù)流量會在Leaf設(shè)備重定向到VAS設(shè)備，VAS設(shè)備轉(zhuǎn)發(fā) 此業(yè)務(wù)流量給Leaf設(shè)備時，通過入接口轉(zhuǎn)發(fā)流量（需要VAS設(shè)備支持）。在此引流模型中，一個VRF關(guān)聯(lián)1個Bridge-Domain,兩者關(guān)系圖如下所示。圖5-6 VRF、BD間關(guān)系示意圖VRFA -若設(shè)定VAS與Leaf互

36、聯(lián)物理鏈路角色為“內(nèi)部鏈路”，則單臺VAS設(shè)備與MLAG Leaf組通過一對子接口互通（承載在互聯(lián)鏈路上），此時為邏輯單臂。若設(shè)定VAS與Leaf互聯(lián)物理鏈路角色為“內(nèi)外部鏈路”，貝憚臺VAS設(shè)備與M- LAG Leaf組通過兩對子接口互通（承載在互聯(lián)鏈路上），此時為邏輯雙臂。若設(shè)定VAS與Leaf互聯(lián)物理鏈路角色分別為“內(nèi)部鏈路”和“外部鏈路”，則單 臺VAS設(shè)備與M-LAG Leaf組通過兩對子接口互通（承載在互聯(lián)鏈路上），此時為 邏輯雙臂。其中，物理單臂、物理雙臂的說明如下：當(dāng)邏輯單臂或邏輯雙臂由一條物理鏈路承載（一條單鏈路或聚合鏈路），為物理單 臂。BD1VASVAS設(shè)備與Leaf設(shè)備

37、連接設(shè)計數(shù)據(jù)中心網(wǎng)絡(luò)中VAS設(shè)備和Leaf設(shè)備連接方式多種多樣，為了方便CloudFabric統(tǒng)一 管理和編排，規(guī)劃了 VAS設(shè)備與Leaf設(shè)備連接方法。VAS設(shè)備與Leaf互聯(lián)鏈路需要 區(qū)分鏈路角色，不同鏈路角色承載的流量不同。鏈路角色分為“內(nèi)部鏈路”和“外部 鏈路”?！皟?nèi)部鏈路”表示該鏈路只承載租戶router與租戶vsys的流量，“外部鏈路”表 示該鏈路只承載外部網(wǎng)絡(luò)與ExtranetVsys的流量，“內(nèi)外部鏈路”表示該物理鏈路既承 載租戶router與租戶vsys的流量也承載外部網(wǎng)絡(luò)與ExtranetVsys的流量，租戶vsys和 ExtranetVsys之間內(nèi)部會進行路由轉(zhuǎn)發(fā)，從而實

38、現(xiàn)租戶router和外部網(wǎng)絡(luò)的流量互通。當(dāng)邏輯雙臂由兩條物理鏈路承載（兩條單鏈路或聚合鏈路），為物理雙臂。同VPC內(nèi)東西向業(yè)務(wù)鏈，當(dāng)前版本推薦物理單臂配合邏輯單臂。南北向業(yè)務(wù)鏈，當(dāng)前版本支持物理單臂配合邏輯雙臂和物理雙臂配合邏輯雙臂方式實 現(xiàn)。5.2.1物理單臂設(shè)計模型物理單臂可以包含邏輯單臂和邏輯雙臂兩種模型，如下：邏輯單臂組網(wǎng)：VAS組成員設(shè)備與Leaf設(shè)備組（MLAG）通過聚合鏈路互聯(lián)， consumer和provider之間業(yè)務(wù)鏈通過內(nèi)部鏈路轉(zhuǎn)發(fā)報文。主設(shè)備和備設(shè)備都存在 一條邏輯鏈路，當(dāng)主設(shè)備邏輯鏈路故障，備設(shè)備邏輯鏈路生效（可靠性高）。圖5-7邏輯單臂組網(wǎng)示意圖consumerpr

39、ovider馮Z聚合鏈路1=0=聚合鏈路2內(nèi)部鏈路 邏輯雙臂組網(wǎng)：VAS組成員設(shè)備與Leaf設(shè)備組（MLAG）通過聚合鏈路互聯(lián)，主 設(shè)備和備設(shè)備通過聚合鏈路與Leaf設(shè)備組互聯(lián)，consumer和provider之間業(yè)務(wù)鏈 通過兩條邏輯鏈路轉(zhuǎn)發(fā)報文。主設(shè)備和備設(shè)備都存在兩條邏輯鏈路，當(dāng)主設(shè)備物 理鏈路故障，備設(shè)備物理鏈路生效（可靠性高）。圖5-8邏輯雙臂組網(wǎng)示意圖consumer聚合鏈路1= 聚合鏈路2內(nèi)部鏈路1內(nèi)部鏈路2或外部鏈路主備VAS設(shè)備provider5.2.2物理雙臂設(shè)計模型物理雙臂僅包含邏輯雙臂一種模型：VAS設(shè)備組與Leaf設(shè)備組（M-LAG）通過兩條聚 合鏈路互聯(lián)，邏輯鏈路被

40、承載在不同的聚合鏈路（可靠性高）。匸口說明下圖備VAS備設(shè)備與主設(shè)備接線方式一致，防止圖片畫線過多，故省略。圖5-9物理雙臂組網(wǎng)示意圖con sumer書：聚合鏈路曲二聚合鏈路2內(nèi)部鏈路1內(nèi)部鏈路2或外部鏈路provider5.3業(yè)務(wù)鏈咼可用設(shè)計原則CloudFabric業(yè)務(wù)鏈高可用可以從兩個維度闡明：VAS設(shè)備高可靠和業(yè)務(wù)鏈路徑高可靠 （SC節(jié)點、SFF節(jié)點），如下表所示。項目VAS設(shè)備可靠性SC節(jié)點可靠性SFF節(jié)點可靠性冗余方式主備/主備鏡像/負 載分擔(dān)MLAG雙活MLAG雙活故障檢測方式VAS設(shè)備之間心跳 線MLAG雙主心跳檢 測MLAG雙主心跳檢 測故障切換方法VAS設(shè)備主動切換BGP

41、收斂BGP收斂5.3.1 VAS設(shè)備組高可用VAS設(shè)備高可用，可以通過主備、主備鏡像、負載分擔(dān)等方式實現(xiàn)。 主備：VAS設(shè)備組成員統(tǒng)一通過VIP地址對外提供服務(wù)，成員間通過參數(shù)比較選 出主成員，主成員負責(zé)所有業(yè)務(wù)處理，將配置同步給備成員，備成員隨時準備接 替主成員（當(dāng)前版本不支持）主備鏡像：VAS設(shè)備組成員統(tǒng)一通過VIP地址對外提供服務(wù)，成員間通過參數(shù)比 較選出主成員，主成員負責(zé)所有業(yè)務(wù)處理，將配置和會話同步給備成員，備成員 隨時準備接替主成員負載分擔(dān)：VAS設(shè)備組成員統(tǒng)一通過VIP地址對外提供服務(wù)，成員均對外提供服 務(wù)，配置會下發(fā)給所有成員（當(dāng)前版本不支持）通常通過VAS集群提供以上高可用功

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

43、設(shè)備組成員主備通過靜 態(tài)路由優(yōu)先級體現(xiàn)。VAS設(shè)備組（主備/主備鏡像）高可用連接方案如下圖所示。圖5-10主備/主備鏡像高可用連接示意圖M-LAG雙活，有相同VTEP-IPAVAS集群VIP負載分擔(dān)高可用連接方案負載分擔(dān)集群VAS設(shè)備組成員通過M-LAG聚合鏈路與Leaf設(shè)備組互聯(lián)，VAS設(shè)備組 成員間通過直連鏈路檢測成員心跳和配置同步，Leaf設(shè)備組之間通過peer-link鏈路和 心跳鏈路實現(xiàn)設(shè)備雙活和同步表項。Leaf設(shè)備組統(tǒng)一對外提供相同的VTEPIP地址， VAS設(shè)備組成員統(tǒng)一對外提供相同的VIP地址，控制器為Leaf設(shè)備組下發(fā)多條目的為 VIP的靜態(tài)路由，靜態(tài)路由對應(yīng)的nextho

44、p分別指向VAS設(shè)備組成員，靜態(tài)路由無需 配置優(yōu)先級，通過ECMP實現(xiàn)負載分擔(dān)。負載分擔(dān)對往返路徑一致性有要求，所以正 向流量和反向流量在hash時應(yīng)忽略方向性。VAS設(shè)備（負載分擔(dān)）高可用連接方案如下圖所示。VAS設(shè)備（負載分擔(dān)）高可用連接方案如下圖所示。圖5-11負載分擔(dān)高可用連接示意圖M-LAG雙活，有相同VTEP-IPVAS集群VIP0聚合孵1聚合鏈路2圖5-12正常時的流量轉(zhuǎn)發(fā)5.3.2設(shè)備和鏈路可靠性故障切換場景上述高可用方案可以覆蓋鏈路故障場景和設(shè)備故障場景。主備鏡像VAS組 正常業(yè)務(wù)，任意一臺Leaf設(shè)備組成員都可以將業(yè)務(wù)流量本地轉(zhuǎn)發(fā)到VAS設(shè)備組主 成員。= 聚合幽聚合矚2業(yè)

45、務(wù)路徑當(dāng)Leaf設(shè)備與VAS組主成員鏈路故障時,業(yè)務(wù)流量可以從MLAG成員設(shè)備通過peerlink鏈路轉(zhuǎn)發(fā)到另一個MLAG成員設(shè)備，再轉(zhuǎn)發(fā)到VAS組主成員。圖5-13 Leaf與VAS組主成員鏈路故障時的流量轉(zhuǎn)發(fā)圖5-15正常時的流量轉(zhuǎn)發(fā)圖5-15正常時的流量轉(zhuǎn)發(fā)Peer- link圖5-14 VAS組主成員故障時的流量轉(zhuǎn)發(fā)令聚合幽鳥聚合矚2高可用路徑主備 當(dāng)VAS組主成員故障時，Leaf設(shè)備組從VAS組備成員學(xué)習(xí)到VAS組VIP的 MAC,后續(xù)流量轉(zhuǎn)發(fā)給VAS組備成員。韋Z聚合晦= 聚合鏈路2高可用路徑主備負載均衡模式VAS組（當(dāng)前版本不支持） 正常業(yè)務(wù)，任意一臺Leaf設(shè)備組成員都可以將業(yè)

46、務(wù)流量本地轉(zhuǎn)發(fā)到VAS設(shè)備組所 有成員。zQz聚合幽= 聚合鏈路2業(yè)務(wù)路徑當(dāng)Leaf設(shè)備與某個VAS成員鏈路故障時，業(yè)務(wù)流量可以從M-LAG成員設(shè)備通過 peerl-ink鏈路轉(zhuǎn)發(fā)到另一個MLAG成員設(shè)備，再轉(zhuǎn)發(fā)到VAS設(shè)備。圖5-16 Leaf與VAS組某個成員部分鏈路故障時的流量轉(zhuǎn)發(fā)聚合幽爭:聚合鹽2 業(yè)務(wù)路徑高可用路徑當(dāng)某個VAS設(shè)備故障時，Leaf設(shè)備組會收斂下一跳為故障VAS設(shè)備的VIP靜態(tài) 路由，其他成員的靜態(tài)路由無影響。圖5-17 VAS組某個成員故障時的流量轉(zhuǎn)發(fā)圖5-17 VAS組某個成員故障時的流量轉(zhuǎn)發(fā)=0= 聚合晦母聚合趟2業(yè)務(wù)路徑高可用路徑6CloudFabric 基線組

47、6CloudFabric 基線組在目前CloudFabric基線組網(wǎng)中，業(yè)務(wù)鏈能力局限在VPC內(nèi)，應(yīng)用場景共3種:外網(wǎng)和VPC通過業(yè)務(wù)鏈互訪：業(yè)務(wù)鏈支持路徑包含VAS設(shè)備或不包含VAS設(shè) 備，不過VAS設(shè)備時由交換機實現(xiàn)業(yè)務(wù)隔離。VPC內(nèi)不同子網(wǎng)通過業(yè)務(wù)鏈互訪：業(yè)務(wù)鏈支持路徑包含VAS設(shè)備或不包含VAS 設(shè)備，不過VAS設(shè)備時由交換機實現(xiàn)業(yè)務(wù)隔離。VPC內(nèi)同子網(wǎng)通過業(yè)務(wù)鏈互訪：業(yè)務(wù)鏈將流量牽引至VAS設(shè)備進行安全控制，Network Overlay網(wǎng)絡(luò)虛擬化組網(wǎng)需要虛擬交換機(VMwaw&Microsoft)通過 PVLAN,將流量牽引至交換機，通過交換機業(yè)務(wù)鏈按需隔離6.1Service L

48、eaf 禾口 Border Leaf 合設(shè)6.2Service Leaf 禾口 Border Leaf 分設(shè)Service Leaf 和 Border Leaf 合設(shè)Service Leaf和Border Leaf合設(shè)的組網(wǎng)基線如下圖所示。圖6-1 Service Leaf和Border Leaf合設(shè)的組網(wǎng)示意圖VASBorderLeaf ServiceLeafFabric-GWServerLeafServerLeafServerLeaf本章業(yè)務(wù)鏈的3種應(yīng)用場景，控制器將重定向策略在源端ServerLeaf下發(fā)，將業(yè)務(wù)流 量牽引至VAS設(shè)備處理，南北向業(yè)務(wù)鏈最后一跳VAS設(shè)備通過靜態(tài)路由的方式

49、轉(zhuǎn)發(fā)業(yè) 務(wù)流量，對應(yīng)轉(zhuǎn)發(fā)邏輯如下圖所示。圖6-2南北向業(yè)務(wù)鏈轉(zhuǎn)發(fā)路徑示意圖VAS2VM3內(nèi)外網(wǎng)過5弟點不同子網(wǎng)過SF節(jié)點同子網(wǎng)過SF節(jié)點Service Leaf 和 Border Leaf 分設(shè)Service Leaf和Border Leaf分設(shè)的組網(wǎng)基線如下圖所示。圖6-3 Service Leaf和Border Leaf分設(shè)的組網(wǎng)示意圖VASBorderLeafServiceLeafFabric-GWServerLeafServerLeafServerLeaf業(yè)務(wù)鏈的3種應(yīng)用場景，重定向策略在源端ServerLeaf下發(fā)，將業(yè)務(wù)流量牽引至VAS 設(shè)備處理（同子網(wǎng)與不同子網(wǎng)引流類似，不予贅述

50、），南北向業(yè)務(wù)鏈最后一跳VAS設(shè) 備通過路由引流的方式轉(zhuǎn)發(fā)業(yè)務(wù)流量，對應(yīng)轉(zhuǎn)發(fā)邏輯如下圖所示。圖6-4南北向業(yè)務(wù)鏈轉(zhuǎn)發(fā)路徑示意圖不同子網(wǎng)過SF節(jié)點同子網(wǎng)過SF節(jié)點業(yè)務(wù)鏈設(shè)計業(yè)務(wù)鏈設(shè)計7.1參考拓撲NSH業(yè)務(wù)鏈PBR業(yè)務(wù)鏈7.1參考拓撲如下圖所示，是業(yè)務(wù)鏈設(shè)計舉例參考拓撲圖。圖7-1業(yè)務(wù)鏈設(shè)計舉例參考拓撲圖InternetSF3ServerLeaf2Vxl AN Tunnelservice-chain service-path 1 service-index 255 nexthop sf remote-ip IP1service-index 254 nexthop sf remote-ip IP2

51、service-index 253 nexthop sff vtep service Lea f2 vni 1000VxLAN Tunnelservice-chain service-path 1 service-index 253 nexthop sf remote-ip IP3 service-index 252 path-terminalservice-chain service-path 1 service-index 255 nexthop sff vtep serviceLeafl vni 1000VM1SF1SF2SF3VM3(IP1)(IP2)(IP3) NSH業(yè)務(wù)鏈引流點NS

52、H轉(zhuǎn)發(fā)表Network Overlay網(wǎng)絡(luò)虛擬化組網(wǎng)VM1、VM2、VM3均是同VPC虛機SF1、SF2、SF3是東西向業(yè)務(wù)鏈SF節(jié)點SF4是南北向業(yè)務(wù)鏈SF節(jié)點假定租戶VRF名稱為Tenant_VRF7.2 NSH業(yè)務(wù)鏈IPv4/IPv6 L2 VAS 設(shè)計暫不支持IPv4/IPv6 L3 VAS 設(shè)計(NSHaware)東西向NSH業(yè)務(wù)鏈L3類型SF配置模型如下圖所示。圖7-2東西向NSH業(yè)務(wù)鏈L3類型SF配置模型traffic classifier tc1if-match ad 3000 traffic behavior tb1redirect service-path 1 servic

53、e-index 255 traffic policy tp1classifier tc1 behavior tb1 interface vbdif 1traffic-policy tp1 inboundVM1VM3業(yè)務(wù)鏈方案(VM3VM 1引流類似，不予贅述)：1. ServerLeafl配置MQC重定向策略到vbdif 1, vbdif是VM1上線對應(yīng)的邏輯口, 將業(yè)務(wù)流量牽引至NSH轉(zhuǎn)發(fā)平面，通過NSH轉(zhuǎn)發(fā)平面，將業(yè)務(wù)流量轉(zhuǎn)發(fā)至 ServiceLeafl ；ServiceLeafl全局下發(fā)NSH轉(zhuǎn)發(fā)表，業(yè)務(wù)流量按照NSH報文頭部信息轉(zhuǎn)發(fā)至 SF1、SF2節(jié)點，SF1和SF2節(jié)點支持NSH協(xié)

54、議，每經(jīng)過一個SF節(jié)點，SI值減 1;ServiceLeaf2全局下發(fā)NSH轉(zhuǎn)發(fā)表，業(yè)務(wù)流量按照NSH報文頭部信息轉(zhuǎn)發(fā)至SF3 節(jié)點，最后由ServiceLeaf2剝離NSH頭部，通過自然轉(zhuǎn)發(fā)至VM3。IPv4/IPv6 L3 VAS 設(shè)計(NSHunaware)東西向NSH業(yè)務(wù)鏈L3類型SF配置模型如下圖所示。圖7-3東西向NSH業(yè)務(wù)鏈L3類型SF配置模型traffic classifier tc1 if-match ad 3000 traffic behavior tb1 redirect service-path 1 service-index 255traffic policy tp1

55、 classifier tc1 behavior tb1 interface vbdif 1 traffic-policy tp1 inboundVxl AN Tunnelservice-chain service-path 1 service-index 255 nexthop sf nsh-proxy remote-ip IP1 service-index 254 nexthop sff vtep ServiceLeaf2 vni 1000 /Servi eaf1service-chain service-path 1 service-index 255 nexthop sff vtep

56、ServiceLeafl vni 1000VM1SF1 (IPDservice-chain service-path 1 service-index 254 nexthop sf nsh-proxy remote-ip IP2 service-index 253 path-terminalVxi an Tunneltraffic classifier tel if-match acl 3000 traffic behavior tb1redirect service-path 1 service-index 254 traffic policy tp1classifier tc1 behavi

57、or tb1 interface vbdif 2traffic-policy tp1 inboundVxLAN TunnelSeM 凡 i eaf2SF2 (IP2)traffic classifier tc1 if-match acl 3000 traffic behavior tb1redirect service-path 1 service-index 253 traffic policy tp1classifier tc1 behavior tb1 interface vbdif 2traffic-policy tp1 inboundServerLeaf2ElVM3NSH業(yè)務(wù)鏈引流點

58、NSH轉(zhuǎn)發(fā)表VM1VM3業(yè)務(wù)鏈方案(VM3VM 1引流類似，不予贅述)：ServerLeafl配置MQC重定向策略到vbdif 1, vbdif是VM1上線對應(yīng)的邏輯口， 通過策略將業(yè)務(wù)流量牽引至NSH轉(zhuǎn)發(fā)平面，通過NSH轉(zhuǎn)發(fā)平面，將業(yè)務(wù)流量轉(zhuǎn) 發(fā)至 ServiceLeafl ；ServiceLeafl全局下發(fā)NSH轉(zhuǎn)發(fā)表，業(yè)務(wù)流量按照NSH報文頭部信息轉(zhuǎn)發(fā)至SF1 節(jié)點，由于SF1節(jié)點為NSH-unaware類型所以轉(zhuǎn)發(fā)前需要將NSH報文頭部剝離 后轉(zhuǎn)發(fā)到SF1節(jié)點；SF1節(jié)點對流量處理完畢后，入ServiceLeafl時需要重新MQC引流，將業(yè)務(wù)流量 重新牽引至NSH轉(zhuǎn)發(fā)平面，Servic

59、eLeafl繼續(xù)按照NSH轉(zhuǎn)發(fā)表轉(zhuǎn)發(fā)業(yè)務(wù)流量；ServiceLeaf2全局下發(fā)NSH轉(zhuǎn)發(fā)表，業(yè)務(wù)流量按照NSH報文頭部信息轉(zhuǎn)發(fā)至SF2 節(jié)點，由于SF2節(jié)點為NSH-imaware類型所以轉(zhuǎn)發(fā)前需要將NSH報文頭部剝離 后轉(zhuǎn)發(fā)到SF2節(jié)點；SF2節(jié)點增值業(yè)務(wù)處理完畢后，入ServiceLeaf2時需要重新MQC引流，將業(yè)務(wù)流 量重新牽引至NSH轉(zhuǎn)發(fā)平面，ServiceLeaf2會剝離NSH報文頭部信息自然轉(zhuǎn)發(fā)業(yè) 務(wù)流量至VM3。7.2.4南北向業(yè)務(wù)鏈設(shè)計NSH業(yè)務(wù)鏈，南北向最后一跳必須按照NSHunawaw類型SF節(jié)點處理，南北向NSH 業(yè)務(wù)鏈SF配置模型如下圖所示。圖7-4南北向NSH業(yè)務(wù)鏈

60、SF配置模型（由內(nèi)網(wǎng)到外網(wǎng)）traffic classifier tc1 if-match acl 3000 traffic behavior tb1 redirect service-path 1 service-index 255traffic policy tp1 classifier tc1 behavior tb1interface vbdif 1 traffic-policy tp1 inboundVxl AN Tunnml二service-chain service-path 1 service-index 255 nexthop sf remote-ip IP1service-