SDNLAB技術(shù)分享：Neutron的基本原理與代碼實(shí)現(xiàn)

一、Openstack網(wǎng)絡(luò)基礎(chǔ)

下面對(duì)Openstack和Neutron的介紹，要從幾個(gè)關(guān)鍵詞入手。

1. 三代網(wǎng)絡(luò)

在網(wǎng)絡(luò)這一口，OpenStack經(jīng)歷了由nova-network到Quantum再到Neutron的演進(jìn)過(guò)程。我們直觀地來(lái)看看三代網(wǎng)絡(luò)的對(duì)比分析：

1）Nova-network是隸屬于nova項(xiàng)目的網(wǎng)絡(luò)實(shí)現(xiàn)，它利用了linux-bridge（早期，目前也支持OVS）作為交換機(jī)，具備Flat、Flat DHCP、VLAN三種組網(wǎng)模式。優(yōu)點(diǎn)是性能出色，工作穩(wěn)定，支持multi-host部署以實(shí)現(xiàn)HA；缺點(diǎn)是網(wǎng)絡(luò)模塊不獨(dú)立，功能不夠靈活，組網(wǎng)模式也比較受限。

2）Quantum作為獨(dú)立的網(wǎng)絡(luò)管理項(xiàng)目出現(xiàn)在F版本，除了linux-bridge外還支持OVS，以及以及其他商業(yè)公司的插件，組網(wǎng)模式上增加了對(duì)GRE和VxLAN兩個(gè)Overlay技術(shù)的支持。優(yōu)點(diǎn)是功能靈活，支持大二層組網(wǎng)；缺點(diǎn)是集中式的網(wǎng)絡(luò)節(jié)點(diǎn)缺乏HA，而且各廠商插件無(wú)法同時(shí)在底層網(wǎng)絡(luò)中運(yùn)行。

3）Neutron出現(xiàn)在H版本，由來(lái)是Quantum和一家公司的名稱沖突而改名。Neutron對(duì)Quantum的插件機(jī)制進(jìn)行了優(yōu)化，將各個(gè)廠商L2插件中獨(dú)立的數(shù)據(jù)庫(kù)實(shí)現(xiàn)提取出來(lái)，作為公共的ML2插件存儲(chǔ)租戶的業(yè)務(wù)需求，使得廠商可以專注于L2設(shè)備驅(qū)動(dòng)的實(shí)現(xiàn)，而ML2作為總控可以協(xié)調(diào)多廠商L2設(shè)備共同運(yùn)行。Neutron繼承了Quantum對(duì)大二層的支持，還支持L2 PoP，DVR，VRRP，HA等關(guān)鍵功能，集成了很多L4-L7的網(wǎng)絡(luò)服務(wù)，一些blueprint也正在積極開(kāi)發(fā)中，如SFC等。優(yōu)點(diǎn)是開(kāi)始引入SDN思想，功能上更為豐富，網(wǎng)絡(luò)兼容性強(qiáng)；缺點(diǎn)是代碼結(jié)構(gòu)復(fù)雜，工作不夠穩(wěn)定，HA機(jī)制仍缺乏大規(guī)模商用的檢驗(yàn)。

從應(yīng)用場(chǎng)景來(lái)看，Nova-network組網(wǎng)模式過(guò)于簡(jiǎn)單，一些復(fù)雜的網(wǎng)絡(luò)需求無(wú)法實(shí)現(xiàn)（比如兩個(gè)公司合并，有大量IP重合的VM要遷移到一個(gè)平臺(tái)，而且要求遷移后都要用原來(lái)的IP）。不過(guò)由于其簡(jiǎn)單穩(wěn)定的特點(diǎn)，仍適合于中小型企業(yè)的生產(chǎn)環(huán)境；Quantum的實(shí)際部署目前基本都跟進(jìn)到了Neutron；Neutron的大二層組網(wǎng)，適合于云計(jì)算規(guī)模的生產(chǎn)環(huán)境，但是由于分布式和HA機(jī)制仍不夠成熟，因此目前多見(jiàn)于私有云和小規(guī)模共有云的部署，大規(guī)模的公有云仍然難以使用Neutron實(shí)現(xiàn)。

2. 四種組網(wǎng)模型

說(shuō)完了基本特征與應(yīng)用場(chǎng)景，下面開(kāi)始對(duì)上述提到的一些網(wǎng)絡(luò)問(wèn)題進(jìn)行詳細(xì)的描述。我們拋開(kāi)技術(shù)，結(jié)合圖例來(lái)抽象地看看不同的組網(wǎng)模型。當(dāng)然，以下模型的實(shí)現(xiàn)不僅僅局限于三張圖中的方式。

1）Flat模型最為簡(jiǎn)單，所有的虛擬機(jī)共用一個(gè)私有IP網(wǎng)段，IP地址在虛擬機(jī)啟動(dòng)時(shí)完成注入，虛擬機(jī)間的通信直接通過(guò)HyperVisor中的網(wǎng)橋轉(zhuǎn)發(fā)，公網(wǎng)流量在該網(wǎng)段的網(wǎng)關(guān)上進(jìn)行NAT（Nova-network實(shí)現(xiàn)為開(kāi)啟nova-network主機(jī)內(nèi)核的iptables，Neutron實(shí)現(xiàn)為網(wǎng)絡(luò)節(jié)點(diǎn)上的l3-agent）。Flat DHCP模型與Flat區(qū)別在于網(wǎng)橋中開(kāi)啟了DHCP進(jìn)程，虛擬機(jī)通過(guò)DHCP消息獲得IP地址（Nova-network實(shí)現(xiàn)為nova-network主機(jī)中的dnsmaq，Neutron實(shí)現(xiàn)為網(wǎng)絡(luò)節(jié)點(diǎn)上的dhcp-agent）。

2）VLAN模型引入了多租戶機(jī)制，虛擬機(jī)可以使用不同的私有IP網(wǎng)段，一個(gè)租戶可以擁有多個(gè)IP網(wǎng)段。虛擬機(jī)IP通過(guò)DHCP消息獲取IP地址（Nova-network實(shí)現(xiàn)為nova-network主機(jī)中的dnsmaq，Neutron實(shí)現(xiàn)為網(wǎng)絡(luò)節(jié)點(diǎn)上的dhcp-agent）。網(wǎng)段內(nèi)部虛擬機(jī)間的通信直接通過(guò)HyperVisor中的網(wǎng)橋轉(zhuǎn)發(fā)，同一租戶跨網(wǎng)段通信通過(guò)網(wǎng)關(guān)路由，不同租戶通過(guò)網(wǎng)關(guān)上的ACL進(jìn)行隔離，公網(wǎng)流量在該網(wǎng)段的網(wǎng)關(guān)上進(jìn)行NAT（Nova-network實(shí)現(xiàn)為開(kāi)啟nova-network主機(jī)內(nèi)核的iptables，Neutron實(shí)現(xiàn)為網(wǎng)絡(luò)節(jié)點(diǎn)上的l3-agent）。如果不同租戶邏輯上共用一個(gè)網(wǎng)關(guān)，則無(wú)法實(shí)現(xiàn)租戶間IP地址的復(fù)用。

3）Overlay模型（主要包括GRE和VxlAN隧道技術(shù)），相比于VLAN模型有以下改進(jìn)。1）租戶數(shù)量從4K增加到16million；2）租戶內(nèi)部通信可以跨越任意IP網(wǎng)絡(luò)，支持虛擬機(jī)任意遷移；3）一般來(lái)說(shuō)每個(gè)租戶邏輯上都有一個(gè)網(wǎng)關(guān)實(shí)例，IP地址可以在租戶間進(jìn)行復(fù)用；4）能夠結(jié)合SDN技術(shù)對(duì)流量進(jìn)行優(yōu)化。

3. 三類節(jié)點(diǎn)和三類網(wǎng)絡(luò)

看過(guò)抽象的組網(wǎng)模型，下面我們來(lái)介紹組網(wǎng)具體的實(shí)現(xiàn)技術(shù)。下面的介紹都是針對(duì)Neutron的，對(duì)nova-network和Quantum將不做討論。

1）3類節(jié)點(diǎn)——管理節(jié)點(diǎn)：實(shí)現(xiàn)鏡像、塊存儲(chǔ)、身份認(rèn)證、前端等服務(wù)，運(yùn)行nova-compute的調(diào)度模塊以及nova api-server；計(jì)算節(jié)點(diǎn)：實(shí)現(xiàn)nova-compute，以及neutron的各種agent（一般不包括l3-agent，DVR除外）；網(wǎng)絡(luò)節(jié)點(diǎn)，：實(shí)現(xiàn)neutron各種agent。注意，由于OpenStack為分布式架構(gòu)實(shí)現(xiàn)，因此neutron-server既可以運(yùn)行在控制節(jié)點(diǎn)，也可以運(yùn)行在網(wǎng)絡(luò)節(jié)點(diǎn)。

2）3種網(wǎng)絡(luò)——OpenStack內(nèi)部模塊之間的交互發(fā)生在管理網(wǎng)絡(luò)，虛擬機(jī)之間的通信發(fā)生在數(shù)據(jù)網(wǎng)絡(luò)，而External Network/API Network網(wǎng)絡(luò)是連接外網(wǎng)的，無(wú)論是用戶調(diào)用Openstack API，還是虛擬機(jī)與外網(wǎng)間的互通都需要經(jīng)過(guò)這個(gè)網(wǎng)絡(luò)。

目前OpenStack通常采用out-of-bound方式進(jìn)行部署，管理網(wǎng)絡(luò)與另外兩個(gè)網(wǎng)絡(luò)是獨(dú)立的，管理節(jié)點(diǎn)上一般也不會(huì)承載Openstack的業(yè)務(wù)流量，下面的分析中網(wǎng)絡(luò)只涉及數(shù)據(jù)網(wǎng)絡(luò)與External Network/API Network網(wǎng)絡(luò)，節(jié)點(diǎn)只涉及計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)。

4. 兩張圖例

有了以上知識(shí)作為基礎(chǔ)，就可以來(lái)分析Openstack中的網(wǎng)絡(luò)通信了。由于OpenStack中容器的通信機(jī)制目前尚不成熟，并且有專門的項(xiàng)目Kuryr去實(shí)現(xiàn)容器相關(guān)網(wǎng)絡(luò)技術(shù)，以下內(nèi)容將不涉及OpenStack中的容器通信。

以下將通過(guò)兩張圖來(lái)分析Neutron中的VLAN組網(wǎng)模型，HyperVisor中的網(wǎng)絡(luò)設(shè)備以O(shè)penvSwitch為例。這三張圖中每一個(gè)信息都是有用的，把這些信息完全弄懂了，Neutron的組網(wǎng)也就能基本掌握了，Overlay模型與VLAN模型的區(qū)別只在于將圖中的br-eth1替換成br-tun即可，具體隧道如何進(jìn)行封裝，稍后我們?cè)僭敿?xì)介紹。

第一張圖是計(jì)算節(jié)點(diǎn)上的網(wǎng)絡(luò)實(shí)現(xiàn)。以虛擬機(jī)發(fā)出流量方向?yàn)槔?，從虛擬機(jī)處開(kāi)始分析：

1)流量經(jīng)由虛擬機(jī)IP內(nèi)核交給虛擬網(wǎng)卡處理，虛擬網(wǎng)卡由TAP軟件實(shí)現(xiàn)，TAP允許用戶態(tài)程序向內(nèi)核協(xié)議棧注入數(shù)據(jù)，它可以運(yùn)行于虛擬機(jī)操作系統(tǒng)之上，能夠提供與硬件以太網(wǎng)卡完全相同的功能。

2)TAP設(shè)備并不是直接連接到OVS上的，而是通過(guò)linux bridge中繼到ovs br-int上，其原因在于ovs無(wú)法實(shí)現(xiàn)linux bridge中一些帶狀態(tài)的iptables規(guī)則，而這些規(guī)則往往用于以虛擬機(jī)為單位的安全組（security group）功能的實(shí)現(xiàn)。qbr是quantum bridge的縮寫，Neutron中沿用了Quantum的叫法。

3)linux bridge與ovs br int間的連接通過(guò)veth-pair技術(shù)實(shí)現(xiàn)，qvb代表quantum veth bridge，qvo代表quantum veth ovs。veth-pair用于連接兩個(gè)虛擬網(wǎng)絡(luò)設(shè)備，總是成對(duì)出現(xiàn)以模擬虛擬設(shè)備間的數(shù)據(jù)收發(fā)，其原理是反轉(zhuǎn)通訊數(shù)據(jù)的方向，需要發(fā)送的數(shù)據(jù)會(huì)被轉(zhuǎn)換成需要收到的數(shù)據(jù)重新送入內(nèi)核網(wǎng)絡(luò)層進(jìn)行處理。veth-pair與tap的區(qū)別可以簡(jiǎn)單理解為veth-pair是軟件模擬的網(wǎng)線，而tap是軟件模擬的網(wǎng)卡。

4)ovs br-int是計(jì)算節(jié)點(diǎn)本地的虛擬交換設(shè)備，根據(jù)neutron-server中OVS Plugin的指導(dǎo)，完成流量在本地的處理：本地虛擬機(jī)送入的流量被標(biāo)記本地VLAN tag，送到本地虛擬機(jī)的流量被去掉本地VLAN tag，本地虛擬機(jī)間的2層流量直接在本地轉(zhuǎn)發(fā)，本地虛擬機(jī)到遠(yuǎn)端虛擬機(jī)、網(wǎng)關(guān)的流量由int-br-eth1送到ovs br-eth1上（在Overlay模型中送到ovs br-tun上）。注意，無(wú)論是VLAN模型還是Overlay模型，由于br-int上VLAN數(shù)量的限制，計(jì)算節(jié)點(diǎn)本地最多支持4K的租戶。

5)ovs br-int與ovs br-eth1間的連接通過(guò)veth-pair技術(shù)實(shí)現(xiàn)。

6)ovs br-eth1將該計(jì)算節(jié)點(diǎn)與其他計(jì)算節(jié)點(diǎn)、網(wǎng)絡(luò)節(jié)點(diǎn)連接起來(lái)，根據(jù)neutron-server中OVS Plugin的指導(dǎo)，完成流量送出、送入本地前的處理：根據(jù)底層物理網(wǎng)絡(luò)租戶VLAN與本地租戶VLAN間的映射關(guān)系進(jìn)行VLAN ID的轉(zhuǎn)換（Overlay模型中此處進(jìn)行隧道封裝，并進(jìn)行VNI與本地租戶VLAN ID間的映射）。由于底層物理網(wǎng)絡(luò)中VLAN數(shù)量的限制，VLAN模型最多支持4K的租戶，而Overlay模型中，24位的VNI最多支持16million的租戶。

7)ovs br-eth1直接關(guān)聯(lián)物理宿主機(jī)的硬件網(wǎng)卡eth1，通過(guò)eth1將數(shù)據(jù)包送到物理網(wǎng)絡(luò)中。Overlay模型中ovs br-tun通過(guò)TUN設(shè)備對(duì)數(shù)據(jù)包進(jìn)行外層隧道封裝并送到HyperVisor內(nèi)核中，內(nèi)核根據(jù)外層IP地址進(jìn)行選路，從硬件網(wǎng)卡eth1將數(shù)據(jù)包送到物理網(wǎng)絡(luò)中。TUN與TAP的實(shí)現(xiàn)機(jī)制類似，區(qū)別在于TAP工作在二層，而TUN工作在三層。

第二張圖是網(wǎng)絡(luò)節(jié)點(diǎn)上的網(wǎng)絡(luò)實(shí)現(xiàn)，以流量流入網(wǎng)絡(luò)節(jié)點(diǎn)方向?yàn)槔?，從底層物理網(wǎng)絡(luò)流量通過(guò)eth1進(jìn)入ovs br-eth1（Overlay模型中為ovs br-tun）開(kāi)始分析：

1)ovs br-eth1將網(wǎng)絡(luò)節(jié)點(diǎn)與計(jì)算節(jié)點(diǎn)連接起來(lái)，根據(jù)neutron-server中OVS Plugin的指導(dǎo)，完成流量送入網(wǎng)絡(luò)節(jié)點(diǎn)前的處理：根據(jù)底層物理網(wǎng)絡(luò)租戶VLAN與本地租戶VLAN間的映射關(guān)系進(jìn)行VLAN ID的轉(zhuǎn)換（Overlay模型中此處進(jìn)行解封裝，并進(jìn)行VNI與本地租戶VLAN ID間的映射）。注意，雖然同一租戶在底層物理網(wǎng)絡(luò)上的VLAN ID（Overlay模型中為VNI）唯一，但是在網(wǎng)絡(luò)節(jié)點(diǎn)與計(jì)算節(jié)點(diǎn)，不同計(jì)算節(jié)點(diǎn)中同一租戶對(duì)應(yīng)的本地VLAN ID可能有所不同。另外由于網(wǎng)絡(luò)節(jié)點(diǎn)也要在ovs br-int上使用本地VLAN，而租戶跨網(wǎng)段流量與公網(wǎng)流量都要經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)，因此使用單個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)時(shí)，Neutron最多能支持4K租戶，可采用部署多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)的方式來(lái)解決這一問(wèn)題。

2)送入網(wǎng)絡(luò)節(jié)點(diǎn)的流量，由ovs br-eth1（ovs br-tun）通過(guò)veth-pair送給ovs br-int，ovs br-int連接了本地不同的namespace，包括實(shí)現(xiàn)dhcp功能的dhcp-agent——dnsmasq，以及實(shí)現(xiàn)路由功能的l3-agent——router。Dnsmasq負(fù)責(zé)給對(duì)應(yīng)租戶的虛擬機(jī)分配IP地址，而router負(fù)責(zé)處理租戶內(nèi)跨網(wǎng)段流量以及公網(wǎng)流量。不同的租戶有不同的dnsmasq和router實(shí)例，因此不同租戶間可以實(shí)現(xiàn)IP地址的復(fù)用。

3)Router namesapce通過(guò)qr接口（Quantum Router）接收到租戶內(nèi)跨網(wǎng)段流量以及公網(wǎng)流量，在ns的IP內(nèi)核中對(duì)跨網(wǎng)段流量進(jìn)行路由，改寫MAC地址并通過(guò)相應(yīng)的qr接口向ovs br-int送出數(shù)據(jù)包。在ns的IP內(nèi)核中對(duì)公網(wǎng)流量進(jìn)行NAT，并通過(guò)qg接口（Quantum Gateway）發(fā)送給ovs br-ex。

4)Ovs br-ex通過(guò)關(guān)物理聯(lián)宿主機(jī)的硬件網(wǎng)卡eth1將流量送至Internet路由器。

5)上述兩幅圖中，ovs br-int與ovs br-ex間有直連，據(jù)說(shuō)主要是防止l3-agent出現(xiàn)問(wèn)題時(shí)能夠保證流量不中斷，但實(shí)際上看來(lái)很少出現(xiàn)此問(wèn)題。

**5. Neutron網(wǎng)絡(luò)全家福

**

上圖是在網(wǎng)上看過(guò)的更加細(xì)致，更為全面的一張圖（http://blog.csdn.net/canxinghen/article/details/46761591#comments），圖中清晰地展示了Neutron對(duì)多種L2技術(shù)（VLAN、VxLAN、GRE）共同運(yùn)行的支持。圖中的mellonax是intel等硬件廠商搞出的具備轉(zhuǎn)發(fā)功能的網(wǎng)卡，能夠避免虛擬交換機(jī)帶來(lái)的資源消耗，并能夠加快轉(zhuǎn)發(fā)速率。一塊這樣的網(wǎng)卡能虛擬出63個(gè)VF，每個(gè)VF就好像一個(gè)獨(dú)立的物理網(wǎng)卡一樣，通過(guò)將VF直接掛到虛擬機(jī)上，能夠?qū)崿F(xiàn)轉(zhuǎn)發(fā)性能的大幅度提高。

以上介紹了OpenStack中網(wǎng)絡(luò)組件的演進(jìn)，以及Neutron組網(wǎng)的基本原理。下面我們將對(duì)Neutron的軟件實(shí)現(xiàn)進(jìn)行簡(jiǎn)單的介紹。

二、Nova虛擬機(jī)啟動(dòng)時(shí)的網(wǎng)絡(luò)處理

設(shè)備啟動(dòng)了，網(wǎng)絡(luò)有了，可是現(xiàn)在還沒(méi)有虛擬機(jī)。下面我們來(lái)看看nova虛擬機(jī)啟動(dòng)時(shí)的網(wǎng)絡(luò)處理過(guò)程。

從頭開(kāi)始講。虛擬機(jī)的啟動(dòng)通常來(lái)自于控制節(jié)點(diǎn)命令行的nova boot，該命令被組裝成REST API送到nova-api。Nova-api與neutron-server干的是一樣的活：接收REST請(qǐng)求，調(diào)nova-scheduler跑一些調(diào)度機(jī)制，計(jì)算出虛擬機(jī)部署的位置，然后通過(guò)rpc與相應(yīng)計(jì)算節(jié)點(diǎn)上的agent——nova-compute進(jìn)行通信，而啟動(dòng)虛擬機(jī)的實(shí)際工作由nova-compute完成。

當(dāng)然，以上過(guò)程與網(wǎng)絡(luò)并沒(méi)有發(fā)生什么關(guān)系，這里不做深入分析，大家要是有興趣可參考http://www.linuxqq.net/archives/1277.html。

假定nova-compute已經(jīng)通過(guò)rpc收到了開(kāi)始干活的命令，我們就從這里開(kāi)始漫長(zhǎng)的代碼分析。在此之前，先來(lái)看一看OpenStack組件層面的調(diào)用流程。這里借用OpenStack大神SammyLiu的一張圖吧，圖中1-6步驟依次做了這么幾件事：

1）Nova-compute向neutron-server請(qǐng)求虛擬機(jī)對(duì)應(yīng)的Port資源。

2）Neutron-server根據(jù)neutron-database生成Port資源。

3）Neutron-server通知Dhcp agent虛擬機(jī)信息。

4）Dhcp agent將虛擬機(jī)信息通知給dhcp server。

5）虛擬機(jī)接入并啟動(dòng)。

6）虛擬機(jī)從dhcp server處獲得IP地址。

最后一步就是傳統(tǒng)的dhcp的交互過(guò)程，這里就不講了，下面來(lái)看1-5的實(shí)現(xiàn)。時(shí)間有限，代碼不再一步步回溯了，詳見(jiàn)SDNLAB“網(wǎng)絡(luò)虛擬化”專題的后續(xù)文章，這里給出代碼的主體思路。

1）Nova-compute向neutron-server發(fā)送create_port的REST API請(qǐng)求，生成新的Port資源。

2）Neutron-server收到該REST請(qǐng)求，通過(guò)APIRouter路由到ML2的create_port方法。該方法中，獲得了neutron-database新生成的Port，并通知ML2 Mechanism Driver該P(yáng)ort的生成。

3）Nova-compute向neutron發(fā)送update_port的REST API請(qǐng)求，

4）Neutron-server收到該REST請(qǐng)求，通過(guò)APIRouter路由到ML2的update_port方法。該方法中，在neutron-database更新該P(yáng)ort的狀態(tài)，并根據(jù)ML2 Mechanism Driver的不同，決定后續(xù)的處理：若Mechanism Driver為hyperv/linuxbridge/ofagent/openvswitch，則需要通過(guò)ML2的update_port方法中執(zhí)行rpc遠(yuǎn)程調(diào)用update_port；對(duì)于其余的Mechanism Driver，ML2的update_port方法調(diào)用其的update_port_postcommit方法進(jìn)行處理，這些Mechanism Driver可能使用非rpc方式與自身的agent通信（如REST API、Netconf等）。

5）ML2執(zhí)行完update_port方法后，Port資源在wsgi中對(duì)應(yīng)的Controller實(shí)例通過(guò)DhcpAgentNotifyAPI實(shí)例rpc通知給網(wǎng)絡(luò)節(jié)點(diǎn)上的dhcp agent（也可能通過(guò)一些調(diào)度機(jī)制通知給分布在計(jì)算節(jié)點(diǎn)上的dhcp agent）。

6）Dhcp agent收到該rpc通知，通過(guò)call_driver方法將虛擬機(jī)MAC與IP的綁定關(guān)系傳遞給本地的DHCP守護(hù)進(jìn)程Dnsmaq。

7）Nova-compute通過(guò)libvirt driver的spawn方法將虛擬機(jī)接入網(wǎng)絡(luò)，然后啟動(dòng)虛擬機(jī)。

到這里，虛擬機(jī)啟動(dòng)過(guò)程中的網(wǎng)絡(luò)處理就都結(jié)束了，虛擬機(jī)間就可以開(kāi)始通信了。下面開(kāi)始介紹Neutron中OVS的流表邏輯，看看OVS是怎么支持虛擬機(jī)間的通信的。

三、Neutron的軟件實(shí)現(xiàn)

5. 5類Neutron組件

在架構(gòu)設(shè)計(jì)上， Neutron沿用了OpenStack完全分布式的思想，各組件之間通過(guò)消息機(jī)制進(jìn)行通信，使得Neutron中各個(gè)組件甚至各個(gè)進(jìn)程都可以運(yùn)行在任意的節(jié)點(diǎn)上，如下圖所示。這種微內(nèi)核的架構(gòu)使得開(kāi)發(fā)者可以集中精力在網(wǎng)絡(luò)業(yè)務(wù)的實(shí)現(xiàn)上。目前Neutron提供了眾多的插件與驅(qū)動(dòng)，基本上可以滿足各種部署的需要，如果這些還難以支撐實(shí)際所需的環(huán)境，則可以方便地在Neutron的框架下擴(kuò)展插件或驅(qū)動(dòng)。

1）Neutron-server可以理解為一個(gè)專門用來(lái)接收Neutron REST API調(diào)用的服務(wù)器，然后負(fù)責(zé)將不同的rest api分發(fā)到不同的neutron-plugin上。

2）Neutron-plugin可以理解為不同網(wǎng)絡(luò)功能實(shí)現(xiàn)的入口，各個(gè)廠商可以開(kāi)發(fā)自己的plugin。Neutron-plugin接收neutron-server分發(fā)過(guò)來(lái)的REST API，向neutron database完成一些信息的注冊(cè)，然后將具體要執(zhí)行的業(yè)務(wù)操作和參數(shù)通知給自身對(duì)應(yīng)的neutron agent。

3）Neutron-agent可以直觀地理解為neutron-plugin在設(shè)備上的代理，接收相應(yīng)的neutron-plugin通知的業(yè)務(wù)操作和參數(shù)，并轉(zhuǎn)換為具體的設(shè)備級(jí)操作，以指導(dǎo)設(shè)備的動(dòng)作。當(dāng)設(shè)備本地發(fā)生問(wèn)題時(shí)，neutron-agent會(huì)將情況通知給neutron-plugin。

4）Neutron database，顧名思義就是Neutron的數(shù)據(jù)庫(kù)，一些業(yè)務(wù)相關(guān)的參數(shù)都存在這里。

5）Network provider，即為實(shí)際執(zhí)行功能的網(wǎng)絡(luò)設(shè)備，一般為虛擬交換機(jī)（OVS或者Linux Bridge）。

6 兩類Plugin

1）Core-plugin，Neutron中即為ML2（Modular Layer 2），負(fù)責(zé)管理L2的網(wǎng)絡(luò)連接。ML2中主要包括network、subnet、port三類核心資源，對(duì)三類資源進(jìn)行操作的REST API被neutron-server看作Core API，由Neutron原生支持。其中：

2）Service-plugin，即為除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要實(shí)現(xiàn)L3-L7的網(wǎng)絡(luò)服務(wù)。這些plugin要操作的資源比較豐富，對(duì)這些資源進(jìn)行操作的REST API被neutron-server看作Extension API，需要廠家自行進(jìn)行擴(kuò)展。

最開(kāi)始曾經(jīng)提到，“Neutron對(duì)Quantum的插件機(jī)制進(jìn)行了優(yōu)化，將各個(gè)廠商L2插件中獨(dú)立的數(shù)據(jù)庫(kù)實(shí)現(xiàn)提取出來(lái)，作為公共的ML2插件存儲(chǔ)租戶的業(yè)務(wù)需求，使得廠商可以專注于L2設(shè)備驅(qū)動(dòng)的實(shí)現(xiàn)，而ML2作為總控可以協(xié)調(diào)多廠商L2設(shè)備共同運(yùn)行”。在Quantum中，廠家都是開(kāi)發(fā)各自的Service-plugin，不能兼容而且開(kāi)發(fā)重復(fù)度很高，于是在Neutron中就為設(shè)計(jì)了ML2機(jī)制，使得各廠家的L2插件完全變成了可插拔的，方便了L2中network資源擴(kuò)展與使用。

ML2作為L(zhǎng)2的總控，其實(shí)現(xiàn)包括Type和Mechanism兩部分，每部分又分為Manager和Driver。Type指的是L2網(wǎng)絡(luò)的類型（如Flat、VLAN、VxLAN等），與廠家實(shí)現(xiàn)無(wú)關(guān)。Mechanism則是各個(gè)廠家自己設(shè)備機(jī)制的實(shí)現(xiàn)，如下圖所示。當(dāng)然有ML2，對(duì)應(yīng)的就可以有ML3，不過(guò)在Neutron中L3的實(shí)現(xiàn)只負(fù)責(zé)路由的功能，傳統(tǒng)路由器中的其他功能（如Firewalls、LB、VPN）都被獨(dú)立出來(lái)實(shí)現(xiàn)了，因此暫時(shí)還沒(méi)有看到對(duì)ML3的實(shí)際需求。

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

一般而言，neutron-server和各neutron-plugin部署在控制節(jié)點(diǎn)或者網(wǎng)絡(luò)節(jié)點(diǎn)上，而neutron agent則部署在網(wǎng)絡(luò)節(jié)點(diǎn)上和計(jì)算節(jié)點(diǎn)上。我們先來(lái)簡(jiǎn)單地分析控制端neutron-server和neutron-plugin的工作，然后再分析設(shè)備端neutron-agent的工作。

具體的代碼這次分享沒(méi)有時(shí)間講了，只能講個(gè)大致的輪廓和思路。有興趣深入研究的同志，可以關(guān)注SDNLAB上“網(wǎng)絡(luò)虛擬化”專題的后續(xù)更新。

（注意，以前廠商開(kāi)發(fā)的L2 plugin跟ML2都存在于neutron/plugins目錄下，而可插拔的ML2設(shè)備驅(qū)動(dòng)則存在于neutron/plugins/ml2/drivers目錄下）

**1. 控制端的實(shí)現(xiàn)

**

從neutron-server的啟動(dòng)開(kāi)始說(shuō)起。neutron-server的啟動(dòng)入口在neutron.server.__init__中，主函數(shù)中主要就干了兩件事，第一是下圖l 48處啟動(dòng)wsgi服務(wù)器監(jiān)聽(tīng)Neutron REST API，第二是在l 52啟動(dòng)rpc服務(wù)，用于core plugin與agent間的通信，兩類服務(wù)作為綠色線程并發(fā)運(yùn)行。從SDN的角度來(lái)看，wsgi負(fù)責(zé)Neutron的北向接口，而Neutron的南向通信機(jī)制主要依賴于rpc來(lái)實(shí)現(xiàn)（當(dāng)然，不同廠家的plugin可能有其它的南向通信機(jī)制）。

1）北向方面，Neutron的wsgi通過(guò)Paste工具進(jìn)行模板化部署，它接收Neutron REST API的業(yè)務(wù)請(qǐng)求，然后通過(guò)APIRouter將其分發(fā)給對(duì)應(yīng)的plugin。

2)Neutron內(nèi)部，plugin與數(shù)據(jù)庫(kù)交互，獲取業(yè)務(wù)的全局參數(shù)，然后通過(guò)rpc機(jī)制將操作與參數(shù)傳給設(shè)備上的Agent（某些plugin和ML2 Mechanism Driver通過(guò)別的方式與Agent通信，比如REST API、NETCONF等）。

3)RPC機(jī)制就可以理解為Neutron的南向通信機(jī)制，Neutron的RPC實(shí)現(xiàn)基于AMPQ模型，plugins和agents之間通常采用“發(fā)布——訂閱”模式傳遞消息，agents收到相應(yīng)plugins的NotifyApi后，會(huì)回調(diào)設(shè)備本地的CallBack來(lái)操作設(shè)備，完成業(yè)務(wù)的底層部署。

2. 設(shè)備端的實(shí)現(xiàn)

控制端neutron-server通過(guò)wsgi接收北向REST API請(qǐng)求，neutron-plugin通過(guò)rpc與設(shè)備端進(jìn)行南向通信。設(shè)備端agent則向上通過(guò)rpc與控制端進(jìn)行通信，向下則直接在本地對(duì)網(wǎng)絡(luò)設(shè)備進(jìn)行配置。Neutron-agent的實(shí)現(xiàn)很多，彼此之間也沒(méi)什么共性的地方，下面選取比較具有代表性的ovs-neutron-agent的實(shí)現(xiàn)進(jìn)行簡(jiǎn)單的介紹。

Ovs-neutron-agent的啟動(dòng)入口為/neutron/plugins/openvswitch/agent/ovs-neutron-agent.py中的main方法，其中負(fù)責(zé)干活的兩行代碼在l 1471和l 1476。L 1471實(shí)例化了OVSNeutronAgent類，負(fù)責(zé)在本地配置OVS，而l 1476則啟動(dòng)了與控制端的rpc通信。

OVSNeutronAgent的實(shí)例化過(guò)程中依次干了6個(gè)工作：?jiǎn)?dòng)ovs br-int網(wǎng)橋；啟動(dòng)rpc；啟動(dòng)ovs br-eth1；啟動(dòng)ovs br-tun；實(shí)例化OVSSecurityGroupAgent；開(kāi)始rpc輪詢與監(jiān)聽(tīng)。

rpc_loop做的工作主要就是輪詢一些狀態(tài)，根據(jù)這些狀態(tài)，進(jìn)行相應(yīng)的操作。比如一旦探測(cè)到本地的OVS重啟了（l 1295，l 1309），就重新創(chuàng)建本地的網(wǎng)橋（l 1294-1300），并重新添加port（l 1336）；再比如一旦rpc監(jiān)聽(tīng)到update_port事件（l 1309），則在本地使能相應(yīng)的port（l 1336）。

ovs-neutron-agent的啟動(dòng)也就是這些工作了，啟動(dòng)完畢后，便開(kāi)始了與相應(yīng)plugin（OVS Plugin或者OVS Mechanism Driver）的rpc通信。

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

Neutron的軟件實(shí)現(xiàn)就簡(jiǎn)單地介紹到這里了，下一節(jié)我們來(lái)具體看看Neutron中各個(gè)OVS上的流表邏輯是怎樣的。

**四、Neutron OVS上的流表分析

**

在具體介紹OVS的工作機(jī)制之前，大家要先理解OVS并不是Neutron網(wǎng)絡(luò)實(shí)現(xiàn)的唯一選擇。

實(shí)際上，Neutron中底層網(wǎng)絡(luò)的實(shí)現(xiàn)千差萬(wàn)別：有的agent本地是真正處理數(shù)據(jù)流的網(wǎng)絡(luò)設(shè)備（OVS，Router，LoadBalancer等），而有的agent本地是SDN控制器（如ODL、ONOS、OpenContrail、NSX等）。上述Neutron底層網(wǎng)絡(luò)的兩種模型示意如下。

第一種模型中Neutron相當(dāng)于SDN控制器，plugin與agent間的通信機(jī)制（如rpc）就相當(dāng)于簡(jiǎn)單的南向協(xié)議。第二種模型中Neutron作為SDN應(yīng)用，將業(yè)務(wù)需求告知SDN控制器，SDN控制器再通過(guò)五花八門的南向協(xié)議遠(yuǎn)程控制網(wǎng)絡(luò)設(shè)備。當(dāng)然，第二種模型中也可以把Neutron看做超級(jí)控制器或者網(wǎng)絡(luò)編排器，去完成OpenStack中網(wǎng)絡(luò)業(yè)務(wù)的集中分發(fā)。

以下我們講的是第一種模型中OVS處理數(shù)據(jù)流的工作機(jī)制。后一種模型中，SDN控制器也可以通過(guò)OpenFlow或者OVSDB來(lái)控制OVS處理數(shù)據(jù)流，對(duì)此本節(jié)暫時(shí)不進(jìn)行討論，后續(xù)也會(huì)有文章會(huì)詳細(xì)介紹ODL和ONOS等SDN控制器對(duì)Openstack的支持。

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

以O(shè)verlay組網(wǎng)模型對(duì)OVS的工作機(jī)制進(jìn)行介紹，具體分為兩個(gè)角度：OVS實(shí)現(xiàn)L2的基本連接，OVS對(duì)連接機(jī)制的優(yōu)化。

**（一）L2基本連接的實(shí)現(xiàn)

**

復(fù)原一下通信場(chǎng)景，其中的網(wǎng)絡(luò)基礎(chǔ)請(qǐng)參考“OpenStack網(wǎng)絡(luò)基礎(chǔ)”一小節(jié)。圖中某租戶有兩個(gè)網(wǎng)段，分別用橙紅色和藍(lán)色表示，網(wǎng)段間的互通要經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)中的Router，網(wǎng)段內(nèi)的通信不需要經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)中的Router。網(wǎng)段間的互通可分為3步：橙紅色網(wǎng)段通過(guò)網(wǎng)段內(nèi)通信找到Router，Router進(jìn)行路由，Router通過(guò)藍(lán)色網(wǎng)段的網(wǎng)段內(nèi)通信轉(zhuǎn)發(fā)給目的地。Router上的路由是linux內(nèi)核實(shí)現(xiàn)的，我們不去關(guān)心，因此可以說(shuō)租戶內(nèi)部通信都是基于網(wǎng)段內(nèi)通信實(shí)現(xiàn)的。

Overlay模型中，網(wǎng)段內(nèi)通信涉及ovs br-int和ovs br-tun，計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)中兩類網(wǎng)橋的實(shí)現(xiàn)沒(méi)有什么區(qū)別。概括地說(shuō)，br-int負(fù)責(zé)在節(jié)點(diǎn)本地的網(wǎng)段內(nèi)通信，br-tun則負(fù)責(zé)節(jié)點(diǎn)間的網(wǎng)段內(nèi)通信。

在本節(jié)的場(chǎng)景內(nèi)br-int實(shí)現(xiàn)為普通的二層交換機(jī)，即完成VLAN標(biāo)簽的增刪和正常的二層自學(xué)習(xí)與轉(zhuǎn)發(fā)，沒(méi)有必要進(jìn)行過(guò)多的解釋，其代碼實(shí)現(xiàn)請(qǐng)參考“Neutron的軟件實(shí)現(xiàn)”中agent部分。

Br-tun采用多級(jí)流表實(shí)現(xiàn)節(jié)點(diǎn)間的網(wǎng)段內(nèi)通信，下面直接通過(guò)圖示來(lái)看br-tun中多級(jí)流表的設(shè)計(jì)。圖中流表的序號(hào)不是固定的，可在neutron.plugins.openvswitch.agent.common目錄下的constants.py文件中修改。

所有流經(jīng)br-tun的數(shù)據(jù)包首先進(jìn)入Table 0進(jìn)行處理。Table 0對(duì)數(shù)據(jù)包的來(lái)源進(jìn)行判斷，從與br-int相連的patch-int進(jìn)入的數(shù)據(jù)包交給Table 1處理，從GRE或者VxLAN端口（不同節(jié)點(diǎn)間的隧道有不同的Port_ID）進(jìn)入的分別交給Table 2、Table 3處理。Table 1根據(jù)數(shù)據(jù)包目的MAC地址判斷是否為單播，是則送往Table 20，否則送往Table 21，Table 20根據(jù)（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關(guān)系將單播包送到特定的隧道，Table 21將非單播包復(fù)制后送到所有隧道。進(jìn)入Table 2或者Table 3的數(shù)據(jù)包，首先判斷TUNNE_ID是否合法，是則添加本地VLAN_ID并送往Table 10，否則丟棄。Table 10記錄數(shù)據(jù)包的VLAN_ID，MAC、入端口以及TUNNEL_ID，將（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關(guān)系寫入Table 20，然后將數(shù)據(jù)包從與br-int相連的patch-int送出。

可見(jiàn)，上述過(guò)程就是標(biāo)準(zhǔn)MAC自學(xué)習(xí)在隧道中的擴(kuò)展，無(wú)非就是將（VLAN_ID，MAC）到PORT_ID的映射變?yōu)榱耍╒LAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射。這種自學(xué)習(xí)仍然要依賴于泛洪來(lái)完成，引入l2_population或者SDN控制器后可以避免掉泛洪。

（二）連接機(jī)制的優(yōu)化

OVS上，連接機(jī)制的優(yōu)化主要體現(xiàn)在l2_population機(jī)制，以及對(duì)DVR（Distributed Virtual Router，分布式L3-agent）的支持。

2.1 L2_population

虛擬機(jī)在通信前，會(huì)發(fā)送ARP請(qǐng)求去解析目的MAC與目的IP間的映射關(guān)系，這一過(guò)程需要發(fā)送二層的廣播包。由（一）中的介紹可知，這會(huì)導(dǎo)致隧道上的泛洪，這顯然是不能令人滿意的。

