Intermediate · Route reflectors on VyOS · section 3 of 6

Reflection

✓ Lab-tested 18 October 2026 on VyOS 2026.10.16-0024-rolling, FRR 10.2.1

Turning rr1 into a reflector is one line: route-reflector-client on the peer group. (It goes on the reflector, against each client. The clients need no configuration at all; they don't know they're clients.)

Now each client receives the other clients' routes (PfxSnt 2 each), and c2's table has both prefixes. Look closely at c2's copy of 203.0.113.0/24:

from 198.51.100.1: it was learnt from rr1…
next hop 198.51.100.11: …but the next hop is still c1. A reflector doesn't change the next hop, so traffic goes from c2 straight to c1. ip route get confirms it. The reflector is a control-plane device: it can sit anywhere routes can reach it, and it doesn't need to be in the forwarding path (or be a big router).
Originator: 198.51.100.11: the router that first injected the route. A router that receives its own route back, with its own ID as originator, drops it.
Cluster list: 198.51.100.1: every reflector that has reflected the route adds its cluster ID (by default its router ID). A reflector that sees its own ID in the list drops the route. Together, these two attributes replace the loop protection the AS path can't give inside an AS.

Because the next hop is unchanged, every client must be able to reach every other client's next hop. In a real network that's the IGP's job (loopbacks, as in Edge and core), plus next-hop-self on the edges for external routes.

rr1: one line

set protocols bgp peer-group CLIENTS address-family ipv4-unicast route-reflector-client

Line 1: Every member of CLIENTS is now a route-reflector client.

Reflected (real output)

vyos@RR1:~$ show ip bgp summary
[... 8 header lines trimmed ...]
198.51.100.11   4      64500         8         9        6    0    0 00:00:12            1        2 c1
198.51.100.12   4      64500         6         9        6    0    0 00:00:12            0        2 c2
198.51.100.13   4      64500         8         9        6    0    0 00:00:12            1        2 c3
c2# show ip bgp
BGP table version is 2, 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# show ip bgp 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 1
Paths: (1 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, best (First path received)
      Originator: 198.51.100.11, Cluster list: 198.51.100.1
      Last update: Sat Oct 17 13:48:47 2026
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

Lines 3–5: Two prefixes sent to each client.
Lines 16–17: c2 now has both prefixes.
Line 25: Learnt from rr1, next hop still c1.
Line 27: The reflection attributes.
Line 30: Forwarding goes straight to c1.

Check your understanding

c2 learns 203.0.113.0/24 from rr1 with next hop 198.51.100.11. Where do c2's packets go?

Directly to c1, 198.51.100.11
To rr1, which forwards them
Nowhere: reflected routes are for backup only
To rr1 and rr2 in turn