1.11.d Route Reflectors¶
Blueprint 1.11: Troubleshoot BGP (Interior and External)
- 1.11.d Route reflector (excluding multiple route reflectors, confederations, dynamic peer)
In scope: one route reflector with its clients and non-clients, the reflection rules, the cluster ID, the ORIGINATOR_ID and CLUSTER_LIST attributes, and the faults you see when reflection is misconfigured. Designs with several reflectors, confederations and dynamic (listen range) neighbors are excluded from the blueprint.
Why route reflectors exist¶
iBGP has a split-horizon rule: a route learned from one iBGP peer is not advertised to another iBGP peer. eBGP prevents loops with the AS_PATH, but inside one AS the AS_PATH does not change, so BGP needs a different safeguard. The price is that every iBGP router must peer with every other one, and a full mesh needs n(n-1)/2 sessions: 10 routers need 45, 20 routers need 190.
A route reflector (RR, RFC 4456) is allowed to break the split-horizon rule for its clients. Each client keeps one session to the RR instead of sessions to everyone. The RR and its clients form a cluster.
graph TB
subgraph Cluster["Cluster 10.255.255.1"]
RR["R1 route reflector"]
C1["R2 client"]
C2["R3 client"]
end
NC["R6 non-client<br/>(full-mesh peer of RR)"]
RR --- C1
RR --- C2
RR --- NC
C1 --- E1["eBGP peer"]
C2 --- E2["eBGP peer"]The reflection rules¶
| Route learned from | RR sends it to |
|---|---|
| An eBGP peer | All clients and all non-clients (normal BGP behaviour) |
| A client | All other clients and all non-clients (and eBGP peers) |
| A non-client iBGP peer | Clients only (and eBGP peers), not other non-clients |
Non-clients are ordinary iBGP peers of the RR, so they must still be fully meshed with each other and with the RR. Clients need no special configuration at all: they do not know they are clients.
What the RR does and does not change:
- It advertises only its best path for each prefix, like every BGP speaker. Clients never see the other paths the RR knows about. This "hidden path" behaviour is a common reason a client picks a different exit than it would in a full mesh.
- It does not change the NEXT_HOP, LOCAL_PREF, MED or AS_PATH of reflected routes. A client therefore needs a route to the original next hop, which is why edge routers use
next-hop-self. - It adds ORIGINATOR_ID and CLUSTER_LIST.
Exam trap
neighbor x route-reflector-client is configured only on the route reflector, pointing at each client. Configuring it on a client, pointing at the RR, turns the client into a reflector for a cluster of one and leaves the real RR as an ordinary iBGP speaker that reflects nothing.
Loop prevention: ORIGINATOR_ID and CLUSTER_LIST¶
Reflection breaks iBGP split horizon, so two new optional non-transitive attributes stop updates from looping inside the AS.
| Attribute | Set by | Value | Loop check |
|---|---|---|---|
| ORIGINATOR_ID | The RR, when it first reflects a route (not overwritten later) | The router ID of the iBGP peer that injected the route into the AS | A router that receives a route with its own router ID as originator ignores it |
| CLUSTER_LIST | Each RR that reflects the route | The RR prepends its cluster ID | An RR that receives a route whose cluster list contains its own cluster ID ignores it |
The cluster ID defaults to the RR's BGP router ID. Change it with bgp cluster-id <value>, given as a dotted number or an integer. Both attributes are only seen on reflected routes, which makes them the quickest way to prove a route came through the RR.
In the best-path algorithm, a reflected path uses its ORIGINATOR_ID in place of the router ID at the router ID step, and the shorter CLUSTER_LIST wins the step after it (Best path, steps 12 and 13).
Configuration¶
router bgp 65010
bgp router-id 10.255.255.1
! bgp cluster-id 10.255.255.1 ! optional, defaults to the router ID
neighbor IBGP peer-group
neighbor IBGP remote-as 65010
neighbor IBGP update-source Loopback0
neighbor 10.255.255.2 peer-group IBGP
neighbor 10.255.255.3 peer-group IBGP
address-family ipv4
neighbor IBGP route-reflector-client
neighbor 10.255.255.2 activate
neighbor 10.255.255.3 activate
route-reflector-client is an address-family command. A neighbor can be a client for IPv4 and an ordinary peer for IPv6, so check the right family. If the clients happen to be fully meshed with each other already, no bgp client-to-client reflection on the RR stops it from reflecting client routes to other clients (they already have them); routes are still reflected to non-clients.
Verification¶
On the RR, show ip bgp neighbors confirms which peers are clients, and show ip bgp <prefix> marks paths that came from a client:
R1# show ip bgp neighbors 10.255.255.3 | include Reflector
Route-Reflector Client
R1# show ip bgp 198.51.100.0
BGP routing table entry for 198.51.100.0/24, version 5
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
65001, (Received from a RR-client)
10.255.255.2 (metric 2) from 10.255.255.2 (10.255.255.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
On a client, the reflected route carries the originator and cluster list. Note that from names the RR (who sent the update), while the next hop and the originator name the router that injected the route:
R3# show ip bgp 198.51.100.0
BGP routing table entry for 198.51.100.0/24, version 5
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65001
10.255.255.2 (metric 3) from 10.255.255.1 (10.255.255.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.255.255.2, Cluster list: 10.255.255.1
show ip bgp neighbors <client> advertised-routes on the RR shows exactly what was reflected to each client, which is the fastest way to find a missing route.
Troubleshooting route reflection¶
| Symptom | Likely cause | Proof |
|---|---|---|
| Client A's routes reach the RR but not client B | route-reflector-client missing for A or B on the RR, or configured under the wrong address family |
show ip bgp neighbors <ip> \| include Reflector on the RR |
A route reaches the client but has no > |
Next hop not reachable from the client (edge router lacks next-hop-self) |
show ip bgp <prefix> on the client shows inaccessible |
| A client uses a worse exit than expected | The RR reflects only its own best path, chosen from the RR's position in the IGP | Compare show ip bgp <prefix> on the RR and the client |
| Two non-clients do not learn each other's routes | Non-client to non-client is not reflected; they need a direct session | Check the non-client sessions in show ip bgp summary |
| A route reaches the RR but not one client, and the client's router ID equals the originator | Duplicate router ID: the client discards it as its own | Originator: in the RR's output matches the client's bgp router-id |
| The RR reflects nothing after a change | route-reflector-client was configured on the client side instead |
show run \| section router bgp on both sides |
Exam trap
A route reflector does not have to be in the forwarding path, but it chooses best paths using its own IGP distances. If it sits off the traffic path, clients may be steered to an exit that is closer to the RR than to them. On the exam, if a client's choice looks wrong and every attribute ties, compare the IGP metric from the RR's point of view.
Exam trap
Duplicate router IDs inside an RR design fail quietly. If R2 and R3 both have router ID 10.255.255.2, R1 reflects R2's routes to R3 with Originator: 10.255.255.2, and R3 discards them because the originator matches its own router ID. Sessions stay up and nothing is logged by default. Always set bgp router-id explicitly.
Lab: read the attributes and fix ticket 8¶
Topology: the module topology with the baseline from the Sessions lab. R1 is the RR, R2 and R3 are clients through the IBGP peer group.
- On R3, run
show ip bgp 198.51.100.0and find the originator (10.255.255.2), the cluster list (10.255.255.1) and thefromaddress (10.255.255.1). Explain to yourself why the three addresses differ. - On R1,
show ip bgp neighbors 10.255.255.2 advertised-routes. You will see 192.0.2.0/24 but not 203.0.113.0/24: R1's best path for that prefix came from R2, and BGP does not send a route back to the peer it came from. R2 therefore never learns R3's path through ISP-B. That is the hidden path effect. - Change the cluster ID:
bgp cluster-id 0.0.0.99on R1, thenclear ip bgp * soft out. On R3 the cluster list now shows 0.0.0.99. Remove the command. - Inject ticket 8 and troubleshoot it.
Fault injection, ticket 8
! R1
router bgp 65010
address-family ipv4
no neighbor IBGP route-reflector-client
! R2
router bgp 65010
address-family ipv4
neighbor 10.255.255.1 route-reflector-client
clear ip bgp * on R1 and R2.
Ticket 8
"After someone 'moved the route reflector configuration', branch users behind R3 lost access to ISP-A's customer network 198.51.100.0/24. All BGP sessions are up. R1 must remain the only route reflector."
Ticket 8: root cause and fix
On R3, show ip bgp 198.51.100.0 returns nothing. On R1, the prefix is present and best (learned from R2), but show ip bgp neighbors 10.255.255.3 advertised-routes lists only 192.0.2.0/24. show ip bgp neighbors 10.255.255.3 | include Reflector returns nothing, so R1 now treats R2 and R3 as plain iBGP peers and iBGP split horizon stops it passing R2's route to R3.
On R2, show ip bgp neighbors 10.255.255.1 | include Reflector returns Route-Reflector Client: the client command was put on the client, pointing at R1. It does no harm to traffic, but it violates the requirement that R1 is the only reflector.
Fix:
! R1
router bgp 65010
address-family ipv4
neighbor IBGP route-reflector-client
! R2
router bgp 65010
address-family ipv4
no neighbor 10.255.255.1 route-reflector-client
If the sessions do not reset on their own after the change, run clear ip bgp * soft. Confirm on R3 that 198.51.100.0/24 is back with Originator: 10.255.255.2, Cluster list: 10.255.255.1.
Quick check¶
An RR has clients C1 and C2 and a non-client N1. N1 advertises a prefix. Who receives it from the RR?
C1 and C2. Routes from a non-client are reflected to clients only, never to other non-clients.
A client receives a reflected route whose ORIGINATOR_ID equals its own router ID. What does it do?
It discards the route. Either the route is its own coming back, or two routers share a router ID.
Which attribute does an RR add to a route each time it reflects it, and what value does it add by default?
CLUSTER_LIST. The RR prepends its cluster ID, which defaults to its BGP router ID.
References¶
- RFC 4456, BGP Route Reflection, at rfc-editor.org
- IP Routing: BGP Configuration Guide, Cisco IOS XE: "Configuring BGP route reflectors" (search on cisco.com)
- Cisco Live On-Demand Library: search "BGP route reflector design"
Unlock the full question banks and cram sheets
A free account opens every question bank, the timed practice exams, the printable cram sheets, all the simulations and the lab files. Without one you see a 5-question sample of each.
No card needed. Study tips by email are optional and off unless you tick the box. Your address is never sold or shared. Privacy policy ยท Terms
Signed in as . Your account
You're on the free account, so lessons after the first module, question banks, exams and cram sheets show a sample. See Track Pass and All-Access
Also from NetManager Systems: NetManager, network monitoring for multi-vendor networks. Try the NetManager, NetDiag, PCAP Analyzer and OpsDash demos: every new account gets a free 7-day read-only login to each.