yahoo-eng-team team mailing list archive

[Brian Haley <1998517@xxxxxxxxxxxxxxxxxx>]

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.

** Project changed: networking-ovn => neutron

** Tags added: ovn

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1998517

Title:
  Floating IP not reachable from instance in other project

Status in neutron:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1998517/+subscriptions