yahoo-eng-team team mailing list archive

[wondra <wondra@xxxxxxxx>]

I've probably found the problem. On the compute nodes, I did not have
enable_distributed_routing = True
In the [agent] section of the ml2_conf.ini. As a result, the mechanism that prevents MAC address conflicts was disabled. It is interesting that it worked that good without it.

** Changed in: neutron
       Status: New => Invalid

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

Title:
  Packet loss with DVR, router MAC learned and flapping

Status in neutron:
  Invalid

Bug description:
  Already posted on the Operator mailing list without answer
  http://comments.gmane.org/gmane.comp.cloud.openstack.operators/5920

  I've stumbled upon a weird condition in Neutron and couldn't find a bug
  filed for it. So even if it is happening with the Kilo release, it could
  still be relevant. I've also read the commit logs without finding anything relevant.

  The setup has 3 network nodes and 1 compute node currently hosting a virtual
  network (GRE based). DVR is enabled. I have just added IPv6 to this network
  and to the external network (VLAN based). The virtual network is set to SLAAC.

  Now, all four mentioned nodes have spawned a radvd process and VMs are
  getting globally routable addresses. Traffic has been statically routed to
  the subnet so reachability is OK in both ways.

  However, the link-local router address and associated MAC address is the
  same in all 4 qr namespaces. About 16% packets get lost in randomly occuring
  bursts. Openvswitch forwarding tables are flapping and I think that the
  packet loss occurs at the moment when all 4 switches learn the MAC address
  from another machine through a GRE tunnel simultaneously. With a second VM on the 
  network on another compute node, the packet loss is 12%.

  Another router address and the external gateway address resides in a snat
  namespace, which exists in only one copy. When I tell the VM to route
  through that, there is no packet loss. My best solution for this so far is
  by passing a script to the VM through user-data that changes the gateway and
  adds a rc script to do the same on reboot.

  Is there any way to change the behavior to get rid of the MAC address
  conflict? I have determined that pushing a host route to the VMs is not supported
  for IPv6. Therefore, the workaround is not feasible if uninformed users will be 
  launching VMs.

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