SDWAN:SD了什麼?

新年開篇，但是這個新年過得非常狼狽，當然也有一些好事，去年在忙著寫Ruta的時候還逼自己報了FRM-1，沒有花很多精力，但最終還是過了，只是有些遺憾讀了那麼多書沒有拿到全1，那麼接下來爭取FRM2拿全一吧~

說的狼狽是指跨年的時候在連續熬了幾個通宵處理一個客戶極其複雜的故障，一般弄到我這裡的活基本上要麼是甲方爸爸牛逼，要麼就是實施過程中問題不斷甲方爸爸怒了逼著要退貨了，這次例外是，有個牛逼的甲方爸爸怒了。具體內容涉及客戶信息就不多說了，有些感想可以分享一下。雖然國內外對SDWAN和企業上雲的認知都是會將其定為為剛需，各位搞SDWAN峰會的也是風光無限，但是捫心自問，誰真的賺了錢？就像我以前說過一段話：

Gartner的報告裡，一個Leader和Niche Players象限擠滿了的行業出了什麼問題？是技術對了而市場沒有成熟？如果是這樣，應該看到大量的visionaries。但偏偏不是，那就是市場對了，而技術本身錯了？

對於我而言，現在的SDWAN和十年前基於STP/VLAN的數據中心類似，在業務迅速增長的時候，試圖通過集群的方式簡化運維，當年出現了VSS、FEX或者IRF的技術， 同時也伴生了TRILL、VPC等技術實現。大二層的思想自然就這麼誕生了，最終這些東西被歷史拋棄的原因是什麼？Overlay解耦

Insieme構建的Overlay技術以及ACI整套商用方案的出現使得爭論逐漸消退，另一方面其它廠家基於BGP-EVPN+VXLAN成了數據中心的標配，當然隨著規模進一步擴大，BGP的問題顯露出來，你看人家Google都用自己的分布KV好多年了，然後轉發規則越來越多，TOR越來越複雜，很多東西在雲上的VPC實現都offload到主機了。
當然這些不是今天這文的重點，重點是回顧一下廣域網最近這十年的發展和業務需求，以史知興衰，嘗試著探索出一條新的路出來，而且我也堅信這樣的路充滿挑戰和質疑，所有的人在這個市場上嘗試了那麼多年為什麼都失敗了，一定是一個工業界上非常有挑戰性的難題，並且答案一定是要另闢蹊徑才能構建的。太早的事情咱就不多說，前溯十幾年吧。這圖留到了17年，沒有加上最近剛發布的8300、8500，因為那些還有更大的變化，下次再說吧。

思科從2600系列路由器開始在傳統路由上增加了語音的功能，然後2800系列開始添加IPsec VPN功能，所以路由器從2600時代的MultiService，就變成了ISR，即「集成業務路由器」的時代。當然還有一個在2008年附近發布的產品叫ASR1000系列的聚合業務路由器把多業務融合推向了一個新的高度，後面的ISR4400、ISR4300、ISR1000都是藉助這個架構實施的，所以您會看到IOS到IOS-XE有一個明顯的分界。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的版本極大的提高了性能。 而另一方面，在多核心多業務處理器上，思科也準備著一個大動作。

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呼之欲出。

