best practice for number of era que

Sat Aug 1 19:57:07 UTC 2015

A
El ago 1, 2015 12:05, "marco da pieve" <mdapieve at 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 <shane at 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 at 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