Getting a BGP table in to a lab

Andre Oppermann nanog-list at nrg4u.com
Thu Apr 21 21:36:03 UTC 2005


Arnold Nipper wrote:
> 
> On 21.04.2005 17:17 Reeves, Rob wrote
>>
>> Quagga is great for smaller implementations, but it doesn't scale very
>> well.  It eats up a lot of CPU, so once you hit a certain number of BGP
>> peers, it may start intermittently flapping BGP sessions, or even just
>> crash the bgpd process entirely. 
> 
> For what numbers? I've two quaggas, ~150 peers each, doing as-path and 
> *full* prefix filtering for each peer (Config is around 9MB). CPU is 
> idle 99.x% mostly ...

Yea, but not 150 full feeds.  With some full feeds flapping Quagga has
a hard time.  This is mostly due to poor scheduling of its poor internal
multithred scheduler.  Fortunatly the root cause has been identified
and fixes are currently being discussed on the Quagga lists.

Nontheless I prefer OpenBGPd because its internal design is made for
many full feeds and it's parts run asynchonously from each other.  The
only missing thing there is full filtering capabilities which are under
development currently.  And of course that I pay the time for one of
the OpenBGPd developers employed at my company.  ;-)  If you want to
tip the jar too you are most welcome.

-- 
Andre [Oppermann]
[aka andre at FreeBSD.ORG]

( http://www.networx.ch )



More information about the NANOG mailing list