Have you considered a virtual route reflector rather than physical hardware? On Aug 1, 2015 11:39 AM, "marco da pieve" <mdapi...@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. >
