BGP Route Reflector

What Is a Route Reflector?

A route reflector (RR) is a mechanism for relaxing the iBGP full-mesh requirement. It is defined in RFC 4456.

As explained in Differences Between iBGP and eBGP, iBGP follows a split-horizon rule: a route learned from an iBGP peer is not advertised to other iBGP peers. This forces every BGP router in the AS to peer with every other one (a full mesh), requiring n × (n - 1) ÷ 2 peerings for n routers.

A route reflector lifts this constraint by granting one router an exception: it may reflect routes received over iBGP to other iBGP peers. Each router then only needs a peering with the RR, reducing the number of peerings to n - 1.

Terminology

Term	Meaning
Route reflector (RR)	The router that reflects routes. It carries the `route-reflector-client` configuration.
Client	An iBGP peer designated as `route-reflector-client` by the RR. It only needs a peering with the RR.
Non-client	An ordinary iBGP peer of the RR that is not designated as a client. Non-clients still need a full mesh among themselves.
Cluster	The RR together with its clients. It is identified by a cluster ID, which defaults to the RR’s BGP Router ID.

No special configuration is needed on the client side. The RR simply declares which peers are clients, and a client is unaware that it is one.

Reflection Rules

Where the route came from determines whether the RR reflects it to its other iBGP peers. Advertisement to eBGP peers follows ordinary BGP and happens regardless of where the route came from.

Received from	Reflected to other iBGP peers	Advertised to eBGP peers
A client	Both other clients and non-clients	Yes
A non-client	Clients only (non-clients are assumed to be fully meshed, so it is not reflected between them)	Yes
An eBGP peer	Both clients and non-clients (the same as ordinary iBGP)	Yes

Two Attributes That Prevent Loops

Relaxing iBGP split horizon creates the risk of a route circulating within a cluster. To prevent this, RFC 4456 adds two path attributes. Both are optional and non-transitive, so they never leave the AS.

Attribute	Type code	Contents
`ORIGINATOR_ID`	9	The BGP Router ID of the router that first brought the route into the AS. The RR adds it when reflecting. A router that receives a route whose `ORIGINATOR_ID` matches its own Router ID ignores that route.
`CLUSTER_LIST`	10	The list of cluster IDs the route has traversed. The RR prepends its own cluster ID when reflecting. An RR that receives a route already containing its own cluster ID discards it.

Where AS_PATH prevents loops between ASes, these two prevent loops within an AS.

Configuration

On IOS XR, route-reflector-client is configured on the RR, under the address family of each neighbor that is to be a client.

Configuring a route reflector on IOS XR (RR side)
router bgp <AS number>
 neighbor <client address>
  address-family ipv4 unicast
   route-reflector-client

To set the cluster ID explicitly, use bgp cluster-id. The BGP Router ID is used by default, so this can be omitted when there is a single RR. It is set when multiple RRs need to be treated as one cluster for redundancy.

Configuring the cluster ID on IOS XR
router bgp <AS number>
 bgp cluster-id <cluster ID>

No special configuration is required on the client routers. They are configured as ordinary iBGP neighbors.

Verification on Real Devices

Five IOS XR (XRd) routers are used to confirm what a route reflector does. AS 65001 contains R1, R2 and R3, with R2 acting as the route reflector and R1 and R3 as its clients. There is no iBGP peering between R1 and R3.

Router	AS	Role	Advertised network
R1	65001	RR client	192.168.1.0/24
R2	65001	Route reflector	192.168.2.0/24
R3	65001	RR client (eBGP with AS 65002)	192.168.3.0/24
R4	65002	-	192.168.4.0/24
R5	65003	-	192.168.5.0/24

Inside AS 65001, OSPF area 0 provides reachability (R1 - R2 and R2 - R3 are point-to-point), and the iBGP peerings use each router’s Loopback0. R3 advertises GigabitEthernet0/0/0/1 (10.3.4.0/24) as an OSPF passive interface so that R1 can reach the NEXT_HOP of the reflected routes.

Before the Route Reflector: Routes That Never Reach R1

First, look at the state before route-reflector-client is configured on R2. R1’s BGP table holds only two routes.

R1 show bgp (before RR)
RP/0/RP0/CPU0:R1#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i

Processed 2 prefixes, 2 paths

These are its own 192.168.1.0/24 and 192.168.2.0/24, which its iBGP peer R2 originates itself. R3’s 192.168.3.0/24, and 192.168.4.0/24 and 192.168.5.0/24 that R3 learned over eBGP, never arrive.

R1 show bgp 192.168.3.0/24 (before RR)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24

%% Network not in table

R2 itself, on the other hand, receives routes from both R1 and R3 and holds all five.

R2 show bgp (before RR)
RP/0/RP0/CPU0:R2#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*> 192.168.2.0/24     0.0.0.0                  0         32768 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.3.4.4                 0    100      0 65002 i
*>i192.168.5.0/24     10.3.4.4                      100      0 65002 65003 i

Processed 5 prefixes, 5 paths

In other words, R2 knows the routes but does not pass them to its other iBGP peers. Looking at an individual route shows this explicitly as Not advertised to any peer.

R2 show bgp 192.168.3.0/24 (before RR)
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24

BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  5            5
Last Modified: Sep  5 06:46:57.774 for 00:04:20
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 5

This is iBGP split horizon: R2 does not advertise a route received from one iBGP peer (R3) to another iBGP peer (R1).

Configuring the Route Reflector

On R2, designate both R1 and R3 as route-reflector-client.

Route reflector configuration on R2
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   route-reflector-client
  !
 !
 neighbor 10.0.0.3
  address-family ipv4 unicast
   route-reflector-client
  !
 !
!

Adding or removing route-reflector-client resets the BGP session with that neighbor. It is recorded in show bgp neighbor as Last reset ... due to RR client configuration changed.

After the Route Reflector: R1 Learns Every Route

R1’s BGP table now holds five routes.

R1 show bgp (after RR)
RP/0/RP0/CPU0:R1#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.3.4.4                 0    100      0 65002 i
*>i192.168.5.0/24     10.3.4.4                      100      0 65002 65003 i

Processed 5 prefixes, 5 paths

The reflected routes carry Originator and Cluster list. Note that the route came from 10.0.0.2 (R2) while the Router ID in parentheses is 10.0.0.3 (R3).

R1 show bgp 192.168.3.0/24 (after RR)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24

BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  9            9
Last Modified: Sep  5 06:53:50.774 for 00:00:44
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.0.0.3 (metric 3) from 10.0.0.2 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 9
      Originator: 10.0.0.3, Cluster list: 10.0.0.2

R3 likewise learns 192.168.1.0/24, advertised by R1, with Originator: 10.0.0.1.

R3 show bgp 192.168.1.0/24 (after RR)
RP/0/RP0/CPU0:R3#show bgp 192.168.1.0/24

BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  9            9
Last Modified: Sep  5 06:53:50.774 for 00:01:24
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.3.4.4
  Path #1: Received by speaker 0
  Local
    10.0.0.1 (metric 3) from 10.0.0.2 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Originator: 10.0.0.1, Cluster list: 10.0.0.2

On R2, a route received from a client is marked (Received from a RR-client).

R2 show bgp 192.168.3.0/24 (after RR)
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24

BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 13           13
Last Modified: Sep  5 06:53:50.774 for 00:00:57
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.1
  Path #1: Received by speaker 0
  Local, (Received from a RR-client)
    10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

The neighbor detail shows Route-Reflector Client and the cluster ID. No cluster ID was configured, so R2’s BGP Router ID 10.0.0.2 is used.

R2 show bgp neighbor 10.0.0.1 (after RR)
RP/0/RP0/CPU0:R2#show bgp neighbor 10.0.0.1

BGP neighbor is 10.0.0.1
 Remote AS 65001, local AS 65001, internal link
 Description: iBGP to R1 (Loopback0)
 Remote router ID 10.0.0.1
 Cluster ID 10.0.0.2
<snip>
 For Address Family: IPv4 Unicast
<snip>
  Route-Reflector Client
<snip>
  1 accepted prefixes, 1 are bestpaths
  Prefix advertised 5, suppressed 0, withdrawn 0
<snip>
  Last reset 00:01:16, due to RR client configuration changed

Before the RR configuration this read Prefix advertised 1 (only R2’s own 192.168.2.0/24); afterwards it reads Prefix advertised 5.

R1 can also reach R5’s Loopback1.

R1 ping (after RR)
RP/0/RP0/CPU0:R1#ping 192.168.5.1 source 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.5.1 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/24 ms

Checking the Attributes in a Packet Capture

A capture was taken between R1 and R2, and the session was reset with clear bgp 10.0.0.2 to observe the UPDATE messages R2 sends to R1. They arrive in packet No.19 of the attached capture (bgp-route-reflector.pcap), a TCP segment carrying five UPDATEs. The output below comes from Wireshark’s tshark; the bit-level breakdown of each flag byte is elided with <snip>.

Download just this No.19 (bgp-route-reflector-no19.pcap)

The reflected 192.168.3.0/24 carries CLUSTER_LIST and ORIGINATOR_ID.

R2 -> R1 UPDATE (192.168.3.0/24)
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 75
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 52
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.3
                IPv4 Address: 10.0.0.3
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.3.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: empty
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 0
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100
        Path Attribute - CLUSTER_LIST: 10.0.0.2
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: CLUSTER_LIST (10)
            Length: 4
            Cluster List: 10.0.0.2
                Cluster ID: 10.0.0.2
        Path Attribute - ORIGINATOR_ID: 10.0.0.3
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: ORIGINATOR_ID (9)
            Length: 4
            Originator identifier: 10.0.0.3

As Flags: 0x80, Optional, Non-transitive shows, both are optional and non-transitive, so they never leave AS 65001 (they do not reach R4 or beyond). Next hop also remains R3’s 10.0.0.3, showing that the RR does not rewrite NEXT_HOP.

Within the same UPDATE, 192.168.2.0/24, which R2 originates itself, carries neither attribute. They are added only to reflected routes.

R2 -> R1 UPDATE (192.168.2.0/24)
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 61
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 38
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.2
                IPv4 Address: 10.0.0.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.2.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.2.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: empty
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 0
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100

The full capture is available here.

Download the full capture (bgp-route-reflector.pcap)

Verification Configs

Download R1 config (r1_bgp-route-reflector.cfg)

Download R2 config (r2_bgp-route-reflector.cfg)

Download R3 config (r3_bgp-route-reflector.cfg)

Download R4 config (r4_bgp-route-reflector.cfg)

Download R5 config (r5_bgp-route-reflector.cfg)

Test Environment and show Output

On every router, show route, show bgp, show bgp <prefix> (for all five prefixes), show bgp summary and show bgp neighbor were collected both before and after the route reflector configuration.

Before the RR configuration:

Download R1 show output (r1_bgp-route-reflector_before_show.txt)

Download R2 show output (r2_bgp-route-reflector_before_show.txt)

Download R3 show output (r3_bgp-route-reflector_before_show.txt)

Download R4 show output (r4_bgp-route-reflector_before_show.txt)

Download R5 show output (r5_bgp-route-reflector_before_show.txt)

After the RR configuration:

Download R1 show output (r1_bgp-route-reflector_after_show.txt)

Download R2 show output (r2_bgp-route-reflector_after_show.txt)

Download R3 show output (r3_bgp-route-reflector_after_show.txt)

Download R4 show output (r4_bgp-route-reflector_after_show.txt)

Download R5 show output (r5_bgp-route-reflector_after_show.txt)

References

Source	Title	Summary
RFC 4456	BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)	Defines route reflection and the `ORIGINATOR_ID` / `CLUSTER_LIST` attributes.
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	The base specification of BGP-4, which defines iBGP split horizon.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of numbers used by BGP, including path attribute type codes.