個人翻譯和理解有限，有錯誤的地方請各位大牛指正

前言

openstack網路的建立是為定義網路連線和雲中的定址提供豐富的API，Neutron服務（先前被稱為“Quantum”），使運營商能夠利用不同的網路技術去搭建他們的雲網絡。 作為與昆騰公司（ “量子”商標的所有者）的一份法律協議的一部分，參與網路相關的開發和文件董事會董事和技術委員會成員已決定更改程式碼名稱為“Neutron” 。
在本指南中，儘可能的刪除對以前程式碼名稱的任何引用，所有的配置檔案已經分別在 “Havana”和本指南中更新。

目標讀者

本指南幫助OpenStack的管理員利用不同的網路技術去搭建雲網絡。本文件介紹瞭如何安裝，配置和執行OpenStack的網路。
你也應該熟悉如何按照運營商的檔案中所描述的執行OpenStack計算服務。

文件修改歷史

此版手冊將取代並淘汰所有先前的版本。下表描述了最近的變化：

Revision Date	Summary of Changes
May 9, 2013	Updated the book title for consistency.
April 30, 2013	Grizzly release.
March 24, 2013	Added auth_token parameters to the neutron.conf file description.
February 4, 2013	Use OpenStack naming conventions through out document.
December 20, 2012	Trunk designation of this document.
November 9, 2012	Folsom release of this document.
September 18, 2012	First edition of this document.

資源

OpenStack的網路和其他相關專案的更多資訊，請參閱該專案OpenStack的維基（ wiki.openstack.org /Neutron） 。

關於對OpenStack的網路API程式設計的詳細資訊，請參閱OpenStack的網路API指南（ V2.0 ） 。

我們歡迎反饋，意見和bug報告在bugs.launchpad.net /Neutron。

openstack網路架構

本節描述openstack網路高階元件，在你部署openstack網路之前，瞭解不同的解決方案，以及這些元件之間和其他服務是如何相互互動，非常有用。

概述

OpenStack的網路是一個獨立的服務，就像其他的OpenStack的服務，如OpenStack計算服務， OpenStack的映象服務，OpenStack的身份認證服務，或OpenStack的介面。和這些服務類似，部署OpenStack的網路往往涉及到各個主機上部署多個程序。
openstack網路服務的主程序是neutron-server，這是一個python的守護程序，暴露了openstack網路API，將使用者的請求傳遞到openstack網路外掛以配置額外的處理。通常情況下，這個外掛需要訪問資料庫做持久儲存（和其他openstack服務） 如果你的部署方式是使用一臺控制主機來集中管理OpenStack計算元件，那麼你可以在同一主機上部署OpenStack的網路服務。不過， OpenStack的網路是完全獨立的，並可以部署在自己的主機上。 OpenStack的網路也可能需要的額外的代理，這得看你的部署方式 有以下三種代理方式： 外掛代理：執行在每個虛擬機器管理程式來執行本地vswitch配置。是否執行代理將取決於您使用的外掛，因為有些外掛實際上並不需要代理。 DHCP代理（neutron-DHCP代理：為租戶網路提供DHCP服務。這個代理對所有外掛是一樣的。
L3代理（neutron-L3代理）：提供L3/NAT轉發為租戶網路上的虛擬機器提供外部網路訪問。這個代理對所有外掛也是一樣的。
以上的代理通過RFC(比如rabbitmq 或者qpid)，或者標準的openstack網路API 和neutron主程序進行互動。 此外 openStack的網路依賴OpenStack的身份服務（keystone）的身份驗證和授權的所有API。 openstack網路與openstack計算（nova）通過標準API進行互動，作為建立虛擬機器的一部分，nova計算服務和openstack網路API的通訊，是插入到每個特定網路的每個虛擬機器的虛擬網絡卡上的
openstack的介面（horizon）集成了openstack網路的API，允許管理員和租戶使用者通過介面去建立和管理網路服務 在物理機上部署服務 和其他的openstack服務一樣，openstack網路給雲管理員決定在某個伺服器上執行某個服務提供了顯著的靈活性。一個極端情況是，所有服務的守護程序都執行在一個單一的物理主機上。另外，每個服務都可以執行在自己的主機上，在某些情況下可以複製冗餘的主機。欲瞭解更多情況，請參見高可用性high availability. 我們將注意力主要集中在一個標準的架構，包括一臺控制主機和一臺網路主機，以及一套正在執行的虛擬機器管理程式，控制主機和網路主機可以部署在一臺主機上。但是假如你希望虛擬機器從網路上傳送大量的的流量，那麼建議你使用單獨的網路主機，以避免潛在的CPU爭用L3代理和其他的openstack服務 網路拓撲
一個標準的OpenStack的網路有四種不同的物理資料中心網路：
管理網路：用於OpenStack的元件之間的內部溝通。在此網路上的IP地址應該只限於在資料中心內部訪問
資料網路：用於雲內部署虛擬機器的資料通訊。這個網路的IP定址要求依賴於OpenStack的網路正在使用的外掛。
外部網路：用於提供虛擬機器在某些部署情況下連線外網。這個網路上的IP地址應該是在網際網路上可以被任何人訪問。 API網路：  對租戶公開所有的OpenStack的API ，包括OpenStack的網路API 。這個網路上的IP地址應該是在網際網路上可以被任何人訪問。 API網路跟外部網路一樣，因為它可以建立一個外部子網，當使用不了全部的ip地址的時候，可以分配ip地址的範圍。

