Hi all, I'm sorry about this email replication (or spam whatever you like most) but one of the replies to my original email could have made this email unnoticed. 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