RE: Getting a BGP table in to a lab

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. Although, I don't recall whether or
not the newer versions support multi-threading for dual processors
now...

-Rob

may i suggest OpenBSD/OpenBGPD

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

Arnold

Arnold Nipper 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. :wink: If you want to
tip the jar too you are most welcome.

Oh, and other very basic things like IPv4-multicast, IPv6-unicast and
IPv6-multicast AFI/SAFI support.

Regards,
Daniel