先發表了，後面慢慢翻譯。。。（翻譯好費力啊。。。） 人數破100了啊。。。繼續翻譯 OpenStack的網路部署使用案例
以下幾個圖是比較經典的 案例一：單平面網路（Single Flat Network，這個術語不太好翻譯就直接翻譯了） 在最簡單的情況下，建立的一個openstack網路。這是一個“共享”的網路，這意味著對所有的租戶都是可見的，租戶的每臺虛擬機器都有單一的網絡卡，並從該網路的子網獲得固定的ip地址，這個使用案例基本上對映到OpenStack計算所提供的FlatManager和FlatDHCPManager模型。不支援浮動IP地址。 這種型別的網路，常常被openstack管理員對映到資料中心的現有物理網路上（故被稱為“服務提供商網路”），這使得供應商可以使用資料中心的物理路由器作為閘道器讓虛擬機器到達外部世界，對於openstack外部網路的每一個子網，物理路由器的閘道器配置必須是手動的。
案例二：多平面網路 除了租戶可以通過openstack API看到多個不同的共享網路和可以選擇插入不同的網路外，本案例類似於上述的單平面網路
案例三：混雜的平面和專用網路
這個用例是上述模式的延伸，除了能夠看到一個或者多個共享網路之外，租戶還可以擁有自己專有的網路（對唯一租戶可用的網路） 虛擬機器可以有多個網絡卡來插入任意一個共享網路或者獲得任意一個專屬的私有網路，這種具有多個網絡卡的虛擬機器的建立使多層網路拓撲結構成為可能。它還支援虛擬機器充當閘道器，從而提供像路由，NAT，負載均衡等等的服務。
案例四：供應商路由器和專用網路 該用例提供每個租戶一個或多個專用網路，通過OpenStack的網路路由器連線到外面的世界。每個租戶的網路，對映為相同的邏輯拓撲的VlanManager（儘管OpenStack的網路不需要VLAN）。使用OpenStack的網路API ，租戶只能看到分配給該租戶的每個專用網路，而API中的路由器物件是由openstack的雲管理員所建立和持有
這個模型支援浮動ip，路由器通過浮動ip將外部網路的地址對映到虛擬機器的私有網路的固定ip上，沒有浮動ip的主機仍然可以連線外部網路，因為提供商路由器對路由器的外部ip實現了SNAT，物理路由器的IP地址作為外部網路的子網gateway_ip，所以供應商具有網際網路流量的預設路由器。 路由器提供給專用網路的L3連線，這意味著除非使用額外的過濾（例如安全組），不同的租戶才可以互相連線。因為只有單一的路由器，所以租戶的網路不能使用重疊的ip地址。因此它可能是管理員將建立代表租戶的私有網路。
案例五：租戶路由器和專用網路
此用例代表了更先進的路由器，在這種情況下每個租戶得到至少一個路由器，並有可能通過openstack的網路API建立更多的路由器，租戶可以建立自己的網路，這些網路上行到路由器上。這種模式允許租戶定義，多層次的應用。每一層是路由器後面的一個單獨的網路。因為有多個路由器，租戶的子網可以無衝突的重疊，因為訪問外部網路是通過SNAT或者浮動ip發生的。每個路由器上行和浮動IP是來自外部網路的子網分配。