SD-WAN 底层原理和技术手册

2024-10-13 21:17:36   7  举报





AI智能生成

1.SD-WAN，即软件定义广域网，是将SDN技术应用到广域网场景中所形成的一种服务，这种服务用于连接广阔地理范围的企业网络、数据中心、互联网应用及混合云等。 2.不定期进行更新。如有建议可在评论区留言。 3.初始价格30元，后续每被克隆5次，价格上调10元。

SD-WAN

网络

广域网

SDN

软件开发

作者其他创作

大纲/内容

商业模式

SD-WAN解决方案的角色与商业模式

SD-WAN解决方案提供商

传统的网络设备厂商，

包括基于传统的企业WAN产品和方案，又演进出提供SD-WAN解决方案的厂商，如华为、思科以及Juniper等。

传统的WAN优化厂商、安全厂商

包括对其现有产品进行改造和升级、也宣称对外提供SD-WAN解决方案的厂商，如传统广域加速厂商SilverPeak、Riverbed，传统安全厂商Fortinet等。

专注于提供SD-WAN解决方案的新兴公司

如Velocloud、Versa等。

客户画像

中小型企业

中小型企业一般分支数量少，只有数个甚至1个分支站点，其主要业务特点如下。

·人员规模低于100人，站点规模低于10个，年销售规模低于1000万元。

·对WAN专线的成本敏感，WAN方面无专门的IT运维人员，需托管给第三方。

·分支互访简单，主要为南北向流量，即分支到总部或者数据中心。

·有基本的安全诉求，边缘设备内置的安全特性即可满足。

·有访问SaaS应用的诉求。

·维护诉求主要包括简单的告警、监控与可视化。

·分支站点需即插即用。

大型企业

大型企业数量巨大，分布在金融业、商业、教育以及制造业等多个不同的行业，其主要业务特点如下。

·站点规模为10～1000个，年销售规模高于1000万元。

·一般有MPLS等运营商专线，希望通过引入因特网来降低专线成本。·

·存在单层和分层网络拓扑，存在南北向和东西向互访流量。

·有访问公有云/SaaS的诉求。

·希望部署广域优化以提升应用体验。

·集中运维与可视化。

·分支站点需即插即用。

跨国企业

是地域跨度比较广的大企业，其业务一般跨越多个国家和地区，因而对WAN的网络建设和业务承载体验都有比较高的要求，其主要业务特点如下。

·站点规模为10～1000个，分布于全球。

·希望高价值流量由MSP提供的跨全球专线网络承载。

·希望部署广域优化以提升应用体验。

·集中运维与可视化。

·分支站点需即插即用。

企业自建

购买产品或解决方案，自行运维

企业购买厂商的SD-WAN 服务

包年包月，不用负责基础设施运维

华为SDWAN Overlay网络设计

拓扑类型

单层网络拓扑（扁平）

Hub-spoke、Full-mesh和Partial-mesh

分层网络拓扑

企业分支站点数量比较多，并且分布区域比较广，比如跨越多个省（区、市）甚至跨越多个国家与大洲，采用扁平的网络拓扑组网很难解决网络规模大、管理复杂度高等问题，这时就需要采用分层网络拓扑进行组网。

网络模型

MEF 标准定义了一个 SD-WAN模型

华为定义的模型

Site ID，即站点ID，是企业站点在SD-WAN中的全局唯一标识，

通常用一串数字或者用IP地址表示，由网络控制器统一自动分配。

CPE ID，即站点CPE的Router ID，是站点CPE在SD-WAN中的全局唯一标识。

一个站点通常包含一两个CPE ，CPE ID通常用CPE的Loopback 0的IP地址表示，由网络控制器统一自动分配。这里的CPE对应于MEF定义的Edge。

WAN，也称为TN，是运营商提供的广域网络线路，通常包括运营商专线和公用网络等

不同的WAN有不同的SLA质量，可开通流程以及收费策略。如果不同运营商提供的TN彼此之间路由可达，则认为这些TN在同一个RD内

不同运营商提供的WAN一般是彼此独立建设的，通常不能互通。

但也存在不同运营商提供的WAN可以互联互通的情况，这种情况下的广域网络属于同一个RD。

SD-WAN隧道，即SD-WAN Overlay隧道。不同的站点之间要实现互通，需要在两者之间建立一条隧道，隧道的两端是两个互联站点CPE的广域接口（TNP）。

该广域接口归属于同一个TN或者归属于同一个RD内的不同TN，这样就可以在Underlay网络实现互通，两个广域接口之间可以直接建立SDWAN隧道。

这里的SD-WAN隧道对应于MEF定义的SWVC。

VPN 的设计

VPN的端到端隔离体现在

站点上的VPN隔离 ,基于 VRF

Underlay VPN

真的需要吗？

控制VPN

业务VPN

业务VPN可能是一个，也可能是多个，根据企业实际需要隔离的业务数量而定。

隧道中的VPN隔离

每个VPN对应一个VN（Virtual Network，虚拟网络）

隧道设计

SD-WAN隧道设计原则

与Underlay解耦，不依赖具体的运营商WAN组网技术

支持IPSec等加密技术

针对某些安全WAN链路，用户可以选择不加密。

支持VPN隔离

SD-WAN需要支持企业多租户以及单租户内多个部门的VPN隔离，

支持NAT穿越

IP Overlay隧道技术

VXLAN、GRE以及IPSec

路由设计

BGP EVPN

在BGP协议的基础上定义了一种新的NLRI（Network Layer Reachability Information，网络层可达信息）即EVPN NLRI

EVPN NLRI定义了多种BGP EVPN路由类型，其中最初的Type 2路由用于携带二层MAC/IP路由；

随着EVPN技术的扩展，EVPN也被用来传递IP三层路由信息，Type 5路由就是IP前缀路由，主要用于通告引入的外部路由，在以SD-WAN的三层互联为主的网络中将发挥重要作用。

Type3路由——Inclusive Multicast路由：用于VTEP的自动发现和VXLAN隧道的动态建立

EVPN控制层面的工作机制

部署IBGP（Internal Border Gateway Protocol，内部边界网关协议）时，为简化全连接配置，可以引入路由反射器。

将从某个VTEP收到的路由反射给其他所有的VTEP

路由反射器可以独立设置，即路由反射器采用独立的设备，也可以同已有CPE合设，即路由反射器与CPE采用同一台设备（总部CPE），

EVPN路由在发布时，会携带RD（Route Distinguisher，路由标识符）和VPN Target（也称为Route Target）。RD用来区分不同的EVPN路由。

VPN Target是一种BGP扩展团体属性，用于控制EVPN路由的发布与接收。也就是说，VPN Target定义了本端的EVPN路由可以被哪些对端接收，以及本端是否接收对端发来的EVPN路由。

华为基于EVPN的SD-WAN路由增强方案

NAT 穿越特性

制在沿用了BGP EVPN基于Type 5传播网段前缀路由基本机制的基础上，对于SD-WAN路由的下一跳等关键信息进行了增强扩展，SD-WAN路由不仅携带一个WAN接口的IP地址作为下一跳，还可以携带多个WAN接口的IP地址以及NAT前后的IP地址信息作为下一跳。

网络可靠性设计

链路可靠性

单CPE 双WAN

双CPE，各只连一个WAN

某台CPE检测到互联的Underlay网络链路发生故障后，会通知另一台CPE，同时对报文转发策略进行调整，将报文通过互联链路转发到另一台CPE，从而规避上行链路的故障问题。

CPE设备可靠性

双活

需要同步业务信息（业务会话等）、链路统计信息和报文调度的策略‘

心跳检测

两种方式

LAN侧二层组网：可通过VRRP进行备份。

VRRP可以支持多个VRRP实例，通过多个实例实现设备的负载分担。

LAN侧三层组网：可通过等价路由进行备份。

传统路由器从SD-WAN设备中学习到等价路由，在正常情况下通过ECMP（Equal-Cost Multi-Path，等价多路径）进行负载分担，当设备出现故障时，对应的邻居关系被撤除，相应的路由信息被撤销。

核心站点高可用（hub）

双Hub站点冗余方案

重定向站点冗余设计

对吞吐量有较高的要求，所以一般选择企业的总部、数据中心或大中型的分支站点来兼任此角色

企业网网络模型

第一类网络当属连锁零售业、餐饮、酒店的生产网络，例如连锁门店与总店之间的交易数据同步，这种场景基本上只要有Internet + POS机就可以投入运营

Internet 线路1条，价格敏感

第二类网络叫做企业办公网络，网络规模各异，企业网包括：视频会议、ERP、Eamil、OA 等高频访问类应用。通常情况下，企业应用会根据不同角色设立不同的策略与规则，这些策略如QOS、故障收敛、负载分担/均衡、安全、监控管理都是依附在MPLS网络之上的

大多数是原MPLS-VPN用户

经济寒冬，中型企业搬迁办公室、快速切换SDWAN能省一笔钱是一笔

如果可以的话还省去、享受多个安全设备的服务，继续省钱。等保要求

按行业场景分类SDWAN客户

“SD-WAN首批客户”: 以传统行业为代表的零售、酒店、医疗、餐饮类行业,

这类客户的前身不少是MPLS客户，场景多半是总部与分支机构，或是连锁门店之类的星形网络。当他们发现SD-WAN这个新物种既能满足原有需求又能降低成本时，自然就成为了首选（少数例外）

第二类是以互联网行业为代表的电商、社交、游戏、直播等客户

他们的主场多半都在公有云，包括多云+数据中心的混合场景，也有办公室和分支机构等全连接场景。

生产系统主要运行在网络上，因此对网络条件自然也要求极高，通常的标准是高可靠、高安全、高SLA、7*24*365随时待命。

第三类大型集团和出海/跨国企业，业务场景类似于前两类的结合，但多半是企业应用加速，

注重应用层的使用效果和体验，不太关注网络连接，即我们常说的企业应用数字化转型。

企业网用户如何看SD-WAN

有些企业技术运维能力强，传统网络在他们手上非常稳固，他们对于SD-WAN的态度首先是考虑能否完美匹配原有环境或与之共存，新产品对他们而言可能会产生哪些新问题（例如可控性、可靠性、原资产利用、使用习惯、学习成本等），而不是看你的产品有多少功能，能节省多少成本，或是否高大上，但凡有一样与他们的预期有差异则很难轻易接受

另外也有一些不太重视运维的企业，网络架构可能会缺少规划，如果遇到规模大的，那就更考验服务商的综合技术服务能力，很可能改网的难度会超过重建一张网络。

改网需要双方之间的深入沟通交流，明确边界（关键是客户），服务商更需围绕企业网现状规划匹配的技术方案，技术过硬是基础，包括实施计划和服务的整体配套。

对于服务商来说，不要期望做两次PPT交流就能获得客户认可

对于客户来说，也不要过于依赖服务商能解决企业网的所有问题

厂商如何看SD-WAN

美国企业擅长技术创新或服务创新。而SD-WAN 和云计算都属于服务创新

站在线路思维的角度来看，SD-WAN在传统网络下的转型之痛并不在完全在于技术，而是传统网络几十年所形成的概念认知、技术方案、思维方式、服务模式、乙方产品粘性等系列因素和用户已深深绑定，他们接受新技术产品需要一个过程。

对比下当年IDC客户迁移至公有云是一个道理，即便到了今天，云上与云下应用环境仍在共存，这就使混合云成为了主流场景。

因此，SD-WAN当前的使命不是要完全替代传统网络（MPLS），而是要与之共存、兼容、智能融合，输出各项更具优势的产品方案和增值服务能力。

相对传统WAN的优势

为不同的应用提供不同的WAN处理策略，提高了WAN线路的ROI。

uCPE 支持VM等形式提供其他增值服务，并通过SFC进行串接

增加了一个控制器的角色，能够自动发现CPE，并向其地推送密钥和路由，省去了IP、IPSec、Tunnel、IGP、NHRP等的手工配置。

集中式的Portal，对上述功能以及其他功能的策略，进行统一的管理与配置

基于应用的识别和转发(应用体验QoE)

SD-WAN的一大亮点就在于能够识别出应用

DPI

逐包检测模式

所有的数据包都要过检测引擎，性能较差，目前用的很少。

逐流检测模式

流的前几个数据包走Normal IP-based Processing，同时被镜像给检测引擎，当完成应用类型的识别后，引擎将流与应用间的映射关系写入datapath的缓存中，该流后续的数据包将直接匹配缓存进行APP-based Processing，从而绕过检测引擎，提高处理的效率。

DPI的特征库需要支持在线升级，同时也应该允许用户自己对应用的特征进行自定义。

缺点：在于难以处理加密的HTTPS流量，

SSL卸载，使得DPI可以完成加解密，不过实现这种思路的厂商目前比较少

比如可以通过DNS Snooping来记录目的IP和URL的关系，这样看到目的IP就大概知道这个流所属的应用了，

或者直接内置一个周知的IP List也可以起到相同的作用。

DFI 深度/动态流检测

分析流的行为模式来确定应用，

缺点：DFI 的结果太粗糙了且不适合短流

基于这一系列流量的行为特征，建立流量特征模型，通过分析会话连接流的包长、连接速率、传输字节量、包与包之间的间隔等信息来与流量模型对比，从而实现鉴别应用类型。

用户自定义应用识别

APP-based Processing ，不仅仅是转发

匹配出应用后，流量会被标记metadata，如APP ID和APP Attribute ID，（类似于key-value）
后续包括Routing、Monitoring && Analytics、QoS、Firewall、WAAS都应该支持围绕着APP ID和APP Attribute ID来进行差异化的处理，
实现完整的APP-based Processing，而并非单纯的APP-based Forwarding。

QoE 实现的方案

应用识别方案 -- 体验保障方案的前提。

应用分类

生产 - ERP ,CRM 邮件

这类应用一般集中部署在总部或者数据中心的服务器上

协同办公

视频会议，VoIP

一般需要在通信的分支站点之间DIA直接进行数据交换。

云化类应用

随着云计算的普及，越来越多的企业应用向SaaS云化转变。比如随着Office365的逐渐流行

识别技术

传统的方式有根据报文五元组识别、根据报文流量特征识别、根据报文载荷识别等；

比较特殊的方式有根据DNS（Domain Name System，域名系统）识别、关联识别等。

应用识别

首包识别

协议识别

DNS 关联识别

特征识别

报文特征字识别

关联识别

行为识别

全网同步识别

分布式识别

集中式识别

以“是否能在接收到首包时就识别应用”为标准对识别技术进行划分，大致可以将其分成两类：首包识别技术和特征识别技术，且每一类又都有相应的子技术

链路质量测量技术

IP FPM（IP Flow Performance Measurement，IP流性能测量）是一种基于IP的网络性能的被动检测方案，通过对报文设置标记的方式（又称为染色）来携带统计信息，实现三层网络端到端的性能统计。一方面，IP FPM可以直接对业务报文进行测量，测量数据可以真实反映IP网络的性能；另一方面，IP FPM可以基于隧道监控IP网络承载业务的变化情况，真实准确地反映出各个路径下应用的运行情况，如图6-15所示。

应用选路方案

基于企业应用的优先级和对链路质量的要求，通过对多个WAN链路状态的持续监测，从而实现链路选择的方案。该方案既可以使多种企业应用充分利用高质量的链路，也能保证在链路拥塞时高价值应用的体验不会下降。

QoS方案

QoS方案是在传统的QoS技术（流量监管、流量整形、队列调度等）功能的基础上进一步扩展，增加企业业务感知功能，从而实现对纷繁的企业应用提供差异化服务的方案。

此外，在企业多部门需要隔离的场景下，该方案还提供基于企业部门的服务质量保障，形成“业务—部门—站点”这种层次化的质量保障。

广域优化方案

是提高数据在WAN链路上的传输质量和效率

包括广域优化技术、抗丢包技术等

基于线路质量QoS的智能选路

监测WAN线路的QoS

线路的质量主要包括Loss/Latency/Jitter/Utilizaiton四个方面，当线路质量出现波动时能够动态地调整应用的转发线路，以保证应用的SLA

被动测量：根据实际业务流的统计信息来进行分析

基本上都是厂家私有的方式与算法

主动测量：在业务流外生成Probe来进行探测。常见的手段有ICMP/BFD/CFM/OWAMP/TWMAP等等，如果是要测量SaaS的QoE，通常就用HTTP PING

双向转发检查BFD、ospf 调用bfd 加快收敛
BFD:Bidirectional Forwarding Detection,双向转发检查
作用：毫秒级故障检查，通常结合三层协议（如静态路由、vrrp、ospf、BGP等）实现链路故障快速检查。

为了保证实时的线路切换，控制器只负责推送SLA策略，而具体的执行需要在CPE本地完成。

探测WAN线路的MTU

多次的封装，如果MTU选择的不恰当的话，会导致大量分片的出现，不仅会多占用WAN线路的带宽，而且重组还会降低性能。

PMTUD（路径MTU检测）

在host 的 TCP的SYN中插入合适的MSS值

WAN 线路间的协同

大型的企业通常会买多条WAN线路，比如双 Internet、双 MPLS、Internet+MPLS 、4G/5G

