openstack/openstack-manuals
Code Issues Proposed changes

Merge "Move Networking scenarios section from Configuration Reference to Cloud Admin Guide"

Browse Source
This commit is contained in:
Jenkins 2014-01-04 16:08:48 +00:00 committed by Gerrit Code Review
commit 9c8a43d420
7 changed files with 312 additions and 389 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1490,6 +1490,10 @@ enabled = True</programlisting>
</para> </para>
</section> </section>
</section> </section>
<xi:include href="section_networking-config-identity.xml"/>
<xi:include href="section_networking-scenarios.xml"/>
<xi:include href="section_networking-adv-config.xml"/>
<xi:include href="section_networking-multi-dhcp-agents.xml"/>
<section xml:id="section_networking-use"> <section xml:id="section_networking-use">
<title>Use Networking</title> <title>Use Networking</title>
<para>You can start and stop OpenStack Networking services <para>You can start and stop OpenStack Networking services
@ -2191,7 +2195,7 @@ enabled = True</programlisting>
</section> </section>
<xi:include href="section_networking_adv_features.xml"/> <xi:include href="section_networking_adv_features.xml"/>
<xi:include href="section_networking_adv_operational_features.xml"/> <xi:include href="section_networking_adv_operational_features.xml"/>
<section xml:id="section_auth"> <section xml:id="section_networking_auth">
<title>Authentication and authorization</title> <title>Authentication and authorization</title>
<para>Networking uses the Identity Service as the default <para>Networking uses the Identity Service as the default
authentication service. When the Identity Service is authentication service. When the Identity Service is

3
doc/config-reference/networking/section_networking-adv-config.xml → doc/admin-guide-cloud/section_networking-adv-config.xml
View File

@ -197,7 +197,8 @@ mysql&gt; grant all on &lt;database-name&gt;.* to '&lt;user-name&gt;'@'%';</comp
--config-file &lt;l3 config&gt;</computeroutput></screen> --config-file &lt;l3 config&gt;</computeroutput></screen>
<para>A driver needs to be configured that matches the plug-in <para>A driver needs to be configured that matches the plug-in
running on the service. The driver is used to create the running on the service. The driver is used to create the
routing interface. <table rules="all"> routing interface.
<table rules="all">
<caption>Basic settings</caption> <caption>Basic settings</caption>
<col width="50%"/> <col width="50%"/>
<col width="50%"/> <col width="50%"/>

210
doc/config-reference/networking/section_networking-config-identity.xml → doc/admin-guide-cloud/section_networking-config-identity.xml
View File

@ -3,22 +3,21 @@
xmlns="http://docbook.org/ns/docbook" xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"> xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
<title>Identity Service</title> <title>Configure Identity Service for Networking</title>
<procedure> <procedure>
<title>To configure the Identity Service for use with <title>To configure the Identity Service for use with
Networking</title> Networking</title>
<step> <step>
<title>Create the <function>get_id()</function> function</title> <title>Create the <function>get_id()</function> function</title>
<para>The <function>get_id()</function> function stores the ID <para>The <function>get_id()</function> function stores the ID of created objects, and removes
of created objects, and removes error-prone copying and the need to copy and paste object IDs in later steps:</para>
pasting of object IDs in later steps:</para>
<substeps> <substeps>
<step> <step>
<para>Add the following function to your <para>Add the following function to your
<filename>.bashrc</filename> file:</para> <filename>.bashrc</filename> file:</para>
<screen><prompt>$</prompt> <userinput>function get_id () { <programlisting>function get_id () {
echo `"$@" | awk '/ id / { print $4 }'` echo `"$@" | awk '/ id / { print $4 }'`
}</userinput></screen> }</programlisting>
</step> </step>
<step> <step>
<para>Source the <filename>.bashrc</filename> file:</para> <para>Source the <filename>.bashrc</filename> file:</para>
@ -28,35 +27,33 @@ echo `"$@" | awk '/ id / { print $4 }'`
</step> </step>
<step> <step>
<title>Create the Networking service entry</title> <title>Create the Networking service entry</title>
<para>OpenStack Networking must be available in the OpenStack <para>Networking must be available in the Compute service catalog. Create the service:</para>
Compute service catalog. Create the service:</para>
<screen><prompt>$</prompt> <userinput>NEUTRON_SERVICE_ID=$(get_id keystone service-create --name neutron --type network --description 'OpenStack Networking Service')</userinput></screen> <screen><prompt>$</prompt> <userinput>NEUTRON_SERVICE_ID=$(get_id keystone service-create --name neutron --type network --description 'OpenStack Networking Service')</userinput></screen>
</step> </step>
<step> <step>
<title>Create the Networking service endpoint <title>Create the Networking service endpoint
entry</title> entry</title>
<para>The way that you create an OpenStack Networking endpoint <para>The way that you create a Networking endpoint entry depends on whether you are using the
entry depends on whether you are using the SQL catalog driver SQL or the template catalog driver:</para>
or the template catalog driver:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>If you use the <emphasis>SQL driver</emphasis>, run <para>If you use the <emphasis>SQL driver</emphasis>, run the following command with the
these command with these parameters: specified region specified region (<literal>$REGION</literal>), IP address of the Networking server
($REGION), IP address of the OpenStack Networking server (<literal>$IP</literal>), and service ID (<literal>$NEUTRON_SERVICE_ID</literal>,
($IP), and service ID ($NEUTRON_SERVICE_ID, obtained in obtained in the previous step).</para>
the previous step).</para>
<screen><prompt>$</prompt> <userinput>keystone endpoint-create --region $REGION --service-id $NEUTRON_SERVICE_ID --publicurl 'http://$IP:9696/' --adminurl 'http://$IP:9696/' --internalurl 'http://$IP:9696/'</userinput></screen> <screen><prompt>$</prompt> <userinput>keystone endpoint-create --region $REGION --service-id $NEUTRON_SERVICE_ID \
--publicurl 'http://$IP:9696/' --adminurl 'http://$IP:9696/' --internalurl 'http://$IP:9696/'</userinput></screen>
<para>For example:</para> <para>For example:</para>
<screen><prompt>$</prompt> <userinput>keystone endpoint-create --region myregion --service-id $NEUTRON_SERVICE_ID \ <screen><prompt>$</prompt> <userinput>keystone endpoint-create --region myregion --service-id $NEUTRON_SERVICE_ID \
--publicurl "http://10.211.55.17:9696/" --adminurl "http://10.211.55.17:9696/" --internalurl "http://10.211.55.17:9696/" </userinput></screen> --publicurl "http://10.211.55.17:9696/" --adminurl "http://10.211.55.17:9696/" --internalurl "http://10.211.55.17:9696/" </userinput></screen>
</listitem> </listitem>
<listitem> <listitem>
<para>If you are using the <emphasis>template <para>If you are using the <emphasis>template driver</emphasis>, specify the following
driver</emphasis>, add the following content to your parameters in your Compute catalog template file
OpenStack Compute catalog template file (<filename>default_catalog.templates</filename>), along with the region
(default_catalog.templates), using these parameters: given (<literal>$REGION</literal>) and IP address of the Networking server
region ($REGION) and IP address of the OpenStack (<literal>$IP</literal>).</para>
Networking server ($IP).</para>
<programlisting language="bash">catalog.$REGION.network.publicURL = http://$IP:9696 <programlisting language="bash">catalog.$REGION.network.publicURL = http://$IP:9696
catalog.$REGION.network.adminURL = http://$IP:9696 catalog.$REGION.network.adminURL = http://$IP:9696
catalog.$REGION.network.internalURL = http://$IP:9696 catalog.$REGION.network.internalURL = http://$IP:9696
@ -65,19 +62,16 @@ catalog.$REGION.network.name = Network Service</programlisting>
<programlisting language="bash">catalog.$Region.network.publicURL = http://10.211.55.17:9696 <programlisting language="bash">catalog.$Region.network.publicURL = http://10.211.55.17:9696
catalog.$Region.network.adminURL = http://10.211.55.17:9696 catalog.$Region.network.adminURL = http://10.211.55.17:9696
catalog.$Region.network.internalURL = http://10.211.55.17:9696 catalog.$Region.network.internalURL = http://10.211.55.17:9696
catalog.$Region.network.name = Network Service</programlisting> catalog.$Region.network.name = Network Service</programlisting>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</step> </step>
<step> <step>
<title>Create the Networking service user</title> <title>Create the Networking service user</title>
<para>You must provide admin user credentials that OpenStack <para>You must provide admin user credentials that Compute and some internal Networking
Compute and some internal components of OpenStack Networking components can use to access the Networking API. Create a special <literal>service</literal>
can use to access the OpenStack Networking API. The suggested tenant and a <literal>neutron</literal> user within this tenant, and assign an
approach is to create a special <literal>service</literal> <literal>admin</literal> role to this role.</para>
tenant, create a <literal>neutron</literal> user within this
tenant, and to assign this user an <literal>admin</literal>
role.</para>
<substeps> <substeps>
<step> <step>
<para>Create the <literal>admin</literal> role:</para> <para>Create the <literal>admin</literal> role:</para>
@ -101,62 +95,47 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
</substeps> </substeps>
</step> </step>
</procedure> </procedure>
<para>For information about how to create service entries and users. <para>For information about how to create service entries and users, see the <citetitle>OpenStack
see the <citetitle>OpenStack Installation Guide</citetitle> for Installation Guide</citetitle> for your distribution (<link xlink:href="docs.openstack.org"
your distribution (<link xlink:href="docs.openstack.org"
>docs.openstack.org</link>).</para> >docs.openstack.org</link>).</para>
<section xml:id="nova_with_neutron"> <section xml:id="nova_with_neutron">
<title>Compute</title> <title>Compute</title>
<para>If you use OpenStack Networking, do not run the OpenStack <para>If you use Networking, do not run the Compute <systemitem class="service"
Compute <systemitem class="service">nova-network</systemitem> >nova-network</systemitem> service (like you do in traditional Compute deployments).
service (like you do in traditional OpenStack Compute Instead, Compute delegates most network-related decisions to Networking. Compute proxies
deployments). Instead, OpenStack Compute delegates most tenant-facing API calls to manage security groups and floating IPs to Networking APIs.
network-related decisions to OpenStack Networking. OpenStack However, operator-facing tools such as <systemitem class="service">nova-manage</systemitem>,
Compute proxies tenant-facing API calls to manage security are not proxied and should not be used.</para>
groups and floating IPs to Networking APIs. However,
operator-facing tools such as <systemitem class="service"
>nova-manage</systemitem>, are not proxied and should not be
used.</para>
<warning> <warning>
<para>When you configure networking, you must use this guide. Do <para>When you configure networking, you must use this guide. Do not rely on Compute
not rely on OpenStack Compute networking documentation or past networking documentation or past experience with Compute. If a <command>nova</command>
experience with OpenStack Compute. If a command or configuration option related to networking is not mentioned in this guide, the
<command>nova</command> command or configuration option command is probably not supported for use with Networking. In particular, you cannot use CLI
related to networking is not mentioned in this guide, the tools like <command>nova-manage</command> and <command>nova</command> to manage networks or
command is probably not supported for use with OpenStack IP addressing, including both fixed and floating IPs, with Networking.</para>
Networking. In particular, you cannot use CLI tools like
<command>nova-manage</command> and <command>nova</command>
to manage networks or IP addressing, including both fixed and
floating IPs, with OpenStack Networking.</para>
</warning> </warning>
<note> <note>
<para>It is strongly recommended that you uninstall <systemitem <para>Uninstall <systemitem class="service">nova-network</systemitem> and reboot any physical
class="service">nova-network</systemitem> and reboot any nodes that have been running <systemitem class="service">nova-network</systemitem> before
physical nodes that have been running <systemitem using them to run Networking. Inadvertently running the <systemitem class="service"
class="service">nova-network</systemitem> before using them >nova-network</systemitem> process while using Networking can cause problems, as can stale
to run OpenStack Networking. Inadvertently running the iptables rules pushed down by previously running <systemitem class="service"
<systemitem class="service">nova-network</systemitem> >nova-network</systemitem>.</para>
process while using OpenStack Networking can cause problems,
as can stale iptables rules pushed down by previously running
<systemitem class="service">nova-network</systemitem>.
</para>
</note> </note>
<para>To ensure that OpenStack Compute works properly with <para>To ensure that Compute works properly with Networking
OpenStack Networking (rather than the legacy <systemitem (rather than the legacy <systemitem
class="service">nova-network</systemitem> mechanism), you must class="service">nova-network</systemitem> mechanism), you must
adjust settings in the <filename>nova.conf</filename> adjust settings in the <filename>nova.conf</filename>
configuration file.</para> configuration file.</para>
</section> </section>
<section xml:id="nova_with_neutron_api"> <section xml:id="nova_with_neutron_api">
<title>Networking API and credential configuration</title> <title>Networking API and credential configuration</title>
<para>Each time a VM is provisioned or de-provisioned in OpenStack <para>Each time you provision or de-provision a VM in Compute, <systemitem class="service"
Compute, <systemitem class="service">nova-*</systemitem> >nova-*</systemitem> services communicate with Networking using the standard API. For this
services communicate with OpenStack Networking using the to happen, you must configure the following items in the <filename>nova.conf</filename> file
standard API. For this to happen, you must configure the (used by each <systemitem class="service">nova-compute</systemitem> and <systemitem
following items in the <filename>nova.conf</filename> file (used class="service">nova-api</systemitem> instance).</para>
by each <systemitem class="service">nova-compute</systemitem>
and <systemitem class="service">nova-api</systemitem>
instance).</para>
<table rules="all"> <table rules="all">
<caption>nova.conf API and credential settings</caption> <caption>nova.conf API and credential settings</caption>
<col width="20%"/> <col width="20%"/>
@ -170,12 +149,13 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
<tbody> <tbody>
<tr> <tr>
<td><para><literal>network_api_class</literal></para></td> <td><para><literal>network_api_class</literal></para></td>
<td><para>Modify from the default to <td>
<para>Modify from the default to
<literal>nova.network.neutronv2.api.API</literal>, to <literal>nova.network.neutronv2.api.API</literal>, to
indicate that OpenStack Networking should be used rather indicate that Networking should be used rather than the
than the traditional <systemitem class="service" traditional <systemitem class="service" >nova-network
>nova-network </systemitem> networking model. </systemitem> networking model.</para>
</para></td> </td>
</tr> </tr>
<tr> <tr>
<td><para><literal>neutron_url</literal></para></td> <td><para><literal>neutron_url</literal></para></td>
@ -191,44 +171,45 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
</tr> </tr>
<tr> <tr>
<td><para><literal>neutron_admin_tenant_name</literal></para></td> <td><para><literal>neutron_admin_tenant_name</literal></para></td>
<td><para>Update to the name of the service tenant created <td>
in the above section on OpenStack Identity <para>Update to the name of the service tenant created in
configuration.</para></td> the above section on Identity configuration.</para>
</td>
</tr> </tr>
<tr> <tr>
<td><para><literal>neutron_admin_username</literal></para></td> <td><para><literal>neutron_admin_username</literal></para></td>
<td><para>Update to the name of the user created in the <td>
above section on OpenStack Identity configuration. <para>Update to the name of the user created in the above
</para></td> section on Identity configuration.</para>
</td>
</tr> </tr>
<tr> <tr>
<td><para><literal>neutron_admin_password</literal></para></td> <td><para><literal>neutron_admin_password</literal></para></td>
<td><para>Update to the password of the user created in the <td>
above section on OpenStack Identity configuration. <para>Update to the password of the user created in the
</para></td> above section on Identity configuration.</para>
</td>
</tr> </tr>
<tr> <tr>
<td><para><literal>neutron_admin_auth_url</literal></para></td> <td><para><literal>neutron_admin_auth_url</literal></para></td>
<td><para>Update to the OpenStack Identity server IP and <td>
port. This is the Identity (keystone) admin API server <para>Update to the Identity server IP and port. This is
IP and port value, and not the Identity service API IP the Identity (keystone) admin API server IP and port
and port.</para></td> value, and not the Identity service API IP and
port.</para>
</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section xml:id="nova_config_security_groups"> <section xml:id="nova_config_security_groups">
<title>Configure security groups</title> <title>Configure security groups</title>
<para>The OpenStack Networking Service provides security group <para>The Networking Service provides security group functionality using a mechanism that is
functionality using a mechanism that is more flexible and more flexible and powerful than the security group capabilities built into Compute. Therefore,
powerful than the security group capabilities built into if you use Networking, you should always disable built-in security groups and proxy all
OpenStack Compute. Therefore, if you use OpenStack Networking, security group calls to the Networking API . If you do not, security policies will conflict by
you should always disable built-in security groups and proxy all being simultaneously applied by both services.</para>
security group calls to the OpenStack Networking API . If you do <para>To proxy security groups to Networking, use the following configuration values in
not, security policies will conflict by being simultaneously
applied by both services.</para>
<para>To proxy security groups to OpenStack Networking, use the
following configuration values in
<filename>nova.conf</filename>:</para> <filename>nova.conf</filename>:</para>
<table rules="all"> <table rules="all">
<caption>nova.conf security group settings</caption> <caption>nova.conf security group settings</caption>
@ -251,8 +232,7 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
</tr> </tr>
<tr> <tr>
<td><para><literal>security_group_api</literal></para></td> <td><para><literal>security_group_api</literal></para></td>
<td><para>Update to <literal>neutron</literal>, so that all <td><para>Update to <literal>neutron</literal>, so that all security group requests are proxied to the
security group requests are proxied to the OpenStack
Network Service.</para></td> Network Service.</para></td>
</tr> </tr>
</tbody> </tbody>
@ -260,13 +240,10 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
</section> </section>
<section xml:id="nova_config_metadata"> <section xml:id="nova_config_metadata">
<title>Configure metadata</title> <title>Configure metadata</title>
<para>The OpenStack Compute service allows VMs to query metadata <para>The Compute service allows VMs to query metadata associated with a VM by making a web
associated with a VM by making a web request to a special request to a special 169.254.169.254 address. Networking supports proxying those requests to
169.254.169.254 address. OpenStack Networking supports proxying <systemitem class="service">nova-api</systemitem>, even when the requests are made from
those requests to <systemitem class="service" isolated networks, or from multiple networks that use overlapping IP addresses.</para>
>nova-api</systemitem>, even when the requests are made from
isolated networks, or from multiple networks that use
overlapping IP addresses.</para>
<para>To enable proxying the requests, you must update the <para>To enable proxying the requests, you must update the
following fields in <filename>nova.conf</filename>.</para> following fields in <filename>nova.conf</filename>.</para>
<table rules="all"> <table rules="all">
@ -323,10 +300,9 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
<title>Example nova.conf (for <systemitem class="service" <title>Example nova.conf (for <systemitem class="service"
>nova-compute</systemitem> and <systemitem class="service" >nova-compute</systemitem> and <systemitem class="service"
>nova-api</systemitem>)</title> >nova-api</systemitem>)</title>
<para>Example values for the above settings, assuming a cloud <para>Example values for the above settings, assuming a cloud controller node running Compute
controller node running OpenStack Compute and OpenStack and Networking with an IP address of 192.168.1.2:</para>
Networking with an IP address of 192.168.1.2.</para> <programlisting language="ini">network_api_class=nova.network.neutronv2.api.API
<screen><computeroutput>network_api_class=nova.network.neutronv2.api.API
neutron_url=http://192.168.1.2:9696 neutron_url=http://192.168.1.2:9696
neutron_auth_strategy=keystone neutron_auth_strategy=keystone
neutron_admin_tenant_name=service neutron_admin_tenant_name=service
@ -339,6 +315,6 @@ firewall_driver=nova.virt.firewall.NoopFirewallDriver
service_neutron_metadata_proxy=true service_neutron_metadata_proxy=true
neutron_metadata_proxy_shared_secret=foo neutron_metadata_proxy_shared_secret=foo
</computeroutput></screen> </programlisting>
</section> </section>
</section> </section>

