sts conf prepare intern c2c chage container 場景 網絡流量

https://www.jianshu.com/p/0b52de73a4b3

OpenStack OVS GRE/VXLAN網絡

學習或者使用OpenStack普遍有這樣的現象：50%的時間花費在了網絡部分；30%的時間花費在了存儲方面；20%的時間花費在了計算方面。OpenStack網絡是不得不逾越的鴻溝，接下來我們一起嘗試努力穿越這個溝壑吧……J

主要參考：

RDO官網對GRE網絡的分析：

http://openstack.redhat.com/Networking_in_too_much_detail

OpenStack網絡出錯處理的一般步驟：

http://docs.openstack.org/trunk/openstack-ops/content/network_troubleshooting.html

OpenStack的主要網絡部署場景：

http://docs.openstack.org/admin-guide-cloud/content/section_networking-scenarios.html

==

OpenStack整體系統架構：

http://docs.openstack.org/trunk/openstack-ops/content/architecture.html

OpenStack網絡設計：

http://docs.openstack.org/trunk/openstack-ops/content/network_design.html

OpenStack網絡組件詳細介紹：

http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html

一OpenStack軟件架構

下圖是OpenStack軟件架構，可以看出主要的組件：

OpenStack Dashboard [Horizon]：提供web管理接口；

OpenStack Object Store [swift]：提供對象存儲服務；

OpenStack Image Service [glance]：提供鏡像管理服務；

OpenStack Computer [nova]:提供計算和簡單的網絡服務；

OpenStack Block Storage [cinder]：提供塊存儲服務；

OpenStack Networking

[Neutron]：提供網絡服務；

OpenStack Identity Service [keystone]：提供認證服務。

各個組件詳細介紹請參考：

http://docs.openstack.org/admin-guide-cloud/content/ch_install-dashboard.html

二OpenStack系統架構介紹

典型的系統架構有兩種，第一種如下圖，是傳統的nova-network架構，它也可以有多種網絡拓撲模式，包括Flat，FlatDHCP，VlanManager。

請參考：

http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html#example_architecture-nova

http://docs.openstack.org/trunk/openstack-ops/content/network_design.html#network_topology

http://blog.csdn.net/lynn_kong/article/details/8083924

第二種是OpenStack

Networking架構（先不理會HA），此種架構常用的網絡拓撲模式包括：VlanManager，GRE和VXLAN。

http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html#example_architecture-neutron

三Neutron組件詳細介紹

接下來是OpenStack Networking組件Neutron的軟件架構圖，它作為OpenStack的一個獨立組件，因此既可以獨立部署在單獨的主機上，也能與其它組件組合部署在同一主機上。但大多數情況下，Neutron組件在OpenStack架構中常以單獨的host形式提供網絡服務，作為網絡節點，這也是我們下面將重點介紹的架構。

Neutron提供多種服務，具體而言：

neutron-server服務：

neutron-server是一個守護進程，用來提供外部調用的API和與其它組件交互的接口。從圖中可看出，其中包括horizon組件，nova-compute服務和keystone認證服務。

neutron agent服務：

(1)plug-in agent(neutron-*-agent)

插件代理，需要部署在每一個運行hypervisor的主機上，它提供本地的vSwitch配置，更多的時候得依賴你具體所使用的插件類型。（常用的插件是OpenvSwitch，還包括Big

Switch，Floodinght

REST Proxy，Brocade，NSX，PLUMgrid，Ryu）

http://docs.openstack.org/admin-guide-cloud/content/section_plugin-arch.html

(2)dhcp agent(neutron-dhcp-agent)

DHCP代理，給租戶網絡提供動態主機配置服務，主要用途是為租戶網絡內的虛擬機動態地分配IP地址。

(3)l3 agent(neutron-l3-agent)

L3代理，提供三層網絡功能和網絡地址轉換(NAT)功能，來讓租戶的虛擬機可以與外部網絡通信。

(4)metering agent(neutron-metering-agent)

計量代理，為租戶網絡提供三層網絡流量數據計量服務。

查看方式：

[root@rdo-allinone ~(keystone_admin)]# cd

/etc/init.d/

[root@rdo-allinone init.d(keystone_admin)]# ll

neutron-*

-rwxr-xr-x. 1 root root 1778 Feb 19 11:10neutron-dhcp-agent

-rwxr-xr-x. 1 root root 1814 Feb 19 11:10neutron-l3-agent

-rwxr-xr-x. 1 root root 1783 Feb 19 11:10neutron-lbaas-agent

