[RFE] unmanaged dynamic router resources - OVN
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Problem description
-------
Regarding the conversation started in March [1] about the use of OVN interconnect with Neutron, we are testing the use of the OVN-IC to interconnect workloads in multiple AZs - with different OpenStacks deployments.
The Neutron default design does not allow to interconnect workloads between different OpenStacks natively, and this could be a requirement for a high availability cloud solution (if we are talking about Cloud Region). Additionally, this OVN-IC solution allows interconnecting other cloud solutions that use OVN as network backend - ovn-kube case.
We tested an OVN interconnect integrated with 3 OpenStack deployments and it worked very well !!! in this case, we are considering direct L3 traffic at the router level between different network infrastructures.
To make it work we need to configure the TS and the LRP manually, as well as examples from the ovn-kube project [2]. The problem with snat (and FIPs) that was reported in the ovn-kube project has already been fixed in OVN version 22.09, and in newer OVN versions it is not necessary to modify anything in Neutron to pass the (--gateway-port) because OVN finds the gateway port automatically.
At the moment the only issue found in Neutron is related to DB sync, and it is natural because the LRP connected to the TS does not exist in the DB. If the operator needs to restore the Neutron DB, the SYNC repair command will remove the unmanaged externally added resources.
Note: The route learning has been tested with IPv4 and IPv6 addresses and is working fine. A detail in the case of IPv6 is related to the filter of routes learned via LLC addresses [3], take care of this case.
SYNC_REPAIR - problem
* Static Routes (learned OVN-IC routes)
* Router Port -> Transit Switches
Jul 10 18:34:11 os-infra-
Jul 10 18:34:11 os-infra-
-------
Proposed solution:
-------
This RFE intends to implement a filter in the OVN mech_driver to validate the external_ids key and not remove LRP's and static routes present in the OVN backend without Neutron "key" in external_ids register.
sync_routers_
LRPs case:
Filter the port list when iterating over existing OVN LRPs before checking for existence in the Neutron DB.
LRP created by Neutron - example
_uuid : 1266061f-
enabled : []
external_ids : {"neutron:
gateway_chassis : []
ha_chassis_group : []
ipv6_prefix : []
ipv6_ra_configs : {}
mac : "fa:16:3e:d4:63:c5"
name : lrp-3581bee6-
networks : ["192.168.1.1/24"]
options : {}
peer : []
LRP externally created - example
ovn-nbctl list logical_router_port rt1-admin-tenant1
_uuid : 6a8bbf7b-
enabled : []
external_ids : {}
gateway_chassis : [b4487769-
ha_chassis_group : []
ipv6_prefix : []
ipv6_ra_configs : {}
mac : "aa:aa:aa:aa:ab:01"
name : rt1-admin-tenant1
networks : ["169.254.
options : {}
peer : []
LRPs created manually do not have Neutron keys in external_ids, the idea here is to filter the return list and use the resource only when external_ids contain Neutron keys.
Static routes case:
Additionally, OVN sync_db composes a list of static routes linked to a router (get_all_
ovn-nbctl lr-route-list 078fd69b-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
2801:
2801:
With these specific changes, the management of these LRPs and learned routes will be completely disassociated from Neutron perspective, and the resources can be managed by the operator, creating and removing links with remote routers on demand.
-------
Regards,
Roberto
[1] https:/
[2] https:/
[3] https:/
-------
Additional logs - Interconnect use case:
OpenStack 1
root@os-
root@os-
root@os-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
root@os-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
root@os-
OpenStack 2
root@os-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
root@os-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
OpenStack 3
root@os-
root@os-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
root@os-
IPv4 Routes
Route Table <main>:
IPv6 Routes
Route Table <main>:
OVN-IC Global database
root@ovn-
availability-zone osp1
gateway 832b6c0d-
hostname: osp1-gwnode1
type: geneve
ip: 192.168.200.28
port admin-rt1-tenant1
transit switch: admin-tenant1
port admin-rt1-tenant1_1
transit switch: admin-tenant1_1
availability-zone osp2
gateway 17ffabdf-
hostname: osp2-gwnode1
type: geneve
ip: 192.168.200.128
port admin-rt2-tenant1
transit switch: admin-tenant1
port admin-rt2-tenant1_1
transit switch: admin-tenant1_1
availability-zone osp3
gateway 97595af9-
hostname: osp3-gwnode1
type: geneve
ip: 192.168.200.228
port admin-rt3-tenant1
transit switch: admin-tenant1
port admin-rt3-tenant1_1
transit switch: admin-tenant1_1
-------
Reference design:
# Global database OVN-IC
ovn-ic-nbctl ts-add admin-tenant1
**** OpenStack 1 ***********
# OVN central 1
ovn-nbctl set NB_Global . name=osp1
ovn-nbctl set NB_Global . options:
ovn-nbctl lrp-add NEUTRON_ROUTER rt1-admin-tenant1 aa:aa:aa:aa:aa:01 169.254.100.1/24
ovn-nbctl lsp-add admin-tenant1 admin-rt1-tenant1 -- \
ovn-nbctl lrp-set-
ovn-nbctl set NB_Global . options:
# Gateway node - Openstack 1
ovs-vsctl set open_vswitch . external_
**** OpenStack 2 ***********
ovn-nbctl set NB_Global . name=osp2
ovn-nbctl set NB_Global . options:
ovn-nbctl lrp-add NEUTRON_ROUTER rt2-admin-tenant1 aa:aa:aa:aa:aa:02 169.254.100.2/24
ovn-nbctl lsp-add admin-tenant1 admin-rt2-tenant1 -- \
ovn-nbctl lrp-set-
ovn-nbctl set NB_Global . options:
# Gateway node
ovs-vsctl set open_vswitch . external_
**** OpenStack 3 ***********
ovn-nbctl set NB_Global . name=osp3
ovn-nbctl set NB_Global . options:
ovn-nbctl lrp-add NEUTRON_ROUTER rt3-admin-tenant1 aa:aa:aa:aa:aa:03 169.254.100.3/24
ovn-nbctl lsp-add admin-tenant1 admin-rt3-tenant1 -- \
ovn-nbctl lrp-set-
ovn-nbctl set NB_Global . options:
# Gateway node
ovs-vsctl set open_vswitch . external_
description: | updated |
@Roderto,
If approved, will you implement this RFE?