Fail to start sdn pod when clusterCIDR is equal to hostCIDR #250
Comments
This was initially changed because it was causing issues when running crc in an OpenShift cluster. However the new one causes collisions in a different environment. Let's try a 3rd different value and see if we are lucky this time :) I picked: - an odd number - bigger than 200 in the hope that sysadmins are less likely to see this as a good value to use for internal networks. This commit also picks smaller network ranges for the serviceNetwork and clusterNetwork, as snc is single node, a /22 for clusterNetwork should be plenty enough. A /23 can't be used because of openshift/sdn#250 This also changes the service network to use a /23 right after the network used for clusterNetwork. This means crc uses addresses from 10.217.0.0 to 10.217.5.255.
This was initially changed because it was causing issues when running crc in an OpenShift cluster. However the new one causes collisions in a different environment. Let's try a 3rd different value and see if we are lucky this time :) I picked: - an odd number - bigger than 200 in the hope that sysadmins are less likely to see this as a good value to use for internal networks. This commit also picks smaller network ranges for the serviceNetwork and clusterNetwork, as snc is single node, a /22 for clusterNetwork should be plenty enough. A /23 can't be used because of openshift/sdn#250 This also changes the service network to use a /23 right after the network used for clusterNetwork. This means crc uses addresses from 10.217.0.0 to 10.217.5.255.
This was initially changed because it was causing issues when running crc in an OpenShift cluster. However the new one causes collisions in a different environment. Let's try a 3rd different value and see if we are lucky this time :) I picked: - an odd number - bigger than 200 in the hope that sysadmins are less likely to see this as a good value to use for internal networks. This commit also picks smaller network ranges for the serviceNetwork and clusterNetwork, as snc is single node, a /22 for clusterNetwork should be plenty enough. A /23 can't be used because of openshift/sdn#250 This also changes the service network to use a /23 right after the network used for clusterNetwork. This means crc uses addresses from 10.217.0.0 to 10.217.5.255. (cherry picked from commit e3ae681)
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closing this issue. In response to this:
Instructions 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. |
When running a single node, the user might configure the network like this:
We tried it for CRC and sadly it fails (see crc-org/snc#311). The installer fails: the sdn pod exited with the following error.
When looking at the code, the failure seems to be related to the fact that
route -ndoesn't contain any routes to the cluster CIDR which is normal in the single node case.Would it be enough to remove this check in the case of clusterCIDR == hostCIDR ?
The text was updated successfully, but these errors were encountered: