BGP Route Reflector Configuration

Start from your working iBGP full mesh: three sessions on loopbacks, next-hop-self on edges, ping working.

Figure 1 – Starting point, the iBGP full mesh

Remove the R2–R4 Session

Tear down the direct session between edges on R2:

R2# configure terminal
R2(config)# router bgp 65002
R2(config-router)# no neighbor 4.4.4.4
%BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down Neighbor deleted
R2(config-router)# end

Do the same on R4:

R4# configure terminal
R4(config)# router bgp 65002
R4(config-router)# no neighbor 2.2.2.2
R4(config-router)# end

Figure 2 – The R2–R4 session you just removed

What R2 Sees Now

Check the BGP table on R2:

R2# show ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   192.168.1.0      10.0.12.1                0             0 65001 i

The network 192.168.2.0/24 disappeared from R2.

R3 still holds the route, but split horizon prevents R3 from forwarding it to R2.

Figure 3 – R3 holds the route but cannot pass it on

Everything happens on R3.
Your clients keep their current configuration.

Figure 4 – Two sessions left, R3 is not a reflector yet

Declare the Clients

Configure R3 with one line per client:

R3# configure terminal
R3(config)# router bgp 65002
R3(config-router)# neighbor 2.2.2.2 route-reflector-client
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down RR client config change
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R3(config-router)# neighbor 4.4.4.4 route-reflector-client
%BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down RR client config change
%BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up
R3(config-router)# end

Each command resets the session.
Neighbors go down and come back up immediately.

Verify on R3

Check how R3 processes the customer prefix:

R3# show ip bgp 192.168.2.0
BGP routing table entry for 192.168.2.0/24, version 7
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  65003, (Received from a RR-client)
    4.4.4.4 (metric 2) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Notice the key line: (Received from a RR-client).
R3 tags the route and advertises it.

Rule 2 from the BGP Route Reflector lesson, in action.

Confirm the route sent to R2:

R3# show ip bgp neighbors 2.2.2.2 advertised-routes
BGP table version is 7, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
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.168.2.0      4.4.4.4                  0    100      0 65003 i

Total number of prefixes 1

The reflector relays the route without rewriting the next hop.

Check the prefix details on R2 to see what R3 added:

R2# show ip bgp 192.168.2.0
BGP routing table entry for 192.168.2.0/24, version 8
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  65003
    4.4.4.4 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 4.4.4.4, Cluster list: 3.3.3.3

The route comes from 3.3.3.3 while the next hop stays 4.4.4.4.
OSPF resolves 4.4.4.4, and the CLI now displays both attributes:

• Originator (4.4.4.4): The router ID of the node that injected the prefix.

• Cluster list (3.3.3.3): The router ID of the reflector forwarding the route.

Count the Sessions

Verify active sessions on R2:

R2# show bgp ipv4 unicast summary
BGP router identifier 2.2.2.2, local AS number 65002
BGP table version is 8, main routing table version 8
2 network entries using 496 bytes of memory
2 path entries using 272 bytes of memory
2/2 BGP path/bestpath attribute entries using 592 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1408 total bytes of memory
BGP activity 2/0 prefixes, 4/2 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4        65002      14      13        8    0    0 00:02:31        1
10.0.12.1       4        65001      52      51        8    0    0 00:41:07        1

You have one eBGP session and one iBGP session.

You reduced your core from three iBGP sessions down to two.
Now verify that end-to-end reachability remains intact.

Ping Test

Run a ping test from PC1 to PC2:

Figure 5 – Same reachability, one session fewer

C:\>ping 192.168.2.10
Pinging 192.168.2.10 with 32 bytes of data:

Reply from 192.168.2.10: bytes=32 time=12ms TTL=123
Reply from 192.168.2.10: bytes=32 time=10ms TTL=123
Reply from 192.168.2.10: bytes=32 time=11ms TTL=123
Reply from 192.168.2.10: bytes=32 time=10ms TTL=123

Ping statistics for 192.168.2.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 12ms, Average = 10ms

The ping succeeds.

Adding a fourth core router now requires a single neighbor statement on R3 and a standard iBGP block on the new node.

Single Point of Failure

Replacing a full mesh with a hub-and-spoke model simplifies scaling.
But one router now carries every internal BGP session in the Autonomous System.

Figure 6 – The reflector fails, every session fails

If R3 crashes, R2 and R4 lose their only route reflection path, and customer traffic drops.
Production networks cannot tolerate a single point of failure.

Redundant Route Reflectors

Production designs deploy two or more reflectors for high availability.

Figure 7 – Two reflectors, no single point of failure

Every client peers directly with all reflectors.

Here, R6 acts as a second reflector while R2 and R4 peer with both R3 and R6.
If R3 goes down, R6 keeps reflecting routes.