[j-nsp] router reflector clients and non-clients

[Victor Sudakov]

adamv0025 at netconsultings.com 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