-rwxr-xr-x. 1 root root 1798 Feb 19 11:10neutron-metadata-agent

-rwxr-xr-x. 1 root root 1836 Feb 19 11:10neutron-openvswitch-agent

-rwxr-xr-x. 1 root root 1160 Feb 19 11:10neutron-ovs-cleanup

-rwxr-xr-x. 1 root root 1820 Feb 19 11:10neutron-server

[root@rdo-allinone ~(keystone_admin)]# neutron

agent-list

+--------------------------------------+--------------------+--------------+-------+----------------+

|id|agent_type|host| alive | admin_state_up|

+--------------------------------------+--------------------+--------------+-------+--------------

| 16436773-3170-46fa-8558-902d4d9c05de | DHCPagent| rdo-allinone | :-)| True|

| 7dbebfde-128c-43a8-9c70-fdbe8e49a89e | L3agent| rdo-allinone | :-)| True|

| 98cb47b5-bc50-4cd2-be24-913bf8111c57 | Open vSwitchagent | rdo-computer | :-) |True|

| ad9a4799-94a0-4541-be6a-5cab1fcb3dbf | Open vSwitchagent | rdo-allinone | :-)|True|

+--------------------------------------+--------------------+--------------+-------+--------------

從圖中也能看出Neutron不可避免與消息系統Queue和數據庫neutron

database交互。

四OpenStack-Neutron-OVS-GRE部署

前面提到了OpenStack系統架構，接下來介紹的GRE網絡使用的是上面提到的第二種架構，圖上的HA可以暫不理會。概括來說這種系統架構有著獨立的控制節點運行horizon，glance，cinder，keystone組件服務，還包括數據庫，消息系統等；獨立的網絡節點運行neutron組件服務；一個或多個獨立的計算節點運行nova組件服務。

·The Controller

Node. Provides all

functionality of the cloud except actually hosting virtual machines

or providing network services. See the "Compute Node" and "Network

Controller" for details about those roles. This server will host

the OpenStack Image Service, the OpenStack Block Storage Service,

the OpenStack Identity Service, and the OpenStack Dashboard. It

will also run portions of the OpenStack Compute service such as the

API server, the scheduler, conductor, console authenticator, and

VNC service. Finally, it hosts the API endpoint for the OpenStack

Network service.

·The Network

Node. Provides the

bulk of the OpenStack Network services such as DHCP, layer 2

switching, layer 3 routing, floating IPs (which this guide does not

configure), and metadata connectivity.

·The Compute

Node. Runs the

OpenStack Compute service as well as the OpenStack Network service

agent (in this case, the Open vSwitch plugin agent). This server

also manages an OpenStack-compatible hypervisor such as KVM or Xen.

This server will host the actual virtual machines

(instances).

為了安全和有機的讓各個組件穩定的運行，劃分網絡是很重要的工作。OpenStack的網絡主要有兩類，內部網絡和外部網絡；再細分內部網絡包括管理網絡和虛擬機之間的數據網絡，外部網絡包括互聯internet網絡和API管控網絡。其中：管理網絡主要是來管理OpenStack中各個組件的，在安裝部署時，很多配置文件項相關的網絡IP就屬於管理網絡範疇；數據網絡主要用於虛擬機之間的通信，虛擬網絡劃分，Network

as a Service等，它由OpenStack的網絡組件Neutron和網絡插件管理並操作；外部網絡就是指可以訪問互聯網和被cloud之外主機訪問或接入的通道；API網絡是對cloud之外提供的可以管理的通道，一般不與外部網絡區分開來。

·Management

network. Used forinternal communication between OpenStackcomponents.The IP addresses on this networkshould be reachable only within the datacenter.

·Data

network. Used for VMdata communication within the clouddeployment.The IP addressing requirements of thisnetwork depend on the OpenStack Networking plugin inuse.

·External

network. Provides VMswith Internet access in some deploymentscenarios.The IP addresses on this network shouldbe reachable by anyone on theInternet.

·API

network. Exposes allOpenStack APIs, including the OpenStack Networking API, totenants.The IP addresses on this network shouldbe reachable by anyone on the Internet.This maybe the same network as the external network, as it is possible tocreate a quantum subnet for the external network that uses IPallocation ranges to use only less than the full range of IPaddresses in an IP block.

具體網絡劃分如下：（網絡使用情況會直接反應在keystone endpoint-list

的內容）

管理網絡：192.168.10.0/24（配置在eth0上），部署OpenStack環境時，各種服務的配置文件均會使用這個網卡上的IP。

數據網絡：192.168.100.0/24（配置在eth1上），用來連通各個節點上的br-tun網橋，構造通信平面，這個通信層可以構建隧道[GRE]，也可以構建L3通信協議層[VXLAN]。同時它也負責連通租戶虛擬網絡內的網絡設備，使虛擬機之間進行網絡通信。

Public/API網絡：10.1.101.0/24（配置在eth2上）外部網關是10.1.101.254，一般用在控制節點和網絡節點上，需要和外部通信。

租戶網絡：是用軟件定義出來的虛擬網絡[10.0.0.0/24]，參考如下

neutron net-create Ext-Net--provider:network_type gre/vxlan--provider:segmentation_id 1 --router:external true

neutronsubnet-create--allocation-poolstart=10.1.101.240,end=10.1.101.252 --gateway10.1.101.254Ext-Net 10.1.101.0/24--enable_dhcp=False

vim A_prepare.sh

#!/bin/bash

# Create Tenant and User

#

tenant=TenantA

user=UserA

[email protected]

role=Member

if keystone tenant-list | grep

-q $tenant;then

echo "Tenant $tenant existed!"

else

tenant_id=`keystone tenant-create --name $tenant | awk ‘/id/{print$4}‘`

fi

if keystone user-list | grep -q

$user;then

echo "User $user existed!"

else

keystone user-create --name=$user --pass=password --tenant-id$tenant_id --email=$usermail

fi

keystone user-role-add --tenant

$tenant --user $user --role $role

neutron --os-tenant-name

$tenant --os-username $user --os-password password

--os-auth-url=http://localhost:5000/v2.0 net-create

$tenant-Net

subnet_id=`neutron

--os-tenant-name $tenant --os-username $user --os-password password

--os-auth-url=http://localhost:5000/v2.0 subnet-create $tenant-Net

10.0.0.0/24 | awk ‘$2~/^id/{print $4}‘`

neutron --os-tenant-name

$tenant --os-username $user --os-password password

--os-auth-url=http://localhost:5000/v2.0 router-create

$tenant-R1

neutron --os-tenant-name

$tenant --os-username $user --os-password password

--os-auth-url=http://localhost:5000/v2.0 router-interface-add

$tenant-R1 ${subnet_id}

neutron router-gateway-set

$tenant-R1 Ext-Net

可以參考RDO官方文檔http://openstack.redhat.com/GettingStartedHavana_w_GRE使用RDO部署多節點的OpenStack-Neutron-OVS-GRE環境。按照以上網絡劃分和網卡地址分配，你將更容易的修改RDO的配置文件，部署你所需要的網絡環境。

CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=gre

CONFIG_NEUTRON_OVS_TUNNEL_RANGES=1:1000

CONFIG_NEUTRON_OVS_TUNNEL_IF=eth1

安裝完成後在安裝了neutron組/插件的主機上可以看到vim

/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini +157配置項local_ip為eth1地址。

五OpenStack-Neutron-OVS網絡

先了解一下這些網絡設備命名的規律：

（1）TenantA的router和Linux網絡命名空間qrouter名稱

# neutron --os-tenant-name TenantA --os-username UserA--os-password password --os-auth-url=http://localhost:5000/v2.0router-list --field id

|165f931b-4e08-46eb-a048-f8c62b72b48e|

# ip netns

qrouter-165f931b-4e08-46eb-a048-f8c62b72b48e

即租戶虛擬路由器的ID號，與qrouter命名相對應。

（2）TenantA的network和Linux網絡命名空間qdhcp名稱

# neutron --os-tenant-name TenantA --os-username UserA--os-password password --os-auth-url=http://localhost:5000/v2.0net-list--field id --fieldname

|id|name|

|4b9ccec6-0d8c-496c-bad3-a26ce01af708 | TenantA-Net

|

| 7f70cae2-fd78-486f-ac62-dabadfbb0959 |Ext-Net|

# ip netns

qdhcp-4b9ccec6-0d8c-496c-bad3-a26ce01af708

即租戶虛擬網絡的ID號，與qdhcp命名相對應。

（3）TenantA網絡端口和其它的網絡設備的名稱

# neutron --os-tenant-name TenantA --os-username UserA

--os-password password --os-auth-url=http://localhost:5000/v2.0

port-list

+--------------------------------------+------+-------------------+-------------------------------

|id|name |mac_address| fixed_ips

+--------------------------------------+------+-------------------+-------------------------------

|4c2c44d9-4b00-4094-9b21-aeb811d213d9|| fa:16:3e:eb:06:2d | {"subnet_id":"cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.2"}|

|6455f9c4-2c63-4c22-abe6-a93bb59130fa|| fa:16:3e:35:a0:f2 | {"subnet_id":"cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.1"}|

|9e6562b4-6bc8-4e73-b794-55215c1a9d7c|| fa:16:3e:49:00:b5 | {"subnet_id":"cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.4"}|

|f2ce023b-aa4d-4a78-a36f-ae121c4164f7|| fa:16:3e:9c:5e:55 | {"subnet_id":"cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.3"}|

+--------------------------------------+------+-------------------+-------------------------------

IP地址為10.0.0.2的虛擬機端口為4c2c44d9-4b00-4094-9b21-aeb811d213d9，那麽上圖中與之相連的網絡設備tap，qbr，qvb，qvo的命名都是加上port

ID前綴的11個字符。同理qr加上IP地址為10.0.0.1的端口ID號前綴就是qrouter下的設備名了；qg加上IP地址為外網的10.1.101.xxx端口ID號前綴就是qrouter先的qg設備名了；tap加上IP地址為10.0.0.3的端口ID號前綴就是qdhcp下的設備名了。

可以使用下面這些命令驗證：

# neutron port-list

# ifconfig

# ovs-vsctl show

# ip netns exec

qrouter-165f931b-4e08-46eb-a048-f8c62b72b48e ifconfig

# ip netns exec qdhcp-4b9ccec6-0d8c-496c-bad3-a26ce01af708

ifconfig

舉例說明：

系統中的網絡設備：

一個外部網絡Ext-Net(8583f2ba-37da-4fa0-b312-f9b0979a4fea)；它的子網是ef11b954-d328-4851-a31e-f4bcaefba42b，網段為10.1.101.0/24，但是分配的地址池是從10.1.101.240到10.1.101.252。

還有一個租戶網絡TenantA-Net（TenantA的網絡，ID號為84191af8-269f-485a-b394-85d79e53a39a，對應著qdhcp-84191af8-269f-485a-b394-85d79e53a39a）；它的子網是b2bc3ba5-667c-4df1-a74f-448ce8261fff，網段為10.0.0.0/24，地址池是10.0.0.2到10.0.0.254。TenantA還有一個私有的路由器TenantA-R1（ID號為45765633-1bd6-41c7-bdfc-7d425818135a，對應著qrouter-45765633-1bd6-41c7-bdfc-7d425818135a）。

系統中的網絡端口：

neuron port-list出來一共有6個端口：

顯然端口974a43e3-90a5-4066-83b1-ac819b29966b（10.0.0.2）和端口0f474d5d-519d-4aef-a633-e4d910cc1b1a（10.0.0.4）是虛擬機cirros-0001和cirros-0002的私有IP地址端口（虛擬機tap網絡設備端口）。[並且虛擬機cirros-0001位於computer-02上，cirros-0002位於computer-01上]

端口beabcafe-044d-43f2-bed9-7597d9dfe051（10.1.101.241）是一個浮點IP端口，它綁定在了虛擬機cirros-0001（0aaecb00-0ca2-4c60-bf7c-869eb0570ba8）上。

端口6defad4c-b22c-4216-8de6-8eba533f6c5b（10.0.0.1）和端口d7e5d255-6247-4483-841b-19860161392f（10.1.101.240）是qrouter上面的網絡端口。分別作TenantA的網絡環境中，子網是b2bc3ba5-667c-4df1-a74f-448ce8261fff（網段為10.0.0.0/24）的網關qr-6defad4c-b2和外網通道qg-d7e5d255-62。[多個網絡對應多個qrouter，即qr和qg設備]

端口ae8517df-a628-4252-ad0c-38806d8549d8（10.0.0.3）是qdhcp上面的網絡端口tapae8517df-a6，為TenantA的網絡環境中，子網是b2bc3ba5-667c-4df1-a74f-448ce8261fff（網段為10.0.0.0/24）的網段動態分配私有IP地址，提供子網dhcp服務。[多個子網對應多個qdhcp，即tap設備]

網絡節點上的Linux網橋和OVS網橋：

由上圖可以看出網絡節點沒有運行虛擬機，所以Linux網橋為空。OVS網橋br-int上面有qrouter的qr端口和qdhcp的tap端口；OVS網橋br-ex上面有qrouter的qg端口，並且br-ex與物理網卡eth2相連；OVS網橋br-tun只是patch網橋br-int和構建隧道平面。

computer-01節點上的Linux網橋和OVS網橋：

由上圖可以看出計算節點computer-01節點上面運行虛擬機cirros-0002（3a0ad0d1-ae47-486b-98b2-6e56181fda9e）網絡端口為0f474d5d-519d-4aef-a633-e4d910cc1b1a（10.0.0.4）。可以看到qvb0f474d5d-51端口qbr0f474d5d-51端口和tap0f474d5d-51端口。OVS網橋br-int上面有qvo0f474d5d-51端口；OVS網橋br-tun只是patch網橋br-int和構建隧道平面。

computer-02節點上的Linux網橋和OVS網橋：

由上圖可以看出計算節點computer-02節點上面運行虛擬機cirros-0001（0aaecb00-0ca2-4c60-bf7c-869eb0570ba8）網絡端口為974a43e3-90a5-4066-83b1-ac819b29966b（10.0.0.2）。可以看到qvb974a43e3-90端口qbr974a43e3-90端口和tap974a43e3-90端口。OVS網橋br-int上面有qvo974a43e3-90端口；OVS網橋br-tun只是patch網橋br-int和構建隧道平面。

虛擬機中數據包傳遞路徑：

上圖是一個典型的Neutron-OVS-GRE網絡模式，有兩個計算節點Computer-01和Computer-02；一個網絡節點Network-node。

假設物理計算節點Computer-02上面的虛擬機VM-003網卡eth0上有網絡數據包向外部物理路由器網關10.1.101.254發出：那麽數據會依次經過tap設備；qbr

Linux Bridge設備；qvb和qvo虛擬網絡設備；到達物理計算節點的OVS網橋br-int上；br-int將數據包attach到計算節點Computer-02的OVS網橋br-tun上；數據包再從計算節點Computer-02上的OVS網橋br-tun與網絡節點Network-node上的OVS網橋br-tun構成的網絡隧道穿過，交付到網絡節點的OVS網橋br-int上；網絡節點上的br-int通過qr設備借助Linux網絡命名空間qrouter連通br-ex上的qg設備，將數據包交付到OVS網橋br-ex上；最後br-ex通過網絡節點的外部物理網口eth2把數據包送達到外部路由器網關。

分別介紹數據包途徑的網絡設備：

計算節點：

（1）與虛擬機相連的TAP設備

從上圖中可以看出，Computer-02上面的虛擬機VM-003的eth0網口與一個tap設備相連。但這個tap設備為什麽不直接與計算節點上的br-int網橋相連，而是上圖黃色框中所展現的連接情況呢？理想的情況應該是Computer-01上面的綠色框所示。

既然br-int也是網橋，為什麽還要穿過Linux bridge

qbr設備，這樣qbr設備，qvb設備，qvo設備豈不是就顯得多余了。沒辦法，哲學上說存在即合理，qbr的存在當然另有它用，官網文檔有這樣的一句話：

http://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1

Security groups:

iptables and Linux bridges

Ideally, the TAP

devicevnet0would

be connected directly to the integration bridge,br-int.

Unfortunately, this isn‘t possible because of how OpenStack

security groups are currently implemented. OpenStack uses iptables

rules on the TAP devices such asvnet0to

implement security groups, and Open vSwitch is not compatible with

iptables rules that are applied directly on TAP devices that are

connected to an Open vSwitch port.

Networking uses an extra Linux

bridge and a veth pair as a workaround for this issue. Instead of

connectingvnet0to

an Open vSwitch bridge, it is connected to a Linux

bridge,qbrXXX.

This bridge is connected to the integration

bridge,br-int,

through the(qvbXXX,qvoXXX)veth

pair.

意思就是說OVS的網橋br-int沒有設置iptables規則的功能，但OpenStack又想要(或必須)提供安全組服務，那麽就借助了Linux

Bridge的功能。雖說OVS的br-int網橋和Linux

Bridge都是二層橋，但是為了功能相互彌補，就同時出現了。

個人觀點：Linux Bridge這種拿來主義的做法大大簡化了組件的開發，但是這樣無疑增加了其復雜性和冗余度，並且從實踐中發現這種做法帶來了不少問題。比如http://blog.sina.com.cn/s/blog_6de3aa8a0101lnar.html最後提到的問題，就是OVS網橋和Linux網橋混用造成的。因此，另尋別的途徑來簡化實現OpenStack安全組是一件有意義的事，今後將對此深入調研。

