[RFE] Floating IP Subnets on Routed Provider Networks

Bug #1667329 reported by John Davidge on 2017-02-23
38
This bug affects 4 people
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Ryan Tidwell

Bug Description

This RFE proposes an enhancement to the Routed Provider Networks[1][2] feature to allow the creation of Floating IP subnets. The planned implementation will leverage the BGP Dynamic Routing[3] and Service Subnets[4] features to achieve this.

Problem Description
===================

Currently, all subnets on a Routed Network are required to belong to a segment, which typically corresponds to the physical rack on which all VMs for the subnet will be provisioned. This doesn't make sense for a Floating IP subnet, which will not be associated with a neutron segment as its address range will span more than a single rack. Additionally, no mechanism currently exists to provide routing from a floating IP to a specific Routed Network Segment.

Proposed Solution
=================

To solve the first part of the problem, Service Subnets[4] will be used to allow a Floating IP subnet to be created on a Routed Network without the need for subnet/segment association. Specifically, a subnet with service_type "network:floating_ip" will not be subject to the segment association check.

To solve the second part, BGP Dynamic Routing[3] will be used to advertise the ToR for the relevant segment as the next-hop for assigned Floating IPs. This will require enhancing the BGP Agent to be segment-aware, rather than just network-aware.

[1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html
[2] https://docs.openstack.org/newton/networking-guide/config-routed-networks.html
[3] https://docs.openstack.org/newton/networking-guide/config-bgp-dynamic-routing.html
[4] https://docs.openstack.org/newton/networking-guide/config-service-subnets.html

Changed in neutron:
status: New → Triaged
Changed in neutron:
importance: Undecided → Wishlist
tags: added: rfe-approved
removed: rfe
Miguel Lavalle (minsel) wrote :

As discussed today in the drivers meeting, next step is a spec and a blue print (e.g. https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch)

Changed in neutron:
assignee: nobody → John Davidge (john-davidge)
Miguel Lavalle (minsel) on 2017-07-02
Changed in neutron:
assignee: John Davidge (john-davidge) → Miguel Lavalle (minsel)
Changed in neutron:
status: Triaged → In Progress
Changed in neutron:
assignee: Miguel Lavalle (minsel) → Ryan Tidwell (ryan-tidwell)

Any progress or ETAs on this RFE?

Ryan Tidwell (ryan-tidwell) wrote :

See https://review.opendev.org/#/c/486450/ for design details that are being hashed out. I'm in the process of proposing an initial patch for this, look for it shortly. This initial patch will demonstrate what I'm proposing in the design spec. Reviews on https://review.opendev.org/#/c/486450/ would be greatly appreciated.

Takashi Sogabe (sogabe) wrote :

Are there any blockers around the RFE?
I evaluated the configuration by using devstack with PoC code. It seems work well and should be a little impact for upstream code.

Takashi Sogabe (sogabe) on 2019-11-28
information type: Public → Public Security
information type: Public Security → Private Security
information type: Private Security → Public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers