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

作者简介:张晨,IP与SDN技术爱好者,现就职于中国电信北京研究院,从事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”,过两天的下篇再来聊“SP Oriented SD-WAN”

上篇导读

首先,将从产品的设计层面进行介绍,包括产品的软硬件架构、功能特色与市场定位。

然后,将全面地对Enterprise Oriented SD-WAN的关键技术及主体实现进行介绍,包括:
 
1、ZTP(零接触部署)是怎么实现的?
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部分。

二、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”进行介绍(下篇直通车:https://www.sdnlab.com/20694.html)。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。
  • 本文链接https://www.sdnlab.com/20683.html
分享到:
相关文章
条评论

登录后才可以评论

张晨 发表于18-04-10
9