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.
Have you considered a virtual route reflector rather than physical hardware? On Aug 1, 2015 11:39 AM, "marco da pieve" <mdapieve@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.
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 <shane@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" <mdapieve@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
On 1/Aug/15 18:34, marco da pieve wrote:
Hi Shane, for the boxes that are currently installed in the network, this is not a valid option (politically/commercially speaking).
Well, Cisco, Juniper and ALU are shipping carrier-grade OS's that will run on a server in a VM. Brocade is also known to be doing good work there re: Vyatta, but I don't know of anyone running that as an RR. In 2015, I'd never spend money on a dedicated RR running on router hardware. Server, VM, end of story. Mark.
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
On 1/Aug/15 17:38, marco da pieve 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?
We deploy 2x RR's in each of our main PoP's. All iBGP clients in that PoP speak to their local RR's. The RR's all speak to one another in a full-mesh. Each RR pair is its own cluster. We run our RR's on Cisco's CSR1000v software, which is IOS XE in a VM (VMware ESXi in our case). These are high-end servers, but we don't worry too much about over-protecting one because there is a redundant one in each cluster. I once ran a network which ad 3x RR's per cluster. That is fine, but the impact on the clients can become an issue over time. Mark.
participants (3)
-
marco da pieve -
Mark Tinka -
Shane Ronan