虽然国内外对SDWAN和企业上云的认知都是会将其定为为刚需，各位搞SDWAN峰会的也是风光无限，但是扪心自问，谁真的赚了钱？就像我以前说过一段话：
Gartner的报告里，一个Leader和Niche Players象限挤满了的行业出了什么问题？是技能对了而市场没有成熟？如果是这样，该当看到大量的visionaries。但偏偏不是，那便是市场对了，而技能本身错了？
zartbot.Net，"大众年夜众号：zartbotSDWAN，路在何方？
对付我而言，现在的SDWAN和十年前基于STP/VLAN的数据中央类似，在业务迅速增长的时候，试图通过集群的办法简化运维，当年涌现了VSS、FEX或者IRF的技能， 同时也伴生了TRILL、VPC等技能实现。大二层的思想自然就这么出身了，终极这些东西被历史抛弃的缘故原由是什么？Overlay解耦
Insieme构建的Overlay技能以及ACI整套商用方案的涌现使得辩论逐渐消退，另一方面其它厂家基于BGP-EVPN+VXLAN成了数据中央的标配，当然随着规模进一步扩大，BGP的问题显露出来，你看人家Google都用自己的分布KV好多年了，然后转发规则越来越多，TOR越来越繁芜，很多东西在云上的VPC实现都offload到主机了。
当然这些不是本日这文的重点，重点是回顾一下广域网最近这十年的发展和业务需求，以史知兴衰，考试测验着探索出一条新的路出来，而且我也坚信这样的路充满寻衅和质疑，所有的人在这个市场上考试测验了那么多年为什么都失落败了，一定是一个工业界上非常有寻衅性的难题，并且答案一定是要另辟路子才能构建的。
1. 广域网技能的发展
太早的事情咱就不多说，前溯十几年吧。这图留到了17年，没有加上最近刚发布的8300、8500，由于那些还有更大的变革，下次再说吧。
思科从2600系列路由器开始在传统路由上增加了语音的功能，然后2800系列开始添加IPsec VPN功能，以是路由器从2600时期的MultiService，就变成了ISR，即“集成业务路由器”的时期。当然还有一个在2008年附近发布的产品叫ASR1000系列的聚合业务路由器把多业务领悟推向了一个新的高度，后面的ISR4400、ISR4300、ISR1000都是借助这个架构履行的，以是您会看到IOS到IOS-XE有一个明显的分界。
1.1 集成业务路由器ISR
ISR系列推出的时候目的就很明确：集成多种业务，而下面这图则是当年的办理方案，分支机构路由器集成了语音的功能，支持IP电话通过路由器和PSTN通信，并利用Cisco Unity Express构建带语音信箱的PBX，另一方面集成了IPSec VPN和SSL VPN的功能，员工可以远程连接到这台路由器的网络中。然后还集成了Waas Express(WAE)广域网压缩缓存和加速功能，然后还有利用Zone Based Firewall的办法构建的防火墙业务，后期还有一些Wireless AP的模块集成。
当然多业务的集成也面临很大的寻衅，毕竟那个时期的IOS还是单线程的，好在当时的带宽并不大，另一方面随着ISR第二代2900、3900发布，支持Intel X86 CPU的版本极大的提高了性能。
而另一方面，在多核心多业务处理器上，思科也准备着一个大动作。
1.2 聚合业务路由ASR
IOS单线程的问题终极被基于IOS-XE平台的ASR1000办理了，在转发平面采取了自研的多核心处理器QFP，掌握面采取了IOS已有的代码，并通过一个叫FMAN的软件组件和转发面通信，为什么叫ASR呢？由于它更多的是处在很多企业总部的位置，当然须要聚合多种业务。ASR1000完全的替代了7200、7300路由器，同时也替代6000、10000系列BAS，后来还基于ASR1000平台衍生出了CMTS的有线电视宽带汇聚平台。
这些汇聚业务的根源在哪？由于我们不雅观察到了广域网繁芜的情形，大量的设备串接在广域网线路上，例如压缩、访问掌握、远程访问、流控等等..下图是我当年做的一个胶片：
当年为理解决这些事情，最常见的做法便是在Catalyst 6500或者7600路由器上插各种业务板卡，至今还有很多友商在做着这样的事情。但是我们创造全体转发路径太长了，报文QoS和策略都很难调配，同时须要大量的策略路由去牵引流量，于是趴地上想想，为啥不集成在一个设备上做呢？
终极实现这些功能的便是QFP处理器，2004年开始设计，2008年发布：
当然现在这个芯片已经发展到了第三代，核心数已经靠近900个并且可以四个芯片做集群。另一方面，把这么多网元和功能集成进去，软件功能的顺序如何处理，是利用流水线还是RTC，流如何调度，这些都是一些保密的东西了，暂且不说了。
1.3 SDWAN的起源：Cisco intelligence WAN
大概2009年的时候，作为ASR1000的测试团队一员参与测试了OBS的IPsec VPN桥接MPLS VPN的PE测试（类似于现在的Azure vWAN hub），测试完成后顺带连支配方案和架构设计都给AS团队做了，然后就被调去做TME，做了海内四大行中的两家的广域网改造项目，同时也做过M的连锁餐饮和H的连锁酒店广域网项目。
当时的认知便是利用互联网线路搭建广域网是可行的，而且规模上到几千个分支机构也可履行，该当不须要像四大行那样的专线网络了，国外实在也有同样的认知。于是大家基于DMVPN的广域网想做更多的探索，一方面是当时思科的VPN种类太多了，CryptoMap、GRE over IPSec、IPsec over GRE、SVTI、DVTI、EasyVPN、DMVPN、GETVPN，当年伴随着IKEv2的支配，思科决定在VPN上统一成FlexVPN：
但是这件事在后期研发的过程中受到了一些影响，终极选择了以DMVPN为骨架，然后合营原来为运营商做PE时采取的FrontDoor VRF和InDoorVRF功能整合起来，构建overlay的广域网，然后沿用PfR功能做广域网选路，并进一步整合AVC、WAAS和Akamai等CDN功能在一起
大略的加法构成了思科的IWAN办理方案，支配起来实在非常的繁芜，特殊是PfR和QoS须要调度大量的参数，终极这个做加法的项目并不是很成功，而且我自己一贯反对这样繁芜的功能叠加和高内聚的项目，终极这样的实现办法产生了灾害性的后果。对付一条路由，广域网上由四套路由协议决定，PfR、Overlay的EIGRP、DMVPN的NHRP、underlay的IGP，然后同时由于PfR的问题，还要约束客户支配拓扑，BR/MC的放置都是问题， 自动路径选路同等性的问题也无法协同办理。
在那几年完备谢绝给客户推举这套办理方案，还闹出了不少抵牾，现在来看是光彩的：）
1.4 SDWAN的插曲：ThinCPE及两大云网
2014年在公司内部既然不推IWAN，总得证明IWAN是错的吧，于是我自己开始做减法，利用OpenWRT+OVS+IPSec+VXLAN和自己写的基于MQTT的掌握面构建了一套低本钱的SDWAN办理方案，我把它叫做ThinCPE。
这套方案也做过很多Demo，当然包括后来创业的大河云联的K姐，以及大地云网的鲁大师（我当时老板）。海内的SDWAN的遍及该当便是这两大云网的功劳吧，K姐从阿里云出来自然能从云端看到上云的需求，而鲁大师作为研发大佬自然也看得清楚。
现在回忆起来我自己做ThinCPE的这段经历，失落败的根源就在对底层软件的开源依赖太重，使得原来的Thin的初衷变得越来越胖重，ODL去管理Remote OVS也有大量的可靠性的问题，所往后期在做Ruta第二次考试测验的时候，就没有再犯这样的缺点。
我一贯都在跟很多同事和客户说：“研发永久想的是做加法，我加一个新的功能，加一个新的组件。而客户永久是想的做减法，少一个网元，网络变得更加简洁，最好你把中间繁芜的事情都自己做了，给我来看便是一个大的路由器。”以是这种思维在后续设计Ruta的时候自然而生。
1.5 SDWAN的发展：Velocloud & Viptela & Versa
后来思科内部做iWAN3.0的时候（当然这个项目胎去世腹中），我就调侃着说要不干脆把Velocloud买了吧，喜好Velo的缘故原由实在很大略：便是大略，特殊是它家开局的那个视频。但是后来的很多教训让我明白还是须要Viptela，并且Viptela和思科自家路由器ISR、ASR集成是必须要经历的痛，正如前文所说，广域网集成真的须要做很多事情。
终极思科选择了Viptela，而Velo被vmware收购，加上最近前大老板去了PaloAlto收购了CloudGenix，这场SDWAN的战斗彷佛到了结局，但是伴随着这场疫情，彷佛硝烟又起？SASE呼之欲出。
2. SDWAN的刚需最小集
全体行业吧，对SDWAN的期待越来越多，觉得便是在资金方的推动下不得不加入大量的观点去竞争各种软件功能，做安全做流控的都担心自己掉队被排挤出去，纷纭加入战局，另一方面各个云厂商也开始渗透进入这个市场。大家都是盲人摸象的去说SDWAN要什么，很多都是站在自己的角度臆想。
2.1 10Mbps~100Gbps多平台软硬件领悟
管你是不是SD的，终极还是一个WAN，广域网上碰着的各种根本难题都还是要先办理的，容量便是关键。链路类型和带宽需求决定了你须要从基于ARM的小盒子到X86或者专有NP的大盒子以及云NFV的全覆盖，针对不同的硬件平台和10Mbps~100Gbps带宽的支持这是一个难题。
很多厂商自己想想，100Gbps的核心节点有没有，能不能同时汇聚数千个分支，不要总认为全体网络都是小盒子，大的PoP点是刚需。
2.2 路由协议栈
很多云厂商和新入行的安全厂商在这方面也就只能拿Quagga玩玩，OpenXXXd加上GoBGP一类的开源协议栈构建路由。起初我不以为然，反正开源的能用就好，功能也差不多，直到去年做了一个客户的广域网改造才创造，一个发展了20年的广域网里面有太多的繁芜的配置，讲真须要抽丝剥茧才能理清楚终极上到SDWAN，那个拓扑要做业务不中断的割接，也便是SDWAN和传统网络共存，有大量的路由过滤规则和OSPF、BGP参数须要配置，否则很随意马虎涌现环路，或者一个总部到分支的链路上到SDWAN后，双归属使得其它传统路由器认为这是一条骨干链路，直接上线必定导致生产事件。
我常常开玩笑说，现在很多企业想上SDWAN的第一步是整理自己的骨干网，由于险些所有XXIE教你别这么干的事情里面都存在着，各种路由乱打Tag乱配ACL，各种静态路由，重分布也不规范的。很多刚进入SDWAN的厂商估计连OSPF有几个Type的LSA都没搞明白，自然用起来就很搞笑了。
2.3 加解密
这一块实在各家都差不多，要么是Intel QAT要么是ARM，或者自己专用的芯片做，inline Crypto是刚需，但是密钥如何协商和分发，如何担保全体集群中支持大量的IPSec SA这是一个难题，很多小厂弄点StrongSwan就来搞自然有很多功能不支持。
2.4 DPI
这一块也是门槛非常高的部分，除了几家头部的做安全的企业以及思科有自己的NBAR和TALOS这类的NGFW的厂商，其它厂商大概率只能选Qosmos的引擎，例如Office 365加速这类的功能或者其它不可描述的功能须要DPI支持选择路径加速时，效果就差了。
最关键的还是性能，当加密和DPI同时打开了，很多小厂的设备只能跑到30Mbps，当然有些大厂也是这德行...
2.5 Traffic Manager
这一块也是在SDWAN履行过程中没有很好的考虑的，很多X86或者ARM平台并没有很好的QoS调度功能，或者有调度的精度也非常差。
2.6 和云的深度集成
第一，云自己做SDWAN一定不会成功，很大略客户要多云。以是Azure非常聪明的做了一个vWAN来广纳天下众家之长。
第二，客户上云一定是要将云里的VPC或者VNET和客户的VPN打通，那么如何做？配置BGP VPN利用RT import ？手工同步VPC信息？这一点上思科做了一个深度的集成，您可以直接在掌握器上获取所有云端vpc、vnet列表：
然后很随意马虎的点点点就可以将云下和云上连通了
目前和AWS以及Azure的集成我们已经做完，详细教程过段韶光写好了发，然后第三名的那朵云我们可以谈：）
2.7 如何呈现站点资源
不同的VPC或者客户的分支站点乃至是数据中央，后面接的网络做事器容器或者是终端，我们都可以抽像为资源，或者便是不同的IP地址段来表示，并且可以通过不同的属性将它们进行VPN隔离，也便是我们常说的Overlay层，而Internet区域也被称为Underlay。
那么Underlay和Overlay层是如何映射的呢？当然所有的人都会说MP-BGP协议进行TLV扩展来支持键值对（Key-Value Pair）。
直策应用MP-BGP或者BGP-EVPN的问题：
1. Underlay公网地址常常变动，BGP路由协议收敛慢
2. 常日VPC须要超过NAT，标准的BGP协议NextHop为VPC私网地址，无法穿越NAT
3. 优选路径类型无法在单独的下一跳信息中得到，常日还须要Community熟习扩展
4. 互联通信还须要NHRP一类的协议进行补充
这些都是思科在考试测验利用DMVPN技能构建IWAN办理方案时犯的缺点，而且正如前文所述新一代的SDWAN须要去中央化的分布式架构，而DMVPN或者DSVPN的办理方案有明显的中央Hub构造，极易造成单点故障或者规模无法扩展的问题。
基于Viptela的SDWAN架构采取递归路径查询的办法，它结合和BGP和LISP的各自优点，将Overlay所对应的VPC网段等资源信息映射到一个被称作为TLOC的资源定位符上，如下图所示，然后再递归查询通过解析TLOC可达性等信息来进行路径选择和策略路由。
详细的TLOC编码如下图所示，我们对每一个VPC站点进行了编码（Site-ID），同时为每一个路由器也体例了System-IP，然后根据它们接入的不同运营商和不同的链路类型，我们为传输接口（Transport Interface）染上了不同的颜色（Color），例如Azure被标记为了Private2（紫色），数据中央的电信链路标记为蓝色（Blue），而联通的线路则标记为赤色（Red）。封装形式（Encapsulation）则可以选择明文的GRE传输或者IPsec传输办法。
2.8 uCPE和SD-Branch
分支站点可能还须要集成一些算力，用于支配一些边缘打算节点，或者某些场景下，您让一个厂商同时做好SDWAN流控、安全、DPI、无线、广域网加速等多种功能也不现实，毕竟术业有专攻，或者等保哀求须要有异构的需求，还有一些企业希望在边缘简化运维，一个物理盒子办理大量的问题。
以是思科推出了Catalyst Edge 8300、8500及8000v，俨然已经不把自己定位成一个路由器了，由于它顺应云时期的变革，将其定义为云的边缘节点，也拉开了云网端领悟的序幕。个中的打算资源只有1/3被用于路由剩下的完备开放给客户利用。
2.9 BigRouter
实质上犹如我设计Ruta的时候讲的那样，如何隐蔽繁芜的广域网拓扑，让客户不用感知到您的广域网路由实现，直接把每个连业务的端口进行配置就好了。这些东西并不是说有一个WebUI或者一堆RestAPI就可以搞定的，接下来我将为大家开拓一系列的运维工具，使得大家真的能够感想熏染到犹如在操作一个大路由器。
3. SDWAN路在何方
全体行业大概的现状犹如Gartner的这张图， Leader太多：）
作为一个理智的SDWAN利用者,什么是你须要的？别被迷雾弄花眼，从自己的刚需入手，选择最好的平台，然后再补缺才是正路。
感谢阅读，欢迎扩散传播！
感谢！
边缘打算社区：促进边缘打算领域知识传播，中立，客不雅观，如果您关注边缘打算、5G、物联网、云原生等领域请关注我们。
