TTR Networks

Intermediate · Route reflectors on VyOS · section 1 of 6

Why route reflectors

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

Replace an iBGP full mesh with route reflectors: see iBGP refuse to pass routes on, turn on reflection, read ORIGINATOR_ID and CLUSTER_LIST, confirm the reflector stays out of the forwarding path, and survive taking one reflector down.

By the end you will be able to:

  • Explain why iBGP needs a full mesh, and how route reflection removes it
  • Configure VyOS as a route reflector with a client peer group
  • Read ORIGINATOR_ID and CLUSTER_LIST, and explain the loop protection they provide
  • Show that a reflector isn't in the forwarding path
  • Run two reflectors and survive the loss of one

Prerequisites: Edge and core: building out a VyOS network

Internal BGP (iBGP) has one strict rule: a route learnt from one iBGP peer is never passed on to another iBGP peer. Inside an AS the AS path doesn't change, so it can't be used to spot loops, and this rule is what prevents them. The consequence is the full mesh from the Edge and core lesson: every router must hear every route first-hand, so every router peers with every other. That's n×(n−1)/2 sessions: 3 for three routers, 45 for ten, 190 for twenty. Each new router means touching every existing one.

A route reflector (RR) relaxes the rule in a controlled way. Routers configured as its clients send it their routes as usual, and the reflector passes them on to its other clients and its non-client peers. Clients only need a session to the reflectors, so a new router means two sessions (to two reflectors) and no changes anywhere else.

This lesson's lab puts everything on one shared core segment, so there's no IGP to distract: two VyOS reflectors (rr1 198.51.100.1, rr2 198.51.100.2) and three FRR clients (c1 .11, c2 .12, c3 .13), all in AS64500. c1 originates 203.0.113.0/24 and c3 originates 192.0.2.0/24. Every output comes from that lab.

Diagram: Two reflectors, three clients — The lab: two VyOS reflectors and three FRR clients on one core segment.
  1. Plain iBGP. c1 sends its prefix to rr1, which keeps it to itself: iBGP routes aren't passed to other iBGP peers.
  2. Reflection. With c1, c2 and c3 as clients, rr1 reflects each client's routes to the others, adding the originator and cluster list.
  3. Forwarding skips the reflector. c2's next hop is c1 itself, so traffic goes straight across the core segment.
  4. Two reflectors. rr2 reflects the same routes. Shut rr1 down and the clients keep everything via rr2.
c1 (FRR): a client that originates a prefix
frr defaults traditional
hostname c1
!
interface eth0
 ip address 198.51.100.11/24
!
ip route 203.0.113.0/24 Null0
!
router bgp 64500
 bgp router-id 198.51.100.11
 neighbor 198.51.100.1 remote-as internal
 neighbor 198.51.100.1 description RR1
 neighbor 198.51.100.2 remote-as internal
 neighbor 198.51.100.2 description RR2
 !
 address-family ipv4 unicast
  network 203.0.113.0/24
 exit-address-family
exit
!
  • Line 9: An ordinary iBGP router…
  • Lines 11–14: …peering with both reflectors, and nothing else.
  • Line 17: Its prefix.

Check your understanding

How many iBGP sessions does a full mesh of 20 routers need?

  • 190
  • 20
  • 380
  • 40