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

[Alexander Marhold]

>3. Non-clients which are also RRs in the same cluster (from which you
should reject updates based on the cluster-id attribute).

NO, NO, NO this is the old way of doing redundant RRs
Never do this as it can lead to missing routing updates if a client A is
connected to RR-1 only and Client B connected to RR-2 only ( because of link
outages)
Therefore---- make each RR with a unique cluster-id ( recommended identical
to router-id ) and then you can either make a normal ibgp connection between
both RRs or each one is the client of the other one

Regards

alexander

-----Ursprüngliche Nachricht-----
Von: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] Im Auftrag von
Victor Sudakov
Gesendet: Mittwoch, 30. Mai 2018 09:07
An: Alan Gravett; juniper-nsp at puck.nether.net
Betreff: Re: [j-nsp] router reflector clients and non-clients

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).


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp