openstack neutron基本原理 一、Openstack網絡基礎 二、Nova虛拟機啟動時的網絡處理 三、Neutron的軟體實作 四、Neutron OVS上的流表分析 Q&A

分享正文

大家好，很高興今天能與大家分享一些Neutron的知識。今天分享的思路是：OpenStack網絡基礎、Neutron的軟體實作、Nova虛拟機啟動時的網絡處理以及OVS流表分析。

一、Openstack網絡基礎

下面對Openstack和Neutron的介紹，要從幾個關鍵詞入手。

1. 三代網絡

在網絡這一口，OpenStack經曆了由nova-network到Quantum再到Neutron的演進過程。我們直覺地來看看三代網絡的對比分析：

出現 版本	支援組 網模式	優點	缺點	适用場景
Nova-network	早期	Flat Flat Dhcp VLAN	性能出色 工作穩定 支援multi-host部署 以實作HA	網絡管理不獨立 功能不夠靈活 組網方式受限	對性能和穩定性要求比較高；中小規模網絡；網絡運維成本有限；私有雲環境
Quantum	Folsom	Flat Flat Dhcp VLAN Overlay	獨立的網絡管理 支援大二層 支援多廠商插件	缺乏HA機制 各廠商插件無法 共同運作	基本上已經都跟進到了Neutron
Neutron	Havana	Flat Flat Dhcp VLAN Overlay	繼承了Quantum的優點 功能上更為豐富 網絡相容性強 開始引入SDN的思想	代碼結構複雜 工作不夠穩定 HA機制仍缺乏大規模商用的檢驗	對功能要求比較多或希望向SDN演進；大規模網絡或對可擴充性要求高；有專業的網絡運維團隊；公有雲環境

• Nova-network是隸屬于nova項目的網絡實作，它利用了linux-bridge（早期，目前也支援OVS）作為交換機，具備Flat、Flat DHCP、VLAN三種組網模式。優點是性能出色，工作穩定，支援multi-host部署以實作HA；缺點是網絡子產品不獨立，功能不夠靈活，組網模式也比較受限。
• Quantum作為獨立的網絡管理項目出現在F版本，除了linux-bridge外還支援OVS，以及以及其他商業公司的插件，組網模式上增加了對GRE和VxLAN兩個Overlay技術的支援。優點是功能靈活，支援大二層組網；缺點是集中式的網絡節點缺乏HA，而且各廠商插件無法同時在底層網絡中運作。
• Neutron出現在H版本，由來是Quantum和一家公司的名稱沖突而改名。Neutron對Quantum的插件機制進行了優化，将各個廠商L2插件中獨立的資料庫實作提取出來，作為公共的ML2插件存儲租戶的業務需求，使得廠商可以專注于L2裝置驅動的實作，而ML2作為總控可以協調多廠商L2裝置共同運作。Neutron繼承了Quantum對大二層的支援，還支援L2 PoP，DVR，VRRP，HA等關鍵功能，內建了很多L4-L7的網絡服務，一些blueprint也正在積極開發中，如SFC等。優點是開始引入SDN思想，功能上更為豐富，網絡相容性強；缺點是代碼結構複雜，工作不夠穩定，HA機制仍缺乏大規模商用的檢驗。

從應用場景來看，Nova-network組網模式過于簡單，一些複雜的網絡需求無法實作（比如兩個公司合并，有大量IP重合的VM要遷移到一個平台，而且要求遷移後都要用原來的IP）。不過由于其簡單穩定的特點，仍适合于中小型企業的生産環境；Quantum的實際部署目前基本都跟進到了Neutron；Neutron的大二層組網，适合于雲計算規模的生産環境，但是由于分布式和HA機制仍不夠成熟，是以目前多見于私有雲和小規模共有雲的部署，大規模的公有雲仍然難以使用Neutron實作。

2. 四種組網模型

說完了基本特征與應用場景，下面開始對上述提到的一些網絡問題進行詳細的描述。我們抛開技術，結合圖例來抽象地看看不同的組網模型。當然，以下模型的實作不僅僅局限于三張圖中的方式。

• Flat模型最為簡單，所有的虛拟機共用一個私有IP網段，IP位址在虛拟機啟動時完成注入，虛拟機間的通信直接通過HyperVisor中的網橋轉發，公網流量在該網段的網關上進行NAT（Nova-network實作為開啟nova-network主機核心的iptables，Neutron實作為網絡節點上的l3-agent）。Flat DHCP模型與Flat差別在于網橋中開啟了DHCP程序，虛拟機通過DHCP消息獲得IP位址（Nova-network實作為nova-network主機中的dnsmaq，Neutron實作為網絡節點上的dhcp-agent）。

• VLAN模型引入了多租戶機制，虛拟機可以使用不同的私有IP網段，一個租戶可以擁有多個IP網段。虛拟機IP通過DHCP消息擷取IP位址（Nova-network實作為nova-network主機中的dnsmaq，Neutron實作為網絡節點上的dhcp-agent）。網段内部虛拟機間的通信直接通過HyperVisor中的網橋轉發，同一租戶跨網段通信通過網關路由，不同租戶通過網關上的ACL進行隔離，公網流量在該網段的網關上進行NAT（Nova-network實作為開啟nova-network主機核心的iptables，Neutron實作為網絡節點上的l3-agent）。如果不同租戶邏輯上共用一個網關，則無法實作租戶間IP位址的複用。

• Overlay模型（主要包括GRE和VxlAN隧道技術），相比于VLAN模型有以下改進。1）租戶數量從4K增加到16million；2）租戶内部通信可以跨越任意IP網絡，支援虛拟機任意遷移；3）一般來說每個租戶邏輯上都有一個網關執行個體，IP位址可以在租戶間進行複用；4）能夠結合SDN技術對流量進行優化。

3. 三類節點和三類網絡

看過抽象的組網模型，下面我們來介紹組網具體的實作技術。下面的介紹都是針對Neutron的，對nova-network和Quantum将不做讨論。

• 3類節點——管理節點：實作鏡像、塊存儲、身份認證、前端等服務，運作nova-compute的排程子產品以及nova api-server；計算節點：實作nova-compute，以及neutron的各種agent（一般不包括l3-agent，DVR除外）；網絡節點，：實作neutron各種agent。注意，由于OpenStack為分布式架構實作，是以neutron-server既可以運作在控制節點，也可以運作在網絡節點。
• 3種網絡——OpenStack内部子產品之間的互動發生在管理網絡，虛拟機之間的通信發生在資料網絡，而External Network/API Network網絡是連接配接外網的，無論是使用者調用Openstack API，還是虛拟機與外網間的互通都需要經過這個網絡。

目前OpenStack通常采用out-of-bound方式進行部署，管理網絡與另外兩個網絡是獨立的，管理節點上一般也不會承載Openstack的業務流量，下面的分析中網絡隻涉及資料網絡與External Network/API Network網絡，節點隻涉及計算節點和網絡節點。

4. 兩張圖例

有了以上知識作為基礎，就可以來分析Openstack中的網絡通信了。由于OpenStack中容器的通信機制目前尚不成熟，并且有專門的項目Kuryr去實作容器相關網絡技術，以下内容将不涉及OpenStack中的容器通信。

以下将通過兩張圖來分析Neutron中的VLAN組網模型，HyperVisor中的網絡裝置以OpenvSwitch為例。這三張圖中每一個資訊都是有用的，把這些資訊完全弄懂了，Neutron的組網也就能基本掌握了，Overlay模型與VLAN模型的差別隻在于将圖中的br-eth1替換成br-tun即可，具體隧道如何進行封裝，稍後我們再詳細介紹。

第一張圖是計算節點上的網絡實作。以虛拟機發出流量方向為例，從虛拟機處開始分析：

1)流量經由虛拟機IP核心交給虛拟網卡處理，虛拟網卡由TAP軟體實作，TAP允許使用者态程式向核心協定棧注入資料，它可以運作于虛拟機作業系統之上，能夠提供與硬體以太網卡完全相同的功能。

2)TAP裝置并不是直接連接配接到OVS上的，而是通過Linux bridge中繼到ovs br-int上，其原因在于ovs無法實作linux bridge中一些帶狀态的iptables規則，而這些規則往往用于以虛拟機為機關的安全組（security group）功能的實作。qbr是quantum bridge的縮寫，Neutron中沿用了Quantum的叫法。

3)linux bridge與ovs br int間的連接配接通過veth-pair技術實作，qvb代表quantum veth bridge，qvo代表quantum veth ovs。veth-pair用于連接配接兩個虛拟網絡裝置，總是成對出現以模拟虛拟裝置間的資料收發，其原理是反轉通訊資料的方向，需要發送的資料會被轉換成需要收到的資料重新送入核心網絡層進行處理。veth-pair與tap的差別可以簡單了解為veth-pair是軟體模拟的網線，而tap是軟體模拟的網卡。

4)ovs br-int是計算節點本地的虛拟交換裝置，根據neutron-server中OVS Plugin的指導，完成流量在本地的處理：本地虛拟機送入的流量被标記原生VLAN tag，送到本地虛拟機的流量被去掉原生VLAN tag，本地虛拟機間的2層流量直接在本地轉發，本地虛拟機到遠端虛拟機、網關的流量由int-br-eth1送到ovs br-eth1上（在Overlay模型中送到ovs br-tun上）。注意，無論是VLAN模型還是Overlay模型，由于br-int上VLAN數量的限制，計算節點本地最多支援4K的租戶。

5)ovs br-int與ovs br-eth1間的連接配接通過veth-pair技術實作。

6)ovs br-eth1将該計算節點與其他計算節點、網絡節點連接配接起來，根據neutron-server中OVS Plugin的指導，完成流量送出、送入本地前的處理：根據底層實體網絡租戶VLAN與本地租戶VLAN間的映射關系進行VLAN ID的轉換（Overlay模型中此處進行隧道封裝，并進行VNI與本地租戶VLAN ID間的映射）。由于底層實體網絡中VLAN數量的限制，VLAN模型最多支援4K的租戶，而Overlay模型中，24位的VNI最多支援16million的租戶。

7)ovs br-eth1直接關聯實體主控端的硬體網卡eth1，通過eth1将資料包送到實體網絡中。Overlay模型中ovs br-tun通過TUN裝置對資料包進行外層隧道封裝并送到HyperVisor核心中，核心根據外層IP位址進行選路，從硬體網卡eth1将資料包送到實體網絡中。TUN與TAP的實作機制類似，差別在于TAP工作在二層，而TUN工作在三層。

第二張圖是網絡節點上的網絡實作，以流量流入網絡節點方向為例，從底層實體網絡流量通過eth1進入ovs br-eth1（Overlay模型中為ovs br-tun）開始分析：

1)ovs br-eth1将網絡節點與計算節點連接配接起來，根據neutron-server中OVS Plugin的指導，完成流量送入網絡節點前的處理：根據底層實體網絡租戶VLAN與本地租戶VLAN間的映射關系進行VLAN ID的轉換（Overlay模型中此處進行解封裝，并進行VNI與本地租戶VLAN ID間的映射）。注意，雖然同一租戶在底層實體網絡上的VLAN ID（Overlay模型中為VNI）唯一，但是在網絡節點與計算節點，不同計算節點中同一租戶對應的原生VLAN ID可能有所不同。另外由于網絡節點也要在ovs br-int上使用原生VLAN，而租戶跨網段流量與公網流量都要經過網絡節點，是以使用單個網絡節點時，Neutron最多能支援4K租戶，可采用部署多個網絡節點的方式來解決這一問題。

2)送入網絡節點的流量，由ovs br-eth1（ovs br-tun）通過veth-pair送給ovs br-int，ovs br-int連接配接了本地不同的namespace，包括實作dhcp功能的dhcp-agent——dnsmasq，以及實作路由功能的l3-agent——router。Dnsmasq負責給對應租戶的虛拟機配置設定IP位址，而router負責處理租戶内跨網段流量以及公網流量。不同的租戶有不同的dnsmasq和router執行個體，是以不同租戶間可以實作IP位址的複用。

3)Router namesapce通過qr接口（Quantum Router）接收到租戶内跨網段流量以及公網流量，在ns的IP核心中對跨網段流量進行路由，改寫MAC位址并通過相應的qr接口向ovs br-int送出資料包。在ns的IP核心中對公網流量進行NAT，并通過qg接口（Quantum Gateway）發送給ovs br-ex。

4)Ovs br-ex通過關實體聯主控端的硬體網卡eth1将流量送至Internet路由器。

5)上述兩幅圖中，ovs br-int與ovs br-ex間有直連，據說主要是防止l3-agent出現問題時能夠保證流量不中斷，但實際上看來很少出現此問題。

5. Neutron網絡全家福

上圖是在網上看過的更加細緻，更為全面的一張圖（http://blog.csdn.net/canxinghen/article/details/46761591#comments），圖中清晰地展示了Neutron對多種L2技術（VLAN、VxLAN、GRE）共同運作的支援。圖中的mellonax是intel等硬體廠商搞出的具備轉發功能的網卡，能夠避免虛拟交換機帶來的資源消耗，并能夠加快轉發速率。一塊這樣的網卡能虛拟出63個VF，每個VF就好像一個獨立的實體網卡一樣，通過将VF直接挂到虛拟機上，能夠實作轉發性能的大幅度提高。

以上介紹了OpenStack中網絡元件的演進，以及Neutron組網的基本原理。下面我們将對Neutron的軟體實作進行簡單的介紹。

二、Nova虛拟機啟動時的網絡處理

裝置啟動了，網絡有了，可是現在還沒有虛拟機。下面我們來看看nova虛拟機啟動時的網絡處理過程。

從頭開始講。虛拟機的啟動通常來自于控制節點指令行的nova boot，該指令被組裝成REST API送到nova-api。Nova-api與neutron-server幹的是一樣的活：接收REST請求，調nova-scheduler跑一些排程機制，計算出虛拟機部署的位置，然後通過rpc與相應計算節點上的agent——nova-compute進行通信，而啟動虛拟機的實際工作由nova-compute完成。

當然，以上過程與網絡并沒有發生什麼關系，這裡不做深入分析，大家要是有興趣可參考http://www.linuxqq.net/archives/1277.html。

假定nova-compute已經通過rpc收到了開始幹活的指令，我們就從這裡開始漫長的代碼分析。在此之前，先來看一看OpenStack元件層面的調用流程。這裡借用OpenStack大神SammyLiu的一張圖吧，圖中1-6步驟依次做了這麼幾件事：

• Nova-compute向neutron-server請求虛拟機對應的Port資源。
• Neutron-server根據neutron-database生成Port資源。
• Neutron-server通知Dhcp agent虛拟機資訊。
• Dhcp agent将虛拟機資訊通知給dhcp server。
• 虛拟機接入并啟動。
• 虛拟機從dhcp server處獲得IP位址。

最後一步就是傳統的dhcp的互動過程，這裡就不講了，下面來看1-5的實作。時間有限，代碼不再一步步回溯了，詳見SDNLAB“網絡虛拟化”專題的後續文章，這裡給出代碼的主體思路。

• Nova-compute向neutron-server發送create_port的REST API請求，生成新的Port資源。
• Neutron-server收到該REST請求，通過APIRouter路由到ML2的create_port方法。該方法中，獲得了neutron-database新生成的Port，并通知ML2 Mechanism Driver該Port的生成。
• Nova-compute向neutron發送update_port的REST API請求，
• Neutron-server收到該REST請求，通過APIRouter路由到ML2的update_port方法。該方法中，在neutron-database更新該Port的狀态，并根據ML2 Mechanism Driver的不同，決定後續的處理：若Mechanism Driver為hyperv/linuxbridge/ofagent/openvswitch，則需要通過ML2的update_port方法中執行rpc遠端調用update_port；對于其餘的Mechanism Driver，ML2的update_port方法調用其的update_port_postcommit方法進行處理，這些Mechanism Driver可能使用非rpc方式與自身的agent通信（如REST API、Netconf等）。
• ML2執行完update_port方法後，Port資源在wsgi中對應的Controller執行個體通過DhcpAgentNotifyAPI執行個體rpc通知給網絡節點上的dhcp agent（也可能通過一些排程機制通知給分布在計算節點上的dhcp agent）。
• Dhcp agent收到該rpc通知，通過call_driver方法将虛拟機MAC與IP的綁定關系傳遞給本地的DHCP守護程序Dnsmaq。
• Nova-compute通過libvirt driver的spawn方法将虛拟機接入網絡，然後啟動虛拟機。

到這裡，虛拟機啟動過程中的網絡處理就都結束了，虛拟機間就可以開始通信了。下面開始介紹Neutron中OVS的流表邏輯，看看OVS是怎麼支援虛拟機間的通信的。

三、Neutron的軟體實作

5. 5類Neutron元件

在架構設計上， Neutron沿用了OpenStack完全分布式的思想，各元件之間通過消息機制進行通信，使得Neutron中各個元件甚至各個程序都可以運作在任意的節點上，如下圖所示。這種微核心的架構使得開發者可以集中精力在網絡業務的實作上。目前Neutron提供了衆多的插件與驅動，基本上可以滿足各種部署的需要，如果這些還難以支撐實際所需的環境，則可以友善地在Neutron的架構下擴充插件或驅動。

• Neutron-server可以了解為一個專門用來接收Neutron REST API調用的伺服器，然後負責将不同的rest api分發到不同的neutron-plugin上。
• Neutron-plugin可以了解為不同網絡功能實作的入口，各個廠商可以開發自己的plugin。Neutron-plugin接收neutron-server分發過來的REST API，向neutron database完成一些資訊的注冊，然後将具體要執行的業務操作和參數通知給自身對應的neutron agent。
• Neutron-agent可以直覺地了解為neutron-plugin在裝置上的代理，接收相應的neutron-plugin通知的業務操作和參數，并轉換為具體的裝置級操作，以指導裝置的動作。當裝置本地發生問題時，neutron-agent會将情況通知給neutron-plugin。
• Neutron database，顧名思義就是Neutron的資料庫，一些業務相關的參數都存在這裡。
• Network provider，即為實際執行功能的網絡裝置，一般為虛拟交換機（OVS或者Linux Bridge）。

6 兩類Plugin

• Core-plugin，Neutron中即為ML2（Modular Layer 2），負責管理L2的網絡連接配接。ML2中主要包括network、subnet、port三類核心資源，對三類資源進行操作的REST API被neutron-server看作Core API，由Neutron原生支援。其中：

Network	代表一個隔離的二層網段，是為建立它的租戶而保留的一個廣播域。subnet和port始終被配置設定給某個特定的network。Network的類型包括Flat，VLAN，VxLAN，GRE等等。
Subnet	代表一個IPv4/v6的CIDR位址池，以及與其相關的配置，如網關、DNS等等，該subnet中的 VM 執行個體随後會自動繼承該配置。Sunbet必須關聯一個network。
Port	代表虛拟交換機上的一個虛機交換端口。VM的網卡VIF連接配接 port 後，就會擁有 MAC 位址和 IP 位址。Port 的 IP 位址是從 subnet 位址池中配置設定的。

• Service-plugin，即為除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要實作L3-L7的網絡服務。這些plugin要操作的資源比較豐富，對這些資源進行操作的REST API被neutron-server看作Extension API，需要廠家自行進行擴充。

最開始曾經提到，“Neutron對Quantum的插件機制進行了優化，将各個廠商L2插件中獨立的資料庫實作提取出來，作為公共的ML2插件存儲租戶的業務需求，使得廠商可以專注于L2裝置驅動的實作，而ML2作為總控可以協調多廠商L2裝置共同運作”。在Quantum中，廠家都是開發各自的Service-plugin，不能相容而且開發重複度很高，于是在Neutron中就為設計了ML2機制，使得各廠家的L2插件完全變成了可插拔的，友善了L2中network資源擴充與使用。

ML2作為L2的總控，其實作包括Type和Mechanism兩部分，每部分又分為Manager和Driver。Type指的是L2網絡的類型（如Flat、VLAN、VxLAN等），與廠家實作無關。Mechanism則是各個廠家自己裝置機制的實作，如下圖所示。當然有ML2，對應的就可以有ML3，不過在Neutron中L3的實作隻負責路由的功能，傳統路由器中的其他功能（如Firewalls、LB、VPN）都被獨立出來實作了，是以暫時還沒有看到對ML3的實際需求。

===================== 代碼分析 =========================

一般而言，neutron-server和各neutron-plugin部署在控制節點或者網絡節點上，而neutron agent則部署在網絡節點上和計算節點上。我們先來簡單地分析控制端neutron-server和neutron-plugin的工作，然後再分析裝置端neutron-agent的工作。

具體的代碼這次分享沒有時間講了，隻能講個大緻的輪廓和思路。有興趣深入研究的同志，可以關注SDNLAB上“網絡虛拟化”專題的後續更新。

（注意，以前廠商開發的L2 plugin跟ML2都存在于neutron/plugins目錄下，而可插拔的ML2裝置驅動則存在于neutron/plugins/ml2/drivers目錄下）

1. 控制端的實作

從neutron-server的啟動開始說起。neutron-server的啟動入口在neutron.server.__init__中，主函數中主要就幹了兩件事，第一是下圖l 48處啟動wsgi伺服器監聽Neutron REST API，第二是在l 52啟動rpc服務，用于core plugin與agent間的通信，兩類服務作為綠色線程并發運作。從SDN的角度來看，wsgi負責Neutron的北向接口，而Neutron的南向通信機制主要依賴于rpc來實作（當然，不同廠家的plugin可能有其它的南向通信機制）。