傳統(tǒng)網(wǎng)絡(luò)中ARP依賴于廣播泛洪的原因在于沒(méi)有一個(gè)集中式的控制平面，而Neutron中的數(shù)據(jù)庫(kù)存有所有虛擬機(jī)MAC地址與IP地址間的映射，可以說(shuō)是一個(gè)天然原生的控制平面。因此有人提出了將該映射關(guān)系注入到OVS本地，在本地處理ARP廣播，以避免隧道上的泛洪，這就是l2_population。

L2_population的實(shí)現(xiàn)并不復(fù)雜，就是在1介紹的流水線中增加一個(gè)ARP Table去處理ARP Request。ARP Table中會(huì)事先存好MAC與IP的映射關(guān)系，如果ARP Table中匹配ARP Request消息中的目的IP，則構(gòu)造一個(gè) ARP 響應(yīng)包，從ARP Request的入端口返回給虛擬機(jī)。如果匹配失敗，則跳轉(zhuǎn)到 Table 21繼續(xù)泛洪。上述過(guò)程如下圖所示，之所以保留ARP Table到Table 21的跳轉(zhuǎn)，主要是為了防止l2_population出現(xiàn)問(wèn)題。

L2_population的工作就是這么簡(jiǎn)單，卻可以大大減少不合意的隧道泛洪。其實(shí)dhcp也存在類似的問(wèn)題，如果只在網(wǎng)絡(luò)節(jié)點(diǎn)上放置dhcp-server，那么所有的DHCP DISCOVER消息都要靠隧道泛洪發(fā)送到網(wǎng)絡(luò)節(jié)點(diǎn)上。當(dāng)然，dhcp消息的數(shù)量和產(chǎn)生頻率遠(yuǎn)遠(yuǎn)趕不上arp，問(wèn)題也不會(huì)那么明顯。

解決dhcp存在的上述問(wèn)題，一種思路是在Table 21上專門寫一條高優(yōu)先級(jí)的dhcp流表項(xiàng)去匹配dhcp廣播消息，并將所有的dhcp消息都封裝送到網(wǎng)絡(luò)節(jié)點(diǎn)的隧道。另外，也可以采用類似于l2_population的思路，從Table 1上專門寫一條高優(yōu)先級(jí)的dhcp流表項(xiàng)去匹配dhcp消息，這條流表項(xiàng)只需要將dhcp消息通過(guò)相應(yīng)的端口轉(zhuǎn)交給dhcp namespace即可。之所以用namespace實(shí)現(xiàn)，是因?yàn)镈hcp消息封裝在應(yīng)用層，OpenFlow流表無(wú)法直接支持dhcp消息的封裝，因此這個(gè)活得由分布在計(jì)算節(jié)點(diǎn)上的dhcp namespace來(lái)完成。

第一種思路優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，但是一旦網(wǎng)絡(luò)節(jié)點(diǎn)發(fā)生單點(diǎn)故障，虛擬機(jī)便無(wú)法正常使用dhcp獲取IP，不過(guò)kilo版本中已經(jīng)有人在多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)中實(shí)現(xiàn)了dhcp_loadbalance（https://blueprints.launchpad.net/neutron/+spec/dhcpservice-loadbalancing）。第二種思路實(shí)現(xiàn)復(fù)雜一些，但能夠避免網(wǎng)絡(luò)節(jié)點(diǎn)單點(diǎn)故障帶來(lái)的問(wèn)題，實(shí)現(xiàn)分布式dhcp。

2.2 DVR

上一小節(jié)簡(jiǎn)略地提到了分布式的dhcp，這個(gè)工作社區(qū)有人提過(guò)但是反響并不是很大，而分布式的路由（Distributed Virtual Routing）卻很早就成為了社區(qū)的共識(shí)，并在Juno版本中給出了實(shí)現(xiàn)。

Neutron中Router用來(lái)實(shí)現(xiàn)同一租戶不同網(wǎng)段的虛擬機(jī)間的通信，這屬于東西向流量，具體可以分為兩種：1. 同一個(gè)物理節(jié)點(diǎn)上不同網(wǎng)段內(nèi)的虛機(jī)之間的通信；2. 不同物理節(jié)點(diǎn)上不同網(wǎng)段內(nèi)的虛機(jī)之間的通信。Router還用來(lái)實(shí)現(xiàn)虛擬機(jī)與Internet間的流量，這屬于南北向流量，具體也可分為兩種：1. 虛擬機(jī)訪問(wèn)Internet的流量，通常需要經(jīng)過(guò)SNAT處理；2. Internet訪問(wèn)虛擬機(jī)的流量，可能需要經(jīng)過(guò)DNAT處理。

在Neutron較早的版本中，上述流量都需要通過(guò)經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)上的Router來(lái)處理，一旦網(wǎng)絡(luò)節(jié)點(diǎn)故障或者網(wǎng)絡(luò)節(jié)點(diǎn)上的Router掛掉了，上述類型的流量也就都丟掉了。解決這一問(wèn)題也有很多種思路：

1）一種是通過(guò)部署多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)，在多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)間做調(diào)度的，不過(guò)這種很難實(shí)現(xiàn)各個(gè)Router本身狀態(tài)的一致性。

2）于是，就有了通過(guò)在Router間跑應(yīng)用層面的VRRP來(lái)同步Router狀態(tài)，這種方式是很不錯(cuò)的，VRRP協(xié)議也比較成熟。但是問(wèn)題在于，大部分流量仍然需要“繞彎子”進(jìn)行傳輸，如同一個(gè)物理節(jié)點(diǎn)上不同網(wǎng)段內(nèi)的虛機(jī)之間的通信可能需要到另一個(gè)物理節(jié)點(diǎn)的Router上處理。

3）再于是，DVR就出現(xiàn)了，通過(guò)把Router分布在各個(gè)計(jì)算節(jié)點(diǎn)中，各類流量都可以得到最優(yōu)的處理，也不會(huì)再有單點(diǎn)故障的問(wèn)題了。

接下來(lái)對(duì)DVR的講解發(fā)生在下圖的場(chǎng)景中：某租戶有紅、綠兩個(gè)網(wǎng)段，兩臺(tái)虛擬機(jī)vm1、vm2分屬兩個(gè)網(wǎng)段，分別位于計(jì)算節(jié)點(diǎn)CN1、CN2，租戶擁有一個(gè)DVR路由器r1，分布在兩個(gè)計(jì)算節(jié)點(diǎn)之上。假定vm1已經(jīng)通過(guò)ARP獲得了CN 1中r1在紅色網(wǎng)段接口的MAC地址r1 red mac，現(xiàn)在vm1發(fā)起向vm2的ping request。

拋開(kāi)流表的格式與下發(fā)的過(guò)程，先按照?qǐng)D中序號(hào)來(lái)看一看DVR流表下發(fā)后通信各個(gè)階段的數(shù)據(jù)包特征。這里規(guī)定（源MAC，目的MAC，源IP，目的IP地址）為數(shù)據(jù)包的特征4元組。

