前面說了很多傳統交換機的流程以及OpenFlow交換機的內容，并結合常用的網絡功能對比了二者的差異。但是需要明白的是，OpenFlow交換機就是OpenFlow交換機，如果用OpenFlow交換機不是結合SDN的方式來使用，而是用其實現傳統的基于MAC的二層轉發或者基于IP的三層轉發，那么就沒有必要折騰了，何必哪?費力費錢還沒有收益。尤其是運營商，對于OpenFlow的態度，盡管他們又各種各樣的設備管理和維護問題，但是如同他們不自研網絡設備，再加上錢多人懶，是不會對運營商網絡做出什么SDN方面的改進的，除了某些項目名稱。 OpenFlow交換機就是基于流標項的轉發，可以結合SDN被用于結合業務的轉發，無需考慮MAC學習，無需考慮是否有路由，而是用戶或者管理員根據自己的需要來配置交換機。所以利用BMC或者MVL的傳統商用交換芯片來做OpenFlow的開發，會導致表項容量小、OpenFlow標準支持不完全、對交換芯片其他處理流程組件浪費的現象。

OpenFlow

像衛峰書中講的那樣，SDN和OpenFlow關系，二者是不能劃等號的。例如OpenStack中，如果Neutron下的plugin用Linux bridge，那么這個就不是SDN了嗎?顯然答案為仍然是SDN網絡。SDN我理解的是一種思想，而不是一種方案或者功能。所以網絡很多做法都是和 SDN有著扯不清的關系，但是這個絕非像某些大的互聯網公司扯自己的產品硬跟SDN掛鉤那樣，因為他們的產品開發時研發和測試人員腦袋里連SDN的概念都沒有聽說過，現在國內互聯網公司和很多的設備商都還只是停留在觀望和接觸的狀態，并沒有什么實質的SDN產品或者方案。并且SDN并不代表完全脫離硬件，有的云計算公司對于網絡虛擬化中有一些硬件參與就不認可是SDN，難道說要全世界的人都用一臺服務器，里面的每人用的虛擬機都用虛擬端口通信才算是真的 SDN嗎?這個邏輯充滿了荒謬。SDN只是一種思想，一種站在用戶角度、站在管理員角度可以參與管理和控制網絡底層轉發決策需求的滿足和實現。底層轉發的實現是否是純軟件或者有多大程度的硬件參與并不重要。如果一個人堅持這么認為，我只能說這個人不懂SDN。而OpenFlow交換機提供的基于流標項的轉發方式，正是SDN用硬件作為底層轉發時所需要的，因此可以說OpenFlow交換機是SDN底層用硬件實現的一種方式，而虛擬網絡里采用 OpenVswitch互通虛擬機則是用OpenFlow流表實現SDN思想的一種純軟件方案。

OpenFlow作為SDN底層實現的一個理想選擇，在轉發層面確實有很多優勢，但是個人認為也有很多需要注意的點：

如前文所述，將控制平面和轉發平面進行分離，減少了控制點，增加了控制平面的負擔，需要比以往有更強的CPU計算能力的設備才能堪重負;

SDN強調管理員在管理網絡方面的能力，這些無疑對管理員的技能和對所管理的業務熟悉度有了更高一步的要求，這點與網絡設備智能化、自動化、傻瓜化的發展思想多少是有點相悖的;

OpenFlow的多表項為業務實現提供了靈活性，但是這無疑增加了設備的成本，并且為交換芯片驅動開發人員在軟件中記錄和維護配置表項、容錯等研發工作提供相當大的復雜度;

OpenFlow 在轉發層面相比于傳統方式有了很大提高，應該是先兼容以前所有的轉發方式，但是現在的標準中，還有很多傳統轉發方式支持但是OpenFlow中不支持的，比如我要實現某個出端口中SIP=1.1.1.1的報文全丟棄，標準中暫時沒有出現匹配出端口的的內容，希望OpenFlow標準盡快得到完善;

傳統交換機中還有很多非產生直接轉發意義或動作方面的功能，比如流控、隊列調度、WRED等方面都要涉及交換芯片MMU，而這些OpenFlow是很難對各個廠家通過標準而統一的，所以OpenFlow標準化方面還有很多的工作要做;

虛擬機、iptables

