專家與用戶的區別——寫在前面的話

SDN——一幫骨灰級的專業網管，不愿被網絡產品廠商技術綁架，自行研究出的用軟件控制網絡流量轉發技術，目前正得到多方面的關注與追捧。此情此景，不由讓我想起十多年前剛工作不久，有幸進入一家國內知名殺毒軟件公司做一個小小的技術支持人員。那時CIH病毒泛濫，每到4.26被CIH病毒破壞的硬盤成堆的擺放在我們面前。為了緩解這種情況，我們和“王老師”的公司推出了兩種相同又不同的解決辦法：“王老師”公司是告之用戶如何用他們的軟盤啟動電腦后通過類似DEBUG的工具編輯硬盤分區表，并進行改寫，從而將被病毒破壞的引導頭信息恢復。我們是告訴用戶軟盤啟動后，如何在菜單選項中選擇自動修復硬盤。我當時的領導形象的將這兩種解決方案稱為一種是將用戶培養成為數據修復專家，一種是為用戶提供解決方案。事實證明，最終我們成功了。而現在的SDN給我的感覺和以前一樣——我們應該用什么方法幫用戶修理“硬盤”?

大二層的兼容與異構——對SDN觀點的轉變

由于初期對SDN技術沒有深入了解，使我產生一種SDN是一幫技術高富帥玩的東西，與我等屌絲無關的觀點。當我對SDN進行一番挖苦之后，思博倫SDN測試技術資深專家羅竑旻的一翻話，使我對SDN的觀點有了根本性的改變。“SDN并非不堪重用，不但在國外大型數據中心中已經有很多成功應用，即便在國內電信行業中，也正在試驗利用SDN解決傳輸網數據通訊問題。” 傳輸網也在試用SDN?這段話讓我開始對SDN技術進行重新審視。不由得回想起多年以前參加某企業網絡系統驗收時的一個情景：該企業網絡系統規模龐大，部門間采用三層OSPF交換設備進行連接，為保障數據傳輸的可靠性，采用的是雙機熱備的形式部署。測試網絡切換時間時發現，由于三層路由需要重新匯聚，即便是在簡單測式環境中，統計單位也是以分鐘來計算，每次倒換的時長基本在十幾分鐘以上。也就是說一但出現故障就會有長時間網絡癱瘓的情況出現。當問及為什么采用OSPF時，承辦方給我看了一張企業內部有著密密麻麻網絡設備節點的網絡拓撲，并問了我一個問題，不用OSPF我怎么把這么多網絡設備連起來?!一句話問的我啞口無言。再回頭看現如今的傳輸網，同樣的問題再次出現，三層網絡路由倒換時間漫長，大二層技術各廠商自行其事，而這一張大網又絕對不可能由一個廠商的產品進行部署，用什么辦法才能將這張網高效率的連起來?看來不是通信企業主動選擇SDN，而是SDN所具備的先天技術優勢逼迫廠商不得不進行選擇。

理想與現實的差距——實際測試中的問題

理想是美好的，但現實是骨感的。這句話用在現在的SDN上可能會非常的合適。為了考查SDN交換機的實用性，《網絡世界》評測實驗室也試著組織了一次以驗證SDN交換機實用性為目的的架頂式交換機SDN功能公開比較測試活動。

活動初期，各交換機廠商對此有著積極的響應。得益于Avaya、博科、H3C和銳捷這幾家廠商在前期的交換機SDN功能調查中的及時回復，使我們初步了解了目前SDN交換產品在生產廠商中的技術發展情況，使得SDN交換產品測試的初步測試方案可以順利制定。在隨后《網絡世界》組織的SDN交換產品測試方法研討會上，Avaya、博科、思科、瞻博等廠商也積極參與了測試方法的討論。然而實際測試時的情況剛好相反，僅有一家新興的SDN交換設備廠商xNet(網銳)公司提供產品進行測試。

為什么會出現這種情況?從與各廠商研討測試方案的過程中，可見一些端倪：與ONF組織的PlugFest測試不同，既然要進行SDN交換產品實用性測試，除了一些數據中心的組網及用戶管理功能外，必然要對SDN交換機的網絡轉發處理性能進行測試。得益于思博倫通信對本次測試的大力支持，我們可以用思博倫TestCenter測試儀表產生一個很大的測試流量，并且可以構造出一個很大的流量表，來測試SDN控制器對大流量的處理能力。而這個測試項也是在測試方法研討中，各廠商討論最集中，顧慮最多的一項。原計劃在測試中，采用20個萬兆接口，每個接口設置200個IP地址，所有IP地址成網狀連接并進行轉發。這樣設計，預計可以構造出一個1600萬條以上的巨大流表。之所以這樣設計，是考慮到在目前的現網環境中，一個萬兆接口肯定不會只有一個接入IP，單個萬兆端口200個接入IP已算是一個相當保守的設計了，而全網狀轉發這個測試項，對于傳統二、三層交換設備來講，也不是一件困難的事情。然而參與研討的廠商紛紛遺憾的說，目前萬兆TOR交換設備在SDN功能上支持不了這么大的表項。目前比較理想狀態下，萬兆TOR的交換機表項也就在4000條左右(這夠干什么的??)。于是改為在產品所支持最大表項下進行流量轉發性能測試。即便如此，那些表示將要參與的廠商也都再未出現，還好有xNet的積極參與，才使本次測試活動可以順利進行了下去。