• 北向方面，Neutron的wsgi通過Paste工具進行模闆化部署，它接收Neutron REST API的業務請求，然後通過APIRouter将其分發給對應的plugin。
• Neutron内部，plugin與資料庫互動，擷取業務的全局參數，然後通過rpc機制将操作與參數傳給裝置上的Agent（某些plugin和ML2 Mechanism Driver通過别的方式與Agent通信，比如REST API、NETCONF等）。
• RPC機制就可以了解為Neutron的南向通信機制，Neutron的RPC實作基于AMPQ模型，plugins和agents之間通常采用“釋出——訂閱”模式傳遞消息，agents收到相應plugins的***NotifyApi後，會回調裝置本地的***CallBack來操作裝置，完成業務的底層部署。

2. 裝置端的實作

控制端neutron-server通過wsgi接收北向REST API請求，neutron-plugin通過rpc與裝置端進行南向通信。裝置端agent則向上通過rpc與控制端進行通信，向下則直接在本地對網絡裝置進行配置。Neutron-agent的實作很多，彼此之間也沒什麼共性的地方，下面選取比較具有代表性的ovs-neutron-agent的實作進行簡單的介紹。

Ovs-neutron-agent的啟動入口為/neutron/plugins/openvswitch/agent/ovs-neutron-agent.py中的main方法，其中負責幹活的兩行代碼在l 1471和l 1476。L 1471執行個體化了OVSNeutronAgent類，負責在本地配置OVS，而l 1476則啟動了與控制端的rpc通信。

OVSNeutronAgent的執行個體化過程中依次幹了6個工作：啟動ovs br-int網橋；啟動rpc；啟動ovs br-eth1；啟動ovs br-tun；執行個體化OVSSecurityGroupAgent；開始rpc輪詢與監聽。

rpc_loop做的工作主要就是輪詢一些狀态，根據這些狀态，進行相應的操作。比如一旦探測到本地的OVS重新開機了（l 1295，l 1309），就重新建立本地的網橋（l 1294-1300），并重新添加port（l 1336）；再比如一旦rpc監聽到update_port事件（l 1309），則在本地使能相應的port（l 1336）。

ovs-neutron-agent的啟動也就是這些工作了，啟動完畢後，便開始了與相應plugin（OVS Plugin或者OVS Mechanism Driver）的rpc通信。

================= 代碼分析 ====================

Neutron的軟體實作就簡單地介紹到這裡了，下一節我們來具體看看Neutron中各個OVS上的流表邏輯是怎樣的。

四、Neutron OVS上的流表分析

在具體介紹OVS的工作機制之前，大家要先了解OVS并不是Neutron網絡實作的唯一選擇。

實際上，Neutron中底層網絡的實作千差萬别：有的agent本地是真正處理資料流的網絡裝置（OVS，Router，LoadBalancer等），而有的agent本地是SDN控制器（如ODL、ONOS、OpenContrail、NSX等）。上述Neutron底層網絡的兩種模型示意如下。

第一種模型中Neutron相當于SDN控制器，plugin與agent間的通信機制（如rpc）就相當于簡單的南向協定。第二種模型中Neutron作為SDN應用，将業務需求告知SDN控制器，SDN控制器再通過五花八門的南向協定遠端控制網絡裝置。當然，第二種模型中也可以把Neutron看做超級控制器或者網絡編排器，去完成OpenStack中網絡業務的集中分發。

以下我們講的是第一種模型中OVS處理資料流的工作機制。後一種模型中，SDN控制器也可以通過OpenFlow或者OVSDB來控制OVS處理資料流，對此本節暫時不進行讨論，後續也會有文章會詳細介紹ODL和ONOS等SDN控制器對Openstack的支援。

================== 分隔線 ======================

以Overlay組網模型對OVS的工作機制進行介紹，具體分為兩個角度：OVS實作L2的基本連接配接，OVS對連接配接機制的優化。

（一）L2基本連接配接的實作

複原一下通信場景，其中的網絡基礎請參考“OpenStack網絡基礎”一小節。圖中某租戶有兩個網段，分别用橙紅色和藍色表示，網段間的互通要經過網絡節點中的Router，網段内的通信不需要經過網絡節點中的Router。網段間的互通可分為3步：橙紅色網段通過網段内通信找到Router，Router進行路由，Router通過藍色網段的網段内通信轉發給目的地。Router上的路由是linux核心實作的，我們不去關心，是以可以說租戶内部通信都是基于網段内通信實作的。

Overlay模型中，網段内通信涉及ovs br-int和ovs br-tun，計算節點和網絡節點中兩類網橋的實作沒有什麼差別。概括地說，br-int負責在節點本地的網段内通信，br-tun則負責節點間的網段内通信。

在本節的場景内br-int實作為普通的二層交換機，即完成VLAN标簽的增删和正常的二層自學習與轉發，沒有必要進行過多的解釋，其代碼實作請參考“Neutron的軟體實作”中agent部分。

Br-tun采用多級流表實作節點間的網段内通信，下面直接通過圖示來看br-tun中多級流表的設計。圖中流表的序号不是固定的，可在neutron.plugins.openvswitch.agent.common目錄下的constants.py檔案中修改。

所有流經br-tun的資料包首先進入Table 0進行處理。Table 0對資料包的來源進行判斷，從與br-int相連的patch-int進入的資料包交給Table 1處理，從GRE或者VxLAN端口（不同節點間的隧道有不同的Port_ID）進入的分别交給Table 2、Table 3處理。Table 1根據資料包目的MAC位址判斷是否為單點傳播，是則送往Table 20，否則送往Table 21，Table 20根據（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關系将單點傳播包送到特定的隧道，Table 21将非單點傳播包複制後送到所有隧道。進入Table 2或者Table 3的資料包，首先判斷TUNNE_ID是否合法，是則添加原生VLAN_ID并送往Table 10，否則丢棄。Table 10記錄資料包的VLAN_ID，MAC、入端口以及TUNNEL_ID，将（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關系寫入Table 20，然後将資料包從與br-int相連的patch-int送出。

