The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.
Try it free

14-day access to the full LogicMonitor platform

The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

BGP MONITORING

BGP Route Reflector

Full-mesh iBGP doesn’t scale. BGP route reflectors solve that problem by allowing a single router to reflect routes to all iBGP peers without the exponential connection overhead. Here’s how to implement them.

5–8 minutes
Denton Chikura

CHAPTERS

    NEWSLETTER

    Subscribe to our newsletter

    Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

    SHARE

    The quick download:

    BGP route reflectors eliminate the full-mesh iBGP requirement by allowing one router to reflect routes to all peers in the AS, making large-scale BGP deployments operationally feasible.

    • Without route reflectors, an AS with N routers requires N*(N-1)/2 iBGP sessions, at 100 routers that’s 4,950 sessions to manage.

    • Route reflectors use cluster IDs and ORIGINATOR_ID attributes to prevent routing loops while relaxing the split-horizon rule.

    • Route reflector redundancy is critical: a single RR is a single point of failure for your entire iBGP topology.

    • Deploy route reflectors in pairs for redundancy and monitor their iBGP session state and route table health as a first-tier observability signal for your entire AS.

    ManFull mesh network topologies are a vital aspect of resilient networks. However, iBGP routers do not advertise routes learned from iBGP neighbors. BGP Route Reflectors solve this problem and enable full-mesh topology within an AS and route propagation across an AS. Additionally, Route Reflectors simplify network configuration from an iBGP neighborship perspective and improve scalability.

    To help you get started with BGP Route Reflectors, let’s take a closer look at how they work and provide a walkthrough of a BGP Route Reflector configuration so you can get hands-on with it. 

    Understanding BGP

    Border Gateway Protocol (BGP) is the engine that keeps the whole internet running. Internet Service Providers (ISPs) and large enterprises use BGP to interconnect Autonomous Systems (AS) and route traffic within an AS.

    BGP comes in two flavors: internal BGP (iBGP) and external BGP (eBGP). iBGP connects routers within an AS, while External BGP (eBGP) connects routers in different Autonomous Systems.

    To understand BGP Route Reflector, it’s important to understand how iBGP advertises network paths to neighbors.

    eBGP uses the AS_PATH attribute to avoid routing loops. The router will discard the route if it sees its own AS number on the list. iBGP, on the other hand, is used entirely within the AS and requires a different approach. iBGP uses the split-horizon rule, which means that if a BGP router receives a route from iBGP peering, it does not advertise that route to other iBGP peers. 

    Because of how iBGP route advertisement works, administrators need to work around it to ensure full connectivity. The three options for doing that are as follows:

    • Full Mesh Topology – Full mesh topology requires every router to establish peering with every other router. The formula for this is N(N-1)/2. For example, having 10 routers will result in 10(10-1)/2 = 45 peerings. This topology can quickly get out of hand if we deal with larger networks.
    • Route Reflector – A Route Reflector is a designated router that will reflect routes learned from other iBGP peers. All routers form a peering relationship only with the Route Reflector. In our case of 10 routers, this will result in only nine peerings instead of 45, as compared to the full mesh topology.
    • BGP Confederation – BGP confederation is an alternative method that reduces the number of peerings required, although it is sometimes used in conjunction with Route Reflectors. A confederation employs nested autonomous systems into the original AS and is also advertised as a single AS to external peers. The nested autonomous systems are also forming eBPG peerings between themselves and thus avoid using Route Reflectors.

    Standard Route Reflector topology

    A Route Reflector simplifies an iBGP network when it comes to route propagation. However, it also creates a single point of failure. If the Route Reflector crashes, the entire network will be affected.

    Clustering Route Reflectors is a standard solution to that problem. In a cluster configuration, each Route Reflector has a Cluster-ID (a four-byte string that can be manually configured or taken from the Router ID). Some cluster configurations give each Route Reflector the same Cluster-ID, while others assign a unique ID to each one. 

    BGP route reflector and the types of iBGP routers

    The broad categories of iBGP routers are Route Reflectors, Route Reflector clients, and Route Reflector non-clients. 

    There are a few rules that BGP Route Reflectors obey when it comes to route propagation:

    • Routes learned from Route Reflector clients are advertised to other RR clients and RR non-clients.
    • Routes received from RR non-clients are advertised to RR clients only.
    • Routes learned from eBGP neighbors are reflected to RR clients and RR non-clients.
    • Only the best routes are reflected if there are multiple possible routes.
    • The Route Reflector cannot change any attributes, including the next-hop address.

    Avoiding routing loops with Route Reflector

    iBGP networks with Route Reflectors use the optional non-transitive BGP attributes Originator ID and Cluster-ID to avoid routing loops.

    The Originator ID is the actual Router ID that originated the route. It helps with loop prevention when the router sees its Originator ID in the list and discards the route.

    The Cluster-ID is the Router ID of the Route Reflector. A Route Reflector discards a route if it comes from its Cluster-ID.

    With Route Reflectors, the path selection process is following the standard BGP attributes as normally before evaluating Originator ID and Cluster-ID.

    • A route without Originator ID is preferred over a reflected route with Originator ID.
    • Routes with shorter Cluster lists are preferred over routes with longer Cluster lists.

    Additional BGP attributes might come into play if there is a tie between the above criteria. 

    How to configure a BGP Route Reflector 

    For this walkthrough, let’s use a simple configuration with three routers and a single Route Reflector in the middle.

    A diagram of a BGP Route Reflector configuration.

    To create this configuration, start with the following commands.

    R1(config)#router bgp 100 
