Two reflectors
One reflector is a single point of failure for the control plane. Run two, and make every client a client of both.
Configure rr2 the same way, and peer rr1 and rr2 with each other as ordinary (non-client) iBGP peers. c2 now receives every route twice: once from each reflector, each copy with a different cluster list (198.51.100.1 or 198.51.100.2). Both have the same next hop (c1), so it makes no difference to forwarding which one wins.
On rr1 you can see the other copy too: the route from c1 itself, marked Received from a RR-client, and the copy reflected by rr2. rr1 prefers its client's direct copy, because it has the shorter cluster list.
Then the reason for two: shut down every session on rr1, as you might for maintenance or an upgrade. c2's session to rr1 drops, and its table doesn't change: both prefixes are still there, now learnt only from rr2, and forwarding still goes straight to c1. Nothing outside the control plane noticed.
(Both reflectors here use their router ID as their cluster ID, so they're in different clusters, and each keeps the other's reflected copies, as rr1's table shows. Some operators give a redundant pair the same cluster ID instead: each then drops the other's reflected copies, which saves memory on large tables. Either works as long as every client peers with both reflectors.)
set system host-name 'RR2'
set interfaces ethernet eth0 address '198.51.100.2/24'
set interfaces ethernet eth0 description 'CORE'
set protocols bgp system-as '64500'
set protocols bgp parameters router-id '198.51.100.2'
set protocols bgp peer-group CLIENTS remote-as 'internal'
set protocols bgp peer-group CLIENTS address-family ipv4-unicast
set protocols bgp neighbor 198.51.100.11 peer-group 'CLIENTS'
set protocols bgp neighbor 198.51.100.11 description 'c1'
set protocols bgp neighbor 198.51.100.12 peer-group 'CLIENTS'
set protocols bgp neighbor 198.51.100.12 description 'c2'
set protocols bgp neighbor 198.51.100.13 peer-group 'CLIENTS'
set protocols bgp neighbor 198.51.100.13 description 'c3'
set protocols bgp peer-group CLIENTS address-family ipv4-unicast route-reflector-client
set protocols bgp neighbor 198.51.100.1 remote-as 'internal'
set protocols bgp neighbor 198.51.100.1 description 'RR1'
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast- Line 14: Reflection from the start.
- Lines 15–17: rr1 as an ordinary iBGP peer.
set protocols bgp neighbor 198.51.100.2 remote-as 'internal'
set protocols bgp neighbor 198.51.100.2 description 'RR2'
set protocols bgp neighbor 198.51.100.2 address-family ipv4-unicast- Lines 1–3: The other side of that session.
c2# show ip bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.12, local AS number 64500 VRF default vrf-id 0
BGP table version 4
RIB entries 3, using 384 bytes of memory
Peers 2, using 33 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
198.51.100.1 4 64500 11 7 4 0 0 00:01:46 2 0 RR1
198.51.100.2 4 64500 5 3 4 0 0 00:00:33 2 0 RR2
Total number of neighbors 2
c2# show ip bgp 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 3
Paths: (2 available, best #1, table default)
Not advertised to any peer
Local
198.51.100.11 from 198.51.100.1 (198.51.100.11)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best (Neighbor IP)
Originator: 198.51.100.11, Cluster list: 198.51.100.1
Last update: Sat Oct 17 13:48:47 2026
Local
198.51.100.11 from 198.51.100.2 (198.51.100.11)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
Originator: 198.51.100.11, Cluster list: 198.51.100.2
Last update: Sat Oct 17 13:49:59 2026
vyos@RR1:~$ show bgp ipv4 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 8
Paths: (2 available, best #1, table default)
Advertised to peers:
198.51.100.11 198.51.100.12 198.51.100.13 198.51.100.2
Local, (Received from a RR-client)
198.51.100.11 from 198.51.100.11 (198.51.100.11)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best (Cluster length)
Last update: Sat Oct 17 13:48:46 2026
Local
198.51.100.11 from 198.51.100.2 (198.51.100.11)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
Originator: 198.51.100.11, Cluster list: 198.51.100.2
Last update: Sat Oct 17 13:50:16 2026- Lines 10–11: Two reflectors, two prefixes from each.
- Line 21: Reflected by rr1…
- Line 26: …and by rr2.
- Line 33: rr1's own copy, from the client…
- Lines 39–40: …and rr2's reflected copy.
set protocols bgp neighbor 198.51.100.11 shutdown
set protocols bgp neighbor 198.51.100.12 shutdown
set protocols bgp neighbor 198.51.100.13 shutdown
set protocols bgp neighbor 198.51.100.2 shutdown- Lines 1–4: Shut every session down.
c2# show ip bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.12, local AS number 64500 VRF default vrf-id 0
BGP table version 6
RIB entries 3, using 384 bytes of memory
Peers 2, using 33 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
198.51.100.1 4 64500 14 9 0 0 0 00:00:09 Active 0 RR1
198.51.100.2 4 64500 6 4 6 0 0 00:01:03 2 0 RR2
Total number of neighbors 2
c2# show ip bgp
BGP table version is 6, local router ID is 198.51.100.12, vrf id 0
Default local pref 100, local AS 64500
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
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 192.0.2.0/24 198.51.100.13 0 100 0 i
*>i 203.0.113.0/24 198.51.100.11 0 100 0 i
Displayed 2 routes and 2 total paths
c2# ip route get 203.0.113.1
203.0.113.1 via 198.51.100.11 dev eth0 src 198.51.100.12 uid 0
cache- Line 10: rr1 gone…
- Line 11: …rr2 still up.
- Lines 24–25: Both prefixes still there.
- Lines 29–30: Forwarding unchanged.
Check your understanding
Why should every client peer with two route reflectors?
- If one reflector fails, clients still learn routes from the other
- To double the routes for load balancing
- Reflectors only reflect half the routes each
- The protocol requires it