192
doc/config-reference/networking/section_networking-multi-dhcp-agents.xml → doc/admin-guide-cloud/section_networking-multi-dhcp-agents.xml
View File

@ -1,39 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section [
<!-- Some useful entities borrowed from HTML -->
<!ENTITY ndash "&#x2013;">
<!ENTITY mdash "&#x2014;">
<!ENTITY hellip "&#x2026;">
<!ENTITY plusmn "&#xB1;">
<!-- Useful for describing APIs -->
<!ENTITY GET '<command xmlns="http://docbook.org/ns/docbook">GET</command>'>
<!ENTITY PUT '<command xmlns="http://docbook.org/ns/docbook">PUT</command>'>
<!ENTITY POST '<command xmlns="http://docbook.org/ns/docbook">POST</command>'>
<!ENTITY DELETE '<command xmlns="http://docbook.org/ns/docbook">DELETE</command>'>
<!ENTITY CHECK '<inlinemediaobject xmlns="http://docbook.org/ns/docbook">
<imageobject role="fo">
<imagedata fileref="figures/Check_mark_23x20_02.svg"
format="SVG" scale="60"/>
</imageobject>
<imageobject role="html">
<imagedata fileref="../figures/Check_mark_23x20_02.png"
format="PNG" />
</imageobject>
</inlinemediaobject>'>
<!ENTITY ARROW '<inlinemediaobject xmlns="http://docbook.org/ns/docbook">
<imageobject role="fo">
<imagedata fileref="figures/Arrow_east.svg"
format="SVG" scale="60"/>
</imageobject>
<imageobject role="html">
<imagedata fileref="../figures/Arrow_east.png"
format="PNG" />
</imageobject>
</inlinemediaobject>'>
]>
<section xmlns="http://docbook.org/ns/docbook" <section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
@ -60,18 +25,16 @@ format="PNG" />
+-----------------+--------------------------+ +-----------------+--------------------------+
</computeroutput></screen></para> </computeroutput></screen></para>
</note> </note>
<informalfigure>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata <imagedata
fileref="../../common/figures/demo_multiple_dhcp_agents.png" fileref="../common/figures/demo_multiple_dhcp_agents.png"
contentwidth="6in"/> contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
</informalfigure> <para>There will be three hosts in the setup.
<para>There will be three hosts in the setup.</para>
<table rules="all"> <table rules="all">
<caption>Hosts for Demo</caption> <caption>Hosts for demo</caption>
<thead> <thead>
<tr> <tr>
<th>Host</th> <th>Host</th>
@ -86,13 +49,11 @@ format="PNG" />
The node must have at least one network The node must have at least one network
interface that is connected to the interface that is connected to the
Management Network.</para> Management Network.</para>
<note> <para>Note that <systemitem class="service"
<para>
<systemitem class="service"
>nova-network</systemitem> should >nova-network</systemitem> should
not be running because it is replaced not be running because it is replaced
by Neutron.</para> by Neutron.</para>
</note></td> </td>
</tr> </tr>
<tr> <tr>
<td>HostA</td> <td>HostA</td>
@ -105,14 +66,12 @@ format="PNG" />
</tr> </tr>
</tbody> </tbody>
</table> </table>
</para>
<section xml:id="multi_agent_demo_configuration"> <section xml:id="multi_agent_demo_configuration">
<title>Configuration</title> <title>Configuration</title>
<itemizedlist> <procedure>
<listitem> <title>controlnode&#151;Neutron Server</title>
<para><emphasis role="bold">controlnode - Neutron <step>
Server</emphasis></para>
<orderedlist>
<listitem>
<para>Neutron configuration file <para>Neutron configuration file
<filename>/etc/neutron/neutron.conf</filename>:</para> <filename>/etc/neutron/neutron.conf</filename>:</para>
<programlisting language="ini">[DEFAULT] <programlisting language="ini">[DEFAULT]
@ -121,8 +80,8 @@ rabbit_host = controlnode
allow_overlapping_ips = True allow_overlapping_ips = True
host = controlnode host = controlnode
agent_down_time = 5</programlisting> agent_down_time = 5</programlisting>
</listitem> </step>
<listitem> <step>
<para>Update the plug-in configuration file <para>Update the plug-in configuration file
<filename>/etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini</filename>:</para> <filename>/etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini</filename>:</para>
<programlisting language="ini">[vlans] <programlisting language="ini">[vlans]
@ -133,14 +92,11 @@ connection = mysql://root:root@127.0.0.1:3306/neutron_linux_bridge
retry_interval = 2 retry_interval = 2
[linux_bridge] [linux_bridge]
physical_interface_mappings = physnet1:eth0</programlisting> physical_interface_mappings = physnet1:eth0</programlisting>
</listitem> </step>
</orderedlist> </procedure>
</listitem> <procedure>
<listitem> <title>HostA and HostB&#151;L2 Agent</title>
<para><emphasis role="bold">HostA and HostB - L2 <step>
Agent</emphasis></para>
<orderedlist>
<listitem>
<para>Neutron configuration file <para>Neutron configuration file
<filename>/etc/neutron/neutron.conf</filename>:</para> <filename>/etc/neutron/neutron.conf</filename>:</para>
<programlisting language="ini">[DEFAULT] <programlisting language="ini">[DEFAULT]
@ -148,8 +104,8 @@ rabbit_host = controlnode
rabbit_password = openstack rabbit_password = openstack
# host = HostB on hostb # host = HostB on hostb
host = HostA</programlisting> host = HostA</programlisting>
</listitem> </step>
<listitem> <step>
<para>Update the plug-in configuration file <para>Update the plug-in configuration file
<filename>/etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini</filename>:</para> <filename>/etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini</filename>:</para>
<programlisting language="ini">[vlans] <programlisting language="ini">[vlans]
@ -160,8 +116,8 @@ connection = mysql://root:root@127.0.0.1:3306/neutron_linux_bridge
retry_interval = 2 retry_interval = 2
[linux_bridge] [linux_bridge]
physical_interface_mappings = physnet1:eth0</programlisting> physical_interface_mappings = physnet1:eth0</programlisting>
</listitem> </step>
<listitem> <step>
<para>Update the nova configuration file <para>Update the nova configuration file
<filename>/etc/nova/nova.conf</filename>:</para> <filename>/etc/nova/nova.conf</filename>:</para>
<programlisting language="ini">[DEFAULT] <programlisting language="ini">[DEFAULT]
@ -174,22 +130,17 @@ neutron_auth_strategy=keystone
neutron_admin_tenant_name=servicetenant neutron_admin_tenant_name=servicetenant
neutron_url=http://100.1.1.10:9696/ neutron_url=http://100.1.1.10:9696/
firewall_driver=nova.virt.firewall.NoopFirewallDriver</programlisting> firewall_driver=nova.virt.firewall.NoopFirewallDriver</programlisting>
</listitem> </step>
</orderedlist> </procedure>
</listitem> <procedure>
<listitem> <title>HostA and HostB&#151;DHCP Agent</title>
<para><emphasis role="bold">HostA and HostB - DHCP <step>
Agent</emphasis></para>
<orderedlist>
<listitem>
<para>Update the DHCP configuration file <para>Update the DHCP configuration file
<filename>/etc/neutron/dhcp_agent.ini</filename>:</para> <filename>/etc/neutron/dhcp_agent.ini</filename>:</para>
<programlisting language="ini">[DEFAULT] <programlisting language="ini">[DEFAULT]
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver</programlisting> interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver</programlisting>
</listitem> </step>
</orderedlist> </procedure>
</listitem>
</itemizedlist>
</section> </section>
<section xml:id="demo_multiple_operation"> <section xml:id="demo_multiple_operation">
<title>Commands in agent management and scheduler <title>Commands in agent management and scheduler
@ -205,10 +156,9 @@ export OS_PASSWORD=adminpassword
export OS_TENANT_NAME=admin export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting> export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
</note> </note>
<itemizedlist> <procedure>
<listitem> <title>Settings</title>
<para><emphasis role="bold">Settings</emphasis></para> <step><para>To experiment, you need VMs and a neutron
<para>To experiment, you need VMs and a neutron
network:</para> network:</para>
<screen><prompt>$</prompt> <userinput>nova list</userinput> <screen><prompt>$</prompt> <userinput>nova list</userinput>
<computeroutput>+--------------------------------------+-----------+--------+---------------+ <computeroutput>+--------------------------------------+-----------+--------+---------------+
@ -225,15 +175,14 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
+--------------------------------------+------+--------------------------------------+ +--------------------------------------+------+--------------------------------------+
| 89dca1c6-c7d4-4f7a-b730-549af0fb6e34 | net1 | f6c832e3-9968-46fd-8e45-d5cf646db9d1 | | 89dca1c6-c7d4-4f7a-b730-549af0fb6e34 | net1 | f6c832e3-9968-46fd-8e45-d5cf646db9d1 |
+--------------------------------------+------+--------------------------------------+</computeroutput></screen> +--------------------------------------+------+--------------------------------------+</computeroutput></screen>
</listitem> </step>
<listitem> </procedure>
<para><emphasis role="bold">Manage agents in neutron <procedure>
deployment</emphasis></para> <title>Manage agents in neutron deployment</title>
<para>Every agent which supports these extensions will <para>Every agent which supports these extensions will
register itself with the neutron server when it register itself with the neutron server when it
starts up.</para> starts up.</para>
<orderedlist> <step>
<listitem>
<para>List all agents:</para> <para>List all agents:</para>
<screen><prompt>$</prompt> <userinput>neutron agent-list</userinput> <screen><prompt>$</prompt> <userinput>neutron agent-list</userinput>
<computeroutput>+--------------------------------------+--------------------+-------+-------+----------------+ <computeroutput>+--------------------------------------+--------------------+-------+-------+----------------+
@ -255,8 +204,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
<filename>neutron.conf</filename> <filename>neutron.conf</filename>
file. Otherwise the <option>alive</option> file. Otherwise the <option>alive</option>
is <literal>xxx</literal>.</para> is <literal>xxx</literal>.</para>
</listitem> </step>
<listitem> <step>
<para>List the DHCP agents that host a <para>List the DHCP agents that host a
specified network</para> specified network</para>
<para>In some deployments, one DHCP agent is <para>In some deployments, one DHCP agent is
@ -275,8 +224,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
| a0c1c21c-d4f4-4577-9ec7-908f2d48622d | HostA | True | :-) | | a0c1c21c-d4f4-4577-9ec7-908f2d48622d | HostA | True | :-) |
+--------------------------------------+-------+----------------+-------+ +--------------------------------------+-------+----------------+-------+
</computeroutput></screen> </computeroutput></screen>
</listitem> </step>
<listitem> <step>
<para>List the networks hosted by a given DHCP <para>List the networks hosted by a given DHCP
agent.</para> agent.</para>
<para>This command is to show which networks a <para>This command is to show which networks a
@ -288,8 +237,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
| 89dca1c6-c7d4-4f7a-b730-549af0fb6e34 | net1 | f6c832e3-9968-46fd-8e45-d5cf646db9d1 10.0.1.0/24 | | 89dca1c6-c7d4-4f7a-b730-549af0fb6e34 | net1 | f6c832e3-9968-46fd-8e45-d5cf646db9d1 10.0.1.0/24 |
+--------------------------------------+------+---------------------------------------------------+ +--------------------------------------+------+---------------------------------------------------+
</computeroutput></screen> </computeroutput></screen>
</listitem> </step>
<listitem> <step>
<para>Show agent details.</para> <para>Show agent details.</para>
<para>The <command>agent-list</command> <para>The <command>agent-list</command>
command shows details for a specified command shows details for a specified
@ -358,19 +307,16 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
<literal>bridge-mapping</literal> and <literal>bridge-mapping</literal> and
the number of virtual network devices on the number of virtual network devices on
this L2 agent.</para> this L2 agent.</para>
</listitem> </step>
</orderedlist> </procedure>
</listitem> <procedure>
<listitem> <title>Manage assignment of networks to DHCP agent</title>
<para><emphasis role="bold">Manage assignment of
networks to DHCP agent</emphasis></para>
<para>Now that you have run the <para>Now that you have run the
<command>net-list-on-dhcp-agent</command> and <command>net-list-on-dhcp-agent</command> and
<command>dhcp-agent-list-hosting-net</command> <command>dhcp-agent-list-hosting-net</command>
commands, you can add a network to a DHCP agent commands, you can add a network to a DHCP agent
and remove one from it.</para> and remove one from it.</para>
<orderedlist> <step>
<listitem>
<para>Default scheduling.</para> <para>Default scheduling.</para>
<para>When you create a network with one port, <para>When you create a network with one port,
you can schedule it to an active DHCP you can schedule it to an active DHCP
@ -398,8 +344,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
<systemitem class="service" <systemitem class="service"
>dnsmasq</systemitem> service only if >dnsmasq</systemitem> service only if
there is a DHCP.</para> there is a DHCP.</para>
</listitem> </step>
<listitem> <step>
<para>Assign a network to a given DHCP <para>Assign a network to a given DHCP
agent.</para> agent.</para>
<para>To add another DHCP agent to host the <para>To add another DHCP agent to host the
@ -416,8 +362,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
<para>Both DHCP agents host the <para>Both DHCP agents host the
<literal>net2</literal> <literal>net2</literal>
network.</para> network.</para>
</listitem> </step>
<listitem> <step>
<para>Remove a network from a specified DHCP <para>Remove a network from a specified DHCP
agent.</para> agent.</para>
<para>This command is the sibling command for <para>This command is the sibling command for
@ -436,18 +382,15 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
HostB is hosting the HostB is hosting the
<literal>net2</literal> <literal>net2</literal>
network.</para> network.</para>
</listitem> </step>
</orderedlist> </procedure>
</listitem> <procedure>
<listitem> <title>HA of DHCP agents</title>
<para><emphasis role="bold">HA of DHCP
agents</emphasis></para>
<para>Boot a VM on net2. Let both DHCP agents host <para>Boot a VM on net2. Let both DHCP agents host
<literal>net2</literal>. Fail the agents in <literal>net2</literal>. Fail the agents in
turn to see if the VM can still get the desired turn to see if the VM can still get the desired
IP.</para> IP.</para>
<orderedlist> <step>
<listitem>
<para>Boot a VM on net2.</para> <para>Boot a VM on net2.</para>
<screen><prompt>$</prompt> <userinput>neutron net-list</userinput> <screen><prompt>$</prompt> <userinput>neutron net-list</userinput>
<computeroutput>+--------------------------------------+------+--------------------------------------------------+ <computeroutput>+--------------------------------------+------+--------------------------------------------------+
@ -467,8 +410,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
| c7c0481c-3db8-4d7a-a948-60ce8211d585 | myserver3 | ACTIVE | net1=10.0.1.5 | | c7c0481c-3db8-4d7a-a948-60ce8211d585 | myserver3 | ACTIVE | net1=10.0.1.5 |
| f62f4731-5591-46b1-9d74-f0c901de567f | myserver4 | ACTIVE | net2=9.0.1.2 | | f62f4731-5591-46b1-9d74-f0c901de567f | myserver4 | ACTIVE | net2=9.0.1.2 |
+--------------------------------------+-----------+--------+---------------+</computeroutput></screen> +--------------------------------------+-----------+--------+---------------+</computeroutput></screen>
</listitem> </step>
<listitem> <step>
<para>Make sure both DHCP agents hosting <para>Make sure both DHCP agents hosting
'net2'.</para> 'net2'.</para>
<para>Use the previous commands to assign the <para>Use the previous commands to assign the
@ -480,10 +423,10 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
| a0c1c21c-d4f4-4577-9ec7-908f2d48622d | HostA | True | :-) | | a0c1c21c-d4f4-4577-9ec7-908f2d48622d | HostA | True | :-) |
| f28aa126-6edb-4ea5-a81e-8850876bc0a8 | HostB | True | :-) | | f28aa126-6edb-4ea5-a81e-8850876bc0a8 | HostB | True | :-) |
+--------------------------------------+-------+----------------+-------+</computeroutput></screen> +--------------------------------------+-------+----------------+-------+</computeroutput></screen>
</listitem> </step>
<listitem> </procedure>
<procedure> <procedure>
<title>To test the HA</title> <title>Test the HA</title>
<step> <step>
<para>Log in to the <para>Log in to the
<literal>myserver4</literal> VM, <literal>myserver4</literal> VM,
@ -518,11 +461,8 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
VM gets the wanted IP again.</para> VM gets the wanted IP again.</para>
</step> </step>
</procedure> </procedure>
</listitem> <procedure>
</orderedlist> <title>Disable and remove an agent</title>
</listitem>
<listitem>
<para>Disable and remove an agent</para>
<para>An administrator might want to disable an agent <para>An administrator might want to disable an agent
if a system hardware or software upgrade is if a system hardware or software upgrade is
planned. Some agents that support scheduling also planned. Some agents that support scheduling also
@ -532,7 +472,7 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
agent. After the agent is disabled, you can safely agent. After the agent is disabled, you can safely
remove the agent. Remove the resources on the remove the agent. Remove the resources on the
agent before you delete the agent.</para> agent before you delete the agent.</para>
<para>To run the following commands, you must stop the <step><para>To run the following commands, you must stop the
DHCP agent on HostA.</para> DHCP agent on HostA.</para>
<screen><prompt>$</prompt> <userinput>neutron agent-update --admin-state-up False a0c1c21c-d4f4-4577-9ec7-908f2d48622d</userinput> <screen><prompt>$</prompt> <userinput>neutron agent-update --admin-state-up False a0c1c21c-d4f4-4577-9ec7-908f2d48622d</userinput>
<prompt>$</prompt> <userinput>neutron agent-list</userinput> <prompt>$</prompt> <userinput>neutron agent-list</userinput>
@ -556,7 +496,7 @@ export OS_AUTH_URL=http://controlnode:5000/v2.0/</programlisting>
+--------------------------------------+--------------------+-------+-------+----------------+</computeroutput></screen> +--------------------------------------+--------------------+-------+-------+----------------+</computeroutput></screen>
<para>After deletion, if you restart the DHCP agent, <para>After deletion, if you restart the DHCP agent,
it appears on the agent list again.</para> it appears on the agent list again.</para>
</listitem> </step>
</itemizedlist> </procedure>
</section> </section>
</section> </section>