R1(config-router)#neighbor 10.1.1.2 remote-as 100
    R3(config)#router bgp 100 
R3(config-router)#neighbor 10.2.2.2 remote-as 100
    R2-RR(config)#router bgp 100 
R2-RR(config-router)#neighbor 10.1.1.1 remote-as 100 
R2-RR(config-router)#neighbor 10.1.1.1 route-reflector-client 
R2-RR(config-router)#neighbor 10.2.2.3 remote-as 100
R2-RR(config-router)#neighbor 10.2.2.3 route-reflector-client

    As shown in the snippet above,only the configuration on the Route Reflector is different. We specify R1 and R3 as our RR clients in this case. 

    Next, run these commands to configure a loopback address on R1 to prove that we can advertise it to R3 through our Route Reflector. 

    R1(config)#router bgp 100
R1(config-router)#network 5.5.5.5 mask 255.255.255.255

    The “show” command below shows that the Route Reflector received a route from an RR client. We can further check if R3 knows about the 1.1.1.1 loopback address.

    R2-RR#show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  Local, (Received from a RR-client)
    10.1.1.1 from 10.1.1.1 (10.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
    R2-RR#show ip bgp neighbors 10.2.2.3 advertised-routes
BGP table version is 2, local router ID is 10.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 5.5.5.5/32       10.1.1.1                 0    100      0 i

Total number of prefixes 1

    Finally, the commands below demonstrate that R3 has learned about the loopback address, and the interesting fields to note are the “Originator” and “Cluster list” t.

    The Route Reflector has introduced the Originator to cope with loops in the network as we are bypassing the split-horizon rule now. In our example, this is the IP address of R1. An iBGP router will not accept a route if it contains its own Originator IP address.

    The other ‘Cluster list’ field is simply the Router ID of the Route Reflector. A single cluster refers to the Route Reflector and all of its clients.

    R3#show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.1.1 (inaccessible) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.1.1.1, Cluster list: 10.2.2.2
      rx pathid: 0, tx pathid: 0

    Summary

    BGP Route Reflectors reduce the number of peerings required for full-mesh connectivity in iBGP networks. Now that you understand BGP Route Reflectors, you can use them to streamline iBGP topology and improve network resilience. 

    Key takeaways to remember are:

    • BGP Route Reflectors simplify route propagation in iBGP networks.
    • Route Reflector clusters eliminate single points of failure.
    • Using Originator ID and Cluster-ID can mitigate routing loops.

    Keep your BGP topology healthy and observable.

    LogicMonitor monitors iBGP session state, route reflector health, and routing table stability so your team knows the moment something changes in your core routing infrastructure.

    FAQs

    What is a BGP route reflector?

    A BGP route reflector (RR) is an iBGP router that is configured to re-advertise routes it receives from iBGP clients to other iBGP peers, relaxing the normal split-horizon rule that prevents iBGP routers from advertising routes learned from iBGP neighbors. This eliminates the need for every router in an AS to maintain direct iBGP sessions with every other router.

    Why is iBGP full mesh not scalable?

    In a full-mesh iBGP topology, every router must establish a direct session with every other router in the AS. The number of required sessions grows quadratically: N*(N-1)/2. For a network with 50 routers, that’s 1,225 sessions. At 100 routers, it becomes 4,950. This is both operationally complex and resource-intensive, as each session consumes memory and CPU on both endpoints.

    What is a route reflector cluster?

    A route reflector cluster consists of the route reflector and its clients. Each cluster is assigned a unique cluster ID, which the RR includes in the CLUSTER_LIST attribute of reflected routes. This attribute is used to detect and prevent routing loops: if a router receives a route with its own cluster ID in the CLUSTER_LIST, it discards the route.

    Can I have multiple route reflectors in the same AS?

    Yes, and it is strongly recommended. Deploying multiple route reflectors provides redundancy, if one fails, iBGP peering is maintained through the other. Route reflectors in the same cluster should have the same cluster ID configured to ensure consistent loop detection. For large networks, a hierarchical route reflector design (with RRs peering to higher-level RRs) can further improve scalability.

    By Denton Chikura

    Technical Writer

    Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

    Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

    © LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.