>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-boun...@puck.nether.net] Im Auftrag von Victor Sudakov Gesendet: Mittwoch, 30. Mai 2018 09:07 An: Alan Gravett; juniper-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
