[ovs-discuss] IPv6 dadfailed

[Tobias Brunner]

Hi,

> I don't use IPv6, so I don't know the specifics, but here are some
> details on how you can debug it.
> 
> * Assuming you have just one VM, on your hypervisor, a 'ovs-vsctl
> show' will show you the name of the virtual interface name (vif). So
> the first thing to do is put a tcpump on that interface to see if any
> traffic is coming through. (If there are many VMs, you will have to
> look at libvirt's xml file to get hints on vif name.)
> 
> * Assuming, you see some traffic on vif, next thing to do is, run
> 'ovs-dpctl -m dump-flows'. This will show all the flows in the kernel.
> If it is a lot of flows, it may be a better idea, to limit OVS use to
> just that one VM, so that you know that all the flows being shown is
> just that VM. If there is no bug, you may see that there is some flow
> which shows as 'drop'. Then you know that there is some problem there.
> 
> * If there is a bug, it is also likely that there is some log message
> in '/var/log/openvswitch/ovs-vswitchd.log' which shows an entry for
> every packet loss.

Thanks a lot for this suggestions. We did some deeper investigation and this 
is what we found out:

After configuring an IPv6 address on the VM guest, the neighbor solicitation 
message is sent out and immediately bounced back to the VM, leading to the 
situation that the kernel thinks there is a duplicate address. This produces 
the log entry "Mar  5 22:54:16 ubuntuutopic kernel: [ 1602.276491] IPv6: eth0: 
IPv6 duplicate address ADDRESS detected!"

The VM host is connected to the network using LACP with two uplinks. The link 
aggregation is configured on the OVS:

---- bond0 ----
bond_mode: balance-tcp
bond may use recirculation: yes, Recirc-ID : 300
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 1705 ms
lacp_status: negotiated
active slave mac: 90:e2:ba:7d:99:3d(p258p2)

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...).
Tcpdumping on another VM running on a different VM host shows that it receives 
the neighbor solicitation message two times.

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...
Another info: We already checked if maybe "hairpinning" could be the problem 
(f.e. https://bugs.launchpad.net/nova/+bug/1011134), but this seems to be 
specifically a problem of the linux bridge. And we're not using OpenStack at 
all.

Thanks for any input in advance.

Cheers,
Tobias

PS: OVS is now running with version 2.3.1.

-- 
Tobias Brunner
Linux and Network Engineer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150305/a21aee84/attachment-0002.sig>