Network Insight · BGP Engineering Guide
BGP Route Reflectors Explained: iBGP Split Horizon and Scalable Network Design
Discover why iBGP route distribution becomes difficult as networks grow, how route reflectors help scale an autonomous system, and how engineers investigate routes that are not propagated as expected. Understand the rules. Trace the evidence. Diagnose the behaviour.
Understanding BGP Route Reflectors
Internal BGP (iBGP) distributes routing information within an autonomous system. However, the iBGP split-horizon rule means that routes learned from one ordinary iBGP peer are not normally advertised to another. This creates a full-mesh requirement that becomes increasingly difficult to manage as a network grows.
Route reflectors provide a scalable alternative. By allowing designated routers to reflect eligible routes to other iBGP peers, they reduce the need for every router to maintain a direct session with every other router.
This guide explains how route reflection works, the roles of clients and non-clients, and how ORIGINATOR_ID and CLUSTER_LIST help prevent routing loops. It then applies these concepts to a practical troubleshooting workflow for missing routes, policy issues, and next-hop reachability.
Your engineering journey: Understand iBGP split horizon → Examine route-reflector roles → Investigate loop prevention → Trace missing routes → Validate the result in the simulator.
Inside a BGP Route Reflector
Explore how route reflection reduces iBGP session requirements, how reflected routes propagate, and what to investigate when a route is missing. Select a mode, then select a router to inspect its role.
Network Insight · BGP Engineering Guide
BGP Route Reflectors Explained: iBGP Split Horizon and Scalable Network Design
Internal Border Gateway Protocol (iBGP) distributes routing information between BGP speakers within the same autonomous system. However, its route propagation rules create a scaling challenge: a route learned from one iBGP peer is not normally advertised to another iBGP peer. Route reflectors provide a way to distribute eligible routes without requiring every router to maintain a full mesh of iBGP sessions.
Understand iBGP split horizon
Learn why an ordinary iBGP speaker does not re-advertise a route learned from one iBGP peer to another, and how this rule influences network design.
Explore route reflection
Examine how a route reflector distributes eligible routes between its clients and other permitted peers, reducing the need for a full mesh.
Investigate routing behaviour
Trace route advertisements, inspect reflection rules, and identify why a prefix might be missing even when the relevant routers have connectivity.
Why route reflectors matter
In a traditional iBGP full mesh, every participating router must establish an iBGP session with every other router in that mesh. As the number of routers increases, the number of required sessions grows rapidly. Route reflection introduces a hierarchical distribution model in which designated routers can reflect eligible routes to configured clients.
Engineering principle: route reflection solves an iBGP route-distribution scaling problem; it does not remove the need to understand route eligibility, import and export policy, best-path selection, next-hop reachability, or loop prevention.
What this guide will investigate
We will follow the route from its source, examine the difference between ordinary iBGP propagation and route reflection, and investigate the attributes and rules that govern reflected advertisements. We will also explore how ORIGINATOR_ID and CLUSTER_LIST contribute to loop prevention and how to troubleshoot routes that fail to reach their intended destinations.
Next: Understand the problem. Start with iBGP split horizon and the full-mesh requirement. Once the propagation constraint is clear, we can examine how route reflectors change the distribution model and what engineers must verify in a working design.
Engineering Summary
Key Takeaways: BGP Route Reflectors
Route reflectors reduce the number of required iBGP sessions, but understanding route propagation and loop prevention is essential when designing or troubleshooting a production network.
Why Route Reflectors Exist
Standard iBGP split-horizon behaviour prevents a route learned from one iBGP peer from being advertised to another iBGP peer. Route reflectors provide a controlled alternative to a full mesh.
Clients and Non-Clients
Reflection behaviour depends on whether a route is learned from a client, a non-client, or an eBGP peer. Correct peer roles and topology design are essential for predictable propagation.
Loop Prevention
ORIGINATOR_ID identifies the route's originating BGP router, while CLUSTER_LIST records route-reflector clusters traversed. These attributes help prevent reflection loops.
Troubleshooting Missing Routes
Trace the prefix from its source through the reflector to the destination peer. Check route eligibility, best-path selection, export policy, session state, and received routes.
Engineering principle: A route being eligible for reflection does not guarantee that an UPDATE will be sent. Verify each stage of the control plane using route and peer evidence.
Table of Contents
Explore how BGP route reflectors overcome the iBGP full-mesh requirement, distribute routes across an autonomous system, prevent reflection loops, and help engineers diagnose missing routes in scalable network designs.
Why iBGP Needs a Scalable Route Distribution Design
Inside an autonomous system, BGP routers must exchange external routing information without creating routing loops or allowing every router to advertise every learned route indiscriminately. The iBGP split-horizon rule helps control that behaviour, but it creates a design challenge as the network grows. Route reflectors provide a scalable way to distribute eligible routes between iBGP speakers.
The iBGP Split-Horizon Rule
A route learned from an ordinary iBGP peer is not normally advertised to another iBGP peer. This prevents unrestricted re-advertisement, but means route distribution must be designed deliberately.
The Full-Mesh Challenge
Without route reflection or another suitable design, iBGP speakers generally need a full mesh of sessions to exchange routes throughout the AS. The number of required peer relationships grows rapidly as routers are added.
Route Reflection
A route reflector can advertise eligible routes between its clients and other permitted iBGP peers, reducing the need for every router to maintain a direct session with every other router.
Understand the difference between route learning and route distribution
Ordinary iBGP behaviour
A router can receive a route and install it in its BGP routing information base without being permitted to advertise that route to another ordinary iBGP peer.
Consequently, a route present on one router may be absent from another router's received-route view.
With route reflection
A configured route reflector applies route-reflection rules to eligible routes and distributes them to the appropriate clients or non-client peers.
The result depends on route eligibility, BGP policy, path selection, session state and other routing conditions.
What this guide will investigate
We will examine the relationship between iBGP split horizon, client and non-client roles, and the route reflector's position in the topology. We will also look at how ORIGINATOR_ID and CLUSTER_LIST help prevent route-reflection loops, then use a structured troubleshooting process to investigate routes that appear on one router but not another.
The objective is to move beyond memorising the rule and understand the evidence an engineer should inspect: session state, received routes, reflection eligibility, import and export policy, best-path selection, and next-hop reachability.
BGP Learning Centre · Interactive Architecture
Inside a BGP Route Reflector
Explore how a route reflector reduces the need for a full mesh of internal BGP sessions. Select a mode to examine the architecture and the rules governing route reflection within AS 65001.
Architecture
One reflector, fewer required sessions
RR1 maintains iBGP sessions with its clients R1 and R5, and with its non-client peers R4 and R6. The clients do not need to form a full mesh with each other just to exchange these reflected routes.
Engineer’s notes
What to remember
- All five routers shown belong to AS 65001.
- The illustrated links represent iBGP sessions to RR1.
- Client status determines how RR1 reflects routes.
BGP Route Reflectors · Section 01 Complete
What You Have Learned
A route reflector changes how iBGP distributes routes within an autonomous system. Understanding its role, its peer relationships, and the boundaries of route reflection is essential before examining the scalability problem it solves.
Three concepts to remember
The route reflector
A route reflector receives eligible iBGP routes and reflects them to permitted iBGP peers. It reduces the need for every router to maintain a direct iBGP session with every other router.
Clients and non-clients
A client is an iBGP peer configured as a client of the route reflector. A non-client is an iBGP peer that is not configured in that role. These roles affect which peers can receive reflected routes.
Reflection follows rules
A route learned from a client can be reflected to other clients and non-clients. A route learned from a non-client is reflected to clients, not to other non-clients. The source peer is not sent its own route back by the reflector.
Engineering principle
A route reflector is not simply a route repeater. Route reflection is governed by peer roles and BGP processing. Actual advertisement also depends on route eligibility, policy, session state and other BGP conditions. A topology diagram alone does not prove that a route was advertised.
iBGP Split Horizon: Why Routes Do Not Simply Pass Between Peers
A BGP route can be valid and usable by one router without being advertised to every other router in the same autonomous system. Understanding this distinction is essential to understanding route reflectors: the challenge is not simply learning a route, but distributing it to the routers that need it.
The rule that changes the design
In ordinary iBGP operation, a route learned from one iBGP peer is not advertised to another iBGP peer. This is commonly described as the iBGP split-horizon rule. It limits the re-advertisement of iBGP-learned routes and helps prevent routing loops within the AS.
Consider three routers inside one autonomous system. Router A learns an external prefix and advertises it to Router B using iBGP. Router B can receive and evaluate the route, but it does not normally advertise that iBGP-learned route onwards to Router C.
Route propagation without a reflector
This is a simplified example of route advertisement behaviour. It does not mean Router C can never learn the prefix: it may receive it through another peer, another routing mechanism, or a different valid path.
Why a full mesh becomes difficult to scale
If every router must learn routes from every other iBGP speaker, a traditional design uses a full mesh of iBGP sessions. Each router establishes a session with every other router in the same iBGP mesh. As the number of routers increases, the number of relationships grows quadratically.
| iBGP Routers | Full-Mesh Sessions | Operational Impact |
|---|---|---|
| 4 | 6 | Relatively simple to maintain |
| 10 | 45 | More peer configuration and session monitoring |
| 20 | 190 | Increasing configuration and operational overhead |
| 50 | 1,225 | Significant session-management complexity |
The figures represent unique pairwise sessions for a single full mesh. They illustrate the growth in session relationships, not the total number of routes processed or the complete resource cost of the design.
Configuration complexity
Adding a router to a full mesh requires new peer relationships with the existing routers. Configuration changes and peer consistency become increasingly demanding.
Operational visibility
Engineers must verify more sessions and determine whether a missing route is caused by reachability, policy, path selection, or advertisement behaviour.
How route reflectors address the problem
A route reflector provides a controlled way to distribute eligible iBGP-learned routes. Routers configured as clients establish iBGP sessions with the reflector, which applies the route-reflection rules when advertising routes. This reduces the need for a full mesh among all participating routers.
Route reflection does not remove the need for correct BGP policy, valid next-hop reachability, loop prevention, or deliberate redundancy. It changes the route-distribution architecture rather than bypassing BGP's path-selection and forwarding requirements.
BGP Learning Centre · Scaling iBGP
Why the iBGP Full Mesh Becomes a Problem
In a traditional iBGP design without route reflection, every BGP speaker generally needs an iBGP session to every other speaker in the same AS. Explore the mesh and calculate how the number of sessions grows.
The scaling problem
Every speaker needs a session to every other speaker
In a full mesh, each router peers with all other routers in the iBGP group. Adding routers increases the number of sessions faster than the router count itself.
Engineering takeaway
Session count is only part of the story
More sessions mean more peer relationships to configure, monitor and troubleshoot. Route reflectors reduce the full-mesh requirement by centralising route reflection, but introduce design considerations around hierarchy, redundancy and policy.
BGP Route Reflectors · Section 02 Complete
What You Have Learned
The iBGP full-mesh requirement becomes increasingly difficult to manage as a network grows. Route reflectors address this scaling challenge by changing how eligible routes are distributed between iBGP peers.
Three concepts to remember
Full mesh creates session growth
In a conventional iBGP design, every participating router must
establish an iBGP session with every other router in the full
mesh. With n routers, the number of pairwise sessions
is n(n−1)/2.
iBGP split horizon limits propagation
Under the standard iBGP propagation rule, a route learned from one iBGP peer is not advertised to another iBGP peer. This prevents unrestricted propagation and is a key reason a conventional full-mesh design is needed.
Route reflectors reduce the mesh
A route reflector can advertise eligible routes learned from one iBGP peer to other permitted peers. Clients form sessions with the reflector rather than requiring direct sessions to every other client.
Engineering principle
Reducing session count does not remove the need to understand route propagation. A route reflector changes the distribution model, but routes still depend on BGP eligibility, peer roles, policy, session state and loop-prevention rules. Fewer sessions do not mean every route reaches every router.
How Route Reflectors Distribute Routes Inside an AS
A route reflector changes the way iBGP speakers exchange eligible routes. Instead of requiring every router to form a session with every other router, a group of client routers can exchange routes through a designated reflector. Understanding the roles and advertisement rules is essential when tracing a route through a reflected iBGP topology.
The three roles in a route-reflector design
A route reflector is an iBGP speaker configured to reflect routes according to BGP route-reflection rules. Other routers can be configured as clients of that reflector. iBGP peers that are not clients of the reflector are described as non-clients.
Conceptual role diagram. A production design may contain multiple reflectors, client groups, non-client peers, and additional routing-policy boundaries.
Client
A client has an iBGP relationship with the route reflector in which it is configured as a client. Client status is a property of that relationship, not an automatic consequence of the router's physical location or name.
Route reflector
The reflector applies route-reflection rules to eligible routes. Its role does not mean that every route received from a client must be advertised to every other peer.
Non-client
A non-client is an iBGP peer that is not configured as a client of that reflector. The reflector follows different reflection rules depending on whether a route was learned from a client or a non-client.
Route-reflection advertisement rules
The route's source relationship matters. A reflector uses the peer from which it learned a route to determine the applicable reflection behaviour. These rules describe permitted route advertisement; normal BGP eligibility, policy, and best-path conditions still apply.
| Route learned from | Potential reflection destination | Rule to remember |
|---|---|---|
| eBGP peer | Client or non-client iBGP peers | Advertised according to normal BGP rules and policy; eBGP-learned routes are not subject to the iBGP-learned route reflection restriction. |
| Client | Other clients and non-client peers | An eligible client-learned route can be reflected to other clients and advertised to non-clients. |
| Non-client iBGP peer | Client peers | An eligible non-client-learned route can be reflected to clients, but is not normally advertised to other non-client iBGP peers by the reflector. |
Why client status matters when troubleshooting
Route received from a client
If the reflector learns a route from a client, investigate whether the route is eligible for reflection to the intended client or non-client destination. Check the selected path and outbound policy as well.
Route received from a non-client
If the reflector learns a route from a non-client, check whether the intended destination is a client. A route learned from one non-client is not normally reflected to another non-client by that reflector.
Reflection does not replace path selection
A route reflector still makes BGP path-selection decisions and advertises routes according to the applicable rules. The path advertised by a reflector may not represent every alternate path known across the AS. This is one reason route-reflector placement and design can influence routing visibility and, in some cases, path optimality.
The receiver must also evaluate the advertised route. A successful reflection does not prove that the receiving router will select the path or install it in the forwarding table. Engineers should verify each stage independently.
ORIGINATOR_ID and CLUSTER_LIST help prevent route-reflection loops, especially in designs with multiple reflectors.
BGP Route Reflectors · Section 3
Route Reflection: Who Receives the Route?
A route reflector does not reflect every route to every iBGP peer. The peer from which the route was learned determines the permitted reflection targets. Switch scenarios to trace the rules through AS65001.
Scenario 1: RR1 learns a route from R1
R1 is configured as a client of RR1. For an eligible route learned from R1, RR1 may reflect it to its other clients and its non-client iBGP peers, subject to normal BGP processing and policy.
- ✓R5 — another client
- ✓R4 — non-client peer
- ✓R6 — non-client peer
- —R1 — route is not reflected back to its source peer
BGP Route Reflectors · Section 03 Complete
What You Have Learned
Route reflection follows specific rules based on whether a route was learned from a client or a non-client. Understanding those rules helps you distinguish expected BGP behaviour from a genuine route-propagation problem.
Three concepts to remember
Routes learned from clients
An eligible route learned from a client can be reflected to other clients and to non-client peers, except the peer from which the route was learned. The reflector still applies normal BGP processing and export policy.
Routes learned from non-clients
An eligible route learned from a non-client is reflected to clients, but not to other non-client peers. This is an important distinction when checking why a route is visible on one router but not another.
Trace the route hop by hop
Identify the route's source peer, determine its client or non-client role, and then check the intended receiving peer. Verify session state, route eligibility, policy and advertised routes rather than relying on topology alone.
Engineering principle
Not every missing advertisement is a fault. If a route learned from non-client R4 is not advertised to non-client R6 by the same route reflector, that behaviour is consistent with the standard reflection rules. First establish whether the advertisement is expected before troubleshooting the network as broken.
ORIGINATOR_ID and CLUSTER_LIST: Preventing Route-Reflection Loops
Route reflection removes the need for a full iBGP mesh, but it introduces additional route-distribution paths. A route may pass through more than one reflector or encounter a topology that could otherwise allow it to return towards its origin. BGP route-reflection attributes help identify these conditions and prevent reflected routes from circulating indefinitely.
Why route-reflection loop prevention matters
In a simple topology with one reflector, route propagation may be straightforward to follow. In larger networks, however, multiple reflectors, client groups, and inter-reflector sessions create more complex paths. A route can be advertised through one reflector and later reach another reflector that has already participated in distributing it.
This is a conceptual example, not a guarantee that every multi-reflector path forms a loop. The attributes provide information that BGP uses to identify the route's originator and reflector history.
1. ORIGINATOR_ID: identifying the route's originator
When a route reflector reflects a route learned from a client, it adds the optional, non-transitive ORIGINATOR_ID attribute if one is not already present. The value identifies the BGP speaker that originated the route into the iBGP route-reflection process, using its BGP Identifier.
What it tells the receiver
The attribute identifies the route's originator within the route-reflection system, even after the route has been advertised through another reflector.
How it prevents a loop
If a BGP speaker receives a route whose ORIGINATOR_ID matches its own BGP Identifier, it treats the route as a routing loop and ignores it.
ORIGINATOR_ID can explain why the receiving router rejects the route as a loop.
2. CLUSTER_LIST: tracking reflector traversal
A route reflector also uses the CLUSTER_LIST attribute to record the cluster identifiers of route reflectors that have reflected the route. When a reflector reflects a route, it prepends its local cluster ID to the list. If the attribute is absent, the reflector creates the list.
What it records
The list provides a history of reflector clusters through which the route has passed. This helps a receiving reflector determine whether the route has already traversed its own cluster.
How it prevents a loop
If a reflector finds its local cluster ID already present in the received CLUSTER_LIST, it treats the route as a loop and ignores it.
Compare the two attributes
| Attribute | Purpose | Loop check |
|---|---|---|
ORIGINATOR_ID |
Identifies the originating BGP speaker for the reflected route. | A speaker ignores a route if the originator ID matches its own BGP Identifier. |
CLUSTER_LIST |
Records the reflector cluster IDs traversed by the route. | A reflector ignores a route if its local cluster ID is already in the list. |
Reading route-reflection evidence
The route has returned to its originator in the route-reflection process. The loop-prevention check explains why it is ignored.
The route has already passed through this reflector cluster. The reflector rejects it to prevent a route-reflection loop.
This does not prove the route will be advertised. Continue checking route eligibility, best-path selection, import and export policy, peer state, and next-hop reachability.
ORIGINATOR_ID tracks the route's originating BGP speaker, while CLUSTER_LIST records the reflector clusters traversed. They solve related but distinct loop-prevention problems. Neither attribute replaces ordinary BGP policy, path selection, or forwarding validation.
In a production investigation, inspect the received route and its attributes on the relevant router, compare the route-reflector configuration and cluster IDs, and trace the route's path through the topology. Attribute evidence should be interpreted alongside the actual peer relationships and route-policy decisions.
BGP Route Reflectors · Section 4
Preventing Routing Loops
Route reflection reduces the need for a full iBGP mesh, but a hierarchy of reflectors needs loop-prevention mechanisms. Explore how ORIGINATOR_ID and CLUSTER_LIST help identify routes that return to their origin or a reflector cluster.
ORIGINATOR_ID: identify the origin
When RR-A first reflects a route originated by R1, it adds R1's BGP Identifier as ORIGINATOR_ID if the attribute is not already present. If that reflected route later returns to R1, R1 can recognize its own identifier and discard the route.
Follow the route
BGP Route Reflectors · Section 04 Complete
What You Have Learned
Route reflection reduces the need for a full iBGP mesh, but it introduces additional mechanisms to help prevent routing loops. Two important attributes record information about the route's reflection history.
Three concepts to remember
ORIGINATOR_ID
A route reflector adds this attribute to a reflected route to identify the route's originator within the iBGP system. If a route returns to that originator, the router can detect the loop and reject it.
CLUSTER_LIST
A route reflector prepends its cluster ID to the
CLUSTER_LIST when reflecting a route. A reflector
that finds its own cluster ID already in the list detects
a reflection loop and rejects the route.
Read the attributes as evidence
When investigating unexpected route propagation, inspect
ORIGINATOR_ID and CLUSTER_LIST
alongside the route's source, peer relationships and
advertised-route state. These attributes provide clues about
the route's reflection path.
Engineering principle
Route reflection must preserve loop-detection context.
ORIGINATOR_ID helps prevent a route from returning
to its originator, while CLUSTER_LIST helps detect
a route returning to a reflector cluster it has already
traversed. These mechanisms complement the reflection rules;
they do not replace sound topology design and route-policy
verification.
Troubleshooting Missing Routes in a Route-Reflector Network
When a prefix appears on one BGP router but is missing from another, avoid changing configuration immediately. First establish where the route exists, identify the expected advertisement path, and collect evidence at each stage. A structured investigation separates session problems from route eligibility, reflection rules, policy, best-path selection, and forwarding issues.
A six-step troubleshooting workflow
Verify the relevant BGP sessions
Check the session between the route source and its expected next BGP speaker, then check the session between the reflector and the destination router. Confirm that the peers are established and that the expected address families are activated.
Find the route at the source
Confirm that the expected source router has learned or originated the exact prefix. Identify the peer from which it learned the route and inspect the path attributes, next hop, and route status.
Inspect what the reflector receives and selects
Check whether the route reaches the reflector. Determine whether it is accepted into the relevant BGP table and whether it is the selected path. A route visible in a received-routes view is not necessarily the route selected for advertisement.
Check reflection eligibility and peer roles
Identify whether the route was learned from a client, a non-client, or an eBGP peer. Confirm that the intended destination is configured as expected and that the applicable route-reflection rules permit advertisement to it.
ORIGINATOR_ID or CLUSTER_LIST attributes.
Inspect outbound policy and advertisement
Verify that outbound policy does not deny, modify, or otherwise prevent the route from being sent. Where supported, inspect the advertised-routes view or BGP update diagnostics to determine whether the prefix is actually being advertised to the intended peer.
Verify the receiving router and forwarding state
If the reflector advertises the route, check whether the destination receives it, accepts it, and selects it. If the route is present in BGP but traffic cannot use it, investigate next-hop reachability, the routing table, and the forwarding information base separately.
Map the evidence to the likely fault domain
| Observed evidence | Likely area to investigate | Next verification |
|---|---|---|
| Expected peer session is not established. | Transport reachability, peer configuration, authentication, or address-family negotiation. | Inspect session state and logs before investigating route reflection. |
| Source has no route for the prefix. | Route origination, upstream advertisement, import policy, or source-side path selection. | Trace the route from its origin or upstream peer. |
| Reflector receives the route but does not select it. | Best-path selection, route validity, import policy, or another preferred path. | Inspect competing paths and the platform's route-selection explanation. |
| Route is selected, but the expected peer does not receive it. | Reflection eligibility, peer roles, export policy, loop-prevention checks, or advertisement conditions. | Inspect the advertised-routes view, policy counters, and reflection attributes. |
| Destination receives the route but rejects it or selects another path. | Import policy, route validity, best-path selection, or another available route. | Compare received paths with the accepted and selected route. |
| Destination has the BGP route, but traffic fails. | Next-hop resolution, routing-table installation, forwarding state, or a downstream data-plane fault. | Trace the next hop and verify the installed forwarding entry. |
Engineer’s route-reflector checklist
ORIGINATOR_ID and CLUSTER_LIST where relevant.From theory to practical investigation
Use the Network Insight BGP learning material to connect topology, route propagation, and path selection. In the shared BGP Core Simulator, the practical objective is to follow a prefix through the relevant routers and compare the routing evidence at each stage. Use the existing simulator link configured on your Learning Centre page rather than creating a new or unverified destination.
Practical Troubleshooting
Cisco CLI: Verify Route Reflector Behaviour
Use these commands to trace a missing BGP prefix through the local BGP table, peer session and outbound advertisements. Examples use Cisco IOS / IOS XE-style IPv4 BGP syntax.
1. Check the route in the BGP table
Route presenceshow ip bgp 203.0.113.0Replace the example prefix with the affected network. Check whether the route exists, which path is selected, its next hop and relevant path attributes.
2. Verify the BGP peer session
Session stateshow ip bgp neighbors 192.0.2.2Replace the example address with the relevant peer. Verify the session state and inspect peer details and message counters where available. An established session does not prove a specific prefix is being advertised.
3. Check routes advertised to the peer
Outbound evidenceshow ip bgp neighbors 192.0.2.2 advertised-routesLook for the affected prefix in the advertised-route output. If it is missing, investigate export policy, best-path selection, route eligibility and route-reflector client configuration.
4. Inspect routes learned from the peer
Inbound evidenceshow ip bgp neighbors 192.0.2.2 routesWhere supported, use this to inspect routes accepted from the peer. Interpret the output alongside inbound policy and platform-specific command behaviour.
- Route missing locally: check the source and inbound learning.
- Route present locally but not advertised: check policy, eligibility and reflection rules.
- Route advertised but missing at the receiver: check the receiving session and inbound policy.
- Route present in BGP but forwarding fails: check next-hop reachability and the forwarding table.
BGP Route Reflector Incident Investigation
Investigate a missing prefix in an iBGP route-reflector design. Select a fault scenario, inspect the affected session or route, trace the expected reflection behaviour, and identify the evidence needed before changing configuration.
1. Inspect the route-reflector topology
Select a router or session. R1 and R5 are RR1's clients; R4 and R6 are non-client iBGP peers. The diagram illustrates the configured relationships, not live device state.
2. Select and inject an incident
Choose a troubleshooting scenario. The lab updates its diagram and evidence summary to show the expected area of investigation.
3. Inspect a router or session
Inspect the selected device's role and the expected evidence to collect during a real investigation.
4. Trace the expected route distribution
The trace shows the modeled status of the prefix at each relevant point. A route may be present at RR1 but absent at a client because of session state, reflection eligibility, loop prevention, or policy.
5. Engineer diagnosis challenge
A client reports that 10.110.110.0/24 is missing. Which investigation sequence is the strongest starting point?
Designing and Operating Route Reflectors Reliably
A successful route-reflector design is more than a way to reduce iBGP session counts. It must distribute the required routes predictably, preserve loop-prevention behaviour, maintain resilient control-plane connectivity, and provide enough visibility for engineers to diagnose routing problems quickly.
Six principles for a sound design
Plan reflector placement
Select reflector locations and client relationships deliberately. Consider topology, failure domains, routing-policy boundaries, and the operational impact of losing a reflector.
Build appropriate redundancy
Where availability requirements justify it, use multiple route reflectors and design client sessions so that a single reflector failure does not unnecessarily isolate routers from required routes.
Preserve loop prevention
Understand the purpose of ORIGINATOR_ID and CLUSTER_LIST. Check reflector and cluster configuration when a route appears to be rejected during reflection.
Control route distribution
Apply import and export policy deliberately. Confirm that intended prefixes are accepted and advertised while unwanted routes are filtered according to the network's policy.
Validate next-hop reachability
A route can be reflected successfully but remain unusable if its next hop cannot be resolved. Verify the underlay, routing table, and forwarding state independently.
Test failures and recovery
Test reflector loss, session interruption, route withdrawal, and recovery behaviour. Confirm which routes remain available and how the network converges after a failure.
Pre-deployment verification checklist
Diagnose the stage, not just the symptom
| Stage | Question to answer | Evidence to inspect |
|---|---|---|
| Session | Can the relevant peers exchange BGP messages? | Session state, address families, transport reachability, and logs. |
| Route reception | Has the router received the expected prefix? | Received routes, source peer, prefix, and path attributes. |
| Route eligibility | Can the route be accepted, selected, and advertised? | Import policy, route validity, best-path result, and reflection rules. |
| Route advertisement | Was the route sent to the intended peer? | Export policy, advertised-routes view, and update diagnostics. |
| Forwarding | Can the selected route actually carry traffic? | Next-hop resolution, routing-table entry, and forwarding information base. |
Continue the BGP learning journey
Route reflectors are one part of the wider BGP control plane. Their behaviour becomes easier to understand when studied alongside network topology, route propagation, best-path selection, and fault investigation.
Understand the routers, autonomous systems, peer relationships, and design choices that shape route distribution.
Trace how a prefix moves between BGP speakers and identify where advertisement rules affect its path.
Use routing evidence to isolate session, policy, best-path, next-hop, and forwarding problems.
The objective is to develop a repeatable engineering method: predict the expected behaviour, inspect the relevant routing evidence, identify the stage where actual behaviour differs, and validate the diagnosis before making a configuration change.
BGP Route Reflectors · Section 05 Complete
What You Have Learned
Effective troubleshooting starts with evidence. Trace the route from its source, verify the route-reflector relationships, and inspect the control-plane state before deciding why a route has not reached its intended destination.
Three troubleshooting priorities
Verify the BGP session
Confirm that the relevant BGP sessions are established and inspect the received and advertised route information. A route cannot be exchanged over a session that is down, and a missing route may have been filtered before advertisement.
Check roles and reflection rules
Establish whether the route was learned from a client or non-client. Confirm that the intended receiver is eligible under the reflection rules, then check route eligibility, import and export policy, and the selected path.
Inspect loop-prevention evidence
Examine ORIGINATOR_ID and CLUSTER_LIST
where present. Check whether a route has returned to its
originator or a reflector cluster, and compare the relevant
routing information across the affected routers.
Engineering principle
Diagnose the first point where expected behaviour diverges. Start with the originating router and follow the route through each relevant BGP session. At every step, establish whether the route was received, accepted, selected and advertised. This narrows the fault domain and avoids changing configuration before the evidence supports a cause.
From iBGP Split Horizon to Scalable Route Reflection
You have explored why ordinary iBGP route distribution requires careful design, how the full-mesh model scales, and how route reflectors help distribute routes across an autonomous system. You have also examined client and non-client relationships, reflection rules, loop prevention, and a structured method for troubleshooting missing routes.
Understand the distribution model
Explain why iBGP-learned routes are not normally re-advertised between ordinary iBGP peers, how route reflectors change that behaviour, and how ORIGINATOR_ID and CLUSTER_LIST help prevent routing loops.
Trace the route through the control plane
Determine whether a route was received, accepted, selected, reflected, and advertised to the intended peer. Then verify next-hop resolution and forwarding rather than assuming that a visible route is usable.
Route reflection improves iBGP scalability, but it does not guarantee that every route will be distributed or used. Correct behaviour still depends on route eligibility, best-path selection, policy, loop prevention, next-hop reachability, and resilient design. Diagnose each stage using evidence.
Now put your knowledge into practice
Explore the topology, follow BGP route propagation, and investigate routing behaviour in the interactive BGP Core Simulator. Continue your wider learning journey through the BGP Learning Centre.