yahoo-eng-team team mailing list archive

[wondra <wondra@xxxxxxxx>]

Public bug reported:

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.

** 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/1596473

Title:
  Packet loss with DVR and IPv6

Status in neutron:
  New

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