BGP Route Reflector - Route Server, Router, etc

Youssef Bengelloun-Zahr bengelly at
Thu Jan 12 22:55:47 UTC 2017

Dear Justin,

You could take a look at this presentation from Mark Tinka during last NANOG :



> Le 12 janv. 2017 à 23:41, Łukasz Bromirski <lukasz at> a écrit :
>> On 12 Jan 2017, at 21:32, Justin Krejci <JKrejci at> 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

More information about the NANOG mailing list