BGP Route Reflector - Route Server, Router, etc

Emille Blanc emille at
Fri Jan 13 00:25:47 UTC 2017

> 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).

We use openbgpd - well, the native OpenBSD equivalent - for route-reflection in a couple of places, as well as a full bgp feed for at least one site, using (old) Poweredge 1950 Gen2's. They were on-hand, so the price was right.
It's not caused us any grief to date. That said, neither have our 7204VXR's which do the same thing in some areas.
Needless to say, we don't use the reflectors to actually move the bits, but have at least on one occasion measured ~88,000pp/s out of one of the 1950's that takes a full feed, before interrupts were starting to look worrisome on old non-smp safe code. 
But switches with bgp or ospf support are cheap provided you're not feeding them with a full table.
Convergence times haven't been a problem for us, but we're only hovering around 1500 routes at the moment.

Having something you can tcpdump on is nice for the few situations that call for it, pf is always extremely handy, re-distributing to/from ospfd is trivial (also in OpenBSD base).

As long as you can find hardware with memory enough to scale to your number of routes, it's been a perfectly valid and sound option for us.

My 5 cents.

-----Original Message-----
From: NANOG [mailto:nanog-bounces at] On Behalf Of Justin Krejci
Sent: January-12-17 12:33 PM
To: NANOG ‎[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