可見，上述過程就是标準MAC自學習在隧道中的擴充，無非就是将（VLAN_ID，MAC）到PORT_ID的映射變為了（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射。這種自學習仍然要依賴于泛洪來完成，引入l2_population或者SDN控制器後可以避免掉泛洪。

（二）連接配接機制的優化

OVS上，連接配接機制的優化主要展現在l2_population機制，以及對DVR（Distributed Virtual Router，分布式L3-agent）的支援。

2.1 L2_population

虛拟機在通信前，會發送ARP請求去解析目的MAC與目的IP間的映射關系，這一過程需要發送二層的廣播包。由（一）中的介紹可知，這會導緻隧道上的泛洪，這顯然是不能令人滿意的。

傳統網絡中ARP依賴于廣播泛洪的原因在于沒有一個集中式的控制平面，而Neutron中的資料庫存有所有虛拟機MAC位址與IP位址間的映射，可以說是一個天然原生的控制平面。是以有人提出了将該映射關系注入到OVS本地，在本地處理ARP廣播，以避免隧道上的泛洪，這就是l2_population。

L2_population的實作并不複雜，就是在1介紹的流水線中增加一個ARP Table去處理ARP Request。ARP Table中會事先存好MAC與IP的映射關系，如果ARP Table中比對ARP Request消息中的目的IP，則構造一個 ARP 響應包，從ARP Request的入端口傳回給虛拟機。如果比對失敗，則跳轉到 Table 21繼續泛洪。上述過程如下圖所示，之是以保留ARP Table到Table 21的跳轉，主要是為了防止l2_population出現問題。

L2_population的工作就是這麼簡單，卻可以大大減少不合意的隧道泛洪。其實dhcp也存在類似的問題，如果隻在網絡節點上放置dhcp-server，那麼所有的DHCP DISCOVER消息都要靠隧道泛洪發送到網絡節點上。當然，dhcp消息的數量和産生頻率遠遠趕不上arp，問題也不會那麼明顯。

解決dhcp存在的上述問題，一種思路是在Table 21上專門寫一條高優先級的dhcp流表項去比對dhcp廣播消息，并将所有的dhcp消息都封裝送到網絡節點的隧道。另外，也可以采用類似于l2_population的思路，從Table 1上專門寫一條高優先級的dhcp流表項去比對dhcp消息，這條流表項隻需要将dhcp消息通過相應的端口轉交給dhcp namespace即可。之是以用namespace實作，是因為Dhcp消息封裝在應用層，OpenFlow流表無法直接支援dhcp消息的封裝，是以這個活得由分布在計算節點上的dhcp namespace來完成。

第一種思路優點是實作簡單，但是一旦網絡節點發生單點故障，虛拟機便無法正常使用dhcp擷取IP，不過kilo版本中已經有人在多個網絡節點中實作了dhcp_loadbalance（https://blueprints.launchpad.NET/neutron/+spec/dhcpservice-loadbalancing）。第二種思路實作複雜一些，但能夠避免網絡節點單點故障帶來的問題，實作分布式dhcp。

2.2 DVR

上一小節簡略地提到了分布式的dhcp，這個工作社群有人提過但是反響并不是很大，而分布式的路由（Distributed Virtual Routing）卻很早就成為了社群的共識，并在Juno版本中給出了實作。

Neutron中Router用來實作同一租戶不同網段的虛拟機間的通信，這屬于東西向流量，具體可以分為兩種：1. 同一個實體節點上不同網段内的虛機之間的通信；2. 不同實體節點上不同網段内的虛機之間的通信。Router還用來實作虛拟機與Internet間的流量，這屬于南北向流量，具體也可分為兩種：1. 虛拟機通路Internet的流量，通常需要經過SNAT處理；2. Internet通路虛拟機的流量，可能需要經過DNAT處理。

在Neutron較早的版本中，上述流量都需要通過經過網絡節點上的Router來處理，一旦網絡節點故障或者網絡節點上的Router挂掉了，上述類型的流量也就都丢掉了。解決這一問題也有很多種思路：

• 一種是通過部署多個網絡節點，在多個網絡節點間做排程的，不過這種很難實作各個Router本身狀态的一緻性。
• 于是，就有了通過在Router間跑應用層面的VRRP來同步Router狀态，這種方式是很不錯的，VRRP協定也比較成熟。但是問題在于，大部分流量仍然需要“繞彎子”進行傳輸，如同一個實體節點上不同網段内的虛機之間的通信可能需要到另一個實體節點的Router上處理。
• 再于是，DVR就出現了，通過把Router分布在各個計算節點中，各類流量都可以得到最優的處理，也不會再有單點故障的問題了。

接下來對DVR的講解發生在下圖的場景中：某租戶有紅、綠兩個網段，兩台虛拟機vm1、vm2分屬兩個網段，分别位于計算節點CN1、CN2，租戶擁有一個DVR路由器r1，分布在兩個計算節點之上。假定vm1已經通過ARP獲得了CN 1中r1在紅色網段接口的MAC位址r1 red mac，現在vm1發起向vm2的ping request。

抛開流表的格式與下發的過程，先按照圖中序号來看一看DVR流表下發後通信各個階段的資料包特征。這裡規定（源MAC，目的MAC，源IP，目的IP位址）為資料包的特征4元組。

1)vm1發出的ping包特征為(vm1 mac, r1 red mac, vm1 ip, vm2 ip)，該資料包送至br-int-cn1。

2)br-int-cn1在之前ARP過程中學到了r1 red mac所在端口，将ping包直接轉發給CN1中的r1。

3)r1進行路由，得知目的虛拟機連接配接在綠色網段上，而且r1中存有目的虛拟機的靜态ARP表項，不需要進行ARP解析。于是CN1中的r1通過其綠色網段接口将ping包重新送回br-int-cn1。此時ping包特征為(r1 grn mac, vm2 mac, vm1 ip, vm2 ip)，br-int-cn1還不知道vm2連在哪裡，進行泛洪。

4)br-tun-cn1由br-int-cn1收到ping包，将源mac位址修改為全局唯一的dvr cn1 mac，并封裝好隧道，标記綠色網段的TUNNEL_ID，直接送往CN2。此時ping包被封裝在外層標頭内，其特征為(dvr cn1 mac, vm2 mac, vm1 ip, vm2 ip)。

5)br-tun-cn2收到後去掉外層標頭，打上綠色網段的原生VLAN标簽，送給br-int-cn2，此時ping包特征仍為(dvr cn1 mac, vm2 mac, vm1 ip, vm2 ip)。

6)br-int-cn2識别出這是CN1經過綠色網段送過來的流量，于是将源mac位址改回r1 grn mac并剝掉VLAN标簽。br-int-cn2還不知道vm2連在哪裡，就将ping包泛洪。此時ping包特征為(r1 grn mac, vm2 mac, vm1 ip, vm2 ip)。

7)vm2收到ping request，回複ping echo，反向的通信過程和上述基本一緻。

上述步驟給出了通信的外在特征，下面說明某些步驟内在的實作原理。

1)“r1中存有目的虛拟機的靜态ARP表項”，是因為各個部署了DVR的計算節點中，l3-agent都事先從neutron資料庫中擷取了虛拟機的網絡資訊，直接注入到了r1中。這是為了防止r1跨隧道泛洪擷取vm2的MAC位址（可以通過l2_population來實作）。

2)“将源mac位址修改為全局唯一的dvr cn1 mac”，是因為在所有計算節點上，r1位于相同網段的接口mac位址是一緻的，即CN1上的r1 red/grn mac與CN2上的r1 red/grn mac一緻。是以為了防止對端br-tun上的混亂， Neutron為每個部署了DVR的計算節點配置設定了全局唯一的dvr mac位址，br-tun在進行隧道傳輸前都需要進行源MAC位址的改寫。

“并封裝好隧道，标記綠色網段的TUNNEL_ID，直接送往CN2”，DVR要求開啟l2_population事先學習（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射，以避免隧道上的泛洪。

3)br-tun-cn2解封裝後，判斷流量由dvr cn1送過來，不進行自學習，直接将流量送給br-int-cn2。

4)br-int-cn2中實作存有所有部署了DVR的計算節點的全局唯一的MAC位址，因而可以識别dvr cn1送過來的流量，完成源MAC位址的回寫後進行轉發。

流表的邏輯跳轉圖如下所示（注意，某些Table的ID發生了變化，且未表示l2_population）。

Table 0對資料包的來源進行判斷，從與br-int相連的patch-int進入的資料包交給Table 1處理，從VxLAN端口（以VxLAN為例）進入的交給Table 4處理。Table 1判斷資料包是否為發向r1的ARP，或者其他發給r1的二層幀，如果是則丢棄（為了保證虛拟機送到r1的資料包隻在本地轉發）。如果Table 1判斷資料包是由r1發出來的，則将源mac位址改為CN1的dvr mac位址（為了避免對端br-tun上的混亂），然後送往Table 2。Table 2根據資料包目的MAC位址判斷是否為單點傳播，是則送往Table 20，否則送往Table 21。Table 20根據（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關系将單點傳播包送到特定的隧道，該映射關系可事先通過L2_populaiton學習到，也可以通過Table 10的觸發學習到。Table 21将非單點傳播包複制後送到所有隧道。進入Table4的資料包，首先判斷TUNNE_ID是否合法，是則添加原生VLAN_ID并送往Table 9，否則丢棄。Table 9判斷資料包源mac位址是否屬于dvr mac位址（由于示例場景比較簡單，圖中示例流表隻比對了CN2的dvr-cn2-mac），如果是直接送給br-int-cn1處理，否則轉給Table 10進行學習。Table 10記錄資料包的VLAN_ID，MAC以及TUNNEL_ID，将（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關系寫入Table 20，然後從與br-int相連的patch-int送出。下面給出各個流表項的标注，其中紅色的為新增的DVR表項。

DVR對于南北向流量的處理有兩種模型，第一種是SNAT在節點本地完成，第二種是SNAT仍需要到網絡節點進行，兩種模型分别示意如下。在節點本地進行SNAT則需要在計算節點的qr上為虛拟機配置設定浮動IP位址，而在網絡節點完成SNAT比較節省公網IP資源，具體選擇哪種模型，要視使用者實際的業務需求而定。

講到這裡，對Neutron OVS上的流表分析就結束了。當然，Neutron的學問遠遠不止這些，看看目前社群已經完成的或正在進行的項目吧（https://wiki.openstack.org/wiki/Neutron）。下一節将簡單地對kilo、liberty、mitaka版本中Neutron的blueprint進行整理，友善大家掌握社群的最新動态，将來能夠共同學習。

Q&A

Q1：能說下在opnfv中為何放棄了tap這一套機制麼？

A1：NFV對IO性能的要求很高，TAP是軟體實作的，性能上肯定會有問題。NFV現在傾向于硬體IO，如SRIOV，DPDK。

Q2：感覺tap這套機制僅僅是為了插入linux bridge，好利用iptable而已

A2：有可能吧，但NFV應該不太會想用軟的裝置做IO。

Q3：ovs-br1是ovs建立網橋嗎, ovs-br1是ovs建立網橋嗎

A3：這個是VLAN模型中，連接配接不同節點的網橋，主控端的實體網卡直接被add上去了，overlay模型中，沒有br-eth1，換成了br-tun。

Q4：可以連接配接本地namespace，實作dhcp.是通過控制器中轉的嗎？

A4：在Neutron的基本實作中，dhcp不做特殊處理。在Neutron的基本實作中，dhcp不做特殊處理。

Q5：網橋是linux自創的？還是ovs建立的？

A5：網橋看你用什麼裝置了，如果是linux-bridge就是linux-bridge-agent通過linux指令自建，如果是ovs，就是openvswitch-agent在裝置本地通過vsctl建立的。

Q6：你這個external網絡也是vlan模式對吧。--provider:network_type vlan 這個external網絡支援vxlan嗎？我看他可以建立gre vxlan vlan flat。

A6：其實無所謂，extenal是另外一個segment，可以是VLAN也可以是别的。沒關系，支援。都可以，external與别的segment并無本質差別。

Q7：tap網卡加入到網橋，是為了iptables使用友善。也可以采用流表實作相關功能？

A7：是的，目前有很多Neutron的子項目，都用OVS的流表支援IPTABLEs。比如DragonFlow。OVS 2.5.0版本還專門支援了OVN（Open Virtual Network），OVN對iptaqbles的支援比較好。

Q8：neutron不是不關心network節點網卡的外部網絡實作嗎？

A8：不是不關心external network，而是是不進行差別對待。隻不過在建立時，external需要admin權限才能建立，建立的過程與别的租戶的network沒有差別。

Q9：external是在vlan模型的麼？

A9：external不限于vlan，什麼都可以，對于external network，Neutron不進行差別對待。external就是一個網段，連在路由器的一個接口上，與其他segment的差別就在于，它的subnet是雲環境外的IP

Q10：如果external選擇了某個vlan的tag，出外網的封包會帶tag?

A10：這要看你external後面的實體交換機了，配置好了就不會在出外網時代VLAN tag。實體交換機需要手動配好。

Q11：metadata-agent dhcp-agent 可以在不同的節點上運作嗎？

A11：metadata-agent dhcp-agent 可以在不同節點運作，都支援HA。在Compute節點上也類似，完全分布式。

Q12：應該是最多支援4k個網絡，而不是4k個網絡，因為一個租戶可以有多個網絡。

A12: 不一定，即使是VLAN模型，如果路由器執行個體多了也可以超過4K個網絡。

Q13：br-int與ovs br-ex間有直連？這個沒見過，除非是vlan或flat模式，具體指的什麼結構，什麼版本？

A13：官方的資料上畫的，實際用途我也不是特别确定，一般情況下不會用到，網上有人說是為了防止L3-agent出現問題而做的備份。

Q14：metering功能怎麼樣，目前應用多嗎？

A14：這個我不太熟悉

Q15：各個廠商的plugin是可以共存的嗎？

A15：ML2中是可以共存的，沒有ML2之前不能共同跑在一個底層網絡裡。

Q16：遇到過dhcp的tap裝置和l3的qr裝置，在某種情況下（伺服器當機）tag會變為4095的情況嗎？

A16：沒有遇到過。

Q17：ovs的性能問題有什麼好的建議？用dpdk能夠解決嗎？

A17：Neutron的性能調優是個太複雜的問題，VM到VM之間但凡用軟體實作的，都可以調優，我這裡單純地了解為IO的速度不夠。對于OVS的調優，不談代碼的話，我主要想到的思路有以下幾個：1. 将部分功能如隧道Offload到TOR上去（這個應該盛科做過），或者使用STT這類可以做TSO的；2.用dpdk給OVS datapath做加速；3.更幹脆一點直接用SRIOV這樣的總線技術把OVS旁路掉。

Q18：dvr的全局mac是存在資料庫裡的嗎，并且在流表裡會有記錄，并做些替換的操作。qr上ip是否相同？qg呢？這個qr和qg是什麼樣子的

A18：dvr mac是存在neutron中的，全局唯一，事先配置設定。dvr存在的意義是：在所有計算節點上，r1位于相同網段的接口mac位址是一緻的，即CN1上的r1 red/grn mac與CN2上的r1 red/grn mac一緻。是以為了防止對端br-tun上的混亂， Neutron為每個部署了DVR的計算節點配置設定了全局唯一的dvr mac位址，br-tun在進行隧道傳輸前都需要進行源MAC位址的改寫。dvr是虛MAC。每個租戶路由器上同一網段的qr的IP位址、MAC位址在各個計算節點上都是一樣的。這正是設計dvr的出發點。qg就是外網的IP，有Floating IP另做考慮。qr上的IP不會沖突，因為除了dvr mac的設計以外，br-tun還把本地VM到QR的流量給抛棄了，不會送進隧道。

----------------------------------------------------------------------------------------------------

SDNLAB微信直播群定位為面向網絡創新技術的愛好者及從業人員進行交流、學習、分享，吸引了來自高校、雲服務提供商、網際網路廠商、裝置廠商、營運商等機關的從業人員近千人，每周會組織定向的技術及業界動态分享，如果你有需要分享的請加微信：353176266聯系。

• 本站聲明：本站原創文章可以轉載，請注明來自 SDNLAB