（2）OVS一體化網橋br-int

br-int是OpenvSwitch創建的虛擬網橋，但在實際運行中它充當著虛擬交換機的角色，br-int上的端口tap設備將宿主機上的虛擬機實例連接到同一網絡交換層上。再透過本機OVS網橋br-tun的互聯協議可以將OpenStack系統架構中所有節點的br-int組織成一個更大的虛擬交換機BR-INT{compuer-01-br-int

+ compuer-02-br-int….}。這是一種很重要的抽象思想，如此一來就好像OpenStack環境中所有的虛擬機實例都連接到了一個巨型的虛擬機交換機上。遺憾的是這個虛擬機交換機的功能有限，不能設定iptables規則實現安全組服務，因此通過qvo，qvb去連接qbr借助linux網橋完成這個工作。所以在計算節點ovs-vsctl

show中的br-int網橋看到tap設備和qvo設備共存也就不足為奇了。

（3）OVS通道網橋br-tun

br-tun是OVS創建的虛擬網橋，它的作用是向下直接與br-int連接作為網絡數據的進出口；對上通過特定的通信協議與各個節點上的br-tun相連構成一個扁平的通信/通道層。如果把所有的br-int構成的抽象層次定義為虛擬二層網絡，那麽所有的br-tun構成的抽象層次便是虛擬三層網絡了。如此說來似乎有點網絡虛擬化的味道了。

網絡節點：

（1）OVS通道網橋br-tun

它與計算節點上的br-tun作用相同，只是作為通道層用於連接別的物理節點。唯一不同的是這個br-tun連接的是網絡節點的br-int，網絡節點br-int與計算節點的br-int區別較大。

（2）OVS一體化網橋br-int

br-int是OpenvSwitch創建的虛擬網橋，也起到了虛擬交換機作用。上面主要有兩類設備：一類是tap設備；另一類是qr設備。linux網絡命名空間namespaceqdhcp和qrouter均由l3-agent所創建，用來隔離管理租戶的虛擬網絡和路由。br-int上的tap設備，ip地址一般為xxx.xxx.xxx.3與dnsmasq進程構成qdhcp，為新創建的虛擬機動態分配私有IP地址。qr-int上的qr設備，IP地址一般為xxx.xxx.xxx.1與br-ex的qg設備構成qrouter，為租戶網絡做路由轉發，通過qg打通租戶內部的虛擬網絡和外部的物理網絡。

（3）OVS外部網橋br-ex

br-ex是OpenvSwitch創建的虛擬網橋，網橋上有qg設備端口，它是打通租戶網絡和外部網絡的重要通道。另外br-ex與物理網卡（圖中是eth2）相連，通往internet網絡。

六OpenStack

Neutron OVS-GRE和OVS-VXLAN網絡

VXLAN介紹：http://blog.sina.com.cn/s/blog_6de3aa8a0101oisp.html

通過上面介紹OVS在neutron中的使用及各個網橋的功能，那麽也就能很容易的理解OVS-GRE和OVS-VXLAN的區別了：關鍵在於各個節點br-tun網橋構成的通道層的連通方式。若br-tun之間兩兩點對點的連接，通信封包為GRE格式，那麽這樣的網絡環境就是OpenStack-Neutron-OVS-GRE網絡模式。同理，若br-tun之間跑三層網絡協議，封包方式為VXLAN格式，這樣的網絡環境就是OpenStack-Neutron-OVS-VXLAN網絡模式。對於GRE和VXLAN網絡模式而言，可以抽象地將每個br-tun看成隧道端點，有狀態的隧道點對點連接即為GRE；無狀態的隧道使用UDP協議連接則為VXLAN。這樣說的依據是RDO的官方文檔（http://openstack.redhat.com/Using_VXLAN_Tenant_Networks）部署VXLAM_Tenant_Networs的過程就可以看出。

接下來不看官方RFC文檔也可以大致猜測一下GRE和VXLAN這兩種網絡模式哪個更好了？答案是VXLAN網絡模式！我為什麽這麽猜測呢，因為OVS-GRE和OVS-VXLAN這兩種br-tun之間的連接協議中，顯然VXLAN的三層方式要比GRE的點對點方式更高級！當然這樣看問題是非常片面的，具體情形還請君視需求而定。

VXLAN：http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-09

GRE：http://tools.ietf.org/html/rfc2784.html

OpenStack OVS GRE/VXLAN