best practice for number of RR

Sat Aug 1 16:34:13 UTC 2015

Hi Shane,
for the boxes that are currently installed in the network, this is not a
valid option (politically/commercially speaking).

thanks,
Marco

On 1 August 2015 at 18:16, Shane Ronan <shane at ronan-online.com> wrote:

> Have you considered a virtual route reflector rather than physical
> hardware?
> On Aug 1, 2015 11:39 AM, "marco da pieve" <mdapieve at gmail.com> wrote:
>
>> Hi all,
>> this is my first time in asking for advices here and I hope not to bother
>> you with this topic (if it has been already covered in the past, would you
>> please please point me to that discussion?).
>>
>> Anyway, I need to decide whether to go for a BGP topology with a single
>> cluster of 3 Route Reflectors (to overcome a dual point of failure issue)
>> or maybe to two standalone clusters each with two RR (sacrificing half of
>> the network in case two RR of the same cluster fail).
>>
>> To give you some input data:
>>
>> - 8000 actual VPNV4 prefixes
>> - 180 BGP neighbors
>>
>> In case of the 3 RRs option, prefixes will become 24000 on the clients
>> (24k
>> received routes in total but 1/3 installed. No BGP multipath will be
>> used).
>> In this scenario considering network growth up to doubling the current
>> number of VPNV4 prefixes, I would end up to have 16k actual vpnv4 prefixes
>> and 48k vpnv4 prefixes received by the clients, which is almost the limit
>> for the HW used.
>>
>> In the case of two standalone clusters each with two RRs, BGP
>> neighborships
>> will be halved among the two clusters and vpnv4 prefixes too. In case of
>> network growth up to doubling the number of prefixes, the clients will
>> receive up to 24k vpnv4 prefixes and this is still far below the HW
>> limits.
>> Of course this option will not prevent a dual failure in the single
>> cluster
>> and half of the network would end up in outage.
>>
>> My choice would be to go for the two clusters assuming that each RR has
>> supervisor/controlling card protection capabilities.
>>
>> However I'd like to have a feedback on the pros and cons on the design
>> itself if any. I know that design is planned on the resources available
>> but
>> just for discussing and abstracting from the HW, would there be any
>> drawbacks in having an odd number of RR in the network? is one of the two
>> option a no to go choice? what was your experience?
>>
>> thanks a lot for your time and patience to go through this email,
>>
>> M.
>>
>

-- 
Marco Da Pieve