漫步雲中網絡，第 2 部分

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 架構圖。