Getting a BGP table in to a lab

Thu Apr 21 22:05:58 UTC 2005

Andre summed it up nicely for me here.  I suppose quagga's stability is
somewhat relative to the actual environment it's being used in.  In our
case, it was a live environment with nearly 20 full routing tables in
constant flux (the usual table churn from various providers).  We moved
on to something else prior to the multithreading fixes being deployed,
so I can't say how much better it is now.

There were several occasions when we had to roll back from a version
upgrade due to process-crashing bugs.  That was also a bit bothersome.
Overall, though, I think quagga could definitely be useful for a lab
environment.  In our testing lab, it was actually *too* stable.  We had
to come up with a way to create constant table updates from the lab
peers in order to confirm the cause of a crash.  :)

-Rob

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 )