前面做了SDN网络解读，今天和大家聊聊SDWAN技术是什么？之前提到的便是答案（SD+WAN），但是真正的答案是什么，或许几乎没有几个人能答上来。

　　此刻想起乔布斯老爷子的一句话：

　　"Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it's really how it works. The design of the Mac wasn't what it looked like, although that was part of it. Primarily, it was how it worked. To design something really well, you have to get it. You have to really grok what it's all about. It takes a passionate commitment to really thoroughly understand something, chew it up, not just quickly swallow it. Most people don't take the time to do that."

　　前文花了两个章节的篇幅来说一些看似怀旧或者无关的话题，本质上是在告诉读者，在漫长的网络架构演进的过程中，SDWAN是如何逐渐被提出来的，用户最根本的需求是什么，”You have to really grok what it's all about"并慢慢咀嚼其中的含义和深刻的理解。

　　3.1 SDWAN解决什么问题？

　　这个问题需要从不同的客户入手，ATM当年最大的问题就是想Anything transport over ATM，不根据实际的情况分析，就想一口吃成个大胖子，最后苦了自己。正如前文我们所看到的，即便是苹果设计MAC，也有macbook air/pro / MAC Pro /MAC mini来针对不同的场景。通常我们分为如下几类：

　　1. 新型的企业，网络构建主要以销售门店为主

　　2. 已经建设网络十多年，并且拥有基于专线的传统型企业

　　3. 运营商广域网，随着过去十多年的建设有成熟的MPLS骨干网络支持。

　　3.1.1 针对新兴企业

　　这一类型的企业分支机构网络非常简单，通常就是一些进销存的管理PC和收银机以及部分门店安保监控等传感器，通常这类的门店并不需要专职的IT人员，其它员工也完全不懂网络。这类企业有一个共性，门店扩张和迁移非常迅速，对成本也极度敏感，通常仅需要门店到数据中心或者公有云的安全连接即可，上行链路以Internet链路为主，网络拓扑较为简单，功能需求也较为单一。

　　这类客户通常仅需要简单的网络地址规划和VPN连通即可，Day 0 的零接触配置（ZeroTouch Provision，ZTP）是用户最为看重的功能。而日常运维只需要一个Dashboard监控门店上线情况即可。

　　Velocloud和Meraki在ZTP部署上用户体验非常棒，特别是Velocloud，它的做法非常巧妙，通过把一些配置弄到一个URL里，由传统的POST上传JSON变成了使用GET将参数传递进入的方式。也就是说只要把网关寄送到门店，随便找个店员微信给他一个URL，只要店员会连WiFI，就可以通过这个URL把配置参数传递给路由器。

　　但是Velocloud犯了一个致命的错误，在VMware和思科的竞争过程中，本来需要简单的场景，VMware只出了一张Velocloud的牌却同时要和Meraki和Viptela竞争，使得很多对这类新兴企业无用的功能加入其中，变相的提高了客户的成本和运维复杂度。

　　其实这类场景最该做的就是公有云的运营商（阿里云的SIG）和一些卖带宽的二线运营商（例如Zenlay收购的kitty姐的大河），只需要一个简单的K-V数据库，Key是小盒子的局域网IP网段，Value是广域网地址和IPsec VPN的密钥，加上一点点CA证书和一个TLS based GPB/MQTT update就行了，OpenWRT加华强北的硬件估计100RMB随便做，根本就没有复杂的路由防环什么的，超级简单，大概2015年我在某司的创新项目就一个人撸过这些代码，OVS+IPSec，然后一个python脚本连MQTT根据Cloud指令改本地OVS配置就好，或者上传BR的IP网段。

　　但是这个场景里的玩家却该做简单的不做简单，非得盯着下一节要说的传统企业网。还是Meraki简单点好，不忘初心，方得始终，

　　3.1.2 已有数据中心和专线广域网的企业

　　这类企业非常多，而且大多数都是中大型企业，分支机构网络规模也较大，十多年的业务发展使得广域网已经具有较大的规模，但是他们为啥也需要SDWAN呢？或者说他们需要哪种类型的SDWAN呢？先从他们遇到的问题入手吧。

　　1.广域网管理困难之运维难度：随着业务的扩张，很多企业的广域网已经构建了十多年，由于运维团队的变更和水平差异，通常设备配置混乱，大量的动态路由协议伴随着随意配置的ACL/Route-map，没有规划的Route-tag和不同的Route-Type，再混合随业务临时添加的PBR和大量的复杂的QoS策略，命令行杂乱无章，设备五花八门，现代的DevOps面对这样的网络束手无策，大量的人力物理消耗在运维上，使得IT部门无法保证业务服务质量。在没有SDWAN的年代，我也亲眼见证了某快消客户因为一个业务变更，在半夜找代理商借了20个工程师同时对3000多台广域网路由器进行配置变更，这些都是过去血泪史。

