BGP Route Reflector - Part III


In this lesson, you will learn how BGP route reflection operates across multiple clusters and how cluster IDs control route propagation between route-reflector clients.

The lab explains the difference between intra-cluster and inter-cluster reflection, the purpose of the ORIGINATOR_ID and CLUSTER_LIST attributes, and how multiple cluster IDs can be used on a route reflector.

Table of Contents

BGP Route Reflector Review

Internal BGP normally requires a full mesh between all iBGP speakers because an iBGP-learned route is not advertised to another iBGP neighbor by default.

A route reflector removes this full-mesh requirement by allowing selected iBGP routes to be reflected between clients and nonclients.

A route-reflector design normally contains:

  • Route reflector: The router that reflects routes between participating iBGP peers.
  • Route-reflector client: An iBGP peer configured as a client of the route reflector.
  • Nonclient peer: An iBGP peer that is not configured as a route-reflector client.
  • Cluster: A route reflector and its associated clients.

Why Route Reflector Clusters Are Used

A cluster provides a logical boundary for route reflection. In larger networks, multiple clusters can be used to improve scalability and organize the iBGP topology.

Cluster IDs are important because they help BGP detect and prevent route-reflection loops.

When a route reflector reflects a route, it can add its cluster ID to the CLUSTER_LIST attribute. A route reflector that later receives a route containing its own cluster ID rejects that route as a reflection loop.

Lab Topology

The topology contains multiple iBGP routers divided into separate route-reflector clusters.

The route reflector is connected to routers in the left and right clusters, with an additional router connected as part of the wider iBGP design.

The lab demonstrates:

  • Route reflection between clients in the same cluster
  • Route propagation between separate clusters
  • Cluster-ID behavior
  • ORIGINATOR_ID and CLUSTER_LIST attributes
  • Control of client-to-client reflection

Understanding ORIGINATOR_ID

ORIGINATOR_ID is an optional, nontransitive BGP attribute used by route reflectors.

When a route reflector reflects a route learned from a route-reflector client, it adds the BGP router ID of the original client as the ORIGINATOR_ID.

The attribute identifies the router that originally introduced the route into the route-reflector topology.

If a router receives a reflected route whose ORIGINATOR_ID matches its own BGP router ID, it rejects the route. This prevents the route from returning to its original source.

Example

Assume R1 advertises a prefix to its route reflector:

  1. R1 originates the prefix.
  2. The route reflector receives the route from R1.
  3. The route reflector adds R1’s BGP router ID as the ORIGINATOR_ID.
  4. The route reflector advertises the route to other eligible iBGP peers.
  5. If the route eventually returns to R1, R1 recognizes its own router ID and rejects it.

Understanding CLUSTER_LIST

CLUSTER_LIST is an optional, nontransitive BGP attribute that records the route-reflector clusters through which a reflected route has passed.

Each route reflector adds its local cluster ID to the CLUSTER_LIST when reflecting the route.

The attribute serves two main purposes:

  • Preventing route-reflection loops
  • Recording the sequence of clusters traversed by a reflected route

When a route reflector receives a route, it checks the CLUSTER_LIST. If its own cluster ID is already present, the route is rejected.

Cluster ID Selection

When no explicit cluster ID is configured, the route reflector commonly uses its BGP router ID as the cluster ID.

When redundant route reflectors serve the same cluster, both route reflectors should normally use the same explicitly configured cluster ID so that the cluster is treated consistently.

Intra-Cluster Route Reflection

Intra-cluster reflection occurs when a route is reflected between clients belonging to the same route-reflector cluster.

For example:

  1. R1 advertises a route to the route reflector.
  2. The route reflector receives the route from a client.
  3. The route reflector reflects the route to another client in the same cluster.
  4. The receiving client installs the route if it passes the normal BGP path-selection and loop-prevention checks.

Client-to-client reflection allows clients to exchange routes without establishing a direct iBGP session with every other client.

Disabling Client-to-Client Reflection

Some designs disable client-to-client reflection when the clients already have another path for exchanging routes or when the administrator wants stricter control over intra-cluster propagation.

The configuration and behavior can depend on the Cisco platform, software release, and use of multiple cluster IDs.

Inter-Cluster Route Reflection

Inter-cluster reflection occurs when a route is propagated from one route-reflector cluster to another.

During this process:

  1. The originating client advertises the route to its route reflector.
  2. The first route reflector adds the ORIGINATOR_ID and its cluster ID.
  3. The route is advertised toward another route reflector or eligible iBGP peer.
  4. The next route reflector checks the CLUSTER_LIST for its own cluster ID.
  5. If no loop is detected, the route may be reflected to clients in the second cluster.
  6. The second route reflector adds its cluster ID to the CLUSTER_LIST.

The CLUSTER_LIST therefore grows as the route crosses route-reflector clusters.

Multiple Cluster IDs

Cisco’s multiple-cluster-ID feature allows a route reflector to use more than one cluster ID.

The route reflector can have:

  • A global cluster ID
  • Additional cluster IDs assigned to specific route-reflector clients

This makes it possible to place different clients connected to the same route reflector into separate logical clusters.

Multiple cluster IDs can be useful when:

  • A single route reflector serves multiple client groups.
  • Different client groups require separate reflection behavior.
  • Client-to-client reflection must be controlled between groups.
  • The network is migrating from one route-reflector design to another.
  • The administrator wants more granular cluster organization.

A per-neighbor cluster ID should be planned carefully because it directly affects loop prevention and route-reflection behavior.

Configuration Workflow

Step 1: Configure the BGP Process

Configure the local autonomous-system number and a stable BGP router ID. 

router bgp <autonomous-system-number>
 bgp router-id <router-id>

Step 2: Define the iBGP Neighbors

neighbor <neighbor-address> remote-as <autonomous-system-number>
neighbor <neighbor-address> update-source Loopback0

The exact syntax depends on the Cisco operating system and software release.

Step 3: Configure Route-Reflector Clients

Under the required address family, identify the client neighbors: 

address-family ipv4 unicast
 neighbor <client-address> activate
 neighbor <client-address> route-reflector-client
 exit-address-family

Step 4: Configure the Global Cluster ID

Where an explicit cluster ID is required: 

router bgp <autonomous-system-number>
 bgp cluster-id <cluster-id>

This is particularly important when multiple route reflectors belong to the same redundant cluster.

Step 5: Configure Additional Client Cluster IDs

On supported platforms, an additional cluster ID can be assigned to an individual route-reflector client.

The exact command placement and syntax vary by platform and release, so the configuration should be verified against the documentation for the deployed system.

Step 6: Review Client-to-Client Reflection

Confirm whether routes should be reflected between clients in the same logical cluster.

Do not disable client-to-client reflection unless the alternative route-propagation path and expected behavior are clearly understood.

Video Demonstration

The following video demonstrates BGP route reflection with multiple clusters, intra-cluster and inter-cluster route propagation, and cluster-ID behavior.

Verification

Verify the BGP Neighbors

show ip bgp summary
show bgp ipv4 unicast summary

Confirm that all expected iBGP sessions are established.

Verify the Route-Reflector Configuration

show running-config | section router bgp
show bgp neighbors <neighbor-address>

Confirm which neighbors are configured as route-reflector clients and review the cluster-ID configuration.

Inspect a Reflected Route

show ip bgp <prefix>
show bgp ipv4 unicast <prefix>

Review:

  • Next hop
  • AS path
  • ORIGINATOR_ID
  • CLUSTER_LIST
  • Best-path status
  • Source neighbor

Verify Intra-Cluster Reflection

  1. Advertise a test prefix from one client.
  2. Confirm that the route reflector receives the prefix.
  3. Verify that another client in the same cluster receives it.
  4. Inspect the ORIGINATOR_ID and CLUSTER_LIST.

Verify Inter-Cluster Reflection

  1. Advertise a prefix from a client in the first cluster.
  2. Confirm that it reaches the first route reflector.
  3. Verify propagation toward the second cluster.
  4. Inspect the CLUSTER_LIST at each stage.
  5. Confirm that the clients in the second cluster receive the prefix.

Verify Loop Prevention

Confirm that a route is rejected when:

  • The local BGP router ID matches the ORIGINATOR_ID.
  • The local cluster ID appears in the CLUSTER_LIST.

Troubleshooting

A Client Does Not Receive Another Client’s Route

  • Confirm that both neighbors are established.
  • Verify that both are configured as route-reflector clients.
  • Check whether client-to-client reflection is disabled.
  • Confirm that the route is valid and selected as the best path.
  • Review inbound and outbound route policies.

A Route Is Rejected Because of the Cluster List

  • Inspect the CLUSTER_LIST on the received route.
  • Check for duplicate or incorrectly assigned cluster IDs.
  • Verify the cluster IDs used by redundant route reflectors.
  • Review the intended inter-cluster topology.

A Route Returns to Its Originating Client

  • Inspect the ORIGINATOR_ID attribute.
  • Verify that router IDs are unique and stable.
  • Confirm that the route reflector is adding the expected attributes.
  • Review any route-policy changes that could affect reflected attributes.

Routes Are Reflected Between the Wrong Client Groups

  • Check the global cluster ID.
  • Review per-neighbor cluster-ID assignments.
  • Confirm client-to-client reflection behavior.
  • Verify which clients belong to each intended logical cluster.

Redundant Route Reflectors Behave Inconsistently

  • Confirm that both route reflectors use the intended cluster ID.
  • Compare route-reflector client configuration.
  • Check routing policies and address-family activation.
  • Verify that the clients peer with both route reflectors.

Conclusion

BGP route reflectors improve iBGP scalability by allowing routes to be reflected between selected peers without requiring a complete iBGP full mesh.

ORIGINATOR_ID prevents a reflected route from returning to the router that originally advertised it. CLUSTER_LIST records the clusters traversed by the route and prevents a route reflector from accepting a route that has already passed through its own cluster.

Multiple cluster IDs allow a route reflector to organize different client groups into separate logical clusters and provide more control over intra-cluster and inter-cluster reflection.

Before deploying this design in production, verify unique router IDs, consistent cluster IDs, expected client-to-client behavior, route-policy operation, redundancy, and loop-prevention attributes.

Related Reading

About the Author

Ehsan Emad is a networking and cybersecurity expert with four CCIE certifications, a CCDE, CISSP, and extensive industry experience. He creates practical tutorials that turn complex networking technologies into clear, real-world solutions.