目錄

• 相關概念
• • 一、Neutron網絡項目
  • 二、Linux虛擬網絡
  • 三、openstack網絡基礎服務
  • • 1、Neutron網絡結構
    • 2、網絡子網和端口
    • 3、網絡拓撲類型
    • 4、網絡基本架構
    • 5、Neutron-server
  • 四、Neutron主要插件、代理和服務
  • • 1、典型的主機節點部署
    • 2、ML2插件
    • 3、Linux Bridge代理
    • 4、Open vSwitch代理
    • 5、DHCP代理
    • 6、Linux網絡名稱空間（租戶）
    • 7、Neutron路由器
    • 8、L3代理
    • • （1）路由（routing）
      • （2）通過網絡名稱空間支持網絡重疊
      • （3）源地址轉換（SNAT）
      • （4）目的地址轉換（DNAT)
      • （5）安全組（Security Group）
    • 9、FWaas(虛擬防火墻)
  • 五、Neutron網絡配置和管理
  • • 1、提供者網絡
    • 2、自服務網絡

相關概念

一、Neutron網絡項目

• Neutron是openstack核心項目之一，提供云計算環境下的虛擬網絡功能。
• Neutron為整個openstack環境提供軟件定義網絡支持
  • 主要功能包括二層交換、三層路由、防火墻、VPN, 以及負載均衡等。
• Neutron在由其他openstack服務 (如nova)管理的網絡接口設備 (如虛擬網卡)之間提供網絡連接即服務。

二、Linux虛擬網絡

linux網絡虛擬化
Neutron最核心的任務：對二層物理網絡進行抽象和管理

傳統物理網絡與虛擬化網絡的區別

• 傳統物理網絡
  • 使用多個物理服務器
  • 使用物理網絡設置
• 虛擬化網絡
  • 將多個虛擬機部署在一臺物理服務器，減少了物理服務器的數量
    • 虛擬機由虛擬機管理器(Hypervisor)統一管理
    • 在Linux系統中Hypervisor通常采用kvm。
  • 網絡虛擬化，減少了物理網絡設置的數量
    • Hypervisor為虛擬機創建一個或多個虛擬網卡(vNIC)，虛擬網卡等同于虛擬機的物理網卡。
    • 物理交換機在虛擬網絡中被虛擬為虛擬交換機(vSwitch)
    • 虛擬機的虛擬網卡連接到虛擬交換機上，虛擬機交換機再通過物理主機的物理網卡連接到外部網絡。
• 對于物理網絡來說,虛擬化的主要工作是對網卡和交換設備的虛擬化。

網絡虛擬化中幾個關鍵的組件

• 虛擬網橋（即虛擬交換機）
  • 網橋接口連著虛擬網卡，網橋接口名稱通常以vnet開頭；
    • 例：虛擬網卡1連接vnet0，虛擬網卡2連接vnet1，虛擬網卡3連接vnet2
  • 網橋接口連著虛擬網橋，虛擬網橋以br開頭；
    • 例如vnet0和vnet1連接br1，vnet2連接br2
  • 虛擬網橋分別連著物理主機的物理網卡；
    • 例如br1連接物理網卡1，br2連著物理網卡2
• 虛擬局域網（即vlan）
  • 防止廣播風暴的產生
  • 劃分VLAN區域，一個VLAN含有多臺虛擬機，一個VLAN的虛擬機相當于連接同一網橋
  • 虛擬化環境中，會將網橋劃分到不同的VLAN中
  • VLAN的協議是802.1Q
• 開放虛擬交換機（open vSwitch）
  • 和硬件交換機擁有一樣的特性，可以在不同虛擬平臺上移植
  • 在虛擬交換機上使用open vSwitch技術，可以使虛擬網絡的管理、網絡狀態和流量的監控更加的輕松
  • 可以在云環境中的虛擬化平臺上實現分布式虛擬交換機
  • 也可以將不同主機上的open vSwitch交換機連接起來，形成一個大規模的虛擬網絡

三、openstack網絡基礎服務

OpenStack網絡服務提供一個API讓用戶在云中建立和定義網絡連接。該網絡服務的項目名稱是Neutron。OpenStack網絡負責創建和管理虛擬網絡基礎架構，包括網絡、交換機、子網和路由器，這些設備由OpenStack計算服務Nova管理。同時，網絡服務還提供防火墻和VPN這樣的高級服務。可以將網絡服務部署到特定主機上。OpenStack網絡組件與身份服務、計算服務和儀表板等多個OpenStack組件進行整合

1、Neutron網絡結構

一個簡化的典型的Neutron網絡結構，包括一個外部網絡、一個內部網絡和一個路由器。

• 外部網絡：負責連接OpenStack項目之外的網絡環境，又稱公共網絡。
  • 與其他網絡不同，它不僅僅是一個虛擬網絡，更重要的是，它表示OpenStack網絡能被外部物理網絡接入并訪問。
  • 外部網絡可能是企業的局域網(Intranet)，也可能是互聯網(Internet) ，這類網絡并不是由Neutron直接管理。
• 內部網絡：完全由軟件定義，又稱私有網絡。
  • 它是虛擬機實例所在的網絡，能夠直接連接到虛擬機。
  • 項目用戶可以創建自己的內部網絡。
  • 默認情況下，項目之間的內部網絡是相互隔離的，不能共享。
  • 該網絡由Neutron直接配置與管理。
• 路由器：用于將內部網絡與外部網絡連接起來，因此，要使虛擬機訪問外部網絡，必須創建一個路由器。

Neutron需要實現的主要是內部網絡和路由器。內部網絡是對二層(L2)網絡的抽象，模擬物理網絡的二層局域網，對于項目來說，它是私有的。路由器則是對三層(L3)網絡的抽象，模擬物理路由器，為用戶提供路由、NAT等服務。

2、網絡子網和端口

• 網絡：一個隔離的二層廣播域，類似交換機中的VLAN。
  • Neutron支持多種類型的網絡， 如FLAT、VLAN、VXLAN等。
• 子網：一個IPV4或者IPV6的地址段及其相關配置狀態。
  • 虛擬機實例的IP地址從子網中分配。
  • 每個子網需要定義IP地址的范圍和掩碼(這個有點像DHCP中定義的作用域的概念)。
• 端口：連接設備的連接點，類似虛擬交換機上的一個網絡端口。
  • 端口定義了MAC地址和IP地址，當虛擬機的虛擬網卡綁定到端口時，端口會將MAC和IP分配給該虛擬網卡。

通常可以創建和配置網絡、子網和端口來為項目搭建虛擬網絡。網絡必須屬于某個項目，一個項目中可以創建多個網絡。一個子網只能屬于某個網絡，一個網絡可以有多個子網。一個端口必須屬于某個子網，一個子網可以有多個端口。

3、網絡拓撲類型

• Local
  • Local網絡與其他網絡和節點隔離。
  • 該網絡中的虛擬機實例只能與位于同一節點上同一網絡的虛擬機實例通信，實際意義不大，主要用于測試環境。
  • 位于同一Local網絡的實例之間可以通信，位于不同Local網絡的示例之間無法通信。
  • 一個Local網絡只能位于同一個物理節點上，無法跨節點部署。
• Flat
  • Flat是一種簡單的扁平網絡拓撲，所有的虛擬機實例都連接在同一網絡中，能與位于同一網絡的實例進行通信，并且可以跨多個節點。
  • 這種網絡不使用VLAN，沒有對數據包打VLAN標簽，無法進行網絡隔離。
  • Flat是基于不使用VLAN的物理網絡實施的虛擬網絡。
  • 每個物理網絡最多只能實現一個虛擬網絡。
• VLAN
  • VLAN是支持802.1q協議的虛擬局域網，使用VLAN標簽標記數據包，實現網絡隔離。
  • 同一VLAN網絡中的實例可以通信，不同VLAN網絡中的實例只能通過路由器來通信。
  • VLAN網絡可以跨節點。
• VXLAN
  • VXLAN (虛擬擴展局域網)可以看作是VLAN的一種擴展，相比于VLAN，它有更大的擴展性和靈活性，是目前支持大規模多租房網絡環境的解決方案。
  • 由于VLAN包頭部限長是12位， 導致VLAN的數量限制是4096 (2¹²) 個，不能滿足網絡空間日益增長的需求。
  • 目前VXLAN的封包頭部有24位用作VXLAN標識符(VNID)來區分VXLAN網段，最多可以支持16777216 (2²⁴) 個網段。
  • VXLAN使用STP防止環路，導致一半的網絡路徑被阻斷。
  • VXLAN的數據包是封裝到UDP通過三層傳輸和轉發的，可以完整地利用三層路由，能克服VLAN和物理網絡基礎設施的限制，更好地利用已有的網絡路徑。
• GRE
  • GRE (通用路由封裝)是用一種網絡層協議去封裝另一種網絡層協議的隧道技術。
  • GRE的隧道由兩端的源IP地址和目的IP地址定義，它允許用戶使用IP封裝IP等協議，并支持全部的路由協議。
  • 在OpenStack環境中使用GRE意味著"IP over IP”，GRE與VXLAN的主要區別在于，它是使用IP包而非UDP進行封裝的。
