SD-WAN部署案例发布将SD-WAN再次掀起一个新高潮，谈到SD-WAN，近网上有很多不错文章，尤其是很多写SD-WAN技术原理、发展历史、特色功能等等，但是从SD-WAN具体实践部署的角度文章不算太多，作为一位老网工，历经了数次广域网技术的大转型，近参与几个大型基于SDN的WAN重构建设项目，在SDN技术发展十周年之际，抱砖引玉从SD-WAN实际部署的方面出发分享一些心得，与大家共勉吧。

  本文将分享三种不同场景的SD-WAN的部署案例，包括：SD-WAN接入-基于Internet Edge解决方案，SD-WAN骨干网-基于SRTE 流量调度的Core解决方案，以及基于多厂商WAN的SDN协同控制器或业务协同编排器。这三个场景比较有代表性，也是目前遇到的典型的SD-WAN的需求，下图以大地云网的架构示意图做参考，便于大家理解!

  SD-WAN接入服务 ，也是典型和通俗的场景，有时也称为SD-WAN Edge 解决方案，运营商可以用这个技术作为互补或下一代替代，公司能够利用这个技术实现分支机构按需组网。

  市场需求情况：随企业上云和广域网按需接入的需求日益增加，传统的MSTP和等专线业务由于成本和部署周期长等问题已难以满足云和互联网时代的需求，面向基于互联网和POP路径选择的SD-WAN是技术随之诞生，这是一种面向分支灵活接入的SDN-WAN 部署场景。由于目前国内运营商 V**网络的已经大规模部署，短期内运营商不会用SD-WAN替换或其他专线业务，但是会利用SD-WAN技术丰富V**业务或者做为后一公里的接入技术。

  主要的技术实现：其实SD-WAN在技术上没有本质上的革新，但SD-WAN在理念上有了新的突破，融入了SDN控制思想结合POP线路SLA探测技术，同时能实现云网一体的协同部署，技术实现如图所示 ：SD-WAN通用技术及通用功能不在这里赘述，前两天有篇文章写的非常详细，这里从实际部署的角度谈谈几点考虑：

  1)在SD-WAN设计和部署时，在中国需要考虑南北运营商Internet瓶颈的问题，客户部署设计时会选择在多个机房部署多线POP节点，在每个POP节点部署vPE设备，各个POP节点的vPE 通过专线组建骨干网保障SD-WAN汇聚上来的流量SLA，在这个案例中 POP节点的vPE 通过客户的 PE节点来组建(在其他项目中我们采用SRTE作为骨干网流量调度)。在一个大SD-WAN部署时，每个CPE会根据控制器的下发列表探测并选择佳的POP节点，并连接佳运营商线路的vPE，在SD-WAN设计时Edge和Core都需要考虑线路的SLA保障，再利用SDN控制器的部署全网统一的路由，安全和QOS的策略部署和控制，从而解决基于Internet接入服务质量问题和全网统一策略部署问题;

  2)另一个要解决的问题是SD-WAN的租户如何与现网的租户对接(租户分支机构有可能是SD-WAN线路，有的是专线混合组网)，前面提到目前几大运营商基本上都已经有自己网络，SD-WAN的对接是必须考虑的问题，我们在PoP点的vPE如何与 PE节点实现自动化对接上有多重方案能轻松实现，包括纳管PE，Option B，Overlay等等。

  3)对于CPE的自动部署与传统路由设备包括线路之间的的备份和负载分担也是SD-WAN能否成功的关键因素，由于现在多数厂家的SD-WAN 控制器与 CPE盒子是紧耦合，导致后期被厂商锁定，因此有几点建议考虑：如CPE盒子是否支持OpenWRT? 小盒子 ZT-PnP自动部署机制如何(防火墙穿越能力)? CPE如何自动选择延时小或带宽佳的接入POP点? 能否做到即插即用、自动连接、自动切换。

  4)对于整个系统的核心是SDN控制器，控制器的可靠性、集群、租户自服务管理 和易用性也不可忽视，作为一个运营商通常还需要 SD-WAN 控制器的北向与现有的BSS/OSS对接集成也是要考虑。 虽然SD-WAN没有大的革新技术，但一个完整和成熟的SD-WAN方案技术上也不简单，SD-WAN带来的部署运维简单易用是明显的，而且企业不再需要专业的CCIE人员设计和运维，对于分支机构的扩展和部署，传统的部署可能需要几个月，而现在理论上分钟级就可以了。

  面向服务商和大企业的SD-WAN核心骨干网调度(包括DCI)，典型场景：大型运营商 和OTT客户的SD-WAN骨干调度(包括DCI)， 大企业 SD-WAN核心骨干网。

  主要的市场需求：SD-WAN骨干调度核心思想是流量调度和基于多租户的服务和管理，有时候我们也称之为SD-WAN DCI/ Core解决方案，这个方案和前面提到的基于互联网的SD-WAN Edge在功能和定位截然不同，但两个方案定位互补。

  主要的技术实现，目前主要有三类方式： 类基于白牌机+Openflow SDN控制器-Google B4就是基于这个方案(2010-2012年)，Google B4的核心是它的TE调度和算法而且它巧妙地避开了的众多缺陷，包括基于源和目的地址配合DSCP作为流表的转发策略，但项目其关键技术细节(如SDN控制器平台算法)即不对外公布，也不对外销售，后来者虽然有模仿但也很少能超越，除了Google，我说了解到一些客户对这个组合方案反馈还是有些问题，包括白牌机对 SRTE 支持能力 、 BFD/Tunnel 支持性能和数量 ， 路由策略和能力 ，交换机流表和端口缓存的大小 等等，毕竟是交换机的方案也不能勉为其难，更何况连Nick McKeown 现在又转向主导的可编程语言P4并创立Barefoot Networks;当然目前业界有一种新的思路基于白牌机的Overlay方案，利用vPE配合白牌机来解决上面提到的问题，vPE与交换机互补来实现流量调度和路由策略等功能，由于篇幅问题这里就不在展开讨论; 第二类有基于 +SDN控制器实现全网的流量调度和V**租户管理- 类似工行SD-WAN骨干网(2017发布)， TE多年前就有在部署，就目前运营商客户部署情况看，绝大部分抱怨 TE的部署过于复杂因而真正在生产网TE隧道使用的并不多，由于成熟有余先进不足，这里就不想过多的赘述 ;第三类方案也是笔者更希望看到的，是基于SR实现流量调度和管理SR+SDN控制器，和的网络类似，但是SR可议基于源头组建一个完整的LSP Path而且和现有的网络可议兼容， 因为SR也是以标签交换为基础的, 只需要对现有的IGP协议进行简单的扩展，就可以实现TE、FRR、 V**等功能， 包括流量工程TE的自动下发、自动计算、自动调整、自动引流和自动调度。

  基于SRTE的SDN控制器目前在业界属于非常领先的技术，SR的基础转发表甚至比LDP更简洁，利用了源路由技术与SDN理念完美结合，在流量TE管理方面，SRTE比RSVP-TE状态少很多，也不需要LDP/RSVP信令那么复杂。但是目前各个硬件厂商(包括第三方控制器+SR路由器)在SRTE具体实现还是有一定差距， 但有几点是部署时需要仔细考虑的：如何根据链路质量(load/loss/delay)动态实时调整TE路径以实现全局负载均衡、隧道快速倒换策略和逃生算法(如思科PBTS技术)、配置回滚的一致性、离线流量规划、TE路径的对称故障检测等等，各家方案功能差别很大， 在国内能真正完整实现基于SRTE的SDN控制器更是屈指可数。大地云网作为国内专注于SDN整体架构和软件技术平台，经过2年多技术攻关和研发测试的创业沉默期，终于成功力克这项艰巨的技术挑战，次实现了完整SR-TE的商用控制器平台并开始商业部署。

  基于多厂商的SDN协同控制器或业务协同编排器，目前大型运营商与OTT客户和超大企业在SD-WAN多厂商异构环境下已经开始考虑。

  主要的市场需求：在前面两大类SD-WAN在部署时，客户往往需要多个厂商设备实现一种平衡，客户是不希望被厂商锁定，但目前多数SD-WAN的网络还是封闭的管理系统，基于多厂商的SDN协同控制器或业务协同编排器是一个难题，互操作和资源统一管理问题是需要上层SDN协同控制器来解决，这类解决方案对大型SDN网络运营尤其重要 。目前几大运营商与OTT行业都意识到或开始考虑这个问题，相信将来企业客户随着SDN部署也会有类似需求。

  主要的技术实现：以某运营商为例，两年前开始预研云环境下骨干网多厂商控制器协同工作问题，经过近两年的设计、研发、测试和联调等各个环节的艰辛努力，该客户成为国内家在全国骨干广域网上实现云网一体化服务的运营商。 同时，也开创了在国内大型SDN项目中，选择独立的核心SDN软件企业与多家大型网络设备厂商通力合作，以确保运营商能够全面主导、把控SDN运营需求和技术架构方向及决策话语权，为终云网一体化产品按时商用上线提供了一个成功案例。但是多厂商的协同控制器需要根据客户的业务实际情况来定制开发，需要SDN软件厂商有非常强的研发能力和行业经验，包括对厂商硬件的北向接口规范、云网技术的深入了解、主流公有云系统的对接、以及和客户OSS/BSS业务系统集成等，实际做起来是非常的复杂，不是一般的SDN厂商和公司玩的起的。 如图所示，随着SD-WAN多场景和多厂商的部署越来越多，多厂商的协同管理和统一编排将成为未来SD-WAN的重要话题。

  后展望一下SD-WAN的未来，SD-WAN是在互联网高速发展和云网融合的大背景下的新思路和架构创新，SD-WAN在理念上的突破远远大于在技术层面革新， 由于时间和篇幅原因，这次和大家分享的三类SD-WAN相关案例和部署场景，表面上看似三个独立SD-WAN方案，但从架构而言，又是一个三维一体的完整架构。今天SD-WAN的旅程慢慢的开始，SD-WAN作为一种新的业务模式带来的价值和意义前景不可估量，相信未来的SDN能够更好理解应用并为应用服务，提供精准的智能调度能力(尤其在SRTE，POP探测选择算法)，能提供更强大的智能运维工具为Underlay和Overlay保驾护航，除此之外未来的SDN的开放性、通用标准和互操作(不被厂商锁定)也是我们从始至终在追求的目标，不忘初心，让我们拭目以待。返回搜狐，查看更加多