best practice for number of RR

Sat Aug 1 22:14:04 UTC 2015

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