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>
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>
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>
k.rennerandClaude Opus 4.7