BGP Route Reflector cluster-id: Configuration Guide

Inside an autonomous system, iBGP's split-horizon rule forbids a router from re-advertising routes learned from one iBGP peer to another iBGP peer. That rule prevents routing loops but forces a full mesh of N(N-1)/2 sessions as the AS grows. BGP route reflectors (RRs) break the full-mesh requirement: clients peer only with the reflector, which reflects routes between them. The catch is loop prevention - and that is exactly what the cluster and cluster-id mechanism handles. This guide explains route reflector roles, why two redundant reflectors in the same cluster must share one cluster-id, and how ORIGINATOR_ID plus CLUSTER_LIST stop reflected routes from looping.

Route Reflector Roles: Client, Non-Client, Cluster

A route reflector re-advertises iBGP routes between its clients and to non-client iBGP peers. The rules:

• Routes from a client are reflected to other clients and to non-clients.
• Routes from a non-client are reflected to clients only.
• A client does not need any special configuration - the RR marks the relationship unilaterally.

Configuring a Route Reflector on Cisco IOS

On the reflector, define each client with the route-reflector-client neighbor command under the address family:

router bgp 65001
 bgp router-id 10.255.0.1
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 update-source Loopback0
 address-family ipv4 unicast
  neighbor 10.0.0.1 route-reflector-client
  neighbor 10.0.0.2 route-reflector-client
 exit-address-family

Why Redundant RRs Need the Same cluster-id

By default the cluster-id equals the RR's router-id. If you deploy two reflectors for redundancy and leave that default, each reflector forms its own cluster and the reflected routes look as if they come from separate clusters - which can cause loops during transient states. Set the same explicit cluster-id on both reflectors of a redundant pair so they act as one logical cluster:

! Configure on both RR1 and RR2 in the same cluster
router bgp 65001
 bgp cluster-id 1.1.1.1

Loop prevention then works through the CLUSTER_LIST attribute: a reflector that receives a route whose CLUSTER_LIST already contains its own cluster-id discards the route. ORIGINATOR_ID carries the identity of the original advertiser, so the route never bounces between reflectors.

Common Mistakes

• Deploying redundant RRs without an explicit shared cluster-id.
• Making one RR a client of another RR - reflectors should peer with each other as regular non-client iBGP.
• Adding a new iBGP router but forgetting to configure it as a client on the RR.
• Forgetting that clients still need a full mesh among themselves only if they are non-clients.

Verifying Route Reflection

router# show ip bgp summary
router# show ip bgp neighbors 10.0.0.1
router# show bgp ipv4 unicast 172.16.0.0/24

Deepen your BGP knowledge with our BGP route flap damping explained, prefix-list and route-map BGP filtering, and BGP communities configuration examples.

原文链接：https://packetmentor.com/topics/bgp-route-reflectors