yahoo-eng-team team mailing list archive

[Eric Miller <1792493@xxxxxxxxxxxxxxxxxx>]

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