【前言】
近年來，隨着“雲架構”或者“新基建”等概念不斷被提及，以及與之相關的IT項目落地，SDN（軟件定義網絡）也隨之被炒熱，加上媒體或者許多培訓機構因為各種目的所進行的“誇張”宣傳，使得許多人尤其是相當部分的傳統網絡工程師認為這一技術將革命性顛覆傳統網絡協議，甚至會淘汰掉不會編程的網絡工程師。針對於“SDN會不會使得傳統網絡工程師丟掉‘飯碗’”這個問題，答案應是否定的，即SDN的出現不會淘汰掉傳統的網絡工程師，但會對傳統網絡工程師職業發展構成挑戰。這個答案是個人基於現階段各類解決方案中，SDN和傳統路由交換網絡之間的關系所得出的。本文將通過個人近期對SDN的理論學習以及相關實驗，闡述一下個人不成熟的看法，一是對相關學習做出總結；二是基於個人認知對SDN做出客觀評價；三是對希望了解SDN的朋友提供一些學習方法建議。因水平有限，文章內容可能會有錯誤之處，歡迎批評指正。
【SDN入門的“三座大山”（學習門檻）】
個人認為，現階段在國內互聯網的資源之下，相對於傳統路由交換網絡，SDN的初學成本是比較高的，這個成本並不是物質上的成本，而是時間和精力上的成本，本人學習SDN所遇到的問題，主要有以下特點：
1、國內互聯網暫無技術中立且成體系的SDN教程，中文資料也相對不足；
2、模擬器匱乏，使得少有機會接觸到真實設備的工程師進行實驗不便利；
3、學習門檻相對較高，在無法接觸真實設備的前提下，僅有的Mininet仿真環境要求學習者有一定的Linux和Python基礎。
【個人對“三座大山”問題的解決】
1、針對於SDN教程零散不中立且不成體系的問題，只能將零散的教程在學習進行匯總。 個人了解到，大部分的傳統網絡工程師都知道SDN最大的特點是“轉控分離”，且聽說過廣泛用於南向接口的OpenFlow協議，但對於“轉控分離”如何實現卻並不是很理解。在這樣的前提下，個人建議首先對SDN的概念有一個初步認識，並SDN模擬器Mininet的操作進行學習，這個步驟可以在bilibili上搜索到課程，鏈接為:https://www.bilibili.com/video/BV1VJ41117vJ，除此之外，文字性的博客文章，網絡上也有很多可供查閱。
在完成上述步驟，並通過Mininet模擬器對SDN有一個感性認識后，接下來可以對華為的HCIA-SDN和HCIP-SDN認證課程進行學習。 需要注意的是，這兩個認證課程雖然成體系，但夾雜有華為自己的產品特性在里面，因此在這一點上學習者需要對這些“私有”的東西進行篩選，使得自己所學的知識是通用和中立的。由於在此階段學習中，相關的實驗是在華為Agile Controller-DCN以及相關硬件設備下進行的，而這些設備對於絕大部分人而言是很難獲得，因此學習者需要將相關實驗中立和通用的部分遷移到Mininet上進行。這一階段完成后，就需要尋找相關“大部頭”資料進行學習，去了解各種使用場景，比如華為、H3C、VMware的技術文檔和書籍。
2、SDN模擬器比較匱乏，和傳統網絡擁有ensp、HCL、eve-ng、GNS3等不同，目前可用於SDN實驗的模擬器僅有Mininet一種，並且該模擬器只能在Linux環境下運行，並且需要使用者具有一定的Linux基礎和Python基礎，用於通過Python腳本創建拓撲以及進行Mininet安裝配置和流表操作（流表是SDN網絡中的一個重要概念，SDN不再通過傳統轉發表項進行二層轉發，而是通過流表項），如果對Python不是太熟悉，也可以使用Mininet的可視化工具Miniedit，但Mininet仍舊有不足之處，比如在模擬SDN的東西向接口有很大局限性，所謂東西向接口並不是SDN的標准名詞，而是一個俗稱，是指SDN網絡作為一個網絡域，通過BGP等域間協議，與傳統網絡對接。
3、針對於需要使用者具有Linux基礎和Python基礎的問題，這一點主要是針對於Mininet的使用而言。在真實的SDN網絡下，則不需要網絡工程師擁有這兩個基礎，也不需要網絡工程師去寫腳本程序。但個人仍舊建議網絡工程師需要掌握Linux和Python，這並不是因為SDN本身，而是因為在某些情況下，Linux可以實現的網絡功能會比路由器交換機更加豐富（如鏈路聚合），而通過Python編寫自動化腳本則可以使網絡工程師減少很多重復性勞動。
【從架構的角度看SDN和傳統網絡的關系】
SDN和傳統路由交換網絡的聯系，主要是由以下問題建立的：
因為SDN具有轉控分離的特點，各個交換機（轉發器）僅有轉發平面而不具有控制平面，控制平面主要由SDN控制器承擔，這也就決定了轉發器在沒有SDN控制器的情況下無法識別和轉發任何網絡數據。由此產生了一個矛盾點——SDN網絡組建初期，轉發器和控制器之間的連接應當怎樣去建立？
針對於這個問題，答案只能是通過傳統路由交換網絡去建立起轉發器和控制器之間的連接。我們通過查看開源的SDN控制器Ryu，發現可供我們使用的設備主要是以OpenFlow交換機為主。也就是說，SDN在基於二層網絡的通信上有很大的作用。由於在數據中心中，大部分網絡架構的核心層都是以三層通信為主，而要想在傳統三層網絡中通過二層通信使得轉發器和轉發器之間，轉發器和控制器之間建立連接，可以使用的技術就基本都是VXLAN了，而在骨干網上，SDN也可以承載於三層網絡之上。眾所周知，VXLAN是一個典型的overlay網絡，而SDN在絕大多數情況下承載於VXLAN網絡之上，因此SDN也屬於overlay網絡之一。而至於underlay網絡，則是諸如OSPF、ISIS、IBGP等傳統協議構成的。
對於SDN網絡的架構，則如下圖所示：
總而言之，上面的描述一直表達的都是這樣的結論——傳統路由交換網絡充當的是“地基”，而SDN則是上層建築；因為SDN建立初期轉發器不具備識別和轉發任何數據的能力，因此它們要想建立起通信，依賴於以VXLAN為首的傳統網絡。
【SDN控制器與轉發器建立連接的過程】
[注：關於本小節理論參考來源為https://blog.csdn.net/qq_33240671/article/details/107106099 ，實驗驗證部分為原創]
通過前面的描述我們知道，SDN網絡在建立初期依賴於傳統網絡，在傳統網絡中，各個SDN轉發器就是普通的交換機，而SDN控制器本質上就是一台普通服務器，交換機和控制器之間建立連接的過程如下：
1、基於傳統網絡協議，控制器與交換機之間建立TCP連接；
2、基於建立起的TCP連接，控制器與交換機之間互發OpenFlow Hello報文，協商OpenFlow版本；
3、互發Hello消息后，控制器向交換機機發送Featrues Request消息，希望獲取交換機的ID、緩沖區數量、端口信息等特性，交換機會將相應信息封裝在Features Reply報文中回復控制器；
4、set config是控制器用來配置交換機發送的數據包；
5、當流表中沒有關於新到達流的數據包或者即使有關於新到達流的流規則但其行為是發往控制器的時候，交換機向控制器發送Packet In消息；
6、Packet Out消息是控制器指定的某個數據包的處理方法。
上述過程我們可以通過實驗來觀察並驗證，實驗拓撲如下：
實驗步驟為：
1、在Linux系統下，進入預先已經安裝完成的Ryu控制器目錄，通過ryu-manager命令選擇其中一種類型的交換機用於將SDN控制器的流量轉發出去，選擇完成后，程序將自動創建一個SDN控制器；（本實驗選擇的是simple_switch_stp_13.py，此交換機表示其支持OpenFlow1.0~OpenFlow1.3協議，並且在SDN建立完成之前運行STP協議來防止環路發生）
2、以root權限打開wireshark，選擇環回接口lo進行抓包，命令如下：
3、編寫Python腳本，創建網絡拓撲，此拓撲僅創建了一個交換機，相關腳本如下：
4、事先安裝完Mininet的前提之下，在Linux終端中，進入到Python腳本所在目錄，輸入命令“sudo mn --custom ./SDN_example.py --topo MyTopo --controller=remote,ip=127.0.0.1,port=6653 --switch ovsk,protocols=OpenFlow13”來啟動Mininet模擬器，運行步驟2中編寫的SDN_example.py腳本，並與SDN控制器建立連接；（此命令含義為：通過sudo（root權限）運行代表Mininet的mn指令，拓撲為SDN_example.py中的MyTopo類，SDN控制器類型為遠端控制器，其IP地址為127.0.0.1，端口為6653，即真實電腦本身,交換機類型為OVSK交換機，並運行OpenFlow1.3協議）
5、進入wireshark界面進行觀察，我們可以觀察到如下圖所示的報文交互過程：（由於是仿真環境，交換機和控制器之間的IP地址均為127.0.0.1）
通過以上幾個步驟，SDN控制器與交換機之間的連接建立完成。
【通過下發體現SDN三個基本層次】
SDN網絡具有三層，他們分別是應用層、集中控制層和基礎設施層，其中基礎設施層代表的是硬件設備，集中控制層代表的SDN控制器，而應用層則是基於控制層給出的北向接口開發出的軟件應用，通常情況下，網絡工程師對SDN網絡進行配置就是基於這些處於應用層的應用軟件進行流表等配置下發。
下面我們可以通過實驗來體現這個層次。實驗拓撲如下：
1、編寫Python腳本創建拓撲（圖中addSwitch()函數的參數dpid指的是Datapath ID，它是由OpenFlow實例ID和設備橋MAC組成,前16個比特是OpenFlow實例ID,后48個比特是設備橋MAC。）：
2、啟動SDN控制器Ryu：
[注：Restful api是SDN北向接口之一，在mininet中，使用Postman可以通過這個接口進行流表操作]
4、啟動mininet並運行Python腳本：
5、確認此時轉發器只有到控制器的流表，而沒有其他流表：
［知識點擴充：通過上面的初始流表我們發現，每一台設備都有一條前往SDN控制器的流表，因此在相關網絡部署中，SDN控制器的邏輯部署位置應當等同於SNMP服務器，分為帶外管理和帶內管理，一般情況下都使用帶外管理，和業務流量隔離］
6、在mininet視圖下，通過links命令查看設備接口情況：
7、根據步驟6中的接口詳情，來下發流表，下發流表的方式有很多，這里我們在Linux系統視圖下使用ovs-ofctl命令來下發流表：
8、在mininet查看流表信息並進行聯通性測試：
下圖為聯通性測試，造成PC2、PC3和PC4無法通信的原因是因為生成樹的計算造成了相關接口的阻塞，但需要注意的是，SDN本身是沒有生成樹的概念的，相關生成樹計算是在SDN網絡形成之前的傳統網絡階段所進行的，待SDN網絡形成后，控制器會根據之前生成樹計算的結果，向相關接口自動下發行為（action）為drop的流表，代表這個接口會丟棄所有的數據包：
在上述步驟7中，我們可以通過調用Restful api接口來對流表進行操作，需要注意的是，如果要使用Restful api接口，需要在個人電腦上自行安裝Postman等應用（Postman有單獨的客戶端版本，也有基於Google Chrome的插件版本），以及在啟動Ryu執行ryu-manager命令時添加“ofctl-rest.py”參數（如步驟7的紅箭頭）。
一切都成功運行后，打開Postman，成功進入后的界面如下：
此時，我們可以進行對流表進行增刪改查等操作，此處我們通過輸入url查看了轉發器1的流表，該流表默認使用json語言顯示的：
個人觀點，如果僅是為了使用mininet做實驗，建議使用ovs-ofctl命令，因為這個命令的參數書寫規則比較統一，不會因為控制器的改變而改變，而通過Restful api接口下發流表的差異就比較大，比如說Ryu控制器和OpenDayLight控制器風格就不同。有關於ovs-ofctl的參數，網絡上已經列舉得比較詳細了，此處不累述，而針對於mininet內轉發器的流表操作語法，按照前文步驟7中的風格即可。
根據上述例子，在使用ovs-ofctl命令下發流表時，應用層是真實的Linux電腦本身，ovs-ofctl相當於調用了真實電腦和Ryu控制器之間的北向接口。ovs-ofctl命令原本是為了對Linux內置的OpenvSwitch進行操作，但mininet+相關Python腳本啟動和執行完成后，會促使Linux創建相關的OpenvSwitch虛擬網卡來提供抓包和連接遠端SDN控制器之用。
而在調用Postman+Restful api這種方式上，應用層是Postman，北向接口則是Restful api接口。
在mininet中，應用層通過北向接口打通集中控制層Ryu，Ryu再通過南向接口協議OpenFlow打通轉發器，不過在真實SDN中，南向接口則不一定是OpenFlow。
【SDN並非適用所有場景】
1、以下只是基於個人結合互聯網上的觀點舉出的三個例子：
2、由於目前SDN尚在發展階段，並且在商業化的過程中涉及到了多方利益（尤其是思科、華為等傳統網絡設備制造商的利益），導致了“交換機白牌化”這一目標暫時無法實現，從而導致了各個廠商之間的SDN解決方案是互不兼容的，盡管OpenFlow是通用的標准協議，但SDN不等同於OpenFlow。所以，在不適合被單一設備廠商“綁定”的場景下，SDN並不適合。
3、由於SDN相對於傳統網絡來說，缺乏大規模落地的項目案例，因此在可靠性和技術成熟度上是未知的，因此，在諸如運營商基礎骨干網這一場景下，為求絕對穩定，對於SDN或者NFV的部署總體持觀望態度。
4、在網絡規模不大的前提之下，沒有必要花費更大的物質和技術成本去部署SDN。
【總結（個人觀點）】
回到本文的主題，本文主要是通過現有解決方案和模擬實驗論證以下觀點：
1、SDN與傳統路由交換網絡的關系為——傳統網絡是“地基”，SDN是上層建築，可以說在現有的解決方案下，沒有傳統路由交換網絡也就沒有SDN；
2、未來，商業化的SDN不會取代傳統路由交換網絡，傳統網絡工程師也不會因此失業，它只是作為現有網絡的一個新技術補充而非取代，但新技術的出現會對傳統網絡工程師的職業發展構成挑戰，所以在這樣的前提之下，傳統網絡工程師必須去積極掌握這一技能。
【附：本文實驗腳本代碼及注釋】
1、實驗：交換機與SDN控制器建立連接過程的拓撲腳本 SDN_example.py：
2、實驗2：通過一個實驗拓撲闡明SDN對比傳統網絡之間優勢-拓撲腳本 SDN_tranditionalNet_compare.py：
————————————————
版權聲明：本文為CSDN博主「木下-俱歡顏」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/muxia_jhy/article/details/109674829