> On 12 Jan 2017, at 21:32, Justin Krejci <jkre...@usinternet.com> wrote:
> 
> Nanog,
> […]

You did some homework. In essence, there’s no immediate problem with running 
Quagga or OpenBGPd as
RR apart from lack of different knobs and not-so-stellar 
performance/scalability. BIRD is grounds up built
to act as high-performance BGP daemon, and it’s actually used as RR in live 
deployments, not only at IXes.

> I am wondering if people can point me in the direction to some good resource 
> material on how to select a good BGP route reflector design. Should I just 
> dust off some 7206VXR routers to act as route reflectors? Use a few existing 
> live routers and just add the responsibility of being route reflectors, is 
> there a performance hit? Install and run BIRD on new server hardware? Buy 
> some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as 
> route reflectors and add them to the iBGP topology? GNS3 running IOS on 
> server hardware? Something else? How many reflectors should be implemented? 
> Two? Four?

Disclaimer: I work at Cisco.

If You have some 7200VXRs that have 1 or 2GBs of RAM, that may be the best 
option (IF you have them).
Loaded with 12.2S/15S software they may actually be the most cost-effective 
solution and at the same
time support things like AddPath, BGP error handling, etc - when time comes to 
use such features.
If that’s a NPE400 based chassis or something even older - leave it for lab/etc 
as You need rather
performant CPU.

So, if that’s not the option, try to work with the BIRD, CSR 1000v (IOS-XE on 
VM) or ASR 1001X/HX
(currently, the most scaleable and fastest BGP route reflector out there, but 
one that will cost $$$).

Two RRs provide ample redundancy to run even very large deployments (1000+ 
clients), so unless you’re
trying to hit higher numbers or plan to play fancy games with one pair of RRs 
for IPv4/IPv6 unicast
and other pair for different AFs, four may be an overkill to maintain, 
synchronize and monitor.

Don’t go with GNS3, running compiled at runtime emulation is wrong idea for any 
production deployment,
not to mention rights/licenses to do it.

— 
Łukasz Bromirski

Reply via email to