整個行業吧，對SDWAN的期待越來越多，感覺就是在資金方的推動下不得不加入大量的概念去競爭各種軟體功能，做安全做流控的都擔心自己掉隊被排擠出去，紛紛加入戰局，另一方面各個雲廠商也開始滲透進入這個市場。大家都是盲人摸象的去說SDWAN要什麼，很多都是站在自己的角度臆想。2.1 10Mbps~100Gbps多平臺軟硬體融合管你是不是SD的，最終還是一個WAN，廣域網上遇到的各種基礎難題都還是要先解決的，容量便是關鍵。鏈路類型和帶寬需求決定了你需要從基於ARM的小盒子到X86或者專有NP的大盒子以及雲NFV的全覆蓋，針對不同的硬體平臺和10Mbps~100Gbps帶寬的支持這是一個難題。很多廠商自己想想，100Gbps的核心節點有沒有，能不能同時匯聚數千個分支，不要總認為整個網絡都是小盒子，大的PoP點是剛需。很多雲廠商和新入行的安全廠商在這方面也就只能拿Quagga玩玩，OpenXXXd加上GoBGP一類的開源協議棧構建路由。起初我不以為然，反正開源的能用就好，功能也差不多，直到去年做了一個客戶的廣域網改造才發現，一個發展了20年的廣域網裡面有太多的複雜的配置，講真需要抽絲剝繭才能理清楚最終上到SDWAN，那個拓撲要做業務不中斷的割接，也就是SDWAN和傳統網絡共存，有大量的路由過濾規則和OSPF、BGP參數需要配置，否則很容易出現環路，或者一個總部到分支的鏈路上到SDWAN後，雙歸屬使得其它傳統路由器認為這是一條骨幹鏈路，直接上線必定導致生產事故。我常常開玩笑說，現在很多企業想上SDWAN的第一步是整理自己的骨幹網，因為幾乎所有XXIE教你別這麼幹的事情裡面都存在著，各種路由亂打Tag亂配ACL，各種靜態路由，重分布也不規範的。很多剛進入SDWAN的廠商估計連OSPF有幾個Type的LSA都沒搞明白，自然用起來就很搞笑了。這一塊其實各家都差不多，要麼是Intel QAT要麼是ARM，或者自己專用的晶片做，inline Crypto是剛需，但是密鑰如何協商和分發，如何保證整個集群中支持大量的IPSec SA這是一個難題，很多小廠弄點StrongSwan就來搞自然有很多功能不支持。這一塊也是門檻非常高的部分，除了幾家頭部的做安全的企業以及思科有自己的NBAR和TALOS這類的NGFW的廠商，其它廠商大概率只能選Qosmos的引擎，例如Office 365加速這類的功能或者其它不可描述的功能需要DPI支持選擇路徑加速時，效果就差了。最關鍵的還是性能，當加密和DPI同時打開了，很多小廠的設備只能跑到30Mbps，當然有些大廠也是這德行...這一塊也是在SDWAN實施過程中沒有很好的考慮的，很多X86或者ARM平臺並沒有很好的QoS調度功能，或者有調度的精度也非常差。第一，雲自己做SDWAN一定不會成功，很簡單客戶要多雲。所以Azure非常聰明的做了一個vWAN來廣納天下眾家之長。第二，客戶上雲一定是要將雲裡的VPC或者VNET和客戶的VPN打通，那麼如何做？配置BGP VPN利用RT import ？手工同步VPC信息？這一點上思科做了一個深度的集成，您可以直接在控制器上獲取所有雲端vpc、vnet列表：

目前和AWS以及Azure的集成我們已經做完，具體教程過段時間寫好了發，然後第三名的那朵雲我們可以談：）
不同的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傳輸方式。

分支站點可能還需要集成一些算力，用於部署一些邊緣計算節點，或者某些場景下，您讓一個廠商同時做好SDWAN流控、安全、DPI、無線、廣域網加速等多種功能也不現實，畢竟術業有專攻，或者等保要求需要有異構的需求，還有一些企業希望在邊緣簡化運維，一個物理盒子解決大量的問題。所以思科推出了Catalyst Edge 8300、8500及8000v，儼然已經不把自己定位成一個路由器了，因為它順應雲時代的變化，將其定義為雲的邊緣節點，也拉開了雲網端融合的序幕。其中的計算資源只有1/3被用於路由剩下的完全開放給客戶使用。

本質上如同我設計Ruta的時候講的那樣，如何隱藏複雜的廣域網拓撲，讓客戶不用感知到您的廣域網路由實現，直接把每個連業務的埠進行配置就好了。這些東西並不是說有一個WebUI或者一堆RestAPI就可以搞定的，接下來我將為大家開發一系列的運維工具，使得大家真的能夠感受到如同在操作一個大路由器。整個行業大概的現狀如同Gartner的這張圖， Leader太多：）

作為一個理智的SDWAN使用者,什麼是你需要的？別被迷霧弄花眼，從自己的剛需入手，選擇最好的平臺，然後再補缺才是正路。