[RFE] Routed provider networks support in OVN

Bug #1865889 reported by Daniel Alvarez
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
High
Maciej Jozefczyk

Bug Description

The routed provider networks feature doesn't work properly with OVN backend. While API doesn't return any errors, all the ports are allocated to the same OVN Logical Switch and besides providing no Layer2 isolation whatsoever, it won't work when multiple segments using different physnets are added to such network.

The reason for the latter is that, currently, in core OVN, only one localnet port is supported per Logical Switch so only one physical net can be associated to it. I can think of two different approaches:

1) Change the OVN mech driver to logically separate Neutron segments:

a) Create an OVN Logical Switch *per Neutron segment*. This has some challenges from a consistency point of view as right now there's a 1:1 mapping between a Neutron Network and an OVN Logical Switch. Revision numbers, maintenance task, OVN DB Sync script, etcetera.

b) Each of those Logical Switches will have a localnet port associated to the physnet of the Neutron segment.

c) The port still belongs to the parent network so all the CRUD operations over a port will require to figure out which underlying OVN LS applies (depending on which segment the port lives in).
The same goes for other objects (e.g. OVN Load Balancers, gw ports -if attaching a multisegment network to a Neutron router as a gateway is a valid use case at all-).

e) Deferred allocation. A port can be created in a multisegment Neutron network but the IP allocation is deferred to the time where a compute node is assigned to an instance. In this case the OVN mech driver might need to move around the Logical Switch Port from the Logical Switch of the parent to that of the segment where it falls (can be prone to race conditions :?).

2) Core OVN changes:

The current limitation is that right now only one localnet port is allowed per Logical Switch so we can't map different physnets to it. If we add support for multiple localnet ports in core OVN, we can have all the segments living in the same OVN Logical Switch.

My idea here would be:

a) Per each Neutron segment, we create a localnet port in the single OVN Logical Switch with its physnet and vlan id (if any). Eg.

name : provnet-f7038db6-7376-4b83-b57b-3f456bea2b80
options : {network_name=segment1}
parent_name : []
port_security : []
tag : 2016
tag_request : []
type : localnet

name : provnet-84487aa7-5ac7-4f07-877e-1840d325e3de
options : {network_name=segment2}
parent_name : []
port_security : []
tag : 2017
tag_request : []
type : localnet

And both ports would belong to the LS corresponding to the multisegment Neutron network.

b) In this case, when ovn-controller sees that a port in that network has been bound to it, all it needs to create is the patch port to the provider bridge that the bridge mappings configuration dictates.

E.g

compute1: bridge-mappings = segment1:br-provider1
compute2: bridge-mappings = segment2:br-provider2

When a port in the multisegment network gets bound to compute1, ovn-controller will create a patch-port between br-int and br-provider1. The restriction here is that on a given hypervisor, only ports belonging to the same segment will be present. ie. we can't mix VMs on different segments on the same hypervisor.

c) Minor changes are required in the Neutron side (just creating the localnet port upon segment creation).

We need to discuss if the restriction mentioned earlier makes sense. If not, perhaps we need to drop this approach completely or look for core OVN alternatives.

I'd lean on approach number 2 as it seems the less invasive in terms of code changes but there's the catch described that may make it a no-go or explore another ways to eliminate that restriction somehow in core OVN.

tags: added: rfe
tags: added: ovn
Revision history for this message
Bence Romsics (bence-romsics) wrote :

I'm sure Daniel knows this already, but for the record:
Please add this RFE to the agenda of the neutron-drivers meeting and discuss it there:

https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
http://eavesdrop.openstack.org/#Neutron_drivers_Meeting

Since the overall architecture implies OVN changes it may make sense to invite OVN developers to the drivers meeting.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Lets start discussion about it on next drivers meeting, on 13.03.2020

tags: added: rfe-triaged
removed: rfe
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

The RFE was discussed in the drivers meeting: http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_drivers.2020-03-13-14.00.log.html#l-16
We decided to accept it. The OVN subteam can choose solution (1 or 2) which is easier/better to go with.
The main downside of approach 2, which is limit for one segment per host isn't really issue for Neutron currently as we have such limitation in case of other in-tree drivers too.

tags: added: rfe-approved
removed: rfe-triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/715157

Revision history for this message
Maciej Jozefczyk (maciejjozefczyk) wrote :
Changed in neutron:
assignee: nobody → Maciej Jozefczyk (maciej.jozefczyk)
importance: Undecided → High
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/ussuri)

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/734768

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master)

Reviewed: https://review.opendev.org/715157
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=483f468fdd5bb549f763d0507e0a7ac1106eb85a
Submitter: Zuul
Branch: master

commit 483f468fdd5bb549f763d0507e0a7ac1106eb85a
Author: Maciej Józefczyk <email address hidden>
Date: Wed Mar 25 15:30:12 2020 +0000

    [OVN] Create localnet port for each created segment

    If new segment is created/old deleted we should update its
    localnet port in related Logical_Switch.

    Added also missing code to sync tool in order to delete provnet
    ports in case of leftovers.

    Change-Id: I6b864ba1c168643640a64bd7c25e1d0fc0ea348a
    Related-Bug: 1865889

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/ussuri)

Reviewed: https://review.opendev.org/734768
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9dd0d32063f72389fd89dcf857ab3a021db73d95
Submitter: Zuul
Branch: stable/ussuri

commit 9dd0d32063f72389fd89dcf857ab3a021db73d95
Author: Maciej Józefczyk <email address hidden>
Date: Wed Mar 25 15:30:12 2020 +0000

    [OVN] Create localnet port for each created segment

    If new segment is created/old deleted we should update its
    localnet port in related Logical_Switch.

    Added also missing code to sync tool in order to delete provnet
    ports in case of leftovers.

    Change-Id: I6b864ba1c168643640a64bd7c25e1d0fc0ea348a
    Related-Bug: 1865889
    (cherry picked from commit 483f468fdd5bb549f763d0507e0a7ac1106eb85a)

tags: added: in-stable-ussuri
tags: added: neutron-proactive-backport-potential
Revision history for this message
Piotr Misiak (pmisiak) wrote :

Hello,

Maciej great work so far! Thanks for implementing this.
What is the status of this RFE?
Is it working? Does this feature requires a specific OVN version?

Thanks!

Revision history for this message
Bernard Cafarelli (bcafarel) wrote :

Hi,

actually this RFE is pretty much complete, only missing patch to mark it complete is the doc one: https://review.opendev.org/c/openstack/neutron/+/743709

I think you will find most answers there (as for code it should be working great)

Revision history for this message
Bernard Cafarelli (bcafarel) wrote :

Doc is also merged, updating status on this one

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 18.0.0.0rc1

This issue was fixed in the openstack/neutron 18.0.0.0rc1 release candidate.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/833653

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/833653
Committed: https://opendev.org/openstack/neutron/commit/d966845e5b80b1cec3cbfe25e4a7e1542e9fca65
Submitter: "Zuul (22348)"
Branch: master

commit d966845e5b80b1cec3cbfe25e4a7e1542e9fca65
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Sun Mar 6 11:12:03 2022 +0000

    [OVN] Remove maintenance "check_for_localnet_legacy_port_name"

    Remove maintenance task "check_for_localnet_legacy_port_name".
    This method was added in [1], four releases ago. We can now
    be sure any logical switch port will have the correct field
    "name" value.

    Related-Bug: #1865889

    [1]https://review.opendev.org/c/openstack/neutron/+/715157

    Change-Id: I71bb605582e2572807e1f38f7ee5b8dd91ab0c4a

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.