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

[Christopher E. Brown]

Using different cluster-ids you end up with multiple copies of all the
prefixes but done correctly it works just fine and provides better
redundancy at the cost of higher "path" count.

If you are running single cluster-id and pushing router memory limits it
would be a bad idea.

If you have the memory, dual RRs with different cluster-ids and
multipath are not a bad thing.

Not like I have a fairly large network doing exactly that since 2011
without issue.

On 5/30/18 00:02, Victor Sudakov wrote:
> Alexander Marhold wrote:
>>> 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
> 
> But in this scenario, a client will send an update both to RR1 and
> RR2, and RR1 will reflect this update to RR2, and RR2 will reflect it
> to RR1, and voila! We have a routing loop.
> 
>>
>> 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/
> 
> Thanks, will read those.
>