4 Commits

Include renames

Author	SHA1	Message	Date
claude-bot	56d55b6228	feat(bgp): let the UDM accept sessions from the ingress VLAN too ... First step of moving the world-to-pod class onto ingress0 (#576). This changes nothing about where the cluster peers from — it only widens what the UDM will accept. The order matters. Cilium's sessions are outbound to the UDM, and the UDM accepts them through `bgp listen range`. Moving the cluster to ingress0 before the UDM listens on 10.2.47.0/24 would drop every session, and with them every advertised LoadBalancer VIP, so external ingress would go down until the UDM caught up. Listing both segments first removes that window entirely: a listen range only accepts a session, it never opens one, so the 47 ranges sit idle until the cluster actually moves. The prefix-lists and route-maps are untouched. They filter which prefixes the UDM accepts — pod CIDRs and the LB pool — and the cluster advertises the same prefixes either way. Only the next hop changes. Uploaded by hand at UniFi UI -> Settings -> Routing -> BGP, as before. Verify with `vtysh -c "show ip bgp summary"`: the six existing sessions on 10.2.40.x and fd40:: must still be established afterwards, and no new ones appear until the cluster side moves. The 40 ranges come out in a later change, once every session is established on 47. Refs #576	2026-09-08 14:57:49 +02:00
k.rennerandClaude Opus 4.7	e95dba9049	bgp: split into parallel v6 + v4 sessions; v6 peers at fd40::1 ... The single v4-transport multiprotocol session couldn't actually deliver v6 routes: Cilium 1.19 BGPv2 advertises extended-nexthop capability only for the IPv4 Unicast AFI/SAFI tuple, so v6 routes sent with the IPv4-mapped MpReach next-hop landed in the UDM's BGP RIB but never made it to the kernel FIB. The kernel can't resolve an IPv4-mapped v6 address as a v6 next-hop on a v6 interface, and there's no CRD field in Cilium 1.19 to fix the capability advertisement. Solution is structural: run two parallel sessions, one per family. fd40::/64 already has SLAAC addresses on every cluster node and a ULA fd40::1 on UDM's br40, so peering natively over v6 needs no new addressing — just a second peer entry on each side and an additional listen range on UDM. v6 routes flow with v6 next-hops, v4 routes flow with v4 next-hops, neither path depends on extended-nexthop. fd40::1 (ULA) is the v6 peer address rather than the GUA so the session survives ISP renumber events. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 21:55:57 +02:00
k.rennerandClaude Opus 4.7	8e26899e89	unifi(bgp): enable extended-nexthop capability for IPv6 over v4 session ... Cilium BGPv2 carries v6 unicast routes over the single IPv4 BGP session with the peer's v4 source as the MpReach Nexthop (RFC 5549/8950). FRR must advertise the extended-nexthop capability to accept and install those routes; without it the v6 SAFI completed negotiation, Cilium sent the /128s, but the UDM either rejected them or installed them as unresolvable. Result: ping -6 mqtt.renner.uno fell through to the default route and the ISP gateway returned ICMPv6 No Route. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 21:40:23 +02:00
k.rennerandClaude Opus 4.7	663d718fe5	unifi: BGP FRR config file for upload to UDM ... The actual FRR config the UDM consumes — pairs with the cluster-side cilium-bgp.yaml. Uploaded via UniFi UI → Settings → Routing → BGP as bgp.conf. Lives in version control so the source-of-truth for what's running on the UDM matches what's intended; the UI upload itself is manual (no GitOps path to the UDM). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 21:24:42 +02:00