作者简介：张晨，IP与SDN技术爱好者，《云数据中心网络与SDN：技术架构与实现》作者。

从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

这种思路是对传统的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们开始思考应对之策。

下篇

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”进行介绍。首先，会介绍厂家给出的SDN-Gateway的方案。其次，将对运营商青睐的vCPE方案进行介绍。最后，简单地聊下MPLS VPN的优化问题。

二、SP Oriented SD-WAN

关于“SD-WAN能否取代传统的MPLS VPN”，其实这个问题的答案很明显。SD-WAN最大的价值之一，就是在Hybrid WAN的场景下更有效地去管理与使用WAN线路，帮助企业提高在WAN这一块的ROI。因此，SD-WAN的出发点并不是要对抗MPLS VPN，因此就谈不上要取代MPLS VPN，因为两者并不在一个层面上。

无论是从纸面上来看设计，还是从实践中看效果，SD-WAN确实实现了它所承诺的价值。运营商也很快地就看清楚了问题的本质，尽管SD-WAN客观上会降低企业对于MPLS VPN的需求，但这是技术演进的自然结果，另外SD-WAN在灵活性、自动化、应用感知、上云等方面相比于传统的技术方案，也有着不可比拟的优势。权衡之下，与其把SD-WAN放到对立面，倒不如想办法把其拉到统一的战线上，作为一个新的业务增长点。因此，运营商并没有排斥SD-WAN，而是对其表现出了相当开放的态度，这与很多人的设想是恰恰相反的。

SD-WAN的厂家们心里也很清楚，要做大事情就一定得把生态搞好，运营商作为生态中最关键的环节，有必要建立起一个融洽的合作模式。首先，纯Overlay的方案存在着一定的局限性，虽然说是Transport Independent，但是如果Transport的线路质量确实不行，那也是巧妇难为无米之炊，另外对于跨国企业来说，如果不用MPLS纯走Internet，那么基本上就约等于不能用。其次，运营商拥有着广泛的客户基础，业务的覆盖范围更广，无论在运营还是运维方面都有着巨大的优势，这正是SD-WAN厂家们最为欠缺的环节，一些大型的客户动辄就几千个分支，虽然技术上是ZTP + Cloud Managed，但是从渠道和服务的角度来说，就完全是另外一回事了。

双方一拍即合。第一种合作的思路是，运营商把厂家的方案买下来，然后自己来做渠道和服务，除了能够分一部分SD-WAN的利润外，更关键地是可以把各种WAN线路打包到方案中，为企业提供一站式、差异化的WAN解决方案。如果有足够实力的话，还可以对产品进行一些定制，把SD-WAN的能力嵌入到自己的业务系统当中。第一种思路，不需要对Enterprise Oriented SD-WAN的技术架构进行改动，同时有着清晰的盈利模式，对于厂家来说是零成本，对于运营商来说是一种快速进入市场的有效手段。

第二种思路，是对原有方案的架构进行调整。最初所设计的SD-WAN方案是Enterprise Oriented的，从技术上来看是找不到运营商位置的，如果要做一个SP Oriented的SD-WAN，就需要在方案中引入SP的角色。那么SP Oriented SD-WAN该怎么做呢？

1、SD-WAN Gateway

厂家给出的方案，是在运营商的POP点里面放SD-WAN Gateway，负责终结企业侧CPE发起的隧道，然后转发到运营商的IP/MPLS网络。在这种方案中，Enterprise SD-WAN中的CPE上所有能力都被保留了，不过端到端的Overlay变成了，两头的Last Mile用Overlay而Middle Mile交给运营商去做，如果运营商有能力的话就可以把MPLS VPN集成进去，如果短期集成不了MPLS VPN，Middle Mile这段用Overlay打过去也不是不可以。

实际上这是种很不错的思路，各方接受起来都很自然。从客户的角度来看，不需要去额外地购买的设备，而且传统的WAN设备也可以通过隧道接进去了，另外SD-WAN的运维也转交给运营商去做了。从厂家的角度来看，Enterprise Oriented的特色得以被保留，CPE仍然是高价值的产品，同时有效地解决了纯Overlay的局限性，另外通过SD-WAN Gateway也得以参与到运营商的组网中。从运营商的角度来看，SD-WAN Gateway不仅提供了对接MPLS的入口，另外也提供了更加灵活的接入方式，对于Last Mile不可达的Off-Net Customer，走Overlay做接入能够省去很多的麻烦事儿。

以SD-WAN Gateway为核心的SP Oriented SD-WAN，保留了Enterprise Oriented SD-WAN的所有能力。在此基础上，主要是提供了对多租户的支持，并在控制逻辑方面进行了相应的加强。

1.1 整体设计
对于运营商来说，SD-WAN Gateway作为业务的接入设备，在位置上和SR/PE并没有本质上的区别。对于Pure Play的SD-WAN厂家来说，他们在POP里面并没有存量的SR/PE，所以就只能推新的设备进去。形态上就是x86的盒子，相比于Enterprise Oriented SD-WAN方案中的CPE，SD-WAN Gateway作为不同客户流量的汇聚点，接口的速率和数量都会做相应的增强，而且由于它要负责大量隧道的终结，因此对CPU和内存的要求高很多，通常会需要专用的Crypto Accelerator。而对于传统的设备厂商来说，比如Juniper、ALU和华为，他们在POP里面有存量的SR/PE，这时候可以选择把SD-WAN Gateway以板卡的形式插到SR/PE的机框上，以避免多引入一个物理设备的麻烦。随着CORD在运营商中的推进，SD-WAN Gateway的形态开始逐渐向vCPE进行靠拢，关于vCPE等到后面CORD的部分再来做介绍。

控制器。从宏观的架构来看，除了Staging Server、Controller和Analytics以外，可能会需要AAA来专门做鉴权。从细节来看，由于多租户需求的出现，以及设备、拓扑复杂度的提高，使得控制器所用的数据模型以及业务流程都会发生一定的变化。从位置来看，On-Premise是不可行的，需要放到运营商自己的机房当中。通常是在地市级的核心机房里面，负责控制下属的各个接入机房中的SD-WAN Gateway，以及本地企业分支的CPE。

Portal也要做相应的调整，而且运营商很可能要自己来做定制，部署的位置也取决于运营商站在什么层面上来看待SD-WAN的业务，所以这里就不多说了。

1.2 多租户是怎么实现的？
企业侧接入SD-WAN Gateway的流量，需要能够与VRF进行关联。按厂家的意思就是用IPSec直接打进来，把接入网这一段OTT掉。在这种方式中，需要能够对IPSec流量关联VRF，大概有下面这几种办法：（1）用GREoverIPSec，为GRE口关联VRF；（2）用MPLSoverGREoverIPSec，用MPLS来关联；（3）用VxLANoverIPSec，通过VNI来关联VRF；（4）通过VTI口来关联VRF；（5）用ISAKMP Profile绑定VRF，识别SPI后直接关联VRF；（6）用私有的IPSec封装，在IPSec后面单独加VPN的字段。比较而言，从标准化程度来讲（1）是最好的，从封装效率上来讲（3）和（4）要好一些，不同厂家的实现中会有不同的选择。

不过，按运营商现有的接入网络来看，除IPSec以外，VLAN/QinQ/L2TP/GRE/MPLS VPN甚至是传输专线都有是有可能的，这对于SD-WAN Gateway的要求就比较高了。此时，传统的设备厂商相比于Pure Play的厂商就有明显的优势了

经过特定VRF的路由后，这里考虑跨地区的流量，流量要被送到目的站点所接入的SD-WAN Gateway上。根据实际情况，又有不同的方式：（1）如果SD-WAN Gateway间要走GRE/IPSec，就还是用上面刚刚所介绍的方法；（2）如果SD-WAN Gateway间要走MPLS VPN，且SD-WAN Gateway自己具备MPLS VPN的能力，这时可以直接给出向流量标记Service Label；（3）如果SD-WAN Gateway间要走MPLS VPN，但是SD-WAN Gateway并不具备MPLS VPN的能力，那么SD-WAN Gateway就要通过接口/子接口和PE做连接，同时与PE间起IGP多实例，或者BGP/MP-BGP打通路由，然后由PE来完成MPLS VPN的工作，这实际上可以看作是VRF-Lite的方案。

不仅是SD-WAN Gateway，整个系统实际上都需要进行多租户的改造。对于CPE来说，要接入SD-WAN Gateway，可能需要对特定的封装提供支持。对于控制器来说，要明确CPE所属的租户，以及SD-WAN Gateway上所接入的租户列表，然后在分发策略和路由的时候，需要能带着租户的信息下去。对于Portal来说，则要提供RBAC的能力，对不同账号的权限进行区分与隔离。多租户所带来的细节问题，还有很多很多，无法逐一而述了。

1.3 端到端的控制如何实现？
在Enterprise Oriented的方案中，控制器看待站点间的连接的角度很简单，两个设备+双向的隧道。在SP Oriented的方案中，由于控制器不仅要控制企业侧的CPE，还要控制运营商的SD-WAN Gateway，另外SD-WAN Gateway的引入还将路径切分成了多段，路由的控制上也很为复杂了。这些都对SP Oriented的控制器提出了很大的挑战，甚至可能需要在集中式和分布式间重新进行决策。

首先，端到端的拓扑就十分的复杂。简单来想，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN CPE）做本地中继，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN Gateway—SD-WAN CPE）做跨地区的隧道拼接，也不排除会做（SD-WAN CPE—N*SD-WAN Gateway—SD-WAN CPE）的POP点组网。如果有Non SD-WAN的设备打隧道接进来，这个设备的控制是不归控制器来管的，虽然控制的设备少了，但实际上控制器的建模却变得更加复杂了。如果Non SD-WAN设备接入SD-WAN Gateway，而SD-WAN CPE间不走SD-WAN Gateway直接打隧道，就更加混乱了。和路由目前来看，SP Oriented SD-WAN还没有一个标准的路由控制逻辑，只能是摸着石头过河。

在实际的部署中，SD-WAN Gateway不可能会是单点，相比于主备运营商更喜欢负载分担，那么还要考虑HA下的均衡问题。而且一个地区的POP点会有很多个，如何在POP点间进行流量的优化，也是一个重要的问题。

另外一个现实的问题是，运营商不可能完全OTT接入网和MPLS。Overlay在Internet上做接入，虽然在灵活性上有很大的优势，便于接入Off-Net的客户，但是对于本地的On-Net客户这种方式却不见得合适。对于一些运营商来说，CPE—BRAS—SD-WAN Gateway—SR/PE的流量模型并不符合路由的规范，而且BRAS、SD-WAN Gateway、SR/PE这三者间的形态关系也是千差万别，现网部署起来会遇到很多麻烦。所以说对于On-Net的客户，SD-WAN Gateway接入这一端更习惯于over在专线上。这样的话还要协同接入网的网管/控制器，如果再考虑与MPLS VPN网管/控制器的协同，整个SP Oriented SD-WAN的编排/控制系统会变得无比复杂。全场景、端到端的编排/控制，目前来看还有相当大的差距。

1.4 公网访问如何实现？
如果是要做Local DIA，那么分流在分支的CPE本地就完成了，流量模型是Branch CPE—BRAS—Internet。如果是要做Backhaul，是由总部/数据中心的CPE统一分流，流量模型的一种可能是Branch CPE—SD-WAN Gateway—HQ/DC CPE—Internet，另一种可能是直接Branch CPE—HQ/DC CPE—Internet。关于DIA和Backhaul，在Enterprise Oriented SD-WAN部分已经介绍过了，这里就不再赘述。

除了Local DIA和Backhaul以外，SP Oriented还提供了Regional Break Out的方式，流量模型是Branch CPE—SD-WAN Gateway—Internet，由SD-WAN Gateway完成公网和VPN流量的分流，公网流量可能还需要进一步地对国内流量和国际流量进行区分，以提供不同的路由策略。Regional Break Out要求SD-WAN Gateway能够提供NAT、安全和HQoS的相关能力，同时要求SD-WAN Gateway具有Internet的连通性。对于客户来说，Regional Break Out的优势在于，既可以避免Internet流量绕行总部/数据中心，降低了时延与带宽消耗，又可以通过SD-WAN Gateway为本地的多个分支集中地提供安全、WAAS这些服务，避免了以分支为单位去使用这些服务的成本。对于运营商来说，客户在本地所有分支的Internet业务可以集中地管理起来，比如对上下行带宽的统一分配。

至于公网流量如何才能从Branch CPE送到SD-WAN Gateway上，还是要看接入的方式是怎么样的。如果要Overlay在Internet上，那么控制器就要下发路由把公网流量通过隧道送给SD-WAN Gateway，此时流量模型实际上是Branch CPE—BRAS—SD-WAN Gateway—Internet，在现网中运营商不一定会愿意提供这种连接方式，这取决于运营商如何去看待BRAS和SD-WAN Gateway两者的关系。如果是over在专线上，路径上就不会出现BRAS，这时相当于一根线上同时跑了宽带和VPN两种业务，需要在计费方式上做好考虑。

2、vCPE

在运营商传统的POP点中，为了支撑话音、宽带、专线等不同专业的业务，需要采购大量专用的硬件设备，开放性和灵活性很差。在Cloud/NFV/SDN等新型架构的驱动下，全球各大运营商纷纷投身于POP点云化的重构进程中。POP点云化后，各类专用的硬件设备在形态上将被基于通用x86平台的VNF所替代，在架构上转发和控制得以分离解耦，这对于运营商具有巨大的价值。一方面在于开放性、灵活性等方面的提高，长期来看能够有效地降低成本。另一方面，运营商得以将各种增值服务的VNF以服务的形式提供给客户，这将是一笔相当可观的业务增收，也是破局“管道化”困境的有效方式。

在这一大背景下，SD-WAN的架构也得到了新的延伸，以vCPE为核心的解决方案开始占据SP Oriented SD-WAN的主流。这里有必要对vCPE的概念进行一下说明，从字面上来直观理解的话，vCPE应该是指一个与CPE具有相同功能的VNF，但实际上业界对于vCPE的定义并非如此。由于传统的CPE是一个泛指的概念，涉及路由、防火墙、WAAS等诸多技术，因此对CPE进行虚拟化的结果，通常并不是一个VNF，而是vRouter、vFW、vWAAS等多个VNF，它们各自完成一部分功能，然后通过服务链串接在一起，共同交付vCPE的能力。虽然在某些产品和语境下，vCPE可以指代一个特定的VNF，但是在通用语境下vCPE是指一套完整的解决方案。

至于SD-WAN与vCPE间的关系，从SD-WAN的角度来看：

• 如果SD-WAN CPE是基于x86的白盒，而且自身具备单独作为vCPE载体的能力，这时SD-WAN CPE就可以被称为vCPE，vCPE就是SD-WAN方案中的一个组件。
• 如果SD-WAN CPE以虚拟机的形态存在，那么可以作为vCPE方案中的一类VNF，这时可以说vCPE是SD-WAN方案中的一种实现手段。
• 如果在vCPE方案中，只提供vRouter、vFW等传统的VNF，并不提供SD-WAN VNF，那么vCPE和SD-WAN两者并无直接的联系。

如果理解起来仍然比较晦涩，那么换作vCPE的角度来看就清楚很多：

• 如果所有的能力都在企业边缘提供，称为Distributed vCPE，无论企业边缘的设备是不是SD WAN CPE。
• 如果所有的能力都在POP点提供，称为Centralized vCPE，无论提不提供SD-WAN VNF。
• 如果一部分能力在企业边缘提供，一部分能力在POP点提供，称为Hybrid vCPE，无论是否存在SD WAN CPE或者SD-WAN VNF。

可以看到的是，SD-WAN和vCPE并不存在严格的包含于被包含的关系。以这篇文章的出发点来说，可暂且把vCPE看作是SP-Oriented SD-WAN中的一种实现形式。下面就来对vCPE进行一个简单的介绍。

2.1 整体架构
一套完整的vCPE方案的实现需要Cloud、NFV和SDN技术的紧密协同。首先，要有一个x86的平台来提供虚拟化的能力，可以是在Distributed vCPE中的SD-WAN CPE上，也可以是在Centralized vCPE中的x86资源池中。其次，要有一套虚拟化的中间件+云管平台，如开源的KVM+OpenStack。然后，需要一套VNFM+NFVO，对VNF进行管理和编排。SDN这块，云POP点的控制器、SD-WAN的控制器，可能是同一套，也可能是两套，另外一些方案中还会包括接入网的网管/控制器。Portal就很难说了，完全取决于厂家的实现和运营商的集成。

vCPE是否要做成多租户的？除了厂家的实现以外，其实还取决于运营商的销售策略。如果是卖VNF的模式，那么一个实例只就能属于一个租户，这时不强制要求多租户。如果并不直接卖VNF，而是包装成网络能力来卖，这时做成多租户就比较划算了，不过要考虑好性能、容量、配额和扩缩容的问题。

实际上，vCPE就是POP点云化的一个企业级用例，上述vCPE的架构也就是POP点云化的架构。关于这套大的架构，本身就可以独立成一篇长文，这里不做深入的展开。

2.2 Distributed vCPE和Centralized vCPE
之前提到过，所有能力都在企业边缘提供的方式被称为Distributed vCPE，实际上Enterprise Oriented SD-WAN中的CPE很可能就是Distributed vCPE的一种表现形式，本地集成VNF，然后通过一些引流手段把它们串在一起。与之相对应的是Centralized vCPE，所有能力都位于POP点中，并由运营商以服务的形式来集中提供。那么，哪种方式更好一些呢？

先来看看市场方面的因素。从厂商的角度来看，如果其产品的能力比较全，就会倾向于Distributed的方式，把所有的功能都自己做在盒子里，如果其产品能力上有较大的缺口，那不可避免地就要做第三方集成，倾向性就会稍弱一些。从运营商的角度来看，一般会更倾向于Centralized的方式，一方面有利于运维，另一方面能够增强自身在企业组网中的地位。从客户的视角来看，Distributed是买硬件+服务，Centralized只需要买服务，如果Distributed和Centralized的使用体验一致，从成本来说自然是Centralized更好一些

不过，Centralized并不会完全地压倒Distributed。一来，目前运营商的POP点云化还处在早期的阶段，技术上距离成熟还有相当的一段距离。再者，一些VNF部署在企业边缘会获得更好的使用体验，比如WAAS。Hybrid vCPE在两者间取了一个平衡，一部分能力在企业边缘的盒子上，一部分能力在POP点中，由客户根据实际情况来自行订购。Hybrid的方式固然灵活，但是VNF的分散性对于运维来说是一个不小的挑战。

2.3 Centralized vCPE的流量模型
Centralized vCPE的目标是最大程度地简化企业侧的设备，最好是只留下二层的功能，把路由也移到POP点里面去。对于运营商来说，自然希望借此获得对于企业业务更加完整的控制权，对于一些中小型的客户来说，这避免了自己去维护路由的工作，实现网络的即插即用。因此，目前在很多的vCPE应用案例中，都会见到这种二层接入的方式。这时VPN和公网的流量都会发给POP点中的vCPE，vCPE不仅仅是虚拟化了企业侧的终端，实际上把BRAS和SR的一部分活儿也都一起给做了。

Centralized vCPE主要包括vRouter、vFW和vWAAS，在实际的部署中会有不同的串接顺序。当然，某些厂商也会将不同的能力集成到一个VNF中去实现，比如SD-WAN VNF很可能就是一个集多种能力于一身，这时流量的模型就要简单很多。这里考虑最常见的串接顺序vRouter—vFW下的流量模型，vFW采用路由模式。vRouter对流量的处理主要包括：（1）对流量进行识别；（2）为企业侧的接入设备分配IP地址；（3）对流量进行限速；（4）将流量送给vFW。在vFW对流量的处理主要包括：（1）对流量进行识别；（2）对公网流量和VPN流量进行分流；（3）执行安全策略；（4）公网流量送给NAT设备，VPN流量送给PE。

具体来看数据面的转发。目前NSH的应用还非常少见，这里不做分析。

• 客户接入vRouter这一段。可能的拓扑有很多，（L2 Switch—POP GW—vSwitch—vRouter）、（L2 Switch—POP GW—vRouter）、（L2 Switch—vSwitch—vRouter）、（L2 Switch—POP GW—vSwitch—vRouter）。由于要接入二层，因此可以选择VLAN/QinQ或者VxLAN，考虑到与物理拓扑解耦走VxLAN会稍好一些，一些节点上会需要做转换/拼接。
• vRouter到vFW这一段。如果在同一个节点上，拓扑是（vRouter—vSwitch—vFW），直接VLAN不用走隧道。如果不在一个节点上，拓扑就是（vRouter—vSwitch—vSwitch—vFW），vSwitch间走VxLAN就行。少数情况下，拓扑会是（vRouter—vFW），可以选择MPLSoverGRE，如果不支持MPLS可以用VRF Aware GRE。
• vFW到NAT/PE这一段。由于NAT/PE通常是物理设备，因此拓扑最好直接就是（vFW-NAT/PE），可以选择MPLSoverGRE，如果不支持MPLS可以用VRF Aware GRE。一些POP点中还会引入vNAT/vPE，这时就可以（vFW—vSwitch—vSwitch—vNAT/vPE）了。

可以看到的是，由于涉及到运营商的网络，因此底层的连接变得非常复杂，要针对现网的实际环境来做具体的方案设计。而且，由于拓扑没有一定固定的形态，因此对控制器的要求也很高，很可能需要做一些定制化的开发。

3. MPLS VPN的优化

从SD-WAN厂家的角度来看，只要把流量做好标记送给PE上就行了，PE间的打通并不属于SD-WAN要考虑的问题。不过对于运营商来说，MPLS VPN是企业广域网业务的基础，也是能够体现服务差异化的最关键环节。因此，运营商在设计SD-WAN业务的时候，一定会带上MPLS VPN一起做考虑。不过，传统的MPLS VPN所存在的一些局限性，使得它在与SD-WAN进行集成时显得很不协调。首先，开通周期太长，交付速度远远跟不上业务的需求。其次，带宽难以按需调整，客户只能按照峰值带宽的水平进行超买。另外，无法与云进行联动，企业入云的流量难以纳入到服务体系中。

快速开通的问题，并非单纯地引入SDN控制器对两端PE/ASBR做自动化配置那么简单。在运营商的传统体系下开通一个MPLS VPN，周期保守估计在45-90天，从开始填写订单到最后完成交付，其间要流转数十个步骤，其中向设备下发配置这个环节已经是由MPLS VPN网管一类的角色自动完成的，换上SDN控制器来配也没有任何本质的区别。真正的问题在于，传统的BOSS系统太过于臃肿，为保证系统的稳定运转，不仅流程复杂繁琐，而且很多步骤需要人工介入。因此破题的关键在于，运营商要对BOSS的架构和业务流程进行精简，否则任何网络层面的改进都是杯水车薪。

带宽按需调整，在BOSS层面也面临着同样的现实问题。单纯从网络的层面来讲，调带宽的方法要看MPLS VPN的QoS模型，如果是Diff-Serv的就是在PE上做限速和Mark，如果是Int-Serv恐怕就要去搞RSVP了。想法是好的，但在现实中运营商可能会遇到一些头疼的问题。首先，是调带宽这个动作极容易使网络变得不稳定，一旦客户调的时候影响了别人，很难去界定责任。其次，按需的粒度很难掌握，细了的话太影响收入，粗了很多时候对客户就失去吸引力了。另外，按需服务的模式对计费系统冲击太大，风险性需要进行谨慎的评估。

与云的联动不足，需要运营商与云提供商双方来共同解决。云机房通常会建设在城域网核心或者骨干网这一层面，通过DC Edge来接入运营商的Internet。随着云计算的逐步成熟，一些高价值的企业流量开始流向云端，然而Internet却难以为这部分流量提供足够的连接质量，引入MPLS VPN来解决这一问题是很自然的需求。对于运营商而言，如果不是市场策略上有什么额外的考虑，单纯从技术上来讲事情是很简单的，DC Edge就是CE，只要搞定它与PE间的接入和路由就可以了。

接入上没什么说的，裸纤/专线/VPN都可以，对于几个大的公有云，甚至可以直接把PE搬到DC Edge的机房去做直连，通过物理接口或者子接口来隔离租户。如果由于一些现实的因素，运营商和公有云间做接入存在困难，还可以通过第三方的IXP/CXP来进行中继。

路由这一块，由于要跨域一般就是静态路由或者BGP，如果是用静态路由，就是由控制器把路由配到DC Edge和PE上，如果是用BGP，那就需要控制器去配好Peering和Policy。从分工界面来看，DC Edge和云内部的网络由公有云提供商来负责，PE和企业侧的接入由运营商来负责，双方的控制器各自封装好API提供出来，上面的Portal或者编排器拆单后直接调用就可以了。对于IaaS流量来说，企业侧和云侧的网络在同一地址空间内，路由直接拉通就行了，但是对于SaaS流量来说，云一侧是公网的IP地址，因此路由是没法直接通的。因此，对于企业侧访问SaaS的流量，运营商还需要在PE送到DC Edge前做NAT，这是一个很容易被忽略的问题，特此进行提示。