A route learned by one ibgp peer won’t be advertised to another ibgp peer. This is called BGP split horizon rule. This rule is used to avoid loop in ibgp cases.
To mitigate this, we have following option by which one ibgp learned routes can be advertised to another ibgp peer.
- BGP full mesh
- BGP confederation
- BGP route-reflector
In this article we will discuss about the 3rd option i.e BGP route-reflector.
BGP route reflector rule.
Whenever a RR learn route from its client it adds two attributes to the route.
- Cluster id – (32-bit identifier, which can be set, by defaults its bgp router-id)
- Originator id- (router id of client who send the route)
The following are the rule for RR which should be taken into consideration.
- If RR receive routes from its client it will add the cluster_id & originator id and send that routes to all (client, nonclient, external peer)
- If RR learned routes from non-client, then it will send the routes to all except nonclient.
- If RR learned ebgp routes it will send that routes to all (client, nonclient, external peer)
- If RR receive route from ebgp peer, it does not create a cluster_list for that route.
- If RR need to send route to ebgp peer, it removes the cluster_list info while sending the route.
- If the route is originated by RR only (local routes) then it does not create cluster list for the route.
RR design cases
There can two known design cases for RR
Case1: When the RRs in same cluster
Case2: When the RRs in different cluster
Case1: When the RRs in same cluster
In the topology given above IOU1 &2 is acting as RR. They are both in same cluster id let’s say 1.1.1.1
Where client1 & client2 are RR client peering with both RR as ibgp peer.
Client 1 will have two copies of routes 44.44.44.44 one via RR1 and other via RR2
Client 2 will have two copies of route 33.33.33.33 one via RR1 and other via RR2
When RR1 receive prefix 44.44.44.44 it will advertise it to client1 and RR2. Since the cluster list on both RR is same RR2 will deny this route to install in bgp rib.
When RR2 receive prefix 44.44.44.44 it will advertise it to client 1 and RR1. Since the cluster list on both RR is same RR1 will deny this route to install in bgp rib.
When client 2 advertised prefix 44.44.44.44, both RR1 and RR2 will have one copy of this prefix.
As a result both RR1&2 will have single installed copy of route 44.44.44.44 from its client, client2.
Now Consider even if RR2 get crashed the, Client2 can easily reach to Client1 route 33.33.33.33 as client2 had two routes for 33.33.33.33(one via RR1 other via RR2)
In case of any one or multiple link went down we will have still redundancy to reach to client.
Note: In case of resource constrain we use both RR to be in same cluster list so that they install only one route and deny routes with same cluster.
Case2: When the RRs in different cluster
In the given topology both RR are connected to each other as plain ibgp peer. They both have different cluster id. RR1 uses cluster id 1.1.1.1 whereas RR2 uses 2.2.2.2.
Where client1 & client2 are RR client peering with both RR as ibgp peer.
Client 1 will have two copies of routes 44.44.44.44 one via RR1 and other via RR2
Client 2 will have two copies of route 33.33.33.33 one via RR1 and other via RR2
When RR1 receive prefix 44.44.44.44 it will advertise it to client1 and RR2. Since the cluster list on both RR is different RR2 will install two routes in RIB (one via client1 other via RR2)
When RR2 receive prefix 44.44.44.44 it will advertise it to client 1 and RR1. Since the cluster list on both RR is different RR2 will install two routes in RIB (one via client1 other via RR1)
In this case also if any link fails the client will have multiple routes and won’t affect the traffic.
Note: If two RRs are connected in different clusters they have to install multiple copies of routes , this design is recommended when we do not have resource constraint.