BGP Route Reflector Path-Hiding Mitigation Playbook — Add-Path vs ORR vs Diverse Path

Date: 2026-04-09
Category: knowledge
Audience: ISP / backbone network operators, peering engineers, routing architects

1) Why this matters

Route reflectors solve IBGP scaling, but they also introduce a classic side effect:

the route reflector chooses one best path from its own perspective and hides the other eligible paths from clients.

That becomes painful when you care about any of the following:

• hot-potato routing from the client’s point of view,
• best-exit selection in geographically asymmetric topologies,
• IBGP ECMP / multipath on edge routers,
• faster failover because clients never learned the alternate path in the first place.

This is the route-reflector path-hiding problem.

The important operator question is not “is path hiding real?”
It is:

Which mitigation should I deploy in my network: Add-Path, ORR, or a diverse-path design?

Those three solve overlapping but different problems.

2) The root cause in one page

Route reflection scales IBGP by design

RFC 4456 route reflection exists because full-mesh IBGP does not scale well. Instead of every IBGP speaker peering with every other one, route reflectors distribute routes to clients.

That scaling win is real.

But RFC 4456 also changes what clients can see

A route reflector typically:

1. receives multiple candidate paths for a prefix,
2. runs best-path selection from its own viewpoint,
3. advertises only that chosen best path to clients.

If the route reflector is not located where its clients are, this can easily create suboptimal forwarding.

Typical example:

• PE1, PE2, and PE3 all advertise the same external destination.
• The RR sees PE1 as best because PE1 is closest to the RR.
• A client PE4 is actually closer to PE3.
• But PE4 never sees PE3’s path, because the RR only reflected PE1.

So the problem is not just “one router made a different tie-break.” It is that useful path diversity was discarded before the client could make its own decision.

3) What each mitigation actually does

A. Add-Path (RFC 7911)

Add-Path extends BGP so a speaker can advertise multiple paths for the same prefix by attaching a locally assigned Path Identifier.

That means the RR can send:

• the best path,
• one or more alternates,
• and potentially enough information for clients to do correct best-path or ECMP decisions.

Core characteristics:

• protocol extension,
• capability negotiation per AFI/SAFI,
• sender/receiver support required on the session,
• more per-path advertisement state on the RR and receivers.

Practical reading: Add-Path is the most general answer when you truly need clients to learn multiple paths.

B. ORR — Optimal Route Reflection (RFC 9107)

ORR changes the RR decision process so the RR chooses the best route from the client’s perspective, not its own.

It does this by calculating IGP distance from a configured client location / root / group rather than from the RR’s physical location.

Core characteristics:

• no protocol change required on clients,
• RR needs topology awareness and link-state information,
• the RR may run per-client or per-group alternate best-path calculations,
• clients still typically receive one best path, just a better one.

Practical reading: ORR is the elegant fix for hot-potato distortion when you mostly need the right single best path rather than many paths.

C. Diverse Path / multi-plane route reflection (RFC 6774)

RFC 6774 describes a pragmatic approach: distribute additional useful paths by using parallel route-reflector planes or related designs, often to expose best + backup (or Nth-best) paths without requiring a protocol-wide Add-Path deployment.

Core characteristics:

• operational/design technique more than a pure protocol feature,
• often limited to a small number of additional paths,
• can reduce deployment friction in brownfield networks,
• usually less general than Add-Path.

Practical reading: Diverse path is the “I need a second useful path without upgrading everything” option.

4) The operator mental model

Use this shortcut:

• Need multiple paths at clients? → think Add-Path
• Need the correct single path per client/group? → think ORR
• Need best + backup with minimal protocol churn? → think Diverse Path

That is the high-level decision tree.

5) Comparison table

6) Add-Path: when it is the right answer

Add-Path is the right answer when your real need is not merely “better best path,” but preserving path diversity.

Typical fits:

• IBGP multipath on edge routers,
• clients that need alternate exits for ECMP,
• faster convergence because alternates are already present,
• multi-level RR topologies where hiding happens at more than one layer,
• advanced designs where one path is not enough.

Strengths

1. Most general mechanism

   • It directly solves the “second UPDATE overwrites the first” problem by adding a Path Identifier.

2. Lets clients decide

   • Clients can run best-path or ECMP with richer input.

3. Works beyond pure hot-potato fixes

   • It is useful for oscillation reduction, convergence improvement, and multipathing.

Costs and risks

1. Capability negotiation matters

   • Sessions must support send/receive roles for the relevant AFI/SAFI.
   • Operationally, this often means BGP session resets during enablement.

2. Per-path state increases

   • RFC 6774 explicitly calls out the memory/processing impact of maintaining advertisement state per path instead of just per prefix.

3. Path count policy becomes important

   • “Send all paths” is easy to reason about, but expensive at scale.
   • “Send best N” is cheaper, but you can accidentally preserve the wrong N from the RR’s viewpoint instead of the client’s needs.

4. Graceful-restart handling deserves testing

   • Path Identifiers are locally assigned and may not be persistent across restart.

My default recommendation

Use Add-Path when:

• you explicitly need multiple usable paths at clients, and
• you can afford the memory / control-plane overhead.

If multipath is the actual goal, ORR alone is usually not enough.

7) ORR: when it is the right answer

ORR is the right answer when your real problem is that the RR is choosing the wrong path because it is standing in the wrong place in the topology.

Typical fits:

• centralized RRs not in the forwarding path,
• large backbones with strong hot-potato behavior,
• POP-level client groups that should share the same egress preference,
• cases where clients do not need multiple paths, just the correct one.

Strengths

1. No client changes required

   • One of ORR’s biggest attractions is that RR clients can remain ordinary BGP speakers.

2. Excellent for hot-potato correctness

   • RFC 9107 directly targets the route-reflection distortion that breaks client-optimal exit selection.

3. Grouping is possible

   • ORR can be per-client, per-group, or per-RR depending on implementation and precision needs.

Costs and risks

1. The RR must know topology well

   • This is fundamentally a link-state-aware solution.
   • The RR needs enough IGP or BGP-LS knowledge to compute route preference from client locations.

2. Compute/update-group complexity rises

   • Different client groups may require different best-path outputs.
   • Vendor implementations often translate this into more update groups and more control-plane work.

3. It does not magically create path diversity at the client

   • ORR fixes “which one best path should I send?”
   • It does not solve “client needs several paths for ECMP / backup” unless paired with other features.

My default recommendation

Use ORR when:

• path hiding is mostly surfacing as suboptimal single-path exit choice, and
• you want to minimize client-side churn.

If your main complaint is “the clients should have picked a different exit,” ORR is often the cleanest answer.

8) Diverse Path: when it is the right answer

Diverse Path is a good answer when you need some extra path diversity, but not the full generality or upgrade scope of Add-Path.

Typical fits:

• brownfield networks,
• best + backup requirements,
• staged migration away from plain RR-only visibility,
• environments where only RR upgrades are practical.

Strengths

1. Can reduce deployment friction

   • RFC 6774’s pitch is exactly this: operators often need more than one path before universal Add-Path deployment is realistic.

2. Good interim architecture

   • If the business need is “one more useful path,” this can be enough.

3. Useful where hardware/software heterogeneity blocks Add-Path

   • Especially in mixed-vendor or mixed-generation estates.

Costs and risks

1. Less general

   • If you need broad multipath semantics or arbitrary N-path distribution, Add-Path wins.

2. Can turn into design complexity

   • Parallel RR planes are conceptually simple but operationally nontrivial.

3. Still needs discipline around consistent path choice

   • You can get partial benefit without fully solving all path-hiding cases.

My default recommendation

Use Diverse Path when:

• you mainly need best + backup or another small number of extra paths,
• and a full Add-Path rollout is too invasive right now.

9) A practical decision framework

Choose Add-Path if...

• clients need ECMP,
• fast local failover benefits from already-known alternates,
• you run multi-level RR topologies,
• you are comfortable budgeting more control-plane memory and churn.

Choose ORR if...

• the dominant problem is hot-potato distortion,
• clients mostly need one correct path,
• your RR platform has strong ORR support,
• you want the least client disruption.

Choose Diverse Path if...

