解读《SDWAN生态技术报告》~ 企业侧

4.1 以企业边缘为核心的SD-WAN

【
所有场景都是以企业方式进行展开，下一章节的运营商SD-WAN可以理解为满足企业组网的一张
Overlay网络，其支持任意POP接入全球可达，内部支持SD-WAN特性，外部支持最后一公里优化服务，
支持企业多租户。
】

这种思路是对传统的IPSec VPN方案的延伸[A]，在企业各个站点边缘[B]的CPE间建立隧道，如果要入云就在云里放一个Software CPE，无论是走Internet或MPLS或其他的WAN线路，只是传输质量有所区别的管道而已，企业的组网完全OTT在运营商的网络之上[C]。从放置的位置来看，CPE可放在企业的总部/数据中心/分支/服务网点，也可以在IDC/公有云的机房[D]，从组网的拓扑来看，可以是P2P/Hub & Spoke/Regional Hub/Full Mesh/Partial Mesh，等等。

【
A、  一种是使用VXLAN进行大二层组网，目前来看在企业侧未见有层二组网需求，而VXLAN一般用于
数据中心。
B、  CPE往往在企业NAT之后，由于在现网部署SDWAN的稳定性和安全性考虑，在SDWAN真正发挥作
用之前，企业习惯最大限度复用当前网络，而最好的部署则是将CPE单线接入核心交换机作为外挂旁
路。
C、  Overlay层虽然是一个管道，但还是需要关注部分运营商线路的情况以对管道进行分类部署，如
MPLS专线不需要加密。
D、  此位置的CPE就是后续文章中提到的云化CPE，企业在云端入网，云端提供安全和专线服务。
】

相比于传统的IPSec VPN，SD-WAN主要的增强可概括为以下几点：
在CPE里集成了WAN线路监测与协同[A]、应用识别的能力，支持为不同的应用提供不同的WAN处理策略，有效提高了WAN线路的投资回报率。
增加了一个控制器的角色，能够自动发现CPE，并向其地推送密钥和路由，省去了复杂、易出错的手工配置，在一些场景下还可以实现路由的调优[B]。
CPE将安全和广域网加速的能力进行了集成，同时CPE还允许以虚拟机等形式提供其他增值服务并对其进行串接，用户可按需进行订购。
通过集中式的Portal，支持对上述以及其他功能的策略进行统一的管理与配置，并为网络、线路、流量、应用等提供了丰富的可视化能力。

【
A、  协同-WAN线路检测具备单点单向特性， 需要统一分析才能决策有效的线路质量，承接此统一任
务的一般交给业务控制器-“会当凌绝顶 一览众山小”。
B、  传统厂商由于路由控制技术成熟通常采用传统分散路由学习方式，但SD-WAN中由于控制面的高
度协同性，部分控制业务需要集中管控。
】

4.1.1 产品设计

考虑到CPE的定位，它对功能的灵活性有很高的要求，不过对于IO性能的要求一般不是很高，因此CPE大多都是基于x86架构进行设计与实现的，很少见到专用的ASIC。软件形态的CPE，自然也大都是基于x86来做。对于面向移动或者IOT场景的产品，也可能会基于ARM来做，但是目前来看还不是很普遍。
CP（控制面）、DP（转发面）和SP（服务面）[A]都是跑在x86上的，各个平面绑定不同的CPU。CP通常会运行在Host OS的用户态，而DP目前一般都会通过DPDK做IO加速，这样DP也是运行在Host OS的用户态，根据性能的不同要求占用总核数的50%-80%或以上。SP用来内置VNF，形态上是虚拟机或者容器，以便与Host OS中的CP、DP进行隔离。同时由于VNF的处理通常是CPU密集的，因此集成SP的CPE通常需要额外的CPU，或者提供一定数量的x86板卡插槽。另外，SP可能对于存储也会有所要求，这时可提供相应的DRAM和SSD能力。这种能够为各种VNF提供一体化的集成平台的，资源高配的x86 CPE，也被称为uCPE。

【
A、业界在这三面的专业术语上略有些分歧，但表达的意思基本是一样的。管控概念在区分有点模
糊，本是一体，上述CP面是管理面（主要对应网管）；DP面是业务面（主要对应业务流量转发路
径）；SP面是控制面（又称业务控制面，支撑业务的全局处理）。
】

从网卡上来看，要支持DPDK实现DP的高速收发，可选支持直通或者SR-IOV为部分VNF提供原生的IO性能。网口的数量上，WAN口1-2个，LAN口2-8个，速率上面向SMB（Small or Medium Branch）的产品10-100Mbps即可，面向标准企业分支的产品在100-500Mbps间，面向大型企业分支/总部/数据中心的产品通常定位在500Mbps-2Gbps或者以上。不过考虑到IPSec，这些物理接口在真正带业务的时候，吞吐量通常都会打上一定的折扣。接口的封装上RJ-45必选，一些产品会添加SFP方便接光纤。在一些SMB的产品中还会提供POE/POE+的能力。除了以太口以外，CPE上还需要集成一些其它类型的接口，LAN侧可选支持WiFi主要面向SMB，WAN侧的T1/E1、xDSL
、Cable和3G/4G等，可根据产品投放地区的实际情况进行选择，3G/4G可通过USB转接或者内置SIM卡和天线[A]。

【
A、通用uCPE在接口类型和数目上不建议做成路由盒子方式，即使在实际业务环境中有此需求，也仍
然建议使用可扩展的多业务卡方式。
】

出于一些专用场景的考量，CPE中可能还会内置一些协处理器，如用于IPSec加解密的加速器，又如用于提高统一通信能力的DSP。另外，相当一部分厂商还会在CPE中内置TPM芯片，用于CPE的身份认证。

对于控制器，不同的SD-WAN方案会有不同的设计。这里所说的控制器是广义上的，主要的功能会包括Staging、Control和Analytics。Staging主要实现认证和自动发现，和CPE间通常采用私有协议，条件允许的话可以使用DHCP扩展项。Control主要实现密钥和路由分发，与CPE间的协议可采用OpenFlow/BGP/Netconf等等，使用私有协议的也很多。Analytics主要实现数据采集和分析处理，与CPE间的协议如NetFlow/IPFIX/SNMP/Syslog等等。控制器的北向上多以RESTful API为主。

控制器的部署位置，可以是放在企业本地On-Premise的，可以放在数据中心甚至是在CPE上开虚拟机，也可以是放在云上的，拥有一个可访问的IP地址即可。考虑金融、零售、餐饮等SD-WAN主要的目标客户的分支站点规模，一套控制器的集群可能会需要带起数以千计的CPE[A]，实际上这也是很多厂家会采用私有控制协议的原因之一，做的越定制化越轻量，性能就越容易把握。

【
A、在零售业中，Overlay承载数量较多且地理分散的CPE，此规模部署下，同时需要考虑控制器的集
群和主备问题。
】

Portal的设计就是见仁见智了，比较关键的有三点。一是应用WAN策略的默认模板，虽然SD-WAN的一个突出的亮点就是能够管理基于应用的WAN处理策略，但是相当一部分的客户只关注结果而不关注过程，这时候就需要一个默认的策略模板，把应用需要什么样的线路质量内嵌到系统中，然后自动生效。另外一点是对Tag机制的支持，为不同的对象（比如站点、设备、应用等[A]）打上不同的标记，然后可以为每个标记制定一份策略（路由、安全、QoS等）并统一生效。第三点，要支持报表的定制与输出，保证SD-WAN的可审计。Portal的位置，同样可以是企业本地或者在云中。

【
A、应用标记比较容易理解，特加是在智能选路上，而对于设备和站点进行标记， 唯一考虑到的就是
站点/设备的组网性能和安全，如某设备转发性能较低，某站点带宽较低，故而对于低层的组网和设备
状态是管理面是需要统筹管理从而影响流量转发。
】

4.1.2 关键特性与实现

ZTP（零接触部署）

零接触部署，可以理解成就是CPE的上线，也可以理解成CPE上线加上控制器把业务打通的全过程。这里按第一种理解来说，控制器的逻辑拆到后面介绍。

首先，每个CPE要有唯一的标识，这个标识可以是发货前配好的，有条件的话可以固化在硬件中，对于Software CPE的话一般在拉起的时候会生成序列号并完成注入。这个标识需要被手动录入或以其他方式注册到系统中，以便后续的识别。等到客户收到CPE并加电后，CPE会通过DHCP/PPPoE来获取IP地址，后续即利用这一IP地址进行通信[A]。之后，CPE要去自动获取控制器的信息，包括IP、端口和认证信息等。获取的方式也有很多，发货前厂家给配好是可以的，但是效率比较低。客户自己手动开局也是可以接受的，方式上包括扫二维码、根据短信做配置、邮件注入、USB注入等等。如果要做成即插即用，可以加电后触发DHCP/DNS来请求控制器信息[B]。获取到信息后，CPE会主动去找控制器，彼此之间完成双向认证[C]，认证成功后就可以通信了。

【
A、  打通Underlay Internet上网需要，当然可能是静态IP入网，此条件保证CPE与控制器/网管之间的
通路，这是任何网络设备入网的前提。
B、  DHCP采用扩展选项携带网管/控制器信息，需要考虑支持网管/控制器的负载或主备特性。
C、  双向认证应该在保护的通道之内，通过采用开局时的预置密钥方式，使用SSL或IPSEC实现双向
认证保护。
】

Underlay路由

Underlay方面，保证隧道目的地址的路由可达是在CPE间建立隧道的基础。如果CPE是单根WAN线路接入，直接利用DHCP或其他方式分配到的默认路由即可。如果CPE是两条Internet线路接入，要考虑好默认路由的策略，是采用主备还是明细，尽量避免出现次优路径，而网络运营商的uRPF可能使得Underlay的连通性存在问题，此时可能需要为特定隧道绑定特定的线路出口[A]。如果CPE是Internet和MPLS混合接入，那么还要考虑Internet与MPLS网络间的连通性，通常是MPLS网络可主动访问Internet，而Internet网络不可主动访问MPLS网络，路由设计上可以是默认路由走Internet线路，MPLS网络的明细路由走MPLS线路，也可能是根据线路质量与其他策略进行选择，这在后面2.8与2.9小节的内容中会再次提到。另外，由于一些协议和隧道习惯上会起在环回口上，这时环回口的地址和路由也都需要控制器去做规划和配置。如果出于可用性的考虑，IPSec或者其他的最外层隧道也要起在逻辑口上，那么还需要确保该逻辑口在网络运营商中的可路由[B]。

【
A、  此动作可避免uRPF方式，但从另一方面考虑：由于运营商网络的全球可达性，到特定隧道的路
径不一定是最优的，如报文DIP所属为联通段，缺在出口选择到了电信的线路，导致南北问题，故而
在出口设备（不一定是CPE）需要保证路径的最优，避免流量绕行。
B、  逻辑口地址使有静态IP方式，需要CPE启用路由协议分发至运营商网络，以使各CPE Underlay可
达。对于建立在逻辑口上的VPN，需要至少满足底层有两条物理线路，才能保证可靠性。而于对不同
运营商的多线接入，由于SD-WAN分流要求，VPN必须建立在物理线路由，当然同一个运营商的多线
接入就没有必要，可选择环回口方式。
】

打通Underlay还面临着NAT的问题。如果企业分支没有公网IP地址，或者企业分支出口有公网IP，但CPE部署在企业内网中无法使用到出口的公网IP地址，那么在跨越Internet的时候，无论是在CPE间建立隧道还是CPE与控制器间的通信，都需要穿越网络运营商的NAT设备。应用如何穿越NAT是老生常谈了，ALG/STUN都可以，不过GRE/VxLAN作为隧道原生上都穿越不了NAT，IPSec通过NAT-T是可以穿的，只要隧道一端的CPE有公网IP[A]。因此IPSec的好处不仅是安全，而且在穿NAT方面也有先天的优势。数据面基本上都需要over IPSec，控制面上OpenFlow可以原生穿越，Netconf需要Call-Home机制来实现穿越，而BGP则需要通过over 在IPSec之上，私有的控制协议则可以自己设计机制来穿越NAT。

【
A、  使用开源STUN联动IPSEC实现NAT穿越，但实际用户部署中，往往仍然选择由HUB中转，一方
面SPOKE组网基本上都位于NAT之后（中国至少是这样，欧美国家本身资源丰富，基本无SD-WAN需
求），穿越成功性极底；另一方面，穿越成功后的稳定性极差，不利于企业内部组网。个人觉得，
SD-WAN目标之一是降低企业网络资费30%，也就最多30%的流量会通过宽带进行，而这30%中， 通
过部署高性能HUB中转能满足大多数延迟需求（中国南北，东西传输时间约30ms，中转后最多
60ms，能满足大多数应用需求）。企业最先看中的是SD-WAN的SD部分，而非WAN优化部分，即可
软件自定义+可视化运维。
】

Overlay路由

传统的IPSec方案中打通Overlay的方式，LAN侧主要是静态路由或者IGP，隧道侧通常是IGP over GRE逻辑口，当然也可以选择手配静态路由，或者做IPSec的反向路由注入[A]。多点VPN的话，以Cisco的DMVPN为例还需要NHRP和多点GRE，其他厂家如果有多点的方案的话，基本上也都会采用类似的技术[B]。

【
A、  IPSEC反向路由注入适用于末端桩网络，SPOKE将本地LAN侧路由反向注入到SPOKE引入下行
流量，上行流量通过默认路由导向HUB。
B、  华为称DSVPN，此类技术基本上都采用MGRE+IPSEC+NHRP方式，而NHRP方式个人觉得比较
繁重，完全可以由业务控制器代替，华三的方案是最优的选择。此方案思科称DMVPN更合适，而华为
的DSVPN称呼中以为看到了智能VPN建连技术，但事实S未在VPN上体现，更多的在智能选路层面。
】

对于SD-WAN而言，由于LAN侧也可能会接入路由器，因此CPE需要保留IGP的能力，隧道侧主流上是由控制器来集中完成隧道的建立和路由的分发[A]，CPE需要完成LAN侧和隧道侧的路由重分布。CPE与控制器交互路由的手段有很多，BGP/OpenFlow/Netconf都可以，私有协议也很常见。具体的选择上，主要取决于厂商的技术背景，比如传统厂商或者从传统厂商跳出去的创业公司，可能会习惯采用BGP/Netconf，如果SDN背景较强OpenFlow会容易上手一些。采用私有协议的也不在少数，其好处是可以实现的非常轻量，而且不仅仅是控制面，有的厂商连隧道的封装，甚至CPE里的协议栈都自己定制了。如果企业客户并不考虑跨厂商互通，对于开放性也没有要求，那么标准化的必要性确实就比较弱了。

由于控制器的存在，路由可能会采用集中分发的方式，此时就不用在隧道上运行IGP，此时GRE的必要性就不再明显，而点对点和点对多点在实现上也区别不大。一些SD-WAN方案对于Overlay在隧道侧的路由仍然选择保留了传统的控制方式，路由是否集中到控制器上，并不是SD-WAN的唯一判别标准。

【
A、传统通信类公司，如华为，由于具备丰富的底层组网的技术实现，而SD-WAN无非是Overlay的一
张虚拟网络，传统技术基本可以满足。初创公司由于技术准备不足，同时参照SDN方案，基本都会选
择集中控制方式。由于智能化需要有全局视野，基于中心业务控制器的方式，个人觉得会越来越有必
要，并且会成为SD-WAN的通用实现技术。
】

组播与服务链

组播是可选支持的，可用于电话或者视频会议，如果支持的话一般也在会归在高档的License中提供。CPE上开启IGMP和PIM，收集组播组成员信息并反馈到控制器上，控制器形成全局组播拓扑，再向相关的CPE去分发组播路由。CPE和控制器间一般用私有协议来实现组播路由的分发。
服务链的话对于uCPE来说必选支持，由于涉及到策略问题，因此只能通过控制器去集中地控制服务链的路径。通过Netconf配置PBR，BGP引流，OpenFlow引流，或者私有协议发布Service路由都是可以的。如果PNF或者VNF都是部署在CPE本地，是不需要走隧道的，如果要求集中部署在总部做统一处理，就需要通过隧道送过去了。目前NSH支持的还很少，在串接多个服务的时候，可对流量标记Service标签，相当于起到NSH中Service Path Index的作用，再额外地对于入端口进行识别，相当于起到NSH中Service Index的作用。

混合云的连接

入云面对的还是隧道、加密、NAT穿越这些老问题，IPSec仍然是可以搞定的，并不需要特殊的新技术。不过在公有云侧，除了一些超大的客户可以在资源池的机房里放硬件的CPE，绝大部分的客户都只能用纯软的CPE。部分SD-WAN厂商已经把产品放到了公有云的Market Place中，以SD-WAN VNF的形式直接按需提供给客户。如果还没放到Market Place，客户也可以在VPC中申请一个新的虚拟机，自己动手来装一个Software CPE进去。在实际的部署中，需要利用公有云提供的路由API去控制混合云流量的分流[A]。另外，大多数运营商会自己提供VPN网关产品实现入云，不过其组网能力较为单一，接口的权限可能并也不会开放给SD-WAN的控制器，比较难于纳入到SD-WAN的体系中来。

【
A、混合云整体仍然是企业自建的私有云，仅部分SPOKE在云端入网，利用到云端的安全机制和云专
线。而云端可以是vCPE，也可以是具备安装或启用VPN服务或软件的云主机，但仍然通过路由分流，
需要打通云端vCPE或主机的路由。此方案与SD-WAN服务商大同小型，可能不同的在云主机或vCPE
的复用性上，后者由于高度复用vCPE，通过VRF实现多租户，在运营资费上会更具优势。
】

为了打通IPSec，站点侧和云侧至少要有一个公网可访问的IP地址，如果是云侧需要这个地址，就需要在公有云上申请一个弹性IP地址并关联到Software CPE所在的虚拟机上。一端面向企业本地的设备，一端面向云侧的设备[A]，具体部署中需要考虑好放置控制器的位置。另外，要注意放开Software CPE所在虚拟机的安全组的限制
，否则流量会被直接丢弃掉。目前来看，企业做混合云主要还是为了打通三层，在站点和公有云间做二层的需求比较少见，公有云自身也不会提供与企业间打通二层的产品与服务[B]。

【
A、  面向企业本地使用弹性IP服务于本地CPE（一般是瘦CPE），而面向云端的是私有IP，用于与云
端另侧vCPE打通内部路由，由于云端的高度稳定性，可采用静态路由，当然云端私有IP不能对企业侧
呈现，需要在其上包装为GRE透传数据。
B、  企业侧一般无大二层组网需求，但如果企业服务全部移至云端，则可能存在二层需求，此时需要
提供VXLAN隧道技术，可使用GRE+BGP组网。
】

Internet流量的处理

除了打通VPN以外，由于CPE的位置放在了站点的边缘，因此站点访问Internet的流量也是由CPE来完成处理[A]。访问Internet有两种流量模型。第一种是分支的Internet流量先送到总部/数据中心，防火墙的统一过滤后再送到Internet上，那么控制器可能要修改分支CPE上的默认路由和IPSec兴趣流，覆盖掉网络运营商分配的默认路由，并通过IPSec将Internet流量回传总部/数据中心。第一种方式的好处在于可以做到安全的集中部署与管理，但是流量绕行后会带来时延的增加，而且对于总部/数据中心的出口带宽提出了较高的要求[B]。

【
A、  由于SD-WAN部署首先对现网优化，按现网的常规部署方案，CPE通常采用单线外挂，旁挂入网
的方式，所以常规的就是LAN侧入网，在LAN侧另一台设备入Internet。
B、  反观流量模型，大多数统量属于CS类型，较少有P2P类型，而业务服务器通常部署在中心站点。
】

第二种是企业分支CPE上保留网络运营商分配的默认路由，IPSec兴趣流也要放行Internet流量到Internet线路上，实现CPE的本地分流，从而降低了时延，并减轻了总部/数据中心的带宽压力。不过，这对于CPE的NAT能力提出了较高要求，一般要支持有状态的会话机制。另外，本地分流还必须要解决安全的问题，否则公网上的流量一旦攻破分支CPE，不仅会对该分支造成影响，还可以通过VPN跳入总部的数据中心，形成不可接受的损失。CPE需要支持ACL以及防火墙的一些高级策略，uCPE也可以通过Service路由把IPS/WAF/NGFW等串接到Internet流量的路径中，实现更为高级的安全防护。另外，也可以把Internet流量通过IPSec就近地向云中进行牵引，使用云化的安全服务来保障。

在各种Internet流量中，SaaS服务于企业办公，需要得到优化与保障。在分支CPE上进行Internet流量的本地分流，可缩短SaaS流量的访问路径，同时结合DNS嗅探/代理[A]和SaaS质量监测等手段，可以有效地对SaaS流量的访问目标进行优化。另外，CPE要具备识别SaaS流量的能力，提高其在WAN口的转发优先级，对于其他非办公用途的Internet流量，在WAN口上进行限速或者直接丢弃掉。

【
A、  DNS网络对网络提速相当明显，由于基于HTTP的业务的瞬发性和不可预期性。一方面是实现本
地DNS代理，另一方面是DNS就近引流。
】

面向应用的处理

SD-WAN最原始的出发点之一就是应用路由，其前提是要能够对应用进行准确的识别。识别的手段有很多，最常用到的是DPI[A]，CPE收到数据包后，先进行预分类获取流的信息，并亲和均衡到不同的核上进行深度检测[B]。逐包模式下，所有的数据包都要经过检测引擎处理，性能较差。逐流模式下，流的前几个数据包走普通的路由转发，同时被镜像给检测引擎，当完成识别后，引擎会将流与应用间的映射关系缓存在转发面，该流后续的数据包将直接匹配缓存来识别应用，避免再次绕行检测引擎，提高处理的效率。DPI的特征库需要支持在线升级，同时也应该允许用户自己对应用的特征进行定义。

【
A、  实际应用场景中，企业内部网络所有办公流量是五元组识别的，基本上无需使用到DPI，并且大
多数流量为HUB-SPOKE模型，极少有P2P类型流量。但Internet流量就存在多样性，基于安全性考
虑，有必要进行DPI。
B、  可见技术实施上DPI处于控制层并且与转发层处于同一个处理单元。为提高流识别性能，可利于
SD-WAN分布式组网的特点，将DPI结果汇总到业务控制面进行统筹。
】

DPI难以处理加密的流量，而当前的Internet上HTTPS流量的占比很大，有相当一部分的SaaS流量都是承载在HTTPS上。对于这些HTTPS流量，一种思路是实现SSL卸载，帮助DPI完成加解密，不过这种方式的实现目前还比较少。另一种思路是绕过DPI通过其他的方式来识别应用，比如可以通过对于流的行为模式进行观察与分析来判别应用，比如可以通过监听DNS来记录目的IP和URL的关系，这样看到目的IP就可以大概知道这个流所属的应用，或者直接内置一个周知的IP列表，虽然简单但是也不失为一种有效的手段。

匹配出应用后，流量可能会被进行标记[A]，后续包括路由、QoS、安全、广域网加速、监控与分析等等，都应该支持围绕着应用的标记来进行差异化的处理，实现完整的面向应用的处理，而并非单纯的应用路由。

【
A、  DPI识别出应用后作用于转发，而应用转发策略则依赖于流量特征，结合用户下发应用模板或策
略模板作用后，标记流特征：应用IP、所属分类、所属VPN、所属带宽、优先级等。
】

WAN线路的监测

除了应用路由以外，基于线路质量进行转发是SD-WAN另外一项重要的能力。线路的质量主要包括丢包、时延、抖动等几个方面[A]，当线路质量出现波动时能够动态地调整应用的转发线路，以保证应用的SLA，这就要求CPE能够对线路的质量进行测量。测量的方式可分为被动和主动两种，被动测量是根据实际业务流的统计信息来进行分析，主动测量是指在业务流外生成探针来进行探测。被动测量基本上都是厂家私有的方式，主动测量常见的手段有ICMP/BFD/CFM/OWAMP/TWMAP等等。得到测量数据后，厂家会采用私有的算法对数据进行处理，得到线路QoE的评价值，并与控制器推送的SLA策略进行比较，如果不能够满足SLA，CPE本地可能会自动触发线路的切换[B]，以保证其实时性。

【
A、  线路质量监测依赖于检查机制或流量条件，结果仅作为线路质量的参考条件之一，更多的需要结
合运营商线路的特点进行额外加权，包括有线/无线、宽带/专线、带宽、甚至于时间段。
B、  线路切换一定是端到端的策略，需要有“上帝视角”进行统一切换，线路质量结合流量工程进行。
另外，线路切换说法可能不太准确，某些时间需要线路分担，并结合传输优化进行。
】

另外对于WAN线路还要探测MTU，因为CPE可能会对原始的数据包进行隧道的封装，如果MTU选择的不恰当的话，会导致大量分片的出现，不仅会多占用WAN线路的带宽，而且还会降低转发的性能。解决这个问题通常有两个方法，第一个方法是路径MTU检测，即PMTUD，CPE会去主动地探测WAN路径上的最小MTU[A]，从而更准确地了解WAN的传输参数。第二个办法是TCP MSS插入，CPE可以监听TCP的SYN[B]，并根据自身所采用的封装格式，去插入合适的MSS值，减小主机发来出的包的长度，从而避免分片。将这两种方式结合起来，可以获得较为理想的数据包长度。

【
A、  路径MTU探测可结合VPN报文的分片情况自适应，一般适用于较大块文件传输的情况，避免过多
分自片对带宽的占用的同时，减少分片重组的压力。相对于MTU的探测，小包的传输性能优化更为重
要，由于小包经常被忽略，大量密集的小包几乎占用相当一部分的加密性能，提升小包传输能力利于
性能优化。
B、  SYN优化结合PMTU进行， 并且是端到端的检测，并应用到出口。网络中大包基本上基于TCP
的，如HTTP图片或FTP。
】

WAN线路间的协同

一些大型的企业站点通常会采用不同的WAN线路进行接入，比如双Internet、Internet与MPLS混合等，随着4G/5G/LPWAN的成熟与发展，未来无线也可能会成为WAN线路篮子中的一个重要选择。有了应用识别，有了WAN线路监测，还需要在不同的WAN线路间进行有效的协同，提高整体的利用效率。WAN线路间的协同，通常也被称为WAN Bonding，把多条WAN线路打包在一起为流量传输提供服务。Bonding可以是逐流的，通过哈希将不同的流静态地映射到不同的WAN线路上去，这种实现较为简单，不过无法有效保证应用的SLA。

SD-WAN重最常被提到的是基于应用的Bonding[A]，即根据应用对于SLA的要求，结合应用识别与WAN线路监测的结果，将不同应用的流量分配到不同的线路上去，不过WAN线路整体的带宽利用率未必实现最优。Bonding也可以是逐数据包的，这种方式的话主要是优化Bulk流量[B]，如大文件传输，WAN线路的带宽利用最为充足，但是需要在对端进行数据包重排，这反过来在一定程度上会降低转发的性能。

【
A、  实际应用中应使用WAN bonding和应用 Bonding相结合的方式，避免流分布的不可预期性或稳定
性。初始流都是按WAN bonding传输，仅在检测到某WAN线路符合某应用基本通信要求时切换，并在
不满足时回切。整个过程要避免频繁换档，并且考虑换档后的QOS策略影响到其它应用流，所以需要
一定的资源预留保障，此SD-WAN SLA保障肯定是无法完全利用线路资源的。
B、  相当于逐流模式，逐包模式属于饥饿型转发，最大限度榨干带宽，适用于传输大文件并且无其它
过多应用对带宽的需求前提下（如测试环境）。
】

WAN Bonding还有一个要求，当WAN线路监测的结果说明一条线路的QoE不好的时候，要切换到其他的线路上，或者均衡一部分流量到其他线路上。值得注意的是，如果目标WAN线路上存在防火墙或其他带状态的中间件，直接做切换很可能会导致流量的中断，因此在做部署时，要考虑好WAN线路和中间件间的有效联动。另外，一些SD-WAN方案还支持允许两个站点CPE间的流量，在来去两个方向上选择不同的WAN线路进行传输，当然这也需要在考虑中间件的情况后再决定是否启用。

广域网加速

【
具备有技术实现的企业可以将此部分作为传输优化的特点，但传输优化更多的适用于传输条件不稳定
且恶劣的线路上。SD-WAN中做好线路的大协同应基本适用于大多数应用了，并且提升优于采用种种
复杂技术带来的加速。好比无线信道，肯定不是视频通信的首选，既然选择了肯定是保障质量的可靠
性而非带宽量，种种优化方案还不如DUP来自直接。总的来说，全局线路协同是首选，是SD-WAN的
核心，后者是增强手段。
】

要提高WAN的利用率，除了在不同的WAN线路间做协同以外，各种加速处理也是需要的。传统的广域网加速需要专用的、昂贵的硬件设备，而在大部分的SD-WAN方案中CPE中都内置了相应的功能，少数方案中即使CPE自身不具备广域网加速的能力，也可以在本地起相应的VNF并进行串接。

广域网加速主要包括以下几个主要方面：数据压缩，采用一定的算法对包头或者载荷进行压缩/解压缩，以降低信息的冗余度；数据消重，对传输过程中出现频次较高的数据进行编号，并使用指针进行替换，以节约编码所占用的空间；内容缓存，将热点内容进行本地缓存，对热点内容的后续访问即可在本地直接返回，避免了对于WAN线路带宽的占用；TCP优化，通过代理的方式将端到端的标准TCP切成多段，并对其中WAN一段的传输进行优化，改善标准TCP的拥塞控制和重传机制，或者基于UDP来增加吞吐量；HTTP和其他应用层协议优化，就需要具体问题具体分析了。

视频会议和VoIP等统一通信流量的优化对企业来说比较关键。FEC常用于对视频传输进行优化，发送方进行FEC编码，在原始数据包以外引入冗余校验包，接收方进行FEC解码，并通过冗余校验包对原始数据包的误码或丢包进行恢复，以降低由于WAN线路质量不稳定所导致的卡屏现象。Packet Duplication常用于对VOIP的传输进行优化，发送端对数据包进行复制，并通过不同的WAN线路进行传输，接收端会以收到第一份为准并忽略掉后续重复的数据包，不同的WAN线路丢掉同一个包的概率基本为0，使得VOIP的通话质量得到保障。

安全

安全贯穿着SD-WAN的方方面面。前面提到过CPE需要有一个唯一的标识，可以在出厂时配好也可以固化在硬件中，VNF在拉起的时候会生成并注入序列号，控制器的标识使用IP和FQDN通常就可以了。有了标识之后，系统中的各个组件间需要进行相互认证，防止非法CPE和控制器的接入，这块的实现可以通过外接LDAP/RADIUS来做，也可以通过PKI体系来做[A]，SD-WAN自身也应该提供认证服务器或者PKI服务器，如果企业自己有认证服务器或者PKI服务器，需要能够与其进行对接。

【
A、整机单元由控制器或网管进行接入认证，组件或第三方软件适用于通信通道认证，特别是对用户
开放的组件体系。
】

IPSec的实现需要两套密钥，第一套是IKE身份认证的密钥，第二套是数据流加密的密钥。第二套密钥在传统方案中是通过DH来分布式计算的，在一些SD-WAN方案中会直接由控制器来进行同步，并周期性地进行更新这个密钥，以提高密钥的安全性。实际上，如果使用控制器去分发第二套密钥，就相当于替代掉了IKE的作用，那么第一套密钥就不必再作用于CPE之间了，而是用于CPE和控制器之间的身份认证，这同样也可以通过PKI来搞定，省去了维护预共享密钥的麻烦。另外，考虑到对于NAT穿越的需求，IPSec一般都会采用ESP+隧道的模式。

数据转发的安全通常就是over在IPSec之上，控制信道的加密则取决于使用何种南向协议。如果是私有的协议的话over在SSL/TLS/DTLS上面就可以，Netconf和OpenFlow也都是原生over在TLS上面。BGP最好也是over在IPSec上，区别于传统方案中IGP需要通过GRE逻辑口来进行组播，BGP使用TCP做单播并不依赖于GRE。同时，原生BGP无法穿越NAT的问题，通过IPSec也可以得到解决。另外，还要防止CPE主控和控制器的DoS，通过一些策略来限制报文的上送速率。

至于业务层面的安全，Log、ACL、Zone-based FW是基本的要求，IPS/WAF/NGNW等通常需要通过Service路由去串接。如果是在总部/数据中心做集中式的安全控制，那么分支的流量就要绕到总部/数据中心去，如果是在CPE本地实现Internet流量的分流，也可以通过IPSec就近引流到第三方的SECaaS服务商进行云化的安全处理。
另外，考虑到包括金融、零售等目标行业客户的需求，SD-WAN产品还要尽量去符合PCI DSS，以确保为支付业务提供一个安全合规的网络传输环境。

高可用

和安全一样，高可用的设计也会贯穿到整个SD-WAN方案中。控制器的集群设计中，要注意的是控制器的工作性质。如果只是做纯配置类的工作，那么实际上对于性能的要求不是很高，通常采用主备模式即可。如果还要负担路由控制类的工作，考虑到某些目标客户的规模比较大，那么集群最好能支持多活的模式以进行负载分担，此时要求ZTP实现中，能够为不同的CPE指定不同的Master控制器。当控制器集群发生故障时，要求不影响到业务的正常转发。

相对而言，控制器的高可用多为IT层面的问题，而网络层面的高可用就非常复杂了，端口/设备/链路/隧道/路由/状态，要考虑的方面很多，而且彼此间还要设计好关联机制。因此，高可用的实现是需要代价的，要在可用性和成本间做好平衡。从物理拓扑来说，小型站点可采用单CPE+单Internet/MPLS线路，大型的分支可采用双CPE+单Internet线路+单MPLS线路，总部/数据中心可采用双CPE+双Internet线路+双MPLS线路，等等。

明确了物理拓扑后，即可根据CPE的数量以及Underlay的连通性来设计逻辑拓扑。对于LAN侧，如果是单CPE可以起Port Channel做链路的主备/负载均衡，双CPE如果接交换机可以用VRRP+基于VLAN的负载均衡，如果接路由器可以使用IGP+ECMP。对于WAN侧，如果是单CPE可以在不同的WAN线路上起不同的隧道，也可以在逻辑口上起一个隧道然后承载在不同的WAN线路上[A]。如果是双CPE，可以在同一条WAN线路上起两条隧道[B]，也可以使用VRRP起一条隧道[C]，还可以在两个CPE上起不同的隧道承载在不同的WAN线路上[D]。双CPE间可以进行横向连接，实现WAN线路的复用与保护。

【
A、  不推荐使用，此方式下线路检测是Underlay方式，并且转发面在最外层转发时涉及真实选路，应
用要流标需要直达此层选路上，实现复杂。推荐的实现的方式是前者，业务面统一在Overlay层体现，
并且自然分流。
B、  此区不区分假IP和公网IP，都需要双IP，在HUB层两条隧道连接两台不同的CPE。
C、  仍然需要双IP，但对LAN侧包装为一个虚拟网关IP。
D、  两台CPE肯定需要打通才能支持应用分流，并且CPE必须是双主控备份设备，否则一台掉电后，
此线路将无法切换到另一台。
】

当出现WAN侧线路不通的情况时，需要能快速地完成路由收敛与转发切换。如果采用控制器集中分发路由的方法，那么控制器需要实时了解不同WAN线路间的可达性，检测到线路断了之后需要能正确地推送新的路由。如果是在CPE间采用分布式路由，可以等到IGP/BGP的自然收敛，也可以通过BFD的手段来加快收敛。另外，如果CPE上要实现NAT、防火墙等有状态的业务，双CPE间就需要同步相应的状态信息[A]，而且还要考虑切换WAN线路后的路径对称性问题。

【
A、状态信息是线路切换需要考虑的条件之一，但不是首选条件，某些业务本身具备一定的搞切能
力，这里需要考虑的是安全问题，特别是防火墙路径。
】

其他关键技术与功能

除此之外，其他的一些技术点还包括：
QoS，需要提供Traffic Shaper、CAR、DSCP Mark/Remark、Queue、AQM、Tunnel QoS、HQoS的能力，并提供面向应用的QoS能力。
远程/移动接入，定位于总部/数据中心的CPE，可选地支持L2TP和SSL VPN[A]。
Wifi管理，定位于小型分支的CPE，可选提供Wifi的认证、频段管理等能力[B]。
VRF隔离，提供Intranet、Extranet间的隔离，常见于对Guest网络进行控制。
时钟同步，可通过NTP为SLA提供精确的时间信息。
CPE可管理性，提供远程文件拉取、远程重启、不中断升级的能力[C]。

【
A、  相当重要的办公能力，不同于CPE，此方式更多属于VPN LAN侧接入控制，并且接入点不限于总
部/数据中心，但都需要有接入安全、路由、管理的基础条件。
B、  部分AC管控能力，结合下述来宾和办公在路由面进行分隔。
C、  简化运维的有效手段之一，运维是SD-WAN的核心，除对接本文档相关技术细节外，对外用户的
呈现UI关系产品成败。
】