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@FreeBSD.ORG] ( http://www.networx.ch )