RETICUX BGP Mastery — Day 39— Redundant and Hierarchical Route Reflectors

1. Opening

One route reflector solves session scale but can become a control-plane single point of failure. Adding a second reflector improves resilience only if clients actually peer to it, policies are consistent, and the reflectors do not share the same hidden dependency.

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 permits multiple route reflectors and cluster designs. Redundancy must be evaluated end to end: reflector processes, IGP reachability, physical failure domains, client adjacency, policy distribution and management. Hierarchical reflection can reduce session fan-out further, but it also increases path-selection layers and troubleshooting complexity.

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

Build RR1 and RR2 in AS65010. Each client peers to both. Place the two RRs on separate simulated failure domains. Compare this with a false-redundant design where both RRs depend on the same transit interface or where half the clients peer to only one.

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

1. Every speaker learns the routes it is supposed to learn.
2. The propagation rule can be explained before commands are applied.
3. Loop-prevention attributes are visible where the feature uses them.
4. A negative test proves that an invalid or unintended propagation does not occur.
5. Rollback returns the topology to a known-good control-plane state.

4. Topology diagram

Redundant and Hierarchical Route Reflectors

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable IGP reachability among BGP loopbacks.
• Explicit update-source and 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
 neighbor 192.0.2.101 remote-as 65010
 neighbor 192.0.2.102 remote-as 65010
 !
 address-family ipv4
  neighbor 192.0.2.101 activate
  neighbor 192.0.2.102 activate
 exit-address-family
!
! On each RR, mark the client as route-reflector-client
! according to that reflector's configuration.

Do 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 route

For 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

Dual-home every client to RR1 and RR2, then fail RR1. The route should remain available through RR2 if the redundancy is real.

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.

Keep RR2 operational but remove the client's session to it. Then fail RR1. This demonstrates that two reflector devices do not create redundancy unless the client relationship is also redundant.

Capture the state before and after the fault. A useful fault must change one causal variable only.

10. Step-by-step troubleshooting

1. Confirm IGP reachability among BGP endpoints.
2. Confirm TCP/BGP sessions are Established.
3. Identify where the route originated.
4. Trace the route one BGP hop at a time.
5. Determine whether the receiving neighbor is eBGP, ordinary iBGP, RR client, RR non-client, or confederation peer.
6. Inspect best-path state before assuming propagation is broken.
7. Inspect ORIGINATOR_ID/CLUSTER_LIST for reflected routes.
8. Inspect policy and next-hop reachability.
9. Verify whether an alternative path was never learned, learned but not selected, or selected but not advertised.
10. Apply the smallest proven correction.
11. Re-run the same positive and negative tests.
12. Observe stability before closing the change.

11. Root cause and correction

The failure is architectural: the supposedly redundant path is not end-to-end. Correct the client peering and validate independent IGP/transport reachability to both reflectors.

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

Redundancy should survive a realistic shared-risk failure, not just a process restart. Hierarchy is justified by scale and geography—not by a desire to draw more layers in the diagram.

Deep-dive engineering notes

Two devices are not automatically redundant

A recurring design error is to count boxes instead of dependencies. RR1 and RR2 can be separate routers yet share the same rack power, aggregation link, IGP adjacency, management plane, configuration pipeline, or software defect. Redundancy should be assessed using shared-risk groups rather than device count.

Clients also need redundant adjacency. If Client-A peers only to RR1 and Client-B peers only to RR2, each client still has a single reflector dependency. A properly dual-homed client design lets either reflector continue distributing reachable paths after the other fails.

Cluster design deserves explicit intent

Cluster IDs participate in reflection loop prevention. Whether redundant RRs share a cluster ID or use distinct clusters depends on the intended reflection design and path behavior. Do not copy a cluster-id convention from another network without understanding what paths may be reflected between the RRs and how CLUSTER_LIST processing will behave.

Hierarchical reflection is a scale tool with a cost

Hierarchical RRs can reduce the number of sessions and align control-plane structure with geography or network tiers. But every reflection layer can further reduce available path information and adds another place where policy or best-path choice can become suboptimal. A hierarchy should therefore have a measurable purpose: peer-scale reduction, regional autonomy, failure containment, or platform limit management.

Failure testing for real redundancy

Test at least four events separately: loss of an RR BGP process, loss of the RR's IGP reachability, loss of a client-to-RR session, and loss of the shared transport beneath both RRs. A design that survives only the first event is not convincingly redundant.

Consistency versus independence

Redundant reflectors generally need consistent baseline policy, but complete operational coupling can create correlated failure. Configuration automation should enforce intended equivalence while allowing controlled staggered deployment, canary validation, and independent rollback. Reliability comes from both similarity of intent and separation of failure.

15. Knowledge check

1. Which problem in this post is a control-plane topology problem rather than a command-syntax problem?
2. What evidence distinguishes “route was never learned” from “route was learned but not selected”?
3. What negative test proves the scaling feature has not introduced unintended propagation?

Answers

1. The relationship among BGP speakers and the rules governing propagation.
2. Per-prefix BGP path detail and neighbor route evidence.
3. Verify a route that should remain hidden/unadvertised is absent from the relevant neighbor's learned/advertised state.

16. Sources

• RFC 4456 — route-reflector clusters and loop prevention
• Cisco IOS XE 17.x — BGP route-reflector configuration
• RFC 7964 — route oscillation considerations with route reflection/confederations