BGP Optimal Route Reflection

When BGP performs best-path selection, it evaluates multiple attributes in a defined order. One of these steps is to prefer the path whose next hop is resolved through the IGP with the lowest metric. This comparison is performed from the perspective of the router making the path selection decision.

For more information about BGP path selection, see Understanding BGP Path Selection.

In networks where route reflectors are deployed on a per–point of presence basis, this behavior typically produces the desired forwarding outcome. Each route reflector reflects routes to its clients based on IGP costs that closely align with the clients’ forwarding topology.

However, in large-scale networks, a route reflector may serve client and non-client peers that are distributed across multiple geographic locations. In these deployments, the IGP metric used during BGP path selection reflects the topology from the route reflector’s location, not from the perspective of the receiving clients.

As a result, the route that appears optimal to the route reflector may not represent the best forwarding path for all clients. This mismatch can lead to suboptimal traffic forwarding, even though BGP path selection is operating correctly.

BGP optimal route reflection addresses this limitation by allowing path selection to better align with the IGP topology of the clients receiving reflected routes, rather than relying solely on the route reflector’s local view.

You can configure BGP Optimal Route Reflection (BGP-ORR), described in RFC 9107, with IS-IS and OSPF as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups. This is done by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.

Client groups sharing the same or similar IGP topology can be grouped as one BGP peer group. You can configure optimal-route-reflection to enable BGP-ORR in that BGP peer group. You can also configure one of the reflector nodes as the primary node (igp-primary) in a BGP peer group so that the IGP metric from that primary node is used to select the best path and advertise it to the clients in the same BGP peer group. Optionally, you can also select another reflector node as the backup node (igp-backup), which is used when the primary reflector node (igp-primary) goes down or is unreachable.

To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.

Note:

BGP-ORR only works when IGP is used for BGP route resolution. BGP-ORR does not work when MPLS/LDP/RSVP is used for route resolution.

Note:

For BGP-ORR to work, the BGP prefix should be resolved through an IGP. In normal Layer 3 VPN, or Layer 2 VPN, or VPLS, or MVPN, or EVPN scenarios, the prefixes are resolved over inet.3. In inet.3, the primary route for the protocol-next-hop of the prefix would be either RSVP or LDP ( and not an IGP protocol like IS-IS or OSPF). For BGP-ORR to work, you need to configure the router to use inet.0 for the route-resolution of Layer 3 VPN, or Layer 2 VPN, or VPLS, or MVPN, or EVPN prefixes. You can do this through the following commands:

• For Layer 3 VPN prefix:

• For Layer 2 VPN, or VPLS prefix:

• For EVPN prefix:

• For MVPN prefix:

Another method is to leak the IGP routes into inet.3 and make them as the primary route in inet.3.

Use the following CLI hierarchy to configure BGP-ORR: