從2016年底開始，國(guó)內(nèi)討論SD-WAN的聲音一直不絕于耳，相信經(jīng)過這么長(zhǎng)的時(shí)間，大家對(duì)“SD-WAN是什么”都有了一定的了解，但是對(duì)于“SD-WAN是怎么實(shí)現(xiàn)的”，估計(jì)大部分同學(xué)還是沒有摸到任何的路數(shù)。寫這篇文章，就把SD-WAN這層技術(shù)的面紗給揭開，爭(zhēng)取幫大家從60分的“及格線”提高到85分的“準(zhǔn)優(yōu)秀線”。

全文純文字無配圖，需要一定的傳統(tǒng)網(wǎng)絡(luò)與SDN基礎(chǔ)，適合于Networking Geek閱讀。

文章太長(zhǎng)，考慮到閱讀體驗(yàn)，將分為上下兩個(gè)部分。此為上篇，閱讀時(shí)間在30分鐘左右。

一、引言

這兩年SD-WAN在業(yè)界可謂是眾星捧月，在一些文章的過度包裝下，非常容易讓人形成一個(gè)錯(cuò)誤的觀念——SD-WAN是一種全新的方案。實(shí)際上，SD-WAN并不是石頭里蹦出來的猴子，雖然有一些吸睛的新特征，但它仍然是根植在很多傳統(tǒng)的傳統(tǒng)企業(yè)級(jí)WAN技術(shù)之上的，主要包括路由、VPN、安全、WAAS等等，在下文對(duì)于SD-WAN的技術(shù)介紹中，會(huì)反復(fù)地提到這些傳統(tǒng)技術(shù)，讀者最好對(duì)相關(guān)的基礎(chǔ)知識(shí)有所了解。至于SD，實(shí)際上SD-WAN并不能單純地被劃歸到SDN的范疇下，它集成了WhiteBox/SDN/NFV/Cloud等多種新型手段，屬于一攬子的解決方案。

硅谷從2011-2012年開始做SD-WAN，到現(xiàn)在也有6、7年了。最開始，SD-WAN在技術(shù)方案上是純Overlay的，網(wǎng)絡(luò)的連接和增值服務(wù)都在企業(yè)邊緣完成，因此完全是OTT ISP的。大概從2016年開始，SP的角色開始被引入SD-WAN方案中，思路上兩點(diǎn)主要的變化在于，網(wǎng)絡(luò)連接上要考慮對(duì)接SP的Underlay，增值服務(wù)方面要考慮對(duì)接SP的TeleCloud。對(duì)于這兩種思路，國(guó)外的一些說法分別稱為“SD-WAN 1.0”和“SD-WAN 2.0”，實(shí)際上這兩種方案并不是單純的升級(jí)關(guān)系，準(zhǔn)確地說，“SD-WAN 1.0”是“Enterprise Oriented”，而“SD-WAN 2.0”是“SP Oriented”，后面就用“Enterprise Oriented SD-WAN”和“SP Oriented SD-WAN”來指代這兩種思路。

實(shí)際上，當(dāng)SP的角色被引入SD-WAN后，SD-WAN在概念上似乎有了很多令人遐想的空間，是不是在廣域網(wǎng)上做SDN就都能叫做SD-WAN呢？這個(gè)問題，從技術(shù)層面來討論是很困難的，因?yàn)镾D-WAN的名字確實(shí)是起得太大了。不過有一點(diǎn)可以確定的是，SD-WAN的出發(fā)點(diǎn)是對(duì)企業(yè)級(jí)的WAN進(jìn)行增強(qiáng)，如果有哪家SP用SDN做了或改造了一個(gè)Backbone，但是這個(gè)WAN并不直接面向企業(yè)提供服務(wù)，那么嚴(yán)格來說它就不應(yīng)該被納入到SD-WAN的范疇中。當(dāng)然，把一個(gè)SD-WAN方案跑在一個(gè)用SDN做的Backbone上也是沒問題的，但這兩者不宜混為一談，更別談?dòng)幸恍〣ackbone其實(shí)就沒做SDN，只是靠著輕載來保證質(zhì)量了。

搞清楚了SD-WAN是什么，下面就進(jìn)入正題，來聊聊“Enterprise Oriented”和“SP Oriented”的SD-WAN分別都是怎么做的。上篇的主題是“Enterprise Oriented SD-WAN”，過兩天的下篇再來聊“SP Oriented SD-WAN”

二、Enterprise Oriented SD-WAN

這種思路是對(duì)傳統(tǒng)的IPSec方案的延伸，在企業(yè)各個(gè)站點(diǎn)邊緣的CPE間建立隧道（如果入云的話就在云里放一個(gè)Software CPE），無論是走Internet或MPLS或其他的WAN線路，只是傳輸質(zhì)量有所區(qū)別的管道而已，企業(yè)的組網(wǎng)完全OTT在SP的網(wǎng)絡(luò)之上。從物理上來看，CPE可放在企業(yè)的總部/數(shù)據(jù)中心/分支/服務(wù)網(wǎng)點(diǎn)，也可以在IDC/公有云的機(jī)房，而從組網(wǎng)上來看，無論是P2P/Hub & Spoke/Full Mesh/Partial Mesh，各站點(diǎn)間邏輯上都是一跳可達(dá)。

那么SD-WAN給這種方案帶來了什么提升呢？主要有以下幾點(diǎn)：

• 在CPE里集成了應(yīng)用識(shí)別，WAN線路監(jiān)測(cè)，以及WAN線路協(xié)同的能力，為不同的應(yīng)用提供不同的WAN處理策略，提高了WAN線路的ROI。
• CPE將VPN、安全和WAAS的能力進(jìn)行了集成，同時(shí)CPE還允許以VM等形式提供其他增值服務(wù)，并通過SFC進(jìn)行串接，用戶可按需進(jìn)行訂購。
• 增加了一個(gè)控制器的角色，能夠自動(dòng)發(fā)現(xiàn)CPE，并向其地推送密鑰和路由，省去了IP、IPSec、Tunnel、IGP、NHRP等的手工配置。
• 有一個(gè)集中式的Portal，對(duì)上述功能以及其他功能的策略，進(jìn)行統(tǒng)一的管理與配置。

這些優(yōu)勢(shì)估計(jì)大家都聽了無數(shù)遍了，不過它們都是怎么實(shí)現(xiàn)的呢？下面就來對(duì)Enterprise Oriented的SD-WAN進(jìn)行一下解剖，講講其中的產(chǎn)品設(shè)計(jì)、關(guān)鍵技術(shù)與實(shí)現(xiàn)。

1、產(chǎn)品設(shè)計(jì)

先來重點(diǎn)看看CPE的設(shè)計(jì)。考慮到CPE的定位，它對(duì)功能的靈活性要求較高，而對(duì)IO性能的要求一般不是很高，因此CPE大多都是基于x86進(jìn)行設(shè)計(jì)的，很少見到用于交換的ASIC。軟件形態(tài)的CPE，自然也大都是基于x86來做，一些廠商的軟件和硬件CPE的架構(gòu)是完全相同的。對(duì)于面向移動(dòng)或者IOT場(chǎng)景的產(chǎn)品，也可能會(huì)基于ARM來做，但是目前來看尚未成氣候。

CP（控制面）、DP（轉(zhuǎn)發(fā)面）和SP（服務(wù)面）都是跑在x86上的，各個(gè)平面綁定不同的CPU。CP通常會(huì)運(yùn)行在Host OS的用戶態(tài)，而DP的話目前一般都會(huì)做DPDK加速，這樣的話DP也是運(yùn)行在Host OS的用戶態(tài)，根據(jù)性能的不同要求占用總核數(shù)的50%-80%或以上。SP的話用來內(nèi)置VNF，形態(tài)上是VM或者Container，以便與Host OS中的CP、DP進(jìn)行隔離，這要求Host OS支持虛擬化或者容器。同時(shí)由于VNF通常是CPU Intensive的，因此集成SP的CPE通常需要額外的CPU，或者提供一定數(shù)量的x86板卡插槽，另外SP可能對(duì)于存儲(chǔ)也會(huì)有所要求，這時(shí)可提供相應(yīng)的DRAM和SSD能力。

從網(wǎng)卡上來看，DPDK必選支持DP高速收發(fā)，直通或者SR-IOV可選為部分VNF提供原生的IO性能。網(wǎng)口的數(shù)量上，WAN口1-2個(gè)，LAN口2-8個(gè)，速率上面向SMB（Small or Medium Branch）的產(chǎn)品10-100M即可，面向標(biāo)準(zhǔn)Branch的產(chǎn)品在100M-500M間，面向大型Branch/HQ/DC的產(chǎn)品通常定位在500M-2G間。不過考慮到IPSec，這些物理接口在真正帶業(yè)務(wù)的時(shí)候，吞吐量通常都會(huì)打上一定的折扣。接口的封裝上RJ-45必選沒說的，一些產(chǎn)品會(huì)添加SFP方便接光纖。在一些SMB的產(chǎn)品中會(huì)提供POE/POE+。除了以太口以外，CPE上還需要集成一些其它類型的接口，LAN側(cè)WiFi可選主要面向SMB，WAN側(cè)的T1/E1、xDSL、Cable和3G/4G等，可根據(jù)產(chǎn)品投放地區(qū)的實(shí)際情況進(jìn)行選擇，3G/4G可通過USB轉(zhuǎn)接或者內(nèi)置SIM和天線。

出于一些專用的考量，一些CPE的產(chǎn)品中還會(huì)內(nèi)置一些協(xié)處理器，如用于提升IPSec性能的Crypto Accelerator，又如用于提高UCaaS能力的DSP。另外，相當(dāng)一部分廠商還會(huì)在CPE中內(nèi)置TPM芯片，用于CPE的身份認(rèn)證。

對(duì)于控制器，不同的SD-WAN方案會(huì)有不同的設(shè)計(jì)。這里所說的控制器是廣義上的，可能會(huì)包括的有Staging Server、Controller和Analytics。Staging Server主要做認(rèn)證和自動(dòng)發(fā)現(xiàn)，和CPE間通常為私有協(xié)議，條件允許的話可以用DHCP。Controller主要做密鑰和路由分發(fā)，南向上各種形式都有，OpenFlow/BGP/Netconf都有，用私有協(xié)議的也很多。Analytics主要做數(shù)據(jù)采集和分析處理，南向上常見的有NetFlow/IPFIX/SNMP/Syslog等。北向上多以RESTful API為主。

控制器的位置，可以是On-Premise的，放在企業(yè)的數(shù)據(jù)中心甚至是在CPE上開虛擬機(jī)，也可以是base在Cloud上的，擁有一個(gè)可訪問的IP地址即可。考慮銀行和零售等SD-WAN主要的目標(biāo)客戶的分支站點(diǎn)的規(guī)模，一套控制器的集群可能會(huì)需要帶數(shù)以千計(jì)的CPE，實(shí)際上這也是很多廠家會(huì)采用私有控制協(xié)議的原因之一，做的越定制化越輕量，性能就越容易把握，如果用BGP的話基本上就必須要分級(jí)了。

Portal的設(shè)計(jì)就是見仁見智了，個(gè)人覺得比較關(guān)鍵的有三點(diǎn)。一是應(yīng)用WAN策略的默認(rèn)模板，雖然SD-WAN的一個(gè)突出的亮點(diǎn)就是能夠管理基于應(yīng)用的WAN處理策略，但是相當(dāng)一部分的客戶只關(guān)注結(jié)果而不關(guān)注過程，這時(shí)候就需要一個(gè)默認(rèn)的策略模板，把應(yīng)用需要什么樣的線路質(zhì)量?jī)?nèi)嵌到系統(tǒng)中，然后自動(dòng)生效。另外一點(diǎn)是對(duì)Tag機(jī)制的支持，把不同的對(duì)象（比如站點(diǎn)、設(shè)備、應(yīng)用等）打上不同的Tag，然后可以制定一份策略（路由、安全、QoS等）統(tǒng)一對(duì)標(biāo)記為Tag的對(duì)象生效。第三點(diǎn)，必須要支持報(bào)表的定制與輸出，保證SD-WAN的可審計(jì)。Portal的位置，同樣可以是On-Premise的或者在Cloud里面。

上述是一個(gè)宏觀層面的介紹，下面將針對(duì)一些技術(shù)的關(guān)鍵點(diǎn)，介紹一下CPE和控制器上相關(guān)的實(shí)現(xiàn)細(xì)節(jié)。關(guān)于Portal，由于不涉及網(wǎng)絡(luò)本身，因此后面就不詳細(xì)說了

2、關(guān)鍵技術(shù)與實(shí)現(xiàn)

2.1 ZTP（零接觸部署）是怎么實(shí)現(xiàn)的？
這看要怎么理解ZTP了，可以理解成就是CPE的上線，也可以理解成CPE上線加上控制器把業(yè)務(wù)打通的全過程。這里按第一種理解來說，控制器的邏輯拆到后面的問題里去說。

首先，每個(gè)CPE要有唯一的標(biāo)識(shí)，這個(gè)標(biāo)識(shí)可以是發(fā)貨前配好的，有條件的話可以固化在硬件中，對(duì)于Software CPE的話一般在拉起的時(shí)候會(huì)生成序列號(hào)并完成注入。這個(gè)標(biāo)識(shí)需要被手動(dòng)錄入或以其他方式注冊(cè)到系統(tǒng)中，以便后續(xù)的識(shí)別。等到客戶收到CPE并加電后，CPE會(huì)通過DHCP/PPPoE來獲取IP地址，后續(xù)即利用這一IP地址進(jìn)行通信。之后，CPE要去自動(dòng)獲取控制器的信息，包括IP、端口和認(rèn)證信息等。獲取的方式也有很多，發(fā)貨前廠家給配好是可以的，但是效率比較低。客戶自己去手動(dòng)開局也是可以接受的，方式上包括掃二維碼、根據(jù)短信做配置、郵件注入、USB注入等等。如果要做成即插即用，可以加電后觸發(fā)DHCP/DNS來查Staging Server。獲取到信息后，CPE會(huì)主動(dòng)去找控制器，彼此之間完成雙向認(rèn)證，認(rèn)證成功后就可以通信了。