223
doc/config-reference/networking/section_networking-scenarios.xml → doc/admin-guide-cloud/section_networking-scenarios.xml
View File

@ -9,8 +9,8 @@
<section xml:id="under_the_hood_openvswitch"> <section xml:id="under_the_hood_openvswitch">
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>Open vSwitch</title> <title>Open vSwitch</title>
<para>This section describes how the Open vSwitch plug-in implements the OpenStack <para>This section describes how the Open vSwitch plug-in implements the Networking
Networking abstractions.</para> abstractions.</para>
<section xml:id="under_the_hood_openvswitch_configuration"> <section xml:id="under_the_hood_openvswitch_configuration">
<title>Configuration</title> <title>Configuration</title>
<para>This example uses VLAN isolation on the switches to isolate tenant networks. This <para>This example uses VLAN isolation on the switches to isolate tenant networks. This
@ -35,7 +35,7 @@ bridge_mappings = physnet2:br-eth1</programlisting></para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>Under the <literal>service</literal> tenant, create the shared router, define the <para>Under the <literal>service</literal> tenant, create the shared router, define the
@ -76,7 +76,7 @@ bridge_mappings = physnet2:br-eth1</programlisting></para>
</para> </para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1-ovs-compute.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1-ovs-compute.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
@ -97,11 +97,10 @@ bridge_mappings = physnet2:br-eth1</programlisting></para>
is how hypervisors such as KVM and Xen implement a virtual network interface card 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 (typically called a VIF or vNIC). An ethernet frame sent to a TAP device is received
by the guest operating system.</para> by the guest operating system.</para>
<para>A <emphasis role="italic">veth pair</emphasis> is a pair of virtual network <para>A <emphasis role="italic">veth pair</emphasis> is a pair of directly connected
interfaces correctly directly together. An ethernet frame sent to one end of a veth virtual network interfaces. An ethernet frame sent to one end of a veth pair
pair is received by the other end of a veth pair. OpenStack networking makes use of is received by the other end of a veth pair. Networking uses veth pairs as
veth pairs as virtual patch cables in order to make connections between virtual virtual patch cables to make connections between virtual bridges.</para>
bridges.</para>
<para>A <emphasis role="italic">Linux bridge</emphasis> behaves like a hub: you can <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. 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 Any ethernet frames that come in from one interface attached to the bridge is
@ -113,8 +112,8 @@ bridge_mappings = physnet2:br-eth1</programlisting></para>
</simplesect> </simplesect>
<simplesect> <simplesect>
<title>Integration bridge</title> <title>Integration bridge</title>
<para>The <literal>br-int</literal> OpenvSwitch bridge is the integration bridge: all of <para>The <literal>br-int</literal> OpenvSwitch bridge is the integration bridge: all
the guests running on the compute host connect to this bridge. OpenStack Networking guests running on the compute host connect to this bridge. Networking
implements isolation across these guests by configuring the implements isolation across these guests by configuring the
<literal>br-int</literal> ports.</para> <literal>br-int</literal> ports.</para>
</simplesect> </simplesect>
@ -141,12 +140,12 @@ bridge_mappings = physnet2:br-eth1</programlisting></para>
<para>Ideally, the TAP device <literal>vnet0</literal> would be connected directly to <para>Ideally, the TAP device <literal>vnet0</literal> would be connected directly to
the integration bridge, <literal>br-int</literal>. Unfortunately, this isn't the integration bridge, <literal>br-int</literal>. Unfortunately, this isn't
possible because of how OpenStack security groups are currently implemented. possible because of how OpenStack security groups are currently implemented.
OpenStack uses iptables rules on the TAP devices such as <literal>vnet0</literal> to OpenStack uses iptables rules on the TAP devices such as
implement security groups, and Open vSwitch is not compatible with iptables rules <literal>vnet0</literal> to implement security groups, and Open vSwitch
that are applied directly on TAP devices that are connected to an Open vSwitch is not compatible with iptables rules that are applied directly on TAP
port.</para> devices that are connected to an Open vSwitch port.</para>
<para>OpenStack Networking uses an extra Linux bridge and a veth pair as a workaround for <para>Networking uses an extra Linux bridge and a veth pair as a workaround for this
this issue. Instead of connecting <literal>vnet0</literal> to an Open vSwitch issue. Instead of connecting <literal>vnet0</literal> to an Open vSwitch
bridge, it is connected to a Linux bridge, bridge, it is connected to a Linux bridge,
<literal>qbr<replaceable>XXX</replaceable></literal>. This bridge is <literal>qbr<replaceable>XXX</replaceable></literal>. This bridge is
connected to the integration bridge, <literal>br-int</literal>, through the connected to the integration bridge, <literal>br-int</literal>, through the
@ -170,7 +169,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
The following figure shows the network devices on the network host:</para> The following figure shows the network devices on the network host:</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1-ovs-network.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1-ovs-network.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>As on the compute host, there is an Open vSwitch integration bridge <para>As on the compute host, there is an Open vSwitch integration bridge
@ -187,99 +186,103 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
packets traverse that veth pair in this example.</para></note> packets traverse that veth pair in this example.</para></note>
<simplesect><title>Open vSwitch internal ports</title> <simplesect><title>Open vSwitch internal ports</title>
<para>The network host uses Open vSwitch <emphasis role="italic">internal <para>The network host uses Open vSwitch <emphasis role="italic">internal
ports</emphasis>. Internal ports enable you to assign one ports</emphasis>. Internal ports enable you to assign one or more IP
or more IP addresses to an Open vSwitch bridge. In previous example, the addresses to an Open vSwitch bridge. In previous example, the
<literal>br-int</literal> bridge has four internal <literal>br-int</literal> bridge has four internal ports:
ports: <literal>tap<replaceable>XXX</replaceable></literal>, <literal>tap<replaceable>XXX</replaceable></literal>,
<literal>qr-<replaceable>YYY</replaceable></literal>, <literal>qr-<replaceable>YYY</replaceable></literal>,
<literal>qr-<replaceable>ZZZ</replaceable></literal>, <literal>qr-<replaceable>ZZZ</replaceable></literal>, and
<literal>tap<replaceable>WWW</replaceable></literal>. Each internal port has <literal>tap<replaceable>WWW</replaceable></literal>. Each internal
a separate IP address associated with it. An internal port, port has a separate IP address associated with it. An internal port,
<literal>qg-VVV</literal>, is on the <literal>br-ex</literal> bridge.</para> <literal>qg-VVV</literal>, is on the <literal>br-ex</literal>
bridge.</para>
</simplesect> </simplesect>
<simplesect><title>DHCP agent</title> <simplesect><title>DHCP agent</title>
<para>By default, The OpenStack Networking DHCP agent uses a program called dnsmasq <para>By default, The Networking DHCP agent uses a process called dnsmasq to provide
to provide DHCP services to guests. OpenStack Networking must create an internal DHCP services to guests. Networking must create an internal port for each
port for each network that requires DHCP services and attach a dnsmasq process to network that requires DHCP services and attach a dnsmasq process to that
that port. In the previous example, the interface port. In the previous example, the
<literal>tap<replaceable>XXX</replaceable></literal> is on subnet <literal>tap<replaceable>XXX</replaceable></literal> interface is on
<literal>net01_subnet01</literal>, and the interface <literal>net01_subnet01</literal>, and the
<literal>tap<replaceable>WWW</replaceable></literal> is on <literal>tap<replaceable>WWW</replaceable></literal> interface is on
<literal>net02_subnet01</literal>.</para> <literal>net02_subnet01</literal>.</para>
</simplesect> </simplesect>
<simplesect> <simplesect>
<title>L3 agent (routing)</title> <title>L3 agent (routing)</title>
<para>The OpenStack Networking L3 agent implements routing through the use of Open <para>The Networking L3 agent uses Open vSwitch internal ports to implement routing and
vSwitch internal ports and relies on the network host to route the packets across relies on the network host to route the packets across the interfaces. In
the interfaces. In this example: interface<literal>qr-YYY</literal>, which is on this example, the <literal>qr-YYY</literal> interface is on
subnet <literal>net01_subnet01</literal>, has an IP address of 192.168.101.1/24, <literal>net01_subnet01</literal> and has the IP address
interface <literal>qr-<replaceable>ZZZ</replaceable></literal>, which is on subnet 192.168.101.1/24. The <literal>qr-<replaceable>ZZZ</replaceable></literal>,
<literal>net02_subnet01</literal>, has an IP address of interface is on <literal>net02_subnet01</literal> and has the IP address
<literal>192.168.102.1/24</literal>, and interface <literal>192.168.102.1/24</literal>. The
<literal>qg-<replaceable>VVV</replaceable></literal>, which has an IP <literal>qg-<replaceable>VVV</replaceable></literal> interface has
address of <literal>10.64.201.254/24</literal>. Because of each of these interfaces the IP address <literal>10.64.201.254/24</literal>. Because each of these
is visible to the network host operating system, it will route the packets interfaces is visible to the network host operating system, the network host
appropriately across the interfaces, as long as an administrator has enabled IP routes the packets across the interfaces, as long as an administrator has
forwarding.</para> enabled IP forwarding.</para>
<para>The L3 agent uses iptables to implement floating IPs to do the network address <para>The L3 agent uses iptables to implement floating IPs to do the network address
translation (NAT).</para> translation (NAT).</para>
</simplesect> </simplesect>
<simplesect> <simplesect>
<title>Overlapping subnets and network namespaces</title> <title>Overlapping subnets and network namespaces</title>
<para>One problem with using the host to implement routing is that there is a chance <para>One problem with using the host to implement routing is that one of the
that one of the OpenStack Networking subnets might overlap with one of the physical Networking subnets might overlap with one of the physical networks that the
networks that the host uses. For example, if the management network is implemented host uses. For example, if the management network is implemented on
on <literal>eth2</literal> (not shown in the previous example), by coincidence happens <literal>eth2</literal> and also happens to be on the
to also be on the <literal>192.168.101.0/24</literal> subnet, then this will cause <literal>192.168.101.0/24</literal> subnet, routing problems will occur
routing problems because it is impossible ot determine whether a packet on this because the host can't determine whether to send a packet on this subnet to
subnet should be sent to <literal>qr-YYY</literal> or <literal>eth2</literal>. In <literal>qr-YYY</literal> or <literal>eth2</literal>. If end users are
general, if end-users are permitted to create their own logical networks and permitted to create their own logical networks and subnets, you must design
subnets, then the system must be designed to avoid the possibility of such 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> collisions.</para>
<para>OpenStack 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 you will see
in the next scenario.</para>
<para>A network namespace can be thought of as an isolated environment that has its own
networking stack. A network namespace has its own network interfaces, routes, and
iptables rules. You can think of like a chroot jail, except for networking instead
of a file system. As an aside, LXC (Linux containers) use network namespaces to
implement networking virtualization.</para>
<para>OpenStack Networking creates network namespaces on the network host in order
to avoid subnet collisions.</para>
<para>Tn this example, there are three network namespaces, as depicted in the following figure.<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>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1-ovs-netns.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1-ovs-netns.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </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> </simplesect>
</section> </section>
</section> </section>
@ -292,7 +295,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
</para> </para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>Under the <literal>service</literal> tenant, define the public <para>Under the <literal>service</literal> tenant, define the public
@ -334,7 +337,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
</para> </para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2-ovs-compute.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2-ovs-compute.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<note><para>The Compute host configuration resembles the <note><para>The Compute host configuration resembles the
@ -349,7 +352,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
scenario.</para> scenario.</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2-ovs-network.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2-ovs-network.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>In this configuration, the network namespaces are <para>In this configuration, the network namespaces are
@ -358,7 +361,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
</para> </para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2-ovs-netns.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2-ovs-netns.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>In this scenario, there are four network namespaces <para>In this scenario, there are four network namespaces
@ -373,8 +376,8 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1</programlisting>
</section> </section>
<section xml:id="under_the_hood_linuxbridge"> <section xml:id="under_the_hood_linuxbridge">
<title>Linux Bridge</title> <title>Linux Bridge</title>
<para>This section describes how the Linux Bridge plug-in implements the OpenStack <para>This section describes how the Linux Bridge plug-in implements the Networking
Networking abstractions. For information about DHCP and L3 agents, see <xref abstractions. For information about DHCP and L3 agents, see <xref
linkend="under_the_hood_openvswitch_scenario1"/>.</para> linkend="under_the_hood_openvswitch_scenario1"/>.</para>
<section xml:id="under_the_hood_linuxbridge_configuration"> <section xml:id="under_the_hood_linuxbridge_configuration">
<title>Configuration</title> <title>Configuration</title>
@ -400,7 +403,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>Under the <literal>service</literal> tenant, create the shared router, define the <para>Under the <literal>service</literal> tenant, create the shared router, define the
@ -440,7 +443,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
</para> </para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1-linuxbridge-compute.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1-linuxbridge-compute.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
@ -478,14 +481,14 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
<para>The following figure shows the network devices on the network host.</para> <para>The following figure shows the network devices on the network host.</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1-linuxbridge-network.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1-linuxbridge-network.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>The following figure shows how the Linux Bridge plug-in uses network namespaces to <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 provide isolation.</para><note><para>veth pairs form connections between the
Linux bridges and the network namespaces.</para></note><mediaobject> Linux bridges and the network namespaces.</para></note><mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-1-linuxbridge-netns.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-1-linuxbridge-netns.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
</section> </section>
@ -497,7 +500,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
Internet.</para> Internet.</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>Under the <literal>service</literal> tenant, define the public <para>Under the <literal>service</literal> tenant, define the public
@ -540,7 +543,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
</para> </para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2-linuxbridge-compute.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2-linuxbridge-compute.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<note><para>The configuration on the compute host is very similar to the configuration in scenario 1. The <note><para>The configuration on the compute host is very similar to the configuration in scenario 1. The
@ -553,7 +556,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
scenario.</para> scenario.</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2-linuxbridge-network.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2-linuxbridge-network.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>The main difference between the configuration in this scenario and the previous one <para>The main difference between the configuration in this scenario and the previous one
@ -561,7 +564,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
across the two subnets, as shown in the following figure.</para> across the two subnets, as shown in the following figure.</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/under-the-hood-scenario-2-linuxbridge-netns.png" contentwidth="6in"/> <imagedata fileref="../common/figures/under-the-hood-scenario-2-linuxbridge-netns.png" contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
<para>In this scenario, there are four network namespaces <para>In this scenario, there are four network namespaces
@ -592,7 +595,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
illustrated below.</para> illustrated below.</para>
<mediaobject> <mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/ml2_without_l2pop_full_mesh.png" <imagedata fileref="../common/figures/ml2_without_l2pop_full_mesh.png"
contentwidth="6in"/> contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject> </mediaobject>
@ -602,7 +605,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
This is achieved by sending broadcasts packets over unicasts only to the relevant This is achieved by sending broadcasts packets over unicasts only to the relevant
agents as illustrated below.<mediaobject> agents as illustrated below.<mediaobject>
<imageobject> <imageobject>
<imagedata fileref="../../common/figures/ml2_without_l2pop_partial_mesh.png" <imagedata fileref="../common/figures/ml2_without_l2pop_partial_mesh.png"
contentwidth="6in"/> contentwidth="6in"/>
</imageobject> </imageobject>
</mediaobject>The partial-mesh is available with the <emphasis>Open vSwitch</emphasis> and </mediaobject>The partial-mesh is available with the <emphasis>Open vSwitch</emphasis> and

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

