简单的加法构成了思科的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被用于路由剩下的完全开放给客户使用。
