这两年SD-WAN在业界可谓是众星捧月，在一些文章的过度包装下，非常容易让人形成一个错误的观念,SD-WAN是一种全新的方案。实际上，SD-WAN并不是石头里蹦出来的猴子，虽然有一些吸睛的新特征，但它仍然是根植在很多传统的传统企业级WAN技术之上的，主要包括路由、VPN、安全、WAAS等等，在下文对于SD-WAN的技术介绍中，会反复地提到这些传统技术，读者最好对相关的基础知识有所了解。
  至于SD，实际上SD-WAN并不能单纯地被划归到SDN的范畴下，它集成了WhiteBox/SDN/NFV/Cloud等多种新型手段，属于一揽子的解决方案。对于这两种思路，国外的一些说法分别称为“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的关键技术及主体实现进行介绍，包括：

  1、零接触部署是怎么实现的？

  2、Underlay是怎么打通的？

  3、Overlay是怎么打通的？

  4、组播和服务链是怎么实现的？

  5、混合云是怎么实现的？

  6、公网的访问是如何实现的？

  7、面向应用的处理是怎么实现的？

  8、WAN线路的监测是怎么实现的？

  9、多条WAN线路间的协同是怎么实现的？

  10、WAN优化是怎么实现的？

  11、安全是怎么实现的？

  12、高可用是怎么实现的？

  13、其他关键技术与功能

  最后，结束对Enterprise Oriented SD-WAN的介绍，衔接SP Oriented SD-WAN部分。‍‍

  2、关键技术与实现

  这种思路是对传统的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。

  对于面向移动或者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个，速率上面向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地址即可。

  2、关键技术

  这看要怎么理解ZTP了，可以理解成就是CPE的上线，也可以理解成CPE上线加上控制器把业务打通的全过程。这里按第一种理解来说，控制器的逻辑拆到后面的问题里去说。

  首先，每个CPE要有唯一的标识，这个标识可以是发货前配好的，有条件的话可以固化在硬件中，对于Software CPE的话一般在拉起的时候会生成序列号并完成注入。这个标识需要被手动录入或以其他方式注册到系统中，以便后续的识别。

  等到客户收到CPE并加电后，CPE会通过DHCP/PPPoE来获取IP地址，后续即利用这一IP地址进行通信。之后，CPE要去自动获取控制器的信息，包括IP、端口和认证信息等。获取的方式也有很多，发货前厂家给配好是可以的，但是效率比较低。客户自己去手动开局也是可以接受的，方式上包括扫二维码、根据短信做配置、邮件注入、USB注入等等。