Multiple BGP route reflectors question

[Hassaan]

Hi all,

I'm looking for advice on how to configure a network with more than one route reflectors.

My specific scenario is that I wish to redistribute an ebgp route into our AS and within this AS I wish to create ibgp route reflectors to "reflect" that route to all routers withing my AS. 

I've set it up so that the border routers (in my AS) are configured as route reflector clients and then an RR situated one hop down reflects that to other RR clients across the network. 

The redistribution and reflection part works fine, now I want to set up two RRs for failover, but an then an issue arises. The issue is that the ebgp route does not get advertised to the other RR.

The two RRs have a direct physical connection, but I also created an ibgp peering between them.

I tried to troubleshoot this by:

- giving the two RRs the same cluster ID

- giving the two RRs different cluster IDs

- I tried to make the two RRs clients of each other

None of the above worked.

Any suggestions?

[iacobansilviu1]

1. The cluster ID is automatically asigned by the RR when it reflects a route and it is it's own bgp router-id. This is a loop prevention mechanism that assures that the 2nd RR doesn't reflect back to the first RR because it sees it in the cluster ID list.

2. The two RR should be clients to each other. The route is received from a non-route-reflector client so it won;t be reflected to anther nonRRclient, but if the 2nd RR is a RR client to the first one then it will be reflected.

3. If the route appears in the bgp database ( show bgp ipv4 unicast ) but it is not installed in the routing table, make sure the next hop is reachable

[Giuseppe Larosa]

Hello @iacobansilviu1 ,

>> The two RR should be clients to each other. The route is received from a non-route-reflector client so it won;t be reflected to anther nonRRclient, but if the 2nd RR is a RR client to the first one then it will be reflected.

Not at all, RR servers must be standard i BGP or MP BGP peers between them not client of each other review BGP documentation.

Actually , for this reason there is a need of a full mesh between RRS in some cases for scalability reasons two levels of route reflectors can be used in order to minimize the total number of iBGP sessions.

>> 1) The cluster ID is automatically asigned by the RR when it reflects a route and it is it's own bgp router-id. This is a loop prevention mechanism that assures that the 2nd RR doesn't reflect back to the first RR because it sees it in the cluster ID list.

This is true only in Cisco implementation where a missing cluster-id is set equal to BGP RID. Other vendors may require explicit configuration of the cluster ID.

Yes the Cluster ID is inserted in the Cluster List attribute that tracks the history of reflections of a BGP advertisement within an AS.

BGP RRS introduce Cluster List and Originator BGP attributes to be able to perform safe reflections.

The alternative or complementary in some cases approach is to use BGP confederations that however have a greater impact for the configuration change

Hope to help

Giuseppe

[paul driver]

Hello

---

@Hassaan wrote:

---

Based on the above, Client 3 & Client 6 will be isolated , The reason being even though they are connecting to  RRCs of another RR  they are not aware of it,  its just another ibgp peer, so from clients-1 & 2 point of view they are receiving internal routes as such ibgp route advertisement from Client1-2 will fail to reach their RR1-RR2 and all other RRCs and this also is true from the other RRCs towards Client 3-6 they will NOT receive ibgp routes either

To make this work based on that physical topology and WITHOUT any re-cabling anything..

The following would need to be done:

Client 1 <> Client 3 (become RRC)
Client 1 - cluster-id  0.0.0.11 + next-hop-self towards AS20
Client 2 <> Client 6 (become RRC)
Client 2 - cluster-id  0.0.0.12 + next-hop-self towards AS20

RR1<>RR2  ( normal ibgp peer and NOT RRCs to each other)
RR1 = cluster-id 0.0.0.1
RR2 - cluster-id 0.0.0.2
Advertise their transit subnets into bgp for ebgp return path reachability

The above will provide full resiliency for RR1 & RR2 clients  even is the interconnecting RRCs links fail, reflection will traverse between RR1-RR2 clusters normal ibgp peering

For both Client 3 & 6 they are now RRCs their networks will then be advertised by Client & 2 to RR1 & RR2 and it associated RRCs