[atlas] Probe doesn't seem to automatically recover from IPv6 connectivity failure

* Antony Antony

> DAD seems a good theory to look into. Thanks for the tip Lorenzo! I
> will try reproduce the issue.

Agreed, failing DAD could explain the problem.

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

In my case, there are no physical loops in the network, but since it's
connected straight to a CPE (which contains internal software bridges
and switch modules and the like) it's certainly not impossible that some
packets are being looped during initialisation/bootup. In my experience,
CPEs do all sorts of crazy things...

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

DAD is run when an address is added to an interface, or when the
interface transitions to the UP state, I believe. When completed (either
successfully or unsuccessfully), it is never retried. As I understand
it, anyway. (DAD can be a very nice DoS attack actually!)

One theory could be that the CPE rebooted, which made the probe's uplink
go DOWN/UP, triggering DAD. If the CPE was retransmitting the probe's
own packets back to itself at this point, DAD could have failed, and the
probe would be left without IPv6 connectivity. OTOH
unplugging/replugging the probe didn't solve the problem for me, but
perhaps once the address goes into a DAD-failed state, a link DOWN/UP
event won't help either. Or maybe I was too quick, so that the probe
didn't register the DOWN/UP events.

Tore