Fix networking issues in RHEL/Centos 6.6 #349
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some parts of the bridge driver code needs to use a different kernel api or use the already existing apis in slightly different ways to make the bridge driver work in RHEL/Centos 6.6. This PR provides those fixes. Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
|
LGTM |
1 similar comment
|
LGTM |
mavenugo
added a commit
that referenced
this pull request
Jun 30, 2015
Fix networking issues in RHEL/Centos 6.6
mavenugo
added a commit
to mavenugo/libnetwork
that referenced
this pull request
Jul 30, 2015
As seen in moby/moby#14738 there is general instability in the later kernels under race conditions when ioctl calls are used in parallel with netlink calls for various operations. (We are yet to narrow down to the exact root-cause on the kernel). For those older kernels which doesnt support some of the netlink APIs, we can fallback to using ioctl calls. Hence bringing back the original code that used netlink (moby#349). Also, there was an existing bug in bridge creation using netlink which was setting bridge mac during bridge creation. That operation is not supported in the netlink library (and doesnt throw an error either). Included a fix for that condition by setting the bridge mac after creating the bridge. Signed-off-by: Madhu Venugopal <madhu@docker.com>
mavenugo
added a commit
to mavenugo/libnetwork
that referenced
this pull request
Jul 30, 2015
As seen in moby/moby#14738 there is general instability in the later kernels under race conditions when ioctl calls are used in parallel with netlink calls for various operations. (We are yet to narrow down to the exact root-cause on the kernel). For those older kernels which doesnt support some of the netlink APIs, we can fallback to using ioctl calls. Hence bringing back the original code that used netlink (moby#349). Also, there was an existing bug in bridge creation using netlink which was setting bridge mac during bridge creation. That operation is not supported in the netlink library (and doesnt throw an error either). Included a fix for that condition by setting the bridge mac after creating the bridge. Signed-off-by: Madhu Venugopal <madhu@docker.com>
mavenugo
added a commit
to mavenugo/libnetwork
that referenced
this pull request
Jul 30, 2015
As seen in moby/moby#14738 there is general instability in the later kernels under race conditions when ioctl calls are used in parallel with netlink calls for various operations. (We are yet to narrow down to the exact root-cause on the kernel). For those older kernels which doesnt support some of the netlink APIs, we can fallback to using ioctl calls. Hence bringing back the original code that used netlink (moby#349). Also, there was an existing bug in bridge creation using netlink which was setting bridge mac during bridge creation. That operation is not supported in the netlink library (and doesnt throw an error either). Included a fix for that condition by setting the bridge mac after creating the bridge. Signed-off-by: Madhu Venugopal <madhu@docker.com>
mavenugo
added a commit
to mavenugo/libnetwork
that referenced
this pull request
Aug 7, 2015
moby#349 brought in changes to support Older kernels which included a fix to bring down the sandbox side of veth in order to set mac-address. But this seems to cause various hard to trace timing issues with the later kernel versions. Signed-off-by: Madhu Venugopal <madhu@docker.com>
crawford
pushed a commit
to crawford/docker
that referenced
this pull request
Sep 16, 2015
As seen in moby#14738 there is general instability in the later kernels under race conditions when ioctl calls are used in parallel with netlink calls for various operations. (We are yet to narrow down to the exact root-cause on the kernel). For those older kernels which doesnt support some of the netlink APIs, we can fallback to using ioctl calls. Hence bringing back the original code that used netlink (moby/libnetwork#349). Also, there was an existing bug in bridge creation using netlink which was setting bridge mac during bridge creation. That operation is not supported in the netlink library (and doesnt throw an error either). Included a fix for that condition by setting the bridge mac after creating the bridge. Signed-off-by: Madhu Venugopal <madhu@docker.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some parts of the bridge driver code needs to use a different kernel
api or use the already existing apis in slightly different ways to
make the bridge driver work in RHEL/Centos 6.6. This PR provides
those fixes.
Signed-off-by: Jana Radhakrishnan mrjana@docker.com