[ovn] l3ha and distributed router extra attributes do not reflect OVN state
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Rodolfo Alonso |
Bug Description
With https:/
Their default values are taken from the global configuration options more relevant for default L3 service plugin implementation based on Linux network namespaces
https:/
https:/
https:/
as opposed to relying on the OVN-specific options. For instance, it order to enable the support for distributed floating IPs there is an OVN-specific global option that enables this mode for all OVN routers:
As a result, OVN routers now have the `distributed` property set to `False` by default (unless the global ML2/ovs-specific default is changed) and it does not reflect the state of the `ovn/enable_
The ML2/ovs and ML2/ovn comparison docs still refer to OVN-based router having no `l3ha` or `distributed` attributes whereas this is not the case anymore:
https:/
One place where it becomes relevant is the neutron-
https:/
https:/
For distributed routers the logic is such that IP addresses of ports with a device owner set to `network:
As a result, if an operator uses distributed FIPs with OVN with the router attribute `distributed == False`, neutron-
On the other hand, if an operator uses distributed FIPs with OVN with the router attribute `distributed == True`, neutron-
There are at least two outputs to expect as a fix:
1) Make sure the distributed state is reflected correctly for OVN routers based on the OVN-specific config option;
2) Fix neutron-dynamic routing to still create centralized /32 routes if there are not any `network:
OR change the OVN implementation to create those for the purposes of direct southbound routing purposes.
A similar approach can be done for the `ha` attribute but based on OVN's approach to it that does not rely on VRRP.
=====
A note on `network:
They were originally added to implement the "fast exit" RFE: https:/
https:/
One *other* reason for having floatingip_
https:/
In that case, the network fabric will need a route with a next hop at the OpenStack side through which a FIP will be reachable. And this is despite the fact an external network is a single-segment one (shared L2).
NDR currently tries to look up a next hop based on ports with `network:
description: | updated |
description: | updated |
summary: |
- [ovn] l3ha and disitributed router extra attributes do not reflect OVN + [ovn] l3ha and distributed router extra attributes do not reflect OVN state |
tags: |
added: l3-bgp removed: ndr |
description: | updated |
Patch: https:/ /review. opendev. org/c/openstack /neutron/ +/886992