openstack/openstack-manuals
Code Issues Proposed changes

Merge "transforming listings to tables in chapter networking"

Browse Source
This commit is contained in:
Jenkins 2013-10-25 17:21:58 +00:00 committed by Gerrit Code Review
commit 9837bb066a
2 changed files with 317 additions and 284 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

408
doc/admin-guide-cloud/ch_networking.xml
View File

@ -33,29 +33,34 @@
<para>The Compute API has a virtual server abstraction to <para>The Compute API has a virtual server abstraction to
describe computing resources. Similarly, the describe computing resources. Similarly, the
Networking API has virtual network, subnet, and port Networking API has virtual network, subnet, and port
abstractions to describe networking resources. In more abstractions to describe networking resources.</para>
detail:</para> <para>
<itemizedlist> <table rules="all">
<listitem> <caption>Networking resources</caption>
<para><emphasis role="bold">Network</emphasis>. An <col width="10%"/>
isolated L2 segment, analogous to VLAN in the <col width="90%"/>
physical networking world.</para> <thead>
</listitem> <tr>
<listitem> <th>Resource</th>
<para><emphasis role="bold">Subnet</emphasis>. A <th>Description</th>
block of v4 or v6 IP addresses and associated </tr>
configuration state.</para> </thead>
</listitem> <tbody>
<listitem> <tr>
<para><emphasis role="bold">Port</emphasis>. A <td><emphasis role="bold">Network</emphasis></td>
connection point for attaching a single <td>An isolated L2 segment, analogous to VLAN in the physical networking world.</td>
device, such as the NIC of a virtual server, </tr>
to a virtual network. Also describes the <tr>
associated network configuration, such as the <td><emphasis role="bold">Subnet</emphasis></td>
MAC and IP addresses to be used on that <td>A block of v4 or v6 IP addresses and associated configuration state.</td>
port.</para> </tr>
</listitem> <tr>
</itemizedlist> <td><emphasis role="bold">Port</emphasis></td>
<td>A connection point for attaching a single device, such as the NIC of a virtual server, to a virtual network. Also describes the associated network configuration, such as the MAC and IP addresses to be used on that port.</td>
</tr>
</tbody>
</table>
</para>
<para>You can configure rich network topologies by <para>You can configure rich network topologies by
creating and configuring networks and subnets, and creating and configuring networks and subnets, and
then instructing other OpenStack services like Compute then instructing other OpenStack services like Compute
@ -98,100 +103,88 @@
others might use more advanced technologies, such as others might use more advanced technologies, such as
L2-in-L3 tunneling or OpenFlow, to provide similar L2-in-L3 tunneling or OpenFlow, to provide similar
benefits.</para> benefits.</para>
<para>Networking includes the following plug-ins:</para> <para>
<itemizedlist> <table rules="all">
<listitem> <caption>Available networking plugins</caption>
<para><emphasis role="bold">Big Switch Plug-in <col width="40%"/>
(Floodlight REST Proxy)</emphasis>. <link <col width="60%"/>
xlink:href="http://www.openflowhub.org/display/floodlightcontroller/Neutron+REST+Proxy+Plugin" <thead>
<tr>
<th>Plugin</th>
<th>Documentation</th>
</tr>
</thead>
<tbody>
<tr>
<td><emphasis role="bold">Big Switch Plug-in (Floodlight REST Proxy)</emphasis></td>
<td>
<link xlink:href="http://www.openflowhub.org/display/floodlightcontroller/Neutron+REST+Proxy+Plugin"
>http://www.openflowhub.org/display/floodlightcontroller/Neutron+REST+Proxy+Plugin</link> >http://www.openflowhub.org/display/floodlightcontroller/Neutron+REST+Proxy+Plugin</link>
</para> </td>
</listitem> </tr>
<listitem> <tr>
<para><emphasis role="bold">Brocade <td><emphasis role="bold">Brocade Plug-in</emphasis></td>
Plug-in</emphasis>. <link <td><link xlink:href="https://github.com/brocade/brocade"
xlink:href="https://github.com/brocade/brocade" >https://github.com/brocade/brocade</link></td>
>https://github.com/brocade/brocade</link> </tr>
</para> <tr>
</listitem> <td><emphasis role="bold">Cisco</emphasis></td>
<listitem> <td><link xlink:href="http://wiki.openstack.org/cisco-neutron"
<para><emphasis role="bold">Cisco</emphasis>. >http://wiki.openstack.org/cisco-neutron</link></td>
<link </tr>
xlink:href="http://wiki.openstack.org/cisco-neutron" <tr>
>http://wiki.openstack.org/cisco-neutron</link> <td><emphasis role="bold">Cloudbase Hyper-V Plug-in</emphasis></td>
</para> <td><link xlink:href="http://www.cloudbase.it/quantum-hyper-v-plugin/"
</listitem> >http://www.cloudbase.it/quantum-hyper-v-plugin/</link></td>
<listitem> </tr>
<para><emphasis role="bold">Cloudbase Hyper-V <tr>
Plug-in</emphasis>. <link <td><emphasis role="bold">Linux Bridge Plug-in</emphasis></td>
xlink:href="http://www.cloudbase.it/quantum-hyper-v-plugin/" <td><link xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin"
>http://www.cloudbase.it/quantum-hyper-v-plugin/</link> >http://wiki.openstack.org/Neutron-Linux-Bridge-Plugin</link></td>
</para> </tr>
</listitem> <tr>
<listitem> <td><emphasis role="bold">Mellanox Plug-in</emphasis></td>
<para><emphasis role="bold">Linux Bridge <td><link xlink:href="https://wiki.openstack.org/wiki/Mellanox-Neutron/"
Plug-in</emphasis>. Documentation included >https://wiki.openstack.org/wiki/Mellanox-Neutron/</link></td>
in this guide at <link </tr>
xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin" <tr>
>http://wiki.openstack.org/Neutron-Linux-Bridge-Plugin</link> <td><emphasis role="bold">Midonet Plug-in</emphasis></td>
</para> <td><link xlink:href="http://www.midokura.com/"
</listitem> >http://www.midokura.com/</link></td>
<listitem> </tr>
<para><emphasis role="bold">Mellanox <tr>
Plug-in</emphasis>. <link <td><emphasis role="bold">ML2 (Modular Layer 2) Plug-in</emphasis></td>
xlink:href="https://wiki.openstack.org/wiki/Mellanox-Neutron/" <td><link xlink:href="https://wiki.openstack.org/wiki/Neutron/ML2"
>https://wiki.openstack.org/wiki/Mellanox-Neutron/</link> >https://wiki.openstack.org/wiki/Neutron/ML2</link></td>
</para> </tr>
</listitem> <tr>
<listitem> <td><emphasis role="bold">NEC OpenFlow Plug-in</emphasis></td>
<para><emphasis role="bold">Midonet <td><link xlink:href="http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin"
Plug-in</emphasis>. <link >http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin</link></td>
xlink:href="http://www.midokura.com/"> </tr>
http://www.midokura.com/</link></para> <tr>
</listitem> <td><emphasis role="bold">Nicira NVP Plug-in</emphasis></td>
<listitem> <td><link xlink:href="http://www.vmware.com/products/datacenter-virtualization/nicira.html"
<para><emphasis role="bold">ML2 (Modular Layer 2) >NVP Product Overview</link>, <link xlink:href="http://www.nicira.com/support"
Plug-in</emphasis>. <link >NVP Product Support</link></td>
xlink:href="https://wiki.openstack.org/wiki/Neutron/ML2"> </tr>
https://wiki.openstack.org/wiki/Neutron/ML2</link></para> <tr>
</listitem> <td><emphasis role="bold">Open vSwitch Plug-in</emphasis></td>
<listitem> <td>included in this guide</td>
<para><emphasis role="bold">NEC OpenFlow </tr>
Plug-in</emphasis>. <link <tr>
xlink:href="http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin" <td><emphasis role="bold">PLUMgrid</emphasis></td>
>http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin</link> <td><link xlink:href="https://wiki.openstack.org/wiki/PLUMgrid-Neutron"
</para> >https://https://wiki.openstack.org/wiki/PLUMgrid-Neutron</link></td>
</listitem> </tr>
<listitem> <tr>
<para><emphasis role="bold">Nicira NVP <td><emphasis role="bold">Ryu Plug-in</emphasis></td>
Plug-in</emphasis>. Documentation is <td><link xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
included in this guide, <link >https://github.com/osrg/ryu/wiki/OpenStack</link></td>
xlink:href="http://www.vmware.com/products/datacenter-virtualization/nicira.html" </tr>
>NVP Product Overview</link>, and <link </tbody>
xlink:href="http://www.nicira.com/support" </table>
>NVP Product Support</link> </para>
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Open vSwitch
Plug-in</emphasis>. Documentation included
in this guide.</para>
</listitem>
<listitem>
<para><emphasis role="bold">PLUMgrid</emphasis>.
<link
xlink:href="https://wiki.openstack.org/wiki/PLUMgrid-Neutron"
>https://https://wiki.openstack.org/wiki/PLUMgrid-Neutron</link>
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Ryu
Plug-in</emphasis>. <link
xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
>https://github.com/osrg/ryu/wiki/OpenStack</link>
</para>
</listitem>
</itemizedlist>
<para>Plug-ins can have different properties for hardware requirements, features, <para>Plug-ins can have different properties for hardware requirements, features,
performance, scale, or operator tools. Because Networking supports a large number of performance, scale, or operator tools. Because Networking supports a large number of
plug-ins, the cloud administrator can weigh options to decide on the right plug-ins, the cloud administrator can weigh options to decide on the right
@ -375,31 +368,43 @@
Networking is entirely standalone and can be deployed Networking is entirely standalone and can be deployed
on its own host as well. Depending on your deployment, on its own host as well. Depending on your deployment,
Networking can also include the following Networking can also include the following
agents:</para> agents.</para>
<itemizedlist> <para>
<listitem> <table rules="all">
<para><emphasis role="bold">plug-in <caption>Networking agents</caption>
agent</emphasis> <col width="30%"/>
(<literal>neutron-*-agent</literal>). Runs <col width="70%"/>
on each hypervisor to perform local vswitch <thead>
configuration. The agent that runs depends on <tr>
the plug-in that you use, and some plug-ins do <th>Agent</th>
not require an agent.</para> <th>Description</th>
</listitem> </tr>
<listitem> </thead>
<para><emphasis role="bold">dhcp agent</emphasis> <tbody>
(<literal>neutron-dhcp-agent</literal>). <tr>
Provides DHCP services to tenant networks. <td><emphasis role="bold">plug-in agent</emphasis>
Some plug-ins use this agent.</para> (<literal>neutron-*-agent</literal>)</td>
</listitem> <td>Runs on each hypervisor to perform local vswitch
<listitem> configuration. The agent that runs depends on
<para><emphasis role="bold">l3 agent</emphasis> the plug-in that you use, and some plug-ins do
<literal>(neutron-l3-agent</literal>). not require an agent.</td>
Provides L3/NAT forwarding to provide external </tr>
network access for VMs on tenant networks. <tr>
Some plug-ins use this agent.</para> <td><emphasis role="bold">dhcp agent</emphasis>
</listitem> (<literal>neutron-dhcp-agent</literal>)</td>
</itemizedlist> <td>Provides DHCP services to tenant networks.
Some plug-ins use this agent.</td>
</tr>
<tr>
<td><emphasis role="bold">l3 agent</emphasis>
(<literal>neutron-l3-agent</literal>)</td>
<td>Provides L3/NAT forwarding to provide external
network access for VMs on tenant networks.
Some plug-ins use this agent.</td>
</tr>
</tbody>
</table>
</para>
<para>These agents interact with the main neutron process <para>These agents interact with the main neutron process
through RPC (for example, rabbitmq or qpid) or through through RPC (for example, rabbitmq or qpid) or through
the standard Networking API. Further:</para> the standard Networking API. Further:</para>
@ -462,43 +467,46 @@
</mediaobject> </mediaobject>
<para>A standard Networking set up has one or more of the <para>A standard Networking set up has one or more of the
following distinct physical data center following distinct physical data center
networks:</para> networks.</para>
<itemizedlist>
<listitem> <para>
<para><emphasis role="bold">Management <table rules="all">
network</emphasis>. Provides internal <caption>General distinct physical data center networks</caption>
communication between OpenStack Components. IP <col width="20%"/>
addresses on this network should be reachable <col width="80%"/>
only within the data center.  </para> <thead>
</listitem> <tr>
<listitem> <th>Network</th>
<para><emphasis role="bold">Data <th>Description</th>
network</emphasis>. Provides VM data </tr>
communication within the cloud deployment.  </thead>
The IP addressing requirements of this network <tbody>
depend on the Networking plug-in that is <tr>
used.</para> <td><emphasis role="bold">Management network</emphasis></td>
</listitem> <td>Provides internal communication between OpenStack Components. IP
<listitem> addresses on this network should be reachable only within the data center.</td>
<para><emphasis role="bold">External </tr>
network</emphasis>. Provides VMs with <tr>
Internet access in some deployment scenarios.  <td><emphasis role="bold">Data network</emphasis></td>
Anyone on the Internet can reach IP addresses <td>Provides VM data communication within the cloud deployment. The IP addressing
on this network.</para> requirements of this network depend on the Networking plug-in that is used.</td>
</listitem> </tr>
<listitem> <tr>
<para><emphasis role="bold">API <td><emphasis role="bold">External network</emphasis></td>
network</emphasis>. Exposes all OpenStack <td>Provides VMs with Internet access in some deployment scenarios.
APIs, including the Networking API, to Anyone on the Internet can reach IP addresses on this network.</td>
tenants. IP addresses on this network should </tr>
be reachable by anyone on the Internet. The <tr>
API network might be the same as the external <td><emphasis role="bold">API network</emphasis></td>
network, because it is possible to create an <td>Exposes all OpenStack APIs, including the Networking API, to
external-network subnet that is allocated IP tenants. IP addresses on this network should be reachable by anyone on the Internet. The
ranges that use less than the full range of IP API network might be the same as the external network, because it is possible to create an
addresses in an IP block.</para> external-network subnet that is allocated IP ranges that use less than the full range of IP
</listitem> addresses in an IP block.</td>
</itemizedlist> </tr>
</tbody>
</table>
</para>
</section> </section>
</section> </section>
<section xml:id="section_networking-use"> <section xml:id="section_networking-use">
@ -541,26 +549,37 @@
IPAM). There is also an extension to cover basic IPAM). There is also an extension to cover basic
L3 forwarding and NAT, which provides capabilities L3 forwarding and NAT, which provides capabilities
similar to <command>nova-network</command>.</para> similar to <command>nova-network</command>.</para>
<para>In the Networking API:</para> <para><table rules="all">
<itemizedlist> <caption>API abstractions</caption>
<listitem> <col width="10%"/>
<para>Network. An isolated L2 network segment <col width="90%"/>
<thead>
<tr>
<th>Abstraction</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><emphasis role="bold">Network</emphasis></td>
<td>An isolated L2 network segment
(similar to a VLAN) that forms the basis (similar to a VLAN) that forms the basis
for describing the L2 network topology for describing the L2 network topology
available in an Networking deployment. available in an Networking deployment.</td>
</para> </tr>
</listitem> <tr>
<listitem> <td><emphasis role="bold">Subnet</emphasis></td>
<para>Subnet. Associates a block of IP <td>Associates a block of IP
addresses and other network configuration, addresses and other network configuration,
such as, default gateways or dns-servers, such as, default gateways or dns-servers,
with an Networking network. Each subnet with an Networking network. Each subnet
represents an IPv4 or IPv6 address block represents an IPv4 or IPv6 address block
and, if needed, each Networking network and, if needed, each Networking network
can have multiple subnets.</para> can have multiple subnets.</td>
</listitem> </tr>
<listitem> <tr>
<para>Port. Represents an attachment port to a <td><emphasis role="bold">Port</emphasis></td>
<td>Represents an attachment port to a
L2 Networking network. When a port is L2 Networking network. When a port is
created on the network, by default it is created on the network, by default it is
allocated an available fixed IP address allocated an available fixed IP address
@ -571,9 +590,10 @@
subnet. Users of the Networking API can subnet. Users of the Networking API can
either choose a specific IP address from either choose a specific IP address from
the block, or let Networking choose the the block, or let Networking choose the
first available IP address.</para> first available IP address.</td>
</listitem> </tr>
</itemizedlist> </tbody>
</table></para>
<?hard-pagebreak?> <?hard-pagebreak?>
<para>The following table summarizes the attributes <para>The following table summarizes the attributes
available for each networking abstraction. For available for each networking abstraction. For

193
doc/admin-guide-cloud/section_networking_adv_features.xml
View File

@ -35,96 +35,109 @@
<para>A number of terms are used in the provider extension <para>A number of terms are used in the provider extension
and in the configuration of plug-ins supporting the and in the configuration of plug-ins supporting the
provider extension:</para> provider extension:</para>
<itemizedlist> <para>
<listitem> <table rules="all">
<para><emphasis role="bold">virtual <caption>Provider extension terminology</caption>
network</emphasis>. An Networking L2 <col width="20%"/>
network (identified by a UUID and optional <col width="80%"/>
name) whose ports can be attached as vNICs to <thead>
Compute instances and to various Networking <tr>
agents. The Open vSwitch and Linux Bridge <th>Term</th>
plug-ins each support several different <th>Description</th>
mechanisms to realize virtual networks.</para> </tr>
</listitem> </thead>
<listitem> <tbody>
<para><emphasis role="bold">physical <tr>
network</emphasis>. A network connecting <td><emphasis role="bold">virtual network</emphasis></td>
virtualization hosts (such as, Compute nodes) <td>An Networking L2
with each other and with other network network (identified by a UUID and optional
resources. Each physical network might support name) whose ports can be attached as vNICs to
multiple virtual networks. The provider Compute instances and to various Networking
extension and the plug-in configurations agents. The Open vSwitch and Linux Bridge
identify physical networks using simple string plug-ins each support several different
names.</para> mechanisms to realize virtual networks.</td>
</listitem> </tr>
<listitem> <tr>
<para><emphasis role="bold">tenant <td><emphasis role="bold">physical network</emphasis></td>
network</emphasis>. A virtual network that <td>A network connecting
a tenant or an administrator creates. The virtualization hosts (such as, Compute nodes)
physical details of the network are not with each other and with other network
exposed to the tenant.</para> resources. Each physical network might support
</listitem> multiple virtual networks. The provider
<listitem> extension and the plug-in configurations
<para><emphasis role="bold">provider identify physical networks using simple string
network</emphasis>. A virtual network names.</td>
administratively created to map to a specific </tr>
network in the data center, typically to <tr>
enable direct access to non-OpenStack <td><emphasis role="bold">tenant network</emphasis></td>
resources on that network. Tenants can be <td>A virtual network that
given access to provider networks.</para> a tenant or an administrator creates. The
</listitem> physical details of the network are not
<listitem> exposed to the tenant.</td>
<para><emphasis role="bold">VLAN </tr>
network</emphasis>. A virtual network <tr>
implemented as packets on a specific physical <td><emphasis role="bold">provider network</emphasis></td>
network containing IEEE 802.1Q headers with a <td>A virtual network
specific VID field value. VLAN networks administratively created to map to a specific
sharing the same physical network are isolated network in the data center, typically to
from each other at L2, and can even have enable direct access to non-OpenStack
overlapping IP address spaces. Each distinct resources on that network. Tenants can be
physical network supporting VLAN networks is given access to provider networks.</td>
treated as a separate VLAN trunk, with a </tr>
distinct space of VID values. Valid VID values <tr>
are 1 through 4094.</para> <td><emphasis role="bold">VLAN network</emphasis></td>
</listitem> <td>A virtual network
<listitem> implemented as packets on a specific physical
<para><emphasis role="bold">flat network containing IEEE 802.1Q headers with a
network</emphasis>. A virtual network specific VID field value. VLAN networks
implemented as packets on a specific physical sharing the same physical network are isolated
network containing no IEEE 802.1Q header. Each from each other at L2, and can even have
physical network can realize at most one flat overlapping IP address spaces. Each distinct
network.</para> physical network supporting VLAN networks is
</listitem> treated as a separate VLAN trunk, with a
<listitem> distinct space of VID values. Valid VID values
<para><emphasis role="bold">local are 1 through 4094.</td>
network</emphasis>. A virtual network that </tr>
allows communication within each host, but not <tr>
across a network. Local networks are intended <td><emphasis role="bold">flat network</emphasis></td>
mainly for single-node test scenarios, but can <td>A virtual network
have other uses.</para> implemented as packets on a specific physical
</listitem> network containing no IEEE 802.1Q header. Each
<listitem> physical network can realize at most one flat
<para><emphasis role="bold">GRE network.</td>
network</emphasis>. A virtual network </tr>
implemented as network packets encapsulated <tr>
using GRE. GRE networks are also referred to <td><emphasis role="bold">local network</emphasis></td>
as <emphasis role="italic">tunnels</emphasis>. <td>A virtual network that
GRE tunnel packets are routed by the IP allows communication within each host, but not
routing table for the host, so GRE networks across a network. Local networks are intended
are not associated by Networking with specific mainly for single-node test scenarios, but can
physical networks.</para> have other uses.</td>
</listitem> </tr>
<listitem> <tr>
<para><emphasis role="bold">Virtual Extensible LAN <td><emphasis role="bold">GRE network</emphasis></td>
(VXLAN) network</emphasis>. VXLAN is a proposed <td>A virtual network
encapsulation protocol for running an overlay implemented as network packets encapsulated
network on existing Layer 3 infrastructure. An using GRE. GRE networks are also referred to
overlay network is a virtual network that is as <emphasis role="italic">tunnels</emphasis>.
built on top of existing network Layer 2 and GRE tunnel packets are routed by the IP
Layer 3 technologies to support elastic compute routing table for the host, so GRE networks
architectures.</para> are not associated by Networking with specific
</listitem> physical networks.</td>
</itemizedlist> </tr>
<tr>
<td><emphasis role="bold">Virtual Extensible LAN (VXLAN) network</emphasis></td>
<td>VXLAN is a proposed
encapsulation protocol for running an overlay
network on existing Layer 3 infrastructure. An
overlay network is a virtual network that is
built on top of existing network Layer 2 and
Layer 3 technologies to support elastic compute
architectures.</td>
</tr>
</tbody>
</table>
</para>
<para>The ML2, Open vSwitch and Linux Bridge plug-ins support <para>The ML2, Open vSwitch and Linux Bridge plug-ins support
VLAN networks, flat networks, and local networks. Only VLAN networks, flat networks, and local networks. Only
the ML2 and Open vSwitch plug-ins currently support GRE the ML2 and Open vSwitch plug-ins currently support GRE