BGP Route Reflector - Route Server, Router, etc

James Breeden James at
Thu Jan 12 21:26:39 UTC 2017


Fusion has run Route Reflection for some time as we didn't want to play full mesh. 

Our current design is that we have 2 routers that are designated as the route reflectors, and every other router maintains RR sessions with those. There is no real additional overhead as the BGP transactions and messaging are handled at the management plane of most routers, not the routing plane. Ours are directly on our Brocade MLXe.

As we are scaling past the initial build, we are running into certain minor routing hiccups dealing with remote routers sometime preferring routes from the reflectors vs their closer routes. We found this to be a function of ingesting transit and default routes directly into route reflector routers and that those routes tended to get preferred in the table than routes from other routers in the network. Our answer to this and what we are deploying this year is that we are picking a site per time zone to be a Route Reflector, which will give us 4 RRs in the states, but we will not use sites that are Transit ingest sites. This way we are more balancing the BGP table across the entire network. Also, I believe we will move to default-free status this year with this same move. 

Happy to discuss more indepth offlist if you'd like. 


James Breeden
The Fusion Network 
jwb at
fusion 844.548.1421
direct 512.360.0000
cell 512.304.0745

-----Original Message-----
From: NANOG [mailto:nanog-bounces at] On Behalf Of Justin Krejci
Sent: Thursday, January 12, 2017 2:33 PM
To: NANOG ‎[nanog at]‎ <nanog at>
Subject: BGP Route Reflector - Route Server, Router, etc


I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). Fortunately, I am also going to be able to decommission some older routers from the network and so shrinking the existing iBGP full mesh is something I am all too happy to spend time and energy on.

For the purpose of this thread though, I am not really interested in the route reflector vs confederation discussion.

In doing some research[1][2][3][4][5] I see a lot of discussions, config examples, etc on using route reflectors but most suggest picking a router, or more appropriately a set of routers, to become route reflectors within an ASN. I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions).

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?

What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated.

[1] - iBGP-to-RR migration slideshow:
[2] - General RR design issues:
[3] - Video intro to RR from Cisco:
[4] - Quagga and BIRD as RR example:
[5] - Countless hours on youtube:

Lots more data is out there of course as that is part of my problem.



More information about the NANOG mailing list