Bird vs Quagga revisited

Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations:
http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf
http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf
as well as the NANOG thread:
http://www.gossamer-threads.com/lists/nanog/users/123027
But have not found anything worthwhile on the matter over the past 2 years.

Both Quagga and BIRD have developed since the comparison in 2010:
http://savannah.nongnu.org/news/?group=quagga
http://bird.network.cz/?o_news

But has anyone performed a more recent comparsion? Does Quagga still suffer from performance issues vs BIRD? Has anyone performed an RFC conformance test to see who complies more strictly to all the various RFCs?

If BIRD is so much better than Quagga why is there no instance at Oregon:
http://www.routeviews.org/

I also notice that BSD Router Project supports both:
http://bsdrp.net/bsdrp
How well do the two coexist at the same time? Any migration issues going from Quagga to BIRD? Any feedback appreciated.

We now take you back to cable wars :slight_smile:

Thanks,
Hank

Hello,

I came across this site a few weeks ago

http://code.google.com/p/google-quagga/source/list

Seems that Google (or at least some Googlers) are working on quagga, or
worked as the last update is tagged July 2011.
Main difference I see between Quagga and Bird, is that it is now possible
to run ISIS on Quagga, but I did not perform a full comparaison of this two
daemon.

Guillaume

I can't speak too highly of BIRD. Our use case is probably not
completely typical, but our multilateral peering route servers have been
hugely improved by switching to BIRD. Our two primary route servers,
one for each LINX London LAN, use BIRD; the two secondaries use an
enhanced version of Quagga.

The BIRD route server scales better, gives much higher performance, is
much more robust, and is much easier to restart - especially when there
are lots of connected sessions. The development team are fantastic:
very active and responsive, and especially responsive to the needs of
the IXP community.

Switching hats to Euro-IX, BIRD is now the most used route server
amongst IXPs, as can be seen from our latest annual report:
https://www.euro-ix.net/documents/1024-Euro-IX-IXP-Report-pdf?download=yes

John

Sorry to disrupt the bad cabling thread, but I'd like to revisit a
thread from 2 years ago. I have read over the NANOG presentations:
http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf

http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf

Much of the Quagga pain discussed openly in 2010 was related to its
performance as a route-server (which in a large instance might need to
converge many millions of best paths, in a multiple table setup). A
route-server is more like a database which uses bgp as its interface,
than it is a router. The problems that we felt as exchange operators at
this time were different to the ones that people using these packages as
a router felt.

Both Quagga and BIRD have developed since the comparison in 2010:
Savannah Administration - News [Savannah]
http://bird.network.cz/?o_news

I'm not clear what you care about from a performance point of view -
forwarding ? acting as a route-server ? collector ? BIRD is a great,
super-fast route-server daemon - much "better" than typical competitors
Quagga and OpenBGPd at this job. In a forwarding capacity, I do not
know and I would really think that Operating system performance and
environment tuning will have more to do with forwarding performance than
the daemon used.

I am hoping that forwarding best-practice information for Quagga
eventually comes out of this project : http://opensourcerouting.org/

Andy

Of those who have used Quagga or Bird, or anything else,
would either of them be appropriate and/or well suited for
use as an iBGP blackhole route server? We currently
do blackholes via manual config on one of our real
routers but are wanting to add a software-based (on linux)
system where we could script a way for some of our tech
support folks to add blackhole routes at the direction
of a network person where they can just enter a command
and the IP address.

Thanks,

David

David

Are you referring to the DROP[1] or BGPF[2] lists? If so there are
various was to use that data.

[1] http://www.spamhaus.org/drop/
[2] http://www.spamhaus.org/bgpf/

+1 ... I guess we at DE-CIX perhaps run the largest routeserver setups
with full as-path and prefix-list filtering. BIRD really was some
magnitudes of perfomance improvement compared to Quagga.

In the meantime some of us (LINX, INEX, DE-CIX) also supported
development of Quagga as a routeserver. Biggest issue currently is to
get this code into mainline Quagga to make it suitabke for further
development and improvement.

Personally I would like to see more work on all three opensource
implementations, i.e. BIRD, OpenBGPd and Quagga.

Arnold

Personally I would like to see more work on all three opensource
implementations, i.e. BIRD, OpenBGPd and Quagga.

http://opensourcerouting.org/ to the rescue?

+1. FIB performance and RIB performance are two very different things, and the former depends on the OS. Besides (although I haven't checked this recently), Quagga still does not support multiple FIBs.

You can use Quagga or Bird as a blackhole BGP injector, because the forwarding load is next to nothing and the number of prefixes in your blackhole RIB is likely to be small.

You might - if you programatically get the blackhole criteria from your crm or some other database find ExaBGP to be easier to integrate with your data source. ExaBGP is a very lightweight BGP speaker that is perfectly suited for this purpose - http://code.google.com/p/exabgp/

Andy

> Personally I would like to see more work on all three opensource
> implementations, i.e. BIRD, OpenBGPd and Quagga.

http://opensourcerouting.org/ to the rescue?

Hi, I'm David Lamparter, employed at the OpenSourceRouting (OSR) project
to maintain Quagga.

I can tell you that the OSR's interest is in providing a stable
open-source routing platform for actual switches/routers (with either a
software or hardware forwarding plane). Quagga and BIRD were considered
equally; Quagga's single-RIB design and existence of isisd were what
tipped the scales.

We primarily perform conformance and scale testing and fix/enhance in
those areas; also we support 3rd parties in cleaning and submitting
Quagga patches/features.

OSPF and IS-IS are stronger targets currently since they need more work
than BGP, and also Euro-IX already did much of the latter. Merging that
is on the TODO, but it's a lot of work. Even as a Quagga maintainer, I
must currently recommend against using mainline Quagga as a route
server. Please use Euro-IX Quagga, and if you can/want, convince your
decisionmakers to support Chris Hall on that -- I've been told future
work on the Euro-IX Quagga branch is not certain.

There's been a BoF on RIPE64 with OSR, BIRD and Quagga involvement.
There'll be one at RIPE65 again I think. Either way if you have
questions, feel free to ask.

-David

Fell free to contact me if you have any questions about ExaBGP as I am painfully aware it's documentation is nowhere near what it should be.

Thomas

Don't forget about XORP if you have any need for multicast routing ...

Of those who have used Quagga or Bird, or anything else,
would either of them be appropriate and/or well suited for
use as an iBGP blackhole route server? We currently
do blackholes via manual config on one of our real
routers but are wanting to add a software-based (on linux)
system where we could script a way for some of our tech
support folks to add blackhole routes at the direction
of a network person where they can just enter a command
and the IP address.

seems you want something like quagga on a secured host... that ought
to be fine, you could even just make it an ebgp peer of 2-3 devices
and use that with a route-map to reset the next-hop, there by not
messing up your current nice ibgp mesh.

What's the state of MPLS on Linux these days?

~Seth

I'm fairly sure that Mikrotik software is based on linux, and supports MPLS.

Not too sure which package they use, or if they rolled their own MPLS support...

MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack.

Last time I looked, the "mpls-linux" project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however.

Edward Dore
Freethought Internet

MPLS and VPLS on RouterOS works very well.

MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack.

Hi,

Does Mikrotik publish their modified Linux kernel source? Might be
interesting to look at it.

Laurent

Just for the records, OpenBSD got fully functional MPLS stack.

HTH,
Dan #13685 (RS/Sec/SP)
The CCIE troubleshooting blog: http://dans-net.com
Bring order to your Private VLAN network: http://marathon-networks.com