[RFE] Routed provider networks support in OVN
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-
options : {network_
parent_name : []
port_security : []
tag : 2016
tag_request : []
type : localnet
name : provnet-
options : {network_
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:
compute2: bridge-mappings = segment2:
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 |
Changed in neutron: | |
assignee: | nobody → Maciej Jozefczyk (maciej.jozefczyk) |
importance: | Undecided → High |
status: | New → In Progress |
tags: | added: neutron-proactive-backport-potential |
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 eavesdrop. openstack. org/#Neutron_ drivers_ Meeting
http://
Since the overall architecture implies OVN changes it may make sense to invite OVN developers to the drivers meeting.