“软件定义”的网络世界

很多人在说我到底是干啥的，以后我就自我分裂成两个吧，一个叫zartbot.Net：主业搞网络的，另一个叫zartbot.Fin，兼职没事玩玩量化的，估计没过多久还会分裂成一个zartbot.Cook，zartbot.AI…当然，
下文是zartbot.
Net发的
…

记得有一个教授说过：软件定义的世界（SDx）就像盲人摸象，谁都有自己见解却无法一窥全貌。而这一段软件定义的历史已经走过了一大半历程，就差一本史记一样的来回顾来复盘了。

作为国内最早一批上互联网的网虫，亲身经历从28.8k modem拨号的年代，创办过网页当过站长理所当然的倒在了第一次互联网泡沫中，后来读大学勤工俭学当网管，做梦也没想到日后的十多年会在某个大厂负责企业网路由器，并且服务和设计了国内那么多关键的行业客户的网络，从各大银行到券商到几大交易所，也有民航空管/铁道部/电力/石油等重要行业，当然也必须包括很多著名的运营商。

恰逢最近一段时间正在帮助某券商将网络升级成SDWAN，那么就从广域网的历史展开这段故事吧,中间再结合历史给大家讲讲数据中心和园区网的软件定义，最后来给大家讲讲SDWAN的全貌以及你真正需要的功能。

1. 传统广域网的历史

1.1 1994~2000：不同介质的互联互通

我国的互联网发展大概也是在90年代中后期，那么故事也就从这张图开始讲起吧

这也是很多刚学网络的人学习CCNA的时候常见的串口通信，帧中继/PPP转以太网一类的东西。那个年代常干的事情也非常简单，就是申请开通DDN专线，然后配IP地址和路由协议，连通了就收工验收。

而家庭用户则通常是在PSTN或者ISDN modem的年代，或许小朋友们已经不知道什么叫Hayes或者US.Robotics，最近公司还找到一个成色非常新的Modem，就收藏起来了。

而那个年代的一个代表性的读物就是电子工业出版社翻译的一些Cisco Press的书，那些把交换机（Switch）翻译成开关的笑话是那个年代的图书的最大的特征，技术上更多的是教会大家路由协议的分类和计算原理，恰逢最近看到一个微博提到了一位老友的藏书，让大家一窥当时的风景。

1.2 不得不提的ATM年代：很多SDWAN的技术都源于这个时代

ATM在国内的部署规模也是非常大的，时间跨度从90年代中期到10年代中期逐渐退役，很多国有的大型银行，民航空管都广泛的将其作为骨干网的技术。当然还有一些早期的家庭上网用户和早期的网吧使用的ADSL技术。
为什么这是一个不得不提的技术呢，从技术上讲，它的设计太过理想化，它所设计的信元传递模式很好的解决了延迟和抖动，而面向连接的控制面 PVC/SVC某种意义上被现在的SDN流表复现，后期SDN出现的OpenFlow也有SVC的影子，不同的AAL层为后期的SDWAN业务区分逻辑也提供了参考， 例如AAL1实现了FEC，AAL2面向连接和实时数据流，AAL5承载了大量的IP协议传输，时至今日，很多人已经忘却了ATM的失败，继续拿着FEC这些东西来炒冷饭了。同时当年的PNNI智能选路，Anycast，FRR都成了后来很多年大家炒冷饭的技术。

1.3 2000~2010 MPLS

似乎我也曾经读过很多很多思科出版社的书，都是从这个年代开始的，也在这个年代结束的时候结束了一本笔记，然后把书分给了同事。

这个年代最为重要的技术就是MPLS了，一方面是广域网链路类型如同万国博览会，另一方面则是伴随着光传输技术的进步和10G以太网逐渐成熟并且可以低成本的替代原有的传输介质。于是基于以太的广域网技术逐渐进入市场，而网络介质逐渐由局域网和广域网异构向统一的以太网介质转化的过程。这个过程中不可避免的出现了ATM帧中继和以太网的互联互通的需求，同时VOIP的发展也使得传统的面向电路的语音交换网络向基于IP的数字语音网络转变。MPLS也便是在那个特殊的年代产生的技术， 通过一个统一的标签完成了ATM 或者帧中继和以太网的互联互通，随着标签和标签栈的扩展又实现了众多业务模式，例如MPLS VPN/ATOM/EoMPLS/VPLS等技术，后期还出现了基于MPLS的流量工程（TE）和快速重路由（FRR）等业务模式

当然广域网发展到这个年代也有客户逐渐采用3层交换机替代广域网路由器或者防火墙直接接广域网的情况。毕竟广域网介质也变成了以太网了嘛：）

2. 跨入软件定义时代

2.1 2010~2013 早期SDN

SDN的概念不得不提起Nick Mckeown，而大多数人并不知道这个概念的演进过程。最早Mckeown在1995年的论文《Fast Swtiched Backplane for a Gigabit Switched Router》设计了基于crossbar的交换矩阵，也就是Cisco GSR12000系列路由器的原型，后期Mckeown教授又提出了《Optics inside routers》即使用LB-BvN架构和MEMS构建一个分布式架构，大量的线卡和一个全光交换机的矩阵互联，但是当年商业化的产品由于MEMS不成熟，切换时间过长等限制，逐渐出现了基于Benes或者CLOS架构的多机框分布式集群，也就是思科的CRS-1和Juniper的TX-Matrix。但是在Cisco这些平台上也出现了一种叫PAL平台抽像层的结构和所谓的forwarding manager的软件架构， 这些便是SDN的雏形，软件上通过PAL层将分布式的线卡和控制面建立连接。OpenFlow也便是基于这种考量诞生的。例如当年IOS XR对外宣布的软件架构，大家可以看到有一个清晰的统一的Forwarding层的存在。

但是OpenFlow和其控制器OpenDayLight并不是SDN的全部，这段时间伴随着数据中心虚拟化，短暂的出现了OTV/Trill等技术，但随着VXLAN技术逐渐登场，这些都逐渐的淡出了人们的视线。

2.2 2013~2016 Network Overlay 

随着思科推出Nexus9000交换机和大量的基于VXLAN的白牌交换机的诞生，网络正式进入了Overlay的时代，而伴随着EPG等概念的引入，微分段（Microsegmentation）策略也逐渐被广为人知，下图是那个年代人人都要讲的PPT

Overlay资源标记/定位/路由和控制便成为各个厂商争论的焦点，伴随着数据中心厂商发布完全VXLAN+BGP-EVPN解决方案，企业网交换机和无线（WLAN）厂商通过收购整合发布基于园区网的虚拟化方案，SDN在园区和数据中心的争议和竞争便告一段落了。

这个时候也伴随着虚拟化和公有云云计算的加速发展以及3G/4G的蓬勃发展，广域网成了各个厂家的必争之地，大量的厂商开始进入SDWAN的竞争，安全厂商把防火墙加VPN加集中网管称为SDWAN，流控和应用交付厂商把流控设备和广域网加速产品加VPN加集中控制器成为SDWAN，传统的路由器厂商把MPLS扩展加上流量工程也叫SDWAN，互联网和云计算厂商随便找华强北生产点OpenWRT的盒子能够连上云也叫SDWAN。如此纷争的年代，或许我们应该单独的拿出一章来娓娓道来。

2.3 2016~Now，Host Overlay & SmartNIC & P4

随着云计算的快速发展，容器和ServiceMesh等技术的出现，伴随着DPDK和VPP等技术的出现，大量的基于软件转发的NFV平台构建起了所谓的Host Overlay网络。HostOverlay的出现极大的丰富了网络的应用，而“软件定义”这词也逐渐渗透到了存储构成了超融合等技术。

任何技术的快速发展都会面临新的挑战，瓶颈来自于两个方面，一方面是Host Overlay过度的使用CPU和内存资源，对于大量成本敏感的云计算厂商而言需要使用某种新的技术来降低成本。另一方面是伴随着AI和软件定义存储的技术，同时存储也伴随着NVMe SSD的发展I/O响应越来越快，最后网络成本了整个链条上最慢的一环，部分激进的厂商开始抛弃以太网转而使用IB，另一部分厂商则开始了主机上ROCE的部署。 这一段时间，伴随着AWS收购Annapurna和微软Azure开始采用FPGA网卡，正式进入了一个Host Overlay的时代， 原有虚拟交换机的路由/ACL过滤/计费/VTEP/LB等功能逐渐从CPU转移到网卡上。

而商业化的实现呢也伴随着P4lang的出现实现了较为统一的dataplane描述语言，基于P4的Barefoot交换芯片和Pensando的智能网卡，加上Intel和Xilinx对P4-FPGA的支持， 智能网卡逐渐从云计算提供商开始进入商业市场。

3. SDWAN技术解析

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的<TCP/IP Routing Vol.2>写的太差，使得大多数人对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架构。特别是一些大型运营商和大型银行的骨干网，具体要了解就看看PE苏翻译的几本书吧

4. 未来网络4.1 不得不提的New IP

就是这篇文章，引起了很多争论，甚至是非议。导致各大机构发文也是够厉害的了。本质上作者想创新并意识到了现有IP网络的一些问题，都没有错误，而错误恰恰就在行文上。这篇文放在国内期刊上，一点问题都没有，不就是可变长度寻址，可信的ID分配，确定性的IP转发么。那么换言之，可变长度寻址和IPv9也有异曲同工之妙，很多时候，工程上解决问题绝不是简单的推倒重来弄个新的。如何在原有的架构上一步步的去解决，去深思熟虑的看相关的IETF WG在做什么，比忙着推到一切弄个新的东西好很多。

4.2 Host Overlay的延续
其实我最近一直在思考一个问题，当我们用Overlay做了那么多加法，其实本质上是在为了更好的区分流量，识别源和目的身份和身分组，获得更好的区分服务和一致性的策略，为遥测功能提供更加精准的数据支持。或许有一个极端的场景来了，整个数据包在网络上各层有Overlay的封装，是否真的有那么一天，我们走个极端，把Host Overlay推到网络的两个端点，我们的手机或者笔记本的网卡芯片打一次标签，服务器的SmartNIC解开封装就好，这不就是我们常常追求的Intelligence Edge & Dummy Core么？

另一个问题是TCP和UDP面临一系列问题，是否有一种低延迟的可靠通信的协议，又能使用SmartNIC轻松完成异构和offload，应用层只需要改一点点socket的代码？或许就是QUIC吧，而广域网优化或许Multihoming QUIC也是一个可以解决问题的方案。

微软全面推进 QUIC 协议替代 TCP/IP，或将重塑未来的互联网？

写了这么多，想起一句台词：“1997年过去了，我很怀念它”