从2016年底开始，国内讨论SD-WAN的声音一直不绝于耳，相信经过这么长的时间，大家对“SD-WAN是什么”都有了一定的了解，但是对于“SD-WAN是怎么实现的”，估计大部分同学还是没有摸到任何的路数。写这篇文章，就把SD-WAN这层技术的面纱给揭开，争取帮大家从60分的“及格线”提高到85分的“准优秀线”。
全文纯文字无配图，需要一定的传统网络与SDN基础，适合于Networking Geek阅读。
文章太长，考虑到阅读体验，将分为上下两个部分。此为上篇，阅读时间在30分钟左右。
一、引言
这两年SD-WAN在业界可谓是众星捧月，在一些文章的过度包装下，非常容易让人形成一个错误的观念——SD-WAN是一种全新的方案。实际上，SD-WAN并不是石头里蹦出来的猴子，虽然有一些吸睛的新特征，但它仍然是根植在很多传统的传统企业级WAN技术之上的，主要包括路由、VPN、安全、WAAS等等，在下文对于SD-WAN的技术介绍中，会反复地提到这些传统技术，读者最好对相关的基础知识有所了解。至于SD，实际上SD-WAN并不能单纯地被划归到SDN的范畴下，它集成了WhiteBox/SDN/NFV/Cloud等多种新型手段，属于一揽子的解决方案。
硅谷从2011-2012年开始做SD-WAN，到现在也有6、7年了。最开始，SD-WAN在技术方案上是纯Overlay的，网络的连接和增值服务都在企业边缘完成，因此完全是OTT ISP的。大概从2016年开始，SP的角色开始被引入SD-WAN方案中，思路上两点主要的变化在于，网络连接上要考虑对接SP的Underlay，增值服务方面要考虑对接SP的TeleCloud。对于这两种思路，国外的一些说法分别称为“SD-WAN 1.0”和“SD-WAN 2.0”，实际上这两种方案并不是单纯的升级关系，准确地说，“SD-WAN 1.0”是“Enterprise Oriented”，而“SD-WAN 2.0”是“SP Oriented”，后面就用“Enterprise Oriented SD-WAN”和“SP Oriented SD-WAN”来指代这两种思路。
实际上，当SP的角色被引入SD-WAN后，SD-WAN在概念上似乎有了很多令人遐想的空间，是不是在广域网上做SDN就都能叫做SD-WAN呢？这个问题，从技术层面来讨论是很困难的，因为SD-WAN的名字确实是起得太大了。不过有一点可以确定的是，SD-WAN的出发点是对企业级的WAN进行增强，如果有哪家SP用SDN做了或改造了一个Backbone，但是这个WAN并不直接面向企业提供服务，那么严格来说它就不应该被纳入到SD-WAN的范畴中。当然，把一个SD-WAN方案跑在一个用SDN做的Backbone上也是没问题的，但这两者不宜混为一谈，更别谈有一些Backbone其实就没做SDN，只是靠着轻载来保证质量了。
搞清楚了SD-WAN是什么，下面就进入正题，来聊聊“Enterprise Oriented”和“SP Oriented”的SD-WAN分别都是怎么做的。上篇的主题是“Enterprise Oriented SD-WAN”，过两天的下篇再来聊“SP Oriented SD-WAN”
二、Enterprise Oriented SD-WAN
这种思路是对传统的IPSec方案的延伸，在企业各个站点边缘的CPE间建立隧道（如果入云的话就在云里放一个Software CPE），无论是走Internet或MPLS或其他的WAN线路，只是传输质量有所区别的管道而已，企业的组网完全OTT在SP的网络之上。从物理上来看，CPE可放在企业的总部/数据中心/分支/服务网点，也可以在IDC/公有云的机房，而从组网上来看，无论是P2P/Hub & Spoke/Full Mesh/Partial Mesh，各站点间逻辑上都是一跳可达。
那么SD-WAN给这种方案带来了什么提升呢？主要有以下几点：
- 在CPE里集成了应用识别，WAN线路监测，以及WAN线路协同的能力，为不同的应用提供不同的WAN处理策略，提高了WAN线路的ROI。
- CPE将VPN、安全和WAAS的能力进行了集成，同时CPE还允许以VM等形式提供其他增值服务，并通过SFC进行串接，用户可按需进行订购。
- 增加了一个控制器的角色，能够自动发现CPE，并向其地推送密钥和路由，省去了IP、IPSec、Tunnel、IGP、NHRP等的手工配置。
- 有一个集中式的Portal，对上述功能以及其他功能的策略，进行统一的管理与配置。
这些优势估计大家都听了无数遍了，不过它们都是怎么实现的呢？下面就来对Enterprise Oriented的SD-WAN进行一下解剖，讲讲其中的产品设计、关键技术与实现。
1、产品设计
先来重点看看CPE的设计。考虑到CPE的定位，它对功能的灵活性要求较高，而对IO性能的要求一般不是很高，因此CPE大多都是基于x86进行设计的，很少见到用于交换的ASIC。软件形态的CPE，自然也大都是基于x86来做，一些厂商的软件和硬件CPE的架构是完全相同的。对于面向移动或者IOT场景的产品，也可能会基于ARM来做，但是目前来看尚未成气候。
CP（控制面）、DP（转发面）和SP（服务面）都是跑在x86上的，各个平面绑定不同的CPU。CP通常会运行在Host OS的用户态，而DP的话目前一般都会做DPDK加速，这样的话DP也是运行在Host OS的用户态，根据性能的不同要求占用总核数的50%-80%或以上。SP的话用来内置VNF，形态上是VM或者Container，以便与Host OS中的CP、DP进行隔离，这要求Host OS支持虚拟化或者容器。同时由于VNF通常是CPU Intensive的，因此集成SP的CPE通常需要额外的CPU，或者提供一定数量的x86板卡插槽，另外SP可能对于存储也会有所要求，这时可提供相应的DRAM和SSD能力。
从网卡上来看，DPDK必选支持DP高速收发，直通或者SR-IOV可选为部分VNF提供原生的IO性能。网口的数量上，WAN口1-2个，LAN口2-8个，速率上面向SMB（Small or Medium Branch）的产品10-100M即可，面向标准Branch的产品在100M-500M间，面向大型Branch/HQ/DC的产品通常定位在500M-2G间。不过考虑到IPSec，这些物理接口在真正带业务的时候，吞吐量通常都会打上一定的折扣。接口的封装上RJ-45必选没说的，一些产品会添加SFP方便接光纤。在一些SMB的产品中会提供POE/POE+。除了以太口以外，CPE上还需要集成一些其它类型的接口，LAN侧WiFi可选主要面向SMB，WAN侧的T1/E1、xDSL、Cable和3G/4G等，可根据产品投放地区的实际情况进行选择，3G/4G可通过USB转接或者内置SIM和天线。
出于一些专用的考量，一些CPE的产品中还会内置一些协处理器，如用于提升IPSec性能的Crypto Accelerator，又如用于提高UCaaS能力的DSP。另外，相当一部分厂商还会在CPE中内置TPM芯片，用于CPE的身份认证。
对于控制器，不同的SD-WAN方案会有不同的设计。这里所说的控制器是广义上的，可能会包括的有Staging Server、Controller和Analytics。Staging Server主要做认证和自动发现，和CPE间通常为私有协议，条件允许的话可以用DHCP。Controller主要做密钥和路由分发，南向上各种形式都有，OpenFlow/BGP/Netconf都有，用私有协议的也很多。Analytics主要做数据采集和分析处理，南向上常见的有NetFlow/IPFIX/SNMP/Syslog等。北向上多以RESTful API为主。
控制器的位置，可以是On-Premise的，放在企业的数据中心甚至是在CPE上开虚拟机，也可以是base在Cloud上的，拥有一个可访问的IP地址即可。考虑银行和零售等SD-WAN主要的目标客户的分支站点的规模，一套控制器的集群可能会需要带数以千计的CPE，实际上这也是很多厂家会采用私有控制协议的原因之一，做的越定制化越轻量，性能就越容易把握，如果用BGP的话基本上就必须要分级了。
Portal的设计就是见仁见智了，个人觉得比较关键的有三点。一是应用WAN策略的默认模板，虽然SD-WAN的一个突出的亮点就是能够管理基于应用的WAN处理策略，但是相当一部分的客户只关注结果而不关注过程，这时候就需要一个默认的策略模板，把应用需要什么样的线路质量内嵌到系统中，然后自动生效。另外一点是对Tag机制的支持，把不同的对象（比如站点、设备、应用等）打上不同的Tag，然后可以制定一份策略（路由、安全、QoS等）统一对标记为Tag的对象生效。第三点，必须要支持报表的定制与输出，保证SD-WAN的可审计。Portal的位置，同样可以是On-Premise的或者在Cloud里面。
上述是一个宏观层面的介绍，下面将针对一些技术的关键点，介绍一下CPE和控制器上相关的实现细节。关于Portal，由于不涉及网络本身，因此后面就不详细说了
2、关键技术与实现
2.1 ZTP（零接触部署）是怎么实现的？
这看要怎么理解ZTP了，可以理解成就是CPE的上线，也可以理解成CPE上线加上控制器把业务打通的全过程。这里按第一种理解来说，控制器的逻辑拆到后面的问题里去说。
首先，每个CPE要有唯一的标识，这个标识可以是发货前配好的，有条件的话可以固化在硬件中，对于Software CPE的话一般在拉起的时候会生成序列号并完成注入。这个标识需要被手动录入或以其他方式注册到系统中，以便后续的识别。等到客户收到CPE并加电后，CPE会通过DHCP/PPPoE来获取IP地址，后续即利用这一IP地址进行通信。之后，CPE要去自动获取控制器的信息，包括IP、端口和认证信息等。获取的方式也有很多，发货前厂家给配好是可以的，但是效率比较低。客户自己去手动开局也是可以接受的，方式上包括扫二维码、根据短信做配置、邮件注入、USB注入等等。如果要做成即插即用，可以加电后触发DHCP/DNS来查Staging Server。获取到信息后，CPE会主动去找控制器，彼此之间完成双向认证，认证成功后就可以通信了。
2.2 Underlay是怎么打通的？
打通Underlay的路由是CPE间起隧道的基础。CPE上线后，控制器就会配置CPE上的Underlay路由。这里之所以需要用控制器来配，而不是走由DHCP或其他方式分配的默认路由呢？因为CPE很有可能接入不同的WAN线路，单纯靠某条线路上SP给的默认路由，很可能出现次优路径甚至不通的情况，如果是多SP接入的话，uRPF的存在也可能使得连通性存在问题。另外，由于一些协议和隧道习惯上会起在loopback口上，这时loopback的地址和路由也都需要控制器去做规划和配置。如果出于可用性的考虑，IPSec或者其他的最外层隧道也要起在逻辑口上，那么还要向SP宣告该逻辑口的路由。
打通Underlay还面临着一个严峻的现实问题。由于很多Branch没有公网IP或者固定的IP，这时在跨越Internet的时候，无论是CPE和控制器间通信，还是CPE间通信，都跑不掉要过SP的NAT/PAT。应用如何穿越NAT/PAT是老生常谈了，ALG/STUN都可以，不过GRE/VxLAN原生上都穿不了NAT，IPSec通过NAT-T是可以穿的，只要有一端有固定IP。因此XXX over IPSec的好处不仅是安全，而且在穿NAT方面也有先天的优势。数据面over IPSec基本上没跑了，控制面穿NAT时，OpenFlow是不用的，但BGP/Netconf通常要over IPSec（有条件改底层实现也可以不over IPSec），私有协议可以自己设计机制来穿NAT，注意要设计好保活防止NAT老化。
2.3 Overlay是怎么打通的？
传统的IPSec方案中打通Overlay的方式，LAN侧主要是Static或者IGP，隧道侧主要是IGPoverGRE，IGPoverVTI，或者直接手配Static，如果不起路由的话可以做RRI，有时还需要在一端做SNAT。多点VPN的话，以Cisco的DMVPN为例还需要NHRP和mGRE，其他厂家如果有多点的方案的话，基本上也都是照葫芦画瓢。
对于SD-WAN而言，LAN侧由于要接路由器，因此CPE需要保留Static/IGP/Redistribution的能力，隧道侧而言，主流上是由控制器来集中完成隧道的建立和路由的分发，这样一来，多点和点对点在实现上其实是没有什么差别的。交互路由的手段有很多，BGP/OpenFlow/Netconf都行，私有协议也很常见。具体用选择哪一种，取决于厂商的技术背景，比如传统厂商或者从传统厂商跳出去的创业公司，习惯上会用BGP/Netconf，SDN背景强的用OpenFlow会容易上手些。用私有协议的也不在少数，其好处是可以实现的非常轻量，而且不仅仅是控制面，有的厂家连隧道的封装，甚至CPE里的协议栈都自己定制了。其实对于Enterprise Oriented SD-WAN来说，通常不存在跨厂商互通，客户对于开放性也不怎么关心，这时候标准化的必要性确实就比较弱了。当然，SP Oriented SD-WAN是一番考虑了。
对于隧道侧的Overlay路由，也不排除一些SD-WAN方案中仍然保留了传统的控制机制。这其实丝毫不影响其技术的含金量，逻辑上都是一跳可达，集中不集中到控制器上，只是形式不通罢了，千万别因为刻板的观念给XXX产品扣帽子。
2.4 组播和服务链是怎么实现的？
组播是可选支持的，可用于电话会议或者视频会议，如果支持的话一般也在会归在高档的License中提供。CPE上跑IGMP和PIM，然后反馈到控制器上，然后控制器在向相关的CPE去分发组播的路由，考虑到IGMP和PIM无法跨Internet传播，因此CPE和控制器间一般用私有协议来分布组播的路由。
服务链的话必选支持，由于涉及到策略问题，因此只能通过控制器去集中地控制服务链的路径。Netconf配PBR，BGP引流，OpenFlow引流，或者私有协议发布Service Route都是可以的。通常来说，PNF或者VNF都是在CPE本地，是不需要走隧道的，但有时候一些增值服务要求部署总部，这时候就得走隧道送过去了。由于NSH目前支持的还很少，因此在串多个服务的时候，一方面可以给流量打上Service Tag，相当于起了Service Path Index的作用，另一方面通常还需要去额外地匹配inport，相当于起了Service Index的作用。
2.5 混合云是怎么实现的？
随着IaaS的成熟与落地，混合云的模式逐渐为市场所接受，其中的一个关键技术环节，就是如何打通企业站点与VPC间的连接。SD-WAN生于云计算的大时代中，作为新一代的企业WAN组网方案，“Cloud Ready”也自然成为了必选支持的功能。
从Enterprise-Oriented SD-WAN的角度来看，入云并不需要什么特殊的技术，还是隧道、加密、NAT穿越这些老问题，IPSec仍然是可以搞定的。不过在Cloud这一侧，除了一些超大的客户可以在资源池的机房里放硬件的CPE，绝大部分的客户都只能用纯软的CPE，部分厂商已经把产品做到了Cloud SP的market place里面，以SD-WAN VNF的形式直接按需提供给客户。如果还没上market place，客户则可以在VPC中起一个新的VM，自己动手装一个Software CPE进去。在实际的部署中，必须要搞清楚云中的路由结构，关键就是vRouter和Software CPE的位置关系，并在合适的地方去控制公网和VPN路由的分流。另外，很多大型的Cloud SP会自己提供Gateway作为不同租户入云的统一入口，不过这个Gateway的能力比较单一，接口的权限通常也不会开放给SD-WAN的控制器，因此很难纳入到SD-WAN的体系中来。
为了打通IPSec，站点侧和云侧至少要有一个公网可访问的IP地址，如果是云侧需要这个地址，就需要向Cloud SP申请一个Fixed IP。一端配本地的设备，一端配云侧的设备，在做具体部署时要为控制器选好合适的位置。
如果有通二层的需求的话，就要VxLAN或者VxLANoverIPSec，然而实际上换了封装二层也很难通起来。如果VPN的路由结构是vRouter—Software CPE两跳，那隧道出来后是没法直接接到Subnet上的。即使VPN的路由是直接走到Software CPE上，二层的流量也还是过不了安全组这一关。解决的办法，要么Cloud SP允许修改默认的VM安全策略，要么找个地方裸放CPE，从vSwitch打VxLAN到这个裸CPE上。不过目前来看，企业做混合云主要还是为了打通三层，在站点和VPC间做二层的需求是比较少见的。
2.6 公网的访问是如何实现的？
除了打通VPN以外，由于CPE的位置放在了站点的边缘，因此站点访问Internet的流量也是由CPE来完成处理。从LAN的策略来说，访问Internet可能需要单独做认证，这时CPE需要提供WEB认证的功能。从WAN的策略来说，Internet流量要做限制，免得一些非关键流量占用宝贵的WAN线路带宽。这就需要CPE具备识别HTTP/HTTPS流量的能力，对SaaS办公流量提高优先级，对于其他非办公流量，进行限速或者直接丢弃掉。
访问Internet有两种流量模型。第一种是分支的Internet流量先送到总部/数据中心，经过总部/数据中心的防火墙的统一过滤后再送到Internet上，那么控制器需要向分支CPE下发一条默认路由，通过隧道指向总部的CPE，覆盖掉WAN口上可能被SP分配的默认路由。第一种方式的好处在于可以做到安全的集中部署与管理，但是流量发生了绕行，而且对总部/数据中心的带宽要求比较高。第二种是分支直接把Internet流量送到Internet上，这种方式被称为DIA（Direct Internet Access）。DIA对于CPE的要求就比较高了，首先CPE上要有丰富的NAT能力，包括NAT/PAT、NAT Server、双向NAT等，需要支持带状态的会话能力。控制器在下发IPSec规则时，需把NAT后的流量排除在IPSec的兴趣流量以外，否则就又被送到总部去了。
部署DIA还必须要解决安全的问题，否则公网上的流量一旦对分支CPE发起攻击，不仅会对该分支造成影响，通过VPN还可以跳入总部的数据中心，这种损失是不可接受的。首先，CPE会内置一些ACL或者防火墙规则，尽量做到不同区域间隔离，其次可以通过Service Route把IPS/AV/UTM/NGFW串到路径中，实现一些高级的防护。另外，也可以把DIA的流量就近地引到云中的安全服务中（如ZScaler），实现更为专业的安全策略。
2.7 面向应用的处理是怎么实现的？
SD-WAN的一大亮点就在于能够识别出应用，并据此进行后续的处理。应用的识别是基础，识别的手段有很多，最常见的是DPI，多数为基于x86架构实现的。收到数据包后，先进行预分类获取流的信息，并亲和均衡到不同的核上进行深度检测。检测可以有逐包和逐流两种检测模式，逐包模式下所有的数据包都要过检测引擎，性能较差，目前用的很少。逐流模式下，流的前几个数据包走Normal IP-based Processing，同时被镜像给检测引擎，当完成应用类型的识别后，引擎将流与应用间的映射关系写入datapath的缓存中，该流后续的数据包将直接匹配缓存进行APP-based Processing，从而绕过检测引擎，提高处理的效率。DPI的特征库需要支持在线升级，同时也应该允许用户自己对应用的特征进行定义。
DPI的问题在于难以处理加密的流量，当前的Internet上HTTPS流量的占比很大，有相当一部分的SaaS流量都走HTTPS，因此SD-WAN必须要找到办法来处理这些HTTPS流量。一种思路是实现SSL卸载，使得DPI可以完成加解密，不过实现这种思路的厂商目前比较少。另一种思路是绕过DPI通过其他的方式来识别应用——比如可以通过DFI来分析流的行为模式来确定应用，但是DFI太粗了且不适合短流，再比如可以通过DNS Snooping来记录目的IP和URL的关系，这样看到目的IP就大概知道这个流所属的应用了，或者直接内置一个周知的IP List也可以起到相同的作用。
匹配出应用后，流量会被标记metadata，如APP ID和APP Attribute ID，后续包括Routing、Monitoring && Analytics、QoS、Firewall、WAAS都应该支持围绕着APP ID和APP Attribute ID来进行差异化的处理，实现完整的APP-based Processing，而并非单纯的APP-based Forwarding。
2.8 WAN线路的监测是怎么实现的？
除了“面向应用的转发”以外，SD-WAN还能提供“基于线路质量的转发”。线路的质量主要包括Loss/Latency/Jitter/Utilizaiton几个方面，当线路质量出现波动时能够动态地调整应用的转发线路，以保证应用的SLA。这就要求CPE能够对线路的质量进行测量，测量的方式可分为被动和主动两种，被动的意思是根据实际业务流的统计信息来进行分析，主动的意思是指在业务流外生成Probe来进行探测。被动的测量基本上都是厂家私有的方式与算法，主动测量常见的手段有ICMP/BFD/CFM/OWAMP/TWMAP等等，如果是要测量SaaS的QoE，通常就用HTTP PING。为了保证实时的线路切换，控制器只负责推送SLA策略，而具体的执行需要在CPE本地完成。
另外一个关于WAN线路的探测是MTU，因为CPE可能会对原始的数据包进行多次的封装，如果MTU选择的不恰当的话，会导致大量分片的出现，不仅会多占用WAN线路的带宽，而且重组还会降低性能。解决这个问题有两个方法，第一个办法是PMTUD（路径MTU检测），CPE会去主动地探测WAN路径上的最小MTU，从而更准确地了解WAN的传输参数。第二个办法是MSS插入，CPE可以监听TCP的SYN，并根据自身所采用的封装格式，去插入合适的MSS值，减小主机发来出的包的长度，从而避免分片。将这两种方式结合起来，可以获得最为理想的数据包长度。
2.9 多条WAN线路间的协同是怎么实现的？
一些大型的企业通常会买不同的WAN线路，比如Dual Internet、Dual MPLS、Internet+MPLS等等，随着4G/5G的成熟与发展，未来移动也会成为WAN线路篮子中一个关键的选择。不管各种WAN线路的成本如何，企业最希望的是能最充分地利用好花出去的每一分钱。有了应用识别，有了WAN线路监测，怎么在这些WAN线路间进行协同呢？
用SD-WAN的专业表述来说，WAN线路间的协同被称为Hybrid WAN或者WAN Bonding，意思就是把多条WAN线路打包在一起提供传输的服务，和Port Channel是类似的。Bonding可以是Per Flow的，即不同的流走到不同的线路上去，这和传统的ECMP没什么区别，但是无法保证应用得到最好的SLA。做Per APP的Bonding，即不同的应用走到不同的线路上去，这是SD-WAN最常提到的，但是在一些情况下资源的利用率不见得是最优的。Bonding也可以是Per Packet的，这种方式的话主要是优化Bulk流量，带宽利用的最为充足，但需要在对端进行reorder。具体Per Flow、Per APP、Per Packet该怎么组合呢？这个和企业的流量模型，以及当前线路的使用情况都有关系，这里无法逐一而述。
WAN Bonding还有一个要求，当WAN线路监测的结果说明一条线路的QoE不好的时候，要切换到其他的线路上，或者均衡一部分流量到其他线路上也可以。值得注意的是，如果目标WAN线路上存在防火墙或其他带状态的中间件，那么直接做切换的话，很可能会导致流量的中断，因此在做部署时，要设计好WAN线路和中间件的联动机制。另外，考虑到不同站点间WAN线路情况的不同，一些SD-WAN方案会提供一种叫做Unidirection Steering机制，允许两个站点间的流量在上下行两个方向选择不同的WAN线路，当然这也要需要在考虑中间件的情况后再决定是否启用。
2.10 WAN优化是怎么实现的？
要向提高WAN的利用率，除了在不同的WAN线路间做协同以外，WAN优化也是必须要做的。传统的WAN优化需要专用的、昂贵的硬件设备，而在大部分的SD-WAN方案中CPE中都内置了一些WAN优化的功能，少数方案中即使CPE自身不提供WAN优化，也可以在本地起WAAS的VNF并进行串接。
WAN优化主要包括以下几个主要的方面：数据压缩，采用一定的算法对包头或者payload进行压缩/解压缩，以降低信息的冗余度；数据消重，对传输过程中出现频次较高的数据进行编号，并使用指针进行替换，以节约编码所占用的空间；内容缓存，将热点内容进行本地缓存，对热点内容的后续访问即可在本地直接返回，直接避免了对于WAN线路带宽的占用；TCP优化，通过TCP代理将端到端的标准TCP切成多段，并对其中WAN一段的传输进行优化，改善标准TCP的拥塞控制和重传机制，或者基于UDP来增加吞吐量；HTTP和其他应用层协议优化，这个就具体问题具体分析了。
对于企业来说价值最高的是UCaaS流量的优化，包括视频会议和VOIP等，这里简单地介绍一下FEC和Packet Duplication。FEC常用于对视频传输进行优化，发送方进行FEC编码，在原始数据包以外引入冗余校验包，接收方进行FEC解码，并通过冗余校验包对原始数据包的误码或丢包进行恢复，以降低由于WAN线路质量不稳定所导致的卡屏现象。Packet Duplication常用于对VOIP的传输进行优化，发送端对数据包进行复制，并通过不同的WAN线路进行传输，接收端会以收到第一份为准并忽略掉后续重复的数据包，不同的WAN线路丢掉同一个包的概率基本为0，使得VOIP的通话质量得以有效的保障。
2.11 安全是怎么实现的？
安全的实现并不是单单是IPSec，而是需要贯穿一个SD-WAN方案的方方面面。首先，前面提到过设备都需要有一个唯一的标识，CPE可以出厂时配好也可以固化在硬件中，VNF在拉起的时候会生成并注入序列号，而控制器的话用IP和FQDN通常就可以了。有了标识之后，系统中的各个组件间需要有相互的认证，防止非法CPE和控制器的接入，这块的实现可以通过外接LDAP/RADIUS来做，也可以通过PKI体系来做，SD-WAN产品自身也应该提供认证服务器或者PKI Server，如果企业自己有认证服务器或者PKI Server，要需要支持与其进行对接。
其次，就是IPSec的问题了。大家知道IPSec需要两套密钥，第一套是IKE身份认证的密钥，第二套是数据流加密的密钥。第二套密钥在传统方案中是通过DH来分布式计算的，在一些SD-WAN方案里则会直接由控制器来进行同步，并周期性地进行更新这个密钥，以实现key rotation。实际上，如果使用控制器去分发第二套密钥，就相当于替代掉了IKE的作用，那么第一套密钥就可以不作用在CPE之间了，而是用于CPE和控制器之间的身份认证，上一段说过这可以通过PKI来搞定，省去了维护预共享密钥的麻烦事儿。另外，考虑到方案对于NAT穿越的强烈需求，IPSec一般都会采用ESP+隧道的模式。
数据面都要overIPSec没什么问题，控制信道的加密如何实现呢？这取决于用的是什么协议了。如果是私有的协议的话over在SSL/TLS/DTLS就可以，Netconf和OpenFlow也都是原生over在TLS上面。BGP的话就比较麻烦，简单的MD5破解起来轻而易举，业界始终都没有找到更好的办法来保证BGP的安全，重大的BGP劫持案例从来就没有间断过。如果SD-WAN方案中控制面要用BGP，那么最好也over在IPSec里面，这倒也没什么奇怪的，传统的方案里IGP实际上也是over在IPSec里面的。另外，原生的BGP还穿越不了NAT，正好用IPSec一并给解决了。类似于传统方案中的COPP，SD-WAN还要防止CPE主控和控制器的DoS，通过一些策略来限制报文的上送速率。
至于业务层面的安全，实现的手段就比较多了，Logging、xACL、Zone-based FW和DPI是最基本的要求，至于IDS/IPS/AV/UTM/NGNW，通常就是通过Service Route来串接了。如果是在总部/数据中心做集中式的安全，那么分支的流量就要绕到总部/数据中心去，如果是DIA的方式，那么就在分支的CPE上做文章，或者就近引流给第三方的SECaaS服务商。
另外，考虑到包括银行和零售等在内的主要目标行业客户的需求，SD-WAN产品还要尽量去符合PCI DSS，以确保为支付业务提供一个安全合规的网络传输环境。
2.12 高可用是怎么实现的？
和安全一样，高可用也是贯穿着SD-WAN方案的各个方面。控制器的集群设计中，要注意的是控制器的工作性质。如果只是做纯配置类的工作，那么实际上对于性能的要求不是很高，集群采用主备模式即可。如果还要负担路由控制类的工作，考虑到某些目标客户的规模比较大，那么集群最好能支持多活的模式以进行负载分担，此时要求ZTP实现中，能够为不同的CPE指定不同的Master控制器。
相对而言，控制器的高可用多为IT层面的问题，而网络层面的高可用就非常复杂了，端口/设备/链路/隧道/路由/状态，要考虑的方面很多，而且彼此间还要做好关联。因此，做高可用是需要代价的，不同的站点要在可用性和成本间做好平衡。从物理拓扑来说，小型的分支而言可采用Single CPE + Dual Internet，大型的分支可采用Dual CPE + Hybrid WAN，总部/数据中心可采用Dual CPE + Dual Internet + Dual MPLS，当然这只是一个粗略的建议，要根据站点的实际情况来设计边缘的物理拓扑。
明确了物理拓扑后，即可根据CPE的数量以及Underlay的连通性来设计逻辑拓扑。先来说LAN侧：如果是Single CPE下连可以起Port Channel，其他的没什么好说的；如果是Dual CPE的话要看下连是接交换机还是路由器，交换机的话就用VRRP+基于VLAN的负载均衡，路由器的话用IGP+ECMP就行了。再来说WAN侧：如果是Single CPE的话，可以在不同的WAN线路上起不同的隧道，也可以在逻辑口上起一个隧道然后承载在不同的WAN线路上；如果是Dual CPE的话，可以在两个CPE上起VRRP支撑一条WAN线路上的一条隧道，也可以在两个CPE上起不同的隧道跑在同一条WAN线路上，也可以在在两个CPE上起不同的隧道跑在不同的WAN线路上，也可以对这三种方法进行组合。
当出现WAN侧线路不通的情况时，两侧CPE上的路由要能快速地完成收敛。如果采用控制器集中分发路由的方法，那么控制器首先要搞清楚不同WAN线路间的可达性，检测到线路断了之后需要能正确地推送新的路由。如果是采用IGPoverTunnel这类传统的分布式路由，可以等IGP的自然收敛，最简单但是速度比较慢，要加跨收敛的话可以用Tunnel BFD去关联IGP，但是会产生额外的开销。
对于Dual CPE的部署方案来说，WAN侧和LAN侧还要能够实现联动。接交换机的话可采用VRRP，需要能够Track接口/路由/BFD。接路由器的话用路由就可以实现，如果是控制器来集中分发路由，那么控制器检测到线路断了之后需要能正确地推送新的路由，如果是传统的分布式路由，那么CPE上就需要能够在Static和IGP、IGP和IGP间做重分布，如果Tunnel上不愿意跑IGP，还得提供类似于反向路由注入的能力。
Dual CPE还要考虑状态的同步，因为CPE上除了VPN以外还会跑NAT、防火墙和WAAS，这时就要再CPE间去同步各种各样的状态信息，这对于大部分厂商来说是个比较头疼的问题。另外，如果CPE的WAN线路上存在NAT、防火墙或者WAAS，还要考虑切换WAN线路后的路径对称性问题。
2.13 其他关键技术与功能
上面总结了关于Enterprise Oriented SD-WAN的12个核心技术问题，除此之外，其他的一些技术点还包括：
QoS，需要提供Traffic Shaper、CAR、DSCP Mark/Remark、Queue、AQM、Tunnel QoS、HQoS的能力，并提供面向应用的QoS能力。远程/移动接入，定位于总部/数据中心的CPE，可选地支持L2TP和SSL VPN。Wifi管理，定位于小型分支的CPE，可选提供Wifi的认证、频段管理等能力。时钟同步，可通过NTP为SLA提供精确的时间信息。CPE可管理性，提供远程文件拉取、远程重启、不中断升级的能力。3. 小结
上述就是Enterprise Oriented SD-WAN的关键技术点了。Enterprise Oriented SD-WAN给企业带来的价值非常明显，在北美讯速地抢占了银行、零售、连锁等行业，包括很多世界500强的大型客户，2015年下半年开始，SD-WAN成为了业界炙手可热的新宠。由于SD-WAN对于上述一系列关键技术的利用，能够显著地提高Internet线路的QoE，这使得Internet线路在某些场景中，得以部分地代替MPLS线路在企业组网中的作用，因此降低了企业对于MPLS的依赖性。
因此，当时业界谈论最多的话题，就是“SD-WAN能否取代传统的MPLS VPN？”。MPLS VPN是全球各大运营商的支撑性业务，SD-WAN的突然崛起，迫使着大T们开始思考应对之策。下篇将对“SP Oriented SD-WAN”进行介绍。
