Floating IP not reachable from instance in other project

[Alexander Käb]

We noticed a strange behavior regarding Floating IPs in an OpenStack environment using ML2/OVN with DVR. Consider the provided test setup consisting of 3 projects. Each project has exactly one Network with two subnets, one for IPv4 one for IPv6, associated with it. Each project’s network is connected to the provider network through a router which has two ports facing the provider network and two internal ones for the respective subnets.

The VM (Instance) Layout is also included. The first instance (a1) in Project A also has an FIP associated with it. Trying to ping this FIP from outside Openstack’s context works without any problems. This is also true when we want to ping the FIP from instance a2 in the same project.
However, trying to do so from any of the other instances in a different project does not work. This however, changes when a FIP is assigned to an instance in a different project. By assigning a FIP to instance b for example will result in b being able to ping the FIP of a1. After removing the FIP this still holds through.

The following observations regarding this have been made.
When a FIP is assigned new entries in OVN’s SB DB (specifically the MAC_Binding table) show up, some of which will disappear again when the FIP is released from b. The one entry persisting is a mac-binding of the mac address and IPv4 associated with the router of project b facing the provider network, with the logical port being the provider net facing port of project a’s router. We are not sure if this is relevant to the problem, we are just putting this out here.

In addition, when we were looking for other solutions we came across this old bug: https://bugzilla.redhat.com/show_bug.cgi?id=1836963 with a possible workaround, this however, lead to pinging not being possible afterwards.

The Overcloud has been deployed using the `/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-dvr-ha.yaml` template for OVN and the following additional settings were added to neutron:

parameter_defaults:
  OVNEmitNeedToFrag: true
  NeutronGlobalPhysnetMtu: 9000

Furthermore, all nodes use a Linux bond for the `br-ex` interface on on which the different node networks (Internal API, Storage, ...) reside. These networks also use VLANs.

If you need any additional Information of the setup, please let me know.
Best Regards

Version Info

- TripleO Wallaby

- puppet-ovn-18.5.0-0.20220216211819.d496e5a.el9.noarch
- ContainerImageTag: ecab4196e43c16aaea91ebb25fb25ab1

inside ovn_controller container:
- ovn22.06-22.06.0-24.el8s.x86_64
- rdo-ovn-host-22.06-3.el8.noarch
- rdo-ovn-22.06-3.el8.noarch
- ovn22.06-host-22.06.0-24.el8s.x86_64

[Brian Haley (brian-haley)]

Moving this to the neutron project as networking-ovn has been retired for a while.

My first question is are you able to test this with a later release? Since it's been 10 months since it was filed just want to make sure it hasn't been fixed.

[Alexander Käb (alexander-kaeb)]

As of now I wasnt able to confirm this is still a problem in our testing environment. However, as the production environment has not yet been updated to the current version of the testing cloud I will test this again when we completed the update process.