A El ago 1, 2015 12:05, "marco da pieve" <mdapi...@gmail.com> escribió: > > 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 <sh...@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" <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. > >> > > > > > -- > Marco Da Pieve