SD-WAN 底层技术原理
2021-02-07 15:16:47 5 举报AI智能生成
登录查看完整内容
SD-WAN，即软件定义广域网，是将SDN技术应用到广域网场景中所形成的一种服务，这种服务用于连接广阔地理范围的企业网络、数据中心、互联网应用及混合云等。
作者其他创作
大纲/内容
包括基于传统的企业WAN产品和方案，又演进出提供SD-WAN解决方案的厂商，如华为、思科以及Juniper等。
传统的网络设备厂商，
包括对其现有产品进行改造和升级、也宣称对外提供SD-WAN解决方案的厂商，如传统广域加速厂商SilverPeak、Riverbed，传统安全厂商Fortinet等。
传统的WAN优化厂商、安全厂商
如Velocloud、Versa等。
专注于提供SD-WAN解决方案的新兴公司
中小型企业一般分支数量少，只有数个甚至1个分支站点，其主要业务特点如下。
·人员规模低于100人，站点规模低于10个，年销售规模低于1000万元。
·对WAN专线的成本敏感，WAN方面无专门的IT运维人员，需托管给第三方。
·分支互访简单，主要为南北向流量，即分支到总部或者数据中心。
·有基本的安全诉求，边缘设备内置的安全特性即可满足。
·有访问SaaS应用的诉求。
·维护诉求主要包括简单的告警、监控与可视化。
·分支站点需即插即用。
中小型企业
大型企业数量巨大，分布在金融业、商业、教育以及制造业等多个不同的行业，其主要业务特点如下。
·站点规模为10～1000个，年销售规模高于1000万元。
·一般有MPLS等运营商专线，希望通过引入因特网来降低专线成本。·
·存在单层和分层网络拓扑，存在南北向和东西向互访流量。
·有访问公有云/SaaS的诉求。
·希望部署广域优化以提升应用体验。
·集中运维与可视化。
大型企业
是地域跨度比较广的大企业，其业务一般跨越多个国家和地区，因而对WAN的网络建设和业务承载体验都有比较高的要求，其主要业务特点如下。
·站点规模为10～1000个，分布于全球。
·希望高价值流量由MSP提供的跨全球专线网络承载。
跨国企业
客户画像
SD-WAN解决方案提供商
购买产品或解决方案，自行运维
企业自建
包年包月，不用负责基础设施运维
企业购买厂商的SD-WAN 服务
SD-WAN解决方案的角色与商业模式
商业模式
Hub-spoke、Full-mesh和Partial-mesh
单层网络拓扑（扁平）
企业分支站点数量比较多，并且分布区域比较广，比如跨越多个省（区、市）甚至跨越多个国家与大洲，采用扁平的网络拓扑组网很难解决网络规模大、管理复杂度高等问题，这时就需要采用分层网络拓扑进行组网。
分层网络拓扑
拓扑类型
MEF 标准定义了一个 SD-WAN模型
通常用一串数字或者用IP地址表示，由网络控制器统一自动分配。
Site ID，即站点ID，是企业站点在SD-WAN中的全局唯一标识，
一个站点通常包含一两个CPE ，CPE ID通常用CPE的Loopback 0的IP地址表示，由网络控制器统一自动分配。这里的CPE对应于MEF定义的Edge。
CPE ID，即站点CPE的Router ID，是站点CPE在SD-WAN中的全局唯一标识。
不同的WAN有不同的SLA质量，可开通流程以及收费策略。如果不同运营商提供的TN彼此之间路由可达，则认为这些TN在同一个RD内
WAN，也称为TN，是运营商提供的广域网络线路，通常包括运营商专线和公用网络等
但也存在不同运营商提供的WAN可以互联互通的情况，这种情况下的广域网络属于同一个RD。
不同运营商提供的WAN一般是彼此独立建设的，通常不能互通。
RD
该广域接口归属于同一个TN或者归属于同一个RD内的不同TN，这样就可以在Underlay网络实现互通，两个广域接口之间可以直接建立SDWAN隧道。
这里的SD-WAN隧道对应于MEF定义的SWVC。
SD-WAN隧道，即SD-WAN Overlay隧道。不同的站点之间要实现互通，需要在两者之间建立一条隧道，隧道的两端是两个互联站点CPE的广域接口（TNP）。
华为定义的模型
网络模型
真的需要吗？
Underlay VPN
控制VPN
业务VPN可能是一个，也可能是多个，根据企业实际需要隔离的业务数量而定。
业务VPN
每个VPN对应一个VN（Virtual Network，虚拟网络）
隧道中的VPN隔离
VPN的端到端隔离体现在
VPN 的设计
与Underlay解耦，不依赖具体的运营商WAN组网技术
针对某些安全WAN链路，用户可以选择不加密。
支持IPSec等加密技术
SD-WAN需要支持企业多租户以及单租户内多个部门的VPN隔离，
支持VPN隔离
支持NAT穿越
SD-WAN隧道设计原则
VXLAN、GRE以及IPSec
IP Overlay隧道技术
隧道设计
在BGP协议的基础上定义了一种新的NLRI（Network Layer Reachability Information，网络层可达信息）即EVPN NLRI
EVPN NLRI定义了多种BGP EVPN路由类型，其中最初的Type 2路由用于携带二层MAC/IP路由；
随着EVPN技术的扩展，EVPN也被用来传递IP三层路由信息，Type 5路由就是IP前缀路由，主要用于通告引入的外部路由，在以SD-WAN的三层互联为主的网络中将发挥重要作用。
Type3路由——Inclusive Multicast路由：用于VTEP的自动发现和VXLAN隧道的动态建立
BGP EVPN
部署IBGP（Internal Border Gateway Protocol，内部边界网关协议）时，为简化全连接配置，可以引入路由反射器。
将从某个VTEP收到的路由反射给其他所有的VTEP
路由反射器可以独立设置，即路由反射器采用独立的设备，也可以同已有CPE合设，即路由反射器与CPE采用同一台设备（总部CPE），
VPN Target是一种BGP扩展团体属性，用于控制EVPN路由的发布与接收。也就是说，VPN Target定义了本端的EVPN路由可以被哪些对端接收，以及本端是否接收对端发来的EVPN路由。
EVPN路由在发布时，会携带RD（Route Distinguisher，路由标识符）和VPN Target（也称为Route Target）。RD用来区分不同的EVPN路由。
EVPN控制层面的工作机制
制在沿用了BGP EVPN基于Type 5传播网段前缀路由基本机制的基础上，对于SD-WAN路由的下一跳等关键信息进行了增强扩展，SD-WAN路由不仅携带一个WAN接口的IP地址作为下一跳，还可以携带多个WAN接口的IP地址以及NAT前后的IP地址信息作为下一跳。
NAT 穿越特性
华为基于EVPN的SD-WAN路由增强方案
路由设计
单CPE 双WAN
某台CPE检测到互联的Underlay网络链路发生故障后，会通知另一台CPE，同时对报文转发策略进行调整，将报文通过互联链路转发到另一台CPE，从而规避上行链路的故障问题。
双CPE，各只连一个WAN
链路可靠性
需要同步业务信息（业务会话等）、链路统计信息和报文调度的策略‘
心跳检测
双活
VRRP可以支持多个VRRP实例，通过多个实例实现设备的负载分担。
LAN侧二层组网：可通过VRRP进行备份。
传统路由器从SD-WAN设备中学习到等价路由，在正常情况下通过ECMP（Equal-Cost Multi-Path，等价多路径）进行负载分担，当设备出现故障时，对应的邻居关系被撤除，相应的路由信息被撤销。
LAN侧三层组网：可通过等价路由进行备份。
两种方式
CPE设备可靠性
双Hub站点冗余方案
对吞吐量有较高的要求，所以一般选择企业的总部、数据中心或大中型的分支站点来兼任此角色
重定向站点冗余设计
核心站点高可用（hub）
网络可靠性设计
华为SDWAN Overlay网络设计
Internet 线路1条，价格敏感
第一类网络当属连锁零售业、餐饮、酒店的生产网络，例如连锁门店与总店之间的交易数据同步，这种场景基本上只要有Internet + POS机就可以投入运营
大多数是原MPLS-VPN用户
如果可以的话还省去、享受多个安全设备的服务，继续省钱。等保要求
经济寒冬，中型企业搬迁办公室、快速切换SDWAN能省一笔钱是一笔
第二类网络叫做企业办公网络，网络规模各异，企业网包括：视频会议、ERP、Eamil、OA 等高频访问类应用。通常情况下，企业应用会根据不同角色设立不同的策略与规则，这些策略如QOS、故障收敛、负载分担/均衡、安全、监控管理都是依附在MPLS网络之上的
企业网网络模型
这类客户的前身不少是MPLS客户，场景多半是总部与分支机构，或是连锁门店之类的星形网络。当他们发现SD-WAN这个新物种既能满足原有需求又能降低成本时，自然就成为了首选（少数例外）
生产系统主要运行在网络上，因此对网络条件自然也要求极高，通常的标准是 高可靠、高安全、高SLA、7*24*365随时待命。
他们的主场多半都在公有云，包括多云+数据中心的混合场景，也有办公室和分支机构等全连接场景。
第二类是以互联网行业为代表的电商、社交、游戏、直播等客户
注重应用层的使用效果和体验，不太关注网络连接，即我们常说的企业应用数字化转型。
第三类 大型集团和出海/跨国企业，业务场景类似于前两类的结合，但多半是企业应用加速，
按行业场景分类SDWAN客户
有些企业技术运维能力强，传统网络在他们手上非常稳固，他们对于SD-WAN的态度首先是考虑能否完美匹配原有环境或与之共存，新产品对他们而言可能会产生哪些新问题（例如可控性、可靠性、原资产利用、使用习惯、学习成本等），而不是看你的产品有多少功能，能节省多少成本，或是否高大上，但凡有一样与他们的预期有差异则很难轻易接受
另外也有一些不太重视运维的企业，网络架构可能会缺少规划，如果遇到规模大的，那就更考验服务商的综合技术服务能力，很可能改网的难度会超过重建一张网络。
对于服务商来说，不要期望做两次PPT交流就能获得客户认可
对于客户来说，也不要过于依赖服务商能解决企业网的所有问题
改网需要双方之间的深入沟通交流，明确边界（关键是客户），服务商更需围绕企业网现状规划匹配的技术方案，技术过硬是基础，包括实施计划和服务的整体配套。
企业网用户如何看SD-WAN
美国企业擅长技术创新或服务创新。而SD-WAN 和云计算都属于服务创新
站在线路思维的角度来看，SD-WAN在传统网络下的转型之痛并不在完全在于技术，而是传统网络几十年所形成的概念认知、技术方案、思维方式、服务模式、乙方产品粘性等系列因素和用户已深深绑定，他们接受新技术产品需要一个过程。
对比下当年IDC客户迁移至公有云是一个道理，即便到了今天，云上与云下应用环境仍在共存，这就使混合云成为了主流场景。
因此，SD-WAN当前的使命不是要完全替代传统网络（MPLS），而是要与之共存、兼容、智能融合，输出各项更具优势的产品方案和增值服务能力。
厂商如何看SD-WAN
为不同的应用提供不同的WAN处理策略，提高了WAN线路的ROI。
uCPE 支持VM等形式提供其他增值服务，并通过SFC进行串接
增加了一个控制器的角色，能够自动发现CPE，并向其地推送密钥和路由，省去了IP、IPSec、Tunnel、IGP、NHRP等的手工配置。
集中式的Portal，对上述功能以及其他功能的策略，进行统一的管理与配置
相对传统WAN的优势
所有的数据包都要过检测引擎，性能较差，目前用的很少。
逐包检测模式
流的前几个数据包走Normal IP-based Processing，同时被镜像给检测引擎，当完成应用类型的识别后，引擎将流与应用间的映射关系写入datapath的缓存中，该流后续的数据包将直接匹配缓存进行APP-based Processing，从而绕过检测引擎，提高处理的效率。
逐流检测模式
DPI的特征库需要支持在线升级，同时也应该允许用户自己对应用的特征进行自定义。
SSL卸载，使得DPI可以完成加解密，不过实现这种思路的厂商目前比较少
比如可以通过DNS Snooping来记录目的IP和URL的关系，这样看到目的IP就大概知道这个流所属的应用了，
或者直接内置一个周知的IP List也可以起到相同的作用。
缺点 ：在于难以处理加密的HTTPS流量，
DPI
缺点 ：DFI 的结果太粗糙了且不适合短流
分析流的行为模式来确定应用，
基于这一系列流量的行为特征，建立流量特征模型，通过分析会话连接流的包长、连接速率、传输字节量、包与包之间的间隔等信息来与流量模型对比，从而实现鉴别应用类型。
DFI 深度/动态流检测
用户自定义应用识别
SD-WAN的一大亮点就在于能够识别出应用
匹配出应用后，流量会被标记metadata，如APP ID和APP Attribute ID，（类似于key-value）后续包括Routing、Monitoring && Analytics、QoS、Firewall、WAAS都应该支持围绕着APP ID和APP Attribute ID来进行差异化的处理，实现完整的APP-based Processing，而并非单纯的APP-based Forwarding。
APP-based Processing ，不仅仅是转发
这类应用一般集中部署在总部或者数据中心的服务器上
一般需要在通信的分支站点之间DIA直接进行数据交换。
视频会议 ，VoIP
协同办公
随着云计算的普及，越来越多的企业应用向SaaS云化转变。比如随着Office365的逐渐流行
云化类应用
应用分类
传统的方式有根据报文五元组识别、根据报文流量特征识别、根据报文载荷识别等；
比较特殊的方式有根据DNS（Domain Name System，域名系统）识别、关联识别等。
协议识别
DNS 关联识别
首包识别
报文特征字识别
关联识别
行为识别
分布式识别
集中式识别
全网同步识别
特征识别
应用识别
以“是否能在接收到首包时就识别应用”为标准对识别技术进行划分，大致可以将其分成两类：首包识别技术和特征识别技术，且每一类又都有相应的子技术
识别技术
IP FPM（IP Flow Performance Measurement，IP流性能测量）是一种基于IP的网络性能的被动检测方案，通过对报文设置标记的方式（又称为染色）来携带统计信息，实现三层网络端到端的性能统计。一方面，IP FPM可以直接对业务报文进行测量，测量数据可以真实反映IP网络的性能；另一方面，IP FPM可以基于隧道监控IP网络承载业务的变化情况，真实准确地反映出各个路径下应用的运行情况，如图6-15所示。
链路质量测量技术
应用识别方案 -- 体验保障方案的前提。
基于企业应用的优先级和对链路质量的要求，通过对多个WAN链路状态的持续监测，从而实现链路选择的方案。该方案既可以使多种企业应用充分利用高质量的链路，也能保证在链路拥塞时高价值应用的体验不会下降。
应用选路方案
QoS方案是在传统的QoS技术（流量监管、流量整形、队列调度等）功能的基础上进一步扩展，增加企业业务感知功能，从而实现对纷繁的企业应用提供差异化服务的方案。
此外，在企业多部门需要隔离的场景下，该方案还提供基于企业部门的服务质量保障，形成“业务—部门—站点”这种层次化的质量保障。
QoS方案
是提高数据在WAN链路上的传输质量和效率
包括广域优化技术、抗丢包技术等
广域优化方案
QoE 实现的方案
基于应用的识别和转发(应用体验QoE)
线路的质量主要包括Loss/Latency/Jitter/Utilizaiton四个方面，当线路质量出现波动时能够动态地调整应用的转发线路，以保证应用的SLA
基本上都是厂家私有的方式与算法
被动测量：根据实际业务流的统计信息来进行分析
主动测量：在业务流外生成Probe来进行探测。常见的手段有ICMP/BFD/CFM/OWAMP/TWMAP等等，如果是要测量SaaS的QoE，通常就用HTTP PING
为了保证实时的线路切换，控制器只负责推送SLA策略，而具体的执行需要在CPE本地完成。
监测WAN线路的QoS
PMTUD（路径MTU检测）
在host 的 TCP的SYN中插入合适的MSS值
多次的封装，如果MTU选择的不恰当的话，会导致大量分片的出现，不仅会多占用WAN线路的带宽，而且重组还会降低性能。
探测WAN线路的MTU
大型的企业通常会买多条WAN线路，比如双 Internet、双 MPLS、Internet+MPLS 、4G/5G
WAN线路间的协同用SD-WAN的专业术语叫 Hybrid WAN或者WAN Bonding，意思就是把多条WAN线路打包在一起提供传输的服务，和Port Channel是类似的。
当WAN线路监测的结果说明一条线路的QoE不好的时候，要全部切换到其他的线路上，或者切换一部分流量到其他线路上
Per Flow的，即不同的流走到不同的线路上去，这和传统的ECMP没什么区别，但是无法保证应用得到最好的SLA。
Per APP的Bonding，即不同的应用走到不同的线路上去，这是SD-WAN最常提到的，但是在一些情况下资源的利用率不见得是最优的
Per Packet的，这种方式的话主要是优化Bulk大象流量，带宽利用的最为充足，但需要在对端进行数据乱序重整。
Per Flow、Per APP、Per Packet该怎么组合呢？这个和企业的流量模型，以及当前线路的使用情况都有关系，具体情况具体分析
目标WAN线路上存在防火墙或其他带状态的中间件，那么直接做切换的话，很可能会导致流量的中断，因此在做部署时，要设计好WAN线路和中间件的联动机制
考虑到不同站点间WAN线路情况的不同，一些SD-WAN方案会提供一种叫做Unidirection Steering机制，允许两个站点间的流量在上下行两个方向选择不同的WAN线路，当然这也要需要在考虑中间件的情况后再决定是否启用。
WAN 线路间的协同
数据压缩，采用一定的算法对包头或者payload进行压缩/解压缩，以降低信息的冗余度；
数据去重，对传输过程中出现频次较高的数据进行编号，并使用指针进行替换，以节约编码所占用的空间；
内容缓存，将热点内容进行本地缓存，对热点内容的后续访问即可在本地直接返回，直接避免了对于WAN线路带宽的占用；
TCP优化，通过TCP代理将端到端的标准TCP切成多段，并对其中WAN一段的传输进行优化，改善标准TCP的拥塞控制和重传机制，或者基于UDP来增加吞吐量；
HTTP和其他应用层协议优化，这个就具体问题具体分析了。
FEC常用于对视频传输进行优化，发送方进行FEC编码，在原始数据包以外引入冗余校验包，接收方进行FEC解码，并通过冗余校验包对原始数据包的误码或丢包进行恢复，
字节跳动研发屏幕内容视频编解码器 BVC1S，编码码率相比 X265 节省 85.3% 。用在了飞书上。。。
使用超高压缩比率的视频聊天APP
视频 优化
Packet Duplication常用于对VOIP的传输进行优化，发送端对数据包进行复制，并通过不同的WAN线路进行传输，接收端会以收到第一份为准并忽略掉后续重复的数据包
VOIP 优化
对于企业来说价值最高的是UCaaS流量的优化，包括视频会议和VOIP等
WAN 加速和智能优化应用
基于线路质量QoS的智能选路
CP（控制面 用户态）、DP（转发面 DPDK）和SP（服务面）都是跑在x86上的，各个平面绑定不同的CPU
SMB（Small or Medium Branch）的产品10-100M \\ 4G \\5G \\Wi-fi
标准Branch的产品在100M-500M间
面向大型Branch/HQ/DC的产品通常定位在500M-2G间
不过考虑到IPSec，这些物理接口在真正跑业务的时候，吞吐量通常都会打上一定的折扣
WAN口1-2个(1G/10G/光、电)，LAN口2-8个，
提升IPSec性能的 Crypto Accelerator，
提高UCaaS能力的DSP
内置TPM芯片，用于CPE的身份认证。
内置一些协处理器
DPDK \\ 内核绑定
X86 中高端CPE
NXP 芯片提供IPsec加解密加速功能包
ARM 多为低端廉价CPE
CPE
Staging Server主要做认证和自动发现，和CPE间通常为私有协议，条件允许的话可以用DHCP。
Controller主要做密钥和路由分发，南向上各种形式都有，OpenFlow/BGP（重量级）/Netconf都有，用私有协议的也很多（因为轻量级）。
Analytics主要做数据采集和分析处理，南向上常见的有NetFlow/IPFIX/SNMP/Syslog等。北向上多以RESTful API为主。
此处不同的SD-WAN方案会有不同的设计
控制器
应用需要什么样的线路质量内嵌到系统中，然后自动生效
一、是应用WAN策略的默认模板
还要支持手工制定一份策略（路由、安全、QoS等）统一对标记为XX的对象生效。
二、支持把不同的对象（比如站点、设备、应用等）打上不同的标记或分组，
三、支持报表的定制与输出，保证SD-WAN的可审计。
Portal的位置，同样可以是On-Premise的或者在Cloud里面。
Portal （for 用户）
产品设计
第一种：CPE上线加上控制器把业务打通的全过程（见下方“打通网络”）
唯一的标识，如虚拟号、MAC
CPE并加电后，CPE会通过DHCP/PPPoE来获取IP地址
扫二维码\\短信\\邮件获取URL得到配置文件，再通过web或U盘导入CPE。
发货前厂家给配好是可以的，但是效率比较低。
客户参照指导书进行全部开局工作
做成即插即用，可以加电后触发DHCP/DNS来查Staging Server。获取到信息后，CPE会主动去找控制器，彼此之间完成双向认证，认证成功后就可以通信了。
CPE要去自动获取控制器的信息，包括IP、端口和认证信息等。获取的方式也有很多，
第二种：仅CPE的上线
ZTP(即插即用)
由于一些协议（比如BGP peer）和隧道习惯上会起在loopback口上，这时loopback的地址和路由也都需要控制器去做规划和配置
如果出于可用性的考虑，IPSec或者其他的最外层隧道也要起在逻辑口上，那么还要向SP宣告该逻辑口的路由。
CPE上线后，控制器就会选择最优WAN路径，下发指向最优出口的默认路由给CPE
要求：至少一端有固定IP
通常都是 ESP+隧道模式以满足穿越NAT
数据面over IPSec ，
控制面穿NAT时，OpenFlow是不用的，但BGP/Netconf通常要over IPSec （如果厂商改底层实现也可以不over IPSec），
私有协议可以自己设计机制来穿NAT，注意要设计好保活防止NAT老化。
IPsec 的NAT-T 穿越机制
BGP/OpenFlow/Netconf都行，私有协议也很常见。
私有协议的也不在少数，其好处是可以实现的非常轻量，而且不仅仅是控制面，有的厂家连隧道的封装，甚至CPE里的协议栈都自己定制了
控制器来集中完成隧道的建立和路由的分发，这样一来，多点和点对点在实现上其实是没有什么差别的
虚拟网络
自动打通物理网络和虚拟网络
IGMP和PIM无法跨Internet传播，因此CPE和控制器间一般用私有协议来分发组播的路由。
可选支持的，可用于电话会议或者视频会议，如果支持的话一般也在会归在高档的License中提供
服务链的话必选支持，由于涉及到策略问题，因此只能通过控制器去集中地控制服务链的路径
由于NSH目前支持的还很少，因此在串多个服务的时候，一方面可以给流量打上Service Tag，相当于起了ServicePath Index的作用，另一方面通常还需要去额外地匹配inport，相当于起了Service Index的作用。
Netconf配PBR，BGP引流，OpenFlow引流，或者私有协议发布Service Route都是可以的。通常来说，PNF或者VNF都是在CPE本地，是不需要走隧道的，但有时候一些增值服务要求部署总部，这时候就得走隧道送过去了
NSH（Network Service Header，网络服务头）是专门为服务链设计的封装格式，并且在OpenDayLight的SFC项目中采用
组播和服务链
还是隧道、加密、NAT穿越这些技术，IPSec仍然是可以搞定的。
客户侧
云市场 VNF
VM 自己安装 vCPE
绝大部分中小客户都只能用纯软的CPE
为了打通IPSec，站点侧和云侧至少要有一个公网可访问的IP地址，如果是云侧需要这个地址，就需要向Cloud SP申请一个Fixed IP
站点和VPC间做二层的需求是比较少见，企业做混合云主要还是为了打通三层
要么Cloud SP允许修改默认的VM安全策略；要么能在公有云机房放置物理CPE，从vSwitch打VxLAN到这个物理CPE上
二层互通比较麻烦
云
混合云
访问Internet可能需要单独做认证，这时CPE需要提供WEB认证的功能。
LAN的策略
Internet流量要做限制、限速，免得一些非关键流量占用宝贵的WAN线路带宽。
需要CPE具备识别HTTP/HTTPS流量的能力，对SaaS办公流量提高优先级，对于其他非办公流量，进行限速或者直接丢弃掉。
WAN的策略
流量策略
经过总部/数据中心的防火墙的统一过滤后再送到Internet上，
那么控制器需要向分支CPE下发一条默认路由，通过隧道指向总部的CPE，覆盖掉WAN口上可能被SP分配的默认路由。
优缺点：好处在于可以做到安全的集中部署与管理，但是流量发生了绕行，而且对总部/数据中心的带宽要求比较高
Internet流量先送到总部
DIA对于CPE的要求就比较高了，首先CPE上要有丰富的NAT能力，包括NAT/PAT、NAT Server、双向NAT等，需要支持带状态的会话能力。
控制器在下发IPSec规则时，需把NAT后的流量排除在IPSec的兴趣流量以外，否则就又被送到总部去了。
直接把Internet流量送到Internet上，即 DIA（Direct Internet Access）
禁止访问公网
流量模型
访问公网
设备都需要有一个唯一的标识，CPE可以出厂时配好也可以固化在硬件中，VNF在拉起的时候会生成并注入序列号，而控制器的话用IP和FQDN通常就可以
唯一的标识
系统中的各个组件间需要有相互的认证，防止非法CPE和控制器的接入，这块的实现可以通过外接LDAP/RADIUS来做，也可以通过PKI体系来做，
SD-WAN产品自身也应该提供认证服务器或者PKI Server，如果企业自己有认证服务器或者PKI Server，要需要支持与其进行对接
认证
第一套是IKE身份认证的非对称密钥
第二套是对称密钥。在传统方案中是通过DH来分布式计算的，在一些SD-WAN方案里则会直接由控制器来进行同步
这就相当于替代掉了IKE的作用，那么第一套密钥的身份认证工作改由通过PKI来实现，省去了维护预共享密钥的负杂工作
IPSec / IKE 的两套密钥机制优化
over IPSec
数据平面的转发数据
私有协议的话over在SSL/TLS/DTLS
Netconf和OpenFlow也都是原生over在TLS上面。
简单的MD5破解起来轻而易举，业界始终都没有找到更好的办法来保证BGP的安全，重大的BGP劫持案例从来就没有间断过。如果SD-WAN方案中控制面要用BGP，那么最好也over在IPSec里面，这倒也没什么奇怪的，传统的方案里IGP实际上也是over在IPSec里面的。另外，原生的BGP还穿越不了NAT，正好用IPSec一并给解决了
BGP over 在IPSec
控制平面信道
Logging、xACL、分级分域的 FW和DPI是最基本的要求
IDS/IPS/AV/UTM/NGNW，通常就是通过Service Route来串接
那么分支的流量就要绕到总部/数据中心去，
如果是在总部/数据中心做集中式的安全
那么就在分支的CPE上做文章，或者就近引流给第三方的SECaaS服务商。
如果是 DIA 的方式
业务层面
加密
PCI DSS对于所有涉及信用卡信息机构的安全方面作出标准的要求，其中包括安全管理、策略、过程、网络体系结构、软件设计的要求的列表等，全面保障交易安全。PCI DSS适用于所有涉及支付卡处理的实体，包括商户、处理机构、购买者、发行商和服务提供商及储存、处理或传输持卡人资料的所有其他实体。PCI DSS包括一组保护持卡人信息的基本要求，并可能增加额外的管控措施，以进一步降低风险 防火墙，加密（最好应用层进行加密）等要求、对于系统密码及其他安全参数，不能使用供应商提供的预设值（默认密码）
符合PCI DSS标准
银行和零售等 ，要保证为支付业务提供一个安全合规的网络传输环境。
满足行业客户的标准
安全
如果控制器只是做纯配置类的工作，那么实际上对于性能的要求不是很高，集群采用主备模式即可
此时要求ZTP实现中，能够为不同的CPE指定不同的Master控制器。
如果还要负担路由控制类的工作，考虑到某些目标客户的规模比较大，那么集群最好能支持多活的模式以进行负载分担，
控制器集群设计
网络层面的高可用就非常复杂了，端口/设备/链路/隧道/路由/状态，要考虑的方面很多，而且彼此间还要做好关联。因此，做高可用是需要代价的，不同的站点要在可用性和成本间做好平衡。
中小型的分支而言可采用Single CPE + Dual Internet
大型的分支可采用Dual CPE + Hybrid WAN，
总部/数据中心可采用Dual CPE + Dual Internet + Dual MPLS，
还要根据站点的实际情况（eg:已有MPLS线路）来设计边缘的物理拓扑。
物理拓扑设计建议
下连可以起Port Channel
Single CPE
下连是接交换机，交换机的话就用VRRP+基于VLAN的负载均衡，
下联接路由器路由器的话用IGP+ECMP就行了。
Dual CPE
LAN侧：
可以在不同的WAN线路上起不同的隧道，
也可以在逻辑口上起一个隧道然后承载在不同的WAN线路上；
Single CPE
可以在两个CPE上起VRRP支撑一条WAN线路上的一条隧道，
也可以在两个CPE上起不同的隧道跑在同一条WAN线路上，
Dual CPE
WAN侧线路不通的情况时，两侧CPE上的路由要能快速地完成收敛。
如果采用控制器集中分发路由的方法，那么控制器首先要搞清楚不同WAN线路间的可达性，检测到线路断了之后需要能正确地推送新的路由。
如果是采用IGPoverTunnel这类传统的分布式路由，可以等IGP的自然收敛，最简单但是速度比较慢，要加快收敛的话可以用Tunnel BFD去关联IGP，但是会产生额外的开销。
链路故障和收敛
已有站点不改变现有组网，通过智能接入网关接入公有云。
旁挂
WAN侧：
逻辑拓扑设计建议
网络层面高可用
高可用
QoS，需要提供Traffic Shaper、CAR、DSCP Mark/Remark、Queue、AQM、Tunnel QoS、HQoS的能力，并提供面向应用的QoS能力
远程/移动接入，定位于总部/数据中心的CPE，可选地支持L2TP和SSL VPN。
Wifi管理，定位于小型分支的CPE，可选提供Wifi的认证、频段管理等能力。
时钟同步，可通过NTP为SLA提供精确的时间信息。
CPE可管理性，提供远程文件拉取、远程重启、不中断升级的能力。
其它技术要点
SD-WAN
0 条评论
回复 删除
下一页
