Course contents

Module 5: Scaling and OperationsLesson 5.1 (1 of 7 in this module)31 of 43 in the BGP course

Route reflectors

iBGP has a loop-prevention rule that forces every router to peer with every other router. That does not scale past a handful of devices. A route reflector is the standard fix.

Advanced · 14 min read

You'll learn to explain the iBGP full-mesh rule, describe what a route reflector does with routes from clients and non-clients, and configure a reflector and its clients.

The full-mesh problem

iBGP has one rule that shapes everything: a router that learns a route from an iBGP peer does not pass it to another iBGP peer. That stops loops, but it means every router in the AS must peer directly with every other. The number of sessions is n × (n - 1) / 2, so ten routers need 45 and fifty need 1,225.

A route reflector replaces the iBGP full mesh
A route reflector replaces the iBGP full meshLeft: four iBGP routers in a full mesh need six sessions. Right: one route reflector with three clients needs three sessions.Full mesh: 4 routers, 6 sessionsRoute reflector: 4 routers, 3 sessionsR1R2R3R4RRC1C2C3route reflector

On small screens, swipe sideways or focus the diagram and use the arrow keys.

With n routers a full mesh needs n(n-1)/2 sessions: 6 for four routers, 45 for ten. A route reflector needs one session per client.

What a route reflector changes

A route reflector (RR) is an iBGP router allowed to break the rule. Its iBGP peers are either clients or non-clients. The reflector decides what to pass on based on who sent the route.

What a route reflector passes on
What a route reflector passes onA route learned from a client is reflected to the other clients and to non-clients. A route learned from a non-client is reflected to clients only, not to other non-clients.Learned froma clientRoute reflectorOther clients: yesNon-clients: yesLearned froma non-clientRoute reflectorClients: yesOther non-clients: no

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Non-clients still need a full mesh among themselves. The reflector only removes the need for clients to peer with everyone.
What a route reflector changes
What a route reflector changesRoute learned from; Reflected to. eBGP peer: All clients and non-clients A client: All other clients and all non-clients A non-client: Clients onlyRoute learned fromReflected toeBGP peerAll clients and non-clientsA clientAll other clients and all non-clientsA non-clientClients only

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each item on the left, with what it means on the right.

Clients need peer only with the reflector, so the mesh shrinks to one session per client. Only the reflector holds the extra configuration, and clients do not know they are clients.

Configure it

router bgp 64500 neighbor 10.255.0.2 remote-as 64500 neighbor 10.255.0.2 update-source Loopback0 neighbor 10.255.0.3 remote-as 64500 neighbor 10.255.0.3 update-source Loopback0 address-family ipv4 unicast neighbor 10.255.0.2 activate neighbor 10.255.0.2 route-reflector-client neighbor 10.255.0.3 activate neighbor 10.255.0.3 route-reflector-client

On the reflector. R2 (10.255.0.2) and R3 (10.255.0.3) are clients. Their own configuration is an ordinary iBGP session to the reflector's loopback.

Illustrative Cisco IOS XE output written for this lesson, not a router capture
RR#show ip bgp neighbors 10.255.0.2 | include Reflector
  Route-Reflector Client
The line confirms the neighbour is treated as a client. To see the loop-prevention attributes on a reflected route, run show ip bgp 203.0.113.0 on a client and look for Originator and Cluster list.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R3#show ip bgp 203.0.113.0
BGP routing table entry for 203.0.113.0/24, version 6
Paths: (1 available, best #1, table default)
  64501
    10.255.0.1 (metric 20) from 10.255.0.9 (9.9.9.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.1.1.1, Cluster list: 9.9.9.9
The route was learned from the reflector (9.9.9.9), but Originator shows R1 as the router that first advertised it and the cluster list shows the reflector it passed through.

Technical reference: RFC 4456, BGP Route Reflection. Output above is illustrative.

Configure a reflector
Configure a reflectorConfigure the clients on the reflector only.iBGP sessionsfrom clients to RROn the RRroute-reflector-clientClientsordinary iBGPVerifyshow ip bgp, originator

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Clients are unaware they are clients, so they need no special configuration.

Following one route through a reflector

Take the route to 203.0.113.0/24. ISP A sends it to R1 over eBGP. R1 is a client of the reflector, so it passes the route over iBGP to RR. RR then reflects it to every other client. R2 and R3 never peer with R1 or with each other, and still learn the route.

A route reaching two clients through one reflector
A route reaching two clients through one reflectorISP A sends 203.0.113.0/24 to R1 over eBGP. R1 is a client of the reflector RR and sends it over iBGP. RR reflects the best path to its other clients R2 and R3, adding ORIGINATOR_ID 10.255.0.1 and its own cluster ID to CLUSTER_LIST. Each client needs one session, to RR, instead of sessions to every other router.ISP AAS 64501R1clientRRreflectorR2clientR3client1 eBGP2 iBGP3 reflect to every other clientAdded by the reflectorORIGINATOR_ID 10.255.0.1CLUSTER_LIST adds RR cluster IDNext hop stays 192.0.2.1clients need a route to it

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Three clients need three sessions to the reflector, where a full mesh of four routers would need six. The reflector passes on only its best path, and the next hop is not changed.

The reflector passes on only its best path

A reflector runs the best-path algorithm like any router and reflects only the best path to its clients. If R1 and R4 both offer a path to the same prefix, the clients hear about one of them and cannot choose between them with full information. In a design where each client should pick its own closest exit, that loss of path diversity is a real cost. Features such as additional paths, covered in the Advanced BGP course, restore it.

Cluster ID: who counts as the same cluster

A reflector and its clients form a cluster. The reflector uses its router ID as the cluster ID unless you set one. When two reflectors serve the same clients, give both the same cluster ID with bgp cluster-id, so each recognises a route reflected by the other in the CLUSTER_LIST and drops it, and clients do not hold two copies of every route.

router bgp 64500 bgp cluster-id 10.255.0.100

On both reflectors of the same cluster. Without it, each uses its own router ID, the two are treated as different clusters, and each accepts the other's reflected routes.

One cluster ID or two
One cluster ID or twoHow two reflectors for the same clients are configured.Same cluster IDEach RR drops routesreflected by the otherFewer copiesDifferent IDsEach RR keeps theother's copiesMore paths to compareor

On small screens, swipe sideways or focus the diagram and use the arrow keys.

A shared cluster ID saves memory on the reflectors. Distinct IDs give the clients more routes to compare, which some designs want.

Where to put a reflector

A reflector chooses the best path from its point of view, using the IGP cost from itself to each next hop. That can differ from what a client would choose, so place reflectors where their view matches the clients, typically in the core, with the same IGP topology as the sessions. A reflector far from its clients may send them a path that is not the closest exit for them. Use two reflectors per cluster, in different places, so one failure does not remove reflection.

Troubleshooting a reflector

A client is missing a route
A client is missing a routeFive checks in order.SessionClient up tothe RR?Client flagroute-reflector-client on RR?At the RRRoute in theRR table, best?Reflectedadvertised-routesto the clientValidNext hopreachable?

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Most missing routes are a session, a client flag or a next hop.

A frequent surprise is that the route reaches the client but is not valid. Reflected routes keep their original next hop, which is the external link on R1, so the clients need a route to it. Use next-hop-self on the border router, as covered in the iBGP lessons.

Check your understanding

Predict · scenario 1

A route reflector learns a route from a client. Where does it send it?

Predict · scenario 2

A reflector learns a route from a non-client. Where does it send it?

Predict · scenario 3

Which two attributes help a route reflector design avoid loops?

FAQ

Why does iBGP need a full mesh?
A router does not advertise a route learned from one iBGP peer to another iBGP peer. That rule prevents loops, because iBGP does not add its AS number to the AS_PATH. Without it, routes would not reach every router unless each peered with every other.
Does a reflector change the next hop?
No. Reflected routes keep their original next hop, so clients still need a route to it. Use next-hop-self on the border routers as before.
How do route reflectors avoid loops?
Reflected routes carry ORIGINATOR_ID, the router ID of the router that first injected them, and CLUSTER_LIST, the reflectors the route has passed through. A router rejects a route that contains its own ID in either.