It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. We will call these routers conventional BGP speakers. The route reflector scheme will allow such conventional BGP speakers to coexist. These routers could be either members of a client group or a non−client group. This would allow easy and gradual migration from the current IBGP model to the route reflector model. One could start creating clusters by configuring a single router as RR and making other RRs and their clients normal IBGP peers. Then more clusters could be created gradually.
In the above diagram, RTD, RTE and RTF have the concept of route reflection. RTC, RTA and RTB are what we call conventional routers and cannot be configured as RRs. Normal IBGP mesh could be done between these routers and RTD. Later on, when we are ready to upgrade, RTC could be made a RR with clients RTA and RTB. Clients do not have to understand the route reflection scheme; it is only the RRs that would have to be upgraded.
The following is the configuration of RTD and RTC:
RTD#
router bgp 100
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 3.3.3.3 remote−as 100
neighbor 2.2.2.2 remote−as 100
neighbor 1.1.1.1 remote−as 100
neighbor 13.13.13.13 remote−as 300
RTC#
router bgp 100
neighbor 4.4.4.4 remote−as 100
neighbor 2.2.2.2 remote−as 100
neighbor 1.1.1.1 remote−as 100
neighbor 14.14.14.14 remote−as 400
When we are ready to upgrade RTC and make it a RR, we would remove the IBGP full mesh and have RTA and RTB become clients of RTC.
Avoiding Looping of Routing Information
We have mentioned so far two attributes that are used to prevent potential information looping:
originator−id and cluster−list. Another means of controlling loops is to put more restrictions on the set clause of out−bound route−maps.
The set clause for out−bound route−maps does not affect routes reflected to IBGP peers.
More restrictions are also put on nexthop−self, which is a per neighbor configuration option. When used on RRs the nexthop−self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed.
We have mentioned so far two attributes that are used to prevent potential information looping:
originator−id and cluster−list. Another means of controlling loops is to put more restrictions on the set clause of out−bound route−maps.
The set clause for out−bound route−maps does not affect routes reflected to IBGP peers.
More restrictions are also put on nexthop−self, which is a per neighbor configuration option. When used on RRs the nexthop−self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed.
