I think I may have found the issue. Note that I wasn't sure what other project/sub-project to add this ticket to, so I will add it to the Neutron project.
We use team interfaces with VLANs, which uses the same MAC address for each VLAN (see the bottom of this note for an example of 3 VLANs on a team interface from "ip a"). It appears that the OVS DVR Neutron Agent assumes that MAC addresses will be unique across interfaces - at least what I can tell here (Note that I am not a Python programmer): https://github.com/openstack/neutron/blob/317cdbf40850964080a0a30d6212a3b536df1caa/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py Specifically look at the "registered_dvr_macs" variable, which is used in a few places, including the _add_dvr_mac method. So, instead of using interface names or IDs, it looks like a MAC address is assumed to be unique, but is not unique at all, especially in VLAN configurations (obviously very common). Anyone know if my theory is right? Btw, the fact that it worked on Queens was likely due to the fact that we did not use team interfaces on its installation since it was installed in VMs with virtual NICs. Eric 10: team0.1000@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000 link/ether ec:0d:9a:d9:09:16 brd ff:ff:ff:ff:ff:ff inet6 fe80::ee0d:9aff:fed9:916/64 scope link valid_lft forever preferred_lft forever 11: team0.1001@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ec:0d:9a:d9:09:16 brd ff:ff:ff:ff:ff:ff inet6 fe80::ee0d:9aff:fed9:916/64 scope link valid_lft forever preferred_lft forever 12: team0.1002@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ec:0d:9a:d9:09:16 brd ff:ff:ff:ff:ff:ff inet6 fe80::ee0d:9aff:fed9:916/64 scope link valid_lft forever preferred_lft forever ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1792493 Title: DVR and floating IPs broken in latest 7.0.0.0rc1? Status in kolla-ansible: New Status in neutron: New Bug description: Kolla-Ansible 7.0.0.0rc1 with binary image build (since the source option is failing to build ceilometer images currently) on CentOS 7.5 (latest updates) What worked previously does not appear to work anymore. I'm not sure if this is due to an update in CentOS 7.5 or OVS or other at this stage, but compute nodes are no longer ARP replying to ARP requests for who has the floating IP. For testing, I looked for the IP assigned to the FIP namespace's fg interface (in my case, fg-ba492724-bd). This appears to be an IP on the ext-net network, but is not the floating IP assigned to a VM. Let's call this A.A.A.A and the floating IP B.B.B.B. I can tcpdump traffic on the physical port of the compute node and see the ARP requests for both A.A.A.A and B.B.B.B with respective pings from the Internet, but no ARP replies. I have attached a diagram showing, what I believe to be, the correct path for the packets. There appears to be something broken between my two arrows. Since tcpdump is not installed in the openvswitch_vswitchd container, nor is ovs-tcpdump, I can't figure out how to mirror and sniff ports on the br-ex and br-int bridges, at least in a containerized instance of OVS. If anyone knows a way to do this, I would really appreciate the help. I haven't found any issues in the OVS configuration (ovs-vsctl show) - which matches the attached diagram. Has anyone else had issues? OVS returns this version info: ovs-vsctl (Open vSwitch) 2.9.0 DB Schema 7.15.1 in case it helps. Eric To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1792493/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp