Peering Between BGP Route Reflectors

[NETAD]

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.

[Jaderson Pessoa]

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?

[paul driver]

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

[NETAD]

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

[paul driver · Accepted solution]

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.

[Giuseppe Larosa · Accepted solution]

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

[smailmilak]

Hi Giuseppe,

should we configure the session as route-reflector client between two RR's or should it be a regular iBGP session? I assume that it should be set as RR client between RR's.

[Giuseppe Larosa]

Hello @smailmilak ,

iBGP sessions between BGP RRS are to be configured as regular non client  iBGP sessions.

From this comes the need of a full mesh of iBGP sessions between RRS in an ISP network.

Setting route-reflector client on one side is used in big networks with two levels of BGP RRS.

I have seen this for AF ipv4 unicast.

Setting route-reflector client on both sides of the iBGP session  shoud be wrong in theory and in practice.

Edit:

the reason why we don't need to set the other RRS as a client is that a RRS reflects clients advertisements to clients and NON clients with no special configuration.

Hope to help

Giuseppe

[smailmilak]

Thank you a lot. It's clear, but after the edited part