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
--
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
