best practice for number of RR

Sat Aug 1 16:16:45 UTC 2015

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