Hi, A quick update. DAD seems a good theory to look into. Thanks for the tip Lorenzo! I will try reproduce the issue. I see a similar error message as reported here when two Development probes are configured with the same link local and the same global IPv6 address. This idea has been around but we never got around verifying it thoroughly. We did not want create loops at RIPE NCC office network to verify it. So if it is true, some how the probe triggers Duplicate Address Detection(DAD) and disable it's own IPv6 address. May be due to temporary layer two loop? One puzzle is in some cases the probe disable the address after a while(it can be hours later, say 6 hours after a reboot) and in some other cases right after a reboot. Is the DAD continuously running in the Linux Kernel? or only when configuring an IPv6 address? I will try to figure out. I have herd other annoyances due DAD. regards, -antony On Thu, May 23, 2013 at 09:39:16PM +0900, Lorenzo Colitti wrote:
On Thu, May 23, 2013 at 6:19 PM, Tore Anderson <tore@fud.no> wrote:
Just to highlight a data point I've mentioned before: My probe did not even respond to pings to its link local address. The link local address is *not* dependent on, or initialised based on IPv6 RAs; it is always present on all interfaces with an IPv6 stack active.
Did it fail DAD on the link-local address, then?