New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[libnetwork] Calico does not work properly on systems with kernel version 4.x+ unless ipv6 network is disabled #192
Comments
Hi, thanks for the report! We're experiencing the exact same issue, but the behaviour seems very flakey. Given many retries/re-schedules, chances are most containers will be successfully started eventually. This started appearing for us when we went from 4.15.15 to 4.16.x (and now 4.18.10). We are using libnetwork, which is likely the case for OP as well. Calico tries to set an IPv6 address on a container interface that should not be v6-enabled. Logging into the container does not show a (stateless) link-local fe80 or anything auto-assigned by the kernel. The Docker network's
Could this be a fallback mechanism in case IPv6Address is empty? Newer kernel versions likely reject unwanted addresses instead of silently dropping the Netlink messages, or are rejected using a different errno. @caseydavenport @fasaxc Any ideas? |
Yes, container will be successfully started after many retries, but the network cannot communicate even if the container is already started. The same behavior with the command: |
This sounds to me like the libnetwork-plugin is trying to assign an IPv6 address when it shouldn't. It seems to decide how to do that here: libnetwork-plugin/driver/network_driver.go Lines 498 to 509 in e9d4f6c
Based off of whether or not an IPv6 LL address is available on the host. Maybe we want to make that configurable, or smarter in some way? |
@caseydavenport That's indeed what I initially thought. This can only really work properly when libnetwork-plugin can query whether or not IPv6 is enabled on the target network. The Docker network in question has There's also the case of IPv6 being enabled on the Docker network, but sysctl disabled on the system, though this shouldn't cause problems because it will still cause Any ideas how we can query |
Looks like we have some logic already to inspect the network, might be as simple as using something like this? libnetwork-plugin/driver/network_driver.go Lines 583 to 590 in e9d4f6c
|
I believe I am having the exact same problem on centos 7 with Kernel 3.10.0-957.12.1.el7.x86_64. I upgraded from 3.10.0-862.14.4.el7.x86_64 and immediately started to get the same problems. Running the following (as described above) fixed it immediately I didn't think this bug applied to me based on the title since I was still using kernel 3.x and my docker network has "EnableIPv6": false. |
So is this solved? We met this issue recently on some nodes after rebooting and it cost us a whole day to locate the issue. These issued nodes return normal after setting the kernel attributes |
I got same problem.But I didn't fix it after disable IPv6. |
How do you disable it? Maybe you need disable and restart docker daemon. |
|
Oh did you reboot your server? In my thoughts settings will rollback if you just run
And use |
It may be worthwhile mentioning this in the getting started docs (I don't think I saw it there) - this was a difficult one to track down. |
Hi, any workaround for this ? |
sysctl config disable ipv6Step 1: add this rule in /etc/sysctl.conf : Step 2: add this rule in /etc/sysconfig/network : Step 4: disable the ip6tables service : Step 5: Reload the sysctl configuration: |
When I run:
docker reported a problem:
I can run this command on standard CentOS 7.x with kernel 3.x and it also not work on ubuntu 18.04 which has kernel 4.x, I found some log in
dmesg
:So I try to disable ipv6 with command:
Then it works fine
Expected Behavior
I hope Calico 2.6 can work properly on systems with kernel version 4.x without ipv6 disabled.
Possible Solution
Disable ipv6
Steps to Reproduce (for bugs)
Context
Your Environment
The text was updated successfully, but these errors were encountered: