Skip to content
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

status.networking.egressCIDRs[0] is invalid: must be valid canonical CIDR #897

Open
rhizoet opened this issue Nov 6, 2024 · 5 comments
Open
Assignees
Labels
area/networking Networking related kind/bug Bug platform/openstack OpenStack platform/infrastructure

Comments

@rhizoet
Copy link

rhizoet commented Nov 6, 2024

How to categorize this issue?

/area networking
/kind bug
/platform openstack

What happened:
After updating to Gardener 1.107.0 we get the following message:

task "Waiting until shoot infrastructure has been reconciled" failed: Shoot.core.gardener.cloud "shoot" is invalid: status.networking.egressCIDRs[0]: Invalid value: "2a13:1a81:8000::5d/32": must be valid canonical CIDR

What you expected to happen:
You should not choose the first IP that comes along. You should check which IP is the correct one. For example, we do not support IPv6 in our Gardener. However, the Router provides an IPv6. Accordingly, you should check whether the IP works or is correct.

How to reproduce it (as minimally and precisely as possible):
Upgrade to 1.107.0 and check whether a Router specifies an IPv6 in the first position.

Anything else we need to know?:

Environment:

  • Gardener version (if relevant): 1.107.0
  • Extension version: 1.42.1
  • Kubernetes version (use kubectl version): 1.29.10 / 1.30.6
  • Cloud provider or hardware configuration: Own Datacenter
  • Others:
@gardener-robot gardener-robot added area/networking Networking related kind/bug Bug platform/openstack OpenStack platform/infrastructure labels Nov 6, 2024
@benedikt-haug
Copy link

Also seeing this issue in our setup. This blocks any update to a release higher than v1.106

@kon-angelo kon-angelo self-assigned this Nov 30, 2024
@kon-angelo
Copy link
Contributor

Hi @rhizoet. I would very much like to contribute the fix but because I am lacking in access to proper ipv6 support in my environment to test properly, could you help understand the situation better ?

Accordingly, you should check whether the IP works or is correct.

AFAIK Neutron would return a singular IP (and not a range). I don't have particular reason to distrust that an IP is incorrect from an API response even if gardener later validates the IP. We do append the /32 because we were expecting an IPv4 which would probably make the IPv6 provided incorrect or at least "non-canonical".

  • Does this mean that your router gets created with multiple ExternalFixedIP ?

You should check which IP is the correct one

In that case we should probably return all of them and assign them to the egressCIDRs
I believe that we should probably return a list of IPs also in the infrastructure status.
Is there any reason that we should filter exclusively for the ipv4 only?

@benedikt-haug
Copy link

Knowing I wasn't asked but trying to be helpful regardless:

For our (unrelated) setup, it looks like this, so if one would expect the first one to be an IPv4 address this wouldn't fit
Image

@kon-angelo
Copy link
Contributor

@benedikt-haug I should extend the question to anyone involved - apologies and thank you 💯

@rhizoet
Copy link
Author

rhizoet commented Dec 4, 2024

Hi @kon-angelo, thank you for your feedback.

It is correct that our routers always receive two ExternalFixedIPs. One IPv4 and one IPv6. This is due to our Openstack setup and cannot be changed.

However, we do not actually use IPv6 in the Gardener context. But since it is not only Gardener or Kubernetes that runs on it, this cannot be changed. I have no preference as to which IPs should be used. Only IPv4 would work for me too. I don't know whether there could be setups where only IPv6 is used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking Networking related kind/bug Bug platform/openstack OpenStack platform/infrastructure
Projects
None yet
Development

No branches or pull requests

4 participants