[email protected] wrote: > > Of Victor Sudakov > > Sent: Wednesday, May 30, 2018 8:07 AM > > > > Alan Gravett wrote: > > > A RR can also be a client with hierarchical RR's... > > > > A hierarchy is irrelevant for this discussion. We are talking about how a > RR > > should differentiate between > > > > 1. Its clients > > > > 2. Non-clients > > > > 3. Non-clients which are also RRs in the same cluster (from which you should > > reject updates based on the cluster-id attribute). > > > I know what you're talking about,
Thank you! > Even if you configure the other RR as a non-client in its dedicated > peer-group router will know what to do and will drop updates based on common > cluster-ID Oh! > -eve cluster-ID is configured under peer-group it's a global BGP > attribute, Oh! That's what I wanted to hear. The matter is much clearer now. > but let me ask you this instead. > Why would you even connect RR1 and RR2 if they are in the same cluster > -why to bother exchanging routes between the RRs just to be dropped by the > receiving party. Well, they are not dedicated RRs, they are part of the full mesh and have other functions. That's probably the only reason. > > Instead you should not even connect RR1 and RR2 together > And treat RR infrastructure built from RR1s I their respective clusters as a > separate infrastructure to RR2s. > This is the proper way When I have dedicated RRs I will certainly follow your advice. And thanks a lot for the enlightenment. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
