晚上好，很高興認識大家，我來自Canonical，做OpenStack的，之前在IBM干了三年也是做OpenStack的，主要做網絡，做純技術的。

所以我就做一些純技術方面的分享吧，漫談一下SDN網絡，拋個磚引個玉，說些觀點，給出鏈接，然后大家提問，大家一起溝通探討認識一下。

IaaS就是為用戶提供隔離的操作系統資源，對外可以以虛機、容器、VPC等外在形式表現出來。

OpenStack最初就是一個開源的IaaS平臺(當然現在在Heat上又掛了一些PaaS的東西，我們暫且不表)。

操作系統資源主要由計算、存儲、網絡三大資源組成，所以Neutron的職責應該是為用戶提供隔離的網絡服務，也即NaaS(Network as a Service)。

所以從這個大的視圖上講，無論是OpenStack還是Neutron的重點應該是提供放之萬物而皆準的權威的北向API，同時像Linux內核一樣提供插件結構讓這領域的不同廠商的不同技術都可以通過寫驅動的形式進來玩。

對于網絡來說：

二三層一般叫網絡拓撲，四到七層叫網絡服務(即網絡應用，如防火墻，負載均衡，入侵檢測系統，入侵防護，深度包檢測，數據緩存，廣域網加速等)。

網絡拓撲可以由兩種技術實現，一是Overlay技術，一是新興的OpenFlow流技術。實現上二者在控制平面/轉發平面所做的事情的思想是一樣的。我們以Overlay舉例來控制平面與轉發平面的實現思想。

轉發平面，NaaS是為每一個用戶提供用戶隔離的網絡服務，一般使用標簽來隔離，如傳統的vlan，但它需要修改物理交換機，部署麻煩。于是，后來一般使用overlay技術，如gre, vxlan，nvgre, Geneve, stt，mpls over udp/gre等，同樣使用標簽segmention id來隔離用戶網絡流量，即通過自定義二層幀，通過UDP或QUIC或TCP Fast Open或IP或者別的什么上層協議傳送到遠端，再由遠端解析這個自定義幀。這個幀是自定義的，所以格式就五花八門，于是，市場上就出現了眾多的SDN產品，但其技術本質都是差不多的。于是，有人就想統一這個幀的格式，于是就有了Geneve。overlay的本質有兩個頭，一個是外部管理網段的頭，一個是內部租戶網段的頭，這樣天然為IPv4實現了NAT之類的網絡地址轉換。

Overlay網絡可以分為兩層，一是物理網絡，一是構建在物理層上的虛擬overlay網絡。

物理網絡不需要和用戶信息關聯，它只是負責提供一個IP矩陣實現所有物理設備之間的單播IP可達性，并提供segmention id功能實現租戶隔離。而虛擬overlay網絡則會包含租戶的信息，即類似于VPN為每一個租戶都生成自己的路由信息，也叫轉發路由實例(VRF)，例如在MPLS主干網上的流量在IP地址前都會添加一個全局唯一的路由標志符(Route Distinguisher, RD)形成唯一的VPN-IPv4地址來識別不同租戶的流量。PE路由器不應該交換全網所有租戶的路由，所以通過手工設定路由目標(Route Targe, RT)來設置從CE路由器向PE路由器導入導出哪些路由。只有所帶RT標記與VRF表中任意一個Import RT相符的路由才會被導入到VRF表中。RT使得PE路由器只包含和其直接相連的VPN的路由，而不是全網所有VPN的路由，從而節省了PE路由器的資源，提高了網絡拓展性。

控制平面，那么導入導出哪些路由完全可以由上層控制平面通過規則來設定，這種通過路由方式將虛機流量導流到底層IP隧道矩陣的做法天然將廣播隔離在了一個節點上，可以省略像Neutron DRV ARP responser特性。也可以天然地讓計算節點也具備三層功能隨意設置局域隔離的網關(fan, opencontrail都是這么干的)。這層還要做地址學習功能。

對于openflow來說，控制平面應該集中全局的VM, PORT, CONTROL, SWITCH的映射拓撲關系，這樣便可以計算給不同CONTROL上的不同SWITCH上的不同的PORT上的VM下發合適的流表(dragonflow就是這么干的)。還可以在邊緣出口路由器處運行Quagga等動態路由協議通過BGP或iBGP收集到動態路由結合ARP路由通過一些規則轉換成流表，如下列是RouteFlow的轉換規則：

Route =IP + MASK [Rede]+IP[Gateway]+Interface
ARP= IP[Host]+MAC[Host]+Interface

路由表轉換成流表：

Match: DST_MAC + DST_IP + SUBNET_MASK
Actions:
Re-Write [SRC_MAC (Interface)], Re-Write [DST_MAC (Nexthop)]
Forward [Port-out(Interface)]

在數據轉發平面方面的性能方面，可以采用用戶態協議棧，通過DPDK在用戶態直接操作硬件網卡，并且構建用戶態socket供上層調用。還可以引入Linux 4.x switchdev避免二層交換時引發CPU中斷從而為SR-IOV網卡提供交換加速功能。

所有SDN產品的大致思想都脫離不了上面的點。現在對照它，我們可以發現Neutron有很多不足之處：

理想網絡我感覺一是無限可伸縮同時適合大小規模部署的網絡拓撲，可以在一個局域網的多個跨三層的OpenStack云之間互聯，可以互聯跨廣域網的多個OpenStack云。我感覺第二點應該是在網絡拓撲之上的好的網絡服務。第三點應該是性能，每個網絡節點都應該同時具備至少第三層功能，干凈利索地解決東西南北流量問題。

先說nova-network, 它的multi-host功能可以讓每一個計算節點同時具備網絡三層功能，我們知道，一個子網是不能出現相同IP的網關的，而多個計算節點是可能出現相同子網的虛機的。所以對于multi-host而言對于同一個子網每一個計算節點上網關的IP都是不一樣的，這樣簡化了設計，但是問題是浪費了IP地址。

Neutron的DVR可以干同樣的事情，每一個計算節點上相同子網的網關都是相同的，但是通過流表來確保這個網關局部隔離。缺點是這種設計實現復雜度較高。

kubernetes則是事先假設每一個計算節點使用不重復的子網，這樣也就避免了計算節點上出現相同子網網關的問題，簡化了設計。

Neutron為二層提供了ML2插件來支持不同廠商的二層設備，在三層沒有提供插件只提供了一個L3-agent來支持三層設備，在四到七層提供了高級服務框架來支持不同的網絡服務。其缺點有：

北向API層做得太爛，如ACL，如QoS，如VPN等高級服務的API始終做不好或者因為有待商榷的代碼評審機制而發展滯后。

分得層數太多，尤其是將二層和三層分開了，這樣不利于讓所有節點同時具備三層功能。特別對于一些不分層的新興網絡技術如SDN是不適合的。二層和三層插件應該合并適應于SDN技術。

三層沒有插件，只有一個l3-agent。應該有插件結構，支持不同廠商的三層設備，特別是一些支持ACL的三層設備，支持跨廣域網的三層支持如MPLS VPN等.

四到七層的服務鏈功能做得不好，同時，它的API只適合傳統的基本iptables服務鏈插入模型，不適合SDN基于流表的服務模型。

SDN的本質是數據轉發平面與集中控制平面相分離，數據轉發這塊主要是基于新興的openflow流以及基于overlay隧道技術，但其技術本質也是一樣的。overlay會對二層數據幀進行自定義，我們可以隨心所欲地改寫，添加兩個包頭，一個是內部包頭對應虛機網段，一個是外部包頭對應管理網段，天然進行內外網的網絡地址轉換。overlay層只負責通過隧道進行數據轉發，另外，其隧道最好是支持segmention id的有利于租戶間的隔離。控制平面首先要是集中的，它會記錄網絡和租戶間的對應關系，通過提供一些規則容易通過上面控制底層的流量轉發，如虛機出來的流量如何進入隧道，如果是經過路由那可以通過路由將廣播只限制在一臺物理機上，也可以像VPN一樣針對每個用戶建立路由轉發實例，也可以像DVR一樣直接響應需機的ARP請求和地址學習等。

Ubuntu Fan網絡的思想和上述一致，問題在于fan網絡是flat的即隧道里還不支持segmention id 來隔離租戶網絡，另外Fan也沒有控制平面不能做規則設置。

opencontrail是我認識的最好的SDN，它忠實實現了上述思想，juniper的工程師們非常理解電信網絡，在電信世界，現在4G的每一個基站和其他基站都是兩兩互連的，也就是說基站和openstack里的計算節點一樣是需要3層功能的。fan實現的是IPIP隧道，opencontrail實現是mpls over udp/gre隧道可以天然地互聯廣域網的多個數據中心。另外，opencontrail的服務鏈功能做得非常完善，如深度包檢測(DPI)，入侵檢測(IDP)，入侵防護(IPS)，廣域網優化和負載均衡等。

Midonet也非常不錯，雖然每個計算節點不具備3層功能，但它支持VTEP和MPLS L2 Gateway功能，這樣同一tenant的不同子網間的東西向流量并不需要經過Provider Router(Neutron DVR解決的是相同子網的東西向流量不繞道l3-agent的情況), 只有跨tenant的東西向流量和南北流量才需要經過Provder Router。它和沒有DVR的neutron的拓撲看起來最像，但是它比l3-agent做得更好也支持BGP與ECMP支持等。另外，neutron是MQ+DB實現的，大量應用了消息，這可能成為性能瓶頸;而Midonet主要基于分布式數據庫技術。采用分布式數據庫NSDB來作集中的控制平面存儲port, node, mac等映射關系。這種搞法和基于openflow流表的SDN實現產品看起來更眼熟，如routeflow等。

Neutron的dragonflow也正在朝這方面努力， 它基于openflow流表同時支持網絡二三層，每個虛機出來的流量經過qvb接口進入br-int網橋后都會將seg_id設置到流規則里的metadata里，顯然，不同的子網就會有不同的seg_id, 再結合destination ip就可以判斷是L2還是L3流量。它和neutron的思想更近，可以代替DVR，比DVR的實現要簡單，復雜度要低，更重要的是，它消除了影響neutron性能的veth和namespace這些東西。總之，它非常好，我也非常看好。但問題是它目前還不成熟，目前，DragonFlow僅支持中心化的SNAT與DNAT，還不支持在計算節點上做SNAT與DNAT。

還有一個就是openvswitch的OVN項目，設想地都非常好，問題是現在只是1.0版本，太多的特性沒有實現。它將支持提供對L2/L3網絡虛擬化的支持(logical switches, distributed logical l3 processing, software and hardware gateway, in-kernel based security groups, and L2/L3/L4 ACLs, tunnel-based[VXLAN, NVGRE, Geneve, STT, IPSec])。