• you need a migration bridge,
• you only need a limited number of additional paths,
• client upgrades are unrealistic,
• you can tolerate more architecture complexity to avoid protocol-wide feature rollout.

10) Rollout advice that avoids pain

Phase 0 — Prove you actually have path hiding

Before changing anything, verify:

• prefixes with multiple eligible exits,
• RR best path differs from client-local ideal path,
• client lacks alternate visibility because of RR reflection policy.

You want evidence, not folklore.

Phase 1 — Classify the symptom

Ask which failure mode dominates:

• wrong single exit → ORR
• missing alternates / no ECMP → Add-Path
• need one extra backup path, minimal churn → Diverse Path

Phase 2 — Lab with real scale assumptions

Do not only test correctness. Also test:

• RIB/FIB growth,
• update-group explosion,
• RR convergence time,
• session reset behavior during enablement,
• failure scenarios (link loss, RR restart, GR interactions).

Phase 3 — Prefer grouped deployment first

For ORR:

• start with POP/group-based roots rather than per-client if topology permits.

For Add-Path:

• start with limited AFI/SAFI and limited neighbors.
• avoid “send everything everywhere” as your first production move.

For Diverse Path:

• keep the design simple and document which path each plane is expected to expose.

Phase 4 — Add observability before wide rollout

Track at minimum:

• number of paths per prefix per client,
• RR CPU and memory,
• update-group counts,
• convergence time on topology events,
• traffic-exit distribution before vs after.

If you cannot measure whether clients are now choosing better exits, you are flying blind.

11) Common operator mistakes

Mistake 1: using Add-Path when the real need was ORR

If your only problem is wrong hot-potato exit choice, flooding clients with more paths can be unnecessary overhead.

Mistake 2: using ORR when the actual goal was ECMP

ORR improves best-path selection.
It does not automatically provide enough alternate visibility for client multipath.

Mistake 3: enabling Add-Path without careful path-selection policy

“Best N” from the sender perspective is not the same as “the N paths each client actually needs.”

Mistake 4: underestimating update-group and control-plane cost

ORR and Add-Path both move complexity into the control plane — just in different places.

Mistake 5: assuming centralized RRs are free

The farther your RRs are from forwarding reality, the more likely path hiding becomes operationally meaningful.

12) My practical bias

If I had to summarize the operator bias in one paragraph:

• Use ORR for the classic “RR chose the wrong best path for the client” problem.
• Use Add-Path when you truly need path diversity at the client.
• Use Diverse Path when you need an incremental or brownfield-friendly bridge and your requirements are modest.

In other words:

ORR fixes perspective. Add-Path preserves diversity. Diverse Path buys time.

That framing usually gets you to the right design faster than arguing abstractly about which feature is “better.”

13) Bottom line

Route reflectors are not broken — they are doing exactly what they were designed to do for scaling. The trouble is that scaling by reflecting only one best path can silently erase information that edge routers need.

So the correct response is to match the mitigation to the actual problem:

• single-path correctness → ORR,
• multi-path visibility → Add-Path,
• limited extra diversity with easier migration → Diverse Path.

If you choose with that lens, path-hiding stops being a vague BGP horror story and becomes a tractable design decision.

References

1. RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
   https://www.rfc-editor.org/rfc/rfc4456

2. RFC 7911 — Advertisement of Multiple Paths in BGP
   https://www.rfc-editor.org/rfc/rfc7911

3. RFC 9107 — BGP Optimal Route Reflection (BGP ORR)
   https://www.rfc-editor.org/rfc/rfc9107

4. RFC 6774 — Distribution of Diverse BGP Paths
   https://www.rfc-editor.org/rfc/rfc6774

5. Cisco — Border Gateway Protocol (BGP) Optimal Route Reflection
   https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/212881-border-gateway-protocol-bgp-optimal-ro.html

6. ipSpace — BGP Optimal Route Reflection 101
   https://blog.ipspace.net/2021/10/bgp-optimal-route-reflection/

7. ipSpace — Optimal BGP Path Selection with BGP Additional Paths
   https://blog.ipspace.net/2021/12/bgp-multipath-addpath/