| 目錄 |
| - 2、配置外部網絡 - 5、啟動實例 - 3、高可用路由 - dvr創建 - dvr東西向流量 - dvr南北向流量 - NAT流量模型 - 浮動IP - ARP代理 |
1、Neutron 三層技術簡介
三層的實現主要對應傳統路由器組網的功能。包括三層的路由、NAT轉換、ARP代理、DHCP服務等。neutron在三層的實現上與二層的耦合性較低，即無論二層采用linux bridge還是ovs，L3都是采用的相同的實現方式。
但有意思的是，三層也分兩種不同的實現架構：分別是集中式、分布式。這兩者之間也恰好代表了傳統和未來的兩種實現方式。
集中式路由
分布式路由
2、集中式router
openstack的 Juno 版本時期，用戶只能創建單機的路由器，即不同的VPC之間要實現互聯，VPC內的數據需要全部轉發到該路由實例上進行轉發。
路由實例在這種場景下，提供：
1、用戶內網（VPC與VPC）之間的互聯、
2、用戶內網與外網（VPC與基礎網絡、Internet、DCI）之間的互聯，通常還要兼任NAT網關的工作。
用戶創建的虛擬網絡之間是隔離的，無法互相訪問。Neutron router 作為默認的網關能夠實現租戶網絡之間的互訪。
路由器同樣是主機linux系統內的一個網絡命名空間，單機部署時，一般部署在物理集群的網絡節點上，一邊連接租戶網絡，一邊連接外部網絡。下圖是openstack官方文檔中對neutron router的介紹：
圖中br-int、br-ex、br-eth 是ovs的交換機，路由器和虛擬主機一樣連接在br-int上，用戶的每一個私有網段都會連接到路由器的一個接口上，同時路由器上行連接到外部交換機上，實現用戶私有網絡與外部的通信。並由主機上的 L3 Agent 來完成路由器的配置。圖中的 dnsmasq 是linux上的一個小型服務器，neutron 用它來實現 DHCP server 的功能，租戶的每一個私有網絡都會創建一個對應的 dnsmasq 實例。
內網與外部網絡之間的NAT地址轉化則是在路由器上完成。NAT轉換使用的是在安全組的介紹中提到過的iptables。由iptables對數據包源地址或目的地址進行重寫，實現路由器的SNAT和DNAT。
在openstack的網絡節點上創建用戶路由器的整體流程如下：
1、在節點上安裝L3 agent
安裝neutron L3 agent需要在cotroller節點上運行以下命令，跟安裝一般軟件包沒有區別。
# apt-get install neutron-l3-agent
Neutron router同時支持linux bridge和ovs。
2、配置外部網絡
/etc/ neutron/l3_agent.ini
[DEFAULT] …
external_network_bridge =
該配置項用於指定路由器的上行交換機。默認值為 br-ex ，即使用br-ex作為連接外部網絡的交換機，一旦使用br-ex后，neutron會將路由器的上聯口連接到br-ex上，並且路由器將不會處理vlan標簽的插入和移除。這種情況下L3 agent只能關聯一個外部網絡，該主機上的所有的路由器都將使用這個外部網絡作為上行的網絡。
如果這值為空，L3 Agent將自行創建交換機、端口、和交換機的流規則。並且同時關聯多個外部網絡。所以該怎么做，已經一目了然了吧。
當有多個外部網絡時，需要手動設置網絡屬性為 router:external。
除此之外如果要制定某個特定的外部的網絡，則需要設置 gateway_external_network_id = <UUID of eligible provider network>
此外較早期版本的openstack中，路由器刪除后，路由器所使用的網絡命令空間不會自動刪除，需要修改配置文件中
[DEFAULT] ...
router_delete_namespaces = true
3、通過CLI或者Horizon 來創建路由
然后就可以開始創建路由器了。
router-create [--tenant-id TENANT_ID] [--admin-state-down] NAME
4、連接租戶網絡和外部網絡
連接指定的租戶網絡
router-interface-add ROUTER INTERFACE
連接外部網絡
router-gateway-set [--disable-snat] ROUTER EXTERNAL-NETWORK
路由器默認會開啟SNAT功能，為租戶網絡內的虛擬機提供NAT服務，保證虛擬機與外部網絡通信。
需要注意的是，目前為止，一個路由器只能連接一個外部網絡。所有內部網絡的流量都將經由此接口流出。這既與neutron router的定位有關，又影響了openstack三層的組網結構。很明顯neutron 的路由器不適合作為匯聚路由器、核心、或者出口路由。無法實現路由之間的互聯、也不支持動態路由協議。所以當前opentsack是無法實現租戶復雜組網環境的。不同子網的虛擬機需要連接到一個路由器，來實現互聯互通。這直接導致大規模部署時，集中式路由器基本不可用。基本上是一環扣一環推出，未來鐵定是分布式路由器的天下。只能說當前 openstack 在三層組網上稍有欠缺，而nicira在這一塊則完整得多。
有意思的是，當前 opentack 的 project 中還沒有看到路由器的規划，有點好奇未來openstack將用何種方式填補這一空缺，是直接像 nicira 一樣引入 NFV， 還是用ovs來代替路由器，亦或是再給iproute2縫縫補補續上幾年。
5、啟動實例
啟動虛擬機，並按照上一篇的內容連接租戶網絡。
6、配置路由器的NAT功能
這里就主要是使用浮動IP了。
neutron路由器支持一對一的靜態NAT，和多對一的PNAT。默認情況下路由器執行PNAT操作，租戶網絡內的主機經路由器與外部通信時，源地址都會修改為路由器路由器外部接口的地址。這也被稱作源地址轉換SNAT。是內網主機上網最常用的一種方式。這種情況下所有的主機共用一個外網地址，外部網絡的主機無法主動發起與內網的通信。這時就需要靜態NAT功能，將內網主機映射為特定的外網地址。即給主機綁定一個fip。
Neutron route 為虛擬機提供NAT服務
通過路由的NAT功能，只要統一做好外部網絡的地址規划后，即可實現租戶內網IP子網的復用，不同的租戶之間能夠復用完全相同的子網網段，且不會沖突。這也是公有雲上能夠容納大量租戶的原因之一。
集中路由模式的問題顯而易見，網絡節點上的路由成為流量的瓶頸點和故障點。在這種模式所有租戶的VPC之間的流量的都經由網絡節點上的路由器轉發，當雲上的租戶較多，所有的流量都匯集到網絡節點的設備上，會直接導致網絡擁塞。同時單個router出現故障，如被重啟時，租戶網絡之間就無法通信了。
3、高可用路由
高可用路由模式是對集中路由模式的一種補充，其核心是采用VRPP協議實現雙路由部署模式下的高可用。VRRP（虛擬路由冗余協議）脫胎於 cisco 的 HSRP，是一個老牌的網絡協議了。在傳統網絡設備中就被大量的使用，曾經也有過VRRP+MSTP這種典型的組網模式，扯遠了。
VRRP 部署模式下，網絡節點上需要部署多個路由器，組成一個 VRRP 組，組內的路由器將通過一個虛擬IP與外界通信。也就是說外部回指路由指向這個虛擬的IP。
VRRP組內將選舉出一個活動的路由器，其余的路由器則作為熱備路由器。主路由器將響應發送給虛擬IP的數據包，備用路由器則不會響應。備用路由器將通過心跳信號檢測主路由器的存活情況，當主路由發生故障時，剩下的備用路由器中將選舉出一個新的活動路由器，備胎轉正。
VRRP的大名路人皆知，這里就不贅述了。很容易看出，高可用路由模式解決了路由器單點故障的問題，單個路由器故障時，備用路由將接替故障路由器的工作，以保證租戶網絡流量的正常。
但是同時，高可用路由模式依舊同時只有一台路由在工作，流量發卡彎的問題依舊沒有解決，路由器依舊是大規模部署時的網絡性能瓶頸。這個時候最終就該DVR（分布式虛擬路由器）登場了。
4、分布式路由（DVR）
是的，就是上篇中提到的Linux bridge不支持的那個DVR。
分布式的使用場景下，內外網的流量不再匯集到網絡節點上之后再轉發。而是在計算節點本地就能處理，在該模式下，當租戶在計算節點上創建了使用DVR的私有網絡時，該節點隨之會自動創建一個路由器實例。傳統模式下跨子網的通信都需要將數據包轉發到網絡節點的路由器上，分布式路由器模式下跨子網的通信，都會由本地的路由器來執行路由
。
Dvr 流量模型
DVR有兩種運行模式。一個是 dvr-snat 模式，該模式的下，主機上的 dvr_snat 不僅要負責不同子網之間東西向的流量，還要作為租戶網絡與外部網絡通信的網關。內網與外部網絡所有的南北向流量都需要經過該主機上的 dvr 進行傳輸，並啟用路由器SNAT功能。另一種則是 dvr 模式，這一模式下，dvr 僅處理租戶網絡內部子網的東西向流量，即租戶在物理主機與物理主機之間的內網流量。該配置由由L3agent的配置文件實現
agent_mode = dvr_snat/dvr
dvr創建
dvr 路由器的創建的命令則與普通路由器一樣，不過最后要帶上--distributed 參數。其他命令與傳統路由器類似，采取同樣命令進行管理。不過需要注意的是 dvr 二層只能使用 ovs，且需要在所有計算節點上啟用 ovs，並修改 neutron ML2 的配置文件的參數：
/etc/neutron/plugins/ml2/ml2_conf.ini
……
enable_distributed_routing = True
l2_population = True
dvr創建好后，neutron L3 agent 會在所有連接了 dvr 的子網所在的主機上都會自動創建一個dvr的實例，用來對本地子網的流量進行路由。ovs則會連接路由器接口，並生成對應的流表。
在管理的時候，看到的是單個路由器
實際上在每一個計算節點上都有一個該路由器實例，如下圖中的MyRouter-DVR 就在controller01和computer01、02上分別創建了路由器實例，這些路由器由DVR統一配置。
通過ip netns exec命令可以查看ar路由器的接口信息和命名空間，每個路由器實例都共享相同的接口名稱、IP地址、MAC地址。
控制節點：
計算節點：
可以看到，控制節點和計算節點上的兩個路由器都包含ip地址為192.168.1.1 的qr-29db7422的接口，這個接口都連接到同一個子網 VPC 。VPC內的虛擬機需要跨子網通信時，可以就近將數據包發往本地的網關。本地的路由實例收到數據包后進行路由。
不過這也帶來一個顯著的問題，如果兩個路由器的接口使用相同的 IP 地址和 MAC 地址的話，那么交換機將從不同的接口上學到相同的MAC地址，在交換機收到虛擬機發來的目的MAC地址為網關的二層幀的時候，交換機將不知道要將數據包發送到哪個接口上，這將導致交換機轉發表的震盪。
dvr東西向流量
為了解決相同的IP和MAC，導致虛擬交換機上 MAC 地址漂移的問題，neutron 引入了獨立MAC地址，每個命名空間都有各自不同的MAC地址，但是當分布式路由器的數據包從計算節點內部離開時，ovs的流規則會對數據包的源MAC地址進行改寫，改為各個節點的獨立 MAC地址。這樣
而當數據從外部接入節點時，流規則會將源mac地址中的統一mac地址修改為本地路由實例的 mac 地址。實現 mac地址的轉換。
不同子網的虛擬機跨主機之間通信的這一詳細過程如下：
第一步：blue VM將數據包發往本地的網關，數據包的源mac地址為虛擬機網卡，目標mac地址為路由器在的接口。Br-int在收到數據包后將它發送給本地的router。
第二步，本地路由實例查找路由表后，發現Red VM 位於子網red，因此將數據包從路由器位於子網2的端口發送出去。此時處理還正常，源 MAC 地址為路由器在子網 Red 的 MAC 地址，目的地址為 Red 子網內 Red VM的地址。同時發往 br-int。
如果 br-in t如果不加任何修改，直接轉發，br-tun勢必從多台物理主機收到相同的 MAC，br-tun將無法正常回包。所以此 時br-int 會將路由器發來源 MAC 地址轉換為主機的獨立MAC，這樣 br-tun 收到的數據包分別來自不同的主機。
第三步：接下來，br-tun 看到目的為Red VM ,正常將數據包轉發給位於主機B。
第四步：主機B上的 br-tun 收到數據包之后，正常將數據包解封裝，並根據流規則添加local vlan的標簽，並轉發給br-int。
第五步：主機B上的br-int 在收到數據包后，知道要發給 vlanxx 內的Red VM。同時主機B上的 br-int將包的源 MAC 地址從主機A的獨立 MAC 轉換為路由器在 Red 子網的接口的 MAC。
第六步：br-int 根據流規則去掉vlan標簽隨后轉發到對應的red VM。
經過這一系列的轉換，Red VM以為自己全程在與本地路由器在通信，而實際上數據包是從另一台主機上的路由器發來的。而在br-tun看來，只是三個不同 MAC地址的主機在通信而已。
全程縮略圖如下：
dvr南北向流量
南北向的流量主要分為兩種情況，一種是子網內所有主機共有一個出口：SNAT、一種是單個主機綁定浮動IP，這兩種情況稍有不同。
NAT流量模型
Neutron 默認開啟了SNAT，沒有綁定FIP的虛擬機訪問外部網絡時，路由器會將數據包中虛擬機的內網地址改寫為路由器外部接口的地址。集中式路由、HA路由、分布式路由都支持SNAT。當使用DVR時，只有工作於dvr_snat模式的路由器才負責與外部的網絡的通信和SNAT。
傳統模式下，所有與外部交互的流量都通過網絡節點上的路由器上，並通過浮動地址與外部通信。SANT 命名空間專門用作 SNAT服務，浮動IP和路由上的SNAT都是由它實現。
Dvr-snat模式下，路由器會附加一個同名的nat命名空間。創建后，路由器不再與外部網絡直接連，而是通過SNAT的 qg 端口與外部連接。同時，SNAT上還有一個端口連接到內網，這個內網端口的地址與路由器內網接口的地址在同一個子網。例如同為 192.168.1.0/24.
路由器的內網接口
snat的兩種接口
計算節點上添加的默認路由
注意，此時計算節點上的默認路由指向了SNAT的內網接口地址。SNAT收到包后會修改包頭的源IP地址為外網接口的地址，然后轉發到外部網絡。
浮動IP
如果說SNAT是一群主機的狂歡，那么浮動IP就是一台主機的孤單。公有雲中最為常見的功能，通過將公網地址直接綁定到主機網卡上，實現主機與外部網絡的直接通信。並可以隨時解綁，關聯到其他任意主機。
浮動IP本質上是1對1的靜態NAT，將主機的內網地址翻譯成公網地址，實現主機與外部的通信。當租戶創建FIP關聯時，neutron L3agent即在節點上創建一個network namespace，作為3層的插件來實現NAT地址轉換。FIP一端連接外部網絡、一端連接着路由器。
當浮動IP直接關聯到虛擬機上時，計算節點上的L3 agent會創建一個新浮動ip命名空間（fip namespace），並創建新的 fg 端口與浮動ip所屬的外部網路進行通信。fip命名空間依靠該端口與外部網絡通信，該端口也需要配置一個外部網絡的ip地址。
該計算節點上的路由器命名空間也連接到相同的外部網絡，則會通過一個veth接口與fip的命令空間相連，並且會使用169.254.x.x地址段中一個反掩碼為/31的ip地址作為接口地址。每個主機上只有一個fip命名空間，多個路由器連接到這一個命名空間。
在路由器這端，接口名稱為rfp （router to FIP）
在fip 命名空間這端，接口名稱為fpr（FIP to router）
同時qrouter的命名空間中會添加一條新的源路由規則：
32768: from 10.30.0.3 lookup 16
其中 對應的路由條目為：
也就是，當關聯了浮動ip的vm與外界通信時，默認會通過rfp接口轉發到FIP命名空間中進行處理。所有的計算節點上都可能有主機需要通過 FIP 來連接外部網絡，這要求所有的物理主機都有網卡連接到外部網絡。這會導致公網ip的浪費，現實中通過其他途徑來解決這一問題。
ARP代理
之前的內容都是內網上行的流量，那么從外界進入內網的流量呢？這就涉及到南北向流量的最核心的問題——上下行流量的對稱性。特別是雲環境中，虛擬機會任意漂移，綁定了FIP的虛擬機可能出現在集群的任意一台主機上，這就給路由帶來了很大的困擾。
arp代理用於fip 回包
FIP的fg接口上設置了公網地址，同時FIP可能還關聯了多個綁定了公網IP地址的雲主機，當路由器需要知道這些雲主機在哪時，例如訪問一個綁定了公網IP的web服務雲主機。這時FIP會啟用ARP代理，即當外界的路由器發起ARP請求時，FIP會通過將自己的MAC地址提供給路由器，這樣路由器能夠正常回包，而又不用每個雲主機都綁定一個不同的FIP。
這要求外界的路由器接口與這些FIP之間具備二層的互聯能力，路由器的ARP的廣播包能夠直接傳遞到集群的主機。
5、雲上的三層架構設計
Neutron router的三層功能發展至今已經基本能夠滿足雲上租戶的需求。租戶可以基於以下的拓撲組建自己的雲上三層網絡。租戶不同的VPC通過路由器連接在一起，實現VPC之間、VPC和外網之間的通信。
三層路由器邏輯拓撲
DVR邏輯拓撲
但也僅此而已。流量從VPC出去之后呢？underlay網絡的路由如何走？
出口選路和負載均衡由誰負責？公網地址池的容量不夠了怎么辦？核心網絡的路由有調整該怎么辦？
對於雲服務提供者來說，neutron的功能還遠不能滿足他們的使用需求。雲的運營者需要的是從租戶創建虛擬網絡、連接虛擬機、關聯公網地址、創建到外部的訪問策略等這一完整的服務鏈的協調、編排、控制。而且這一切要對上層透明，對底層交換機、路由器、防火牆、虛擬路由、虛擬防火牆等設備的操作。實現underlay網絡和overlay網絡一體化的自動化管理。
雲網絡自動化
顯然，Neutron還不能形成一個完整的閉環，這也是大量SDN企業的發力點。那有較為完善的商業系統能夠與openstack集成，實現全網絡的自動化編排以滿足我們的需求么？
首先看 VMware（nicira）：
VMware 給出的解決方案是NFV，VMware在租戶層面上與openstack類似，同樣的分布式交換機、分布式路由器。但是VMware比openstack多出了一個組件：Edge。VMware推薦使用Edge作為租戶分布式路由器的下一跳設備，Edge以NFV的方式承載了租戶網絡的FW、NAT、LB等功能，並且運行着動態路由協議，可以實現與外部網絡之間的路由交換。
這樣做的好處顯而易見，Edge 可以通過 VMware 的NSX平台統一管理，租戶網絡的所有操作都可以自動化完成，無需底層unerlay網絡的參與即可實現，物理設備僅需實現互聯即可，無需做任何更改。從租戶的創建到最后租戶的離開，都可以實現自動化的編排。
其次，Edge是虛擬設備，雲提供商可以按需增加和縮減設備，為不同的租戶分配不同的虛擬設備，這樣整個網絡中不會存在明顯的單點故障點，流量被分散開來。
但是這樣做也存在以下的問題：1.使用NFV的方式實現，則底層硬件只能使用X86的設備，X86設備作為轉發設備費效比太低，NAT、FW性能嬴弱，單個NFV設備能夠承載的租戶有限，如果數據中心內部流量過大，很可能導致需要部署大量的網絡節點來解決這一問題。
相比openstack，VMware的NSX平台顯然更為成熟，也更為完善。
然后是juniper
Juniper 在SDN方面收購了open contrail 與其硬件路由器、虛擬防火牆一起組成了較為完整的雲數據中心SDN解決方案。並可以與openstack平台集成，實現網絡的自動化編排。
Open Contrail 架構
Contrail 的控制器包含三大組件，分別是配置、分析、控制。配置組件負責與其他系統的對接（如，Openstack Neutron），並將北向的應用層的需求翻譯成對網元的操作，控制組件負責將配置信息同步到各個網元中，分析系統則實時從網元中獲取數據並進行呈現。
轉發層面則是由分布在各個計算節點上的vRouter完成，vRouter定位類似OVS，本身由vRouter Agent和位於hypervisor中的轉發平面構成。vRouter Agent通過XMPP與控制器通信，獲取路由等信息，並植入到轉發平面中。轉發平面上的轉發表（FIB）記錄了到達各個目標主機的路由信息，同時其包含的流表則提供了豐富的防火牆、負載均衡等功能。
相比Neutron更為優勢的是，OpenContrail 的服務鏈支持更為智能的轉發策略。並支持通過gateway節點實現租戶網絡與外部Internet或VPN的連接。得益於juniper在硬件領域的優勢，gateway節點可以選用 Juniper Networks MX 系列 3D 通用 Edge Routers 和 QFX 系列 、EX 系列的交換機。
MX系列路由器
juniper的MX系列路由器有着不錯的性能和豐富的特性，支持MPLS、BGP、VPN、VXLAN、和VRF等特性，基本可以滿足雲租戶的各種出口場景的使用需求。並且也可以擴展DPI、防火牆、負載均衡等等線卡。
而且Contrail 控制模塊與Gateway之間是通過BGP協議來交換路由信息的，這也是現如今大部分硬件路由器和軟件路由廣泛支持的協議，所以使用非juniper的路由器無需改動也一樣能達到相同的效果，僅僅只是缺失部分juniper獨有的特性。
OpenContrail的解決方案在轉發層面雖有不同但與openstack是非常類似的，同時通過bgp協議對硬件設備的的統一編排，實現租戶與外部、租戶與租戶之間L2-L7的服務鏈實現。整個方案的架構上沒有明顯的短板，難怪的獲得了Mirantis 的認可，作為其openstack發行版默認的SDN組件，將來很有可能將完全替代 Neutron，成為其私有雲甚至容器平台的SDN解決方案。但技術的先進不能決定產品的成功，未來還等 OpenContrail 給出答案。
然后是cisco
Cisco的 DNA (Digital Network Architecture) 解決方案覆蓋了從接入到WAN、數據中心和雲多個領域，包含了網絡的方方面面。
與此同時Cisco也推出一系列的網絡設備作為數據轉發設備，包括Cisco Catalyst系列、Nexus系列交換機、ISR、ASR、ASA路由、安全設備、以及無線設備等。以及一系列的管理、控制軟件 SD-Access(終端接入)、DNA Center(雲內網絡)、SD-WAN、IWAN(智能廣域網)。產品成熟度較高，且擁有能夠覆蓋大多數網絡使用的場景。
基於這個統一的平台,Cisco希望能夠在所有這些場景下上提供一套端到端的的控制策略，實現全網的的SDN化。與此同時Cisco甚至允許用戶自行編寫應用運行在設備上，以提供額外的功能和更適應客戶的網絡環境。
DNA解決方案
DNA 產品
Cisco的SDN解決方案秉承着有限的開放策略，允許用戶在Cisco允許的范圍內進行一定的開發，但是這種開放是極度受限的，所有其上運行的應用都是通過調用設備自身提供的接口來實現新的功能，這受限於設備硬件和NOS本身的能力，以及軟件的License。真正涉及到操作系統、底層功能等核心的部分依舊是封閉的。在當前環境下這種有限的開放能滿足大部分企業的需求，但是鑒於其架構與常用的開源方案架構差異較大，用戶遷移壁壘較高，整個服務鏈中只要有一環不是Cisco的設備就無法實現完全的自動化和編排，而同時開源解決方案展現的強大生命力已經讓昔日的大哥黯然失色。
最后，Cisco這套全家桶可不便宜…
midonet
midonet同樣采用的是分布式架構，沒有中心化的網絡節點，所有節點的流量都由計算節點本地的midolm agent來路由，但是midonet 引入了一個 gateway 節點，網關節點上運行開源的BGP Daemon ( Quagga )路由軟件，通過BGP實現外部網絡與Internet之間的路由交換。新版的（5.0以后）midonet以及支持創建多個gateway實現出口的分流。
midonet的實現與vmware類似。通過 Provider router 來實現雲內網絡與雲外網絡的互聯，provider router可以代替傳統的出口路由器或者VPN設備，而雲內部的流量則由計算節點上的網絡agent來管理和維護。
最后上個big switch
Big Switch Fabic最大的特色是在轉發層面上有兩套方案：
一是，Switch light OS，一個輕量化網絡操作系統，基於開放計算聯盟（OCP）中的開放網絡項目構建。Switch light OS可安裝在支持Broadcom Trident系列或 Tomahawk 系列ASIC芯片的交換機內部。並可以兼容諸多開源的轉發插件，如：Quagga（是的，就是Midonet gateway上使用的那個，支持非常豐富的路由特性）、BIRD以及Facebook FBOSS 。這樣使得一台支持OCP標准的白牌交換機能夠直接變為一台SDN交換機。
另外一個，Switch Light VX則是一套部署在KVM上的虛擬化版本，在OVS內核上增加了更多的功能並提升了性能。類似vmware的純軟件部署模式，同樣能夠實現網絡的SDN化。
Big Network Controller 則是基於開源項目Floodlight 開發的SDN控制器，南向采用的是標准的openflow 標准協議對網元的轉發行為進行控制，北向則向各種應用提供標准的API接口。
Big switch 這種“軟硬結合”的方式，也可以算得上另辟蹊徑了，不過Big Switch顯然想做的是SDN界的微軟，把控SDN設備的操作系統。不過顯然的事實是，相比要用openflow統一南向的ONF來說，想把各設備廠家最核心的OS都給替換掉的Bigswitch簡直是冒天下之大不韙，要了所有硬件廠家的命。幾乎難以獲得廠家的支持，除了與DELL合作了數款設備外少有大型設備廠商的支持。注定難以全面下沉到普通用戶側，其未來可能還要看由Facebook主導的開放計算聯盟（Open Compute Project）的發展情況。
各路解決方案已經演化出自己的特色，給網絡這一領域的技術發展帶來了極大的活力，並開始在各個領域廣泛應用，那么這些系統能夠滿足你的需求么？