WAN线路间的协同用SD-WAN的专业术语叫 Hybrid WAN或者WAN Bonding，意思就是把多条WAN线路打包在一起提供传输的服务，和Port Channel是类似的。

当WAN线路监测的结果说明一条线路的QoE不好的时候，要全部切换到其他的线路上，或者切换一部分流量到其他线路上

Per Flow的，即不同的流走到不同的线路上去，这和传统的ECMP没什么区别，但是无法保证应用得到最好的SLA。

Per APP的Bonding，即不同的应用走到不同的线路上去，这是SD-WAN最常提到的，但是在一些情况下资源的利用率不见得是最优的

Per Packet的，这种方式的话主要是优化Bulk大象流量，带宽利用的最为充足，但需要在对端进行数据乱序重整。

Per Flow、Per APP、Per Packet该怎么组合呢？这个和企业的流量模型，以及当前线路的使用情况都有关系，具体情况具体分析

目标WAN线路上存在防火墙或其他带状态的中间件，那么直接做切换的话，很可能会导致流量的中断，因此在做部署时，要设计好WAN线路和中间件的联动机制

考虑到不同站点间WAN线路情况的不同，一些SD-WAN方案会提供一种叫做Unidirection Steering机制，允许两个站点间的流量在上下行两个方向选择不同的WAN线路，当然这也要需要在考虑中间件的情况后再决定是否启用。

WAN 加速和智能优化应用

数据压缩，采用一定的算法对包头或者payload进行压缩/解压缩，以降低信息的冗余度；

数据去重，对传输过程中出现频次较高的数据进行编号，并使用指针进行替换，以节约编码所占用的空间；

内容缓存，将热点内容进行本地缓存，对热点内容的后续访问即可在本地直接返回，直接避免了对于WAN线路带宽的占用；

TCP优化，通过TCP代理将端到端的标准TCP切成多段，并对其中WAN一段的传输进行优化，改善标准TCP的拥塞控制和重传机制，或者基于UDP来增加吞吐量；

HTTP和其他应用层协议优化，这个就具体问题具体分析了。

对于企业来说价值最高的是UCaaS流量的优化，包括视频会议和VOIP等

视频优化

FEC常用于对视频传输进行优化，发送方进行FEC编码，在原始数据包以外引入冗余校验包，接收方进行FEC解码，并通过冗余校验包对原始数据包的误码或丢包进行恢复，

使用超高压缩比率的视频聊天APP

字节跳动研发屏幕内容视频编解码器 BVC1S，编码码率相比 X265 节省 85.3% 。用在了飞书上。。。

VOIP 优化

Packet Duplication常用于对VOIP的传输进行优化，发送端对数据包进行复制，并通过不同的WAN线路进行传输，接收端会以收到第一份为准并忽略掉后续重复的数据包

产品设计

CPE

CP（控制面用户态）、DP（转发面 DPDK）和SP（服务面）都是跑在x86上的，各个平面绑定不同的CPU

WAN口1-2个(1G/10G/光、电)，LAN口2-8个，

SMB（Small or Medium Branch）的产品10-100M \ 4G \5G \Wi-fi

标准Branch的产品在100M-500M间

面向大型Branch/HQ/DC的产品通常定位在500M-2G间

不过考虑到IPSec，这些物理接口在真正跑业务的时候，吞吐量通常都会打上一定的折扣

内置一些协处理器

提升IPSec性能的 Crypto Accelerator，

提高UCaaS能力的DSP

内置TPM芯片，用于CPE的身份认证。

X86 中高端CPE

DPDK \ 内核绑定

ARM 多为低端廉价CPE

NXP 芯片提供IPsec加解密加速功能包

控制器

Staging Server主要做认证和自动发现，和CPE间通常为私有协议，条件允许的话可以用DHCP。

Controller主要做密钥和路由分发，南向上各种形式都有，OpenFlow/BGP（重量级）/Netconf都有，用私有协议的也很多（因为轻量级）。

Analytics主要做数据采集和分析处理，南向上常见的有NetFlow/IPFIX/SNMP/Syslog等。北向上多以RESTful API为主。

此处不同的SD-WAN方案会有不同的设计

Portal （for 用户）

一、是应用WAN策略的默认模板

应用需要什么样的线路质量内嵌到系统中，然后自动生效

二、支持把不同的对象（比如站点、设备、应用等）打上不同的标记或分组，

