cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
311
Views
15
Helpful
5
Replies
Highlighted
Participant

Peering Between BGP Route Reflectors

Hello, we're configuring IBGP over the WAN and and we have 2 RR's. We're configuring the same cluster-id on both RR's. I'm wondering about peering between the 2 RR's if it's necessary since they won't receive route updates from each other.

2 ACCEPTED SOLUTIONS

Accepted Solutions
VIP Advisor

Re: Peering Between BGP Route Reflectors

Hello

Really doesn't matter TBH -  If each RR has its own clients and these clients dont connect to the other RR or if they do connect to the other RR's as long you dont manually set the cluster id to be the same on both RR bgp will assign one via the elected bgp rid of each RR.

So because of the reasons specified earlier(loop prevention) my understanding is you shouldn't manually set the cluster id to be the same on the RR's and if you do they should be different.



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future
Hall of Fame Expert

Re: Peering Between BGP Route Reflectors

Hello NETAD,

if you set the same cluster-id on the two RRs, actually only routes coming from eBGP peers are exchanged between the two RRS,

As suggested by Paul using a different cluster-id provides more redundancy even if the two RRS have the same set of route reflector clients.

The price to pay is a greater usage of memory on the two RRS.

 

If the two RRS are not serving the same set of clients you must use a different cluster-id on them and you need the iBGP session between them

If the two RRS are serving the same set of clients configuring the same cluster-id provides some savings in resources on the RRS as they will not consider routes with the Cluster List attribute containing the same cluster-id.

If you don't configure the cluster-id the cluster-id will be equal to the BGP router-id of each RRS.

 

You need to make a design choice/tradeoff between having more redundancy but using more resources (different cluster-id) or saving resources with a lower level of fault tolerance.

The use of a different cluster-id for two RRS serving the same set of clients covers a special case of double fault:

Client X ---- RRS1 -- RRS2--- ClientY

if for any reason CiientX session to RRS2 is stopped /shutdown and ClientY has the session with RRS1 failed routes can travel between ClientX and ClientY going through the two RRS as described in the above diagram.

And in this case the iBGP session between the two RRS makes the difference.

 

Hope to help

Giuseppe

 

 

5 REPLIES 5
Rising star

Re: Peering Between BGP Route Reflectors

Hello,

 

 If the RR receive its own cluster id in a prefix will discard that prefix because this is a potential route loop. If the cluster id are not the same, will accept the route, but cluster id are used when you have more than 1 RR in the same cluster, if you dont configure this will use the router id.


Could you share your current configuration?

 

Jaderson Pessoa
*** Rate All Helpful Responses ***
VIP Advisor

Re: Peering Between BGP Route Reflectors

Hello
Suggest you configure different cluster/router id for the two RR this way any route leaking back into either RR(cluster) from say a non RR client will be negated by the RR seeing its own id/cluster list attribute in the bgp update.

Note: Cluster-ID if not configured will take the bgp router-id address of the RR



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future
Participant

Re: Peering Between BGP Route Reflectors

Thanks Paul, but if we configure the cluster ID to be the same, is peering necessary and will they exchange routes?
VIP Advisor

Re: Peering Between BGP Route Reflectors

Hello

Really doesn't matter TBH -  If each RR has its own clients and these clients dont connect to the other RR or if they do connect to the other RR's as long you dont manually set the cluster id to be the same on both RR bgp will assign one via the elected bgp rid of each RR.

So because of the reasons specified earlier(loop prevention) my understanding is you shouldn't manually set the cluster id to be the same on the RR's and if you do they should be different.



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future
Hall of Fame Expert

Re: Peering Between BGP Route Reflectors

Hello NETAD,

if you set the same cluster-id on the two RRs, actually only routes coming from eBGP peers are exchanged between the two RRS,

As suggested by Paul using a different cluster-id provides more redundancy even if the two RRS have the same set of route reflector clients.

The price to pay is a greater usage of memory on the two RRS.

 

If the two RRS are not serving the same set of clients you must use a different cluster-id on them and you need the iBGP session between them

If the two RRS are serving the same set of clients configuring the same cluster-id provides some savings in resources on the RRS as they will not consider routes with the Cluster List attribute containing the same cluster-id.

If you don't configure the cluster-id the cluster-id will be equal to the BGP router-id of each RRS.

 

You need to make a design choice/tradeoff between having more redundancy but using more resources (different cluster-id) or saving resources with a lower level of fault tolerance.

The use of a different cluster-id for two RRS serving the same set of clients covers a special case of double fault:

Client X ---- RRS1 -- RRS2--- ClientY

if for any reason CiientX session to RRS2 is stopped /shutdown and ClientY has the session with RRS1 failed routes can travel between ClientX and ClientY going through the two RRS as described in the above diagram.

And in this case the iBGP session between the two RRS makes the difference.

 

Hope to help

Giuseppe

 

 

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards