openstack/openstack-manuals
Code Issues Proposed changes

Include ML2 plugin documentation

Browse Source 
Add ML2 plugin references and description
Include VXLAN as provider network
Add a deprecation note for openvswitch and linuxbridge plugins

Fix bug #1230283

Change-Id: I5710f81601fdb04b752737dfa0f36fc7863cca9e
This commit is contained in:
Edgar Magana 2013-10-01 22:44:52 -07:00
parent 1b20fb9268
commit 2f5084ce70
3 changed files with 95 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -140,16 +140,20 @@
<para><emphasis role="bold">Mellanox
Plug-in</emphasis>. <link
xlink:href="https://wiki.openstack.org/wiki/Mellanox-Neutron/"
>
https://wiki.openstack.org/wiki/Mellanox-Neutron/</link>
>https://wiki.openstack.org/wiki/Mellanox-Neutron/</link>
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Midonet
Plug-in</emphasis>. <link
xlink:href="http://www.midokura.com/">
http://www.midokura.com/</link>
</para>
http://www.midokura.com/</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">ML2 (Modular Layer 2)
Plug-in</emphasis>. <link
xlink:href="https://wiki.openstack.org/wiki/Neutron/ML2">
https://wiki.openstack.org/wiki/Neutron/ML2</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">NEC OpenFlow
@ -188,12 +192,24 @@
</para>
</listitem>
</itemizedlist>
<para>Plug-ins can have different properties for hardware
requirements, features, performance, scale, or
operator tools. Because Networking supports a large
number of plug-ins, the cloud administrator is able to
weigh different options and decide which networking
technology is right for the deployment.</para>
<para>Plug-ins can have different properties for hardware requirements, features,
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
networking technology for the deployment.</para>
<para>In the Havana release, OpenStack Networking provides the <emphasis role="bold">Modular
Layer 2 (ML2)</emphasis> plug-in that can concurrently use multiple layer 2
networking technologies that are found in real-world data centers. It currently
works with the existing Open vSwitch, Linux Bridge, and Hyper-v L2 agents. The ML2
framework simplifies the addition of support for new L2 technologies and reduces the
effort that is required to add and maintain them compared to monolithic
plug-ins.</para>
<note>
<title>Plugins Deprecation Notice:</title>
<para>The Open vSwitch and Linux Bridge plug-ins are deprecated in the Havana
release and will be removed in the Icehouse release. All features have been
ported to the ML2 plug-in in the form of mechanism drivers. ML2 currently
provides Linux Bridge, Open vSwitch and Hyper-v mechanism drivers.</para>
</note>
<para>Not all Networking plug-ins are compatible with all
possible Compute drivers:</para>
<table rules="all">
@ -275,6 +291,15 @@
<td/>
<td/>
</tr>
<tr>
<td>ML2</td>
<td>Yes</td>
<td/>
<td/>
<td>Yes</td>
<td/>
<td/>
</tr>
<tr>
<td>NEC OpenFlow</td>
<td>Yes</td>
@ -364,15 +389,15 @@
<listitem>
<para><emphasis role="bold">dhcp agent</emphasis>
(<literal>neutron-dhcp-agent</literal>).
Provides DHCP services to tenant networks. All
plug-ins use this agent. </para>
Provides DHCP services to tenant networks.
Some plug-ins use this agent. </para>
</listitem>
<listitem>
<para><emphasis role="bold">l3 agent</emphasis>
<literal>(neutron-l3-agent</literal>).
Provides L3/NAT forwarding to provide external
network access for VMs on tenant networks. All
plug-ins use this agent. </para>
network access for VMs on tenant networks.
Some plug-ins use this agent. </para>
</listitem>
</itemizedlist>
<para>These agents interact with the main neutron process
@ -1387,6 +1412,11 @@
</tr>
</thead>
<tbody>
<tr>
<td>ML2</td>
<td>True</td>
<td>True</td>
</tr>
<tr>
<td>Open vSwitch</td>
<td>True</td>

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

@ -27,8 +27,8 @@
additional provider attributes on all virtual networks,
and are able to specify these attributes in order to
create provider networks.</para>
<para>The provider extension is supported by the openvswitch
and linuxbridge plug-ins. Configuration of these plug-ins
<para>The provider extension is supported by the Open vSwitch
and Linux Bridge plug-ins. Configuration of these plug-ins
requires familiarity with this extension.</para>
<section xml:id="provider_terminology">
<title>Terminology</title>
@ -42,7 +42,7 @@
network (identified by a UUID and optional
name) whose ports can be attached as vNICs to
Compute instances and to various Networking
agents. The openvswitch and linuxbridge
agents. The Open vSwitch and Linux Bridge
plug-ins each support several different
mechanisms to realize virtual networks.</para>
</listitem>
@ -114,13 +114,23 @@
are not associated by Networking with specific
physical networks.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Virtual Extensible LAN
(VXLAN) network</emphasis>. 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.</para>
</listitem>
</itemizedlist>
<para>Both the openvswitch and linuxbridge plug-ins
support VLAN networks, flat networks, and local
networks. Only the openvswitch plug-in currently
supports GRE networks, provided that the host's Linux
kernel supports the required Open vSwitch
features.</para>
<para>The ML2, Open vSwitch and Linux Bridge plug-ins support
VLAN networks, flat networks, and local networks. Only
the ML2 and Open vSwitch plug-ins currently support GRE
and VXLAN networks, provided that the required features
exist in the hosts Linux kernel, Open vSwitch and iproute2
packages.</para>
</section>
<section xml:id="provider_attributes">
<title>Provider attributes</title>
@ -688,11 +698,9 @@
<note>
<itemizedlist>
<listitem>
<para>To use the Compute security group API with
Networking, the Networking plug-in must
implement the security group API. The
following plug-ins currently implement this:
Nicira NVP, Open vSwitch, Linux Bridge, NEC,
<para>To use the Compute security group API with Networking, the Networking
plug-in must implement the security group API. The following plug-ins
currently implement this: ML2, Nicira NVP, Open vSwitch, Linux Bridge, NEC,
and Ryu.</para>
</listitem>
<listitem>
@ -1402,8 +1410,8 @@
two instances to enable fast data plane failover.</para>
<note>
<para>The allowed-address-pairs extension is currently
only supported by the following plug-ins: Nicira NVP,
OpenvSwitch, and ML2.</para>
only supported by the following plug-ins: ML2, Nicira
NVP, and OpenvSwitch.</para>
</note>
<section xml:id="section_allowed_address_pairs_workflow">
<title>Basic allowed address pairs operations</title>

21
doc/common/ch_getstart.xml
View File

@ -573,19 +573,22 @@
for action.</para>
</listitem>
<listitem>
<para>OpenStack Networking plug-ins and agents. Plugs and
unplugs ports, creates networks or subnets, and provides
IP addressing. These plug-ins and agents differ depending
on the vendor and technologies used in the particular
cloud. OpenStack Networking ships with plug-ins and agents
for Cisco virtual and physical switches, Nicira NVP
product, NEC OpenFlow products, Open vSwitch, Linux
bridging, and the Ryu Network Operating System.</para>
<para><systemitem class="service"
>OpenStack Networking Plug-ins and Agents</systemitem>.
Plug and unplug ports, create networks or subnets, and
provide IP addressing. These plug-ins and agents differ
depending on the vendor and technologies used in the Cloud
System. OpenStack Networking ships with plug-ins and agents
for Arista, Brocade, Cisco NXOS as well as Nexus 1000V and
Mellanox switches, Linux bridging, Nicira NVP product, NEC
OpenFlow, Open vSwitch, PLUMgrid Platform, and the Ryu
Network Operating System.</para>
<para>The common agents are L3 (layer 3), DHCP (dynamic host
IP addressing), and a plug-in agent.</para>
</listitem>
<listitem>
<para>Messaging queue. Most OpenStack Networking
<para><systemitem class="service"
>Messaging Queue</systemitem>. Most OpenStack Networking
installations make use of a messaging queue to route
information between the neutron-server and various agents
as well as a database to store networking state for