还要支持手工制定一份策略（路由、安全、QoS等）统一对标记为XX的对象生效。

三、支持报表的定制与输出，保证SD-WAN的可审计。

Portal的位置，同样可以是On-Premise的或者在Cloud里面。

ZTP(即插即用)

第一种：CPE上线加上控制器把业务打通的全过程（见下方“打通网络”）

第二种：仅CPE的上线

唯一的标识，如虚拟号、MAC

CPE并加电后，CPE会通过DHCP/PPPoE来获取IP地址

CPE要去自动获取控制器的信息，包括IP、端口和认证信息等。获取的方式也有很多，

发货前厂家给配好是可以的，但是效率比较低。

扫二维码\短信\邮件获取URL得到配置文件，再通过web或U盘导入CPE。

客户参照指导书进行全部开局工作

做成即插即用，可以加电后触发DHCP/DNS来查Staging Server。获取到信息后，CPE会主动去找控制器，彼此之间完成双向认证，认证成功后就可以通信了。

自动打通物理网络和虚拟网络

CPE上线后，控制器就会选择最优WAN路径，下发指向最优出口的默认路由给CPE

由于一些协议（比如BGP peer）和隧道习惯上会起在loopback口上，这时loopback的地址和路由也都需要控制器去做规划和配置

如果出于可用性的考虑，IPSec或者其他的最外层隧道也要起在逻辑口上，那么还要向SP宣告该逻辑口的路由。

IPsec 的NAT-T 穿越机制

要求：至少一端有固定IP

通常都是 ESP+隧道模式以满足穿越NAT

数据面over IPSec ，

控制面穿NAT时，OpenFlow是不用的，但BGP/Netconf通常要over IPSec （如果厂商改底层实现也可以不over IPSec），

私有协议可以自己设计机制来穿NAT，注意要设计好保活防止NAT老化。

虚拟网络

控制器来集中完成隧道的建立和路由的分发，这样一来，多点和点对点在实现上其实是没有什么差别的

BGP/OpenFlow/Netconf都行，私有协议也很常见。

私有协议的也不在少数，其好处是可以实现的非常轻量，而且不仅仅是控制面，有的厂家连隧道的封装，甚至CPE里的协议栈都自己定制了

组播和服务链

可选支持的，可用于电话会议或者视频会议，如果支持的话一般也在会归在高档的License中提供

IGMP和PIM无法跨Internet传播，因此CPE和控制器间一般用私有协议来分发组播的路由。

服务链的话必选支持，由于涉及到策略问题，因此只能通过控制器去集中地控制服务链的路径

Netconf配PBR，BGP引流，OpenFlow引流，或者私有协议发布Service Route都是可以的。通常来说，PNF或者VNF都是在CPE本地，是不需要走隧道的，但有时候一些增值服务要求部署总部，这时候就得走隧道送过去了

由于NSH目前支持的还很少，因此在串多个服务的时候，一方面可以给流量打上Service Tag，相当于起了Service
Path Index的作用，另一方面通常还需要去额外地匹配inport，相当于起了Service Index的作用。

NSH（Network Service Header，网络服务头）是专门为服务链设计的封装格式，并且在OpenDayLight的SFC项目中采用

混合云

客户侧

还是隧道、加密、NAT穿越这些技术，IPSec仍然是可以搞定的。

云

绝大部分中小客户都只能用纯软的CPE

云市场 VNF

VM 自己安装 vCPE

为了打通IPSec，站点侧和云侧至少要有一个公网可访问的IP地址，如果是云侧需要这个地址，就需要向Cloud SP申请一个Fixed IP

二层互通比较麻烦

站点和VPC间做二层的需求是比较少见，企业做混合云主要还是为了打通三层

要么Cloud SP允许修改默认的VM安全策略；要么能在公有云机房放置物理CPE，从vSwitch打VxLAN到这个物理CPE上

访问公网

流量策略

LAN的策略

访问Internet可能需要单独做认证，这时CPE需要提供WEB认证的功能。

WAN的策略

Internet流量要做限制、限速，免得一些非关键流量占用宝贵的WAN线路带宽。

需要CPE具备识别HTTP/HTTPS流量的能力，对SaaS办公流量提高优先级，对于其他非办公流量，进行限速或者直接丢弃掉。

流量模型

Internet流量先送到总部

经过总部/数据中心的防火墙的统一过滤后再送到Internet上，

