Neutron 理解 (1): Neutron 所實現的網路虛擬化 [How Neutron Virtualizes Network]

學習 Neutron 系列文章：

1. 為什麼要網路虛擬化？

個人認為，這裡主要有兩個需求：一個是資料中心的現有網路不能滿足雲端計算的物理需求；另一個是資料中心的現有網路不能滿足雲端計算的軟體化即SDN要求。

1.1 現有物理網路不能滿足雲端計算的需求

網際網路行業資料中心的基本特徵就是伺服器的規模偏大。進入雲端計算時代後，其業務特徵變得更加複雜，包括：虛擬化支援、多業務承載、資源靈活排程等（如圖1所示）。與此同時，網際網路雲端計算的規模不但沒有縮減，反而更加龐大。這就給雲端計算的網路帶來了巨大的壓力。

圖1. 網際網路雲端計算的業務特點

（1）大容量的MAC表項和ARP表項

虛擬化會導致更大的MAC表項。假設一個網際網路雲端計算中心的伺服器有5000臺，按照1:20的比例進行虛擬化，則有10萬個虛擬機器。通常每個虛擬機器會配置兩個業務網口，這樣這個雲端計算中心就有20萬個虛擬網口，對應的就是需要20萬個MAC地址和IP地址。雲端計算要求資源靈活排程，業務資源任意遷移。也就是說任意一個虛擬機器可以在整個雲端計算網路中任意遷移。這就要求全網在一個統一的二層網路中。全網任意交換機都有可能學習到全網所有的MAC表項。與此對應的則是，目前業界主流的接入交換機的MAC表項只有32K，基本無法滿足網際網路雲端計算的需求。另外，閘道器需要記錄全網所有主機、所有網口的ARP資訊。這就需要閘道器裝置的有效ARP表項超過20萬。大部分的閘道器裝置晶片都不具備這種能力。

（2）4K VLAN Trunk問題

傳統的大二層網路支援任意VLAN的虛擬機器遷移到網路的任意位置，一般有兩種方式。方式一：虛擬機器遷移後，通過自動化網路管理平臺動態的在虛擬機器對應的所有埠上下發VLAN配置；同時，還需要動態刪除遷移前虛擬機器對應所有埠上的VLAN配置。這種方式的缺點是實現非常複雜，同時自動化管理平臺對多廠商裝置還面臨相容性的問題，所以很難實現。方式二：在雲端計算網路上靜態配置VLAN，在所有埠上配置VLAN trunk all。這種方式的優點是非常簡單，是目前主流的應用方式。但這也帶來了巨大的問題：任一VLAN內如果出現廣播風暴，則全網所有VLAN內的虛擬機器都會受到風暴影響，出現業務中斷。

（3）4K VLAN上限問題

雲端計算網路中有可能出現多租戶需求。如果租戶及業務的數量規模超出VLAN的上限（4K），則無法支撐客戶的需求。

（4）虛擬機器遷移網路依賴問題

VM遷移需要在同一個二層域內，基於IP子網的區域劃分限制了二層網路連通性的規模。

（資料來源）

1.2 雲端計算的 SDN 要求

資料中心（Data Center）中的物理網路是固定的、需要手工配置的、單一的、沒有多租戶隔離的網路。這是一個物理網路區域性例項：

（圖1，來源：Cisco 網站。 TOR：Top On Rack 交換機。圖中的一個伺服器有三塊網絡卡，分別連到連線資料網路和管理網路的交換機。）

而云架構往往是多租戶架構，這意味著多個客戶會共享單一的物理網路。因此，除了提供基本的網路連線能力以外，雲還需要提供網路在租戶之間的隔離能力；同時雲是自服務的，這意味著租戶可以通過雲提供的 API 來使用虛擬出的網路組建來設計，構建和部署各種他們需要的網路。

（左圖-圖3：計算虛擬化和網路虛擬化。來源）（右圖-圖4：來源 MidoNet 提供的物理網路和邏輯網路的對映）

OpenStack 雲也不例外。 OpenStack 通過 Neutron 專案在物理網路環境之上提供滿足多租戶要求的虛擬網路和服務。Neutron 提供的網路虛擬化能力包括：

（1）二層到七層網路的虛擬化：L2（virtual switch）、L3（virtual Router 和 LB）、L4-7（virtual Firewall ）等
（2）網路連通性：二層網路和三層網路
（3）租戶隔離性
（4）網路安全性
（4）網路擴充套件性
（5）REST API
（6）更高階的服務，包括 LBaaS，FWaaS，VPNaaS 等。具體以後再慢慢分析。

2. Neutron 網路虛擬化

在實際的資料中心中，網路可以分為三層：OpenStack Cloud network，機房intranet （external network），以及真正的外部網路即 Internet。External 網路和Internet 之間是資料中心的 Uplink 路由器，它負責通過 NAT 來進行兩個網路之間的IP地址（即 floating IP 和 Internet/Public IP）轉換，因此，這部分的控制不在 OpenStack 控制之下，也不在本文的主要探討範圍之內。

OpenSack Cloud network：OpenStack 所管理的網路。
External network：資料中心所管理的的公司網（Intranet），虛機使用的 Floating IP 是這個網路的地址的一部分。
Internet：由各大電信運營商所管理的公共網路，使用公共IP。

這是 RedHat 提供的一個 OpenStack Cloud network 網路架構：

大概地分類的話，該網路管理網路和資料網路，資料網路中關鍵的是租戶網路，用於租戶虛機之間的通訊。這部分也是 Neutron 所實現的網路虛擬化的核心。在目前的Neutron 實現中，Neutron 向租戶提供虛擬的網路（network）、子網（subnet）、埠（port）、交換機（switch）、路由器（router）等網路元件。下圖顯示了虛擬網路和物理網路的對映關係：

（圖5.來源：2015 OpenStack技術大會-Neutron雲端計算網路虛擬化-龔永生.pdf）

2.1 網路（L2 network）

網路（network）是一個隔離的二層網段，類似於物理網路世界中的虛擬 LAN (VLAN)。更具體來講，它是為建立它的租戶而保留的一個廣播域，或者被顯式配置為共享網段。埠和子網始終被分配給某個特定的網路。這裡所謂的隔離，可以理解為幾個含義：

跨網路的子網之間的流量必須走 L3 Virtual Router
每個網路使用自己的 DHCP Agent，每個 DHCP Agent 在一個 Network namespace 內
不同網路內的IP地址可以重複（overlapping）

根據建立網路的使用者的許可權，Neutron network 可以分為：

Provider network：管理員建立的和物理網路有直接對映關係的虛擬網路。
Tenant network：租戶普通使用者建立的網路，物理網路對建立者透明，其配置由 Neutron根據管理員在系統中的配置決定。

虛機可以直接掛接到 provider network 或者 tenant network 上 “VMs can attach directly to both tenant and provider networks, and to networks with any provider:network_type value, assuming their tenant owns the network or its shared.”。

根據網路的型別，Neutron network 可以分為：

VLAN network（虛擬區域網）：基於物理 VLAN 網路實現的虛擬網路。共享同一個物理網路的多個 VLAN 網路是相互隔離的，甚至可以使用重疊的 IP 地址空間。每個支援 VLAN network 的物理網路可以被視為一個分離的 VLAN trunk，它使用一組獨佔的 VLAN ID。有效的 VLAN ID 範圍是 1 到 4094。
Flat network：基於不使用 VLAN 的物理網路實現的虛擬網路。每個物理網路最多隻能實現一個虛擬網路。
local network（本地網路）：一個只允許在本伺服器內通訊的虛擬網路，不知道跨伺服器的通訊。主要用於單節點上測試。
GRE network （通用路由封裝網路）：一個使用 GRE 封裝網路包的虛擬網路。GRE 封裝的資料包基於 IP 路由表來進行路由，因此 GRE network 不和具體的物理網路繫結。
VXLAN network（虛擬可擴充套件網路）：基於 VXLAN 實現的虛擬網路。同 GRE network 一樣， VXLAN network 中 IP 包的路由也基於 IP 路由表，也不和具體的物理網路繫結。

注：在AWS中，該概念對應 VPC 概念。AWS 對 VPC 的數目有一定的限制，比如每個賬戶在每個 region 上預設最多隻能建立 5 個VPC，通過特別的要求最多可以建立 100 個。

2.1.1 Provider network

Provider Network 是由 OpenStack 管理員建立的，直接對應於資料中心的已有物理網路的一個網段。這種網路有三個和物理網路有關屬性：

provider:network_type (網路型別，包括 vxlan, gre, vlan, flat, local)
provider:segmentation_id (網段 ID，比如 VLAN 的 802.1q tag, GRE 網路的 Tunnel ID, VXLAN 網路的 VNI)
provider:physical_network (物理網路的邏輯名稱，比如 physnet1, ph-eth1, etc)

這種網路是可以在多個租戶之間共享的。這種網路通過計算和網路節點上指定的 bridge 直接接入物理網路，所以預設的情況下它們是可以路由的，因此也不需要接入 Neutron Virtual Router，也不需要使用 L3 agent。使用這種網路，必須預先在各計算和網路節點上配置指定的網橋。

雖然可以建立 GRE 和 VXLAN 型別的 Provider network，但是（個人認為）Provider network 只對 Flat 和 VLAN 型別的網路才有意義，因為 Provider network 的一個重要屬性是 provider:physical_network，而這個引數對其他網路型別沒有有意義。

建立 provider network：

local 型別的：neutron net-create NAME --provider:network_type local
flat 型別的：neutron net-create NAME --provider:network_type flat --provider:physical_network PHYS_NET_NAME
vlan 型別的：neutron net-create NAME --provider:network_type vlan --provider:physical_network PHYS_NET_NAME --provider:segmentation_id VID
gre 型別的：neutron net-create NAME --provider:network_type gre --provider:segmentation_id TUNNEL_ID
vxlan 型別的：neutron net-create NAME --provider:network_type vxlan --provider:segmentation_id TUNNEL_ID

2.1.3 Tenant network

Tenant network 是由 tenant 的普通使用者建立的網路。預設情況下，這類使用者不能建立共享的 tenant network（因此 Nuetron Server 的policy 設定了"create_network:shared": "rule:admin_only"。），因此這種網路是完全隔離的，也不可以被別的 tenant 共享。

Tenant network 也有 local，flat，vlan，gre 和 vxlan 等型別。但是，tenant 普通使用者建立的 Flat 和 VLAN tenant network 實際上還是 Provider network，所以真正有意義的是 GRE 和 VXLAN 型別，這種網路和物理網路沒有繫結關係。

建立 tenant network 的過程：

（0）管理員在 neutron 配置檔案中配置 tenant_network_types，其值可以設為一個所支援的網路型別列表，比如 “vlan,gre,vxlan”。其預設值為 “local“，因此需要改變。該值表明該 OpenStack 雲中允許被建立的 tenant network 型別。

（1）執行命令 neutron net-create <net_name>

（2）neutron server 逐一根據該配置項嘗試建立 network segment，成功則立即返回。

def allocate_tenant_segment(self, session):
    for network_type in self.tenant_network_types: #挨個試
        driver = self.drivers.get(network_type)
        segment = driver.obj.allocate_tenant_segment(session)
        if segment: #返回第一個成功的 segment
            return segment
    raise exc.NoNetworkAvailable()

建立每種網路時，使用不同的配置項：

網路型別	配置項	說明	例項
vlan	network_vlan_ranges = physnet1:1000:2999,physnet2	指定所使用的物理網路的標籤和支援的 VLAN ID 範圍	network_vlan_ranges = default:2000:3999 integration_bridge = br-int bridge_mappings = default:br-eth1
flat	flat_networks = physnet1,physnet2	指定所使用的物理網路的 label
gre	tunnel_id_ranges =a list of <tun_min>:<tun_max> local_ip = <ip>	一組可用的 GRE ID 區間列表；建立 GRE Tunnel 使用的 IP 地址	enable_tunneling = true tunnel_id_ranges = 1:1000 integration_bridge = br-int tunnel_bridge = br-tun local_ip = 10.0.0.3
vxlan	vni_ranges = a list of <vni_min>:<vni_max> local_ip = <ip> vxlan_group = 239.1.1.1	一組可用的 VNI 區間列表；建立 VxLAN Tunnel 使用的 IP 地址 VXLAN 組播組	enable_tunneling = true tunnel_type = vxlan integration_bridge = br-int tunnel_bridge = br-tun local_ip = 10.0.0.3 tunnel_types = vxlan
所有	integration_bridge bridge_mappings = default:br-eth1 tunnel_bridge enable_tunneling = False	指定intergration bridge 的名稱，預設為 br-int；指定物理網路label 和伺服器上的 bridge 對應關係；指定 turnnel bridge 的名稱，預設為 br-tun 是否使用 tunneling 型別的網路，包括 GRE 和 VxLAN。使用的話，ML2 agent 會在每個計算和網路節點建立名稱為 tunnel_bridge 的 tunnel bridge。

2.1.4 Provider network 和 Tenant network 的區別

（圖6.來源：google）

幾個區別：

Provider network 是由 Admin 使用者建立的，而 Tenant network 是由 tenant 普通使用者建立的。
Provider network 和物理網路的某段直接對映，比如對應某個 VLAN，因此需要預先在物理網路中做相應的配置。而 tenant network 是虛擬化的網路，Neutron 需要負責其路由等三層功能。
對 Flat 和 VLAN 型別的網路來說，只有 Provider network 才有意義。即使是這種型別的 tenant network，其本質上也是對應於一個實際的物理段。
對 GRE 和 VXLAN 型別的網路來說，只有 tenant network 才有意義，因為它本身不依賴於具體的物理網路，只是需要物理網路提供 IP 和組播即可。
Provider network 根據 admin 使用者輸入的物理網路引數建立；而 tenant work 由 tenant 普通使用者建立，Neutron 根據其網路配置來選擇具體的配置，包括網路型別，物理網路和 segmentation_id。
建立 Provider network 時允許使用不在配置項範圍內的 segmentation_id。

2.1.5 多網段 Provider network （multi-segment provider network）

預設情況下，使用者只能建立單網段 provider network。這個 Blueprint 使得 Neutron 能夠支援建立多網段網路。這種網路由相同或者不同網路型別的多個網段（network segments）組成一個廣播域。一個 Port 只能在一個 segment 中分配。

一個例項：

[email protected]:~$ neutron net-create multinet --segments type=dict list=true provider:physical_network=physnet1,provider:segmentation_id=153,provider:network_type=vlan provider:physical_network='',provider:segmentation_id=801,provider:network_type=vxlan

Created a new network:
+-----------------+-------------------------------------------------------------------------------------------------------------+
| Field           | Value                                                                                                       |
+-----------------+-------------------------------------------------------------------------------------------------------------+
| admin_state_up | True                                                                                                        |
| id | 206ae34c-7993-4128-b14d-196e084fbefe                                                                        |
| name | multinet                                                                                                    |
| router:external | False                                                                                                       |
| segments | {"provider:network_type": "vlan", "provider:physical_network": "physnet1", "provider:segmentation_id": 153} |
| | {"provider:network_type": "vxlan", "provider:physical_network": null, "provider:segmentation_id": 801}      |
| shared | False                                                                                                       |
| status | ACTIVE                                                                                                      |
| subnets |                                                                                                             |
| tenant_id | 74c8ada23a3449f888d9e19b76d13aab                                                                            |
+-----------------+-------------------------------------------------------------------------------------------------------------+

下圖中的網路包括型別分別為 flat，gre 和 vlan 的三個網段：

（圖7。來源 google）

2.1.6 Mirantis 描述的網路

Mirantis 將邏輯網路分為以下三大類：

public network （公共網路）
- 虛機通過 pulic network 訪問 internet。它分配外部的 IP 地址給網路節點，以及在使用 DVR 時分配給計算節點，然後虛機通過 SNAT 來訪問外網。
- 它也向 public endpoints 提供虛擬IP，用於外網訪問 openstack service api。
- 管理員制定一個相鄰的地址區間給浮動IP使用。
- 需要將 public network 與其它網路隔離。
internal network （內部網路）
- internal network 是出了 public network 和 provate network 的其他網路的統稱，包括儲存，管理，PXE 網路等。
  - 內部網路 - PXE 網路，用於環境部署
  - 儲存網路 - 用於儲存訪問
  - 管理網路 - 包括資料庫，MQ，HA 服務，以及計算和儲存節點之間的 iSCSI 網路。
- 內部網路將各節點連線起來。openstack 環境中的各個模組之間的互動通過內部網路進行。
- 不要將 internal network 和 private network 混淆，private network 只用於虛機之間的通訊。
- 出於安全考慮，需要將內部網路從 public 和 private network 隔離出來。
Private network （私有網路）
- 用於虛機之間的通訊，包括 VLAN, GRE/VXLAN 等型別的虛擬網路都會執行在私有網路之上。

當 Neutron使用 VLAN 模式時候的網絡卡分配方案：

三網絡卡方案：

eth0 - PXE 網路
eth1 - 公共網路（untagged），管理網路（tag=102），儲存網路（tag=103）
eth2 - 私有網路

四網絡卡方案

eth0 - PXE 網路
eth1 - 公共網路（untagged），管理網路（tag=102）
eth2 - 私有網路
eth3 - 儲存網路

這是 OVS + VLAN 使用三塊網絡卡時的配置示例：

當 Neutron使用隧道（GRE或者 VXLAN）模式時候的網絡卡分配方案：

兩網絡卡方案

eth0 - PXE 網路
eth1 - 公共網路（untagged），管理網路（tag=102），儲存網路（tag=103）

三網絡卡方案：

eth0 - PXE 網路
eth1 - 公共網路（untagged），管理網路（tag=102）
eth2 - 儲存網路

四網絡卡方案

eth0 - PXE 網路
eth1 - 管理網路
eth2 - 公共網路
eth3 - 儲存網路

這是 OVS + GRE 配置示例：

備註：這表格中提到 GRE網路和管理網路混在一起，這是 mirantis Fuel 6.0從UI上配置的一個已知問題，詳情在這裡 https://bugs.launchpad.net/fuel/+bug/1285059。其實Mrantis也是不推薦這麼配置的。

2.2 子網（subnet）

子網是一組 IPv4 或 IPv6 地址以及與其有關聯的配置。它是一個地址池，OpenStack 可從中向虛擬機器 (VM) 分配 IP 地址。每個子網指定為一個無類別域間路由 (Classless Inter-Domain Routing) 範圍，必須與一個網路相關聯。除了子網之外，租戶還可以指定一個閘道器、一個域名系統 (DNS) 名稱伺服器列表，以及一組主機路由。這個子網上的 VM 例項隨後會自動繼承該配置。

在 OpenStack Kilo 版本之前，使用者需要自己輸入 CIDR。Kilo 版本中實現了這個 Blueprint，使得 Neutron 能夠從使用者指定的 CIDR Pool 中自動分配 CIDR。

注：在AWS中，該概念對應其 Subnet 概念。AWS 對 Subnet 的數目有一定的限制，預設地每個 VPC 內最多隻能建立 200 個 Subnet。從CIDR角度看，一個 VPC 有一個比較大的網段，其中的每個 Subnet 分別擁有一個較小的網段。這種做法和OpenStack 有區別，OpenStack 中建立網路時不需要指定 CIDR。

2.3 埠（Port）

一個 Port 代表虛擬網路交換機（logical network switch）上的一個虛機交換埠（virtual switch port）。虛機的網絡卡（VIF - Virtual Interface）會被連線到 port 上。當虛機的 VIF 連線到 Port 後，這個 vNIC 就會擁有 MAC 地址和 IP 地址。Port 的 IP 地址是從 subnet 中分配的。

2.4 虛機交換機（Virtual switch）

Neutron 預設採用開源的 Open vSwitch 作為其虛機交換機，同時還支援使用 Linux bridge。

2.5 虛擬路由器（Virtual router）

一個 Virtual router 提供不同網段之間的 IP 包路由功能，由 Nuetron L3 agent 負責管理。

2.6 各元件之間的關係

OpenStack 實際上並未增加網路功能。路由、交換和名稱解析是由底層的網路基礎架構處理的。OpenStack 的作用是將這些元件的管理捆綁在一起，並將它們連線到計算工作負載。

（圖8.來源 google）

3. Neutron中的網路連通性

如上面第二章節所述，一個標準 OpenStack 環境中的物理網路配置往往包括：

Internet（Pulic network）：傳統意義上的公共網路，使用往往由電信運營商提供的公共IP。
外部網路（External network）：資料中心 Intranet，從這裡分配浮動IP地址。
OpenStack 內部網路：
- 管理網路（management network）：提供 OpenStack 各個元件之間的內部通訊，以及 API 訪問端點（Endpoint）。為安全考慮，該網路必須限制在資料中心之內。
- API 網路：其實這不是一個單獨的網路，而是包含在外部和內部網路中。API 的 Endpoint 包括 publicurl 和 internalurl，其中，publicurl 包含的是 externa network 的 IP 地址，internal network 包含的是 management network IP 地址。為了簡單起見，提供給內外網路訪問的API的 publicurl 和 internalurl 相同，而只給內部網路訪問的 API 只使用 internalurl。
- 資料網路（data network）：除管理網路以外的其它網路，往往還可以細分為下面幾種。它們可以合為一種，也可以從效能方面考慮分離出一種或幾種作為單獨的網路。
  - 租戶網路（Tenant network）：提供虛機在計算節點之間，以及計算節點和網路節點之間的通訊。同樣這也是資料中心的內部網路。
  - 儲存訪問網路（storage access network）：訪問儲存的網路。
  - 儲存後端網路（storage backend network）：比如 Ceph 和 Swift 叢集用於後端資料複製的網路。
除了以上網路外，往往還有各種功能網路，包括 IPMI 網路，PXE 網路，監控網路等等。這部分就略去不談了。

這幾種網路，在物理交換機上，往往都使用 VLAN 來做網路隔離。現在討論的只是租戶網路即虛機之間通訊的網路，在 Neutron 的實現看來，該網路的連通性包括幾個層次：

同主機和不同主機上一個網段內的虛機之間的連線性：虛擬二層網路，走物理二層（VLAN）或者三層（GRE/VxLAN）網路。
不同網段內的虛機之間的連通性：經過物理（VLAN）或者 Neutron Virtual router
虛機和外部網路之間的連通性：經過物理路由器（給 VLAN 虛擬網路實用的物理交換機連線的路由器）或者 Neutron Virtual router

3.1 虛擬二層網路的實現

所謂虛擬二層網路，就是提供給虛機的一種虛擬網路，使得虛機可以和同網段中的其它虛機就像在物理二層網路一樣在網路二層直接通訊，不管目的虛機處於什麼物理位置。也就是說，對虛機來說，物理三層網路對它是透明的。

3.1.1 使用 VLAN 實現虛擬二層網路

（圖10.來源：google）

3.1.2 基於 GRE/VxLAN 實現的二層網路（L2）

除了 VLAN 方式的物理的二層網路，另一種方式使用Tunnel/Overlay 方式實現虛機二層網路。那Overlay如何應對雲端計算網路的挑戰呢？

（1）首先，Overlay的核心是重新構建一個邏輯網路平面，其技術手段的關鍵是採用隧道技術實現L2oIP的封裝。通過隧道實現各虛擬機器之間的二層直連。這樣網路只看見Overlay邊緣節點的MAC地址，物理網路學習到的MAC表項非常有限，現有接入交換機32K的MAC表項足以滿足需求（如下圖所示）。對應的Overlay邊緣節點實現基於會話的地址學習機制，也就是說只學習有互動流量的虛擬機器MAC地址。這樣也嚴格限制了邊緣節點的地址表項。

Overlay網路如何應對雲端計算網路的挑戰

（2）其次，Overlay網路僅僅是一個邏輯上的二層直連網路。其依賴的物理網路，是一個傳統的路由網路。這個路由網路是一個三層到邊緣的網路。也就是說二層廣播域被縮小到極致。這樣，網路風暴潛在的風險大幅度降低。同時，對於一些需要依賴二層廣播的協議報文，例如：ARP報文，Overlay網路通過ARP代理等方式實現協議的內容透傳，不會影響協議報文的正常運作。

（3）再次，針對4K VLAN上限問題，Overlay網路通過L2oIP的封裝欄位，提供24bits長度的隔離ID，最大可以支援16M租戶或業務。

（4）最後，針對網路虛擬化問題。Overlay網路本身就是一個從物理網路中抽離的邏輯網路，通過名址分離使得內層IP地址完全作為一個定址標籤，不再具備路由功能，可以實現不同subnet之間二層互通，保證二層網路的連通性不受IP地址段的限制。

（資料來源）

在 Neutron 中，Neutron 將虛機發出的資料幀打包，走三層物理網路到達目的虛機的主機，解包給虛機。這種實現使得兩個虛機的通訊看起來是二層網路通訊。

（圖11.來源：google）

3.2 虛擬路由器（virtual router）

跨子網的通訊需要走虛擬路由器。同物理路由器一樣，虛擬路由器由租戶建立，擁有多個 virtual interface，連線一個租戶的子網，以及外部網路。它具有以下特性：

一個 VR 只屬於建立它的租戶，只用於該租戶的子網之間和子網與外網的路由
同一網路內的若干子網可以掛在一個 VR 上
同一租戶的不同網路的沒有 IP 地址重疊的子網可以掛在一個 VR 上
不同租戶之間的內網之間是不能使用 VR 的
同一租戶的不同網路內的有 IP 地址重疊的兩個子網不能使用同一個 VR（新增子網到 VR 時會報錯）
在網路節點上，一個 VR 執行在一個 Network namespace 內，該namespace 的名稱包含該 VR 的 UUID

具體會在後面的文章中分析。

（圖12。來源：google）

3.3 DHCP 服務

DHCP 服務是網路環境中必須有的。Neutron 提供基於 Dnamasq 實現的虛機 DHCP 服務，向租戶網路內的虛機動態分配固定 IP 地址。它具有以下特性：

一個網路可以有多個執行在不同物理網路節點上的 DHCP Agent，同時向網路內的虛機提供服務
一個 DHCP Agent 只屬於一個網路，在網路節點上執行在一個 network namespace 內
網路內的子網共享該 DHCP Agent

4. Neutron 租戶網路的隔離性（isolation of tenant network）

Neutron 實現了不同層次的租戶網路隔離性：

租戶之間的網路是三層隔離的，連通過 VR 做路由都不行，實在要連通的話，需要走物理網路
一個租戶內的不同網路之間二層隔離的，需要通過 VR 做三層連通
一個網路內的不同子網也是二層隔離的，需要通過 VR 做三層連通

Neutron 對每個租戶網路（tenant network）都分配一個 segmentation_id，其特點包括：

每個 tenant network 都有一個這種 ID
每個租戶網路的 ID 在全部的租戶範圍內都是唯一的
一個 ID 代表一個廣播域
一個 ID 使得同一網路內的兩個虛機之間好像建立了一個虛擬通道（tunnel）一樣
不同 ID 的網路 tunnel 之間是互相隔離的
根據物理實現不同，該ID被實現為幾種不同的形式：
- VLAN ID
- GRE Tunnel ID
- VxLAN VNI

以下圖描述的 GRE 型別的網路為例：

（圖13。圖片來源。）

（1）計算節點的 br-int 上，neutron 為每個虛機連線 OVS 的 access port 分配了內部的 VLAN Tag。這種 tag 限制了網路流量只能在 tenant network 之內。
（2）計算節點的 br-tun 上，neutron 將內部的 VLAN Tag 轉化為 GRE Tunnel ID，是的不同 network 的流量走不通的 tunnel。
（3）網路節點的 br-tun 上，neutron 將 GRE Tunnel ID 轉發了一一對應的內部 VLAN Tag，使得網路流被不同的服務處理。
（4）網路節點的 br-int 上連線的 DHCP 和 L3 agent 使用 Linux network namespace 進行隔離。

請參考：

5. Neutron 租戶網路的安全性（security）

除了租戶的隔離性以外，

Neutron 還提供資料網路與外部網路的隔離性。預設情況下，所有虛機通往外網的流量全部走網路節點上的 L3 agent。在這裡，內部的固定 IP 被轉化為外部的浮動 IP 地址。這種做法一方面保證了網路包能夠回來，另一方面也隱藏了內部的 IP 地址。
Neutron 還是用 Linux iptables 特性，實現其 Security Group 特性，從而保證訪問虛機的安全性。
Neutron利用網路控制節點上的 network namespace 中的 iptables，實現了進出租戶網路的網路包防火牆，從而保證了進出租戶網路的安全性。

請參考下面的文章：

6. Neutron 租戶網路的可用性（HA）和擴充套件性（Scalability）

OpenStack 雲中可能用於成千上萬臺虛機，成千上萬個租戶，因此，Neutron 的資料網路的可用性和擴充套件性非常重要。Neutron 中，這些特性包括幾個層次：

（1）軟體架構上，Neutron 實現OpenStack 標準的去中心化架構和外掛機制，有效地保證了其擴充套件性。

（圖14.來源於 google）

（2）Neutron 為每個 provider/tenant network 分配一個唯一的 segmentation_id。該 ID 的數目是影響可擴充套件性的因素之一。在規模不大的私有云中，往往是用 VLAN 模式，簡單、可靠、能夠滿足規模要求；而在大型的私有云或者公有云中，往往使用 VxLAN。

