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