發布日期：2022-10-18 點擊率：94
從2016年底開始，國內討論SD-WAN的聲音一直不絕于耳，相信經過這么長的時間，大家對“SD-WAN是什么”都有了一定的了解，但是對于“SD-WAN是怎么實現的”，估計大部分同學還是沒有摸到任何的路數。寫這篇文章，就把SD-WAN這層技術的面紗給揭開，爭取幫大家從60分的“及格線”提高到85分的“準優秀線”。
全文純文字無配圖，需要一定的傳統網絡與SDN基礎，適合于Networking Geek閱讀。
文章太長，考慮到閱讀體驗，將分為上下兩個部分。此為上篇，閱讀時間在30分鐘左右。
一、引言
這兩年SD-WAN在業界可謂是眾星捧月，在一些文章的過度包裝下，非常容易讓人形成一個錯誤的觀念——SD-WAN是一種全新的方案。實際上，SD-WAN并不是石頭里蹦出來的猴子，雖然有一些吸睛的新特征，但它仍然是根植在很多傳統的傳統企業級WAN技術之上的，主要包括路由、VPN、安全、WAAS等等，在下文對于SD-WAN的技術介紹中，會反復地提到這些傳統技術，讀者最好對相關的基礎知識有所了解。至于SD，實際上SD-WAN并不能單純地被劃歸到SDN的范疇下，它集成了WhiteBox/SDN/NFV/Cloud等多種新型手段，屬于一攬子的解決方案。
硅谷從2011-2012年開始做SD-WAN，到現在也有6、7年了。最開始，SD-WAN在技術方案上是純Overlay的，網絡的連接和增值服務都在企業邊緣完成，因此完全是OTT ISP的。大概從2016年開始，SP的角色開始被引入SD-WAN方案中，思路上兩點主要的變化在于，網絡連接上要考慮對接SP的Underlay，增值服務方面要考慮對接SP的TeleCloud。對于這兩種思路，國外的一些說法分別稱為“SD-WAN 1.0”和“SD-WAN 2.0”，實際上這兩種方案并不是單純的升級關系，準確地說，“SD-WAN 1.0”是“Enterprise Oriented”，而“SD-WAN 2.0”是“SP Oriented”，后面就用“Enterprise Oriented SD-WAN”和“SP Oriented SD-WAN”來指代這兩種思路。
實際上，當SP的角色被引入SD-WAN后，SD-WAN在概念上似乎有了很多令人遐想的空間，是不是在廣域網上做SDN就都能叫做SD-WAN呢？這個問題，從技術層面來討論是很困難的，因為SD-WAN的名字確實是起得太大了。不過有一點可以確定的是，SD-WAN的出發點是對企業級的WAN進行增強，如果有哪家SP用SDN做了或改造了一個Backbone，但是這個WAN并不直接面向企業提供服務，那么嚴格來說它就不應該被納入到SD-WAN的范疇中。當然，把一個SD-WAN方案跑在一個用SDN做的Backbone上也是沒問題的，但這兩者不宜混為一談，更別談有一些Backbone其實就沒做SDN，只是靠著輕載來保證質量了。
搞清楚了SD-WAN是什么，下面就進入正題，來聊聊“Enterprise Oriented”和“SP Oriented”的SD-WAN分別都是怎么做的。上篇的主題是“Enterprise Oriented SD-WAN”，過兩天的下篇再來聊“SP Oriented SD-WAN”
二、Enterprise Oriented SD-WAN
這種思路是對傳統的IPSec方案的延伸，在企業各個站點邊緣的CPE間建立隧道（如果入云的話就在云里放一個Software CPE），無論是走Internet或MPLS或其他的WAN線路，只是傳輸質量有所區別的管道而已，企業的組網完全OTT在SP的網絡之上。從物理上來看，CPE可放在企業的總部/數據中心/分支/服務網點，也可以在IDC/公有云的機房，而從組網上來看，無論是P2P/Hub & Spoke/Full Mesh/Partial Mesh，各站點間邏輯上都是一跳可達。
那么SD-WAN給這種方案帶來了什么提升呢？主要有以下幾點：
這些優勢估計大家都聽了無數遍了，不過它們都是怎么實現的呢？下面就來對Enterprise Oriented的SD-WAN進行一下解剖，講講其中的產品設計、關鍵技術與實現。
1、產品設計
先來重點看看CPE的設計。考慮到CPE的定位，它對功能的靈活性要求較高，而對IO性能的要求一般不是很高，因此CPE大多都是基于x86進行設計的，很少見到用于交換的ASIC。軟件形態的CPE，自然也大都是基于x86來做，一些廠商的軟件和硬件CPE的架構是完全相同的。對于面向移動或者IOT場景的產品，也可能會基于ARM來做，但是目前來看尚未成氣候。
CP（控制面）、DP（轉發面）和SP（服務面）都是跑在x86上的，各個平面綁定不同的CPU。CP通常會運行在Host OS的用戶態，而DP的話目前一般都會做DPDK加速，這樣的話DP也是運行在Host OS的用戶態，根據性能的不同要求占用總核數的50%-80%或以上。SP的話用來內置VNF，形態上是VM或者Container，以便與Host OS中的CP、DP進行隔離，這要求Host OS支持虛擬化或者容器。同時由于VNF通常是CPU Intensive的，因此集成SP的CPE通常需要額外的CPU，或者提供一定數量的x86板卡插槽，另外SP可能對于存儲也會有所要求，這時可提供相應的DRAM和SSD能力。
從網卡上來看，DPDK必選支持DP高速收發，直通或者SR-IOV可選為部分VNF提供原生的IO性能。網口的數量上，WAN口1-2個，LAN口2-8個，速率上面向SMB（Small or Medium Branch）的產品10-100M即可，面向標準Branch的產品在100M-500M間，面向大型Branch/HQ/DC的產品通常定位在500M-2G間。不過考慮到IPSec，這些物理接口在真正帶業務的時候，吞吐量通常都會打上一定的折扣。接口的封裝上RJ-45必選沒說的，一些產品會添加SFP方便接光纖。在一些SMB的產品中會提供POE/POE+。除了以太口以外，CPE上還需要集成一些其它類型的接口，LAN側WiFi可選主要面向SMB，WAN側的T1/E1、xDSL、Cable和3G/4G等，可根據產品投放地區的實際情況進行選擇，3G/4G可通過USB轉接或者內置SIM和天線。
出于一些專用的考量，一些CPE的產品中還會內置一些協處理器，如用于提升IPSec性能的Crypto Accelerator，又如用于提高UCaaS能力的DSP。另外，相當一部分廠商還會在CPE中內置TPM芯片，用于CPE的身份認證。
對于控制器，不同的SD-WAN方案會有不同的設計。這里所說的控制器是廣義上的，可能會包括的有Staging Server、Controller和Analytics。Staging Server主要做認證和自動發現，和CPE間通常為私有協議，條件允許的話可以用DHCP。Controller主要做密鑰和路由分發，南向上各種形式都有，OpenFlow/BGP/Netconf都有，用私有協議的也很多。Analytics主要做數據采集和分析處理，南向上常見的有NetFlow/IPFIX/SNMP/Syslog等。北向上多以RESTful API為主。
控制器的位置，可以是On-Premise的，放在企業的數據中心甚至是在CPE上開虛擬機，也可以是base在Cloud上的，擁有一個可訪問的IP地址即可。考慮銀行和零售等SD-WAN主要的目標客戶的分支站點的規模，一套控制器的集群可能會需要帶數以千計的CPE，實際上這也是很多廠家會采用私有控制協議的原因之一，做的越定制化越輕量，性能就越容易把握，如果用BGP的話基本上就必須要分級了。
Portal的設計就是見仁見智了，個人覺得比較關鍵的有三點。一是應用WAN策略的默認模板，雖然SD-WAN的一個突出的亮點就是能夠管理基于應用的WAN處理策略，但是相當一部分的客戶只關注結果而不關注過程，這時候就需要一個默認的策略模板，把應用需要什么樣的線路質量內嵌到系統中，然后自動生效。另外一點是對Tag機制的支持，把不同的對象（比如站點、設備、應用等）打上不同的Tag，然后可以制定一份策略（路由、安全、QoS等）統一對標記為Tag的對象生效。第三點，必須要支持報表的定制與輸出，保證SD-WAN的可審計。Portal的位置，同樣可以是On-Premise的或者在Cloud里面。
上述是一個宏觀層面的介紹，下面將針對一些技術的關鍵點，介紹一下CPE和控制器上相關的實現細節。關于Portal，由于不涉及網絡本身，因此后面就不詳細說了
2、關鍵技術與實現
2.1 ZTP（零接觸部署）是怎么實現的？
這看要怎么理解ZTP了，可以理解成就是CPE的上線，也可以理解成CPE上線加上控制器把業務打通的全過程。這里按第一種理解來說，控制器的邏輯拆到后面的問題里去說。
首先，每個CPE要有唯一的標識，這個標識可以是發貨前配好的，有條件的話可以固化在硬件中，對于Software CPE的話一般在拉起的時候會生成序列號并完成注入。這個標識需要被手動錄入或以其他方式注冊到系統中，以便后續的識別。等到客戶收到CPE并加電后，CPE會通過DHCP/PPPoE來獲取IP地址，后續即利用這一IP地址進行通信。之后，CPE要去自動獲取控制器的信息，包括IP、端口和認證信息等。獲取的方式也有很多，發貨前廠家給配好是可以的，但是效率比較低。客戶自己去手動開局也是可以接受的，方式上包括掃二維碼、根據短信做配置、郵件注入、USB注入等等。如果要做成即插即用，可以加電后觸發DHCP/DNS來查Staging Server。獲取到信息后，CPE會主動去找控制器，彼此之間完成雙向認證，認證成功后就可以通信了。
2.2 Underlay是怎么打通的？
打通Underlay的路由是CPE間起隧道的基礎。CPE上線后，控制器就會配置CPE上的Underlay路由。這里之所以需要用控制器來配，而不是走由DHCP或其他方式分配的默認路由呢？因為CPE很有可能接入不同的WAN線路，單純靠某條線路上SP給的默認路由，很可能出現次優路徑甚至不通的情況，如果是多SP接入的話，uRPF的存在也可能使得連通性存在問題。另外，由于一些協議和隧道習慣上會起在loopback口上，這時loopback的地址和路由也都需要控制器去做規劃和配置。如果出于可用性的考慮，IPSec或者其他的最外層隧道也要起在邏輯口上，那么還要向SP宣告該邏輯口的路由。
打通Underlay還面臨著一個嚴峻的現實問題。由于很多Branch沒有公網IP或者固定的IP，這時在跨越Internet的時候，無論是CPE和控制器間通信，還是CPE間通信，都跑不掉要過SP的NAT/PAT。應用如何穿越NAT/PAT是老生常談了，ALG/STUN都可以，不過GRE/VxLAN原生上都穿不了NAT，IPSec通過NAT-T是可以穿的，只要有一端有固定IP。因此XXX over IPSec的好處不僅是安全，而且在穿NAT方面也有先天的優勢。數據面over IPSec基本上沒跑了，控制面穿NAT時，OpenFlow是不用的，但BGP/Netconf通常要over IPSec（有條件改底層實現也可以不over IPSec），私有協議可以自己設計機制來穿NAT，注意要設計好保活防止NAT老化。
2.3 Overlay是怎么打通的？
傳統的IPSec方案中打通Overlay的方式，LAN側主要是Static或者IGP，隧道側主要是IGPoverGRE，IGPoverVTI，或者直接手配Static，如果不起路由的話可以做RRI，有時還需要在一端做SNAT。多點VPN的話，以Cisco的DMVPN為例還需要NHRP和mGRE，其他廠家如果有多點的方案的話，基本上也都是照葫蘆畫瓢。
對于SD-WAN而言，LAN側由于要接路由器，因此CPE需要保留Static/IGP/Redistribution的能力，隧道側而言，主流上是由控制器來集中完成隧道的建立和路由的分發，這樣一來，多點和點對點在實現上其實是沒有什么差別的。交互路由的手段有很多，BGP/OpenFlow/Netconf都行，私有協議也很常見。具體用選擇哪一種，取決于廠商的技術背景，比如傳統廠商或者從傳統廠商跳出去的創業公司，習慣上會用BGP/Netconf，SDN背景強的用OpenFlow會容易上手些。用私有協議的也不在少數，其好處是可以實現的非常輕量，而且不僅僅是控制面，有的廠家連隧道的封裝，甚至CPE里的協議棧都自己定制了。其實對于Enterprise Oriented SD-WAN來說，通常不存在跨廠商互通，客戶對于開放性也不怎么關心，這時候標準化的必要性確實就比較弱了。當然，SP Oriented SD-WAN是一番考慮了。
對于隧道側的Overlay路由，也不排除一些SD-WAN方案中仍然保留了傳統的控制機制。這其實絲毫不影響其技術的含金量，邏輯上都是一跳可達，集中不集中到控制器上，只是形式不通罷了，千萬別因為刻板的觀念給XXX產品扣帽子。
2.4 組播和服務鏈是怎么實現的？
組播是可選支持的，可用于電話會議或者視頻會議，如果支持的話一般也在會歸在高檔的License中提供。CPE上跑IGMP和PIM，然后反饋到控制器上，然后控制器在向相關的CPE去分發組播的路由，考慮到IGMP和PIM無法跨Internet傳播，因此CPE和控制器間一般用私有協議來分布組播的路由。
服務鏈的話必選支持，由于涉及到策略問題，因此只能通過控制器去集中地控制服務鏈的路徑。Netconf配PBR，BGP引流，OpenFlow引流，或者私有協議發布Service Route都是可以的。通常來說，PNF或者VNF都是在CPE本地，是不需要走隧道的，但有時候一些增值服務要求部署總部，這時候就得走隧道送過去了。由于NSH目前支持的還很少，因此在串多個服務的時候，一方面可以給流量打上Service Tag，相當于起了Service Path Index的作用，另一方面通常還需要去額外地匹配inport，相當于起了Service Index的作用。
2.5 混合云是怎么實現的？
隨著IaaS的成熟與落地，混合云的模式逐漸為市場所接受，其中的一個關鍵技術環節，就是如何打通企業站點與VPC間的連接。SD-WAN生于云計算的大時代中，作為新一代的企業WAN組網方案，“Cloud Ready”也自然成為了必選支持的功能。
從Enterprise-Oriented SD-WAN的角度來看，入云并不需要什么特殊的技術，還是隧道、加密、NAT穿越這些老問題，IPSec仍然是可以搞定的。不過在Cloud這一側，除了一些超大的客戶可以在資源池的機房里放硬件的CPE，絕大部分的客戶都只能用純軟的CPE，部分廠商已經把產品做到了Cloud SP的market place里面，以SD-WAN VNF的形式直接按需提供給客戶。如果還沒上market place，客戶則可以在VPC中起一個新的VM，自己動手裝一個Software CPE進去。在實際的部署中，必須要搞清楚云中的路由結構，關鍵就是vRouter和Software CPE的位置關系，并在合適的地方去控制公網和VPN路由的分流。另外，很多大型的Cloud SP會自己提供Gateway作為不同租戶入云的統一入口，不過這個Gateway的能力比較單一，接口的權限通常也不會開放給SD-WAN的控制器，因此很難納入到SD-WAN的體系中來。
為了打通IPSec，站點側和云側至少要有一個公網可訪問的IP地址，如果是云側需要這個地址，就需要向Cloud SP申請一個Fixed IP。一端配本地的設備，一端配云側的設備，在做具體部署時要為控制器選好合適的位置。
如果有通二層的需求的話，就要VxLAN或者VxLANoverIPSec，然而實際上換了封裝二層也很難通起來。如果VPN的路由結構是vRouter—Software CPE兩跳，那隧道出來后是沒法直接接到Subnet上的。即使VPN的路由是直接走到Software CPE上，二層的流量也還是過不了安全組這一關。解決的辦法，要么Cloud SP允許修改默認的VM安全策略，要么找個地方裸放CPE，從vSwitch打VxLAN到這個裸CPE上。不過目前來看，企業做混合云主要還是為了打通三層，在站點和VPC間做二層的需求是比較少見的。
相關內容推薦：
SD-WAN是什么？
SD-WAN進階教程(續)
新興技術：SD-WAN
下一篇： PLC、DCS、FCS三大控
上一篇： 5G固定無線接入的優勢