1)vm1發(fā)出的ping包特征為(vm1 mac, r1 red mac, vm1 ip, vm2 ip)，該數(shù)據(jù)包送至br-int-cn1。

2)br-int-cn1在之前ARP過(guò)程中學(xué)到了r1 red mac所在端口，將ping包直接轉(zhuǎn)發(fā)給CN1中的r1。

3)r1進(jìn)行路由，得知目的虛擬機(jī)連接在綠色網(wǎng)段上，而且r1中存有目的虛擬機(jī)的靜態(tài)ARP表項(xiàng)，不需要進(jìn)行ARP解析。于是CN1中的r1通過(guò)其綠色網(wǎng)段接口將ping包重新送回br-int-cn1。此時(shí)ping包特征為(r1 grn mac, vm2 mac, vm1 ip, vm2 ip)，br-int-cn1還不知道vm2連在哪里，進(jìn)行泛洪。

4)br-tun-cn1由br-int-cn1收到ping包，將源mac地址修改為全局唯一的dvr cn1 mac，并封裝好隧道，標(biāo)記綠色網(wǎng)段的TUNNEL_ID，直接送往CN2。此時(shí)ping包被封裝在外層包頭內(nèi)，其特征為(dvr cn1 mac, vm2 mac, vm1 ip, vm2 ip)。

5)br-tun-cn2收到后去掉外層包頭，打上綠色網(wǎng)段的本地VLAN標(biāo)簽，送給br-int-cn2，此時(shí)ping包特征仍為(dvr cn1 mac, vm2 mac, vm1 ip, vm2 ip)。

6)br-int-cn2識(shí)別出這是CN1經(jīng)過(guò)綠色網(wǎng)段送過(guò)來(lái)的流量，于是將源mac地址改回r1 grn mac并剝掉VLAN標(biāo)簽。br-int-cn2還不知道vm2連在哪里，就將ping包泛洪。此時(shí)ping包特征為(r1 grn mac, vm2 mac, vm1 ip, vm2 ip)。

7)vm2收到ping request，回復(fù)ping echo，反向的通信過(guò)程和上述基本一致。

上述步驟給出了通信的外在特征，下面說(shuō)明某些步驟內(nèi)在的實(shí)現(xiàn)原理。

1)“r1中存有目的虛擬機(jī)的靜態(tài)ARP表項(xiàng)”，是因?yàn)楦鱾€(gè)部署了DVR的計(jì)算節(jié)點(diǎn)中，l3-agent都事先從neutron數(shù)據(jù)庫(kù)中獲取了虛擬機(jī)的網(wǎng)絡(luò)信息，直接注入到了r1中。這是為了防止r1跨隧道泛洪獲取vm2的MAC地址（可以通過(guò)l2_population來(lái)實(shí)現(xiàn)）。

2)“將源mac地址修改為全局唯一的dvr cn1 mac”，是因?yàn)樵谒杏?jì)算節(jié)點(diǎn)上，r1位于相同網(wǎng)段的接口mac地址是一致的，即CN1上的r1 red/grn mac與CN2上的r1 red/grn mac一致。因此為了防止對(duì)端br-tun上的混亂， Neutron為每個(gè)部署了DVR的計(jì)算節(jié)點(diǎn)分配了全局唯一的dvr mac地址，br-tun在進(jìn)行隧道傳輸前都需要進(jìn)行源MAC地址的改寫。

“并封裝好隧道，標(biāo)記綠色網(wǎng)段的TUNNEL_ID，直接送往CN2”，DVR要求開(kāi)啟l2_population事先學(xué)習(xí)（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射，以避免隧道上的泛洪。

3)br-tun-cn2解封裝后，判斷流量由dvr cn1送過(guò)來(lái)，不進(jìn)行自學(xué)習(xí)，直接將流量送給br-int-cn2。

4)br-int-cn2中實(shí)現(xiàn)存有所有部署了DVR的計(jì)算節(jié)點(diǎn)的全局唯一的MAC地址，因而可以識(shí)別dvr cn1送過(guò)來(lái)的流量，完成源MAC地址的回寫后進(jìn)行轉(zhuǎn)發(fā)。

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

Table 0對(duì)數(shù)據(jù)包的來(lái)源進(jìn)行判斷，從與br-int相連的patch-int進(jìn)入的數(shù)據(jù)包交給Table 1處理，從VxLAN端口（以VxLAN為例）進(jìn)入的交給Table 4處理。Table 1判斷數(shù)據(jù)包是否為發(fā)向r1的ARP，或者其他發(fā)給r1的二層幀，如果是則丟棄（為了保證虛擬機(jī)送到r1的數(shù)據(jù)包只在本地轉(zhuǎn)發(fā)）。如果Table 1判斷數(shù)據(jù)包是由r1發(fā)出來(lái)的，則將源mac地址改為CN1的dvr mac地址（為了避免對(duì)端br-tun上的混亂），然后送往Table 2。Table 2根據(jù)數(shù)據(jù)包目的MAC地址判斷是否為單播，是則送往Table 20，否則送往Table 21。Table 20根據(jù)（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關(guān)系將單播包送到特定的隧道，該映射關(guān)系可事先通過(guò)L2_populaiton學(xué)習(xí)到，也可以通過(guò)Table 10的觸發(fā)學(xué)習(xí)到。Table 21將非單播包復(fù)制后送到所有隧道。進(jìn)入Table4的數(shù)據(jù)包，首先判斷TUNNE_ID是否合法，是則添加本地VLAN_ID并送往Table 9，否則丟棄。Table 9判斷數(shù)據(jù)包源mac地址是否屬于dvr mac地址（由于示例場(chǎng)景比較簡(jiǎn)單，圖中示例流表只匹配了CN2的dvr-cn2-mac），如果是直接送給br-int-cn1處理，否則轉(zhuǎn)給Table 10進(jìn)行學(xué)習(xí)。Table 10記錄數(shù)據(jù)包的VLAN_ID，MAC以及TUNNEL_ID，將（VLAN_ID，MAC）到（PORT_ID，TUNNEL_ID）的映射關(guān)系寫入Table 20，然后從與br-int相連的patch-int送出。下面給出各個(gè)流表項(xiàng)的標(biāo)注，其中紅色的為新增的DVR表項(xiàng)。

DVR對(duì)于南北向流量的處理有兩種模型，第一種是SNAT在節(jié)點(diǎn)本地完成，第二種是SNAT仍需要到網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行，兩種模型分別示意如下。在節(jié)點(diǎn)本地進(jìn)行SNAT則需要在計(jì)算節(jié)點(diǎn)的qr上為虛擬機(jī)分配浮動(dòng)IP地址，而在網(wǎng)絡(luò)節(jié)點(diǎn)完成SNAT比較節(jié)省公網(wǎng)IP資源，具體選擇哪種模型，要視用戶實(shí)際的業(yè)務(wù)需求而定。

講到這里，對(duì)Neutron OVS上的流表分析就結(jié)束了。

審核編輯：郭婷