@ -233,7 +233,7 @@
actions for users with the admin role. An authorized actions for users with the admin role. An authorized
client or an administrative user can view and set the client or an administrative user can view and set the
provider extended attributes through Networking API provider extended attributes through Networking API
calls. See <xref linkend="section_auth"/> for details calls. See <xref linkend="section_networking_auth"/> for details
on policy configuration.</para> on policy configuration.</para>
</section> </section>
<section xml:id="provider_api_workflow"> <section xml:id="provider_api_workflow">

13
doc/config-reference/ch_networkingconfigure.xml
View File

@ -8,12 +8,11 @@
xmlns:ns3="http://www.w3.org/1998/Math/MathML" xmlns:ns3="http://www.w3.org/1998/Math/MathML"
xmlns:ns="http://docbook.org/ns/docbook"> xmlns:ns="http://docbook.org/ns/docbook">
<title>Networking</title> <title>Networking</title>
<para>This chapter explains the configuration options and scenarios for OpenStack Networking. <para>This chapter explains the OpenStack Networking configuration options. For installation
For installation prerequisites, steps, and use cases, refer to corresponding chapter in the prerequisites, steps, and use cases, see the <citetitle>OpenStack Installation
<emphasis role="italic">OpenStack Installation Guide</emphasis>.</para> Guide</citetitle> for your distribution (<link xlink:href="docs.openstack.org"
>docs.openstack.org</link>) and <citetitle><link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/">Cloud
Administrator Guide</link></citetitle>.</para>
<xi:include href="networking/section_networking-options-reference.xml"/> <xi:include href="networking/section_networking-options-reference.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"/>
</chapter> </chapter>