SDWAN：SD了什么？

最新推荐文章于 2024-07-10 11:47:09 发布

边缘计算社区

最新推荐文章于 2024-07-10 11:47:09 发布

阅读量873

点赞数

文章标签：路由器思科大数据人工智能 java

虽然国内外对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被用于路由剩下的完全开放给客户使用。