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

[Alexander Marhold]

>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

NO,NO,NO
This was the proper way in 1995, but not actual as...
(Unfortunately most BGP books have been written at that time and are still
sold...)

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) then A does not get the routes from B and vice versa

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

There are nice explanations on the Internet backing me up ( Ivan Peplnjak,
 http://packetpushers.net/bgp-rr-design-part-1/ 
http://orhanergun.net/2015/02/bgp-route-reflector-clusters/
)

Regards
alexander

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

> 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,
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 -eve cluster-ID is configured under peer-group it's a global BGP
attribute, 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.

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

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp