从60分到85分——SD-WAN进阶教程

小o 更新于 4月前

作者简介:张晨,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,这是一个很容易被忽略的问题,特此进行提示。

1个评论
Smark

写的非常好[赞][赞][赞]

收起
9月前
0 收起评论 0