Specification for Neutron Dynamic Routing
Change-Id: I0bc1956d9c6d94af00936a5c78213ec2cd6e001d
This commit is contained in:
parent
f4e3399e9d
commit
8dba158ba1
|
@ -0,0 +1,216 @@
|
||||||
|
..
|
||||||
|
Copyright 2018, Canonical UK
|
||||||
|
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0
|
||||||
|
Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
..
|
||||||
|
This template should be in ReSTructured text. Please do not delete
|
||||||
|
any of the sections in this template. If you have nothing to say
|
||||||
|
for a whole section, just write: "None". For help with syntax, see
|
||||||
|
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||||
|
http://www.tele3.cz/jbar/rest/rest.html
|
||||||
|
|
||||||
|
===============================
|
||||||
|
Neutron Dynamic Routing
|
||||||
|
===============================
|
||||||
|
|
||||||
|
OpenStack supports dynamic routing, specifically BGP. BGP forms a significant
|
||||||
|
part of the routing infrastructure for many TelCos and large other
|
||||||
|
organizations with complex networks. Our charms need to grow support for
|
||||||
|
dynamic routing.
|
||||||
|
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
In a typical setup with Neutron Gateway, infrastructure routers do not have
|
||||||
|
knowledge of the private networks allocated to OpenStack tenants. As a result,
|
||||||
|
services external to OpenStack do not know how to route traffic to OpenStack
|
||||||
|
instances. As OpenStack networks are elastic and therefore can evolve in many
|
||||||
|
ways, a way of communicating changes between OpenStack and external routers is
|
||||||
|
needed.
|
||||||
|
|
||||||
|
Since networks in OpenStack are self serviced, any addition or removal of
|
||||||
|
OpenStack network should not depend on network administrator’s actions. Network
|
||||||
|
limitations should be set up front. This is further facilitated by the use of
|
||||||
|
subnet pools in OpenStack.
|
||||||
|
|
||||||
|
Other implications include decoupling subnets from layer 2, allowing different
|
||||||
|
next-hops for floating IPs.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Neutron dynamic routing solves this problem by introducing a BGP speaker, which
|
||||||
|
then peers with the existing infrastructure router(s) and announces the
|
||||||
|
next-hop virtual routers for OpenStack owned networks. This allows dynamic
|
||||||
|
routing changes to be communicated to the physical infrastructure based on
|
||||||
|
changes in OpenStack networks. Since OpenStack Networks are managed by users,
|
||||||
|
address scope limitations need to be in place.
|
||||||
|
|
||||||
|
A new charm is proposed called neutron-dynamic-routing which will configure and
|
||||||
|
deploy the neutron-bgp-dragent (Neutron BGP dynamic routing agent). The
|
||||||
|
neutron-bgp-dragent is a BGP speaker which can be peered with existing routers
|
||||||
|
in the BGP infrastructure. This charm will require interfaces for AMQP and
|
||||||
|
potentially neutron-api-plugin (TBD). For testing purposes it will also make
|
||||||
|
use of the bgp interface to peer with the quagga charm, both written by Frode
|
||||||
|
Nordahl (See Testing below.)
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
------------
|
||||||
|
|
||||||
|
The charm will need to select an interface on the provider network for
|
||||||
|
communication with OpenStack. It may also need to select an interface to speak
|
||||||
|
with BGP routers in the infrastructure.
|
||||||
|
|
||||||
|
High availability is accomplished by deploying N number of units of
|
||||||
|
neutron-dynamic-routing with care for placement on different physical hosts.
|
||||||
|
This will introduce multiple neutron-bgp-dragents. BGP infrastructure routers
|
||||||
|
will need to be manually informed of each neutron-bgp-dragent.
|
||||||
|
|
||||||
|
IPv4 and IPv6 support is handled with separate bgp-speakers defined for each.
|
||||||
|
|
||||||
|
The charm will need to support both DVR and centralized OpenStack routing.
|
||||||
|
|
||||||
|
Outside the scope
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
It is important to understand what the OpenStack dynamic routing implementation
|
||||||
|
does *not* do and lies outside of the scope of this spec.
|
||||||
|
|
||||||
|
* It does not provide ingress BGP to OpenStack, it is purely egress
|
||||||
|
advertisement of OpenStack owned networks.
|
||||||
|
* It does not automatically advertise all OpenStack networks or whole subnet
|
||||||
|
pools. A considerable amount of administrator configuration is still
|
||||||
|
required, including associating OpenStack networks with the bgp-speaker. See
|
||||||
|
the `Testing documentation https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html>`__
|
||||||
|
for a sense of the administrative overhead required.
|
||||||
|
* It does not provide a mechanism for injecting arbitrary BGP routes (for
|
||||||
|
example for /32 FIPs). It merely advertises OpenStack networks that have been
|
||||||
|
associated with the bgp speaker.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Floating IPs, and NAT in general, are one approach to this problem, but there
|
||||||
|
are couple of drawbacks. For starters, NAT comes with a performance price as
|
||||||
|
number of connections grows. In cloud, where many VMs can establish connections
|
||||||
|
to various external peers, this can require significant memory and cpu
|
||||||
|
resources. Neutron gateway doesn't really scale without manual intervention. On
|
||||||
|
top of that, if only NAT is used, peers can’t really know which instance
|
||||||
|
established connection, they only know connection came ‘from the cloud’. Same
|
||||||
|
problems apply to DVR.
|
||||||
|
|
||||||
|
Static routes on physical gateways are the closest thing to BGP solution. The
|
||||||
|
only drawback is operational; in case address scope in Neutron changes, these
|
||||||
|
changes need to be implemented on physical routers too.
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
thedac
|
||||||
|
|
||||||
|
Additional work:
|
||||||
|
fnordahl
|
||||||
|
|
||||||
|
Gerrit Topic
|
||||||
|
------------
|
||||||
|
|
||||||
|
Use Gerrit topic "<topic_name>" for all patches related to this spec.
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
git-review -t dragent
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
**New charm neutron-dynamic-routing**
|
||||||
|
|
||||||
|
A new reactive charm will be developed to configure and deploy the
|
||||||
|
neutron-bgp-dragent.
|
||||||
|
|
||||||
|
**Update neutron-api charm**
|
||||||
|
|
||||||
|
The neutron-api charm will need to load the service_plugin
|
||||||
|
neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin and subsequently run
|
||||||
|
a db migrate.
|
||||||
|
|
||||||
|
**Potential need for new neutron-api-plugin interface**
|
||||||
|
|
||||||
|
It is unclear at this time if a relationship to neutron-api will be required.
|
||||||
|
If it is required no layered interface for neutron-api-plugin yet exists and
|
||||||
|
will need to be created.
|
||||||
|
|
||||||
|
**New charm quagga**
|
||||||
|
|
||||||
|
For testing purposes the new quagga charm will act as a BGP peer to validate
|
||||||
|
and test neutron-dynamic-routing. Frode Nordahl has already begun work on this
|
||||||
|
project: https://github.com/openstack-charmers/charm-quagga
|
||||||
|
|
||||||
|
**New interface bgp**
|
||||||
|
|
||||||
|
For testing purposes the new bgp interface will define the peering relationship
|
||||||
|
between neutron-dynamic-routing and the quagga charm. Frode Nordahl has already
|
||||||
|
begun work on this project: https://github.com/openstack-charmers/interface-bgp
|
||||||
|
|
||||||
|
|
||||||
|
Repositories
|
||||||
|
------------
|
||||||
|
|
||||||
|
A new repository for the neutron-dynamic-routing charm is needed.
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
git://git.openstack.org/openstack/charm-neutron-dynamic-routing
|
||||||
|
|
||||||
|
A new repository for the quagga charm is needed.
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
git://git.openstack.org/openstack-charmers/charm-quagga
|
||||||
|
|
||||||
|
A new repository for the bgp interface is needed.
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
git://git.openstack.org/openstack-charmers/interface-bgp
|
||||||
|
|
||||||
|
|
||||||
|
Documentation
|
||||||
|
-------------
|
||||||
|
|
||||||
|
An update to the charm deployment guide will be required.
|
||||||
|
|
||||||
|
Upstream documentation is found at the following:
|
||||||
|
https://docs.openstack.org/neutron-dynamic-routing/latest/
|
||||||
|
|
||||||
|
Security
|
||||||
|
--------
|
||||||
|
|
||||||
|
The neutron-dynamic-routing charm is dependent on the OpenStack implementation
|
||||||
|
of BGP. Which uses a simple string as a password.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
-------
|
||||||
|
|
||||||
|
The neutron-dynamic-routing charm will need to be tested with a BGP peer. Frode
|
||||||
|
Nordahl has begun work on the quagga charm which will act as an infrastructure
|
||||||
|
BGP router allowing for testing and validation.
|
||||||
|
|
||||||
|
A mojo spec, or other suitably automated test, will be a requirement for this
|
||||||
|
feature implementation.
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
Loading…
Reference in New Issue