From 96e20146a74ce6c4f6e8081da7a0ebeda97df590 Mon Sep 17 00:00:00 2001 From: Claude Bot Date: Fri, 28 Aug 2026 15:39:28 +0200 Subject: [PATCH] feat(cilium): track the BGP switch and native-routing CIDRs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Step 1 of the ownership transition in PROPOSAL-cilium-single-owner.md. Nothing about ownership changes yet — this only moves three live settings out of nowhere and into git. enable-bgp-control-plane and both native-routing CIDRs existed in no file at all. They were applied by hand and are held by the `kubectl-patch` field manager on cilium-config; server-side apply left them alone, so nothing broke and nothing reported them. The peering itself was always in git as CRDs in post-crds/cilium-bgp.yaml, which is what made the gap invisible: BGP looked configured because its policy was version-controlled, while the switch that starts the control plane was not. A cold rebuild installs only what git describes, so it would have come up with two established-looking peers configured and no BGP at all. The CIDRs go with it because they are the same decision. They are a masquerading exception, not a routing statement: pod traffic to 10.0.0.0/8 and fd00::/8 leaves unmasqueraded so LAN services see real pod IPs, and that only works because BGP advertises the pod CIDRs and gives the UDM a route back. Tracking one without the other would leave a half-decision in git. This is not purely a change of ownership, which is why it is its own step and not folded into a later one. Enabling bgpControlPlane through the chart emits five companion keys the hand-patch never set, so Cilium has been running on its own internal defaults for router-id allocation among others. They should agree with the chart's; if they do not, the sessions re-establish. Verify the peers after Flux reconciles before moving to step 2. --- .../infrastructure/cilium/helmrelease.yaml | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/kubernetes/infrastructure/cilium/helmrelease.yaml b/kubernetes/infrastructure/cilium/helmrelease.yaml index 7d5febbf..0cab3b5f 100644 --- a/kubernetes/infrastructure/cilium/helmrelease.yaml +++ b/kubernetes/infrastructure/cilium/helmrelease.yaml @@ -140,3 +140,28 @@ spec: enabled: true externalIPs: enabled: true + # BGP to the UDM. The peering itself has always been in git as CRDs in + # post-crds/cilium-bgp.yaml — but the switch that starts the control plane + # was not, and neither were the CIDRs below. They were applied by hand and + # held by the `kubectl-patch` field manager on cilium-config. Server-side + # apply left them alone, so nothing broke and nothing noticed; a cold + # rebuild would have come up with BGP off while the CRDs said otherwise. + # + # This is not a free change of ownership. Enabling bgpControlPlane through + # the chart also emits companion keys the hand-patch never set — + # bgp-secrets-namespace, bgp-router-id-allocation-mode and -ip-pool, + # enable-bgp-control-plane-status-report, enable-bgp-legacy-origin-attribute + # — so Cilium has been running on its own defaults for those. Router-id + # allocation is the one to watch: if the chart's default disagrees with + # Cilium's, the sessions re-establish. + bgpControlPlane: + enabled: true + # Masquerading exception, not a routing statement: pod traffic to these + # ranges leaves unmasqueraded, so LAN services see real pod IPs. That only + # works because BGP advertises the pod CIDRs, which is what gives the UDM a + # route back. The two settings are one decision and have to move together. + # + # Pod CIDRs are 10.244.0.0/16 and fd10:244::/48 (talos/patches/cluster.yaml); + # the supernets here cover the LAN as well, which is the point. + ipv4NativeRoutingCIDR: 10.0.0.0/8 + ipv6NativeRoutingCIDR: fd00::/8 -- 2.54.0