功能測試——SDN不負所望

雖然參與廠商僅剩下了一家，但正是因為xNet的大力協助，使我們的測試活動還是可以繼續進行了下去。在功能測試中，我們對在數據中心中呼聲最高的環網連接、數據流路徑切換和用戶權限管理這三項功能進行了測試。

環網連接

環網連接，這可以算得上是大二層云計算網絡的標志性功能了。環網連接無風暴，根據路徑智能選路，這些全新的網絡應用功能在SDN交換網絡中是否可以實現，下面，我們就實際的驗證了一下。

在這項測試中，我們采用了兩臺48口千兆(具備4個萬兆上聯接口)X1-48T和一臺48口萬兆(4個40G上聯接口)的X10-48S型號的xNet 白盒SDN交換機進行了組網測試。測試中，我們將三臺交換機的6個萬兆接口兩兩互連，通過第三方Floodlight控制器組成一環形網絡。(網絡拓撲及實際測試環境參見下圖)

Floodlight自動生成網絡拓撲

環網實際測試環境

在隨后利用兩臺PC接入環網進行測試發現，三臺SDN交換機通過Floodlight控制器組成的環網中，未出現廣播風暴現象，兩臺PC可以互相Ping通，數據傳輸正常。由此可知，在現階段SDN交換設備在設備組網功能方面，還是可以滿足大二層組網的應用需求的。#p#

路徑切換

數據流傳輸的路徑切換時間，關系到網絡的穩定性及可靠性，回想起當年三層網絡動輒十數分種的心跳切換時間，現在SDN[注]的路徑切換時長又是多少呢?為此我們對SDN數據流路徑切換時間又進行了一次測試。測試還是在上面的環型組網環境中進行，兩臺PC分別接入A、B兩臺交換機，在控制器上設置并檢測數據傳輸路徑是由A—B雙向進行傳輸后，A、B上接入的兩臺PC互Ping。斷開A交換機與B交換機的網絡連接(拔掉光纖)。查看網絡是否可以自動切換到A—C—B的路徑繼續進行數據傳輸，并從丟包數計算路徑轉換的切換時間。

切換時間Ping包截圖

從上圖的切換時間Ping包截圖中，我們可以發現，當SDN環網A-B的鏈接斷掉之后，環網鏈路自動轉換到A-C-B鏈接繼續進行傳輸，Ping包測試結果表示并沒有Ping包丟失，只是切換時Ping包延時增高到了52ms(上圖中紅框標出)。從十幾分種到幾十毫秒，這樣的鏈路切換時間已經有了跨時代的進步。

用戶管理

在當前的網絡應用中，還需要對接入用戶進行分類管理，為此我們也對SDN交換機用戶接入管理能力進行了測試。測試還是采用環網的測試環境，在控制器上設置兩臺接入PC一臺可以從接入的DHCP Server上獲得IP地址，另一臺則禁止IP地址的自動獲取。在實際測試中，無論是轉換接入端口還是換交換機，這兩臺PC的接入權限并沒有發生變化。由此可知，在目前SDN交換設備上，通過控制器可以有效的對網絡設備的接入權限進行管理。

從以上三種SDN功能性測試上來看，xNet的SDN交換設備與Floolight控制器配合確實可以解決數據中心組網搭建、連接鏈路切換以及用戶接入管理控制功能。而SDN交換機的實際應用性能如何呢?我們在隨后的性能測試中有了更深入的了解。

性能測試——控制器 控制器!

在接下來的測試中，我們對SDN[注]交換機數據轉發性能進行了測試。為此我們通過思博倫Spirent TestCenter測試儀表生成了一個200G的測試流量，通過測試儀表上的20個萬兆接口與xNet白盒SDN交換機X10-48S相連，并對數據包轉發性能進行測試。

Spirent TestCenter上20個萬兆光纖接口

X10-48S上20個萬兆光纖接口

在測試的流量結構上設置上，我們聽從了xNet網絡工程師的建議，減少了每端口數據流的條數，采用一對一的方式進行連接，并在每個端口上設置了50個IP地址，每個端口的源IP分別向目的端口的50個目的IP發起連接請求，共建立1000條IP連接并傳輸數據。#p#

Spirent TestCenter目前已經支持Openflow控制器仿真，但在本次連接性測試中，我們為了同時了解第三方控制器在真實流量轉發時的處理能力而未曾采用。在通過Spirent TestCenter測試儀表測試時，我們發現，1000條連接建立順利，并可以順利產生測試流量。但接下來的RFC 2544標準測試中，卻發生了意外。在2544測試中，我們采用從10%開始，以二分法的方式，進行網絡層吞吐量性能測試時發現，測試時，始終有大量的數據包丟包產生，以至于最后吞吐量性能接近“清零”。在問題排查中我們發現，測試儀表發流時，第三方的Floodlight SDN控制器不能及時給予處理，從而導致流表無法全部成功建立，更嚴重的是，反復幾次流表重建后，還會引發SDN控制器“死機”現象的出現。從而使測試儀表所發數據流無法正常進行轉發。原本xNet交換機通過其自主研發的flexSDN技術可以將SDN流表“緩存”在其交換機上，從而有效緩解此類問題的出現。然而在進行2544測試的同時，為了對控制器流表處理能力進行測試，每次發流前，我們都會設置測試儀表將端口進行重置，導致xNet交換機上流表清空。因此，當控制器處理能力不足，乃至于死機時，測試流量失去流表的引導，從而導致了測試的失敗。

為了保證測試不受控制器處理能力的影響，我們又一次減低了連接建立的條數，采用每端口單IP共建20條連接的方式進行測試。這次測試順利得以通過。(測試結果參見下表)

在網絡性能中，我們可以看出除64Byte下xNet SDN[注]交換機吞吐量性能較低外(由于實際應用中，基本不會出現64Byte 100%吞吐量的應用，因此現在很多交換機廠商也開始降低為小字節數據包轉發性能)，其產品在網絡層吞吐量性能始終保持在99.9%以上。(由于SDN技術轉發與控制分離的技術設計，其數據包轉發時，包內必需添加相應識別字段，因此吞吐量性能不能達到100%)表明xNet X10-48S型白盒SDN交換機從自身數據包轉發性能上來看，是完全沒有問題的。220微秒以內的數據包轉發時延也可以很好滿足當前數據中心網絡[注]數據轉發的應用需求。

但從第三方控制器的網絡流表處理能力來看，今后SDN交換技術的發展必然還將會在一段十分曲折的道路上前行。

未來發展——重筑SDN 1.0

前段時間參加迪普科技的DP xFabric解決方案架構發布會，他們用的一個詞“重筑”，給我留下了很深的印象。我曾設想如果迪普的xFabric架構與xNet的flexSDN技術結合，可能將會極大加快SDN向實用性邁進的步伐。三層網絡架構需要重筑，目前看來，SDN技術也需要一次重筑。我是從產品測試的角度來考慮這個問題的：

首先，我們要解決SDN數據傳輸一致性的問題，不要再盲目追求更多更全的SDN新功能。從底層做起，甚至是從鏈路層做起，統一不同交換機廠商SDN交換數據傳輸標準。做到各廠商產品在數據傳輸層面上的互聯互通。

在這方面，最好是由測試儀表廠商來進行引導。例如Spirent TestCenter上加入統一的SDN控制功能，在性能測試時，流表統一先由測試儀表進行下發，下發完成后再進行轉發性能測試。這在Spirent TestCenter(目前STC已經支持Openflow控制器仿真，本次測試由于要對第三方控制器性能同步進行測試而未曾采用)上并非一件十分困難的事情。當各廠商SDN交換產品在統一測試儀表下可以成功完成數據轉發后，其SDN產品的互通性自然也可以達到實用性的要求了。也再也沒有組織眾多廠商進行協議一致性測試的必要。

其次，要解決SDN控制器連接處理能力的問題，這就需要重新定制一個全新的SDN控制器處理性能測試方案。第一，要了解SDN控制器在實際應用中所必須的流表建立速率，并對SDN控制器處理性能進行測試。具體測試方法可以參照目前應用層網絡產品對新建連接性能測試方法來進行。第二，要了解SDN控制器在應用中所需的流表容量，并制定相應標準進行測試。這同樣可以參照應用層產品測試對并發連接數的測試要求。通過這兩項測試，可以解決SDN控制器處理能力和穩定性方面的問題。

最后是SDN功能性上的要求，這方面，不妨徹底放開，在保障底層網絡互聯互通的基礎上，由網絡廠商八仙過海，自行去設計對SDN流量的管理控制功能，那個廠商的管理控制功能做的多，處理性能強，自然就可以占據網絡的核心領域，不足的廠商自然會被排擠到網絡的邊緣，或者接入設備的地位上，從而實現自然的優勝劣汰。

隨著功能及性能方面的不斷提升，SDN技術自然會得到蓬勃的發展，從而徹底改善目前網絡應用現狀。希望這一切都可以從“重筑SDN 1.0”重新開始!