core, ipv6: enable optimistic_dad instead of completely disabling Duplicate Address Detection#261
core, ipv6: enable optimistic_dad instead of completely disabling Duplicate Address Detection#261flouthoc wants to merge 2 commits intocontainers:mainfrom
optimistic_dad instead of completely disabling Duplicate Address Detection#261Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flouthoc The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
flouthoc
force-pushed
the
switch_optimistic_dad
branch
from
3781661 to
a6a5c14
Compare
| // Do not accept Router Advertisements if ipv6 is enabled | ||
| let br_accept_dad = format!("/proc/sys/net/ipv6/conf/{}/accept_dad", ifname); | ||
| let br_optimistic_dad = format!("/proc/sys/net/ipv6/conf/{}/optimistic_dad", ifname); | ||
| let br_accept_ra = format!("net/ipv6/conf/{}/accept_ra", ifname); |
There was a problem hiding this comment.
Question not sure about this but do we need to enable Router Advertisements ?
There was a problem hiding this comment.
I don't know. I think this was copied from cni.
|
Caution: This is a draft PR and needs to be experimented on before this can be merged. Follow discussion here: #260 |
…uplicate Address Detection We are disabling duplicate address detection for `ipv6` complelety which might not be needed so instead of setting `accept_dad` to `0` we can still do `optimistic_dad` to `1` for required interface. Some cons of using `optimistic_dad` * Might be still slower than disabling DAD. * Not good support for older kernels since it was added in later released of `3.x` Signed-off-by: Aditya R <arajan@redhat.com>
flouthoc
force-pushed
the
switch_optimistic_dad
branch
from
a6a5c14 to
613d297
Compare
|
I don't think we need to support such old kernels. The test failures are exactly the reason why we disabled dad. I guess optimistic dad does not work as hoped. |
|
@Luap99 Yeah I think it will be still slow and I am still missing the reason why do we need to enable DAD inside container is it to avoid conflicts for the new device addresses ? But nvm I'll check a few things and if this does not works out I'll close the issue. |
|
@flouthoc Can you try setting |
Signed-off-by: Aditya R <arajan@redhat.com>
|
Hi,
There are two reasons I suggested optimistic DAD should be used instead of disabling DAD completely:
I see the netcat test is still failing. I don't think that's because of the delay from optimistic DAD (that's really small, and comparable with address assignment timing), but I can try that out in a simplified scenario with a simple network namespace if it helps. |
|
Hi @sbrivio-rh, Thank you so much for the explanation. Sure could you please try to reprod this in a smaller env. That would be great help. Meanwhile I'm also trying to look at this. Thank you for the help :D |
|
@flouthoc: PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
4 participants
We are disabling duplicate address detection for
ipv6completely whichmight not be needed so instead of setting
accept_dadto0we canstill do
optimistic_dadto1for required interface.Some cons of using
optimistic_dadreleased of
3.xCloses: #260