[80033] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Getting a BGP table in to a lab

daemon@ATHENA.MIT.EDU (Andre Oppermann)
Thu Apr 21 17:36:33 2005

Date: Thu, 21 Apr 2005 23:36:03 +0200
From: Andre Oppermann <nanog-list@nrg4u.com>
To: Arnold Nipper <arnold@nipper.de>
Cc: "Reeves, Rob" <rreeves@arbinet.com>, nanog@merit.edu
In-Reply-To: <42681656.8020108@nipper.de>
Errors-To: owner-nanog@merit.edu


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@FreeBSD.ORG]

( http://www.networx.ch )

home help back first fref pref prev next nref lref last post