那么控制器需要向分支CPE下发一条默认路由，通过隧道指向总部的CPE，覆盖掉WAN口上可能被SP分配的默认路由。

优缺点：好处在于可以做到安全的集中部署与管理，但是流量发生了绕行，而且对总部/数据中心的带宽要求比较高

直接把Internet流量送到Internet上，即 DIA（Direct Internet Access）

DIA对于CPE的要求就比较高了，首先CPE上要有丰富的NAT能力，包括NAT/PAT、NAT Server、双向NAT等，需要支持带状态的会话能力。

控制器在下发IPSec规则时，需把NAT后的流量排除在IPSec的兴趣流量以外，否则就又被送到总部去了。

禁止访问公网

安全

唯一的标识

设备都需要有一个唯一的标识，CPE可以出厂时配好也可以固化在硬件中，VNF在拉起的时候会生成并注入序列号，而控制器的话用IP和FQDN通常就可以

认证

系统中的各个组件间需要有相互的认证，防止非法CPE和控制器的接入，这块的实现可以通过外接LDAP/RADIUS来做，也可以通过PKI体系来做，

SD-WAN产品自身也应该提供认证服务器或者PKI Server，如果企业自己有认证服务器或者PKI Server，要需要支持与其进行对接

IPSec / IKE 的两套密钥机制优化

第一套是IKE身份认证的非对称密钥

第二套是对称密钥。在传统方案中是通过DH来分布式计算的，在一些SD-WAN方案里则会直接由控制器来进行同步

这就相当于替代掉了IKE的作用，那么第一套密钥的身份认证工作改由通过PKI来实现，省去了维护预共享密钥的负杂工作

加密

数据平面的转发数据

over IPSec

控制平面信道

私有协议的话over在SSL/TLS/DTLS

Netconf和OpenFlow也都是原生over在TLS上面。

BGP over 在IPSec

简单的MD5破解起来轻而易举，业界始终都没有找到更好的办法来保证BGP的安全，重大的BGP劫持案例从来就没有间断过。
如果SD-WAN方案中控制面要用BGP，那么最好也over在IPSec里面，这倒也没什么奇怪的，传统的方案里IGP实际上也是over在IPSec里面的。
另外，原生的BGP还穿越不了NAT，正好用IPSec一并给解决了

业务层面

Logging、xACL、分级分域的 FW和DPI是最基本的要求

IDS/IPS/AV/UTM/NGNW，通常就是通过Service Route来串接

如果是在总部/数据中心做集中式的安全

那么分支的流量就要绕到总部/数据中心去，

如果是 DIA 的方式

那么就在分支的CPE上做文章，或者就近引流给第三方的SECaaS服务商。

满足行业客户的标准

银行和零售等，要保证为支付业务提供一个安全合规的网络传输环境。

符合PCI DSS标准

PCI DSS对于所有涉及信用卡信息机构的安全方面作出标准的要求，其中包括安全管理、策略、过程、网络体系结构、软件设计的要求的列表等，全面保障交易安全。PCI DSS适用于所有涉及支付卡处理的实体，包括商户、处理机构、购买者、发行商和服务提供商及储存、处理或传输持卡人资料的所有其他实体。PCI DSS包括一组保护持卡人信息的基本要求，并可能增加额外的管控措施，以进一步降低风险

防火墙，加密（最好应用层进行加密）等要求、
对于系统密码及其他安全参数，不能使用供应商提供的预设值（默认密码）

高可用

控制器集群设计

如果控制器只是做纯配置类的工作，那么实际上对于性能的要求不是很高，集群采用主备模式即可

如果还要负担路由控制类的工作，考虑到某些目标客户的规模比较大，那么集群最好能支持多活的模式以进行负载分担，

此时要求ZTP实现中，能够为不同的CPE指定不同的Master控制器。

网络层面高可用

网络层面的高可用就非常复杂了，端口/设备/链路/隧道/路由/状态，要考虑的方面很多，而且彼此间还要做好关联。因此，做高可用是需要代价的，不同的站点要在可用性和成本间做好平衡。

物理拓扑设计建议

中小型的分支而言可采用Single CPE + Dual Internet

大型的分支可采用Dual CPE + Hybrid WAN，

总部/数据中心可采用Dual CPE + Dual Internet + Dual MPLS，

还要根据站点的实际情况（eg:已有MPLS线路）来设计边缘的物理拓扑。