#Juniper route reflector full

Think that if you peer your RR, there is only one peer more to get a full mesh ibgp, from both clients. There will happen nothing, because cliens have a redundant connection to each RR, this way, if a internet connection fails, or a RR fails, or the client to a RR path fail, there will be a exit/incoming path through the other RR. I you lost that RR will lost all ibgp peers. Route reflectors are useless if each ibgp peer have only a peering with one RR. If your topology need to propagate ibgp learned prefix to other ibgp peers, and you have to peer the RR to get this, then maybe you may take other solution, like Confederations.Ĭonfederations is the right way to propagate ibgp learned prefix to other ibgp internal peers, if you cant have a full mesh ibgp topology. Usually, each internal ibgp peers with each RR, so there is no need to peer both RR. This is not usual to peer RR, these should peer with the edge ebgp peers, and internal ibgp peers. If the cluster id are not the same, will accept the route, but cluster id are used when you have more tan 1 RR in the same cluster, if you dont configure this will use the router id.

If the RR receive its own cluster id in a prefix will discard that prefix because this is a potential route loop. This way each RR knows that a prefix comes from a RR in the same cluster.

The cluster id is used to avoid routing loops. If you configure a peer as RR Client, then will override the rule 'dont propagete ibgp prefix to ibgp peers'.