[networking] Reorganize content
Reorganize content as follows: 1) Move topics from "advanced configuration" to "configuration" in an attempt to increase adoption of such features by decreasing mental barriers. 2) Add missing references to top of files. 3) Add notes for experimental features and/or those with incomplete documentation. 4) Fix some consistency issues between titles and file names. 5) Fix some consistency issues with introductory content. 6) Concatenate introductory content, at least temporarily. 7) Remove files lacking content and placeholders to reduce the "beta" feel. I will add the appropriate HTTP redirects for the defunct files after we sufficiently agree on the reorganization. Change-Id: Ie667251bcbe77bd1ec59ef5811aed4c499f765e7 backport: mitaka
This commit is contained in:
Matthew Kassawara
parent
66f817cab7
commit
059d540028
doc/networking-guide/source
adv-config-debugging.rstadv-config-fwaas.rstadv-config-group-policy.rstadv-config-vpnaas.rstadv-config.rstconfig-address-scopes.rstconfig-auto-allocation.rstconfig-az.rstconfig-bgp-dynamic-routing.rstconfig-dhcp-ha.rstconfig-dns-int.rstconfig-dns-res.rstconfig-dvr-ha-snat.rstconfig-ipam.rstconfig-ipv6.rstconfig-lbaas.rstconfig-ml2.rstconfig-mtu.rstconfig-ovsfwdriver.rstconfig-qos.rstconfig-rbac.rstconfig-server.rstconfig-sfc.rstconfig-sriov.rstconfig-subnet-pools.rstconfig.rstdeploy.rstindex.rstintro-basic-networking.rstintro-nat.rstintro-network-components.rstintro-network-namespaces.rstintro-os-networking-overview.rstintro-os-networking-service.rstintro-os-networking.rstintro-overlay-protocols.rstintro.rstmigration-classic-to-dvr.rstmigration-classic-to-l3ha.rstmigration-database.rstmigration-nova-network-to-neutron.rstmigration.rstmisc-libvirt.rstmisc.rstmiscellaneous.rstops-ip-availability.rstops-resource-purge.rstops-resource-tags.rstops.rstscenario-classic-lb.rstscenario-classic-mt.rstscenario-classic-ovs.rstscenario-dvr-ovs.rstscenario-l3ha-lb.rstscenario-l3ha-ovs.rstscenario-provider-lb.rstscenario-provider-ovs.rst
@ -1,56 +0,0 @@
|
||||
=========
|
||||
Debugging
|
||||
=========
|
||||
|
||||
The OpenStack Networking service offers many degrees of freedom because
|
||||
of the pluggable back end that supports a variety of open source and
|
||||
vendor (proprietary) plug-ins. The open source plug-ins generally implement
|
||||
native Linux facilities such as Open vSwitch (OVS) and Linux bridge. This
|
||||
section provides methods to troubleshoot and mitigate network issues for
|
||||
environments using the open source ML2 plug-in with the OVS or Linux bridge
|
||||
agent.
|
||||
|
||||
Neutron-debug command line tools
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Network troubleshooting can unfortunately be a very difficult and
|
||||
confusing procedure. A network issue can cause a problem at several
|
||||
points in the cloud. Using a logical troubleshooting procedure can
|
||||
help mitigate the confusion and quickly isolate the network issue.
|
||||
|
||||
Some of the following sections reference these popular tools to understand
|
||||
both network configuration and traffic patterns:
|
||||
|
||||
#. iproute2
|
||||
#. tcpdump
|
||||
#. iptables
|
||||
|
||||
Neutron-debug command line tools
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Subsection ...
|
||||
|
||||
Network configuration in the database
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Subsection ...
|
||||
|
||||
Debugging DHCP Issues
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Subsection ...
|
||||
|
||||
Debugging DNS Issues
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Subsection ...
|
||||
|
||||
Network namespaces configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Subsection ...
|
||||
|
||||
Summary
|
||||
~~~~~~~
|
||||
|
||||
Subsection ...
|
||||
@ -1,7 +0,0 @@
|
||||
=====
|
||||
FWaaS
|
||||
=====
|
||||
|
||||
See the following URL:
|
||||
|
||||
http://docs.openstack.org/admin-guide/networking_introduction.html#firewall-as-a-service-fwaas-overview
|
||||
@ -1,14 +0,0 @@
|
||||
============
|
||||
Group policy
|
||||
============
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
How it differs from legacy neutron data model
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
@ -1,8 +0,0 @@
|
||||
======
|
||||
VPNaaS
|
||||
======
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
|
||||
@ -1,28 +0,0 @@
|
||||
======================
|
||||
Advanced configuration
|
||||
======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
adv-config-mtu.rst
|
||||
adv-config-dvr-ha-snat.rst
|
||||
adv-config-rbac.rst
|
||||
adv-config-subnet-pools.rst
|
||||
adv-config-address-scopes.rst
|
||||
adv-config-ovsfwdriver.rst
|
||||
adv-config-lbaas.rst
|
||||
adv-config-fwaas.rst
|
||||
adv-config-vpnaas.rst
|
||||
adv-config-sfc.rst
|
||||
adv-config-qos.rst
|
||||
adv-config-group-policy.rst
|
||||
adv-config-debugging.rst
|
||||
adv-config-ipv6.rst
|
||||
adv-config-sriov.rst
|
||||
adv-config-ipam.rst
|
||||
adv-config-availability-zone.rst
|
||||
adv-config-bgp-dynamic-routing.rst
|
||||
adv-config-dns.rst
|
||||
adv-config-net-ip-availability.rst
|
||||
adv-config-tag.rst
|
||||
@ -1,13 +1,9 @@
|
||||
.. _config-address-scopes:
|
||||
|
||||
==============
|
||||
Address scopes
|
||||
==============
|
||||
|
||||
This page serves as an introduction to the address scopes feature of the
|
||||
Networking service.
|
||||
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
|
||||
Address scopes build from subnet pools. While subnet pools provide a mechanism
|
||||
for controlling the allocation of addresses to subnets, address scopes show
|
||||
where addresses can be routed between networks, preventing the use of
|
||||
@ -1,9 +1,8 @@
|
||||
===================
|
||||
Additional features
|
||||
===================
|
||||
.. _config-auto-allocation:
|
||||
|
||||
Auto-allocation of network topologies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
==========================================
|
||||
Automatic allocation of network topologies
|
||||
==========================================
|
||||
|
||||
The auto-allocation feature introduced in Mitaka simplifies the procedure of
|
||||
setting up an external connectivity for end-users, and is also known as **Get
|
||||
@ -1,13 +1,8 @@
|
||||
=======================
|
||||
Using availability zone
|
||||
=======================
|
||||
.. _config-az:
|
||||
|
||||
This page serves as a guide for how to use the ``Availability Zone``
|
||||
functionality available in the Networking service as of the Mitaka release.
|
||||
|
||||
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
==================
|
||||
Availability zones
|
||||
==================
|
||||
|
||||
An availability zone groups network nodes that run services like DHCP, L3, FW,
|
||||
and others. It is defined as an agent's attribute on the network node. This
|
||||
@ -1,4 +1,4 @@
|
||||
.. _adv-config-bgp-dynamic-routing:
|
||||
.. _config-bgp-dynamic-routing:
|
||||
|
||||
===================
|
||||
BGP dynamic routing
|
||||
@ -1,6 +1,8 @@
|
||||
=================================
|
||||
Adding high availability for DHCP
|
||||
=================================
|
||||
.. _config-dhcp-ha:
|
||||
|
||||
==========================
|
||||
High-availability for DHCP
|
||||
==========================
|
||||
|
||||
This section describes how to use the agent management (alias agent) and
|
||||
scheduler (alias agent_scheduler) extensions for DHCP agents
|
||||
@ -1,8 +1,8 @@
|
||||
.. _adv-config-dns:
|
||||
.. _config-dns-int:
|
||||
|
||||
=======================================
|
||||
DNS integration in OpenStack Networking
|
||||
=======================================
|
||||
===============
|
||||
DNS integration
|
||||
===============
|
||||
|
||||
This page serves as a guide for how to use the DNS integration functionality of
|
||||
the Networking service. The functionality described covers DNS from two points
|
||||
@ -13,9 +13,6 @@ of view:
|
||||
* Integration of the Compute service and the Networking service with an
|
||||
external DNSaaS (DNS-as-a-Service).
|
||||
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
|
||||
Users can control the behavior of the Networking service in regards to DNS
|
||||
using two attributes associated with ports, networks, and floating IPs. The
|
||||
following table shows the attributes available for each one of these resources:
|
||||
@ -37,7 +34,7 @@ following table shows the attributes available for each one of these resources:
|
||||
- Yes
|
||||
- Yes
|
||||
|
||||
.. _adv-config-dns-int-dns-resolution:
|
||||
.. _config-dns-int-dns-resolution:
|
||||
|
||||
The Networking service internal DNS resolution
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -67,7 +64,7 @@ After re-starting the ``neutron-server``, users will be able to assign a
|
||||
.. note::
|
||||
The enablement of this functionality is prerequisite for the enablement of
|
||||
the Networking service integration with an external DNS service, which is
|
||||
described in detail in :ref:`adv-config-dns-int-ext-serv`.
|
||||
described in detail in :ref:`config-dns-int-ext-serv`.
|
||||
|
||||
The following illustrates the creation of a port with ``my-port``
|
||||
in its ``dns_name`` attribute.
|
||||
@ -205,12 +202,12 @@ Users can also integrate the Networking and Compute services with an external
|
||||
DNS. To accomplish this, the users have to:
|
||||
|
||||
#. Enable the functionality described in
|
||||
:ref:`adv-config-dns-int-dns-resolution`.
|
||||
:ref:`config-dns-int-dns-resolution`.
|
||||
#. Configure an external DNS driver. The Networking service provides a driver
|
||||
reference implementation based on the OpenStack DNS service. It is expected
|
||||
that third party vendors will provide other implementations in the future.
|
||||
For detailed configuration instructions, see
|
||||
:ref:`adv-config-dns-int-ext-serv`.
|
||||
:ref:`config-dns-int-ext-serv`.
|
||||
|
||||
Once the ``neutron-server`` has been configured and restarted, users will have
|
||||
functionality that covers three use cases, described in the following sections.
|
||||
@ -223,9 +220,9 @@ In each of the use cases described below:
|
||||
created. For the description of the use cases below, it is assumed the zone
|
||||
``example.org.`` was created previously.
|
||||
* The PTR records will be created in zones owned by a project with admin
|
||||
privileges. See :ref:`adv-config-dns-int-ext-serv` for more details.
|
||||
privileges. See :ref:`config-dns-int-ext-serv` for more details.
|
||||
|
||||
.. _adv-config-dns-use-case-1:
|
||||
.. _config-dns-use-case-1:
|
||||
|
||||
Use case 1: Ports are published directly in the external DNS service
|
||||
--------------------------------------------------------------------
|
||||
@ -375,13 +372,13 @@ In this example the port is created manually by the user and then used to boot
|
||||
an instance. Notice that:
|
||||
|
||||
* The port's data was visible in the DNS service as soon as it was created.
|
||||
* See :ref:`adv-config-dns-performance-considerations` for an explanation of
|
||||
* See :ref:`config-dns-performance-considerations` for an explanation of
|
||||
the potential performance impact associated with this use case.
|
||||
|
||||
Following are the PTR records created for this example. Note that for
|
||||
IPv4, the value of ipv4_ptr_zone_prefix_size is 24. In the case of IPv6, the
|
||||
value of ipv6_ptr_zone_prefix_size is 116. For more details, see
|
||||
:ref:`adv-config-dns-int-ext-serv`:
|
||||
:ref:`config-dns-int-ext-serv`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -403,7 +400,7 @@ value of ipv6_ptr_zone_prefix_size is 116. For more details, see
|
||||
| 877e0215-2ddf-4d01-a7da-47f1092dfd56 | PTR | 9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.b.d.0.1.0.0.2.ip6.arpa. | my-vm.example.org. |
|
||||
+--------------------------------------+------+---------------------------------------------------------------------------+---------------------------------------------------------------------+
|
||||
|
||||
See :ref:`adv-config-dns-int-ext-serv` for detailed instructions on how
|
||||
See :ref:`config-dns-int-ext-serv` for detailed instructions on how
|
||||
to create the externally accessible network.
|
||||
|
||||
Use case 2: Floating IPs are published with associated port DNS attributes
|
||||
@ -564,7 +561,7 @@ floating IP is associated to the port.
|
||||
|
||||
Following are the PTR records created for this example. Note that for
|
||||
IPv4, the value of ipv4_ptr_zone_prefix_size is 24. For more details, see
|
||||
:ref:`adv-config-dns-int-ext-serv`:
|
||||
:ref:`config-dns-int-ext-serv`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -732,7 +729,7 @@ Note that in this use case:
|
||||
|
||||
Following are the PTR records created for this example. Note that for
|
||||
IPv4, the value of ipv4_ptr_zone_prefix_size is 24. For more details, see
|
||||
:ref:`adv-config-dns-int-ext-serv`:
|
||||
:ref:`config-dns-int-ext-serv`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -745,25 +742,25 @@ IPv4, the value of ipv4_ptr_zone_prefix_size is 24. For more details, see
|
||||
| 589a0171-e77a-4ab6-ba6e-23114f2b9366 | PTR | 5.4.24.172.in-addr.arpa. | my-floatingip.example.org. |
|
||||
+--------------------------------------+------+--------------------------+---------------------------------------------------------------------+
|
||||
|
||||
.. _adv-config-dns-performance-considerations:
|
||||
.. _config-dns-performance-considerations:
|
||||
|
||||
Performance considerations
|
||||
--------------------------
|
||||
|
||||
Only for :ref:`adv-config-dns-use-case-1`, if the port binding extension is
|
||||
Only for :ref:`config-dns-use-case-1`, if the port binding extension is
|
||||
enabled in the Networking service, the Compute service will execute one
|
||||
additional port update operation when allocating the port for the instance
|
||||
during the boot process. This may have a noticeable adverse effect in the
|
||||
performance of the boot process that must be evaluated before adoption of this
|
||||
use case.
|
||||
|
||||
.. _adv-config-dns-int-ext-serv:
|
||||
.. _config-dns-int-ext-serv:
|
||||
|
||||
Configuring OpenStack Networking for integration with an external DNS service
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
The first step to configure the integration with an external DNS service is to
|
||||
enable the functionality described in :ref:`adv-config-dns-int-dns-resolution`.
|
||||
enable the functionality described in :ref:`config-dns-int-dns-resolution`.
|
||||
Once this is done, the user has to take the following steps and restart
|
||||
``neutron-server``.
|
||||
|
||||
@ -815,7 +812,7 @@ Once this is done, the user has to take the following steps and restart
|
||||
Configuration of the externally accessible network for use case 1
|
||||
-----------------------------------------------------------------
|
||||
|
||||
In :ref:`adv-config-dns-use-case-1`, the externally accessible network must
|
||||
In :ref:`config-dns-use-case-1`, the externally accessible network must
|
||||
meet the following requirements:
|
||||
|
||||
* The network cannot have attribute ``router:external`` set to ``True``.
|
||||
@ -1,4 +1,4 @@
|
||||
.. _config-dns-resolution:
|
||||
.. _config-dns-res:
|
||||
|
||||
=============================
|
||||
Name resolution for instances
|
||||
@ -1,16 +1,12 @@
|
||||
.. _scenario-dvr-snat-ha-ovs:
|
||||
.. _config-dvr-snat-ha-ovs:
|
||||
|
||||
================================================
|
||||
Distributed Virtual Router SNAT HA configuration
|
||||
================================================
|
||||
============================================
|
||||
Distributed Virtual Routing with VRRP (L3HA)
|
||||
============================================
|
||||
|
||||
Starting with the Mitaka release, OpenStack Networking allows for the creation
|
||||
of routers with the ``--distributed`` and ``--ha`` flags set to ``True``. These
|
||||
routers will provide DVR functionality as well as SNAT HA functionality.
|
||||
|
||||
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
:ref:`Distributed Virtual Routing <scenario-dvr-ovs>` supports augmentation
|
||||
using :ref:`VRRP (L3HA) <scenario-l3ha-ovs>`. Using this configuration,
|
||||
virtual routers support both the ``--distributed`` and ``--ha`` options.
|
||||
|
||||
Similar to legacy HA routers, DVR/SNAT HA routers provide a quick fail over of
|
||||
the SNAT service to a backup DVR/SNAT router on an l3-agent running on a
|
||||
@ -30,6 +26,10 @@ configuring IP addresses on the interfaces in the ``snat`` namespace. In
|
||||
environments with more than one backup router, the rules of VRRP are followed
|
||||
to select a new master router.
|
||||
|
||||
.. note::
|
||||
|
||||
Experimental feature or incomplete documentation.
|
||||
|
||||
|
||||
Configuration example
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -1,7 +1,13 @@
|
||||
.. _config-ipam:
|
||||
|
||||
==================
|
||||
IPAM configuration
|
||||
==================
|
||||
|
||||
.. note::
|
||||
|
||||
Experimental feature or incomplete documentation.
|
||||
|
||||
Starting with the Liberty release, OpenStack Networking includes a pluggable
|
||||
interface for the IP Address Management (IPAM) function. This interface creates
|
||||
a driver framework for the allocation and de-allocation of subnets and IP
|
||||
@ -1,20 +1,10 @@
|
||||
====================================
|
||||
Using OpenStack Networking with IPv6
|
||||
====================================
|
||||
.. _config-ipv6:
|
||||
|
||||
The purpose of this page is to describe how the features and
|
||||
functionality available in OpenStack (using neutron networking) as of
|
||||
the Kilo release. It is intended to serve as a guide for how to deploy
|
||||
IPv6-enabled instances using OpenStack Networking. Where appropriate,
|
||||
features planned for Liberty or beyond may be described.
|
||||
====
|
||||
IPv6
|
||||
====
|
||||
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
|
||||
OpenStack Networking has supported IPv6 tenant subnets in certain
|
||||
configurations since Juno, but later releases added a number of new
|
||||
features, functionality and bug fixes to make it more robust. The
|
||||
focus of this page will be:
|
||||
Scope:
|
||||
|
||||
* How to enable dual-stack (IPv4 and IPv6 enabled) instances.
|
||||
* How those instances receive an IPv6 address.
|
||||
@ -29,7 +19,7 @@ IPv6 attributes (``ipv6_ra_mode`` and ``ipv6_address_mode``) set. The
|
||||
the next section. Finally, the subnets ``cidr`` needs to be provided.
|
||||
|
||||
Not in scope
|
||||
------------
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Things not in the scope of this document include:
|
||||
|
||||
@ -707,6 +697,7 @@ Extra configuration
|
||||
|
||||
Neutron dhcpv6_pd_agent
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To enable the driver for the dhcpv6_pd_agent, set pd_dhcp_driver to this in
|
||||
``/etc/neutron/neutron.conf``:
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _config-lbaas:
|
||||
|
||||
==================================
|
||||
Load Balancer as a Service (LBaaS)
|
||||
==================================
|
||||
@ -1,3 +1,5 @@
|
||||
.. _config-plugin-ml2:
|
||||
|
||||
===========
|
||||
ML2 plug-in
|
||||
===========
|
||||
@ -121,7 +123,7 @@ Provider networks provide connectivity like project networks.
|
||||
But only administrative (privileged) users can manage those
|
||||
networks because they interface with the physical network infrastructure.
|
||||
More information about provider networks see
|
||||
:doc:`intro-os-networking-overview` or the `OpenStack Administrator Guide
|
||||
:doc:`intro-os-networking` or the `OpenStack Administrator Guide
|
||||
<http://docs.openstack.org/admin-guide/networking_adv-features.html#provider-networks>`__.
|
||||
|
||||
* Flat
|
||||
@ -163,7 +165,7 @@ Project (tenant) networks provide connectivity to instances for a particular
|
||||
project. Regular (non-privileged) users can manage project networks
|
||||
within the allocation that an administrator or operator defines for
|
||||
them. More information about project and provider networks see
|
||||
:doc:`intro-os-networking-overview`
|
||||
:doc:`intro-os-networking`
|
||||
or the `OpenStack Administrator Guide
|
||||
<http://docs.openstack.org/admin-guide/networking_adv-features.html#provider-networks>`__.
|
||||
|
||||
@ -488,7 +490,7 @@ This guide characterizes the L2 reference implementations that currently exist.
|
||||
Due to direct connection, some features are not available when using SRIOV.
|
||||
For example, DVR, security groups, migration.
|
||||
|
||||
For more information see the :doc:`adv-config-sriov`.
|
||||
For more information see the :ref:`config-sriov`.
|
||||
|
||||
* MacVTap mechanism driver and MacVTap agent
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.. _adv-config-mtu:
|
||||
.. _config-mtu:
|
||||
|
||||
==================
|
||||
MTU considerations
|
||||
@ -1,9 +1,13 @@
|
||||
.. _adv-config-ovsfwdriver:
|
||||
.. _config-ovsfwdriver:
|
||||
|
||||
===================================
|
||||
Native Open vSwitch firewall driver
|
||||
===================================
|
||||
|
||||
.. note::
|
||||
|
||||
Experimental feature or incomplete documentation.
|
||||
|
||||
Historically, Open vSwitch (OVS) could not interact directly with *iptables*
|
||||
to implement security groups. Thus, the OVS agent and Compute service use
|
||||
a Linux bridge between each instance (VM) and the OVS integration bridge
|
||||
@ -1,9 +1,8 @@
|
||||
===================================
|
||||
Using OpenStack Networking with QoS
|
||||
===================================
|
||||
.. _config-qos:
|
||||
|
||||
This page serves as a guide for how to use the ``Quality of Service`` (QoS)
|
||||
functionality of OpenStack Networking.
|
||||
========================
|
||||
Quality of Service (QoS)
|
||||
========================
|
||||
|
||||
QoS is defined as the ability to guarantee certain network requirements
|
||||
like bandwidth, latency, jitter, and reliability in order to satisfy a
|
||||
@ -18,10 +17,6 @@ constraints. On a system without network QoS management, all traffic will be
|
||||
transmitted in a "best-effort" manner making it impossible to guarantee service
|
||||
delivery to customers.
|
||||
|
||||
|
||||
The basics
|
||||
~~~~~~~~~~
|
||||
|
||||
QoS is an advanced service plug-in. QoS is decoupled from the rest of the
|
||||
OpenStack Networking code on multiple levels and it is available through the
|
||||
ml2 extension driver.
|
||||
@ -1,3 +1,5 @@
|
||||
.. _config-rbac:
|
||||
|
||||
================================
|
||||
Role-Based Access Control (RBAC)
|
||||
================================
|
||||
@ -1,13 +0,0 @@
|
||||
======
|
||||
Server
|
||||
======
|
||||
|
||||
Architecture
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Configuration file organization, relationships, etc.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Reference common configuration items
|
||||
------------------------------------
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _config-sriov:
|
||||
|
||||
==========================
|
||||
Using SR-IOV functionality
|
||||
==========================
|
||||
@ -1,3 +1,5 @@
|
||||
.. _config-subnet-pools:
|
||||
|
||||
============
|
||||
Subnet pools
|
||||
============
|
||||
@ -1,14 +1,33 @@
|
||||
.. _config:
|
||||
|
||||
=============
|
||||
Configuration
|
||||
=============
|
||||
|
||||
This content currently under development. For general configuration, see
|
||||
the `Configuration Reference
|
||||
<http://docs.openstack.org/mitaka/config-reference/>`_.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
config-server.rst
|
||||
config-ml2-plug-in.rst
|
||||
config-dns-resolution.rst
|
||||
config-ml2
|
||||
config-address-scopes
|
||||
config-auto-allocation
|
||||
config-az
|
||||
config-bgp-dynamic-routing
|
||||
config-dhcp-ha
|
||||
config-dns-int
|
||||
config-dns-res
|
||||
config-dvr-ha-snat
|
||||
config-ipam
|
||||
config-ipv6
|
||||
config-lbaas
|
||||
config-mtu
|
||||
config-ovsfwdriver
|
||||
config-qos
|
||||
config-rbac
|
||||
config-sfc
|
||||
config-sriov
|
||||
config-subnet-pools
|
||||
|
||||
.. note::
|
||||
|
||||
For general configuration, see the `Configuration Reference
|
||||
<http://docs.openstack.org/mitaka/config-reference/>`_.
|
||||
|
||||
@ -7,11 +7,11 @@ Deployment scenarios
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
scenario-classic-ovs.rst
|
||||
scenario-classic-lb.rst
|
||||
scenario-classic-mt.rst
|
||||
scenario-dvr-ovs.rst
|
||||
scenario-l3ha-ovs.rst
|
||||
scenario-l3ha-lb.rst
|
||||
scenario-provider-ovs.rst
|
||||
scenario-provider-lb.rst
|
||||
scenario-classic-ovs
|
||||
scenario-classic-lb
|
||||
scenario-classic-mt
|
||||
scenario-dvr-ovs
|
||||
scenario-l3ha-ovs
|
||||
scenario-l3ha-lb
|
||||
scenario-provider-ovs
|
||||
scenario-provider-lb
|
||||
|
||||
@ -21,14 +21,13 @@ Contents
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
common/conventions.rst
|
||||
intro-networking.rst
|
||||
intro-os-networking.rst
|
||||
config.rst
|
||||
deploy.rst
|
||||
migration.rst
|
||||
miscellaneous.rst
|
||||
adv-config.rst
|
||||
common/conventions
|
||||
intro
|
||||
config
|
||||
deploy
|
||||
ops
|
||||
migration
|
||||
misc
|
||||
|
||||
Appendix
|
||||
~~~~~~~~
|
||||
@ -36,7 +35,7 @@ Appendix
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
common/app_support.rst
|
||||
common/app_support
|
||||
|
||||
Glossary
|
||||
~~~~~~~~
|
||||
@ -44,7 +43,7 @@ Glossary
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
common/glossary.rst
|
||||
common/glossary
|
||||
|
||||
Search in this guide
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _intro-basic-networking:
|
||||
|
||||
================
|
||||
Basic networking
|
||||
================
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _intro-nat:
|
||||
|
||||
===========================
|
||||
Network address translation
|
||||
===========================
|
||||
@ -1,3 +1,5 @@
|
||||
.. _intro-network-components:
|
||||
|
||||
==================
|
||||
Network components
|
||||
==================
|
||||
@ -1,3 +1,5 @@
|
||||
.. _intro-network-namespaces:
|
||||
|
||||
==================
|
||||
Network namespaces
|
||||
==================
|
||||
|
||||
@ -1,162 +0,0 @@
|
||||
=======================
|
||||
Overview and components
|
||||
=======================
|
||||
|
||||
OpenStack Networking allows you to create and manage network objects,
|
||||
such as networks, subnets, and ports, which other OpenStack services
|
||||
can use. Plug-ins can be implemented to accommodate different
|
||||
networking equipment and software, providing flexibility to OpenStack
|
||||
architecture and deployment.
|
||||
|
||||
The Networking service, code-named neutron, provides an API that lets you
|
||||
define network connectivity and addressing in the cloud. The Networking
|
||||
service enables operators to leverage different networking technologies
|
||||
to power their cloud networking. The Networking service also provides an
|
||||
API to configure and manage a variety of network services ranging from L3
|
||||
forwarding and :term:`NAT` to load balancing, perimeter firewalls, and
|
||||
virtual private networks.
|
||||
|
||||
It includes the following components:
|
||||
|
||||
API server
|
||||
The OpenStack Networking API includes support for Layer 2 networking
|
||||
and :term:`IP address management (IPAM) <IP Address Management (IPAM)>`, as
|
||||
well as an extension for a Layer 3 router construct that enables routing
|
||||
between Layer 2 networks and gateways to external networks. OpenStack
|
||||
Networking includes a growing list of plug-ins that enable interoperability
|
||||
with various commercial and open source network technologies,
|
||||
including routers, switches, virtual switches and software-defined
|
||||
networking (SDN) controllers.
|
||||
|
||||
OpenStack Networking plug-in and agents
|
||||
Plugs and unplugs ports, creates networks or subnets, and provides
|
||||
IP addressing. The chosen plug-in and agents differ depending on the
|
||||
vendor and technologies used in the particular cloud. It is
|
||||
important to mention that only one plug-in can be used at a time.
|
||||
|
||||
Messaging queue
|
||||
Accepts and routes RPC requests between agents to complete API operations.
|
||||
Message queue is used in the ML2 plug-in for RPC between the neutron
|
||||
server and neutron agents that run on each hypervisor, in the ML2
|
||||
mechanism drivers for :term:`Open vSwitch` and :term:`Linux bridge`.
|
||||
|
||||
|
||||
OpenStack Networking concepts
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To configure rich network topologies, you can create and configure networks
|
||||
and subnets and instruct other OpenStack services like Compute to attach
|
||||
virtual devices to ports on these networks.
|
||||
OpenStack Compute is a prominent consumer of OpenStack Networking to provide
|
||||
connectivity for its instances.
|
||||
In particular, OpenStack Networking supports each tenant having multiple
|
||||
private networks and enables tenants to choose their own IP addressing scheme,
|
||||
even if those IP addresses overlap with those that other tenants use. There are
|
||||
two types of network, tenant and provider networks. It is possible to share any
|
||||
of these types of networks among tenants as part of the network creation
|
||||
process.
|
||||
|
||||
Tenant networks
|
||||
---------------
|
||||
|
||||
Users create tenant networks for connectivity within projects. By default, they
|
||||
are fully isolated and are not shared with other projects. OpenStack Networking
|
||||
supports the following types of network isolation and overlay technologies.
|
||||
|
||||
Flat
|
||||
All instances reside on the same network, which can also be shared
|
||||
with the hosts. No VLAN tagging or other network segregation takes place.
|
||||
|
||||
VLAN
|
||||
Networking allows users to create multiple provider or tenant networks
|
||||
using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the
|
||||
physical network. This allows instances to communicate with each other
|
||||
across the environment. They can also communicate with dedicated servers,
|
||||
firewalls, load balancers, and other networking infrastructure on the
|
||||
same layer 2 VLAN.
|
||||
|
||||
GRE and VXLAN
|
||||
VXLAN and GRE are encapsulation protocols that create overlay networks
|
||||
to activate and control communication between compute instances. A
|
||||
Networking router is required to allow traffic to flow outside of the
|
||||
GRE or VXLAN tenant network. A router is also required to connect
|
||||
directly-connected tenant networks with external networks, including the
|
||||
Internet. The router provides the ability to connect to instances directly
|
||||
from an external network using floating IP addresses.
|
||||
|
||||
Provider networks
|
||||
-----------------
|
||||
|
||||
The OpenStack administrator creates provider networks. These networks map to
|
||||
existing physical networks in the data center. Useful network types in this
|
||||
category are flat (untagged) and VLAN (802.1Q tagged).
|
||||
|
||||
.. image:: figures/NetworkTypes.png
|
||||
:alt: Tenant and provider networks
|
||||
|
||||
Subnets
|
||||
-------
|
||||
|
||||
A block of IP addresses and associated configuration state. This
|
||||
is also known as the native IPAM (IP Address Management) provided by the
|
||||
networking service for both tenant and provider networks.
|
||||
Subnets are used to allocate IP addresses when new ports are created on a
|
||||
network.
|
||||
|
||||
Subnet Pools
|
||||
------------
|
||||
|
||||
End users normally can create subnets with any valid IP addresses without other
|
||||
restrictions. However, in some cases, it is nice for the admin or the tenant
|
||||
to pre-define a pool of addresses from which to create subnets with automatic
|
||||
allocation. This is what :doc:`adv-config-subnet-pools` provide.
|
||||
|
||||
Using subnet pools constrains what addresses can be used by requiring that
|
||||
every subnet be within the defined pool. It also prevents address reuse or
|
||||
overlap by two subnets from the same pool.
|
||||
|
||||
Ports
|
||||
-----
|
||||
|
||||
A port is a connection point for attaching a single device, such as the NIC
|
||||
of a virtual server, to a virtual network. The port also describes the
|
||||
associated network configuration, such as the MAC and IP addresses to be
|
||||
used on that port.
|
||||
|
||||
Routers
|
||||
-------
|
||||
|
||||
This is a logical component that forwards data packets between
|
||||
networks. It also provides L3 and NAT forwarding to provide external
|
||||
network access for VMs on tenant networks. Required by certain
|
||||
plug-ins only.
|
||||
|
||||
Security groups
|
||||
---------------
|
||||
|
||||
A security group acts as a virtual firewall for your compute instances to
|
||||
control inbound and outbound traffic. Security groups act at the port level,
|
||||
not the subnet level. Therefore, each port in a subnet could be
|
||||
assigned to a different set of security groups. If you don't specify a
|
||||
particular group at launch time, the instance is automatically assigned
|
||||
to the default security group for that network.
|
||||
|
||||
Security groups and security group rules give administrators and tenants the
|
||||
ability to specify the type of traffic and direction (ingress/egress) that is
|
||||
allowed to pass through a port. A security group is a container for security
|
||||
group rules. When a port is created, it is associated with a security group. If
|
||||
a security group is not specified, the port is associated with a 'default'
|
||||
security group. By default, this group drops all ingress traffic and allows all
|
||||
egress. Rules can be added to this group in order to change the behavior.
|
||||
|
||||
Extensions
|
||||
----------
|
||||
|
||||
The OpenStack Networking service is extensible. Extensions serve two
|
||||
purposes: they allow the introduction of new features in the API
|
||||
without requiring a version change and they allow the introduction of
|
||||
vendor specific niche functionality. Applications can programmatically
|
||||
list available extensions by performing a GET on the
|
||||
:code:`/extensions` URI. Note that this is a versioned request; that
|
||||
is, an extension available in one API version might not be available
|
||||
in another.
|
||||
@ -1,86 +0,0 @@
|
||||
===============================
|
||||
Service and component hierarchy
|
||||
===============================
|
||||
|
||||
Server
|
||||
~~~~~~
|
||||
|
||||
Overview and concepts
|
||||
---------------------
|
||||
|
||||
* Provides API, manages database, etc.
|
||||
|
||||
Plug-ins
|
||||
~~~~~~~~
|
||||
|
||||
Overview and concepts
|
||||
---------------------
|
||||
|
||||
* Manages agents
|
||||
|
||||
Agents
|
||||
~~~~~~
|
||||
|
||||
Overview and concepts
|
||||
---------------------
|
||||
|
||||
* Provides layer 2/3 connectivity to instances
|
||||
|
||||
* Handles physical-virtual network transition
|
||||
|
||||
* Handles metadata, etc.
|
||||
|
||||
Layer 2 (Ethernet and Switching)
|
||||
--------------------------------
|
||||
|
||||
* Linux Bridge
|
||||
|
||||
* Overview and concepts
|
||||
|
||||
* OVS
|
||||
|
||||
* Overview and concepts
|
||||
|
||||
Layer 3 (IP and Routing)
|
||||
------------------------
|
||||
|
||||
* L3
|
||||
|
||||
* Overview and concepts
|
||||
|
||||
* DHCP
|
||||
|
||||
* Overview and concepts
|
||||
|
||||
Miscellaneous
|
||||
-------------
|
||||
|
||||
* Metadata
|
||||
|
||||
* Overview and concepts
|
||||
|
||||
Services
|
||||
~~~~~~~~
|
||||
|
||||
Routing services
|
||||
----------------
|
||||
|
||||
VPNaaS
|
||||
------
|
||||
|
||||
The Virtual Private Network-as-a-Service (VPNaaS) is a neutron
|
||||
extension that introduces the VPN feature set.
|
||||
|
||||
LbaaS
|
||||
-----
|
||||
|
||||
The Load-Balancer-as-a-Service (LBaaS) API provisions and configures
|
||||
load balancers. The reference implementation is based on the HAProxy
|
||||
software load balancer.
|
||||
|
||||
FwaaS
|
||||
-----
|
||||
|
||||
The Firewall-as-a-Service (FWaaS) API is an experimental API that
|
||||
enables early adopters and vendors to test their networking
|
||||
implementations.
|
||||
@ -1,10 +1,233 @@
|
||||
==============================================
|
||||
Introduction to OpenStack Networking (neutron)
|
||||
==============================================
|
||||
.. _intro-os-networking:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
====================
|
||||
OpenStack Networking
|
||||
====================
|
||||
|
||||
intro-os-networking-overview.rst
|
||||
intro-os-networking-service.rst
|
||||
intro-os-networking-features.rst
|
||||
OpenStack Networking allows you to create and manage network objects,
|
||||
such as networks, subnets, and ports, which other OpenStack services
|
||||
can use. Plug-ins can be implemented to accommodate different
|
||||
networking equipment and software, providing flexibility to OpenStack
|
||||
architecture and deployment.
|
||||
|
||||
The Networking service, code-named neutron, provides an API that lets you
|
||||
define network connectivity and addressing in the cloud. The Networking
|
||||
service enables operators to leverage different networking technologies
|
||||
to power their cloud networking. The Networking service also provides an
|
||||
API to configure and manage a variety of network services ranging from L3
|
||||
forwarding and :term:`NAT` to load balancing, perimeter firewalls, and
|
||||
virtual private networks.
|
||||
|
||||
It includes the following components:
|
||||
|
||||
API server
|
||||
The OpenStack Networking API includes support for Layer 2 networking
|
||||
and :term:`IP address management (IPAM) <IP Address Management (IPAM)>`, as
|
||||
well as an extension for a Layer 3 router construct that enables routing
|
||||
between Layer 2 networks and gateways to external networks. OpenStack
|
||||
Networking includes a growing list of plug-ins that enable interoperability
|
||||
with various commercial and open source network technologies,
|
||||
including routers, switches, virtual switches and software-defined
|
||||
networking (SDN) controllers.
|
||||
|
||||
OpenStack Networking plug-in and agents
|
||||
Plugs and unplugs ports, creates networks or subnets, and provides
|
||||
IP addressing. The chosen plug-in and agents differ depending on the
|
||||
vendor and technologies used in the particular cloud. It is
|
||||
important to mention that only one plug-in can be used at a time.
|
||||
|
||||
Messaging queue
|
||||
Accepts and routes RPC requests between agents to complete API operations.
|
||||
Message queue is used in the ML2 plug-in for RPC between the neutron
|
||||
server and neutron agents that run on each hypervisor, in the ML2
|
||||
mechanism drivers for :term:`Open vSwitch` and :term:`Linux bridge`.
|
||||
|
||||
|
||||
Concepts
|
||||
~~~~~~~~
|
||||
|
||||
To configure rich network topologies, you can create and configure networks
|
||||
and subnets and instruct other OpenStack services like Compute to attach
|
||||
virtual devices to ports on these networks.
|
||||
OpenStack Compute is a prominent consumer of OpenStack Networking to provide
|
||||
connectivity for its instances.
|
||||
In particular, OpenStack Networking supports each tenant having multiple
|
||||
private networks and enables tenants to choose their own IP addressing scheme,
|
||||
even if those IP addresses overlap with those that other tenants use. There are
|
||||
two types of network, tenant and provider networks. It is possible to share any
|
||||
of these types of networks among tenants as part of the network creation
|
||||
process.
|
||||
|
||||
Tenant networks
|
||||
---------------
|
||||
|
||||
Users create tenant networks for connectivity within projects. By default, they
|
||||
are fully isolated and are not shared with other projects. OpenStack Networking
|
||||
supports the following types of network isolation and overlay technologies.
|
||||
|
||||
Flat
|
||||
All instances reside on the same network, which can also be shared
|
||||
with the hosts. No VLAN tagging or other network segregation takes place.
|
||||
|
||||
VLAN
|
||||
Networking allows users to create multiple provider or tenant networks
|
||||
using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the
|
||||
physical network. This allows instances to communicate with each other
|
||||
across the environment. They can also communicate with dedicated servers,
|
||||
firewalls, load balancers, and other networking infrastructure on the
|
||||
same layer 2 VLAN.
|
||||
|
||||
GRE and VXLAN
|
||||
VXLAN and GRE are encapsulation protocols that create overlay networks
|
||||
to activate and control communication between compute instances. A
|
||||
Networking router is required to allow traffic to flow outside of the
|
||||
GRE or VXLAN tenant network. A router is also required to connect
|
||||
directly-connected tenant networks with external networks, including the
|
||||
Internet. The router provides the ability to connect to instances directly
|
||||
from an external network using floating IP addresses.
|
||||
|
||||
Provider networks
|
||||
-----------------
|
||||
|
||||
The OpenStack administrator creates provider networks. These networks map to
|
||||
existing physical networks in the data center. Useful network types in this
|
||||
category are flat (untagged) and VLAN (802.1Q tagged).
|
||||
|
||||
.. image:: figures/NetworkTypes.png
|
||||
:alt: Tenant and provider networks
|
||||
|
||||
Subnets
|
||||
-------
|
||||
|
||||
A block of IP addresses and associated configuration state. This
|
||||
is also known as the native IPAM (IP Address Management) provided by the
|
||||
networking service for both tenant and provider networks.
|
||||
Subnets are used to allocate IP addresses when new ports are created on a
|
||||
network.
|
||||
|
||||
Subnet Pools
|
||||
------------
|
||||
|
||||
End users normally can create subnets with any valid IP addresses without other
|
||||
restrictions. However, in some cases, it is nice for the admin or the tenant
|
||||
to pre-define a pool of addresses from which to create subnets with automatic
|
||||
allocation.
|
||||
|
||||
Using subnet pools constrains what addresses can be used by requiring that
|
||||
every subnet be within the defined pool. It also prevents address reuse or
|
||||
overlap by two subnets from the same pool.
|
||||
|
||||
See :ref:`config-subnet-pools` for more information.
|
||||
|
||||
Ports
|
||||
-----
|
||||
|
||||
A port is a connection point for attaching a single device, such as the NIC
|
||||
of a virtual server, to a virtual network. The port also describes the
|
||||
associated network configuration, such as the MAC and IP addresses to be
|
||||
used on that port.
|
||||
|
||||
Routers
|
||||
-------
|
||||
|
||||
This is a logical component that forwards data packets between
|
||||
networks. It also provides L3 and NAT forwarding to provide external
|
||||
network access for VMs on tenant networks. Required by certain
|
||||
plug-ins only.
|
||||
|
||||
Security groups
|
||||
---------------
|
||||
|
||||
A security group acts as a virtual firewall for your compute instances to
|
||||
control inbound and outbound traffic. Security groups act at the port level,
|
||||
not the subnet level. Therefore, each port in a subnet could be
|
||||
assigned to a different set of security groups. If you don't specify a
|
||||
particular group at launch time, the instance is automatically assigned
|
||||
to the default security group for that network.
|
||||
|
||||
Security groups and security group rules give administrators and tenants the
|
||||
ability to specify the type of traffic and direction (ingress/egress) that is
|
||||
allowed to pass through a port. A security group is a container for security
|
||||
group rules. When a port is created, it is associated with a security group. If
|
||||
a security group is not specified, the port is associated with a 'default'
|
||||
security group. By default, this group drops all ingress traffic and allows all
|
||||
egress. Rules can be added to this group in order to change the behavior.
|
||||
|
||||
Extensions
|
||||
----------
|
||||
|
||||
The OpenStack Networking service is extensible. Extensions serve two
|
||||
purposes: they allow the introduction of new features in the API
|
||||
without requiring a version change and they allow the introduction of
|
||||
vendor specific niche functionality. Applications can programmatically
|
||||
list available extensions by performing a GET on the
|
||||
:code:`/extensions` URI. Note that this is a versioned request; that
|
||||
is, an extension available in one API version might not be available
|
||||
in another.
|
||||
|
||||
Service and component hierarchy
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Server
|
||||
------
|
||||
|
||||
* Provides API, manages database, etc.
|
||||
|
||||
Plug-ins
|
||||
--------
|
||||
|
||||
* Manages agents
|
||||
|
||||
Agents
|
||||
------
|
||||
|
||||
* Provides layer 2/3 connectivity to instances
|
||||
|
||||
* Handles physical-virtual network transition
|
||||
|
||||
* Handles metadata, etc.
|
||||
|
||||
Layer 2 (Ethernet and Switching)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Linux Bridge
|
||||
|
||||
* OVS
|
||||
|
||||
Layer 3 (IP and Routing)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* L3
|
||||
|
||||
* DHCP
|
||||
|
||||
Miscellaneous
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
* Metadata
|
||||
|
||||
Services
|
||||
--------
|
||||
|
||||
Routing services
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
VPNaaS
|
||||
^^^^^^
|
||||
|
||||
The Virtual Private Network-as-a-Service (VPNaaS) is a neutron
|
||||
extension that introduces the VPN feature set.
|
||||
|
||||
LBaaS
|
||||
^^^^^
|
||||
|
||||
The Load-Balancer-as-a-Service (LBaaS) API provisions and configures
|
||||
load balancers. The reference implementation is based on the HAProxy
|
||||
software load balancer.
|
||||
|
||||
FWaaS
|
||||
^^^^^
|
||||
|
||||
The Firewall-as-a-Service (FWaaS) API is an experimental API that
|
||||
enables early adopters and vendors to test their networking
|
||||
implementations.
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
===================
|
||||
Tunnel technologies
|
||||
===================
|
||||
.. _intro-overlay-protocols:
|
||||
|
||||
==========================
|
||||
Overlay (tunnel) protocols
|
||||
==========================
|
||||
|
||||
Tunneling is a mechanism that makes transfer of payloads feasible over an
|
||||
incompatible delivery network. It allows the network user to gain access to
|
||||
@ -1,6 +1,8 @@
|
||||
==========================
|
||||
Introduction to networking
|
||||
==========================
|
||||
.. _intro:
|
||||
|
||||
============
|
||||
Introduction
|
||||
============
|
||||
|
||||
The OpenStack :term:`Networking service` provides an API that allows users
|
||||
to set up and define network connectivity and addressing in the
|
||||
@ -37,8 +39,9 @@ components:
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
intro-basic-networking.rst
|
||||
intro-networking-components.rst
|
||||
intro-tunnel-technologies.rst
|
||||
intro-network-namespaces.rst
|
||||
intro-network-address-translation.rst
|
||||
intro-basic-networking
|
||||
intro-network-components
|
||||
intro-overlay-protocols
|
||||
intro-network-namespaces
|
||||
intro-nat
|
||||
intro-os-networking
|
||||
@ -1,7 +0,0 @@
|
||||
=============
|
||||
Legacy to DVR
|
||||
=============
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
===============
|
||||
Legacy to L3 HA
|
||||
===============
|
||||
.. _migration-classic-to-l3ha:
|
||||
|
||||
======================
|
||||
Classic to VRRP (L3HA)
|
||||
======================
|
||||
|
||||
This section describes the process of migrating from a classic router to an L3
|
||||
HA router, which is available starting from the Mitaka release.
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
==================
|
||||
Database migration
|
||||
==================
|
||||
.. _migration-database:
|
||||
|
||||
========
|
||||
Database
|
||||
========
|
||||
|
||||
The upgrade of the Networking service database is implemented with Alembic
|
||||
migration chains. The migrations in the ``alembic/versions`` contain the
|
||||
@ -1,6 +1,8 @@
|
||||
=============================================================
|
||||
Migrate legacy nova-network to OpenStack Networking (neutron)
|
||||
=============================================================
|
||||
.. _migration-nova-to-neutron:
|
||||
|
||||
=====================================================
|
||||
Legacy nova-network to OpenStack Networking (neutron)
|
||||
=====================================================
|
||||
|
||||
Two networking models exist in OpenStack. The first is called legacy
|
||||
networking (:term:`nova-network`) and it is a sub-process embedded in
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _migration:
|
||||
|
||||
=========
|
||||
Migration
|
||||
=========
|
||||
@ -5,8 +7,6 @@ Migration
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
migration-neutron-database.rst
|
||||
migration-nova-network-to-neutron.rst
|
||||
migration-classic-to-dvr.rst
|
||||
migration-classic-to-l3ha.rst
|
||||
|
||||
migration-database
|
||||
migration-nova-network-to-neutron
|
||||
migration-classic-to-l3ha
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
============================
|
||||
Disabling libvirt networking
|
||||
============================
|
||||
.. _misc-disable-libvirt-networking:
|
||||
|
||||
==========================
|
||||
Disable libvirt networking
|
||||
==========================
|
||||
|
||||
Most OpenStack deployments use the `libvirt <http://libvirt.org>`__
|
||||
toolkit for interacting with the
|
||||
|
||||
10
doc/networking-guide/source/misc.rst
Normal file
10
doc/networking-guide/source/misc.rst
Normal file
@ -0,0 +1,10 @@
|
||||
.. _miscellaneous:
|
||||
|
||||
=============
|
||||
Miscellaneous
|
||||
=============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
misc-libvirt
|
||||
@ -1,10 +0,0 @@
|
||||
=============
|
||||
Miscellaneous
|
||||
=============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
misc-libvirt.rst
|
||||
misc-add-ha-for-dhcp.rst
|
||||
misc-neutron-purge.rst
|
||||
@ -1,6 +1,8 @@
|
||||
=========================================
|
||||
Network IP Availability plug-in extension
|
||||
=========================================
|
||||
.. _ops-ip-availability:
|
||||
|
||||
=======================
|
||||
IP availability metrics
|
||||
=======================
|
||||
|
||||
Network IP Availability is an information-only API extension that allows
|
||||
a user or process to determine the number of IP addresses that are consumed
|
||||
@ -1,6 +1,8 @@
|
||||
=============
|
||||
Neutron purge
|
||||
=============
|
||||
.. _ops-resource-purge:
|
||||
|
||||
==============
|
||||
Resource purge
|
||||
==============
|
||||
|
||||
The Networking service provides a purge mechanism to delete the
|
||||
following network resources for a project (tenant):
|
||||
16
doc/networking-guide/source/adv-config-tag.rst → doc/networking-guide/source/ops-resource-tags.rst
16
doc/networking-guide/source/adv-config-tag.rst → doc/networking-guide/source/ops-resource-tags.rst
@ -1,13 +1,11 @@
|
||||
=================
|
||||
Tagging resources
|
||||
=================
|
||||
.. _ops-resource-tags:
|
||||
|
||||
This page serves as a guide for how to use the ``Tag`` functionality available
|
||||
in the Networking service as of the Mitaka release. The service supports
|
||||
networks only in the Mitaka release. The Networking service allows users to set
|
||||
tags on their resources. Tagging resources can be used by external systems or
|
||||
any other clients of the Networking service REST API (and NOT back-end
|
||||
drivers).
|
||||
=============
|
||||
Resource tags
|
||||
=============
|
||||
|
||||
Various virtual networking resources support tags for use by external
|
||||
systems or any other clients of the Networking service API.
|
||||
|
||||
Use cases
|
||||
~~~~~~~~~
|
||||
12
doc/networking-guide/source/ops.rst
Normal file
12
doc/networking-guide/source/ops.rst
Normal file
@ -0,0 +1,12 @@
|
||||
.. _operations:
|
||||
|
||||
==========
|
||||
Operations
|
||||
==========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
ops-ip-availability
|
||||
ops-resource-tags
|
||||
ops-resource-purge
|
||||
@ -546,7 +546,7 @@ Controller node
|
||||
service_plugins = router
|
||||
allow_overlapping_ips = True
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
@ -594,7 +594,7 @@ Controller node
|
||||
[securitygroup]
|
||||
firewall_driver = iptables
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. Start the following services:
|
||||
|
||||
|
||||
@ -383,7 +383,7 @@ Controller node
|
||||
service_plugins = router
|
||||
allow_overlapping_ips = True
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
@ -422,7 +422,7 @@ Controller node
|
||||
[securitygroup]
|
||||
firewall_driver = iptables
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. Start the following services:
|
||||
|
||||
|
||||
@ -198,7 +198,7 @@ The compute nodes contain the following network components:
|
||||
#. Conventional Linux bridges handling security groups. Optionally, a native
|
||||
OVS implementation can handle security groups. However, due to kernel and
|
||||
OVS version requirements for it, this scenario uses conventional Linux
|
||||
bridges. See :ref:`adv-config-ovsfwdriver` for more information.
|
||||
bridges. See :ref:`config-ovsfwdriver` for more information.
|
||||
|
||||
.. image:: figures/scenario-classic-ovs-compute1.png
|
||||
:alt: Compute node components - overview
|
||||
@ -650,7 +650,7 @@ Controller node
|
||||
service_plugins = router
|
||||
allow_overlapping_ips = True
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
@ -701,7 +701,7 @@ Controller node
|
||||
[securitygroup]
|
||||
firewall_driver = iptables_hybrid
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. Start the following services:
|
||||
|
||||
|
||||
@ -172,7 +172,7 @@ The compute nodes contain the following network components:
|
||||
#. Conventional Linux bridges handling security groups. Optionally, a native
|
||||
OVS implementation can handle security groups. However, due to kernel and
|
||||
OVS version requirements for it, this scenario uses conventional Linux
|
||||
bridges. See :ref:`adv-config-ovsfwdriver` for more information.
|
||||
bridges. See :ref:`config-ovsfwdriver` for more information.
|
||||
|
||||
.. image:: figures/scenario-dvr-compute1.png
|
||||
:alt: Network node components - overview
|
||||
@ -498,7 +498,7 @@ Controller node
|
||||
create distributed routers using the ``--distributed True`` option
|
||||
during router creation.
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
@ -550,7 +550,7 @@ Controller node
|
||||
[securitygroup]
|
||||
firewall_driver = iptables_hybrid
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. Start the following services:
|
||||
|
||||
|
||||
@ -218,7 +218,7 @@ Controller node
|
||||
You can increase the ``dhcp_agents_per_network`` value up to the
|
||||
number of nodes running the DHCP agent.
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
@ -266,7 +266,7 @@ Controller node
|
||||
[securitygroup]
|
||||
firewall_driver = iptables
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. Start the following services:
|
||||
|
||||
|
||||
@ -163,7 +163,7 @@ The compute nodes contain the following components:
|
||||
#. Conventional Linux bridges handling security groups. Optionally, a native
|
||||
OVS implementation can handle security groups. However, due to kernel and
|
||||
OVS version requirements for it, this scenario uses conventional Linux
|
||||
bridges. See :ref:`adv-config-ovsfwdriver` for more information.
|
||||
bridges. See :ref:`config-ovsfwdriver` for more information.
|
||||
|
||||
.. figure:: figures/scenario-l3ha-ovs-compute1.png
|
||||
:alt: Compute node components - overview
|
||||
@ -226,7 +226,7 @@ Controller node
|
||||
You can increase the ``dhcp_agents_per_network`` value up to the
|
||||
number of nodes running the DHCP agent.
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
@ -277,7 +277,7 @@ Controller node
|
||||
[securitygroup]
|
||||
firewall_driver = iptables_hybrid
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. Start the following services:
|
||||
|
||||
|
||||
@ -383,7 +383,7 @@ Controller node
|
||||
`Installation Guide <http://docs.openstack.org/mitaka/install-guide-ubuntu/horizon-install.html>`__
|
||||
for more information.
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
|
||||
@ -147,7 +147,7 @@ The compute nodes contain the following network components:
|
||||
#. Conventional Linux bridges handling security groups. Optionally, a native
|
||||
OVS implementation can handle security groups. However, due to kernel and
|
||||
OVS version requirements for it, this scenario uses conventional Linux
|
||||
bridges. See :ref:`adv-config-ovsfwdriver` for more information.
|
||||
bridges. See :ref:`config-ovsfwdriver` for more information.
|
||||
|
||||
.. figure:: figures/scenario-provider-ovs-compute1.png
|
||||
:alt: Compute node components - overview
|
||||
@ -415,7 +415,7 @@ Controller node
|
||||
`Installation Guide <http://docs.openstack.org/mitaka/install-guide-ubuntu/horizon-install.html>`__
|
||||
for more information.
|
||||
|
||||
* If necessary, :ref:`configure MTU <adv-config-mtu>`.
|
||||
* If necessary, :ref:`configure MTU <config-mtu>`.
|
||||
|
||||
#. In the ``ml2_conf.ini`` file:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user