2.2 Underlay是怎么打通的？

打通Underlay的路由是CPE間起隧道的基礎(chǔ)。CPE上線后，控制器就會(huì)配置CPE上的Underlay路由。這里之所以需要用控制器來配，而不是走由DHCP或其他方式分配的默認(rèn)路由呢？因?yàn)镃PE很有可能接入不同的WAN線路，單純靠某條線路上SP給的默認(rèn)路由，很可能出現(xiàn)次優(yōu)路徑甚至不通的情況，如果是多SP接入的話，uRPF的存在也可能使得連通性存在問題。另外，由于一些協(xié)議和隧道習(xí)慣上會(huì)起在loopback口上，這時(shí)loopback的地址和路由也都需要控制器去做規(guī)劃和配置。如果出于可用性的考慮，IPSec或者其他的最外層隧道也要起在邏輯口上，那么還要向SP宣告該邏輯口的路由。

打通Underlay還面臨著一個(gè)嚴(yán)峻的現(xiàn)實(shí)問題。由于很多Branch沒有公網(wǎng)IP或者固定的IP，這時(shí)在跨越Internet的時(shí)候，無論是CPE和控制器間通信，還是CPE間通信，都跑不掉要過SP的NAT/PAT。應(yīng)用如何穿越NAT/PAT是老生常談了，ALG/STUN都可以，不過GRE/VxLAN原生上都穿不了NAT，IPSec通過NAT-T是可以穿的，只要有一端有固定IP。因此XXX over IPSec的好處不僅是安全，而且在穿NAT方面也有先天的優(yōu)勢(shì)。數(shù)據(jù)面over IPSec基本上沒跑了，控制面穿NAT時(shí)，OpenFlow是不用的，但BGP/Netconf通常要over IPSec（有條件改底層實(shí)現(xiàn)也可以不over IPSec），私有協(xié)議可以自己設(shè)計(jì)機(jī)制來穿NAT，注意要設(shè)計(jì)好保活防止NAT老化。

2.3 Overlay是怎么打通的？

傳統(tǒng)的IPSec方案中打通Overlay的方式，LAN側(cè)主要是Static或者IGP，隧道側(cè)主要是IGPoverGRE，IGPoverVTI，或者直接手配Static，如果不起路由的話可以做RRI，有時(shí)還需要在一端做SNAT。多點(diǎn)VPN的話，以Cisco的DMVPN為例還需要NHRP和mGRE，其他廠家如果有多點(diǎn)的方案的話，基本上也都是照葫蘆畫瓢。

對(duì)于SD-WAN而言，LAN側(cè)由于要接路由器，因此CPE需要保留Static/IGP/Redistribution的能力，隧道側(cè)而言，主流上是由控制器來集中完成隧道的建立和路由的分發(fā)，這樣一來，多點(diǎn)和點(diǎn)對(duì)點(diǎn)在實(shí)現(xiàn)上其實(shí)是沒有什么差別的。交互路由的手段有很多，BGP/OpenFlow/Netconf都行，私有協(xié)議也很常見。具體用選擇哪一種，取決于廠商的技術(shù)背景，比如傳統(tǒng)廠商或者從傳統(tǒng)廠商跳出去的創(chuàng)業(yè)公司，習(xí)慣上會(huì)用BGP/Netconf，SDN背景強(qiáng)的用OpenFlow會(huì)容易上手些。用私有協(xié)議的也不在少數(shù)，其好處是可以實(shí)現(xiàn)的非常輕量，而且不僅僅是控制面，有的廠家連隧道的封裝，甚至CPE里的協(xié)議棧都自己定制了。其實(shí)對(duì)于Enterprise Oriented SD-WAN來說，通常不存在跨廠商互通，客戶對(duì)于開放性也不怎么關(guān)心，這時(shí)候標(biāo)準(zhǔn)化的必要性確實(shí)就比較弱了。當(dāng)然，SP Oriented SD-WAN是一番考慮了。

對(duì)于隧道側(cè)的Overlay路由，也不排除一些SD-WAN方案中仍然保留了傳統(tǒng)的控制機(jī)制。這其實(shí)絲毫不影響其技術(shù)的含金量，邏輯上都是一跳可達(dá)，集中不集中到控制器上，只是形式不通罷了，千萬別因?yàn)榭贪宓挠^念給XXX產(chǎn)品扣帽子。

2.4 組播和服務(wù)鏈?zhǔn)窃趺磳?shí)現(xiàn)的？

組播是可選支持的，可用于電話會(huì)議或者視頻會(huì)議，如果支持的話一般也在會(huì)歸在高檔的License中提供。CPE上跑IGMP和PIM，然后反饋到控制器上，然后控制器在向相關(guān)的CPE去分發(fā)組播的路由，考慮到IGMP和PIM無法跨Internet傳播，因此CPE和控制器間一般用私有協(xié)議來分布組播的路由。

服務(wù)鏈的話必選支持，由于涉及到策略問題，因此只能通過控制器去集中地控制服務(wù)鏈的路徑。Netconf配PBR，BGP引流，OpenFlow引流，或者私有協(xié)議發(fā)布Service Route都是可以的。通常來說，PNF或者VNF都是在CPE本地，是不需要走隧道的，但有時(shí)候一些增值服務(wù)要求部署總部，這時(shí)候就得走隧道送過去了。由于NSH目前支持的還很少，因此在串多個(gè)服務(wù)的時(shí)候，一方面可以給流量打上Service Tag，相當(dāng)于起了Service Path Index的作用，另一方面通常還需要去額外地匹配inport，相當(dāng)于起了Service Index的作用。

2.5 混合云是怎么實(shí)現(xiàn)的？

隨著IaaS的成熟與落地，混合云的模式逐漸為市場(chǎng)所接受，其中的一個(gè)關(guān)鍵技術(shù)環(huán)節(jié)，就是如何打通企業(yè)站點(diǎn)與VPC間的連接。SD-WAN生于云計(jì)算的大時(shí)代中，作為新一代的企業(yè)WAN組網(wǎng)方案，“Cloud Ready”也自然成為了必選支持的功能。

從Enterprise-Oriented SD-WAN的角度來看，入云并不需要什么特殊的技術(shù)，還是隧道、加密、NAT穿越這些老問題，IPSec仍然是可以搞定的。不過在Cloud這一側(cè)，除了一些超大的客戶可以在資源池的機(jī)房里放硬件的CPE，絕大部分的客戶都只能用純軟的CPE，部分廠商已經(jīng)把產(chǎn)品做到了Cloud SP的market place里面，以SD-WAN VNF的形式直接按需提供給客戶。如果還沒上market place，客戶則可以在VPC中起一個(gè)新的VM，自己動(dòng)手裝一個(gè)Software CPE進(jìn)去。在實(shí)際的部署中，必須要搞清楚云中的路由結(jié)構(gòu)，關(guān)鍵就是vRouter和Software CPE的位置關(guān)系，并在合適的地方去控制公網(wǎng)和VPN路由的分流。另外，很多大型的Cloud SP會(huì)自己提供Gateway作為不同租戶入云的統(tǒng)一入口，不過這個(gè)Gateway的能力比較單一，接口的權(quán)限通常也不會(huì)開放給SD-WAN的控制器，因此很難納入到SD-WAN的體系中來。

為了打通IPSec，站點(diǎn)側(cè)和云側(cè)至少要有一個(gè)公網(wǎng)可訪問的IP地址，如果是云側(cè)需要這個(gè)地址，就需要向Cloud SP申請(qǐng)一個(gè)Fixed IP。一端配本地的設(shè)備，一端配云側(cè)的設(shè)備，在做具體部署時(shí)要為控制器選好合適的位置。

如果有通二層的需求的話，就要VxLAN或者VxLANoverIPSec，然而實(shí)際上換了封裝二層也很難通起來。如果VPN的路由結(jié)構(gòu)是vRouter—Software CPE兩跳，那隧道出來后是沒法直接接到Subnet上的。即使VPN的路由是直接走到Software CPE上，二層的流量也還是過不了安全組這一關(guān)。解決的辦法，要么Cloud SP允許修改默認(rèn)的VM安全策略，要么找個(gè)地方裸放CPE，從vSwitch打VxLAN到這個(gè)裸CPE上。不過目前來看，企業(yè)做混合云主要還是為了打通三層，在站點(diǎn)和VPC間做二層的需求是比較少見的。

相關(guān)內(nèi)容推薦：

SD-WAN是什么？

SD-WAN進(jìn)階教程(續(xù))

新興技術(shù)：SD-WAN