http://www.ibm.com/developerworks/cn/cloud/library/1311_zhanghua_openstacknetwork2/index.html
作為《漫步雲中網絡》的姊妹篇，在它講述 L2-L3 層網絡技術原理的基礎之上，繼續向大家講述最新的 Neutron 背後所依賴的 L2-L7 層網絡技術内幕，特别是這些複雜的網絡技術的來龍去脈，盡量深入淺出地用淺顯易懂的語言從純技術角度切中這些技術的本質。幫您在進入研究 Neutron 細節之前就清楚知道 Neutron 是什麼、有什麼、為什麼有，這樣您在研究這些複雜網絡技術時始終清楚定位不緻于迷失方向。本文适合希望迅速了解 Neutron 全部特性的架構師，适合希望研究 Neutron 代碼的程式員以及希望運作 Neutron 的測試人員，也适合想了解基礎網絡内幕知識的讀者。
本文不會講解每一種網絡技術的細節，也不會講解 Neutron 網絡的實作細節，而是高度概括這些基礎網絡技術的技術本質，試圖幫您在這些網絡技術和 Neutron 之間建立更進階别的聯系，讓大家舉重若輕，全局系統把握 Neutron。是以閱讀本文前，了解以下知識将有助于本文的了解：
- 了解 OSI 七層模型，了解基本的 L2 層幀轉發、L3 層路由轉發等網絡基礎知識。
- 了解 Neutron 網絡或者其他任何雲網絡也将有助于本文的了解。
Neutron 是什麼?
一句話描述，Neutron 是 OpenStack 的一個子子產品，它的實質是一個定義良好的架構用來驅動 L2-L7 層不同的底層網絡技術來為第三方應用獨立地提供租戶隔離的虛拟網絡服務。
上面的定義隻是筆者對 Neutron 長期以來一個最直覺的感受，仁者見仁，智者見智，相信您在讀完本文後，對于“Neutron 是什麼”這個問題會有自己的看法。
筆者之前在 developworks 上曾發表過一篇文章，《漫步雲中網絡》，在那篇文章中，筆者也沒有直接具體講 Quantum HOWTO 的問題(目前 Quantum 因為與一家公司重名，是以已更名為 Neturon），而是描述了 Qauntum 網絡背後的一般原理，讀者至少可以從那篇文章擷取如下知識：
- 知道 Linux 下實作虛拟網卡一般使用 TAP/TUN 技術。一個 TAP 裝置就是 Linux 下的一個程序，兩個虛機通過虛拟網卡的通信，實際上就是 Linux 中兩個程序間的通信。是以很多 Hypervisor 為了提升同一實體機中的兩台虛機之間的網絡 IO 性能采用 DMA（直接記憶體通路）技術也就毫不奇怪了。
- 知道在 L2 層，Linux 網橋是虛拟交換機的一種實作，知道無論是虛拟交換機還是實體交換機，原理都是一樣的。知道 L2 層用于使用 VLAN 來做實體隔離。知道 FLAT 網絡和 VLAN 網絡的根本差別。
- 知道在 L3 層如何通過 ipv4 forward 功能進行靜态路由轉發，知道如何使用 iptables 的 SNAT 和 DNAT 規則實作内網中的虛機通路外網和外網通路内網上的虛機（也就是所謂的浮動 IP）。
在我寫第一季的時候，Quantum 隻實作了 L2，L3 兩層，是以在《漫步雲中網絡》一文也就隻涉及了 L2、L3 兩層背後的網絡原理知識。但是現在 Neutron 在 L2 和 L3 層上實作了更多的網絡技術，同時在 L4-L7 層也有更多的動作，是以有必要出第二季對整個 L2-L7 層的網絡進行一個全面的疏理。本季中也會概括 L2、L3 的理論知識，但不會像第一季中那麼詳細，大家也可以結合第一季進行學習。是以，本文的主要内容有:
- L2 層：交換機的原理；為什麼會出現 VLAN；Neutron 中 FLAT 與 VLAN 的差別；
- L3 層：Linux 上實作靜态路由的技術（namespace + ipv4 forward + iptables）；動态路由；Neutron 用 L3 層的 GRE 遂道技術克服 VLAN 大小的限制；
- 利用 L3 層擴充 L2 層的遂道技術：VXLAN; NVGRE;
- 利用 L2 層擴充 L3 層的标簽技術：MPLS；
- 差別于傳統路由轉發的流轉發技術：OpenFlow 以及 SDN 的實質；
- L4－L7 層：如 LBaaS；FWaaS; VPNaaS; NATaaS
回頁首
OSI 七層模型
提到網絡不得不提到 OSI 七層模型，從上到下，OSI 分為七層：
- L7，應用層
- L6，表示層
- L5，會話層
- L4，運輸層
- L3，網絡層
- L2，資料鍊路層
- L1，實體層
對于 OSI 七層模型至少得知道下列常識：
- L2 層主要通過 MAC 位址進行幀轉發
- L3 層主要通過 IP 位址進行包轉發
- L4 層再結合端口 PORT 來唯一标志一個應用程式
- 協定是通信雙方對資料的一個了解，例如在 L7 層有我們常用的協定 HTTP 協定，在 HTTP 協定上傳輸的是通信雙方都了解的 HTML 資料；在 L4 層有兩大重要協定，無連接配接的 UDP 和面向連接配接的 TCP。可靠傳輸可以通過 TCP 協定來實作，對于下面的 L2，L3 層并不需要實作可靠傳輸機制，像 L2 層，傳輸資料幀的過程中出了錯誤簡單丢棄就行，上層的 TCP 自然會控制它重傳。socket 不是協定，隻是 L4 層傳輸資料的一個接口定義。
- 當網卡接收到資料之後，硬體網卡會給 CPU 發中斷，CPU 在指令周期内訓示作業系統軟體從網卡緩沖區取走資料，然後作業系統将資料交給 TCP/IP 棧來處理，到了 L2 層，解析 L2 層資料幀頭中的 MAC 位址來決定 L2 中的轉發，如需 3 層轉發就交給上面的 L3 層解析出資料標頭中的 IP 位址來決定 L3 中的轉發，依此類推。
回頁首
L1
L1 是實體層，主要是涉及硬體的一些電氣特性，與偏軟體的 Neutron 虛拟網絡從知識脈絡上關系甚少，不展開。
回頁首
L2
FLAT
L2 資料鍊路層通過交換機裝置進行幀轉發。交換機在接收到幀之後(L2 層叫幀，L3 層叫包)先解析出幀頭中的 MAC 位址，再在轉發表中查找是否有對應 MAC 位址的端口，有的話就從相應端口轉發出去。沒有，就洪泛（專業術語，即将幀轉發到交換機的所有端口），每個端口上的計算機都檢查幀頭中的 MAC 位址是否與本機網卡的 MAC 位址一緻，一緻的話就接收資料幀，不一緻就直接丢棄。而轉發表是通過自學習自動建立的。
這裡引出一個重要概念，混雜模式。預設情況下計算機隻接收和本機 MAC 位址一緻的資料幀，不一緻就丢棄，如果要求計算機接受所有幀的話，就要設定網卡為混雜模式（ifconfig eth0 0.0.0.0 promisc up)。是以在虛拟網橋中，如果希望虛機和外部通訊，必須打開橋接到虛拟網橋中實體網卡的混雜模式特性。
VLAN
FLAT 中的洪泛，經常會在一個區域網路内産生大量的廣播，這也就是所謂的“廣播風暴”。為了隔離廣播風暴，引入了 VLAN 的概念。即為交換機的每一個端口設定一個 1-4094 的數字，交換機根據 MAC 位址進行轉發的同時也要結合 VLAN 号這個數字，不同的話也要丢棄。這樣就實作了 L2 層資料幀的實體隔離，避免了廣播風暴。
在 Neutron 中，我們知道，截止到筆者寫這篇文章之時已經實作了 FLAT、VLAN、GRE、VXLAN 四種網絡拓撲。那麼如何區分 FLAT 和 VLAN 呢？很簡單，結合 VLAN 号和 MAC 位址進行轉發的是 VLAN 模式，隻根據 MAC 位址進行轉發的是 FLAT 模式。
VLAN 的缺點與大 L2 層技術
實際上，遂道技術并不能完全歸類于 L2 層。因為有基于 L2 層的遂道協定，例如 PPTP 和 L2TP 等；也有基于 L3 層的遂道，如 GRE、VXLAN、NVGRE 等；但是這些遂道從技術原理上講差不多，是以筆者将這些技術作為“大 L2 層”放在一塊來描述，但希望讀者不要誤解。
本文隻将着重講 Neutron 中用到的 GRE 和 VXLAN 技術。
L3 層的 GRE 遂道
VLAN 技術能有效隔離廣播域，但同時有很多缺點：
- 要求穿越的所有實體交換機都配置允許帶有某個 VLAN 号的資料幀通過，因為實體交換機通常隻提供 CLI 指令，不提供遠端接口可程式設計調用，是以都需要手工配置它，容易出錯且工作量巨大，純粹的體力勞動，影響了大規模部署。
- VLAN 号隻能是 1－4094 中的一個數字，對于小規模的私有雲可能不是個問題，但對于租戶衆多的公有雲，可選擇的 VLAN 号的範圍是不是少了點呢？
為了克服上面的缺點，Neutron 開發了對 GRE 模式的支援。GRE 是 L3 層的遂道技術，本質是在遂道的兩端的 L4 層建立 UDP 連接配接傳輸重新包裝的 L3 層標頭，在目的地再取出包裝後的標頭進行解析。因為直接在遂道兩端建立 UDP 連接配接，是以不需要在遂道兩端路徑的實體交換機上配置 TRUNK 的操作。
說說 GRE 的缺點吧：
- GRE 将 L2 層的操作上移到 L3 層來做，性能肯定是會下降的。同時，由于遂道隻能是點對點的，是以可以想象，如果有 N 個節點，就會有 N*(N-1)條 GRE 遂道，對于寶貴的 L4 層的端口資源也是一個浪費哦。那也是為什麼 GRE 遂道使用 UDP 而不使用 TCP 的原因了，因為 UDP 用完後就可以釋放，不用老占着端口又不用。
- 在 Neutron 的 GRE 實作中，即使兩台實體機上的兩台虛機也不是直接建立 GRE 遂道的。而是通過 L3-agent 網絡節點進行中轉，這樣做是基于友善使用 iptables 隔離網絡流量的考慮。
利用 L3 層擴充 L2 層的遂道技術 VXLAN 與 SDN 的本質
VXLAN 是 VMware 的技術，可以克服 VLAN 号不足的問題；同時也可以克服 GRE 實質上作為點對點遂道擴充性太差的問題。
如果說 GRE 的本質是将 L3 層的資料標頭重新定義後再通過 L4 層的 UDP 進行傳輸，那麼 VXLAN 的本質就是對 L2 層的資料幀頭重新定義再通過 L4 層的 UDP 進行傳輸。也就是筆者說的所謂的利用 L3 層擴充 L2 層.
既然 L2 層的資料幀頭要重新定義，那就随便定義啦，是否滿足以下三點是筆者從技術角度将一件産是否視為 SDN 的關鍵因素：
- 可将 L7 層租戶 tenant 的概念做到 L2 層。在筆者的前一篇《漫步雲中網絡》姊妹篇中已經介紹了 IaaS 雲的本質就是賣虛機，即将虛機租給多租戶使用後收費。是以位于 L7 應用層的 tenant 的概念是雲用來對計算、存儲、網絡資源進行隔離的重要概念。那麼将 tenant 的概念從 L7 層下移到 L2 層中意義重大。
- 也可将類似 VLAN 的概念做到 L2 層，并且由于是軟體定義的（不像實體交換機那樣受硬體限制），那麼很容易突破 VLAN 号在 1－4094 之間的限制。
- 是否提供集中式的控制器對外提供北向 API 供第三方調用來動态改變網絡拓撲。
清楚了 SDN 的本質，那麼 VXLAN 的本質又是什麼呢？
- VXLAN 是一種 L2 層幀頭的重新封裝的資料格式。
- VXLAN 仍然使用 GRE 遂道通過 UDP 傳輸重新封裝幀頭後的資料幀。
VXLAN 重新定義的 L2 層幀頭格式如下圖 1 所示，其中 VNI VXLAN ID 與 VLAN 的從概念上等同，但是因為它是用軟體實作的，範圍可用 24 bits 來表示，這就比 VLAN 的 1－4094 大多了。
圖 1. VXLAN 幀頭格式
因為 VXLAN 通過重新定義 L2 層幀頭（相當于通過 MAC 位址進行 NAT 的方案）進而讓兩個跨 L3 層的甚至廣域網内的兩個子網從 L2 層上互通。是以 VXLAN 的優點很多，能讓遺留子網不改變 IP 位址的情況下無縫的遷移到雲上來；也可以讓虛機跨資料中心進行遷移（以前頂多隻能在同一個 VLAN 裡遷移）。
當然，VXLAN 也不是沒有缺點的，通過上面的學習，大家已經知道 VXLAN 也是通過 GRE 走 UDP 來傳輸重定義的标準化的 VXLAN 封裝格式的幀頭的。由于在遂道的兩端之間直接建立遂道，那麼它是無法與途經的一些實體裝置（如 DHCP 伺服器）通信的，那麼就需要 VXLAN 網關這種實體裝置在遂道的中途截獲 VXLAN 資料包（網關網關嘛，就是進行資料截獲再轉換的），解析裡面的資料，然後做一些事情（像流量統計，DHCP 資訊等等），最後再将資料重新打成 VXLAN 資料包交給遂道繼續傳輸。可以想象，在所有需要與實體裝置打交道的地方都是需要 VXLAN 網關的。覺得麻煩了嗎？
利用 L2 層擴充 L3 層的标簽技術 MPLS
VLAN 是一種标簽技術，VLAN 一般用在區域網路的交換機上，标簽很容易在 L2 層通過硬體來實作轉發。
MPLS 也是一種标簽技術，原理類似于 VLAN，但一般用在 WAN 上的路由器上，下面我們說道說道。
對于 L3 層的傳統路由轉發來說一般是在路由表裡查找相應的路由來實作。因為路由嘛，不同的 CIDR 之間可長可短，如 10.0.0.0/8 與 10.0.100.0/24 這兩個子網首先長度不一樣，其次 CIDR 号一個是 8，一個是 24，在路由器中，是通過字元串的按最長比對算法來比對路由的，那麼應該選擇 10.0.100.0/24 這個路由。字元串的按最長比對算法很難通過硬體來實作，通過軟體速度慢啊。那麼廣域網的路由器能不能也引入标簽通過硬體轉發的優點，在路由器作轉發時，不再在 L3 層的通過軟體去查找路由來實作轉發，而是直接在 L2 層就通過标簽通過硬體轉發了呢？答案就是 MPLS。
例如 A 路由器通過 B 路由器給 C 路由器發包時，傳統的路由器是根據目的位址進行轉發，A 在開始轉發時，并不知道去 C 的完整路由，它隻知道轉給 B，B 再決定轉給 C，這種走一步看一步的叫基于目的位址的路由轉發。但是 MPLS 的原理完全不同，A 在給 C 發包時，先發個 HELLO 包從 A 到 C 走一遍，在走的過程中就已經知道了 A 到 C 的路由路徑并且根據 LDP（标簽分發協定）将 A 到 C 的标簽序列就事先确定好了。那樣 A 再給 C 發資料時，A 就提前知道了在 L2 層怎麼根據标簽來轉發，是以它不用再到 L3 層查找路由資訊了，另外它在 L2 層通過标簽轉發可以很容易通過硬體來實作，這樣速度更快了，最後标簽的确定是通過 LDP 協定動态配置設定的這也避免了像 VLAN 的那種标簽需要手工去設定的麻煩。
回頁首
SDN
在 VXLAN 一節中，筆者已經說過了筆者判斷一個産品是否是 SDN 産品的核心判斷因素，即是否将 tenant 租戶的概念做到了 L2 層并且提供了北向 API 供第三方應用調用動态調整網絡拓撲。做到了，就是 SDN 産品。目前，SDN 産品主要有三類：
- 基于 Overlay 技術的，如 VMware 的 VxLAN，如 Microsoft 的 NVGRE，如 IBM 的 Dove
- 基于 OpenFlow 技術的
- 基于專有技術的，如 Cisco 的 onePK
基于 Overlay 技術的 VxLAN 已經在上面介紹過了，這裡着重介紹一下 OpenFlow 和 Dove。
OpenFlow
OpenFlow 是完全不同于傳統網絡技術的新興網絡技術。
傳統交換機能通過自主學習建立轉發表，然後根據轉發表轉發。但對于 OpenFlow 交換機，它是很“笨”的，資料幀來了它并不知道往哪個端口轉發，不知道怎麼辦呢？不懂就問呗，找 OpenFlow 控制器問。控制器通過一定算法告訴它往哪個端口轉發，然後 OpenFlow 交換機照着做就行了。下圖 2 顯示了 OpenFlow 的結構：
圖 2. OpenFlow 的結構
我并沒有将 OpenFlow 歸于 L2 層，因為從理論上講，它并不嚴格屬于 L2 層，因為它設計了 L2－L4 層的轉發項進行轉發。現在 OpenFlow 的 FIB（轉發資訊表，Forward Info Base）中至少有下列條目：
- L2 層的 MAC、VLAN 等
- L3 層的 source ip, dest ip
- L4 層的 source port, dest port
- 甚至有基于 WAN 的動态路由的轉發項，如 BGP、MPLS 等
OpenFlow 進行轉發的時候和傳統的網絡技術不一樣，傳統的是存儲包轉發（資料到了 L2 層就解析出 MAC 位址進行轉發，到了 L3 層後就解析出 IP 位址進行轉發）。而 OpenFlow 則根據所謂的流進行轉發。它将上面的 MAC、VLAN, source ip, dest ip, source port, dest port 等視作平等的平面，直接通過某個高效的字元串比對算法比對到了後再做某些動作，如 accept 或者 drop 掉。
再聊聊筆者所了解的 OpenFlow 的缺點。理論上，如果 OpenFlow 通過 L3 層的 IP 進行轉發的話，那它就成了一個路由器了。但實際上，目前，OpenFlow 主要還是用在 L2 層當做一個交換機來使用的。如果真要在 L3 層和路由結合的話，那麼它将以怎麼樣的方式和現存的分布式的動态路由協定（如 RIP、OSPF、BGP、MPLS）協作呢？ 并且傳統的 WAN 本來為了可靠就是以分布式來設計的，現在搞成 OpenFlow 式的集中式控制，監控什麼的是友善了，但一旦控制器挂了那麼整個網絡也全挂了，并且 OpenFlow 控制器一旦被某方勢力所掌握，那麼整個 OpenFlow 網絡也就全被掌握了，畢竟 WAN 是要考慮這些因素的。是以筆者不認為 OpenFlow 這種集中式控制的路由器能在 WAN 上将取代傳統分布式的路由協定，頂多在 LAN 的 L2 層會有一些作為吧。
Dove/OpenDaylight
上面已經說到 SDN 需要對外提供北向 API 供第三方調用。
對于控制器與交換機之間的南向 API 的通訊标準就是由 google, facebook 這些使用者主導定制的 OpenFlow 協定。
北向 API 沒有标準，南向 API 也五花八門，将 tenant 和 VLAN 的概念做到 SDN 裡也沒有标準（雖然有 VMware 主導了一個 VXLAN 的資料封裝格式），是以業界存在很多 SDN 的産品，Dove 便是由 IBM 實作的其中一種，OpenDaylight 的插件結構可以同時和衆多的 SDN 控制器打交道，降低第三方應用同時和衆多 SDN 控制器打交道的複雜性。
回頁首
L3
L3 層的路由分靜态路由和動态路由兩種：
- 在 Linux 中，通過打開 ipv4 forward 特性可以讓資料包從一塊網卡路由到另外一塊網卡上。
- 動态路由，如内部網關協定 RIP，OSPF；如外部網關協定 BGP。能夠自動地學習建立路由表。
目前 Neutron 隻支援靜态路由，要點如下：
- 對于不同 tenant 子網通過 namespace 功能進行隔離，在 Linux 中，一個命名空間 namespace 您可以簡單了解成 linux 又啟動了一個新的 TCP/IP 棧的程序。多個 tenant 意味着多個 namespace，也意味着多個 TCP/IP 棧。
- 對于同一 tenant 中的不同子網的隔離通過 iptables 來做，也意味着，同一 tenant 中的相同子網的兩個虛機不用走 L3 層，直接走 L2 層能通，沒問題；但如果同一 tenant 中的不同子網的兩個虛機要通訊的話，必須得繞道 L3-agent 網絡節點，這是影響性能的。
回頁首
L4-L7
LBaaS
OpenStack 最初的目标是做 x86 平台下的開源 IaaS 雲，但它目前也有了類似于 LBaaS (Load Balance as a Service)這樣本屬于 SaaS 的特性。
LbaaS 服務可以為一個 tenant 下的多台虛機提供負載均衡服務，要點如下：
- 提供負載均衡的虛機之間組成一個服務組
- 虛機之間提供心跳檢查
- 外部通過 VIP 來通路 LB 服務組提供的服務，動态地将 VIP 根據負載均衡政策綁定到具體提供服務虛機的 fixed ip 上
下圖 3 顯示了 LBaaS 應用的幾種情形：
圖 3. LBaaS 的應用場景
說明如下：
- 有兩個虛機 192.168.0.3 和 192.168.0.1 組成負載均衡池，它們之間做心跳
- 如果這個 LB 服務隻用在内網，可以隻為虛機提供一個内部的 vip，如 192.168.0.4
- 如果這個 LB 服務也需要從外部通路，那麼這個 vip 可以做成 floating ip，如 10.1.1.10
是以實作上述 LB 服務的 neutron 指令如下：
清單 1. 實作例子 LB 服務的 neutron 指令
neurton lb-pool-create --lb-method ROUND_ROBIN --name mypool --protocol HTTP --subnet-id <subnet-id>
neurton lb-member-create --address 192.168.0.3 --protocol-port 80 mypool
neurton lb-member-create --address 192.168.0.1 --protocol-port 80 mypool
neurton lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3
neurton lb-healthmonitor-associate <lb-healthomonitor-id> mypool
neurton lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-id> mypool
neurton lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-id> mypool
neurton floatingip-create public
neurton floatingip-associate <floating-ip-id> <lb-vip-port-id> FwaaS
目前，Neutron 已經實作了一個 Security Group 服務，FWaaS 服務正在開發中。 FwaaS 和 Security Group 的原理差不多，隻不過代碼重構将以前 Security Group 的代碼挪到了現有的 L4/L7 層架構來了；這樣，以前 Security Group 作為 nova-compute 的一個元件隻能運作在計算節點上，單純拆出來做為一個獨立程序之後也可以部署在 l3-agent 的那個實體機上提供邊緣防火牆特性。下圖 4 顯示了 Security Group 服務的原理圖：
圖 4. Security Group 原理圖
Security Group 由一系列的 iptables rule 組成
- 這些 iptables rule 運作在計算節點上
- 可以控制從虛機出去的流量
- 可以控制進來虛機的流量
- 可以控制虛機之間的流量
實施 Security Group 的步驟如下，例如，四個虛機，可以從 80 端口通路 web 虛機，從 web 虛機上可以通路 database 虛機，ssh 跳轉虛機上可以同時通路 database 和 web 虛機，可以通過端口 22 通路 ssh 虛機。
清單2. 實施Security Group 的步驟
neutron security-group-create web
neutron security-group-create database
neutron security-group-create ssh
neutron security-group-rule-create --direction ingress --protocol TCP \
--port-range-min 80 --port-range-max 80 web
neutron security-group-rule-create --direction ingress --protocol TCP \
--port-range-min 3306 --port-range-max 3306 --remote-group-id web database
neutron security-group-rule-create --direction ingress --protocol TCP \
--port-range-min 22 --port-range-max 22 --remote-group-id ssh database
neutron security-group-rule-create --direction ingress --protocol TCP \
--port-range-min 22 --port-range-max 22 --remote-group-id ssh web
neutron security-group-rule-create --direction ingress --protocol tcp \
--port-range-min 22 --port-range-max 22 ssh VPNaaS
我們仍然從技術的本質角度出發來解釋什麼是 VPN。VPN 類似于 GRE，也是一種遂道。但是不同的是 VPN 也要求不同的使用者可以使用相同的子網，是以在每個建立 VPN 的兩個端點所對應的邊緣路由器上都會為每個使用者建立它自己的 VPN 路由執行個體 VRF，白話一點的話，VRF 就是 Linux 裡上面提到過的 namespace 的概念。
建立 GRE 遂道容易，但是 VPN 強調私密性，一個組織的 VPN 總不希望不經授權的通路吧。是以一般使用 SSL 或者 IPSec 結合 GRE 來建立 VPN。也可以通過 MPLS 來建立 VPN。Neutron 中這三類 VPN 目前均在開發之中。從下面 MPLS VPN 的 blueprint 中的圖 5 可以看到将來要實作的樣子：
圖 5. MPLS VPN 實作原理圖
目前，l3-agent 沒有使用動态路由，使用的是 namespace + ipv4 forward + iptables 的靜态路由技術。l3-agent 現在充當着 CE 的角色（Custum Edge)。我們設想一下，筆者認為 BGPMpls Driver 将來至少要實作下列幾個方面的内容：
- 調用 PE API 在邊緣路由器 PE 上通過 namespace 特性定義并配置 tenant 之間隔離的自己的 VPN 路由執行個體 VRF
- tenant 定義的 VRF 路由并不需要在每個 WAN 核心路由上都存在，是以可以通過配置輸入和輸出政策實作，即使用 router-target import/export 指令導入或導出相應的 VRF 條目
- 配置 PE 到 CE 的鍊路
- 将 CE 的接口關聯到預先定義的 VRF
回頁首
Neutron 有什麼?
Neutron 就是一個定義良好的插件架構，用來調用上述 L2-L7 層不同實作，且對外提供北向 API 來提供虛拟網絡服務。
它自己提供了 tenant 的概念，它隻是一個 SDN 架構，和底層的 SDN 軟體如 Dove 內建時可以提供 SDN 的功能，但需要将它的 tenant 和 SDN 自身的 tenant 概念之間做一個映射。
L2
在 L2 層，由虛拟交換機來實作。虛拟交換機有下列這些種：
- Linux 網橋，基于 Linux 核心的網橋。需要說明的是，網橋就是交換機，是交換機的一種常用的書面叫法。
- OpenvSwitch（OVS）：OVS 有兩種模式，一種是當普通的虛拟交換機來使用，另一個是和 OpenFlow 控制器協作當作 OpenFlow 控制器來使用。
- 一些基于 Overlay 技術的 SDN 實作，如 Dove 等。
- 一些非開源的商業交換機。
目前，Neutron 已經實作的 L2 層插件如下圖 6 所示，linuxbridge 實作了 Linux 網橋，openvswitch 插件實作了 openvswitch 網橋，bigswitch 插件實作了一種 SDN 控制器，ml2 是一種通用的插件（這些 L2 層的插件主要分寫資料庫的 plugin 部分和運作在計算節點的 agent 部分，plugin 寫資料庫的字段有差異但不多，是以代碼重複，ml2 可以了解為一個公共的 plugin）。且每種插件基本上實作了 FLAT, VLAN, VXLAN, GRE 等四種拓撲。
圖 6. Neutron 中 L2 層插件
L3
Neutron 的 L3 層由基于 namespace ipv4 forward + iptables 實作。
需要啟動 l3-agent 程序，如果需要 DHCP 服務的話也需要啟動 dhcp-agent 程序。
L4-L7
LBaaS 基于 Haproxy 實作；FWaaS 基于 iptables 實作；VPNaaS 有基于 IPSec 的 VPN 實作，也有基于 MPLS 的 VPN 實作，也有基于 SSL 的 VPN 實作。
截止到筆者寫此文為止，目前隻有 LBaaS 能用，其他的 FWaaS, VPNaaS 和 NATaaS 仍在開發中。但對于 FWaaS 有 Security Group 功能可用，差別在于前者由于作為獨立服務也能部署在網絡節點上提供邊緣防火牆特性，後者依然能夠在計算節點上使用 iptables 規則控制從虛機出去的，進來虛機的，虛機之間的流量。
回頁首
結論
本文在《漫步雲中網絡》姊妹篇講述 L2-L3 網絡原理的基礎上，繼續講述了最新的 Neutron 代碼背後 L2-L7 層所依賴的網絡技術内幕，讓讀者能夠在心中建立起一個 High Level 的完整的 Neutron 架構圖。