openstack/openstack-manuals
Code Issues Proposed changes

[cloud-admin-guide] Purging defunct networking content

Browse Source 
Removing oudating networking content in XML files before
RST conversion.

Change-Id: I5c05681917032014bdbb8567e60de52548a0b09f
Closes-bug: #1463520
This commit is contained in:
Alexandra Settle 2015-06-30 10:20:57 +10:00
parent 9d6cb34b5e
commit 25b3b8e1be
4 changed files with 0 additions and 1661 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -13,7 +13,6 @@
<xi:include href="networking/section_networking_config-agents.xml"/>
<xi:include href="networking/section_networking_arch.xml"/>
<xi:include href="networking/section_networking-config-identity.xml"/>
<xi:include href="networking/section_networking-scenarios.xml"/>
<xi:include href="networking/section_networking-adv-config.xml"/>
<xi:include href="networking/section_networking-multi-dhcp-agents.xml"/>
<xi:include href="networking/section_networking-use.xml"/>

117
doc/admin-guide-cloud/networking/section_networking-adv-config.xml
View File

@ -7,123 +7,6 @@
example, configuration options where the default works but that the user wants to customize
options. After installing from packages, <literal>$NEUTRON_CONF_DIR</literal> is
<filename>/etc/neutron</filename>.</para>
<section xml:id="section_adv_cfg_l3_agent">
<title>L3 agent</title>
<para>You can run an L3 agent that enables layer-3 forwarding and floating IP support.</para>
<para>The node that runs the L3 agent should run:</para>
<screen><userinput>neutron-l3-agent --config-file <replaceable>NEUTRON_CONFIG_FILE</replaceable> --config-file <replaceable>L3_CONFIG_FILE</replaceable></userinput></screen>
<para>You must configure a driver that matches the plug-in that runs on the service. This
driver creates the routing interface.</para>
<table rules="all">
<caption>Settings</caption>
<thead>
<tr>
<th>Option</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td><emphasis role="bold">Open vSwitch</emphasis></td>
<td/>
</tr>
<tr>
<td>interface_driver ($NEUTRON_CONF_DIR/l3_agent.ini)</td>
<td>neutron.agent.linux.interface.OVSInterfaceDriver</td>
</tr>
<tr>
<td>external_network_bridge ($NEUTRON_CONF_DIR/l3_agent.ini)</td>
<td>br-ex</td>
</tr>
<tr>
<td><emphasis role="bold">Linux Bridge</emphasis></td>
<td/>
</tr>
<tr>
<td>interface_driver ($NEUTRON_CONF_DIR/l3_agent.ini)</td>
<td>neutron.agent.linux.interface.BridgeInterfaceDriver</td>
</tr>
<tr>
<td>external_network_bridge ($NEUTRON_CONF_DIR/l3_agent.ini)</td>
<td>This field must be empty (or the bridge name for the external network).</td>
</tr>
</tbody>
</table>
<section xml:id="adv_cfg_l3_agent_namespace">
<title>Namespace</title>
<para>By default, the L3 agent uses Linux network namespaces to support overlapping IP
addresses.</para>
<para>If the Linux installation does not support network namespaces, you must disable
network namespaces in the L3 agent configuration file. The default value of
<option>use_namespaces</option> is <literal>True</literal>.</para>
<programlisting language="ini">use_namespaces = False</programlisting>
<para>When you set <option>use_namespaces</option> to <literal>False</literal>, only one
router ID is supported per node.</para>
<para>Use the <option>router_id</option> configuration option to configure the
router:</para>
<programlisting language="ini"># If use_namespaces is set to False then the agent can only configure one router.
# This is done by setting the specific router_id.
router_id = 1064ad16-36b7-4c2f-86f0-daa2bcbd6b2a</programlisting>
<para>To configure it, you must run the OpenStack Networking service, create a router,
and set the router ID value to the <option>router_id</option> value in the L3 agent
configuration file.</para>
<screen><prompt>$</prompt> <userinput>neutron router-create myrouter1</userinput>
<computeroutput>Created a new router:
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| admin_state_up | True |
| external_gateway_info | |
| id | 338d42d7-b22e-42c5-9df6-f3674768fe75 |
| name | myrouter1 |
| status | ACTIVE |
| tenant_id | 0c236f65baa04e6f9b4236b996555d56 |
+-----------------------+--------------------------------------+</computeroutput></screen>
</section>
<section xml:id="adv_cfg_l3_agent_multi_extnet">
<title>Multiple external networks</title>
<para>Use one of these methods to support multiple external networks:</para>
<itemizedlist>
<listitem>
<para>Assign multiple subnets to an external network.</para>
</listitem>
<listitem>
<para>Use multiple floating IP pools.</para>
</listitem>
</itemizedlist>
<para>The following sections describe these options.</para>
<section xml:id="adv_cfg_l3_agent_multi_subnet">
<title>Assign multiple subnets to an external network</title>
<para>This approach leverages the addition of on-link routes, which enables a router
to host floating IPs from any subnet on an external network regardless of which
subnet the primary router IP address comes from. This method does not require
the creation of multiple external networks.</para>
<para>To add a subnet to the external network, use the following command
template:</para>
<screen><prompt>$</prompt> <userinput>neutron subnet-create <replaceable>EXT_NETWORK_NAME</replaceable> <replaceable>CIDR</replaceable></userinput></screen>
<para>For example:</para>
<screen><prompt>$</prompt> <userinput>neutron subnet-create my-ext_network 10.0.0.0/29</userinput> </screen>
</section>
<section xml:id="adv_cfg_l3_agent_multi_floatip">
<title>Multiple floating IP pools</title>
<para>The L3 API in OpenStack Networking supports multiple
floating IP pools. In OpenStack Networking, a floating
IP pool is represented as an external network, and a
floating IP is allocated from a subnet associated with
the external network. You can associate a L3 agent
with multiple external networks.</para>
<para>Before starting a L3 agent, you must update the
configuration files with the UUID of the external network.</para>
<para>To enable the L3 agent to support multiple external
networks, edit the <filename>l3_agent.ini</filename> file
and leave the <option>gateway_external_network_id</option>
and <option>external_network_bridge</option> options unset:</para>
<programlisting language="ini">handle_internal_only_routers = True
gateway_external_network_id =
external_network_bridge = </programlisting>
</section>
</section>
</section>
<section xml:id="section_adv_cfg_l3_metering_agent">
<title>L3 metering agent</title>
<para>You can run an L3 metering agent that enables layer-3 traffic metering. In general,

791
doc/admin-guide-cloud/networking/section_networking-scenarios.xml
View File

@ -1,791 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="section_networking-scenarios">
<title>Networking scenarios</title>
<para>This chapter describes two networking scenarios and how the Open vSwitch plug-in and the
Linux Bridge plug-in implement these scenarios.</para>
<section xml:id="under_the_hood_openvswitch">
<?dbhtml stop-chunking?>
<title>Open vSwitch</title>
<para>This section describes how the Open vSwitch plug-in implements the Networking
abstractions.</para>
<section xml:id="under_the_hood_openvswitch_configuration">
<title>Configuration</title>
<para>This example uses VLAN segmentation on the switches to isolate tenant networks.
This configuration labels the physical network associated with the public network as
<literal>physnet1</literal>, and the physical network associated with the data
network as <literal>physnet2</literal>, which leads to the following configuration
options in <filename>ovs_neutron_plugin.ini</filename>:</para>
<programlisting language="ini">[ovs]
tenant_network_type = vlan
network_vlan_ranges = physnet1,physnet2:100:110
integration_bridge = br-int
bridge_mappings = physnet2:br-eth1</programlisting>
</section>
<section xml:id="under_the_hood_openvswitch_scenario1">
<title>Scenario 1: one tenant, two networks, one router</title>
<para>The first scenario has two private networks (<literal>net01</literal>, and
<literal>net02</literal>), each with one subnet
(<literal>net01_subnet01</literal>: 192.168.101.0/24,
<literal>net02_subnet01</literal>, 192.168.102.0/24). Both private networks are
attached to a router that connects them to the public network
(10.64.201.0/24).</para>
<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>Under the <literal>service</literal> tenant, create the shared router, define the
public network, and set it as the default gateway of the
router<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/service/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron router-create router01</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant public01 \
--provider:network_type flat \
--provider:physical_network physnet1 \
--router:external True</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
--gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp</userinput>
<prompt>$</prompt> <userinput>neutron router-gateway-set router01 public01</userinput></screen></para>
<para>Under the <literal>demo</literal> user tenant, create the private network
<literal>net01</literal> and corresponding subnet, and connect it to the
<literal>router01</literal> router. Configure it to use VLAN ID 101 on the
physical
switch.<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list|awk '/demo/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net01 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 101</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router01 net01_subnet01</userinput></screen></para>
<para>Similarly, for <literal>net02</literal>, using VLAN ID 102 on the physical
switch:<screen><prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net02 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 102</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router01 net02_subnet01</userinput></screen></para>
<section xml:id="under_the_hood_openvswitch_scenario1_compute">
<title>Scenario 1: Compute host config</title>
<para>The following figure shows how to configure various Linux networking devices
on the compute host:</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-1-ovs-compute.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<simplesect>
<title>Types of network devices</title>
<note>
<para>There are four distinct type of virtual networking devices: TAP
devices, veth pairs, Linux bridges, and Open vSwitch bridges. For an
Ethernet frame to travel from <literal>eth0</literal> of virtual machine
<literal>vm01</literal> to the physical network, it must pass
through nine devices inside of the host: TAP <literal>vnet0</literal>,
Linux bridge <literal>qbr<replaceable>NNN</replaceable></literal>, veth
pair <literal>(qvb<replaceable>NNN</replaceable>,
qvo<replaceable>NNN</replaceable>)</literal>, Open vSwitch
bridge <literal>br-int</literal>, veth pair <literal>(int-br-eth1,
phy-br-eth1)</literal>, and, finally, the physical network interface
card <literal>eth1</literal>.</para>
</note>
<para>A <emphasis role="italic">TAP device</emphasis>, such as
<literal>vnet0</literal> is how hypervisors such as KVM and Xen
implement a virtual network interface card (typically called a VIF or vNIC).
An Ethernet frame sent to a TAP device is received by the guest operating
system.</para>
<para>A <emphasis role="italic">veth pair</emphasis> is a pair of directly
connected virtual network interfaces. An Ethernet frame sent to one end of a
veth pair is received by the other end of a veth pair. Networking uses veth
pairs as virtual patch cables to make connections between virtual
bridges.</para>
<para>A <emphasis role="italic">Linux bridge</emphasis> behaves like a simple
MAC learning switch: you can connect multiple (physical or virtual) network
interfaces devices to a Linux bridge. The Linux bridge uses a MAC caching
table to record which interface on the bridge is used to communicate with a
host on the link. For any Ethernet frames that come in from one interface
attached to the bridge, the host MAC address and port on which the frame was
received is recorded in the MAC caching table for a limited time. When the
bridge needs to forward a frame, it will check to see if the frame's
destination MAC address is recorded in the table. If so, the Linux bridge
forwards the frame through only that port. If not, the frame is flooded to
all network ports in the bridge, with the exception of the port where the
frame was received.</para>
<para>An <emphasis role="italic">Open vSwitch bridge</emphasis> behaves like a
virtual switch: network interface devices connect to Open vSwitch bridge's
ports, and the ports can be configured much like a physical switch's ports,
including VLAN configurations.</para>
</simplesect>
<simplesect>
<title>Integration bridge</title>
<para>The <literal>br-int</literal> Open vSwitch bridge is the integration
bridge: all guests running on the compute host connect to this bridge.
Networking implements isolation across these guests by configuring the
<literal>br-int</literal> ports.</para>
</simplesect>
<simplesect>
<title>Physical connectivity bridge</title>
<para>The <literal>br-eth1</literal> bridge provides connectivity to the
physical network interface card, <literal>eth1</literal>. It connects to the
integration bridge by a veth pair: <literal>(int-br-eth1,
phy-br-eth1)</literal>.</para>
</simplesect>
<simplesect>
<title>VLAN translation</title>
<para>In this example, net01 and net02 have VLAN ids of 1 and 2, respectively.
However, the physical network in our example only supports VLAN IDs in the
range 101 through 110. The Open vSwitch agent is responsible for configuring
flow rules on <literal>br-int</literal> and <literal>br-eth1</literal> to do
VLAN translation. When <literal>br-eth1</literal> receives a frame marked
with VLAN ID 1 on the port associated with <literal>phy-br-eth1</literal>,
it modifies the VLAN ID in the frame to 101. Similarly, when
<literal>br-int</literal> receives a frame marked with VLAN ID 101 on
the port associated with <literal>int-br-eth1</literal>, it modifies the
VLAN ID in the frame to 1.</para>
</simplesect>
<simplesect>
<title>Security groups: iptables and Linux bridges</title>
<para>Ideally, the TAP device <literal>vnet0</literal> would be connected
directly to the integration bridge, <literal>br-int</literal>.
Unfortunately, this isn't possible because of how OpenStack security groups
are currently implemented. OpenStack uses iptables rules on the TAP devices
such as <literal>vnet0</literal> to 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.</para>
<para>Networking uses an extra Linux bridge and a veth pair as a workaround for
this issue. Instead of connecting <literal>vnet0</literal> to an Open
vSwitch bridge, it is connected to a Linux bridge,
<literal>qbr<replaceable>XXX</replaceable></literal>. This bridge is
connected to the integration bridge, <literal>br-int</literal>, through the
<literal>(qvb<replaceable>XXX</replaceable>,
qvo<replaceable>XXX</replaceable>)</literal> veth pair.</para>
</simplesect>
</section>
<section xml:id="under_the_hood_openvswitch_scenario1_network">
<title>Scenario 1: Network host config</title>
<para>The network host runs the neutron-openvswitch-plugin-agent, the
neutron-dhcp-agent, neutron-l3-agent, and neutron-metadata-agent
services.</para>
<para>On the network host, assume that eth0 is connected to the external network,
and eth1 is connected to the data network, which leads to the following
configuration in the <filename>ovs_neutron_plugin.ini</filename> file:</para>
<programlisting language="bash">[ovs]
tenant_network_type = vlan
network_vlan_ranges = physnet1,physnet2:101:110
integration_bridge = br-int
bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
<para>The following figure shows the network devices on the network host:</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-1-ovs-network.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>As on the compute host, there is an Open vSwitch integration bridge
(<literal>br-int</literal>) and an Open vSwitch bridge connected to the data
network (<literal>br-eth1</literal>), and the two are connected by a veth pair,
and the neutron-openvswitch-plugin-agent configures the ports on both switches
to do VLAN translation.</para>
<para>An additional Open vSwitch bridge, <literal>br-ex</literal>, connects to the
physical interface that is connected to the external network. In this example,
that physical interface is <literal>eth0</literal>.</para>
<note>
<para>While the integration bridge and the external bridge are connected by a
veth pair <literal>(int-br-ex, phy-br-ex)</literal>, this example uses layer
3 connectivity to route packets from the internal networks to the public
network: no packets traverse that veth pair in this example.</para>
</note>
<simplesect>
<title>Open vSwitch internal ports</title>
<para>The network host uses Open vSwitch <emphasis role="italic">internal
ports</emphasis>. Internal ports enable you to assign one or more IP
addresses to an Open vSwitch bridge. In previous example, the
<literal>br-int</literal> bridge has four internal ports:
<literal>tap<replaceable>XXX</replaceable></literal>,
<literal>qr-<replaceable>YYY</replaceable></literal>,
<literal>qr-<replaceable>ZZZ</replaceable></literal>, and
<literal>tap<replaceable>WWW</replaceable></literal>. Each internal
port has a separate IP address associated with it. An internal port,
<literal>qg-<replaceable>VVV</replaceable></literal>, is on the
<literal>br-ex</literal> bridge.</para>
</simplesect>
<simplesect>
<title>DHCP agent</title>
<para>By default, the Networking DHCP agent uses a process called dnsmasq to
provide DHCP services to guests. Networking must create an internal port for
each network that requires DHCP services and attach a dnsmasq process to
that port. In the previous example, the
<literal>tap<replaceable>XXX</replaceable></literal> interface is on
<literal>net01_subnet01</literal>, and the
<literal>tap<replaceable>WWW</replaceable></literal> interface is on
<literal>net02_subnet01</literal>.</para>
</simplesect>
<simplesect>
<title>L3 agent (routing)</title>
<para>The Networking L3 agent uses Open vSwitch internal ports to implement
routing and relies on the network host to route the packets across the
interfaces. In this example, the
<literal>qr-<replaceable>YYY</replaceable></literal> interface is on
<literal>net01_subnet01</literal> and has the IP address
192.168.101.1/24. The <literal>qr-<replaceable>ZZZ</replaceable></literal>,
interface is on <literal>net02_subnet01</literal> and has the IP address
<literal>192.168.102.1/24</literal>. The
<literal>qg-<replaceable>VVV</replaceable></literal> interface has
the IP address <literal>10.64.201.254/24</literal>. Because each of these
interfaces is visible to the network host operating system, the network host
routes the packets across the interfaces, as long as an administrator has
enabled IP forwarding.</para>
<para>The L3 agent uses iptables to implement floating IPs to do the network
address translation (NAT).</para>
</simplesect>
<simplesect>
<title>Overlapping subnets and network namespaces</title>
<para>One problem with using the host to implement routing is that one of the
Networking subnets might overlap with one of the physical networks that the
host uses. For example, if the management network is implemented on
<literal>eth2</literal> and also happens to be on the
<literal>192.168.101.0/24</literal> subnet, routing problems will occur
because the host can't determine whether to send a packet on this subnet to
<literal>qr-<replaceable>YYY</replaceable></literal> or
<literal>eth2</literal>. If end users are permitted to create their own
logical networks and subnets, you must design the system so that such
collisions do not occur.</para>
<para>Networking uses Linux <emphasis role="italic">network namespaces
</emphasis>to prevent collisions between the physical networks on the
network host, and the logical networks used by the virtual machines. It also
prevents collisions across different logical networks that are not routed to
each other, as the following scenario shows.</para>
<para>A network namespace is an isolated environment with its own networking
stack. A network namespace has its own network interfaces, routes, and
iptables rules. Consider it a chroot jail, except for networking instead of
for a file system. LXC (Linux containers) use network namespaces to
implement networking virtualization.</para>
<para>Networking creates network namespaces on the network host to avoid subnet
collisions.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-1-ovs-netns.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>In this example, there are three network namespaces, as shown in the
figure above:<itemizedlist>
<listitem>
<para><literal>qdhcp-<replaceable>AAA</replaceable></literal>:
contains the
<literal>tap<replaceable>XXX</replaceable></literal>
interface and the dnsmasq process that listens on that interface
to provide DHCP services for <literal>net01_subnet01</literal>.
This allows overlapping IPs between
<literal>net01_subnet01</literal> and any other subnets on
the network host.</para>
</listitem>
<listitem>
<para><literal>qrouter-<replaceable>BBBB</replaceable></literal>:
contains the
<literal>qr-<replaceable>YYY</replaceable></literal>,
<literal>qr-<replaceable>ZZZ</replaceable></literal>,
and <literal>qg-<replaceable>VVV</replaceable></literal>
interfaces, and the corresponding routes. This namespace
implements <literal>router01</literal> in our example.</para>
</listitem>
<listitem>
<para><literal>qdhcp-<replaceable>CCC</replaceable></literal>:
contains the
<literal>tap<replaceable>WWW</replaceable></literal>
interface and the dnsmasq process that listens on that
interface, to provide DHCP services for
<literal>net02_subnet01</literal>. This allows overlapping
IPs between <literal>net02_subnet01</literal> and any other
subnets on the network host.</para>
</listitem>
</itemizedlist></para>
</simplesect>
</section>
</section>
<section xml:id="under_the_hood_openvswitch_scenario2">
<title>Scenario 2: two tenants, two networks, two routers</title>
<para>In this scenario, tenant A and tenant B each have a network with one subnet and
one router that connects the tenants to the public Internet.</para>
<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>Under the <literal>service</literal> tenant, define the public
network:<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/service/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant public01 \
--provider:network_type flat \
--provider:physical_network physnet1 \
--router:external True</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
--gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp</userinput></screen></para>
<para>Under the <literal>tenantA</literal> user tenant, create the tenant router and set
its gateway for the public
network.<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list|awk '/tenantA/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron router-create --tenant-id $tenant router01</userinput>
<prompt>$</prompt> <userinput>neutron router-gateway-set router01 public01</userinput></screen>
Then, define private network <literal>net01</literal> using VLAN ID 101 on the
physical switch, along with its subnet, and connect it to the router.
<screen><prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net01 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 101</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router01 net01_subnet01</userinput></screen></para>
<para>Similarly, for <literal>tenantB</literal>, create a router and another network,
using VLAN ID 102 on the physical
switch:<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list|awk '/tenantB/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron router-create --tenant-id $tenant router02</userinput>
<prompt>$</prompt> <userinput>neutron router-gateway-set router02 public01</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net02 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 102</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router02 net02_subnet01</userinput></screen></para>
<section xml:id="under_the_hood_openvswitch_scenario2_compute">
<title>Scenario 2: Compute host config</title>
<para>The following figure shows how to configure Linux networking devices on the
compute host:</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-2-ovs-compute.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<note>
<para>The compute host configuration resembles the configuration in scenario 1.
However, in scenario 1, a guest connects to two subnets while in this
scenario, the subnets belong to different tenants.</para>
</note>
</section>
<section xml:id="under_the_hood_openvswitch_scenario2_network">
<title>Scenario 2: Network host config</title>
<para>The following figure shows the network devices on the network host for the
second scenario.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-2-ovs-network.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>In this configuration, the network namespaces are organized to isolate the two
subnets from each other as shown in the following figure.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-2-ovs-netns.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>In this scenario, there are four network namespaces
(<literal>qdhcp-<replaceable>AAA</replaceable></literal>,
<literal>qrouter-<replaceable>BBBB</replaceable></literal>,
<literal>qrouter-<replaceable>CCCC</replaceable></literal>, and
<literal>qdhcp-<replaceable>DDDD</replaceable></literal>), instead of
three. Because there is no connectivity between the two networks, each router is
implemented by a separate namespace.</para>
</section>
</section>
<section xml:id="under_the_hood_openvswitch_tunneling">
<title>Configure Open vSwitch tunneling</title>
<para>Tunneling encapsulates network traffic between physical Networking hosts and
allows VLANs to span multiple physical hosts. Instances communicate as if they share
the same layer 2 network. Open vSwitch supports tunneling with the VXLAN and GRE
encapsulation protocols.</para>
<figure>
<title>Example VXLAN tunnel</title>
<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/OVStunneling.png"
contentwidth="6in"/>
</imageobject>
<textobject>
<phrase>Example VXLAN tunnel</phrase>
</textobject>
</mediaobject>
</figure>
<para>This diagram shows two instances running on separate hosts connected by a VXLAN
tunnel. The required physical and virtual components are also illustrated. The
following procedure creates a VXLAN or GRE tunnel between two Open vSwitches running
on separate Networking hosts:</para>
<procedure>
<title>Example tunnel configuration</title>
<step>
<para>Create a virtual bridge named OVS-BR0 on each participating host:</para>
<programlisting>ovs-vsctl add-br OVS-BR0</programlisting>
</step>
<step>
<para>Create a tunnel to link the OVS-BR0 virtual bridges. Run the ovs-vsctl
command on HOST1 to create the tunnel and link it to the bridge on
HOST2:</para>
<para><emphasis role="bold"> GRE tunnel command: </emphasis></para>
<programlisting>ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.11</programlisting>
<para><emphasis role="bold">VXLAN tunnel command: </emphasis></para>
<programlisting>ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.11</programlisting>
</step>
<step>
<para>Run the ovs-vsctl command on HOST2 to create the tunnel and link it to the
bridge on HOST1.</para>
<para><emphasis role="bold"> GRE tunnel command: </emphasis></para>
<programlisting>
ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.10
</programlisting>
<para><emphasis role="bold"> VXLAN tunnel command: </emphasis></para>
<programlisting>
ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.10
</programlisting>
</step>
</procedure>
<para>Successful completion of these steps results in the two instances sharing a layer
2 network.</para>
</section>
</section>
<section xml:id="under_the_hood_linuxbridge">
<title>Linux Bridge</title>
<para>This section describes how the Linux Bridge plug-in implements the Networking
abstractions. For information about DHCP and L3 agents, see <xref
linkend="under_the_hood_openvswitch_scenario1"/>.</para>
<section xml:id="under_the_hood_linuxbridge_configuration">
<title>Configuration</title>
<para>This example uses VLAN isolation on the switches to isolate tenant networks. This
configuration labels the physical network associated with the public network as
<literal>physnet1</literal>, and the physical network associated with the data
network as <literal>physnet2</literal>, which leads to the following configuration
options in <filename>linuxbridge_conf.ini</filename>:</para>
<programlisting language="ini">[vlans]
tenant_network_type = vlan
network_vlan_ranges = physnet1,physnet2:100:110
[linux_bridge]
physical_interface_mappings = physnet2:eth1</programlisting>
<note>
<para>In this configuration there isn't a bridge mapping for <literal>physnet1</literal> as it is only needed on
the network host, which maps it to the Open vSwitch bridge <literal>br-ex</literal> connected to
the external network as seen below.</para>
</note>
</section>
<section xml:id="under_the_hood_linuxbridge_scenario1">
<title>Scenario 1: one tenant, two networks, one router</title>
<para>The first scenario has two private networks (<literal>net01</literal>, and
<literal>net02</literal>), each with one subnet
(<literal>net01_subnet01</literal>: 192.168.101.0/24,
<literal>net02_subnet01</literal>, 192.168.102.0/24). Both private networks are
attached to a router that connects them to the public network
(10.64.201.0/24).</para>
<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>Under the <literal>service</literal> tenant, create the shared router, define the
public network, and set it as the default gateway of the
router<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/service/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron router-create router01</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant public01 \
--provider:network_type flat \
--provider:physical_network physnet1 \
--router:external True</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
--gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp</userinput>
<prompt>$</prompt> <userinput>neutron router-gateway-set router01 public01</userinput></screen></para>
<para>Under the <literal>demo</literal> user tenant, create the private network
<literal>net01</literal> and corresponding subnet, and connect it to the
<literal>router01</literal> router. Configure it to use VLAN ID 101 on the
physical
switch.<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list|awk '/demo/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net01 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 101</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router01 net01_subnet01</userinput></screen></para>
<para>Similarly, for <literal>net02</literal>, using VLAN ID 102 on the physical
switch:<screen><prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net02 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 102</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router01 net02_subnet01</userinput></screen></para>
<section xml:id="under_the_hood_linuxbridge_scenario1_compute">
<title>Scenario 1: Compute host config</title>
<para>The following figure shows how to configure the various Linux networking
devices on the compute host.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-1-linuxbridge-compute.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<simplesect>
<title>Types of network devices</title>
<note>
<para>There are three distinct type of virtual networking devices: TAP
devices, VLAN devices, and Linux bridges. For an Ethernet frame to
travel from <literal>eth0</literal> of virtual machine
<literal>vm01</literal>, to the physical network, it must pass
through four devices inside of the host: TAP <literal>vnet0</literal>,
Linux bridge <literal>brq<replaceable>XXX</replaceable></literal>, VLAN
<literal>eth1.101)</literal>, and, finally, the physical network
interface card <literal>eth1</literal>.</para>
</note>
<para>A <emphasis role="italic">TAP device</emphasis>, such as
<literal>vnet0</literal> is how hypervisors such as KVM and Xen
implement a virtual network interface card (typically called a VIF or vNIC).
An Ethernet frame sent to a TAP device is received by the guest operating
system.</para>
<para>A <emphasis role="italic">VLAN device</emphasis> is associated with a VLAN
tag attaches to an existing interface device and adds or removes VLAN tags.
In the preceding example, VLAN device <literal>eth1.101</literal> is
associated with VLAN ID 101 and is attached to interface
<literal>eth1</literal>. Packets received from the outside by
<literal>eth1</literal> with VLAN tag 101 will be passed to device
<literal>eth1.101</literal>, which will then strip the tag. In the other
direction, any Ethernet frame sent directly to eth1.101 will have VLAN tag
101 added and will be forward to <literal>eth1</literal> for sending out to
the network.</para>
<para>A <emphasis role="italic">Linux bridge</emphasis> behaves like a hub: you
can connect multiple (physical or virtual) network interfaces devices to a
Linux bridge. Any Ethernet frames that come in from one interface attached
to the bridge is transmitted to all of the other devices.</para>
</simplesect>
</section>
<section xml:id="under_the_hood_linuxbridge_scenario1_network">
<title>Scenario 1: Network host config</title>
<para>The following figure shows the network devices on the network host.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-1-linuxbridge-network.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>The following figure shows how the Linux Bridge plug-in uses network
namespaces to provide isolation.</para>
<note>
<para>veth pairs form connections between the Linux bridges and the network
namespaces.</para>
</note>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-1-linuxbridge-netns.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
</section>
</section>
<section xml:id="under_the_hood_linuxbridge_scenario2">
<title>Scenario 2: two tenants, two networks, two routers</title>
<para>The second scenario has two tenants (A, B). Each tenant has a network with one
subnet, and each one has a router that connects them to the public Internet.</para>
<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>Under the <literal>service</literal> tenant, define the public
network:<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/service/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant public01 \
--provider:network_type flat \
--provider:physical_network physnet1 \
--router:external True</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
--gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp</userinput></screen></para>
<para>Under the <literal>tenantA</literal> user tenant, create the tenant router and set
its gateway for the public
network.<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list|awk '/tenantA/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron router-create --tenant-id $tenant router01</userinput>
<prompt>$</prompt> <userinput>neutron router-gateway-set router01 public01</userinput></screen>
Then, define private network <literal>net01</literal> using VLAN ID 102 on the
physical switch, along with its subnet, and connect it to the router.
<screen><prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net01 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 101</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router01 net01_subnet01</userinput></screen></para>
<para>Similarly, for <literal>tenantB</literal>, create a router and another network,
using VLAN ID 102 on the physical
switch:<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list|awk '/tenantB/ {print $2}')</userinput>
<prompt>$</prompt> <userinput>neutron router-create --tenant-id $tenant router02</userinput>
<prompt>$</prompt> <userinput>neutron router-gateway-set router02 public01</userinput>
<prompt>$</prompt> <userinput>neutron net-create --tenant-id $tenant net02 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 102</userinput>
<prompt>$</prompt> <userinput>neutron subnet-create --tenant-id $tenant --name net02_subnet01 net01 192.168.101.0/24</userinput>
<prompt>$</prompt> <userinput>neutron router-interface-add router02 net02_subnet01</userinput></screen></para>
<section xml:id="under_the_hood_linuxbridge_scenario2_compute">
<title>Scenario 2: Compute host config</title>
<para>The following figure shows how the various Linux networking devices would be
configured on the compute host under this scenario.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-2-linuxbridge-compute.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<note>
<para>The configuration on the compute host is very similar to the configuration
in scenario 1. The only real difference is that scenario 1 had a guest
connected to two subnets, and in this scenario the subnets belong to
different tenants.</para>
</note>
</section>
<section xml:id="under_the_hood_linuxbridge_scenario2_network">
<title>Scenario 2: Network host config</title>
<para>The following figure shows the network devices on the network host for the
second scenario.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-2-linuxbridge-network.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>The main difference between the configuration in this scenario and the
previous one is the organization of the network namespaces, in order to provide
isolation across the two subnets, as shown in the following figure.</para>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/under-the-hood-scenario-2-linuxbridge-netns.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>In this scenario, there are four network namespaces
(<literal>qdhcp-<replaceable>AAA</replaceable></literal>,
<literal>qrouter-<replaceable>BBBB</replaceable></literal>,
<literal>qrouter-<replaceable>CCCC</replaceable></literal>, and
<literal>qdhcp-<replaceable>DDDD</replaceable></literal>), instead of
three. Each router is implemented by a separate namespace, since there is no
connectivity between the two networks.</para>
</section>
</section>
</section>
<section xml:id="ml2_scenarios">
<title>ML2</title>
<para>The Modular Layer 2 plug-in allows OpenStack Networking to simultaneously utilize the
variety of layer 2 networking technologies found in complex real-world data centers. It
currently includes drivers for the local, flat, VLAN, GRE and VXLAN network types and
works with the existing <emphasis>Open vSwitch</emphasis>, <emphasis>Linux Bridge
</emphasis>, and <emphasis>HyperV</emphasis> L2 agents. The <emphasis>ML2</emphasis>
plug-in can be extended through mechanism drivers, allowing multiple mechanisms to be
used simultaneously. This section describes different <emphasis>ML2</emphasis> plug-in
and agent configurations with different type drivers and mechanism drivers.</para>
<note>
<para>Currently, there is no need to define <literal>SEGMENTATION_ID</literal>
network provider attribute for GRE and VXLAN network types. The choice can be
delegated to Networking, in such case ML2 plug-in tries to find a network
in tenant network pools which respects specified provider network attributes.
</para>
</note>
<para>Previously, Networking deployments were only able to use the plug-in that had been
selected at implementation time. For example, a deployment running the Open vSwitch
plug-in was only able to use Open vSwitch exclusively; it wasn't possible to
simultaneously run another plug-in such as Linux Bridge. This was found to be a
limitation in environments with heterogeneous requirements.</para>
<warning>
<para>Disabling a ML2 type driver and re-enabling it later may lead to database
inconsistencies if ML2 is reconfigured without support for that type.</para>
</warning>
<section xml:id="ml2_l2pop_scenarios">
<title>ML2 with L2 population mechanism driver</title>
<para>The L2 Population driver enables broadcast, multicast, and unicast traffic to
scale out on large overlay networks. This traffic is sent to the relevant agent via
encapsulation as a targeted unicast.</para>
<para>Current <emphasis>Open vSwitch</emphasis> and <emphasis>Linux Bridge</emphasis>
tunneling implementations broadcast to every agent, even if they don't host the
corresponding network as illustrated below.</para>
<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/ml2_without_l2pop_full_mesh.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>
<para>As broadcast emulation on overlay is costly, it may be better to avoid its use for
MAC learning and ARP resolution. This supposes the use of proxy ARP on the agent to
answer VM requests, and to populate forwarding table. Currently only the
<emphasis>Linux Bridge</emphasis> Agent implements an ARP proxy. The
pre-population limits L2 broadcasts in overlay, however it may anyway be necessary
to provide broadcast emulation. This is achieved by broadcasting packets via unicast
only to the relevant agents as illustrated below.<mediaobject>
<imageobject>
<imagedata fileref="../../common/figures/ml2_without_l2pop_partial_mesh.png"
contentwidth="6in"/>
</imageobject>
</mediaobject>The partial-mesh is available with the <emphasis>Open
vSwitch</emphasis> and <emphasis>Linux Bridge</emphasis> agents. The following
scenarios will use the L2 population mechanism driver with an <emphasis>Open
vSwitch</emphasis> agent and a <emphasis>Linux Bridge</emphasis> agent. Enable
the l2 population driver by adding it to the list of mechanism drivers. In addition,
a tunneling driver must be selected. Supported options are GRE, VXLAN, or a
combination of both. Configuration settings are enabled in
<filename>ml2_conf.ini</filename>:</para>
<programlisting language="ini">[ml2]
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers = openvswitch,linuxbridge,l2population</programlisting>
</section>
<section xml:id="ml2_l2pop_ovs_scenarios">
<title>Scenario 1: L2 population with Open vSwitch agent</title>
<para>Enable the l2 population extension in the <emphasis>Open vSwitch</emphasis> agent,
and configure the <option>local_ip</option> and <option>tunnel_types</option>
parameters in the <filename>ml2_conf.ini</filename> file:</para>
<programlisting language="ini">[ovs]
local_ip = <replaceable>192.168.1.10</replaceable>
[agent]
tunnel_types = <replaceable>GRE</replaceable>,<replaceable>VXLAN</replaceable>
l2_population = True</programlisting>
</section>
<section xml:id="ml2_l2pop_lb_scenarios">
<title>Scenario 2: L2 population with <emphasis>Linux Bridge</emphasis> agent</title>
<para>Enable the l2 population extension on the <emphasis>Linux Bridge</emphasis> agent.
Enable VXLAN and configure the local_ip parameter in
<filename>ml2_conf.ini</filename>.</para>
<programlisting language="ini">[vxlan]
enable_vxlan = True
local_ip = <replaceable>192.168.1.10</replaceable>
l2_population = True</programlisting>
</section>
<section xml:id="ml2_l2_security_group">
<title>Enable security group API</title>
<para>The ML2 plug-in can concurrently support different L2 agents (or other
mechanisms) with different configuration files, so each L2 agent
configuration file (such as
<filename>ovs_neutron_plugin.ini</filename> or
<filename>linuxbridge_conf.ini</filename>) should contain the appropriate
<option>firewall_driver</option> value for that
agent in addition to setting <option>enable_security_group</option> to
<literal>True</literal> (which is the default).</para>
<para>The <option>firewall_driver</option> value in the API server's <filename>ml2_conf.ini</filename> file
does not matter.</para>
<para>To disable the securitygroup API, edit the <filename>ml2_conf.ini</filename> file
on the API server, and <filename>ovs_neutron_plugin.ini</filename>,
<filename>linuxbridge_conf.ini</filename> or other L2 agent
configuration files on the agent servers :</para>
<programlisting language="ini">[securitygroup]
enable_security_group = False
firewall_driver = neutron.agent.firewall.NoopFirewallDriver</programlisting>
</section>
</section>
</section>

