Also take secondary CIDRs into account when checking for validity of IPv4NativeRoutingCIDR

[codablock]

The given IPv4NativeRoutingCIDR is not necessarily part of the primary
VPC CIDR and may as well be part of one of the secondary CIDRs. We should
take these into account as well before bailing out.

This PR also contains a refactoring commit to first move out the auto detection logic into its own function.

I encountered this issue in our VPC setup, which has a primary CIDR and multiple secondary CIDRs. These CIDRs are from two different classes of CIDRs: 172.16.0.0/12 and 100.64.0.0/10. We use the 172.16.0.0/12 CIDRs for nodes that must be routable inside our VPN. The 100.64.0.0/10 CIDRs are used for k8s/cilium internal IPs, e.g. POD IPs. The IPv4NativeRoutingCIDR that we specify via configuration is a CIDR that contains all the smaller CIDRs from the 100.64.0.0/10 class. This IPv4NativeRoutingCIDR however does not contain the primary VPC CIDR (which is from the 172.16.0.0/12 class), which then causes cilium to abort with a fatal message.

Also take secondary CIDRs into account when checking for validity of IPv4NativeRoutingCIDR

Related: #17762

[gandro]

Overall looks good to me! One question around the missing ENI status however.

[gandro]

Awesome, thank you!

[gandro]

/test

Job 'Cilium-PR-K8s-GKE' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sLRPTests Checks local redirect policy LRP connectivity

Failure Output

FAIL: Cannot retrieve services on cilium pod

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-GKE so I can create a new GitHub issue to track it.

Job 'Cilium-PR-K8s-1.23-kernel-net-next' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sLRPTests Checks local redirect policy LRP connectivity

Failure Output

FAIL: Cannot retrieve services on cilium pod

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.23-kernel-net-next so I can create a new GitHub issue to track it.

[codablock]

I assume that test failures are not related to this PR?

Edit: I rebased on master to ensure that I don't miss any fixes in this PR. Looking at the code again, it can't be related as the tests are using the cluster-pool IPAM so the changed code path is not even executed.

[gandro]

I assume that test failures are not related to this PR?

Yes, looking at the output, I think so too. Thanks for the rebase. I'll re-run the tests.

[gandro]

/test

Job 'Cilium-PR-K8s-1.22-kernel-4.19' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sDatapathConfig Iptables Skip conntrack for pod traffic

Failure Output

FAIL: Cannot flush conntrack table

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.22-kernel-4.19 so I can create a new GitHub issue to track it.

Job 'Cilium-PR-K8s-1.21-kernel-5.4' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sDatapathConfig Iptables Skip conntrack for pod traffic

Failure Output

FAIL: Cannot flush conntrack table

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.21-kernel-5.4 so I can create a new GitHub issue to track it.

Job 'Cilium-PR-K8s-1.23-kernel-net-next' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sDatapathConfig Iptables Skip conntrack for pod traffic

Failure Output

FAIL: Cannot flush conntrack table

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.23-kernel-net-next so I can create a new GitHub issue to track it.

[codablock]

@gandro Tests were still failing, so I did a rebase + force-push again. Can you trigger tests again?

[gandro]

/test

[codablock]

@gandro @jibi Is it possible to also backport this into 1.11? This would allow us to switch to a vanilla release when it gets released.

[jibi]

@gandro @jibi Is it possible to also backport this into 1.11? This would allow us to switch to a vanilla release when it gets released.

@codablock I nominated this PR for v1.11 backporting as I think this should be classified as a bugfix

[christarazi]

This likely fixes a bug in ENI mode where the user is utilizing secondary CIDRs and the cilium_host restoration logic doesn't account for these CIDRs (as it relies on the autodetection of the VPC CIDR which this PR fixes), introduced from #17762.

Marking as needs backport to v1.10.