　　2.广域网管理困难之协议限制：过去广域网的主要功能便是连通，大多数路由协议设计的年代是90年代初期，并未考虑到网络规模会如此迅速的扩张。而OSPF/ISIS等路由协议本质上是进行路由数据库的分布式同步和分布式最短路径计算，因此在一个SPF域内很难实现灵活的路由调度和提高链路资源利用率，通常唯一能够调整的就是Cost。

　　BGP等协议通常较为复杂，而国内大多数企业级的网工并未清楚的接受过BGP协议的培训（这得怪Jeff Doyle的写的太差，使得大多数人对BGP和mcast都不了解。

　　所以最近金融保险等行业国家要求上BGP和IPv6也就是这个原因了。

　　3.广域网安全和互联网隔离：最近一段时间大量的护网行动实际上也看到这类客户的痛点，随着互联网接入增多，广域网安全管控成为一个大问题，大量的陈旧的设备非常容易产生漏洞，而广域网和内网隔离又因为传统设备的限制没有明确的界限，安全边界相对模糊，通常只是挂一个防火墙完事。

　　这类客户上SDWAN的根本原因在于：需要一个技术平滑的演进并对十多年发展而来的广域网进行整理和规范化构建，底层拓扑借助Internet降低成本，隐藏底层拓扑获取安全隔离的抽像层便于DevOps的实施，并且借助于Telemetry等遥测技术实现可预测性的AIOps，充分利用广域网带宽并支持弹性部署，灵活可控的多云互联互通和云应用的直接连接。

　　看上去内容挺多的，那么下面就分几个小节来分开阐述：

　　3.1.2.1 互联互通和拓扑隐藏

　　SDWAN最基本的功能便是互联互通，如何将每个站点后面挂接的网络作为资源或者服务提供出来，供其它设备选择和传输是这一节的重点

　　1.广域网/局域网隔离： 借助“软件定义”中的Overlay的概念将底层的广域网链路拓扑和连接介质类型的复杂性和上层应用之间解耦合， 从而我们把面向局域网的端口称之为业务接口（Service Interface），而面向广域网的接口则称作传输接口（Trasnport Interface)，并且将两者的路由表进行隔离，同时对广域网接口配置访问控制列表仅允许控制器流量和Overlay隧道流量。

　　业务接口考虑到对接SDN网络，需要支持Overlay传输模式和多VPN路由模式。

　　2.多广域网介质支持：SDWAN一定要对多种广域网介质的支撑，例如4G/5G上行，GPON/EPON或者以太网专线上行链路，当然还有一些客户在升级的过程中还存在大量的E1等传统链路。

　　如上图所示，对于用户而言，他们往往最关心的本质是：如何唯一的标记这个路由器后面所接的网络？其实是在完成路由表中的下一跳信息。

　　同样借助“软件定义”中的Overlay的概念将底层的广域网链路拓扑和连接介质类型的复杂性和上层应用之间解耦合。

　　对于Overlay层面，我们可以借助以往的Router-ID的概念对路由器进行编号，然后用链路颜色（Color）标记具体是哪种类型的链路，例如4G/5G或者MPLS，最后再选择何种封装形式到达，IPSec？或者是MPLS Label或者是GRE隧道或者是VXLAN？这就是思科解决方案中定义的TLOC（Transport Locator），即将客户最关心的三个信息组合在一起构成TLOC：

　　1.资源在哪台路由器(System IP)

　　2.资源可以通过哪种链路类型到达（Color）

　　3.资源可以通过哪种封装方式到达，是不是加密（Encapsulation）

　　当你看到TLOC=<1.1.1.1,MPLS,IPsec>时，也就非常直观的知道，某个服务或者业务可以使用MPLS链路并执行IPsec封装到达1.1.1.1获取。

　　通过这样的编码方式，我们轻而易举的将底层的链路复杂性封装了起来，并且对于overlay路由的构建也不失灵活性。

　　3.多控制层协议互联：广域网需要连接各种资源和传统的网络互操作，平滑的割接，对Network Overlay和Host Overlay的支持。它需要对传统的路由协议OSPF/RIP/BGP支持也需要对新型的BGP-EVPN/LISP等协议支持。思科采用的便是前文所述的BGP，通过扩展BGP协议支持了大量的路由协议互通和重分布，它可以使用BGP的TLV，将任意的VPN前缀和路由前缀关联到TLOC上，通过这样的方式描述的资源和传输地址的关联性。而路由的分发则采用了RR的做法，利用vSmart去分发路由。

　　4.路径选择：这一点便是大多数厂家容易犯的一个大错误了，大多数厂商设计时都认为控制器具有上帝视角，应该由它来算路径，事实上大量的underlay链路的可达性管理会极大的影响控制器支持的容量，因此很多厂商在支持到几百台规模时控制器已经不堪重负了。思科则采用了一种很巧妙的递归路由和分布式可达性管理的策略。

　　我们都知道BGP不支持NAT穿越，思科通过巧妙的利用vBond识别了NAT前后地址，并将Mapping关系返还给Edge路由器后，Edge路由器通过TLOC update路由的方式将TLOC和underlay地址以及IPSec密钥等信息发送给了vSmart，并让vSmart作为RR反射给其它设备：

　　最后路径的查询和可达性由每个edge设备产生BFD会话来监控延迟和抖动，并根据结果选择最优的TLOC传输。

　　5.隧道封装：VXLAN的VNID长度为24bits，而MPLS标签也是24bits，不得不说是个巧合，于是思科的SDWAN也非常巧妙的在IPSec内部放置了24bits作为Label区分不同的虚拟网流量：

　　6.路由策略：很多年前，在没有SDWAN的年代，我们就通过BGP-FlowSpec的方式帮助某大型国有银行进行集中式的策略路由控制，而SDWAN也借鉴了FlowSpec的功能，可以通过它定义策略，并通过BGP消息发送到不同的站点。

　　任何一类的策略无非就是Classification+ Action， 在分类中，它可以根据Site-ID/VPN/Application DPI/地址段/BGP的属性多种方式进行分类匹配，Action则可以修改下一跳/加计数器/增加FEC等增值业务等。业务逻辑上抽象的非常不错。

　　所有的策略再也不用登陆到每个设备上配置了，集中在控制器上点点鼠标就搞定了~

　　7.云端互通：通常伴随着云计算的使用，SDWAN还伴生了云端互通的需求和虚拟化的支持，即同一套软件既有放置在办公室数据中心等场合的物理机，也有纯虚拟化的平台放置于公有云中，并可以为公有云提供AZ互联或者公有云和私有云专线互联的业务。

　　这一节全部用思科举例，并不是我偏袒它或者故意说它好，的确姜还是老的毒辣啊，它这套基于BGP修改的方案的确很好的契合了客户对广域网改造的需求，把Overlay和Underlay非常好的抽像分离了，唯一的难点就是网工们需要重新学习一套路由协议。

　　3.1.2.2 控制器设计

　　前面说到路由选路的时候就提到过一部分，如果路由决策全部由控制器集中下达，对全网的可扩展性和可靠性都将带来极大的影响，在SDN中，控制器如何放置都成了一个专门研究的学科，分布式控制器和在网络中分布式放置和多机构成分布式集群便成了刚需。而配置具有大量的不确定性，任何配置的增删减都需要很好的抽像，特别是传统的基于CLI的厂商，需要严格的使用Yang model来规划配置。

　　3.1.2.3 遥测和AIOps

　　伴随着SDWAN规范化的部署，客户对于遥测（Telemetry）的需求也在增加，逐渐有些大型客户开始根据遥测数据进行AIOps的探索，特别是基于数据的可预测路由和可预测流量工程，它可以极大的提高客户对网络的管理能力，当然这里有很多保密的算法给某司有NDA就不多说了，只是告诉大家这里面有大量的AI算法可以用进去。

　　3.1.2.4 增值业务

　　这一类业务主要是做应用加速的，例如Citrix和Silverpeak提供的AppQoE，做FEC，链路绑定等，其实应用层有了BBR，特别是很多应用的操作系统换成CentOS 8就可以轻松开启，这些传统的AppQoE业务讲真没有多大的必要。而我最近在测试某家的产品的时候，开了FEC发现比不开更差，原因就是在极度拥塞（上海到香港20%丢包）的场景下，FEC反而会带来大量的丢失，有些东西该交给应用的就给应用吧。

　　然后另一类增值业务就是做安全，特别是应用层的IPS。以思科集成Snort和Fortinet为代表，这一类的做的挺不错的，但是都缺乏深层次的整合和通用的Service-chain的抽像。

　　当然最后还有一类就是QoS了，基于应用的QoS,层次化QoS，各种队列，有些时候我还在反问自己一个问题，到底设计了这么多QoS有哪个客户用好过的？一些简单的QoS规则加上AIOps才是王道。

　　3.1.3 针对大型网络的Segment Routing

　　SR的出现可以说是很好的解决了大量部署了MPLS网络的客户骨干网灵活可编程的需求。伴随着国内的IPv6的部署，很多大型拥有专线的企业或者逐渐部署V6广域网的企业可以开始基于SR构建新一代的SDWAN架构。

　　未来企业的网络将如何演变我们将进一步的沟通，对sdwan和海外专线感兴趣的可以随时技术沟通和交流。

TikTok千粉号购买平台：https://tiktokusername.com/