Floating IP's for routed networks
This specification proposes to add functionality that allows users to associate floating IPs to ports of routed networks Partial-Bug #1667329 Change-Id: Id07f52da9fff321827aff8be11614a347030bb04
This commit is contained in:
Miguel Lavalle
Thomas Goirand
parent
c234530aa6
commit
3f584dc9b7
|
|
@ -0,0 +1,240 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
================================
|
||||
Floating IPs for Routed Networks
|
||||
================================
|
||||
|
||||
https://bugs.launchpad.net/neutron/+bug/1667329
|
||||
|
||||
This specification proposes the implementation of floating IPs for Routed
|
||||
Networks.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
`Neutron Routed Networks`__ are composed of individual L2 segments stitched
|
||||
together by L3 routers in the operator infrastructure. The operator has the
|
||||
option to route the fixed IP addresses of the ports in such a network to the
|
||||
external world, but this might not be feasible for IPv4 without a large enough
|
||||
externally routable address range.
|
||||
|
||||
__ routed-networks_
|
||||
|
||||
Routed Networks were implemented in the first place to support a large number
|
||||
of ports / VMs, beyond the constraints of networks based on a single L2
|
||||
broadcast domain. Operators want to be able to support a number of ports / VMs
|
||||
as large as possible and route a subset of them externally, without being
|
||||
limited by the availability IPv4 address ranges.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
This specification proposes to enable the association of ports in a Routed
|
||||
Network with floating IP addresses (floating IPs). This will enable operators
|
||||
and their users to create ports in routed networks with fixed IP addresses in
|
||||
private ranges and assign to them scarce publicly routable IPv4 addresses only
|
||||
when needed, through the association of floating IPs. This functionality will
|
||||
require the changes described in the following sections.
|
||||
|
||||
Creation of subnets spanning segments
|
||||
-------------------------------------
|
||||
|
||||
To support the use of floating IP's on a routed provider network, there
|
||||
needs to be a way to create a subnet that is not bound to a segment. In its
|
||||
current state, a subnet cannot be created on a network without specifying a
|
||||
segment when one or more subnets on the network are already bound to a
|
||||
segment.
|
||||
|
||||
A new subnet service type of ``network:routed`` will be introduced. When a
|
||||
subnet supports this service_type it can be associated to the network of a
|
||||
routed provider network rather than having to be associated to one of the
|
||||
segments that comprises the routed network. This provides a way of expressing
|
||||
the notion of a subnet that spans the segments of a routed network. As such,
|
||||
this not only supports the use of floating IP's on routed networks but also
|
||||
allows various neutron backends to handle these subnets in innovative ways.
|
||||
|
||||
The current definition of a routed provider network is a network in which
|
||||
each subnet is associated to a different segment. This definition will change
|
||||
subtly and include networks where 1 or more subnets with ``network:routed`` in
|
||||
its ``service_types`` is associated with the network but none of the individual
|
||||
segments comprising it.
|
||||
|
||||
To enable this, minor changes to ``_validate_segment()`` in
|
||||
``neutron/db/ipam_backend_mixin.py`` that allow for subnets with this special
|
||||
service type to exist outside of any segment.
|
||||
|
||||
|
||||
Service subnets and floating IPs for routed networks
|
||||
----------------------------------------------------
|
||||
|
||||
`Service subnets`__ enable operators to define valid port types for each subnet
|
||||
on a network, without limiting networks to one subnet or manually creating
|
||||
ports with a specific subnet ID. Using this feature, operators can ensure that
|
||||
ports for instances and router interfaces, for example, always use different
|
||||
subnets.
|
||||
|
||||
__ service-subnets_
|
||||
|
||||
To allow floating IP's to be created on a routed network, an operator will
|
||||
leverage this functionality when creating the floating IP subnet. To create a
|
||||
floating IP subnet that can be used on a routed provider network, the subnet
|
||||
should be created with two ``service_types``: ``network:routed`` and
|
||||
``network:floatingip``. ``network:routed`` allows the subnet to be pinned to
|
||||
the network rather than a particular segment, and ``network:floatingip``
|
||||
allows for floating IP's be allocated from the subnet.
|
||||
|
||||
No changes are anticipated to enable this to work properly. Documentation
|
||||
will be updated to explain the workflow for operators. No change to the
|
||||
current workflow for creating/associating/disassociating/deleting floating
|
||||
IP's will be introduced.
|
||||
|
||||
DVR and routed provider networks
|
||||
--------------------------------
|
||||
|
||||
No changes to the current operation of DVR need to be made in support of
|
||||
these changes. Changes to documentation will be made to reflect the fact that
|
||||
subnets on segments where you wish to have floating IP gateway ports built
|
||||
should be created with the ```service_type`` of
|
||||
``network:floatingip_agent_gateway`` should be used to indicate that compute
|
||||
nodes can reach the routed external network on a given segment. For the
|
||||
network node connectivity, a ``service_type`` of ``network:router_gateway``
|
||||
should be used to indicate centralized router ports will be instantiated on
|
||||
the proper segment(s).
|
||||
|
||||
Because only the ToR device providing connectivity to the network segment
|
||||
would know how to reach the floating IP (DVR will send a gratuitous ARP),
|
||||
connectivity from outside the segment must be provided host routes that steer
|
||||
traffic to the appropriate segment. This can be achieved by enabling
|
||||
neutron-dynamic-routing, enabling it to announce FIP reachability to
|
||||
ToR routers, and ensuring ToR routers propogate the FIP host route with an
|
||||
appropriate next-hop. Documentation will be added to explain how this can be
|
||||
set up by an operator.
|
||||
|
||||
|
||||
Floating IPs advertisement with BGP Dynamic Routing
|
||||
---------------------------------------------------
|
||||
|
||||
`BGP Dynamic Routing`__ is a Neutron Stadium project that enables advertisement
|
||||
of self-service (private) network prefixes to physical routers that support
|
||||
BGP, thus removing the conventional dependency on static routes. A ``BGP
|
||||
speaker`` advertises the self-service network prefixes to associated ``BGP
|
||||
peers``, which represent the BGP capable physical routers in the operator
|
||||
infrastructure.
|
||||
|
||||
__ bgp-dynamic-routing_
|
||||
|
||||
In its current state, neutron-dynamic-routing determines next-hops for floating
|
||||
IP's by identifying the relevant router and floating IP agent gateway ports
|
||||
and mapping floating IP's to their proper endpoint. In this way, it is
|
||||
completely agnostic of segments and is capable of properly discovering and
|
||||
announcing the correct next-hop for a /32 host route of a floating IP.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
This change is not expected to pose any new security concerns.
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
No client impacts are anticipated. The network guide will be updated with
|
||||
proper documentation and example configurations.
|
||||
|
||||
Future Work
|
||||
-----------
|
||||
|
||||
For some operators, there is a desire to allow for floating IP's to be
|
||||
associated to a port without first connecting a router to an external network
|
||||
and a tenant network. This can be implemented in many ways. One way is by
|
||||
relying on a cloud-init-like process to set the FIP as a loopback address
|
||||
inside a VM and rely on a BGP process to announce the FIP with the fixed IP
|
||||
as the next-hop address for the floating IP. With the implementation described
|
||||
in previous sections in place, a similar scheme would be the next logical
|
||||
iteration of routed provider networks.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
* `Ryan Tidwell <https://launchpad.net/~ryan-tidwell>`_
|
||||
|
||||
Other contributors:
|
||||
|
||||
* `Miguel Lavalle <https://launchpad.net/~minsel>`_
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
#. Introduce the new ``network:routed`` subnet service type.
|
||||
#. Refactor network segment integrity checks to allow subnets with a
|
||||
``service_type`` of ``network:routed`` to be associated directly to a
|
||||
network.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Tempest Tests
|
||||
-------------
|
||||
|
||||
There are currently no tempest tests for routed provider networks. However,
|
||||
some tests are being developed and tests that cover floating IP creation on
|
||||
routed provider networks can eventually be added to these tests.
|
||||
|
||||
Functional Tests
|
||||
----------------
|
||||
|
||||
Unknown
|
||||
|
||||
API Tests
|
||||
---------
|
||||
|
||||
The following tests can be added to the suite of scenario tests being developed
|
||||
in https://review.opendev.org/#/c/665155/ :
|
||||
|
||||
- Floating IP subnets can be created on a routed provider network
|
||||
- Floating IP's can be created on a routed provider network
|
||||
- Floating IP's from the same subnet can be associated to ports across
|
||||
different segments
|
||||
- Tests in neutron-dynamic-routing to assert proper route discovery on
|
||||
routed provider networks
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Yes
|
||||
|
||||
User Documentation
|
||||
------------------
|
||||
|
||||
- Document new behavior for creating floating IP subnets
|
||||
- Document how to use in conjunction with neutron-dynamic-routing
|
||||
- Example configurations of routed networks, ToR router BGP config, and
|
||||
neutron-dynamic-routing.
|
||||
|
||||
Developer Documentation
|
||||
-----------------------
|
||||
|
||||
A new section to the Neutron devref will be added describing the implementation
|
||||
of floating IPs for routed networks.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. _routed-networks: https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html
|
||||
.. _bgp-dynamic-routing: https://docs.openstack.org/ocata/networking-guide/config-bgp-dynamic-routing.html
|
||||
.. _service-subnets: https://docs.openstack.org/neutron/latest/admin/config-service-subnets.html
|
||||
.. _DVR: https://docs.openstack.org/neutron/latest/admin/deploy-ovs-ha-dvr.html
|
||||
Loading…
Reference in New Issue