• GENEVE
  • GENEVE(通用網絡虛擬封裝)的目標宣稱是僅定義封裝數據格式，盡可能實現數據格式的彈性和擴展性。
  • GENEVE封裝的包通過標準的網絡設備傳送，即通過單播或多播尋址，包從一個隧道端點傳送到另一個或多個隧道端點。
  • GENEVE幀格式由一個封裝在IPV4或IPV6的UDP里的簡化的隧道頭部組成。
  • GENEVE推出的主要目的是為了解決封裝時添加的元數據信息問題(到底多少位，怎么用GENEVE自動識別與調整) ，以適應各種虛擬化場景。

小結：
隨著目前互聯網技術的發展，對于網絡部分，使用虛擬化的方案，實現對傳統網絡（承載網絡，Underlay）的擴展，利用疊加網絡（Overlay ）的方式，常用的疊加網絡VXLAN、GRE和GENEVE。
Overlay網絡無須對基礎網絡進行大規模修改，不用關心這些底層實現，是實現云網融合的關鍵。

4、網絡基本架構

• Neutron僅有一個主要服務進程neutron-server。
  • 它是運行在控制節點上的，對外提供Openstack網絡API作為訪問Neutron的入口，收到請求后調用插件進行處理，最終由計算節點和網絡節點上的各種代理完成請求。
• 網絡提供者是指提供OpenStack網絡服務的虛擬或物理網絡設備
  • 如Linux Bridge、Open vSwitch
  • 或者其他支持Neutron的物理交換機。
• 與其他服務一樣，Neutron的各組件服務之間需要相互協調和通信
  • neutron-server、插件和代理之間通過消息隊列進行通信和相互調用。
• 數據庫用于存放OpenStack的網絡狀態信息
  • 例如：網絡、子網、端口、路由器等。
• 客戶端是指使用Neutron服務的應用程序，可以是命令行工具、Horizon和Nova計算服務等。

實例：以一個創建VLAN 100虛擬網絡的流程為例說明這些組件如何協同工作。

• neutron-server收到創建網絡的請求，通過消息隊列通知已注冊的Linux Bridge插件。(插件可以有很多，這里舉例創建虛擬網絡的插件是Linux Bridge插件)
• 該插件將要創建的網絡信息(如名稱、VLAN ID等)保存到數據庫中，并通過消息隊列通知運行在各節點上的代理
• 代理收到消息后會在節點上的物理網卡上創建VLAN設備(比如eth1.100)，并創建一個網橋(比如brqxxx)來橋接VLAN設備。

5、Neutron-server

• RESTful API：直接對客戶端提供API服務，屬于最前端的API，包括Core API和Extension API兩種類型。
  • Core API提供管理網絡、子網和端口核心資源的RESTful API;
  • Extension API則提供管理路由器、防火墻、負載均衡、安全組等擴展資源的RESTful API。
• Common Service:通用服務，負責對API請求進行檢驗、認證，并授權。
• Neutron Core:核心處理程序，調用相應的插件API來處理API請求。
• Plugin API:定義插件的抽象功能集合，提供調用插件的API接口，包括Core Plugin API 和 Extension Plugin API兩種類型。
  • Neutron Core通過Core Plugin API調用相應的Core Plugin
  • Neutron Core通過Extension Plugin API調用相應的Service Plugin

四、Neutron主要插件、代理和服務

Neutron遵循OpenStack的設計原則，采用開放性架構，通過插件、代理和網絡提供者的配合來實現各種網絡功能。

• 插件是Neutron的一種API的后端實現，目的是增強擴展性。
• 插件按照功能可分為CorePlugin和Service Plugin兩種類型。
  • Core Plugin提供基礎二層虛擬機網絡支持，實現網絡、子網和端口核心資源的支持。
  • Service plugin是指Core Plugin之外的其他插件，提供路由器、防火墻、安全組、負載均衡等服務支持。
    • 直到OpenStack的Havana版本，Neutron才開始提供一個名為L3 RouterService Plugin的插件支持路由服務。
• 插件由Neutron-server 的Core Plugin API和Extension Plugin API調用
  • 用于確定具體的網絡功能，要配什么樣的網絡
• 工作流程：插件處理Neutron-Server發來的請求
  • 主要職責是在數據庫中維護Neutron網絡的狀態信息(更新Neutron數據庫)，通知相應的代理實現具體的網絡功能。
  • 每一個插件支持一組API資源并完成特定操作，這些操作最終由插件通過RPC調用相應的代理(Agent)來完成。
  • 代理處理插件轉來的請求，負責在網絡提供者上真正實現各種網絡功能。
  • 代理使用物理網絡設備或者虛擬化技術完成實際的操作任務，如用于路由具體操作L3 Agent。

插件和代理與網絡提供者配套使用，比如網絡提供者是Linux Bridge，就需要使用LinuxBridge的插件和代理，如換成OpenySwitch,則需要改成相應的插件和代理。

1、典型的主機節點部署

