This repository was archived by the owner on Feb 24, 2020. It is now read-only.
kvm: solve certain routing issues by using the same default bridge as CNI #3905
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.
When the kvm stage1 and the coreos stage1 are used on the same machine with a
flannel CNI configuration (and likely other configurations) without a specified
bridge name, different bridges will be constructed by each stage1 for the same
subnet -- cni0 and kvm-cni0 -- causing traffic intended for the
later-constructed bridge to be lost, as it is routed to the earlier-constructed
bridge.
The normal workaround is to specify a bridge name in the CNI configuration, but
this fix avoids the issue altogether by making sure that cni0 is used in all
cases.
I can't find any records of a specific motivation for using kvm-cni0 instead of cni0, so it's possible that I'm missing the original reason behind it, but it seems like an arbitrarily-made decision from the original development of CNI support in the kvm stage1.