One of the readers of my BGP Route Reflectors article spotted an “obvious deviation from how we always though the route reflectors work”:

An IBGP route received from a route-reflector client is sent to all IBGP peers, including the client from which it was received.

A quick lab test confirmed the validity of my claims: a BGP route reflector does send an update back to the client from which it was received (and it’s perfectly legal according to the updated BGP Route Reflector RFC).

Why Are We Discussing This?

The traditional BGP route reflector (RR) rules (specified in RFC 1966) stipulated that a BGP RR shall not send an update received from a RR client back to the same client. The RR thus had to treat each RR client individually and could not reuse outbound BGP updates sent to one RR client for other RR clients, resulting in significant performance degradation in scenarios where a RR had numerous RR clients.

RFC 4456 has relaxed the update propagation requirements of RFC 1966 and specifies that a RR sends the same update to all RR clients (even if the original route was received from an RR client). The ORIGINATOR ID BGP attribute is used by the RR clients to detect propagation loops. The relaxed rules of RFC 4456 allow a route reflector to group all the RR clients into a single update group, resulting in significant performance improvements, as the RR computes a single outbound BGP update which is sent to all RR clients.

Test Network Diagram

The behavior of Cisco IOS BGP Route Reflector code was tested in the following network. All routers were running IOS release 12.2(33)SRC3 (other recent IOS releases exhibit the same behavior).

Router Configurations

The following printouts include relevant parts of configurations of R1 and RR.

hostname RR
!
interface Loopback0
 ip address 10.0.1.2 255.255.255.255
!
interface FastEthernet0/0
 description LAN 1 (R1)
 ip address 10.2.1.1 255.255.255.0
 speed auto
 duplex auto
!
interface Serial1/0
 description Link to POP(ROUTER) s1/0
 ip address 10.0.7.2 255.255.255.252
 encapsulation ppp
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface Serial1/0
 network 0.0.0.0 255.255.255.255 area 0
!
router bgp 64500
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.7.1 remote-as 64500
 neighbor 10.0.7.1 route-reflector-client
 neighbor 10.2.1.2 remote-as 64500
 neighbor 10.2.1.2 route-reflector-client
 no auto-summary

hostname R1
!
interface Loopback0
 ip address 10.0.1.3 255.255.255.255
!
interface FastEthernet0/0
 description LAN 1 (RR)
 ip address 10.2.1.2 255.255.255.0
 speed auto
 duplex auto
!
interface Serial1/1
 description Link to Customer
 ip address 10.0.7.9 255.255.255.252
 encapsulation ppp
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 network 0.0.0.0 255.255.255.255 area 0
!
router bgp 64500
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.7.10 remote-as 65100
 neighbor 10.2.1.1 remote-as 64500
 no auto-summary

Test results

The show ip bgp update-groups command executed on RR clearly indicates that the BGP update process computes a single outbound BGP update for both RR clients:

RR#show ip bgp update-group 
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
  BGP Update version : 7/0, messages 0
  Route-Reflector Client
  Update messages formatted 6, replicated 6
  Number of NLRIs in the update sent: max 1, min 0
  Minimum time between advertisement runs is 0 seconds
  Has 2 members (* indicates the members currently being sent updates): 
   10.0.7.1         10.2.1.2        

The printouts of the debug ip bgp updates command on R1 also demonstrate the low-level details of IBGP update processing. When R1 receives an update from the EBGP peer, it propagates the update to RR:

19:58:28.151: BGP(0): 10.0.7.10 rcvd UPDATE w/ attr: nexthop 10.0.7.10,↲
origin i, metric 0, path 65100
19:58:28.155: BGP(0): 10.0.7.10 rcvd 10.9.9.0/24
19:58:28.171: BGP(0): Revise route installing 1 of 1 routes↲
for 10.9.9.0/24 -> 10.0.7.10(global) to main IP table
19:58:28.171: BGP(0): 10.2.1.1 NEXT_HOP is on same subnet↲
as the bgp peer and set to 10.0.7.10 for net 10.9.9.0/24
19:58:28.171: BGP(0): 10.2.1.1 send UPDATE (format) 10.9.9.0/24, ↲
next 10.0.7.10, metric 0, path 65100

Almost immediately, the same route is received back from the route reflector, but R1 ignores it because the RR inserted R1’s router ID into the ORIGINATOR ID attribute of the route:

19:58:28.191: BGP: 10.2.1.1 Local router is the Originator; ↲
Discard update
19:58:28.191: BGP(0): 10.2.1.1 rcv UPDATE w/ attr: nexthop 10.0.7.10, ↲
origin i, localpref 100, metric 0, originator 10.0.1.3, ↲
clusterlist 10.0.1.2, path 65100
19:58:28.191: BGP(0): 10.2.1.1 rcv UPDATE about 10.9.9.0/24↲
 -- DENIED due to: ORIGINATOR is us;