網路型別	ID 數目	說明
flat	1	通常不用於資料網路，因為其不具備租戶隔離型。
vlan	4094	802.1Q 定義了 VLAN ID 佔 12-bit
GRE	16777216	RFC 2637 定義的 GRE 的 ID 佔 24-bit
VxLAN	16777216	RFC 7348 定義的 VxLAN 的 ID 佔 24-bit

（3）分散式 Virtual Router （DVR）和分散式 DHCP agent

預設情況下，L3 agent 和 DHCP agent 部署在網路節點上，這在大規模的雲環境中可能會存在效能問題。這是 Blueprint。

（左圖-圖15，未使用DVR。右圖-圖16，使用了DVR-分散式虛擬路由器。來源。）

通過使用 DVR，L3 轉發和 NAT 會被分佈在計算節點上，這使得計算節點變成了網路節點，這樣集中式的網路節點的負載就被分擔了。這個 Blueprint 實現了分散式的 DHCP Agent，這進一步釋放了集中式網路節點的壓力。

（4）L2 Population 和 ARP Responder：這兩個功能大大減少了網路的複雜性，提交了網路效率，從而促進了擴充套件性。

（4）高可用：雖然 Neutron 在高可用實現方面走在了 OpenStack 所有元件的前列，目前已經實現了多種 L3 Agent 的 HA 方案，但是，這些方案目前還不是很成熟，大都是在 Juno 版本中新增的，而且現在還在持續優化中，離正式進入生產環境還有一些距離。但是，我們可以相信，再經過兩三個版本，這些功能就能夠進入生產環境。

請參考這個文章：

7. Neutron 擴充套件服務（extension service）

在實際的網路中，除了網路的核心功能以外，還有一些普遍應用的網路服務，比如 VPN， Load Balancing 和 Firewall 等。Neutron 針對這些普遍的服務，也提供了參考實現。需要注意的是，目前這些實現更多類似於一種原型實現（PoC），其目的是向給產品實現者提供一種參考架構，因此，這些功能往往還不能直接應用到生產系統。正是考慮到這些特點，目前 Neutron 專案組將這些程式碼挪出了 Neutron的主程式碼庫。

具體請參考：

8. Neutron REST API

Neutron 的 neutron-server 模組提供 REST API 來操作上文提到的各種網路元件，包括 network，subnet，port，router 等。可參考上圖13。具體的 API 可以參考這裡和這裡。

9. Neutron 的實現框架

Neutron 中包含了大量內容。那Neutron 是如何實現這麼多概念的呢？

9.1 服務分類

neutron 採用『分而治之』策略，同時採取外掛式框架。首先Neutron把服務分類。

它把所提供的服務分為兩大類：

第一類是核心服務，通過 core plugin 實現。在 /etc/neutron/neutron.conf 中的 core_plugin 配置項中指定。從這個配置項名稱看，一個 Neutron 環境應該只能支援一個核心服務。現在主要支援的核心服務見下面列表。從列表可以看出來，除了 ML2 是Neutron 社群實現的，其它都是各個廠家自己實現的。因此，neutron 的預設 core plugin 就這是 ml2。ml2 是 neutron的核心外掛，所有neutron內建API請求都會被它處理。它主要實現了最核心的 network、subnet、port等概念，實現了這幾種資源的操作API。

Short name	Class name
bigswitch	neutron.plugins.bigswitch.plugin:NeutronRestProxyV2
brocade	neutron.plugins.brocade.NeutronPlugin:BrocadePluginV2
cisco	neutron.plugins.cisco.network_plugin:PluginV2
embrane	neutron.plugins.embrane.plugins.embrane_ovs_plugin:EmbraneOvsPlugin
hyperv	neutron.plugins.hyperv.hyperv_neutron_plugin:HyperVNeutronPlugin
midonet	neutron.plugins.midonet.plugin:MidonetPluginV2
ml2	neutron.plugins.ml2.plugin:Ml2Plugin
mlnx	neutron.plugins.mlnx.mlnx_plugin:MellanoxEswitchPlugin
nec	neutron.plugins.nec.nec_plugin:NECPluginV2
nicira	neutron.plugins.nicira.NeutronPlugin:NvpPluginV2
plumgrid	neutron.plugins.plumgrid.plumgrid_plugin.plumgrid_plugin:NeutronPluginPLUMgridV2
ryu	neutron.plugins.ryu.ryu_neutron_plugin:RyuNeutronPluginV2

第二類是非核心服務。這類服務通過 service plugin 實現。 service plugin 主要是用來支援除 core plugin 之外的其他資源的操作API的。neutron核心資源上面已經講過，就包含很少的幾個（network、subnet、port等），其他資源如 qos、router、floatingips、fwaas、lbaas、vpnaas 等的操作API都需要通過相應的plugin來支援，有部分老版本的plugin的實現是在neutron專案中（services目錄下），而新版本的資源一般都是在各自獨立的專案中，如neutron_lbaas、neutron_fwaas、neutron_vpnaas，減少與neutron主專案的耦合，便於各自獨立快速的發展更新。當前支援的主要 service plugin 包括：

Short name	Class name
dummy	neutron.tests.unit.dummy_plugin:DummyServicePlugin
router	neutron.services.l3_router.l3_router_plugin:L3RouterPlugin
firewall	neutron.services.firewall.fwaas_plugin:FirewallPlugin
lbaas	neutron.services.loadbalancer.plugin:LoadBalancerPlugin
metering	neutron.services.metering.metering_plugin:MeteringPlugin
vpnaas	neutron_vpnaas.services.vpn.plugin:VPNDriverPlugin

9.2 ML2

因為 ML2 是 Neutron 的核心，因此要重點講一下。它的配置檔案是 /etc/neutron/plugins/ml2/ml2_conf.ini。它主要實現了兩種驅動：

型別驅動：Neutron 支援的每一種網路型別都有實現一個型別驅動。包括：
- Flat：這種型別只能作為 Provider network type
- VLAN
- GRE
- VXLAN
機制驅動：機制驅動是實現某個網路型別所採用的機制即網路元件。主要包括：
- Arista
- Cisco
- Nexus
- Hyper-V Agent
- L2 Population
- Linuxbridge
- Open vSwitch
- OpenDaylight
- OpenContrail
- 各廠家自己的

因此，可以簡單認為，ML2 的主要工作就是實現這幾種網路元件支援的網路。要注意，型別驅動和機制驅動不是完全對應關係。下面是它們之間的對照表：

備註：L2 population 是一種特殊的機制驅動，它旨在優化 VXLAN 和 GRE 環境中的 BUM（廣播，未知目的地址，多播）網路包。它必須和 linux bridge 或者 OVS 一起工作，不能單獨使用。

9.3 Agent 代理

前面講的是neutorn 要實現的目標，也就是要提供的網路服務。對所有的服務，都需要在控制、網路、計算等節點上執行相應的操作，比如建立網橋、建立名稱空間、建立埠、建立 iptables 規則等。這些操作是通過稱為 Agent 的多種元件來完成的。它們要麼接收別人發過來的指令，要麼自己通過掃描等行為，來觸發具體行動，完成所需執行的內容。

Agent 也分為兩大類：

L2 agent：對應於核心服務。這是完成 ML2 所需操作的agent。基本上每種機制驅動都有對應一個 L2 agent。每個agent 通常會支援一種機制驅動，但也可能支援多種。L2 Agent 執行在網路和計算節點上。

L2 agent 名稱	配置檔案	安裝包名稱	作用	所支援的機制驅動
Open vSwitch agent	openvswitch_agent.ini	neutron-openvswitch-agent	通過配置 Open vSwitch 來實現 L2 網路	Open vSwitch; L2 population
Linux bridge agent	linuxbridge_agent.ini	neutron-linuxbridge-agent	通過配置 Linux bridge 來實現 L2 網路	Linux bridge;L2 population
SRIOV Nic Switch agent	sriov_agent.ini	neutron-sriov-nic-agent	通過配置 PCI virtual function 來實現 L2 網路	SRIOV
MacVTap agent	macvtap_agent.ini	neutron-macvtap-agent	通過配置 MacVTap 裝置來實現 L2 網路	MacVTap

其它驅動：對應於非核心服務。這些驅動執行在網路節點上。

看下元件部署示意圖：

可以使用 neutron 命令 agent-list 來檢視所有 agent：

9.4 neutron 之內以及與其它元件間通訊

openstack 的核心是虛擬機器，neutron，nova 以及其它模組都是為虛擬服務的。在虛機啟動時，nova 和 neutron 需要緊密配合。簡單的nova 和 neutron互動示意圖如下：

這裡面的通訊機制包括直接API呼叫（nova 呼叫 neutron api），網路物件掃描（L2 agent 在計算節點上持續掃描nova 建立的 tap 裝置，然後配置 br-int 和 br-tun、安全組規則、和neutorn server 互動等）。關於虛機建立過程，請參閱 OpenStack 建立虛機過程簡要彙總。

9.4.1 neutron server 通知 L2 和 L3 agent

L2 agent：主要包括安全組規則更新和port update。

L3 agent：主要是 router 更新。

9.4.2 l2 agent 主動掃描 tap 裝置

當掃描到有新增的埠時，

當掃描到有埠刪除時，

9.4.3 跨元件通知 notification

另外一個元件間通訊機制是 notification，即通過RPC傳送通知。neutron_server.ini 中能配置的幾種 notification 包括：

notify_nova_on_port_data_changes：當neutron 將繫結到一個虛機的浮動IP在不釋放的情況下關聯到一個新虛機時，需要給nova 傳送原來關聯的虛機的資訊，以使它能修改資料庫。程式碼在這裡。
notify_nova_on_port_status_changes：預設值為 true。當 neutron port 狀態有變化，在neutron 做資料庫修改之前，向 nova 傳送通知。程式碼在這裡。
dhcp_agent_notification：預設值為 true。表示允許傳送資源操作通知給 dhcp agent。其傳送時機包括：
- network.create.end
- network.update.end