752
doc/admin-guide-cloud/networking/section_networking_adv_features.xml
View File

@ -178,50 +178,6 @@
and set the provider extended attributes through Networking API calls. See <xref
linkend="section_networking_auth"/> for details on policy configuration.</para>
</section>
<section xml:id="provider_api_workflow">
<title>Provider extension API operations</title>
<para>To use the provider extension with the default policy settings, you must have the
administrative role.</para>
<para>This list shows example neutron commands that enable you to complete basic
provider extension API operations:</para>
<itemizedlist>
<listitem>
<para>Shows all attributes of a network, including provider attributes:</para>
<screen><prompt>$</prompt> <userinput>neutron net-show <replaceable>NAME_OR_NET_ID</replaceable></userinput></screen>
</listitem>
<listitem>
<para>Creates a local provider network:</para>
<screen><prompt>$</prompt> <userinput>neutron net-create <replaceable>NAME</replaceable> --tenant_id <replaceable>TENANT_ID</replaceable> --provider:network_type local</userinput></screen>
</listitem>
<listitem>
<para>When you create flat networks, <replaceable>PHYS_NET_NAME</replaceable>
must be known to the plug-in. See the <citetitle>OpenStack Configuration
Reference</citetitle> for details. Creates a flat provider
network:</para>
<screen><prompt>$</prompt> <userinput>neutron net-create <replaceable>NAME</replaceable> --tenant_id <replaceable>TENANT_ID</replaceable> --provider:network_type flat --provider:physical_network <replaceable>PHYS_NET_NAME</replaceable></userinput></screen>
</listitem>
<listitem>
<para>When you create VLAN networks, <replaceable>PHYS_NET_NAME</replaceable>
must be known to the plug-in. See the <citetitle>OpenStack Configuration
Reference</citetitle> for details on configuring network_vlan_ranges to
identify all physical networks. When you create VLAN networks,
<replaceable>VID</replaceable> can fall either within or outside any
configured ranges of VLAN IDs from which tenant networks are allocated.
Creates a VLAN provider network:</para>
<screen><prompt>$</prompt> <userinput>neutron net-create <replaceable>NAME</replaceable> --tenant_id <replaceable>TENANT_ID</replaceable> --provider:network_type vlan --provider:physical_network <replaceable>PHYS_NET_NAME</replaceable> --provider:segmentation_id <replaceable>VID</replaceable></userinput></screen>
</listitem>
<listitem>
<para>When you create GRE networks, <replaceable>TUNNEL_ID</replaceable> can be
either inside or outside any tunnel ID ranges from which tenant networks are
allocated.</para>
<para>After you create provider networks, you can allocate subnets, which you
can use in the same way as other virtual networks, subject to authorization
policy based on the specified <replaceable>TENANT_ID</replaceable>. Creates
a GRE provider network:</para>
<screen><prompt>$</prompt> <userinput>neutron net-create <replaceable>NAME</replaceable> --tenant_id <replaceable>TENANT_ID</replaceable> --provider:network_type gre --provider:segmentation_id <replaceable>TUNNEL_ID</replaceable></userinput></screen>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="section_l3_router_and_nat">
<title>L3 routing and NAT</title>
@ -241,136 +197,6 @@
(and often to all hosts on the Internet). You can allocate and map floating IPs from one
port to another, as needed.</para>
<?hard-pagebreak?>
<section xml:id="l3_api_abstractions">
<title>L3 API abstractions</title>
<table rules="all">
<caption>Router</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the router.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Human-readable name for the router. Might not be unique.</td>
</tr>
<tr>
<td>admin_state_up</td>
<td>Bool</td>
<td>True</td>
<td>The administrative state of router. If false (down), the router does not
forward packets.</td>
</tr>
<tr>
<td>status</td>
<td>String</td>
<td>N/A</td>
<td>
<para>Indicates whether router is currently operational.</para>
</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the router. Only admin users can specify a tenant_id other than
its own.</td>
</tr>
<tr>
<td>external_gateway_info</td>
<td>dict contain 'network_id' key-value pair</td>
<td>Null</td>
<td>External network that this router connects to for gateway services (for
example, NAT)</td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Floating IP</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the floating IP.</td>
</tr>
<tr>
<td>floating_ip_address</td>
<td>string (IP address)</td>
<td>allocated by Networking</td>
<td>The external network IP address available to be mapped to an internal IP
address.</td>
</tr>
<tr>
<td>floating_network_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>
<para>The network indicating the set of subnets from which the floating
IP should be allocated</para>
</td>
</tr>
<tr>
<td>router_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Read-only value indicating the router that connects the external network
to the associated internal port, if a port is associated.</td>
</tr>
<tr>
<td>port_id</td>
<td>uuid-str</td>
<td>Null</td>
<td>Indicates the internal Networking port associated with the external
floating IP.</td>
</tr>
<tr>
<td>fixed_ip_address</td>
<td>string (IP address)</td>
<td>Null</td>
<td>Indicates the IP address on the internal port that is mapped to by the
floating IP (since an Networking port might have more than one IP
address).</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the Floating IP. Only admin users can specify a tenant_id other
than its own.</td>
</tr>
</tbody>
</table>
</section>
<?hard-pagebreak?>
<section xml:id="l3_workflow">
<title>Basic L3 operations</title>
<para>External networks are visible to all users. However, the default policy settings
@ -599,130 +425,6 @@
</listitem>
</itemizedlist>
</note>
<section xml:id="securitygroup_api_abstractions">
<title>Security group API abstractions</title>
<table rules="all">
<caption>Security group attributes</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the security group.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Human-readable name for the security group. Might not be unique. Cannot
be named default as that is automatically created for a tenant.</td>
</tr>
<tr>
<td>description</td>
<td>String</td>
<td>None</td>
<td>Human-readable description of a security group.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the security group. Only admin users can specify a tenant_id
other than their own.</td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Security group rules</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the security group rule.</td>
</tr>
<tr>
<td>security_group_id</td>
<td>uuid-str or Integer</td>
<td>allocated by Networking</td>
<td>The security group to associate rule with.</td>
</tr>
<tr>
<td>direction</td>
<td>String</td>
<td>N/A</td>
<td>The direction the traffic is allow (ingress/egress) from a VM.</td>
</tr>
<tr>
<td>protocol</td>
<td>String</td>
<td>None</td>
<td>IP Protocol (icmp, tcp, udp, and so on).</td>
</tr>
<tr>
<td>port_range_min</td>
<td>Integer</td>
<td>None</td>
<td>Port at start of range</td>
</tr>
<tr>
<td>port_range_max</td>
<td>Integer</td>
<td>None</td>
<td>Port at end of range</td>
</tr>
<tr>
<td>ethertype</td>
<td>String</td>
<td>None</td>
<td>ethertype in L2 packet (IPv4, IPv6, and so on)</td>
</tr>
<tr>
<td>remote_ip_prefix</td>
<td>string (IP cidr)</td>
<td>None</td>
<td>CIDR for address range</td>
</tr>
<tr>
<td>remote_group_id</td>
<td>uuid-str or Integer</td>
<td>allocated by Networking or Compute</td>
<td>Source security group to apply to rule.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the security group rule. Only admin users can specify a
tenant_id other than its own.</td>
</tr>
</tbody>
</table>
</section>
<section xml:id="securitygroup_workflow">
<title>Basic security group operations</title>
<para>This table shows example neutron commands that enable you to complete basic
@ -850,292 +552,6 @@
</itemizedlist>
</section>
<?hard-pagebreak?>
<section xml:id="fwaas">
<title>Firewall-as-a-Service</title>
<para>The Firewall-as-a-Service (FWaaS) API is an experimental API that enables early
adopters and vendors to test their networking implementations.</para>
<section xml:id="fwaas_api_abstractions">
<title>Firewall-as-a-Service API abstractions</title>
<table rules="all">
<caption>Firewall rules</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the firewall rule.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the firewall rule. Only admin users can specify a tenant_id
other than its own.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Human readable name for the firewall rule (255 characters limit).</td>
</tr>
<tr>
<td>description</td>
<td>String</td>
<td>None</td>
<td>Human-readable description for the firewall rule (1024 characters
limit).</td>
</tr>
<tr>
<td>firewall_policy_id</td>
<td>uuid-str or None</td>
<td>allocated by Networking</td>
<td>This is a read-only attribute that gets populated with the uuid of the
firewall policy when this firewall rule is associated with a firewall
policy. A firewall rule can be associated with only one firewall policy
at a time. However, the association can be changed to a different
firewall policy.</td>
</tr>
<tr>
<td>shared</td>
<td>Boolean</td>
<td>False</td>
<td>When set to True makes this firewall rule visible to tenants other than
its owner and it can be used in firewall policies not owned by its
tenant.</td>
</tr>
<tr>
<td>protocol</td>
<td>String</td>
<td>None</td>
<td>IP protocol (icmp, tcp, udp, None).</td>
</tr>
<tr>
<td>ip_version</td>
<td>Integer or String</td>
<td>4</td>
<td>IP version (4, 6).</td>
</tr>
<tr>
<td>source_ip_address</td>
<td>String (IP address or CIDR)</td>
<td>None</td>
<td>Source IP address or CIDR.</td>
</tr>
<tr>
<td>destination_ip_address</td>
<td>String (IP address or CIDR)</td>
<td>None</td>
<td>Destination IP address or CIDR.</td>
</tr>
<tr>
<td>source_port</td>
<td>Integer or String (either as a single port number or in the format of a
':' separated range)</td>
<td>None</td>
<td>Source port number or a range.</td>
</tr>
<tr>
<td>destination_port</td>
<td>Integer or String (either as a single port number or in the format of a
':' separated range)</td>
<td>None</td>
<td>Destination port number or a range.</td>
</tr>
<tr>
<td>position</td>
<td>Integer</td>
<td>None</td>
<td>This is a read-only attribute that gets assigned to this rule when the
rule is associated with a firewall policy. It indicates the position of
this rule in that firewall policy.</td>
</tr>
<tr>
<td>action</td>
<td>String</td>
<td>deny</td>
<td>Action to be performed on the traffic matching the rule (allow,
deny).</td>
</tr>
<tr>
<td>enabled</td>
<td>Boolean</td>
<td>True</td>
<td>When set to <literal>False</literal>, disables this rule in the firewall
policy. Facilitates selectively turning off rules without having to
disassociate the rule from the firewall policy.</td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Firewall policies</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the firewall policy.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the firewall policy. Only admin users can specify a tenant_id
other their own.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Human readable name for the firewall policy (255 characters limit).</td>
</tr>
<tr>
<td>description</td>
<td>String</td>
<td>None</td>
<td>Human readable description for the firewall policy (1024 characters
limit).</td>
</tr>
<tr>
<td>shared</td>
<td>Boolean</td>
<td>False</td>
<td>When set to True makes this firewall policy visible to tenants other
than its owner and can be used to associate with firewalls not owned by
its tenant.</td>
</tr>
<tr>
<td>firewall_rules</td>
<td>List of uuid-str or None</td>
<td>None</td>
<td>This is an ordered list of firewall rule uuids. The firewall applies the
rules in the order in which they appear in this list.</td>
</tr>
<tr>
<td>audited</td>
<td>Boolean</td>
<td>False</td>
<td>When set to True by the policy owner indicates that the firewall policy
has been audited. This attribute is meant to aid in the firewall policy
audit work flows. Each time the firewall policy or the associated
firewall rules are changed, this attribute is set to False and must be
explicitly set to True through an update operation.</td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Firewalls</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the firewall.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the firewall. Only admin users can specify a tenant_id other
than its own.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Human readable name for the firewall (255 characters limit).</td>
</tr>
<tr>
<td>description</td>
<td>String</td>
<td>None</td>
<td>Human readable description for the firewall (1024 characters
limit).</td>
</tr>
<tr>
<td>admin_state_up</td>
<td>Boolean</td>
<td>True</td>
<td>The administrative state of the firewall. If False (down), the firewall
does not forward any packets.</td>
</tr>
<tr>
<td>status</td>
<td>String</td>
<td>N/A</td>
<td>
<para>Indicates whether the firewall is currently operational. Possible
values include:</para>
<itemizedlist>
<listitem>
<para>ACTIVE</para>
</listitem>
<listitem>
<para>DOWN</para>
</listitem>
<listitem>
<para>PENDING_CREATE</para>
</listitem>
<listitem>
<para>PENDING_UPDATE</para>
</listitem>
<listitem>
<para>PENDING_DELETE</para>
</listitem>
<listitem>
<para>ERROR</para>
</listitem>
</itemizedlist>
</td>
</tr>
<tr>
<td>firewall_policy_id</td>
<td>uuid-str or None</td>
<td>None</td>
<td>The firewall policy uuid that this firewall is associated with. This
firewall implements the rules contained in the firewall policy
represented by this uuid.</td>
</tr>
</tbody>
</table>
</section>
</section>
<?hard-pagebreak?>
<section xml:id="section_plugin_specific_extensions">
<title>Plug-in specific extensions</title>
<?dbhtml stop-chunking?>
@ -1165,76 +581,6 @@
rxtx scaling factor. Note that after a network or default queue is specified,
queues are added to ports that are subsequently created but are not added to
existing ports.</para>
<section xml:id="section_vmware_nsx_qos_api_abstractions">
<title>VMware NSX QoS API abstractions</title>
<table rules="all">
<caption>VMware NSX QoS attributes</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the QoS queue.</td>
</tr>
<tr>
<td>default</td>
<td>Boolean</td>
<td>False by default</td>
<td>If True, ports are created with this queue size unless the
network port is created or associated with a queue at port
creation time.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Name for QoS queue.</td>
</tr>
<tr>
<td>min</td>
<td>Integer</td>
<td>0</td>
<td>Minimum Bandwidth Rate (kbps).</td>
</tr>
<tr>
<td>max</td>
<td>Integer</td>
<td>N/A</td>
<td>Maximum Bandwidth Rate (kbps).</td>
</tr>
<tr>
<td>qos_marking</td>
<td>String</td>
<td>untrusted by default</td>
<td>Whether QoS marking should be trusted or untrusted.</td>
</tr>
<tr>
<td>dscp</td>
<td>Integer</td>
<td>0</td>
<td>DSCP Marking value.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>The owner of the QoS queue.</td>
</tr>
</tbody>
</table>
</section>
<section xml:id="vmware_nsx_qos_walk_through">
<title>Basic VMware NSX QoS operations</title>
<para>This table shows example neutron commands that enable you to complete
@ -1569,104 +915,6 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny</userinput></screen>
measurement. Two abstractions have been added: One is the metering label that can
contain metering rules. Because a metering label is associated with a tenant, all
virtual routers in this tenant are associated with this label.</para>
<section xml:id="metering_abstraction">
<title>L3 metering API abstractions</title>
<table rules="all">
<caption>Label</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the metering label.</td>
</tr>
<tr>
<td>name</td>
<td>String</td>
<td>None</td>
<td>Human-readable name for the metering label. Might not be unique.</td>
</tr>
<tr>
<td>description</td>
<td>String</td>
<td>None</td>
<td>The optional description for the metering label.</td>
</tr>
<tr>
<td>tenant_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>Owner of the metering label.</td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Rules</caption>
<col width="20%"/>
<col width="20%"/>
<col width="20%"/>
<col width="40%"/>
<thead>
<tr>
<th>Attribute name</th>
<th>Type</th>
<th>Default Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>uuid-str</td>
<td>generated</td>
<td>UUID for the metering rule.</td>
</tr>
<tr>
<td>direction</td>
<td>String (Either ingress or egress)</td>
<td>ingress</td>
<td>The direction in which metering rule is applied, either ingress or
egress.</td>
</tr>
<tr>
<td>metering_label_id</td>
<td>uuid-str</td>
<td>N/A</td>
<td>
<para>The metering label ID to associate with this metering rule.</para>
</td>
</tr>
<tr>
<td>excluded</td>
<td>Boolean</td>
<td>False</td>
<td>Specify whether the remote_ip_prefix will be excluded or not from
traffic counters of the metering label (for example, to not count the
traffic of a specific IP address of a range).</td>
</tr>
<tr>
<td>remote_ip_prefix</td>
<td>String (CIDR)</td>
<td>N/A</td>
<td>Indicates remote IP prefix to be associated with this metering
rule.</td>
</tr>
</tbody>
</table>
</section>
<?hard-pagebreak?>
<section xml:id="metering_operations">
<title>Basic L3 metering operations</title>
<para>Only administrators can manage the L3 metering labels and rules.</para>