和ODL會員對比一下，非常鮮明。

總體來看，SDN這塊新大陸暗流涌動，各路勢力代表著自己的利益互相角逐，也因此更需要關注為什麼需要SDN，想清楚SDN是否符合我們的利益，畢竟目前廠商出來推銷的SDN解決方案一定是符合廠商的利益的，而不一定是使用者的。

POD 2.關於SDN的幾個特性

下面隨便聊聊關於幾個SDN常說的特性和名詞

」轉控分離」

這點可以說是SDN提到最多的字眼了。

其實網路設備的控制層面和轉發層面本身就是分離的，SDN里的專控分離所帶來的變化其實的是控制層面的自治轉變到集權控制。

也就是說，轉控分離這點更多要研究的是網路控制層面上是要做自治，還是集權。

傳統網路考慮的思路是網路這麼大，覆蓋範圍這麼廣，網路的管理得是自治的，你管你的網，我管我的網。因此控制相對獨立，大家如何統一步伐靠的是協議，大家遵守一樣的規範那就沒有問題了，事實上幾十年來也做的非常好。

而SDN化後就要做集權控制了，一個網路中天下歸一。

然後為什麼SDN要集權呢？主要矛盾還是每個網路設備的配置都是獨立的，運行都是自治的，這就帶來了在於業務比較複雜的網路環境中新增或調整一些業務經常要挨個設備去調，這在一些有快速業務變更的場景里來說或者說想實現快速實時的業務變更簡直是一個災難。

而且對於比較小的網路（包括Google B4，從節點上來說還是蠻小的），而且責權十分清楚，網裡都是我的設備。這種情況下做SDN式集權是現實的，不會帶來顯著的負面影響和困難。

但對於大規模網路或分區域自治的網路，這種集權式的網路對控制器的性能、調度演算法、設備廠家多樣性、可維護性和行政問題等各方面都帶來了很大的挑戰。雖然現在也有多級的方案來探索解決，但這也是一個不能忽視的問題。得掂量下SDN化後得到的東西和失去的東西。

轉控分離另外個問題是控制層面分離的還不夠徹底，openflow把流表控制權拿走了，但設備管理還丟那沒人管呢，配過設備的都知道刷腳本一半是業務的，還有一半是管理的，管理配置目前的方案還是依賴一些其它手段比如netconf等甚至CLI。可以這麼說，某些廠商的園區SDN解決方案裡面，netconf的作用比openflow的大多了。然而依賴其它手段又是一噸私有的內容，開放兼容遙遙無期。

開放性

開放性這裡指的是對北向的開放，就是那些個北向介面，不論是哪個陣營哪家的SDN控制器，都可以提供可觀的介面，可以使用這些介面開發上層應用、對接openstack這些。

眾所周知，說到介面就是開發，也就是這點是說給有開發能力的人和需要進一步開發來匹配自己網路需求的人說的。不會開發的就只能等廠商開發好應用賣給你，或者說……不做又不是不能用。

關於簡化運維

從理論上是的，SDN推進軟體化後，廠商可以寫出不少好東西來簡化我們的運維，工作量肯定是可以大幅度下降。在各廠商的SDN網路方案中基本都有不少簡化運維的特性。

但我們需要清晰的看到SDN簡化運維的另一面，長遠來看就是運維的深度要求會大幅度提高，技能也會完全改變。因為網路控制的軟體化，網路會逐漸變成一個黑盒，故障排查這件事會變成debug。以前基於單個自治系統的排查故障的方式和工具一下就全部沒用了。

長遠來說這應該是個好事情，畢竟debug是廠商的事。不過以目前SDN深化的程度，現狀是廠商針對某個場景的寫了個比較好的簡化運維手段的應用，很符合我們的業務、運維實際情況，然後我們經過學習使用後可以在這個場景下大幅度降低運維工作量。

到這裡又會遇到兼容性問題了，控制層面分離的還不夠徹底，配置這塊都是廠家私有的東西搞的，就不要想什麼兼容了，宣傳兼容的背後肯定多少要犧牲一些宣傳的特性，至少華三的方案是核心匯聚都需要全部使用華三某些指定型號的產品，接入可以換其他廠家，但會損失一些自動化運維的功能。

關於兼容性

這點可以說是SDN最大的詬病所在了。

眾所周知，我們把思科的、華為的、華三的、銳捷的甚至邁普烽火TPLINK的路由器、交換機拼在一起使用，我想大家從來不會擔心互相的兼容性問題，像802.1Q、RSTP、OSPF等傳統網路協議的標準化是非常成熟的

但SDN這塊把以上廠家裡做SDN的拉在一起問問他們，不開發的情況下誰敢說能夠互相兼容？

上面提到的轉控分離、北向開放、簡化運維裡面帶來的各種優勢都可以被這一條撂翻。

如果按照某些廠商的方案思路，我們買了他的SDN解決方案，那結果是我們要換掉網路中幾乎所有的設備，而且局限於這個廠家的某一些產品。也許廠家會說可以兼容什麼的，但相信我，他們提的5個亮點，你每用一種其它廠家的設備就要犧牲其中某個亮點。

問題來自哪裡呢，首先是openflow，openflow看起來似乎是一個規範標準的協議，但裡面有的是廠商自己的私有擴展，而那些解決方案都是高度依賴這些私有的內容的。

另外就是之前提到的openflow對設備控制的不全面，除了流表的控制基本都是廠商自己定義，這點短時間內幾乎無解。

白盒化

這是一個賣方少掙錢，買方少花錢的故事。上一個白盒化的IT基礎設施是伺服器，結果大家非常清楚，伺服器殺成白菜價，阿貓阿狗都能做伺服器。軟體也與硬體完全解耦，伺服器上裝啥操作系統都行。

這個事最大的反對者就是思科，最大的支持者是運營商、白盒廠家，還有些打不過思科的小廠家。比如阿里買數據中心交換機居然會大批量買銳捷的，而且動不動幾千萬的買。按照常理來說阿里這麼有錢這麼牛逼為什麼要買一個小廠家的交換機，背後一定有PY交易。

事實情況是頂端的玩家真的不在乎這些大廠提供的解決方案了，這些解決方案根本解決不了問題，拿來還得開發，還賣的死貴。所以對於阿里這種公司來說白盒化程度越高越好，機子穩定性能夠就行，我要的1234基本功能567介面你給我準備好就行，其它花架子軟體反正都是我要自己寫的。

目前白盒化SDN這塊算是有點眉目了，可以了解下P4和stratum項目，這次是想要實現全面的控制了（真不要netconf了）

不過目前來看還是各運營商主要考慮的事，和園區網關係不大。園區網還是這些傳統大廠褥羊毛。

隨便說下對NFV的看法

字面意思 軟體功能虛擬化，大概就是，要什麼路由器、丟虛擬機里去，要什麼防火牆，丟虛擬機里去，要什麼負載均衡，丟虛擬機里去。

仔細想了想，我在家裡的虛擬機上跑了ROS軟路由作為主路由，應該算是趕上NFV的時髦了。

NFV的願景總結兩個詞就是省錢和靈活。

目前最大的阻礙是廠商和X86平台的性能，首先傳統廠商對於NFV是抗拒的，NFV了我還賣鎚子硬體，我一台BRAS幾十萬，一台伺服器才幾萬塊錢。然後為了適應潮流不被新興廠家找到空子插了足也還是出了NFV產品，然後賣的比盒子還貴。

第二是性能問題，即使是加了DPDK，X86平台的性能還是十分吃緊，20G-40G的轉發對於專業設備來說還是na?ve。

似乎網路邊緣的性能要求不高的地方但還是有完整的多業務需求的地方似乎是個不錯的選擇。這就是另外個話題了，有興趣可以了解下邊緣計算、ONF的另外個項目CORD。

POD 3.從業務來看SDN

由於不同行業、不同客戶的業務及業務背後引發出的需求完全不一樣，我也只從2個我相對比較熟悉的行業來看看SDN目前融合業務的情況。

園區網

先說結論，大部分園區網SDN並不能對業務帶來很大提升或者在業務上存在剛需。

首先定義一下我這裡所說的園區網一般包含什麼，一般來說是一個企業園區、單個大樓、工廠、學校、醫院或者類似的網路。不含金融，這個太特殊。

園區網大點的OSPF都要起多個域，小點的默認路由+NAT permit any any，不同行業、不同規模對於業務的需求也都完全不一樣。但從整體業務上來看，80%的業務需求是上網，還有10%是要跑些業務，比如醫院內網、校園一卡通、監控網之類的

如果只是上網的話，個人的理解是網路越簡單越好，網路大解決好廣播域和接入安全什麼的就可以了，運營商的PPPOE接入就是一個極端例子，直接隧道點對點送過來，不要考慮那麼多，只有上網需求，網通了就行，就是一個字，干！

如果說什麼東西在園區需要用一些新技術來解決的，這個真的需要抓腦殼好好想想，園區網大多數情況還是處於沒有SDN也沒多少解決不了的問題，或者不解決也沒啥影響的問題。以下幾個是我們的各路廠家給出的思路（其實是先做SDN，然後看看SDN能解決什麼問題）

• 安全資源池引流，就是防火牆、IPS、流控這些個東西都旁掛，業務A的流量丟防火牆裡過一下、B流量的丟流控里，C流量直接過，順帶還送個bypass功能，屬於SDN方案萬金油，openflow拿手好戲，到哪都能用。
• 准入認證策略遷移的問題，就是園區認證後如果對安全策略控制有些要求的單位，搞了SDN這個安全策略可以跟著人跑，不受接入層配置的限制
• 大量啞終端准入認證問題
• 簡化運維，接入匯聚上線時、替換時搞些模板化配置就行了，其它的交給SDN控制器或者overlay來解決

以上內容不代表SDN能在園區網裡做這些功能，只是各廠家自己通過SDN搞出來的一些功能，基本只能或其中某些關鍵設備只能使用這個廠家的設備。而且裡面某些功能並不是基於openflow搞出來的。

其它一些SDN的特性呢？

轉控分離：沒啥壞事，全網設備都是我的，我集權理所應當，也確實能解決一些問題，但沒有啥剛需問題需要轉控分離來解決的。

北向介面開放：開玩笑，園區網管擼代碼？只能等廠商開發好喂嘴裡了。不過個別有志之士和比較牛逼的大學信息中心確實可以干這個。畢竟openflow就是斯坦福大學裡搞出來的。

兼容性：可能是園區網SDN化的一個阻礙，上來就要換掉全網設備，要不效果總要打點折扣。後期擴容、升級、故障替換都得用這個廠家的，否則輕則損失部分功能，重則要停掉SDN恢復成傳統狀態。不過廠商關係做透了+用戶有錢這個問題就不是問題了。

簡化運維：SDN簡化運維更多的還是來源於統一設備後的廠家提供的統一配置

關於國內各做園區網的廠家是怎麼玩園區網的方案的，華為、銳捷是以SDN控制器+支持SDN的交換機做流表控制或直接下發配置來解決一些以前扁平化和三層網路方案的一些問題。華三相對比較激進一些，是直接採用VXLAN構建overlay的方式來做，各有特點，哪種方式是否適合園區網或者是否有新的思路或解決方案還需要時間和市場來做定論。

對於園區網，SDN大部分情況還是一種有則更好，但也沒啥問題一定要SDN的狀況，根源在於SDN解決的問題不是業務的問題，也不是啥不做就會死的剛需。在這種情況下，SDN更多的是一種嘗試探索、引領潮流甚至只是門面、政績工程。

數據中心

先說結論，提供雲服務數據中心SDN屬於業務剛性需求，其它數據中心也可以使用SDN來改善業務的。

講實話數據中心個人理解還不夠深入，尤其是超大規模的數據中心，在這裡班門弄斧分析一下。

首先，大家可能默認已經認為SDN在數據中心裡有非常廣泛的應用了，似乎不搞SDN的數據中心都已經脫離的潮流了。

這點在雲數據中心應該是正確的。SDN在對外提供雲服務的數據中心比如阿里雲、騰訊雲這些雲服務商有剛需需要通過SDN技術來配合雲管平台給租戶開放業務時能夠自動的配置網路數據，這種需求是數據中心使用SDN最重要的理由之一了，屬於業務剛需。

再者就是安全資源池引流，這裡對比園區網就可以體現出很高的價值了，業務種類非常多，由SDN來引流可以實現自動和自助化，也可以給雲數據中心的業務帶來價值。

另外還有多數據中心DCI的流量調度，也就是Google B4案例所做的事情。某公司分布在各個地方多個數據中心DCI鏈路成本還是非常高的，一條路徑跑滿了另外條還是半空的對業務體驗也會造成不良影響，如何提高DCI的利用率關係到錢和服務質量的問題。這個是SDN對業務層面上對業務有很大提升的一個方面。

另外提一點，其實很多數據中心的交換機上都是沒有開SDN功能的，但是數據中心裡上了全套的SDN+VXLAN。這裡是把數據中心租戶的網關、VXLAN的VTEP做到了vswitch上面，SDN控制的交換機是這個vswitch，外面的交換機主要就負責轉發。這樣最大的好處就是又用了SDN，享受SDN帶來對業務的提升，在實現完全白盒化之前又避免了廠商綁定，外面的交換機能跑常見的L2、L3協議就行了，這些協議的互通傳統設備肯定是沒有問題的，比如阿里雲和移動的幾個大資源池就是這麼乾的，Vmware的NSX解決方案也是這樣。

POD 4.總結

一個新技術的出現，目的總是為了解決業務中的一個或某一類問題，但我們的網路的場景實在太多了，園區網、數據中心、運營商等等不同的場景要解決的問題完全不一樣

有的場景中比如數據中心，SDN帶來的價值非常符合數據中心的業務需求

而大部分園區網，SDN能解決的基本都是非核心業務類問題，再加上廠商磨刀霍霍的聲音，是否選擇上SDN還真得認真考慮下。

另外SDN內部也是出於一種各方角逐的狀態，學術派和設備廠商也難以達成一個共識，還有運營商和白盒廠家攪攪事情。

因此以SDN目前的力量還很難達成普世性，SDN成為救世主還有很長的路要走。

推薦閱讀：