cilium icon indicating copy to clipboard operation
cilium copied to clipboard

CFP: native route reflector

Open ar406 opened this issue 2 weeks ago • 0 comments

Cilium Feature Proposal

Thanks for taking time to make a feature proposal for Cilium! If you have usage questions, please try the slack channel and see the FAQ first.

Is your proposed feature related to a problem?

Cilium in a Layer 3 setup uses BGP, and BGP sessions are established between worker nodes and external routers. In an iBGP setup, all iBGP speakers must establish a routing session with one another (forming a full mesh) or use route reflectors in order to avoid routing loops. A route reflector is a device which can peer with multiple iBGP speakers (RR clients) and "reflect" routes to all the RR clients except the one who originated that route (see https://datatracker.ietf.org/doc/html/rfc4456). Usually, for HA reasons, multiple route reflectors are set up.

Describe the feature you'd like

It would be useful for Cilium to provide native support for route reflector functionalities, by designating (for example, through labels) one or more workers as route reflectors.

This would imply that the Cilium agents running on top of those workers would "concentrate" all routes and would be the only ones to establish peerings with the rest of the network.

Something similar was proposed with https://github.com/cilium/cilium/issues/38407, which was closed as "Not planned".

However, things may have changed because this feature is available in the enterprise release (https://isovalent.com/blog/post/isovalent-networking-for-kubernetes-118-new-routing-policy-and-observability-enhancements/#bgp-route-reflector), so it could be possible to bring this feature to the upstream version.

ar406 avatar Dec 09 '25 16:12 ar406