CloudFabric云数据中心网解决方案-业务链设计指南

CloudFabric云数据中心网解决方案

设计指南（业务链）

目录

1CloudFabric业务链介绍.....................................................1

2CloudFabric业务链应用场合.................................................2

3业务链模型...................................................................4

3.1业务链基本模型............................................................................4

3.2业务链逻辑模型............................................................................5

3.3业务链编排模型............................................................................5

3.3.1PBR业务链编排模型.......................................................................5

3.3.2NSH业务链编排模型......................................................................6

3.4NSH协议介绍.............................................................................7

3.5PBR和NSH业务链对比.....................................................................9

4业务链方案架构..............................................................11

4.1网络虚拟化场景业务链方案架构..............................................................11

4.2云网一体化场景业务链方案架构..............................................................12

5业务链设计原则..............................................................13

5.1业务链引流模型............................................................................13

5.1.1Go-to引流模型...........................................................................14

5.1.2Go-through弓I流模型......................................................................15

5.1.3One-Arm引流模型........................................................................15

5.2VAS设备与Leaf设备连接设计...............................................................16

5.2.1物理单臂设计模型........................................................................17

5.2.2物理双臂设计模型........................................................................18

5.3业务链高可用设计原则.....................................................................18

5.3.1VAS设备组高可用........................................................................18

5.3.2设备和链路可靠性故障切换场景............................................................20

6CloudFabric基线组网........................................................24

6.1ServiceLeaf和BorderLeaf合设..............................................................24

6.2ServiceLeaf和BorderLeaf分设..............................................................26

7业务链设计..................................................................28

7.1参考拓扑.....................................................................................28

7.2NSH业务链...................................................................................29

7.2.1IPv4/IPv6L2VAS设计........................................................................29

722IPv4/IPv6L3VAs设计(NSH-aware)........................................................................................................................29

7.2.3IPv4/IPv6L3VAs设计(NSH-unaware).................................................................................................................30

7.2.4南北向业务链设计...........................................................................30

7.3PBR业务链...................................................................................32

7.3.1IPv4/IPv6L2VAS设计........................................................................32

7.3.2IPv4/IPv6L3VAS设计........................................................................33

7.3.3南北向业务链设计...........................................................................34

8业务链高可用................................................................35

8.1健康性检测...................................................................................35

8.2业务链逃生...................................................................................35

8.2.1参考拓扑....................................................................................36

8.2.2NSH业务链逃生(NSH-aware).....................................................................................................................................36

8.2.3PBR业务链逃生.............................................................................37

A参考图片...................................................................38

CloudFabric业务链介绍

CloudFabric数据中心网络（以下简称“CloudFabric”）解决方案旨在为客户构筑简单、

智慧、开放的云数据网络中心，广泛应用于运营商私有云、公有云、电信云等场景，

帮助客户加速数字化转型。CloudFabric解决方案中，“业务链”技术可以在业务转发路

径中插入“增值服务设备”（以下简称“VAS设备”，如防火墙、负载均衡、深度检

测、入侵防御等设备），对业务流量进行增值服务。

•通过CloudFabric业务链，可以将业务流量重定向到防火墙和负载均衡等VAS设

备，而无需VAS设备作为网关。

通过CloudFabric业务链,可以有选择的将流量转发到VAS设备。

通过CloudFabric业务链,VAS设备可以无需修改已有拓扑的方式插入

CloudFabric»

通过CloudFabric业务链,可以快速的横向扩展VAS设备。

CloudFabric解决方案业务链是一种有序的业务功能集，可以保证被选择的流量有序的

获取增值服务。CloudFabric解决方案可以将网络与增值业务统一部署，也可以分开部

署，这取决于增值业务设备管理平台和“iMasterNCE-Fabric"（CloudFabric解决方案

的核心组件，实现对云数据中心网络的统一管控和动态调度、自动化部署和弹性扩缩

容，以下简称“控制器”）的对接程度。

CloudFabric业务链应用场合

业务链具备设备品牌多，功能复杂，引流形式多样等特性，由于CloudFabric解决方案

本身不提供VAS设备，所以需要根据控制器是否可以管理VAS设备，决定业务链模

式。

业界通常支持如下三种管理业务链模式：

•ServicePolicy模式：控制器负责Fabric和VAS设备之间互联L2-L3层网络的编

排，并负责VAS设备所有L2〜L3层网络编排和L4〜L7业务策略下发。

ServicePolicy模式依赖控制器对接VAS设备（或其管理平台）的能力，VAS设备

整体被包含在CloudFabric解决方案中，VAS设备L2〜L7层业务编排属于

CloudFabric基础框架的一部分。

•ServiceManager模式：控制器负责Fabric和VAS设备之间互联L2〜L3层网络的编

排，由第三方VAS设备管理平台负责VAS设备L4〜L7层业务策略下发。

ServiceManager模式依赖控制器对接VAS设备（或其管理平台）的能力，VAS设

备部分业务被包含在CloudFabirc解决方案，VAS设备L2〜L3层业务编排属于

CloudFabric基础框架的一部分。

•NetworkPolicy模式：控制器只负责Fabric侧L2〜L3层网络的编排，VAS设备

L2-L7层网络和业务编排不在控制器管理范围内。

NetworkPolicy模式不依赖控制器对接VAS设备（或其管理平台）的能力，VAS

设备整体被隔离CloudFabirc解决方案之外，VAS设备的L2〜L7业务编排依靠其

第三方管理平台或设备本身。

华为CloudFabric解决方案中，目前三种业务链模式支持情况如下：

•ServicePolicy模式支持HWFW

•ServiceManager模式仅支持CheckpointFW,FortinetFW,PaloaltoFW,F5LB等

VAS设备

•NetworkPolicy模式支持其他第三方VAS设备

在选用业务链模式时，需要考虑以下几点：

1.业务链配置是否会反复变更，变更业务链引流策略还是变更VAS设备业务配置？

2.控制器是否可以管理VAS设备网络和业务配置？

3.业务链相关配置是否有专门业务管理员维护，还是由网络管理员统一编排？

带着这些问题，结合下图，可以找到适合的业务链模型。

图2-1业务链模式的选择指引

业务链模型

3.1业务链基本模型

3.2业务链逻辑模型

3.3业务链编排模型

3.4NSH协议介绍

3.5PBR和NSH业务链对比

3.1业务链基本模型

业务链的基本概念模型如下图所示。

图3-1业务链基本概念

Policyruleset

Policyrule

Classifier^Action=

fijuffl+TCP-Forward、

Flag/ICMP-Deny、

TypeRedirect

•EPG：可以基于externalNetwork、logicswitch、logicRouter定义，最小粒度为IP

网段(subnet)o

•Policyruleset：策略规则集合，定义组间多个访问控制策略规则。

•Policyrule：一条规则，代表一类业务流量和对应的业务链行为。

•Classifer：流分类器，支持基于五元组+TCP-flag/ICMP-type对流量进行分类。

•Action：规则中定义的的流动作，支持permit/deny/redirect。

•SFP：对应业务链的路径，定义路径包含VAS设备的数量、类型和经过VAS设备

的顺序，目前CloudFabric解决方案当前一条PBR方式SFP中最多可定义3个

VAS设备。

3.2业务链逻辑模型

业务链的基础逻辑模型如下图所示。

图3-2业务链逻辑模型

业务链逻辑模型中涉及到的几个角色介绍如下。

•SC（ServiceClassifier,业务分类节点）：实现业务流识别（选择流量重定向到业

务链）。

•SF（ServiceFunction,业务功能节点）：提供增值服务功能的节点，即VAS设

备。

•SFF（ServiceFunctionForwarder,业务转发节点）：连接SF节点的交换机，可以

识别要经过业务链的业务流量，转发至SF节点。还可以识别SF节点处理后的业

务流量，继续重定向到后续业务链流程。

3.3业务链编排模型

3.3.1PBR业务链编排模型

PBR类型的业务链的编排模型和业务过程如下图所示。

图3-3PBR业务链编排模型

iMasterNCE-Fabric

・引流点

访问流星

[MasterNH

•控制器向SC节点下发过滤和重定向策略，选择性的将业务流量重定向到SF1,

PBR方式不改变CONSUMER访问PROVIDER的业务报文。

•控制器向SFF1节点下发隧道侧和用户侧过滤和重定向策略，SFF1节点选择性将

业务流量牵引至SF1、SF2。

•控制器向SFF2节点下发隧道侧过滤和重定向策略，SFF2节点选择性将业务流量

牵引至SF3,最后将业务报文转发给PROVIDER,

3.3.2NSH业务链编排模型

NSH类型的业务链的编排模型和业务过程如下图所示。

图34NSH业务链编排模型

(MasterNCE-Fabric

・引流点

NSH转发表

iMasterNCE

访向流量

下发NSH转发表,：，：、、

!、(OVXLAN转发谈道

SFF2

TOR

MBT°R

CONSUMER丁二

■■

■■

KWfBB

MMMHB

,,■■

PROVIDER

SF1SF2SF3

•控制器向SC节点下发过滤和重定向策略，选择性将业务流量牵引至NSH转发路

径，NSH方式会改变CONSUMER访问PROVIDER的原始报文。

•控制器向SC节点和SFF节点下发NSH转发表，牵引业务流量按照SFP路径转

发。

•若SF是NSH-unaware类型，控制器还需要在SFF节点下发NSH代理配置(剥离

NSH头部转发)，同时还需要下发过滤和重定向策略将经过SF处理的流量重新牵

引至NSH转发路径。

•若SF是NSH-aware类型，控制器不需要在SFF节点下发NSH代理配置，SF节

点处理业务流量时，会自行处理业务报文中NSH头部字段且不会剥离NSH头

部。

3.4NSH协议介绍

ITEF定义了一种新的数据面业务封装格式NSH(NetworkServiceHeader),封装头包

括业务路径和MetaData信息等，使得业务链路径上的各个节点能够相互传递路径信

息，从而构建一个新业务平面，实现业务链可以对数据做动态灵活的策略处理。NSH

协议标准可以参考RFC8300。承载NSH报文的网络报文格式，如下所示。

•承载网为VxLAN的NSH报文封装格式如下图所示:

VXLAN+NSH封

OuterEthernetheaderOuterIPheaderUDPheaderVXLANheaderNSHheaderPayload=IPPacket

•承载网为VLAN的NSH报文封装格式如下图所示:

ETH+NSH封

802.1Qheader

OuterEthernetheaderEth-Type=0x894FPayload=IPPacket

其中NSHheader头部格式如下所示。

•当MDType值为0x1时，报文格式如下：

01234567890123456789012345678901

|Ver|O|U|TTL|Length|U|U|U|U|MDType|NextProtocol|

|ServicePathIdentifier(SPI)|ServiceIndex|

II

|Fixed-LengthContextHeader

•当MDType值为0x2时，报文格式如下：

01234567890123456789012345678901

|Ver|O|U|TTL|Length|U|U|U|U|MDType|NextProtocol|

|ServicePathIdentifier(SPI)|ServiceIndex|

II

~Variable-LengthContextHeaders(opt)*

II

具体字段含义，请参考表3-1

表3-1NSH报文格式中各个字段的说明

字段描述

VerNSH版本号

当前支持版本号为0

0NSH报文类型

0：表示数据报文

1：表示0AM维护报文

U保留字段

发送时NSH报文保留字段置0,接收NSH报文时忽略此字段

TTL用于防环，默认值为63

初始TTL值应该可以被控制面配置，一个TTL值可以被用在多个SFP

每个SFF在转发NSH报文时，需要将TTL值减1后再查找NSH转发

表

当TTL值减1后为0时，丢弃该NSH报文

LengthNSH报文的总长度，该项的值代表4字节的整倍数

如果MDtype值为1,则Length必须是6,表示NSH报文长度位6*4

字段描述

字节

如果MDtype是2,则Length必须大于或等于2

MDtype元数据域的格式类型

(MetaDat

0：保留值，暂不使用

atype)

1：表示元数据域为固定长度16字节

2：表示元数据域为可变长度。

F：仅测试或实验阶段可以使用

当前设备支持的MD类型为1

NextNSH封装前的报文类型

Protocol

•0x1：IPv4报文

,0x2：IPv6报文

,0x3：Ethernet报文

•0x4：NSH报文

•0x5：MPLS报文

,0x6~0xFD：未定义

•0xFE~0xFF：Experimental

当前设备仅支持IPv4报文

SPI业务链路径编号

用于唯一标识一条业务链路径

SI业务功能索引

用于标识SF节点在SFP中的位置

Context元数据域

Header

当MDType值为0x0时，ContextHeader长度必须为0（基本不用）

当MDType值为0x1时，ContextHeader固定长度为16字节

当MDType值为0x2时，ContextHeader为变长字段，长度必须为4的

整数倍,

3.5PBR和NSH业务链对比

PBR和NSH两种业务链业务的对比参见下表。

表3-2PBR和NSH的对比

对比点PBR业务链NSH业务链(NSH-aware)

基本特点PBR业务链不需要改变原始NSH业务链需要改变原始报文

报文（优）

地址变换VASNAT难度在于控制器编排和NSH转发平面可以减少NAT

（NAT和LB）来回路径编排难度（优）

MetaData信息不支持支持（优）

Fabric设备要求无兼容性需求（优）有兼容性需求

VAS设备要求无需求（优）需支持NSH需求

业务链防环无防环能力（cisco能防环）无环（优）

带宽资源占用不增加协议头部（优）增加协议头部

VAS节点规格受限ACL资源，IPv4最多3最大支持255（优）

跳业务链

受限ACL资源，IPv6最多1

跳业务链

单特性转发转发性能下降不明显（优）转发性能下降明显

Bypass能力无Bypass能力（当SF为L3当SF为L3类型时，支持逃生

类型时，单跳业务链自带逃（优）

生）

流量可视无需适配（优）流量可视软件支持NSH协议

ACL资源消耗需要每跳用户侧或网络侧匹只在SC节点匹配ACL,其他

配节点不消耗（优）

NSH业务链只有当VAS设备支持NSH协议，对比PBR业务链才会具备明显的优势。

目前华为NSH协议生态，包含厂商：迪普FW（双栈）和山石FW（双栈），其他

3rdVAS设备作为NSH-unware引流。

•若对业务链需求高性能转发，则推荐PBR业务链；

•若要求业务链组网丰富，则推荐NSH业务链。

业务链方案架构

4.1网络虚拟化场景业务链方案架构

4.2云网一体化场景业务链方案架构

4.1网络虚拟化场景业务链方案架构

如图4-1所示，在网络虚拟化场景下，业务链的架构中各个组件的功能如下。

图4-1网络虚拟化中的SFC方案架构

iMasterNCE-Fabric：

实现租户业务和编排，发放VPC/vRouter/Subnct等服务

-管理华为CE交换机L2/L3Fabric网络

编排业务链路径和引流策略

负责华为VAS设备和L2/L3Fabric双向网络开通和业务配置

负责到第三方VAS的L2/L3Fabric侧的网络开通

•SecoManager：管理华为VAS设备，控制器下发华为VAS设备业务配置至Seco

Manager

•HuaweiVAS：华为VAS设备，提供FW、LB、IPS、EIP,SNAT、IPSecVPN等

业务的实体

•3rdVAS：第三方VAS设备，提供FW、LB、IPS、EIP,SNAT、IPSecVPN等业

务的实体

•3rdSF业务Portal：管理第三方VAS设备，开通相关业务和VAS设备侧网络

4.2云网一体化场景业务链方案架构

如图4-2所示，在云网一体化场景下，业务链的架构中各个组件的功能如下。

图4-2云网一体化中的SFC方案架构

•OpcnStack：实现租户业务和编排，发放VPC/vRouter/Subnet等服务

•iMasterNCE-Fabric：

-实现租户业务和编排，发放VPC/vRouter/Subnet等服务

管理华为CE交换机L2/L3Fabric网络

还原OpenStack网络，二次编排业务链路径和引流策略

-负责华为VAS设备和L2/L3Fabric双向网络开通和业务配置

负责到第三方VAS的L2/L3Fabric侧的网络开通

•SecoManager：管理华为VAS设备，VAS设备相关业务在SecoManager编排配置

•HuaweiVAS：华为VAS设备，提供FW、EIP、SNAT、IPSecVPN等业务的实体

•3rdVAS：第三方VAS设备，提供FW、LB、IPS等业务的实体

•3rdSF业务Portal：管理第三方VAS设备，开通相关业务和VAS设备侧L2/L3网

络

业务链设计原则

5.1业务链引流模型

5.2VAS设备与Leaf设备连接设计

5.3业务链高可用设计原则

5.1业务链引流模型

业务链的核心能力在于引流，如何正确、均匀的将业务流量牵引至VAS设备是业务链

的核心功能。在CloudFabric解决方案中，不同类型的VAS设备，引流方式有所不

同。VAS设备类型总体来讲，可以分为三种，分别为：L1类型设备、L2类型设备和

L3类型设备。

LI、L2和L3类型设备具体定义如下：

1.L1类型设备

-无VLAN转换能力

所有的设备接口均属于同一个VLAN

业务流量经过设备不会二层或三层转发

-通常采用接口对的形式，从一个接口进，从另一个接口出

2.L2类型设备

具备VLAN转换能力

设备接口VLAN可配置，不同接口可以配置不同VLAN

-业务流量经过设备会二层转发

设备接口具备MAC学习能力

3.L3类型设备

-具备VLAN转换能力

-设备接口VLAN可配置，不同接口可以配置不同VLAN

业务流量经过设备会三层转发

设备接口具备MAC学习能力

不同类型VAS设备对应不同的引流方式。L1/L2类型VAS设备本身无IP地址，需要

通过Go-through方式引流；而L3类型VAS设备本身可以配置IP地址，通过Go-to方

式引流。

5.1.1Go-to引流模型

参考下图，Go-to引流模型分为两种情况：

•业务链VAS设备直接作为consumer的网关（CloudFabric当前方案暂不支持）。

•网络设备BD接口地址作为consumer的网关，通过业务链重定向的方式将业务流

量重定向到VAS设备。

Go-to引流模型如下图所示。

图5-1Go-t。引流模型示意图

Leaf

VRF

soy、D2

VAS

Go-tomode

consumer访问provider的流量会在Leaf设备重定向到VAS设备IP,由VAS设备通过

静态路由将业务流量处理后再转发给Leaf设备，由Leaf设备继续重定向或转发给

provider,

在此引流模型中，一个VRF关联两个Bridge-Domain,两者关系图如下所示。

图5-2两个BD之间的关系示意图

BD1BD2

5.1.2Go-through引流模型

参考下图，Go-through引流模型指VAS设备桥接在consumer和provider之间，VAS设

备本身不具备IP地址，流量不会在VAS设备L2/L3转发。

在CloudFabric解决方案中，需要业务流量重定向到L1/L2类型VAS设备时，通常采

用Go-through引流模式部署业务链。

Go-through引流模式基本模型，如下图所示。

图5-3Go-through弓I流模型

Leaf

consumerprovider

VRFAVRFB

BD1BD2

VAS

Gothroughmode

Consumer访问provider的流量会在Leaf设备重定向到VAS设备，VRFA接口转发业务

报文的目的MAC为VRFB接口地址MAC。L1类型VAS设备会将业务报文直接与入

接口同接口对的另一接口转发；L2类型VAS设备会将业务报文二层转发。

在此引流模型，两个VRF分别关联一个Bridge-Domian,两者关系图如下所示。

图5-4两个VRF之间的关系示意图

VAS

5.1.3One-Arm引流模型

参考下图，One-Arm模型指VAS设备和Leaf之间通过逻辑单臂互联，指业务流量通过

一个逻辑接口转发。需要VAS设备支持此种引流模型。

当前CloudFabric解决方案中，同VPC内业务链通常采用这种业务链模型。

One-Arm引流模型如下图所示。

图5-5One-Arm引流模型

consumerproviderJ

BD1

VAS

OneArmmode

Consumer访问provider的业务流量会在Leaf设备重定向到VAS设备，VAS设备转发

此业务流量给Leaf设备时，通过入接口转发流量（需要V^S设备支持）。

在此引流模型中，一个VRF关联1个Bridge-Domain,两者关系图如下所示。

图5-6VRF、BD间关系示意图

VRFA

5.2VAS设备与Leaf设备连接设计

数据中心网络中VAS设备和Leaf设备连接方式多种多样，为了方便CloudFabric统一

管理和编排，规划了VAS设备与Leaf设备连接方法。VAS设备与Leaf互联链路需要

区分链路角色，不同链路角色承载的流量不同。链路角色分为“内部链路”和“外部

链路”。“内部链路”表示该链路只承载租户router与租户vsys的流量，“外部链路”表

示该链路只承载外部网络与ExtranetVsys的流量，“内外部链路”表示该物理链路既承

载租户router与租户vsys的流量也承载外部网络与ExtranetVsys的流量，租户vsys和

ExtranetVsys之间内部会进行路由转发，从而实现租户router和外部网络的流量互通。

•若设定VAS与Leaf互联物理链路角色为“内部链路”，则单台VAS设备与M-

LAGLeaf组通过一对子接口互通（承载在互联链路上），此时为逻辑单臂。

•若设定VAS与Leaf互联物理链路角色为“内外部链路”，则单台VAS设备与M-

LAGLeaf组通过两对子接口互通（承载在互联链路上），此时为逻辑双臂。

•若设定VAS与Leaf互联物理链路角色分别为“内部链路”和“外部链路”，则单

台VAS设备与M-LAGLeaf组通过两对子接口互通（承载在互联链路上），此时为

逻辑双臂。

其中，物理单臂、物理双臂的说明如下：

•当逻辑单臂或逻辑双臂由一条物理链路承载（一条单链路或聚合链路），为物理单

臂。

•当逻辑双臂由两条物理链路承载（两条单链路或聚合链路），为物理双臂。

同VPC内东西向业务链，当前版本推荐物理单臂配合逻辑单臂。

南北向业务链，当前版本支持物理单臂配合逻辑双臂和物理双臂配合逻辑双臂方式实

现。

5.2.1物理单臂设计模型

物理单臂可以包含逻辑单臂和逻辑双臂两种模型，如下：

•逻辑单臂组网：VAS组成员设备与Leaf设备组（M-LAG）通过聚合链路互联，

consumer和provider之间业务链通过内部链路转发报文。主设备和备设备都存在

一条逻辑链路，当主设备逻辑链路故障，备设备逻辑链路生效（可靠性高）。

图5-7逻辑单臂组网示意图

consumerprovider

-Q-聚合链路i

存聚合链路2

-----内部链路

•逻辑双臂组网：VAS组成员设备与Leaf设备组（M-LAG）通过聚合链路互联，主

设备和备设备通过聚合链路与Leaf设备组互联，consumer和provider之间业务链

通过两条逻辑链路转发报文。主设备和备设备都存在两条逻辑链路，当主设备物

理链路故障，备设备物理链路生效（可靠性高）。

图5-8逻辑双臂组网示意图

consumerprovider

-Q-聚合链路1

金：聚合链路2

-----内部链路1

-----内部链路2或外部链路

5.2.2物理双臂设计模型

物理双臂仅包含逻辑双臂一种模型：VAS设备组与Leaf设备组（M-LAG）通过两条聚

合链路互联，逻辑链路被承载在不同的聚合链路（可靠性高）。

匚口说明

下图备VAS备设备与主设备接线方式一致，防止图片画线过多，故省略。

图5-9物理双臂组网示意图

5.3业务链高可用设计原则

CloudFabric业务链高可用可以从两个维度阐明：VAS设备高可靠和业务链路径高可靠

（SC节点、SFF节点），如下表所示。

项目