BGP Optimal Route Reflection (ORR) Explained

A route reflector that sits outside the forwarding path is a well-known source of suboptimal routing: the reflector selects a best path based on its own IGP metric, and every client inherits that decision even if its own nearest exit is completely different. BGP Optimal Route Reflection (ORR), standardised in RFC 9107, solves this by letting the reflector compute a per-client (or per-client-group) best path using the IGP metric from the client's vantage point instead of its own. This article explains when ORR matters, how the decision process changes, and how to configure it on a modern implementation.

The problem with plain route reflection

In a typical two-tier design, a handful of reflectors in the core reflect routes between all leaf clients. Each reflector runs the standard best-path algorithm and advertises one winner. Because the algorithm compares IGP cost to the NEXT_HOP as seen by the reflector, a leaf whose own uplink is the shortest path to the destination can still receive traffic pinned to a different edge — its own traffic now traverses the core twice.

Leaf-1 -> Edge-A = 10 (its own uplink, best for Leaf-1)
Reflector -> Edge-A = 30, Reflector -> Edge-B = 10
Reflector picks Edge-B and advertises it to everyone
=> Leaf-1 sends traffic toward Edge-B, adding ~40 cost of tromboning

Adding reflectors does not fix it; it only makes the affected set smaller and the failure harder to see.

What ORR changes

ORR keeps the standard tie-breaking order but replaces the IGP-metric step with a per-client computation. The reflector needs to know the IGP cost from each client to each candidate next hop, which it derives either by running a shadow IGP topology (a second, client-anchored SPF) or by importing reachability information from the IGP itself.

The practical outputs are:

- per-client-group best path selection
- clients with identical topology share a group (scalability)
- fallback to normal reflection when no ORR data exists
- optional ORR cost community to pin selection explicitly

How ORR interacts with the standard algorithm

ORR is not a replacement for the 13-step algorithm — it substitutes the step where IGP cost to next hop is compared. Attributes with higher precedence still win first:

1. WEIGHT / administrative distance (local preference)
2. LOCAL_PREF
3. locally originated
4. AS_PATH length
5. ORIGIN
6. MED
7. eBGP over iBGP
8. >>> IGP metric to next hop  <<< ORR changes this step
9. multipath
10. router-id / peer address tie-breakers

The ordering is worth internalising before designing ORR policies; a shared reference for the unmodified order is BGP best path selection step by step.

Configuration sketch

! conceptual CLI — naming varies by vendor
router bgp 65000
 address-family ipv4 unicast
  bgp bestpath optimal-route-reflection
  orr-group LEAF-1
   client-group 10.0.1.0/24
  !
  neighbor 10.0.1.1 remote-as 65000
  neighbor 10.0.1.1 orr-group LEAF-1
 !

Two design rules matter more than the syntax. First, group clients aggressively: hundreds of per-client SPFs defeat the purpose, while grouping by access-pod or by rack captures almost all of the benefit. Second, keep the reflector's own traffic out of the optimised set unless it happens to be a client too.

ORR cost community

Implementations that support the BGP cost community can encode an insertion point so that ORR-derived cost is compared at a defined position in the algorithm. That allows an operator to make ORR advisory (compared late, after MED) or authoritative (compared early, before MED) without rewriting local preference everywhere.

set community cost 1 point-of-insertion pre-bestpath
! alternatively: point-of-insertion after-igp-cost

Verification and pitfalls

show bgp ipv4 unicast  bestpath     ! per-client best path evidence
show bgp orr groups                          ! group membership and topology
show ip route 
traceroute from two leaves to the same destination

Pitfall                                  Effect
Too many client groups                   CPU/memory growth, slower convergence
Stale IGP data for the shadow topology   ORR picks an unreachable exit
ORR enabled but no groups defined        behaviour silently reverts to normal
Multipath expectations                   ORR selects, ECMP still needs maximum-paths

If you monitor BGP health with BMP, remember ORR changes per-client decisions, so a single collector view can look "wrong" — see BGP Monitoring Protocol setup. Design-time comparisons with plain reflection and confederations are in confederation vs route reflector.

FAQ

Q: Is ORR worth it in a small network? Usually not — with two or three exit points and a symmetric IGP, the reflector's view is already correct. ORR pays off in large fabrics with many roughly equal exits.
Q: Does ORR break route reflection RFC compliance? No. RFC 9107 is an informational standard that explicitly preserves RFC 4456 compatibility for clients that cannot use ORR data.
Q: How does it interact with add-path? They are orthogonal; add-path advertises multiple paths, ORR decides which one each client should prefer.

原文链接：https://www.rfc-editor.org/rfc/rfc9107.html