Day 40 — Route-Reflector Path Hiding and Optimal Route Reflection
1. Opening
Route reflection can hide paths. A reflector generally selects a best path and reflects that view; clients may therefore never learn alternatives that would have been available in a full mesh. This can create suboptimal egress and can interact with convergence.
The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture.
2. Concept and standards behavior
RFC 4456's reduction of routing information creates the path-hiding problem. RFC 7911 ADD-PATH allows multiple paths for the same NLRI to be advertised when negotiated. RFC 9107 defines Optimal Route Reflection, in which the reflector can calculate client-appropriate optimal paths using client location/IGP perspective. These mechanisms solve different problems and must not be conflated.
A recurring rule in this module is that configuration scale and routing-information scale are different problems. A design can be easy to configure but still create poor path visibility, slow convergence, or an oversized blast radius. Conversely, a topology can carry complete information but be operationally expensive to maintain.
3. Scenario
Use two exits for 203.0.113.0/24. RR1 has lower IGP cost to Exit-A, while Client-B is physically closer to Exit-B. Without additional mechanisms, RR1's own best-path view can cause Client-B to receive a path that is not locally optimal.
Documentation-safe addressing is used. The common lab AS is 65010. Internal loopbacks use 192.0.2.0/24 host routes; external test prefixes use 203.0.113.0/24 and 198.51.100.0/24 where needed. All fictional failures are lab-only.
Success criteria
- Every speaker learns the routes it is supposed to learn.
- The propagation rule can be explained before commands are applied.
- Loop-prevention attributes are visible where the feature uses them.
- A negative test proves that an invalid or unintended propagation does not occur.
- Rollback returns the topology to a known-good control-plane state.
4. Topology diagram
 |
| Route-Reflector Path Hiding and Optimal Route Reflection |
5. Prerequisites
- IOS XE 17.18.x documentation baseline.
- Stable IGP reachability among BGP loopbacks.
- Explicit
update-sourceand appropriate neighbor reachability for loopback-based sessions. - Authentication only if the lab image and design have been validated for it.
- Independent management access before changing route-reflection/confederation policy.
- Pre-change capture of BGP summary, selected paths and relevant neighbor state.
6. Baseline configuration
Topic-specific configuration excerpt — not a complete device configuration.
router bgp 65010
! Route-reflector baseline omitted for brevity.
!
address-family ipv4
! Verify platform support and exact ADD-PATH/ORR syntax
! before enabling either mechanism.
exit-address-familyDo not silently transfer this syntax to IOS XR or NX-OS. Those platforms must use their own policy/configuration model.
7. Verification before modification
Use a combination of topology, session and route evidence:
show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors
show ip routeFor route-reflection topics also inspect the path detail for ORIGINATOR_ID and CLUSTER_LIST where present. The absence or presence of a route must be explained by the propagation rule, not guessed from neighbor state alone.
8. Controlled modification
First reproduce path hiding with ordinary reflection. Then, in a capability-appropriate lab, compare the information made available by ADD-PATH with the client-specific selection objective of ORR.
Predict the exact peers whose Adj-RIB-In/Loc-RIB should change. Then apply one control-plane change, re-check path detail, and verify that no unrelated peer loses reachability.
9. Fault injection
Illustrative lab — not a real incident.
Manipulate IGP cost so the reflector and a distant client have different closest exits. If the client never receives the alternative, troubleshooting the client's local BGP policy alone cannot fix the missing information.
Capture the state before and after the fault. A useful fault must change one causal variable only.
10. Step-by-step troubleshooting
- Confirm IGP reachability among BGP endpoints.
- Confirm TCP/BGP sessions are Established.
- Identify where the route originated.
- Trace the route one BGP hop at a time.
- Determine whether the receiving neighbor is eBGP, ordinary iBGP, RR client, RR non-client, or confederation peer.
- Inspect best-path state before assuming propagation is broken.
- Inspect ORIGINATOR_ID/CLUSTER_LIST for reflected routes.
- Inspect policy and next-hop reachability.
- Verify whether an alternative path was never learned, learned but not selected, or selected but not advertised.
- Apply the smallest proven correction.
- Re-run the same positive and negative tests.
- Observe stability before closing the change.
11. Root cause and correction
The cause is information reduction at the reflector, not necessarily an incorrect client policy. Correct by redesigning reflector placement or using a supported path-diversity/optimal-reflection mechanism after validating platform behavior.
The correction must address the architectural cause rather than adding random neighbor statements until the route appears.
12. Post-fix verification
Verify:
- all intended sessions remain Established;
- the expected prefix is learned by the intended speakers;
- reflected attributes are correct where applicable;
- next hop remains reachable;
- no routing loop is created;
- the negative propagation test still passes.
13. Rollback
Restore the previous neighbor relationship or policy, not an ad-hoc alternative. If the change affects route reflection, preserve enough connectivity that clients do not become isolated during rollback. Roll back for unexpected loss of route visibility, oscillation, unintended path change, or evidence that the design created a larger failure domain than approved.
14. Production lessons
Path visibility is a design input. ADD-PATH increases path diversity; ORR changes which path is optimal for a client perspective. More paths can improve decisions but also increase control-plane state.
Deep-dive engineering notes
Path hiding begins with information reduction
In a full mesh, a speaker can potentially learn alternate paths directly from their originators. With route reflection, the reflector's decision can become the information boundary. If RR1 selects Exit-A and never advertises Exit-B's alternative to a client, the client cannot select Exit-B regardless of its own lower IGP cost to that exit.
This is why local troubleshooting at the client can be misleading. The client's BGP table may be internally consistent; it simply never received the alternative. The correct diagnostic question becomes “which paths were available at the reflector, which one did it select, and which paths did it advertise?”
ADD-PATH and ORR solve different dimensions
RFC 7911 ADD-PATH allows multiple paths for the same NLRI to be advertised with path identifiers when capability negotiation permits it. The client gains more path diversity and can make a richer local decision. The cost is additional control-plane state and update volume.
RFC 9107 Optimal Route Reflection aims at a different problem: the RR can select paths using a perspective appropriate to the client, such as the client's location in the IGP topology. ORR is therefore about selecting a client-optimal view; ADD-PATH is about advertising multiple paths. A design may use one, the other, neither, or platform-specific combinations.
Reflector placement can mitigate or amplify hiding
If the reflector's network location and IGP perspective closely match its clients, its selected path may already be acceptable for those clients. Centralizing a single RR far from diverse client populations increases the chance that the RR's hot-potato choice differs from the client's best exit.
Scale trade-off
Path diversity is not free. More paths can increase Adj-RIB-Out state, memory, update processing, and downstream selection work. Before enabling a feature globally, identify the prefixes or address families that benefit and establish measurable convergence or optimality objectives.
Verification strategy
Capture the same prefix at Exit-A, Exit-B, RR, and client. Record all available paths at the RR, the selected path, and the client's received paths. That four-point evidence proves whether the issue is path hiding, client policy, or next-hop resolution.
15. Knowledge check
- Which problem in this post is a control-plane topology problem rather than a command-syntax problem?
- What evidence distinguishes “route was never learned” from “route was learned but not selected”?
- What negative test proves the scaling feature has not introduced unintended propagation?
Answers
- The relationship among BGP speakers and the rules governing propagation.
- Per-prefix BGP path detail and neighbor route evidence.
- Verify a route that should remain hidden/unadvertised is absent from the relevant neighbor's learned/advertised state.
16. Sources
- RFC 4456 — route reflection
- RFC 7911 — ADD-PATH
- RFC 9107 — BGP Optimal Route Reflection (ORR)