Neutron與其他OpenStack服務組件系統工作，可以部署在多個物理主機節點上，主要涉及控制節點、網絡節點計算節點，每個節點可以部署多個,典型的主機節點部署介紹如下
控制節點和計算節點的結合

控制節點上部署Neutron-service (API)、Core Plugin和Service Plugin的代理，這些代理包括neutron-plugin-agent、neutron-medadata-agent、neutron-dhcp-agnet、neutron-l3-agent、neutron-lbass-agent等。Core plugin和service plugin已經集成到neutron-server中，不需要運行獨立的plugin服務。
計算節點上可以部署Core Plugin、Linux Bridge或Open vSwitch的代理，負責體提供二層網絡功能。
控制節點和計算節點都需要部署Core Plugin的代理，因為控制節點與計算節點通過該代理，才能建立二層連接。

控制節點和網絡節點的結合

可以通過增加網絡節點承擔更大的負載，該方案特別適合規模較大的OpenStack環境
控制節點部署Neutron-server服務，只負責通過Neutron-server響應的API請求。（水平擴展）
網絡節點部署的服務包括Core Plugin的代理和service Plugin的代理。將所有的代理主鍵從上述控制節點分離出來，部署到獨立的網絡節點上，由獨立的網絡節點實現數據的交換，路由以及負責均衡等高級網絡服務。

2、ML2插件

之前使用Neutron項目時，開發人員發現了兩個突出的問題：

• 第一個問題：多種網絡提供者無法共存
  • 一個Neutron網絡只能由一個插件管理
  • Core Plugin負責管理和維護Neutron二層的虛擬網絡的狀態信息，Core Plugin插件與相應的代理是一一對應的
  • Linux Bridge插件，只能選擇Linux Bridge代理,必須在OpenStack的所有節點上使用Linux Bridge作為虛擬交換機。
• 第二個問題：開發插件的工作量太大
  • 所有傳統的CorePlugin之間存在大量重復的代碼(如數據庫訪問代碼)

而從OpenStack的Havana 版本開始，Neutron 中出現一個插件ML2(Moduler Layer2)，ML2的出現取代了所有Core Plugin，允許在OpenStacks網絡中同時使用多種二層的網絡技術，不同的節點可以使用不同的網絡實現機制，ML2能夠與現在所有的代理無縫集成，以前使用費的代理無需變更，只要將傳統的Core Plugin替換ML2。ML2使openstack對先的網絡技術的支持更加簡單，無需從頭開發Core Plugin，只需開發相應的機制驅動，大大減少編寫的代碼。

ML2插件架構詳解

ML2對二層的網絡進行抽象，解鎖了Neutron所支持的網絡類型（Type）與訪問這些網絡類型的虛擬網絡實現機制（Mechansim），并通過驅動的形式進行擴展，不同的網絡類型對應不同的類型的驅動（Type Driver），由類型管理器（Type Manager）進行管理，不同的網絡實現機制對應不同的機制驅動（Mechasiom Driver），由機制管理器（Mechasim Manager）進行管理。這種ML2實現框架具有彈性，易于擴展，能夠能活支持多種網絡類型和實現機制

類型驅動（Type Driver）

Neutron支持的每一種網絡類型都有一個對應的ML2類型驅動，類型驅動負責維護網絡類型的狀態，執行驗證、創建網絡等工作。目前Neutron已經實現的網絡類型包括Flat、Local、Vlan、Vxlan、Gre

機制驅動（Mechansim Driver）

Neutron支持的每一種網絡機制都有一個對應的ML2機制驅動
機制驅動負責獲取類型驅動維護的網絡狀態，確保在相應的網絡設備（物理或者虛擬的）上正確實現這些狀態

類型驅動vlan，機制驅動為Linux Bridge，如果創建vlan10，那么vlan的類型驅動會確保將vlan10的信息保存到Neutron數據庫中，包括網絡的名稱、vlan ID等，而Linux bridge機制驅動會確保各個節點上Linux Bridge代理在物理網卡上創建ID為10的vlan設備和bridge設備，并且將二者進行橋接
Neutron的網絡機制有3種類型
基于代理（Agent-based）：包括Linux bridge、Openvswitch
基于控制器（controller-based）：包括OpenStacDaylight、VMware NSX等
基于物理交換：Cisco Nexus、Arista、Mellanox等

擴展資源

ML2作為一個Core Plugin，在實現網絡、子網和端口核心資源的同事，也實現了包括端口綁定（port Bindings）、安全組（Security Group）等部分擴展資源

3、Linux Bridge代理

• Linux Bridge是成熟可靠的Neutron二層網絡虛擬化技術，支持Local、Flat、vlan、Vxlan這四種網絡類型
• Linux Bridge可以將一臺主機上的多個網卡橋接起來，充當一臺交換機，它可以橋接物理網卡，又可以是虛擬網卡。
  • 用于橋接虛擬網卡（虛擬機網卡）的是Tap接口，這是一個虛擬機出來的網絡設備，稱為Tap設備，作為網橋的一個端口。
  • tap接口在邏輯上與物理接口具有相同的功能，可以接收和發送數據包
• 若選擇Linux Bridge代理，在計算節點上數據包從虛擬機發送到物理網卡需要經過以下設備
  • Tap接口（Tap interface）：用于網橋虛擬機的網卡，命令為tap XXX
  • Linux網橋（Linux bridge）：作為二層交換機，命令為brq XXXX
  • VLAN 接口（Vlan interface）：在vlan網絡中用于連接網橋，命名為ethx.y(ethx為物理網卡名稱，y為vlan ID)
  • VXLAN接口（VXLAN interface）：在vxlan網絡中用于連接網橋，命名為vxlan-z（z是vlan ID）
  • 物理網絡接口：用于連接到物理網絡

4、Open vSwitch代理

與Linux Bridge相比，Open vSwitch（簡稱OVS）具有幾種管控功能，而且性能更加優化，支持更多的功能，目前在Openstack領域為主流。

• OVS代理支持Local、flat、vlan、vxlan、GRE和GENEVE等網絡類型
• OVS的設備類型
  • Tap設備：用于網橋連接虛擬機網卡
  • Linux網橋：橋接網絡接口（包括虛擬接口）
  • VETH對（VETH Pair）：直接相連的一對虛擬機網絡接口
    • 兩個虛擬機網絡接口一個接受一個發送
    • 用來連接兩個虛擬網橋
  • OVS網橋：OVS的核心設備，包括一個OVS集成網橋和一個OVS物理連接網橋。
    • 兩個OVS網橋一般通過VETH來對接

數據包流程（在計算節點上的數據包從虛擬機發送到物理網卡）

• Tap接口：用于網橋虛擬機的網卡，命名為tapxxx
• Linu網橋：與LInux bridge不同，命名為qbrxxx（其中編號xxx與tapxxx中相同）
• VETH對：兩端分別命名為qvbxxx和qvoxxx（其中編號xxx與tapxxx中相同）
• OVS集成網橋：命名為br-int
  • OVS PATCH端口：兩端分別命名為int-br-ethx和phy-br-ethx（x為物理網卡名稱的編號）
    • 特殊端口類型，只能在Open vSwitch中使用
  • OVS物理連接網橋：分為兩種類型
    • 在flat和vlan網絡中使用OVS提供者網橋（provider bridge），命名為br-ethx（x為物理網卡名稱的編號）
    • 在vxlan、GRE和GENEVE疊加網絡中使用OVS隧道網橋（Tunnel Bridge），命名為Br-tun
    • 另外在local網絡中不需要在OVS物理連接網橋
• 物理網路接口：用于連接到物理網絡，命名為ethx（x 為物理網卡的名稱中的編號）

OVS網絡的邏輯結構

所有的虛擬機都連接到同一個網橋br-int，Open VSwitch通過配置br-int和br-ethx上流規則（flow rule）來進行vlan轉換，進而實現vlan之間的隔離
例如:內部標簽分別為1和2，而物理網絡的vlan標簽是101和102，當br-eth1網橋上的phy-br-eth1端口收到一個vlan1標記的數據包時，會將其中的vlan1轉讓為vlan101；當br-init網橋上的init-br-eth1端口收到一個vlan101標記的數據包時，會將其中的vlan101轉讓為vlan1

5、DHCP代理

openstack實例在啟動過程中能夠從Neutron提供的DHCP服務自動獲取IP地址

• DHCP主要組件
  • DHCP代理（neutron-dhcp-agent）：為項目網絡提供DHCP功能，提供元數據請求（Metadata request）服務
  • DHCP驅動：用于管理DHCP服務器，默認為DNSmasq，這是有一個提供DHCP和DNS服務的開源軟件，提供DNS緩存和DHCP服務功能
  • DHCP代理調度器（Agent-Scheduler）：負責DHCP代理與網絡（network）的調度

DHCP代理的主要任務

• ①定期報告DHCP代理的網絡狀態
  • 通過RPC報告給Neutron-server，然后通過Core Plugin報告給數據庫并進行更新網絡狀態。
• ②啟動dnsmasg進程
  • 檢測qdhcp-xxx名稱空間( Namespace)中的ns-xxx端口接收到DHCP DISCOVER請求

DHCP代理的配置文件
DHCP代理配置文件是/etc/neutron/dhcp_agent.ini

• interface_ driver：用來創建TAP設備的接口驅動
  • 如果使用Linux Bridge連接，該值設為neutron.agent.Linux.interface.BridgelnterfaceDriver
  • 如果選擇Open Vswitch,該值為neutron.agnt.linux.interface.OVSInterfaceDriver
• dhcp_ driver：指定DHCP啟動
  • 默認值為neutron.agent.linux.dhcp.Dnsmasq表示dnsmasq進程來實現DHCP服務

DHCP代理的工作機制

①創建實例時，Neutron 隨機生成MAC并從配置數據中分配一個固定的 IP地址，一起保存到dnsmasg的hosts文件中，讓dnsmasq進程做好準備。
②與此同時，Nova-compute 會設置Mac地址。
③實例啟動，發出DHCP DISCOVER廣播，該廣播消息在整個網絡中都可以被收到。
④廣播消息到達dnsmasq監聽Tap接口。dnsmasg收到后檢查hosts文件，發現有對應項，它以DHCP OFFER消息將IP和網關IP發回到虛擬機實例。
⑤虛擬機實例發回DHCP REQUEST消息確認接收DHCP OFFER
⑥dnsmasq.發回確認消息DHCPACK，整個過程結束。

6、Linux網絡名稱空間（租戶）

在介紹DHCP服務時提到的linux網絡名稱空間( Network Namespace簡稱netns )是linux提供的一種內核級別的網絡環境隔離方法，Namespace也可以翻譯稱為命名空間或者叫名字空間。當前linux支持6種不同類型的名稱空間，網絡名稱空間是其中一種，在二層網絡上，VLAN可以將一個物理交換機分割幾個獨立的虛擬交換機。類似地，在三層網絡上，Linux 網絡名稱空間可以將一個物理三層網絡跟個成幾個獨立的虛擬三層網絡。

Linux網絡名稱空間概述

在Linux中，網絡空間可以被認為是隔離的擁有單獨網絡棧(網絡接口、路由、iptables等)的環境，它經常來隔離網絡資源(設備和服務)，只有擁有同樣網絡名稱空間的設備才能批次訪問。它還能提供了在玩過名稱空間內運行進程的功能，后臺進程可以運行不同名稱空間內的相同端口上，用戶還可以虛擬出一塊網卡。
可以創建一個完全獨立的全新網絡環境，包括獨立的網絡接口、路由表、ARP 表，IP地址表、iptables 或ebtables等，與網絡有關的組件都是獨立的。

通常情況下可以使用ip netns add命令添加新的網絡名稱空間，使用ip netns list命令查看所有的網絡名稱空間。
執行以下命令進入指定的網絡名稱空間

ip netns exec netns 名稱 命令

可以在指定的虛擬環境中運行任何命令，如下

ip netns exec net001 bash

為虛擬網路環境netns0的Eth0接口增加P地址，如下

ip netns exec netns0 ip address add 10.0.1.1/24 eth0

網絡名稱空間內部通信沒有問題，但是被隔離的網絡名稱空間之間要進行通信，就必須采用特定方法，即VETH對，VETH對是一種成對出現的網絡設備，他們像一根虛擬的網絡線，可用于連接兩個名稱空間，向VETH對一端輸入的數據將自動轉發到另外一端。

例如創建兩個網絡名稱空間的netns1和netns2并使他們之間通信，可以執行以下步驟
①創建兩個網絡名稱空間

ip netns add netns1 ip netns add netns2

②創建一個VETH對（創建的一-對VETH虛擬接口類似管道(pipe) ，發給veth1的數據包可以在veth2收到，發給veth2的數據包可以在veth1收到，相當于安裝兩個接[ 1并用網線連接起來）

ip link add veth1 type veth peer name veth2

③將上述兩個VETH對虛擬接口分別放置到兩個網絡名稱空間中

ip link set veth1 netns netns1 ip link set veth2 netns netns2

Linux網絡名稱空間實現DHCP服務隔離

Neutron通過網絡名稱空間為每個網絡提供獨立的DHCP和路由服務，從而允許項目創建重疊的網絡，如果沒有這種隔離機制，網絡就不能重疊，這樣就失去了很多靈活性
每個dnsmasq.進程都位于獨立的網絡名稱空間，命名為qdhcpxx

以創建flat網絡為例

• Neutron自動新建該網絡對應的網橋brqfxxx，以及DHCP的Tap設備tapxxx。
• 物理主機本身也有一個網絡名稱空間，稱為root，新創建的名稱空間默認只擁有一個回環設備(LoopbackDevice)。
• 如果DHCP的Tap虛擬接口放置到gdhcp-xxx名稱空間，該Tap虛擬接口將無法直接與root名稱空間中網橋設備brqxxx連接。
• 為此，Neutron使用VETH對來解決這個問題，添加VETH對taxxx與ns-xxx i讓gdhce xxx連接到brxxx.

Linux網絡名稱空間實現路由器

Neutron允許在不同的網絡中的子網的CIDR和IP地址重疊，具有相同的IP地址的2個虛擬機也不會產生沖突，這是由于Neutron的路由器通過Linux網絡名稱空間實現的，每個路由器有自己的獨立的路由表

7、Neutron路由器

Neutron路由器是-一個三層的(L3)的抽象，其模擬物理路由器，為用戶提供路由、NAT等服務，在OpenStack網絡中，不用子網之間的通信需要路由器，項目網絡與外部網絡之間的通信更需要路由器。

Neutron提供虛擬路由器，也支持物理路由器。例如，兩個隔離的VLAN網絡之間需要實現通信，可以通過物理路由器實現，由物理路由器提供相應的IP路由表，確保兩個IP子網之間的通信，將兩個VLAN網絡中的虛擬機默認網關分別設置為路由路由器的接口A和B的IP地址。VLANA中的虛擬機要與VLAN B中的虛擬機通信時，數據包將通過VLAN A中的物理網卡到達路由器，由物理路由器轉發到VLAN B中的物理網卡，再到達目的虛擬機。
Neutron的虛擬路由器使用軟件模擬物理路由器，路由實現機制組網。Neutron的路由服務由L3代理提供

8、L3代理

在Neutron中L3代理(neutron-l3agent)具有相當重要的地位。它不僅提供虛擬機路由器，而且通過iptables提供地址轉換(SNAT、DNAT)、浮動地址( Floating IP)和安全組(security group)功能，L3代理利用LInux IP棧、路由和iptables.來實現內部網絡中不同網絡的虛擬機實例之間的通信，以及虛擬機實例和外部網絡之間的網絡流量路由和轉發，L3代理可以部署在控制節點或者網絡節點上

（1）路由（routing）

L3代理提供的虛擬路由器通過虛擬接口連接到子網，一個子網對應一個接口，該接口的地址是該子網的網關地址。
L3代理會將每個路由器創建一個網絡名稱空間，通過VETH對于TAP相連，然后將網關IP配置在位于名稱空間的VETH接口上，這樣就能夠提供路由。
網絡節點如果不支持linux名稱空間，則只能運行一個虛擬路由器

（2）通過網絡名稱空間支持網絡重疊

在云環境下用戶可以按照自己的規劃創建網絡，不同的項目( 租戶)的網絡IP地址可能會重疊，為實現此功能，L3 代理使用linux網絡名稱空間來提供隔離的轉發上下文，隔離不同的項目(租戶)的網絡，每個L3代理運行在一個名稱空間中，每個名稱空間由quouter-命名

（3）源地址轉換（SNAT）

L3代理通過在iptables表中增加POSTROUTING鏈來實現源地址轉換，既內網計算機訪問外網時，發起訪問的內網IP地址(源IP地址)轉換為外網網關的IP地址。這種功能讓虛擬機實例能夠直接訪問外網。不過外網計算機還不能直接訪問虛擬機實例，因為實例沒有外網IP地址，而H的地址轉化就能解決這一問題。

（4）目的地址轉換（DNAT)

Neutron需要設置浮動IP地址支持從外網訪問項目(租戶)網絡中的實例。
每個浮動IP唯一對應一個路由器，浮動IP–>關聯的端口–>所在的子網–>包含該子網及外部子網路由器。創建浮動IP時，在Neutron分配IP地址后，通過RPC通知該浮動IP地址對應的路由器去設置該浮動IP對應的iptabels規則，從外網訪問虛擬機實例時，目的IP地址為實例的浮動IP地址，因此必須由lptables將其轉化成固定的IP地址，然后在將其路由到實例。
浮動IP地址是提供靜態NAT功能，建立外網IP地址與實例所在的項目(租戶網絡) IP地址的一對一映射，浮動IP地址配置在路由器提供網關的外網接口上。

（5）安全組（Security Group）

安全組定義了那些進入的網絡流量能被轉發給虛擬機實例。安全組包含一些防火墻策略，稱為安全組規則( Security Group nule) ,可以定義若干個安全組。每個安全組可以有若千調規則。可以給每個實例綁定若千個安全組
安全組的原理是通過iptables對是咧所在的計算機節點的網絡流量進行過濾。安全組規則作用在實例的端口上，具體是在連接實例的計算節點上的linux網橋上實施。

9、FWaas(虛擬防火墻)

Fwaas（firewall-as-a-service)是一種基于Neutron L3 Agent的虛擬防火墻，是Neutron的一個高級服務。通過它，OpenStack 可以將防火墻應用到項目(租戶)、路由器、路由器端口和虛擬機端口，在子網邊界上對三層和四層的流量進行過濾。
傳統的網絡中的防火墻一般在網關上,用來控制子網之間的訪問。FWaas的原理也是一樣，在Neutron路由上應用防火墻規則，控制進出項目(租戶)網絡的數據。防火墻必須關聯某個策略(Policy) 。
FWaas 的應用對象是慮報路由器，可以在安全組之前控制從外部傳入的流量，但是對于同一個子網內的流量不做限制，安全組保護的是實例，而FWaas保護的是子網，兩者互為補允，通常部客FWaas和安全組來實現雙重防護。
補充：
策略是規則(rule) 的集合，防火墻會按順序因公策略中的每一條規則。規則是訪問控制的規則，由源于日的子網IP、源于日的端口、協議、允許Allow)和拒絕(Deny)動作組成
安全組是最早的網絡安全模塊，其應用對象是虛擬網卡，在計算機節點上通過iptables.規則控制進出實例慮積網卡的流量。

FW版本（FWaasV1與FWaasV2）

• FWaaSv1是傳統方后墻方案，對路由器提供保護，將防火墻應用到路由器時，該路由器的所有內部端口受到保護，其中虛擬機2進出的數據流都會得到防火墻保護。
• FWaaSv2提供了更具細粒度的安全服務，FWaaSv2防火墻的概念防火墻組(firewallgroup)代替，一個防火城包括兩項策略：入口策略(ingress polie)和出口(egress poliy)。
  • 防火墻組不在用于路由器級(路由器全部端口)，而是路由器端口。
  • 注意，FWaas v2的配置僅提供命令行工具，不支持dashboard圖形頁面。

五、Neutron網絡配置和管理

虛擬網絡類型：提供者網絡和自服務網絡

1、提供者網絡

• 提供者網絡選項以最簡單的方式部署OpenStack網絡服務，包括二層服務(橋/交換機)服務、VLAN網絡分段。
• 本質上，它建立虛擬網絡到物理網絡的橋，依靠物理網絡基礎設施提供三層服務(路由)。
• 提供者網絡默認有管理員創建，實際上，就是與物理網絡有直接映射關系的虛擬網絡，要使用物理網絡直接連接虛擬機實例，必須在openstack中將物理網絡定義為提供者網絡。
• 這種網絡可以在多個項目之間共享。
• 雖然可以創建VXLAN或GRE類型的提供者網絡，但是只有Flat或VLAN類型的網絡拓撲才對提供者網絡具有實際意義。
• 提供者網絡和物理網絡的某個網段直接映射，因此需要預先在物理網絡中做好相應的配置。物理網絡的每個網段最多只能實現一個提供者網絡.

2、自服務網絡

• 自服務網絡主要目的：讓非特權的普通項目自行管理網絡，無需管理員介入。
• 這種網絡完全是虛擬的。需要通過虛擬焰由器與提供者網絡和像Internet這樣的外部網絡通信。自服務網絡也對實例提供DHCP服務和元數據服務。
• 絕大多數情況下，自服務網絡使用像VXLAN或GRE這樣的Overlay協議，因此這些協議要比使用VLAN標記的二層網終分段支持更多的網絡，而且VLAN通常還要求物理網絡設施的額外配置
• IPV4自服務網絡通過虛擬路由器上的源NAT與提供者網絡進行交互進行通信(內部)，浮動IP地址則通過虛擬路由器上的目的NAT讓來自提供者網絡的用戶訪問虛擬機實例(外部)。
• 網絡服務使用L3代理實現路由器，L3代理至少要部署在一個網絡節點上。自服務網絡必須有一個L3代理。不過，一個L3代理或網絡節點的過載或故障就能影響一大批自服務網絡和使用它們的實例。實際部署痍要提供高可用功能來增加冗余，提高自服務網絡的性能。
• 用戶可以為項目中的連創建項目網絡，也就是自服務網絡。默認情況下自服務網絡被完全隔離，OpenStack網絡支持的網絡隔離和覆蓋技術包括Flat、VLAN、GRE和VLAN等。
• 一個典型自服務網絡包括三層路由服務、DHCP服務、不能提供LBaas和FWaas這樣高級服務。
  • 雖然自服務網絡可以選擇Local、Flat、VLAN、VXLAN或GRE等類型，但是Flat和VLAN類型的自服務網絡本質上對應于一個實際的物理網段，因此真正有意義的是VXLAN或GRE類型，因為這類Overlay網絡本身不依賴于具體的物理網絡，只要物理網絡能夠提供IP多播支持即可。
• 這種虛擬網絡中包括自服務網絡（作為內部網絡）和提供者網絡（作為外部網絡)，也可以使用
  這兩種網絡為虛擬機實例提供網絡連接。

總結

以上是生活随笔為你收集整理的OpenStack之Neutron理论部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。