對于SDN大家估計都耳熟能詳，這里首先講講虛擬化網絡技術故事，當VM技術出現的時候，存儲通過本地存儲或遠端掛載的形式基本沒有太大變化，但是網絡技術呈現形式一直不斷翻新。
OVS可以說是一個網絡虛擬化里一個重量級的開源產品級作品，OVS模仿物理交換機設備的工作流程，實現了很多物理交換機當時才支持的許多網絡功能，但是每次配置都需要到宿主機里去手工設置，管理員們正在煩惱之時，SDN就像朝陽帶來了希望
就是可以將OVS設置SDN的控制器，然后管理員就可以通過頁面點擊按鈕來調用SDN的北向API來配置和管理多個OVS，這為網絡虛擬化管理和配置帶來了便捷；這給某些工程師帶來了些認識：
1 軟件時代來臨了，軟件實現的虛擬網元可以取代系統工程師和運維工程師一直摸不透的黑盒子；
2 SDN的名稱Software Defined Network名稱更讓人理解為軟件替代一切的SDX理念，后來衍生到軟件定義存儲SDS和軟件定義數據中心SDDC的概念
這里說幾個虛擬化（存儲、計算和網絡）的好處：
1 通過虛擬化，屏蔽底層故障，增加手工干預所需時間，便于運維；
2 通過一虛多提高資源使用效率，節省成本；
3 便于集中管理資源，為云計算的服務提供堅實基礎支持；
這里需要提及下，一臺物理機虛擬多個虛擬機時虛擬化，多個物理機虛擬一臺虛擬機同樣是虛擬化。虛擬機和物理機同時被云平臺管理也是現階段很多場景需要的，包括Openstack的組件里有管理虛擬機的Nova和相應管理裸機的Ironic。
這里澄清下幾個概念：SDN提出的時候并沒有區分所控制的軟件轉發層面是虛擬網元還是物理網元，但是從SDN的理念開放的南向接口這項來看，OpenvSwitch這類虛擬網元支持的Openflow協議速度比硬件支持實現肯定要快很多（這里并不是說OVS是第一種SDN里的網元，也不是說SDN里先支持虛擬網元后支持物理網元），多多少少關聯了些NFV（Network Function Virtualization）的思想（NFV的理念現在很多被設計為VMaas，SDN結合NFV在部署和網絡管理上提供更多的相互支撐）。
但是SDN的名稱和對OVS支持，讓系統工程師和運維工程師多多少少會認為SDN就是軟件代替硬件網絡和SDN就是運維網絡的工具；當系統工程師和運維工程師云SDN津津樂道的時候，而此時的網絡工程師在做什么哪？理論上講SDN是屬于網絡領域的概念，而SDN產生前期的時候絕大多數的網絡工程師（到現在還有很多設備商的網絡工程師）還是沉浸在數據包轉發和網絡協議的開發中，幾乎對SDN沒有什么概念。
我們現在經常看到各種分享和峰會里，提及SDN應用的很多是互聯網公司的運維工程師（需求是網絡可視，突破網絡協議OSPF/BGP等不可控的約束對網絡操作，作為一種運維工具實現可視化網絡）和云計算公司的系統工程師（軟件實現網絡，擺脫理解不了的硬件盒子，使用軟交換或白盒交換機實現可控），設備商的網絡工程師分享SDN的則相比不是太多。
個人觀點：最懂網絡設計的工程師還在于世界上各大設備商公司里，SDN這種新架構的落地要靠他們（當然包括他們從設備商跳槽或創業后后到互聯網和云計算公司從事的SDN網絡設計落地工作，以及協助集成商落地SDN）。
做網絡開發的對虛擬網元的網絡原理都懂，上手代碼也會很快；但是沒有玩過網絡設備的工程師搞網絡，對黑盒子都會始終有很多迷惑的認知，這些往往是導致出網絡問題的根源，曾經出現過某云平臺因為交換機問題導致的云平臺故障
OpenvSwitch現在來說是比較出名的虛擬網元，還有思科的Nexus 1000V，微軟的Hyper-v Vswitch，Vmware的VSS/VDS等；OpenvSwitch來講，相比于硬件交換機，支持的功能逐漸完整，并且已經發布集成Conntrackd的有狀態規則（OVN已經實用之來作為Neutron里替代Iptables實現安全組，但最新2.4版本的OVS未發布該特性），這點作為新特性的創新來說是傳統硬件交換機支持不了的；
但是OVS在Egress Pipeline Processing方面支持度還有待進一步增強（Openflow1.5才有這個支持），包括流表對出口的匹配、端口出方向QOS帶寬限速、出入方向對BUM報文的抑制等，但是OVS的性能和現在萬兆的交換機相比，還相差很遠。
個人觀點：所以在虛擬化網絡不成熟的今天，需要虛擬交換機這類來不斷完善新特性；但是縱觀網絡發展，包括殺毒硬件、L7交換機等類似產品，以及博通等芯片廠商硬件開始支持端口虛擬化和虛交換機等，網絡虛擬化產品最終也應以網絡設備的虛擬化來實現為主，從而釋放出所占用的服務器 CPU等資源。
這里再說下傳統網絡的SDN應對的問題：以前的大規模網絡互通是靠路由協議實現路由發布實現數據轉發面互通（此時路由協議的交互基本是通過數據轉發面來實現即帶內），路由協議一旦啟用人類很少能主動干預，這種不可控導致了一些問題；
無法動態為所部署的業務分配所需網絡資源（為何以前不能分配所需？因為以前的網絡資源還不足夠多，現在隨著網絡設備能力增強帶寬只是個數字而已）；大象流集中到某些鏈路導致網絡帶寬使用率不理想等；大象流超過單鏈路帶寬如果走多路徑ECMP會導致接收端服務器對報文重排序非常耗CPU；
這也是為何單端口帶寬一直上升的原因，從千兆到萬兆，現在又盛行升級到25G，然后40G/100G，后續還會再增加。
傳統網絡還有一些問題：比如各廠家堆疊基本都是各廠家自身產品幾個有限型號才能堆疊，這就導致了另一個問題，作為匯聚或核心層設備進行HA的時候，一旦一臺設備在某種場景下觸發了BUG或問題，另一臺同型號設備的話則也會有同樣的問題，使得HA失效。
上面講了這么多，主要是說SDN出現的一些背景，這里簡單說下SDN的概念，SDN主要是說能夠將應用和底層網絡轉發關聯起來，讓上層應用控制底層數據轉發，所以SDN的名稱ADN（Application Defined Network） 更符合一些；
那這就要底層轉發網元和管理面做一些相應的改進，SDN有三個特征：控制轉發（邏輯）分離 ，開放的（不是開源）的編程接口 ；集中（邏輯）的網絡控制。所以SDN的本質個人認為是：
一種新型的可視化網絡設計架構
一種網絡資源管理和優化使用方式
一種節約資源降低網絡成本的技術
一種體現對網絡需求增速變慢的技術體現點
另外SDN不是：
SDN不是網絡虛擬化或NFV ，即SDN不是軟件實現網絡，
SDN不是網絡設備，包括OVS和白盒交換機
SDN不是某種網絡協議，包括Openflow（含TTP)
SDN不是網絡的必須或主宰技術 ，和其他技術一樣，需求推動
SDN不是純粹的網絡配置工具
SDN不是純粹的網絡運維工具
SDN不是軟件網元替代硬件網元
SDN不是提升轉發面網元本身性能的工具，只是網絡資源使用方式的改變，換句話說SDN只是換了種對網元的使用方式，將其自身的最佳性能得到了發揮；所這點來講，對于苛求或批判SDN方案（尤其是Neutron結合SDN）提升網元自身轉發性能的同學，只能說還不理解SDN或者還不理解網絡
SDN的各向接口：
北向暫時沒有標準，各家控制器基本都有自己的接口，這點北向標準還不如Neutron
南向:Openflow，Netconf，BGP、OVSDB及思科的Openflex等等（一款控制器可以同時使用多種南向協議）
東西向：BGP等等（有個SDN東西向的Draft：SDNi，還有篇paper提出了East-west bridge）
SDN級聯，包括了SDN的南向和東西流流量，暫時未看到標準
這里著重說下最后一點，Openstack的L版添加了Port的Qos特性API，另外企業網尤其是中小企業的小規模網絡會不會從SDN里收益？大家一致的印象是只有大規模設備用SDN才劃算，對此個人觀點是找到合適的應用場景SDN一樣可以讓小規模網絡收益，包括企業辦公網等。
說完了SDN也順便聊下NFV，NFV自身是說為了解決當前hardware-based情形下，隨著應用更新的加快，硬件跟不上應用需求的步伐，導致硬件設備壽命縮短導致浪費，需要對存儲、計算等所需的網絡功能進行虛擬化，來加快創新，并節省對硬件設備的投資。
個人理解，NFV是英特爾等CPU廠商用X86和虛擬化廠商用虛擬化技術進軍網絡研發領域的一種策略；首先，上層應用對網絡所需的特性并沒有那么多的個性化定制，尤其是隨著先交換機白盒智能化和存儲設備的白盒化，應對創新需求只是這些廠商對運營商的單方說辭；其次，無論NFV在運營商的產品化形態如何（VMaas就是一種形態），運營商對網絡設備的需求都是不可少的，但NFV對傳統網設備商還是有了一定的智能化促；
最后英特爾等也同時硬件設備領域沒有放手，通過收購FM研發硬件交換芯片，并結合X86推出基于FM10000的ServerSwtich，使其網絡方面虛擬網元和硬件網元優化一體化解決方案的戰略內容之一。所以NFV可謂是“項莊舞劍，意在沛公”，Openstack里也越來越多的NFV特性比如Service chain方面的支持。
現在來看云計算方面的內容，云計算中大二層需求、網絡虛擬導流所用隔離技術包括Vlan Mpls Vxlan Nvgre STT Geneve 等，Vxlan逐漸 成為趨勢 ，但OVS 2.4.0版本Geneve支持basic 版本；所以這里拋出一個問題，現有技術的規模還是受限，如何做到隔離域有無限大的可能哪？
因為現在來看可能IPV6的地址數目128比特和STT在內隔離域數目最多為64bit，但是終將還是個固定值，相對于將來的星球間宇際通信來說，數目還是少的可憐（當然星球間通信是不是以太網或IP還是未知數）。
然后回到分享開頭所提及的虛擬機技術，個人觀點現在KVM/XEN/Hyper-v/ESX等都是半虛擬化，實現了VM跨主機的才是真正意義上的虛擬化，虛擬化方面包括現在盛行的Docker 引入的網絡管理組件都是僅是用了已有的網絡技術，對網絡技術的本質創新都沒有做出貢獻，僅僅是在使用樣式上有了翻新；
但這些確實促進了技術的發展，包括在計算服務器通用后的存儲和網絡的白盒化，網絡方面也促進了服務器網卡虛擬化（SR-IOV等）和交換機的虛擬化（交換芯片的虛擬化和端口hair-pin等特性），服務器網卡收發包方面DPDK的出現也有一定的影響。
這里才到今天真正的主題里說下Neutron相關的內容，Neutron是什么？
Openstack開源社區網絡配置管理組件
Neutron的網絡服務包括L2-L7
Neutron只是管理配置VM所用網絡
Neutron有很多SDN控制器作為plugin
Neutron的主要功能：L2功能（Port、Subnet、Network、Qos、安全組等）、L3(Router/DVR、DCHP等)、L4-L7(FWaas、LBaas、VPNaas、DNSaas-Designate等)。對應的網絡功能底層網元實現來看，Port對應VM掛載的VNIC相應TAP/TUN設備，Subnet只是一個IP Pool的數據集合，Network則要對應分配網絡類型和相應隔離域ID，Qos功能可以基于OVS來實現，安全組最初基于linux bridge上的iptables，這種有狀態的規則前面也提及現在可以基于OVS來實現了；
L3上Router實現是通過linux的Namespace，不過Dragonflow則是通過OpenvSwitch的流表，DHCP和DNS服務最初是通過Dnsmasq；L4-L7的服務開源實現方案里，FWaas是通過Router里的Iptables，LBaas是通過Haproxy，VPNaas則是Openswan，當然現在很多設備廠商比如Juniper、思科、華為和F5將L4-L7的底層實現換成了自己的設備。
Neutron的機制是通過plugin/driver/agent等方式實現不同底層網元實現的集成，plugin里L2-L3稱之為core plugin，L4-L7成為service plugin；driver是同一個plugin下替換不同網元實現的方式，而agent是部署在底層網元一側的相應Driver代理，來對網元轉換參數并下發到網元里；
Dragonflow/OVN是Neutron比較新的Core plugin，不過都想將service plugin也統一起來。Neutron的未來，這里借用下華為同事章宇（sina微博：一棹凌煙）的話說：將來只剩下Neutron的北向API及Neutron server；這點比較贊同；
Openstack本來只是一個框架，底層實現應該讓云平臺廠商來定制化。
Neutron畢竟是份開源代碼，現有實現ML2等有比較多的缺點：
過多的臃腫代碼，維護和修改比較困難
這么多plugin，這么多種類plugin，也是醉了
系統工程師思維搞網絡，軟件才可控
無法理解和集成硬件是其永遠的痛，設備商的加入才走向網絡正規
開源實現思路，實現優先，產品化次之
企業廠商產品化道路多舛，有礙Neutron社區發展
多方利益博弈，規劃道路多變
主張所用技術經常被顛覆，積累容易付諸東流
Neutron的演進：
Nova-network是前身
Core plugin完成L2/L3/DHCP等基本功能
Service plugin完成L4~L7功能升級
DVR等實現系統層次的HA可用
Neutron結合SDN實現網絡可控為終極形態 ，Neutron有很多SDN控制器作為plugin
這里提及下DVR，解決同路由下跨網段的三層東西流量卸載 ，減輕集中式網絡節點負擔 ，因為同網段二層通信本來就不經過網絡節點，DVR的實現軟硬都可以，并不只有OVS等虛擬網元才能實現。
京公網安備 11010502049343號