為了提高物理服務器CPU的利用率，出現了使用虛擬機的概念，這樣一臺物理設備有多臺虛擬機，分別“計算”處理不同的數據，如果物理服務器是多核的情況下，可以說是真正的并行計算不同的數據。當一臺物理機內有很多虛擬機時，虛擬機的通信和隔離就有了需求，因為可能在一臺物理機內的虛擬機承載著不同的業務，而承載相同業務的虛擬機分布在多臺物理機上。打個比方，中國每個城市是一臺物理機，每個城市里的企事業單位是不同虛擬機;同一臺物理機的每個企事業單位之間是無法用自己的內網直接通信的，他們必須都將內網地址轉化為外網地址才能在公網上交互數據;而每個企事業單位可能有很多分地，比如可能騰訊在北京有幾個地方，而在廣州、深圳和上海還有分地，所有騰訊的這些分地內網都是想通的，其他企事業單位在任何處的公司里都可以通過內網轉換后利用外網訪問騰訊提供在公網的服務，這個就是不同虛擬機之間的隔離和互通。如果阿里內網的一臺設備，想SSH到騰訊的一臺內網機器上，必須給騰訊的這臺設備賦予一個公網的IP，且通常情況下，從阿里這臺設備上發出的報文到達騰訊內網時，會通過一種功能將報文的目的IP從公網地址轉成騰訊的內網IP地址，這種功能就是NAT。為了進制這種現象的發生，騰訊的內網可以通過iptables配置這臺設備進制外網ssh連接。iptables是云計算中虛擬機常用的技術，NAT是 iptables的一個功能子集，就像對報文丟棄是OpenFlow規則中動作的一種一樣。而云計算是把所有相關的管理節點和計算節點進行多虛一，看做是一個大的整體并進行統一的資源管理和調度;在所有的這些物理機上的虛擬機之間的通信和隔離，有很多種實現方案，但從技術方案上說基本都是二層vlan隔離或者對vlan數目要求過多時的vxlan方案及nvgre方案。拿OpenStack舉例，Neutron下面的plugin僅官方支持的就有十來種之多，還有很多非官方維護的，OVS的一出現就受到關注有其道理;因為最初虛擬機之間的隔離是采用Linux bridge技術，非常的不靈活而且配置無法模板化，對于搭建復雜的虛擬網絡是無法滿足的;并且對于虛擬網絡的調試、監控、故障定位都是非常不便的，而且搭建復雜拓撲的功能也很多無法滿足;Openvswitch的出現解決了這些問題，并引入了QOS、鏡像、CFM、netflow等功能，而且它還可以支持OpenFlow標準，最重要的是有一套用C語言的開源實現;導致其在網絡虛擬化里得到了很大的重視。這部分內容在論文《Extending Networking into the Virtualization Layer》和《VirtualSwitching in an Era of Advanced Edges》有非常詳細的介紹。

OpenStack

OpenStack現在是一個非常火的開源社區，官方有大量的資料和大牛貢獻代碼及文檔。但是從國內的分享來看，大部分是基于如何搭建出某種簡單的環境，尤其是網絡這塊如何搭建，以保證能建立虛擬機后在虛擬機內部可以正確的訪問各種網絡，但是從介紹來看絕大多數的分享者對OpenStack的底層技術并不了解，甚至出現了兩臺云主機在兩個vlan就無法ping通的實驗。因為網絡虛擬化在OpenStack進行商業活動中提供服務的重要性，每年的OpenStack會議都有大量的會議在討論網絡相關的技術。而此時也是SDN體現價值的一個重要案例。OpenStack的缺點已經被各種吐槽，我個人認為OpenStack為了獲取最廣泛的支持，采取了吸納百家的策略，就是現在項目眾多，耦合性也越來越大;最麻煩的是，對于計算、網絡和存儲的虛擬化，它不是采用了一種經過考慮后慎重選擇一種最有前途的然后進行專注和持續積累的方式，而是選擇了每種技術都支持且經過抽象封裝了一層中間層，這就導致的問題是OpenStack的專注無法集中，開發者的力量被分散，代碼需要經過多次的封裝，自然也就效率非常低下。商業版本除了修正其固有的BUG外，還必須解決上述問題。

VXLAN/NVGRE

VXLAN 和NVGRE的兩種方案都是為了解決大二層中Vlan ID個數不夠的問題，除了衛峰所述的封裝導致的傳輸效率降低和負載均衡受影響外，還會對硬件設備的要求上有進一步提高，據我所知，現在BCM或MVL幾乎只有一兩款芯片產品支持，這對OpenFlow的本意來說本身就是個挑戰;更別說那些通過收購其他網絡公司來完善自己產品布局的某些企業下這些收購后的子公司，他們的產品更是在SDN上沒有什么大的進展。

從ACL中吸收了經驗而改進形成的OpenFlow規則，結合現在盛行的SDN概念，已經開出了很多花朵，但是這些花朵能否最后能秋季成熟還是個未知數。但是OpenFlow確實在QOS分類、實現ACL的防火墻的安全功能、在現有網絡上對新協議進行試驗都是十分有效的。SDN是一個對現有網絡考慮了兼容性的框架，如果結合具體的業務需求，將OpenFlow的規則利用起來，必能給客戶帶來收益，給云計算、設備商和芯片商等企業帶來發展的機會和激烈的競爭。OpenFlow到底是會革命成功大放光彩，還是僅是一種過渡形態的曇花一現，可能后者的概率要大一些。

河南億恩科技股份有限公司(www.ibaoshan.net)始創于2000年，專注服務器托管租用，是國家工信部認定的綜合電信服務運營商。億恩為近五十萬的用戶提供服務器托管、服務器租用、機柜租用、云服務器、網站建設、網站托管等網絡基礎服務，另有網總管、名片俠網絡推廣服務，使得客戶不斷的獲得更大的收益。
服務器/云主機 24小時售后服務電話：0371-60135900
虛擬主機/智能建站 24小時售后服務電話：0371-55621053
網絡版權侵權舉報電話：0371-60135995
服務熱線：0371-60135900