Re: best practice for number of era que

[Alejandro Acosta <alejandroacostaalamo () gmail com>]

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