[ovs-discuss] IPv6 dadfailed
alexw at nicira.com
Fri Mar 6 02:31:39 UTC 2015
> > Running tcpdump on the two physical uplinks shows that the neighbor
> > solicitation is sent out on both interfaces (Or maybe sent out on one and
> > received on the other, I'm not quite sure...).
> If it is the later, it makes sense that the sending VM receives it
> again. Which means that there is some sort of loop in the upstream
> If it is the former, it looks to be a OVS bug (or some sort of LACP
> negotiation issue?)
This is a good point. I suspect there is a loop in the setup causing the
> > Tcpdumping on another VM running on a different VM host shows that it
> > the neighbor solicitation message two times.
> I cannot yet reconcile this with the previous message of the sending
> VM receiving the traffic with a hairpin.
Besides checking the VM, I'd suggest you check on the HV and run
'ovs-dpctl dump-flows -m' (this will show you how the packets are forwarded
in kernel), right after you configure IPv6 on VM. 'ovs-dpctl show' will
you the mapping between port number and port name. So, we can see
how other HV process the IPv6 message and check if there is a loop.
> > I have a feeling that there *could* be something wrong with how the
> bonding in
> > OVS handles this neighbor solicitation messages.
> > Are there any ideas from the community on this topic? We're not yet sure
> if it
> > has something to do with OVS, but at the moment we're searching in this
> > direction...
> Are you using OVS tunnels? If so, one idea could be to connect VM
> vifs to a OVS bridge. But use Linux bonding to carry the tunneled
> traffic out of the machine. Another option to try out is not to use
> LACP bonds but rather something like active-backup (man
> ovs-vswitchd.conf.db -> Bonding Configuration)
This is a good suggestion.
> I have added 2 people familiar with OVS bonding code. They should be
> able to discern better.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss