Quagga: A Success, and Yet a Failure, of Open-Source In Networking?

DZone 's Guide to

Quagga: A Success, and Yet a Failure, of Open-Source In Networking?

· Java Zone ·
Free Resource
Quagga: A Success, and Yet a Failure, of Open-Source In Networking?

SDNCentral had the opportunity to speak to Martin Winter, one of the current caretakers of the Quagga project, one of the most venerable open-source routing stacks in networking. Quagga powers many large service providers and numerous networking appliances today.

In our conversation, we dig into why Quagga is so poorly supported as an open-source project despite so many corporations deriving value from the stack behind closed doors. Is Quagga the poster child for the failure of the open-source model in networking? Read on and decide for yourself.

For the readers who might not be familiar with Quagga, can you provide some insight into what it is and a very brief history?

Winter: Quagga is an open-source-licensed (GPLv2) routing stack. It is an implementation of IP routing protocols such as RIP, RIPng, OSPF and ISIS. I want to make the clear distinction of a routing stack compared to a full router implementation. For a full router, you need traffic forwarding and a routing stack. Quagga only implements the routing protocols. It can be run with Linux and can use the standard Linux kernel for forwarding (as software router), or it could be connected to a distributed forwarding platform using OpenFlow or any other open or proprietary interface (as a high-end distributed router). It could also be used just for the routing protocols to interface with off-the shelf routers to receive and announce routes.

Quagga evolved out of the Zebra routing code approximately 10 years ago. Zebra, as a public project, is abandoned, but it continues as a commercial solution with IP Infusion as ZebOS.

Can you give me a brief description of what you do and your current relationship to the Quagga project?

Winter: I’m one of the founders of the Network Device Education Foundation (NetDEF), a non-profit company. Before starting NetDEF, I was working at the Internet Systems Consortium (ISC) on the OpenSourceRouting project, which was started in 2011. NetDEF is now taking over ownership of the OpenSourceRouting project from ISC to continue its mission.

OpenSourceRouting does not own Quagga. Its community owns Quagga. We are mainly sponsoring a maintainer, testing, and bug fixing (and some development). We employ the main active maintainer of Quagga. We spend considerable time to test (and fix) the current and new code. We see our role in providing a paycheck to a few people in the community to make sure they can afford the time working on the project. Our goal is not to take over ownership and control away from the community, but to help building a stable community around Quagga.

What do you see as the importance of Quagga to SDN and NFV?

Winter: The networks, and with them the router market, are today mostly controlled by large vendors such as Cisco and Juniper. However, these companies may have different ideas on where the market should go and how this will help their market share. I always look at SDN and NFV as concepts to question traditional ideas and come up with radical new ones. Having an open-source routing stack makes it much easier to try new methods by testing the feasibility of the new ideas, by making changes on an existing protocol, interfacing to current networks (you still need the traditional routing protocols, at least at the edge), or just using it for routing on the platform of your choice.

We really hope that all the SDN/NFV vendors pick an open-source solution for their routing (preferably Quagga). I think the opportunity for the end user to actually modify and write their own enhancements would be a huge benefit. The whole concept behind SDN and NFV is still young and there is a large amount of ideas out there. I would like to give the best chance to everyone to try their own ideas and hope to see some radical new solutions. The best ideas may come from small new companies or companies running networks in a different way than anyone else. Quagga gives them a chance to start from an existing routing stack instead of rewriting everything from scratch.

Who uses Quagga today, and are there any other viable open-source alternatives?

Winter: Quagga is mostly used in virtual environments, large data centers (clouds providers), and in the academic/research community, which needs access to an open-source implementation of the routing protocols as a base for trying new standards and ideas on top of it.

Unfortunately, most of the large users use Quagga in secret. They won’t publicly admit to it. They use Quagga because they are able to customize it to their specific needs in their network.

As viable open-source alternatives, the biggest alternative to Quagga is Bird. Bird started initially as a BGP route-server/route-reflector for Internet providers and exchange points. It has many unique features for this environment. Over the past years, Bird started to evolve into a more generic routing stack. It supported OSPF for a long time, and ISIS is in the works. Bird is mostly used in environments where the system does not forward traffic and only receives/sends BGP. Other than Bird there is XORP, which unfortunately has not much of an active community behind it, and the OpenBSD-supported OpenBGPd and OpenOSPFd projects.

Who do you see as the main sponsors for Quagga?

Winter: We are not looking at the home users. We see the responsibility to support Quagga being on the large network/cloud providers who use (or consider using) Quagga and on network equipment providers looking for a routing stack. The cost to support (and improve) Quagga is miniscule compared to what is currently spent on licensing or purchasing network equipment or a routing stack.

One of our current sponsors is Cumulus Networks, and OpenSourceRouting was initially started with donations from Google.

Many Fortune 100 companies use Quagga because they can modify and extend it with their own intelligence. They see this as a competitive advantage to run a better infrastructure. One of the common misconceptions with open-source software is that everything needs to be published. For GPLv2 this is only the case for code, which is distributed to other parties. As long as the enhancement is only used in-house, it does not need to be shared. This is one of the key advantages of using Quagga compared to commercial solutions. Most commercial vendors will share the new features with every other customer (if they accept any feature requests at all). There is no way to ask for the source code from them to make your own private enhancements. With open-source code, they can just write their own enhancements or hire someone to do this for them.

In addition, didn’t Vyatta use Quagga? Is Brocade continuing to contribute to Quagga?

Winter: Vyatta was one of the key supporters of Quagga. They didn’t change Quagga much, but mostly worked on the underlying Linux improving the packet forwarding and the management of the system. Initially they sold their own hardware platforms and then later moved their product to a virtual environment. Since the acquisition of Vyatta by Brocade, we haven’t seen much activity from them, and rumors are that they may abandon it.

Furthermore, I know you can’t cite these companies by name, but with so many major service providers in the world using or benefiting from Quagga, why is it that Quagga is so poorly supported (financially)?

Winter: I believe that this is one of the disadvantages of being open-source. The idea is: “Why should I pay if I can get the same for free?” Everyone expects others to pay. The other challenge is that a company using Quagga probably started to use it by some engineer to solve a problem, but it was never in the budget discussion, as it was free. The sad thing is that many of the shortcomings in Quagga could be long fixed if they would be just willing to put a small amount of money up to pay for it.

What’s your vision for Quagga? What do you think it can do for the networking community at large?

Winter: I see a huge potential for Quagga if we can manage to find enough financial support to pay for maintainers, testing and development. I believe that now is the time where the limitations in the traditional networks are uncovered, and I would like to make Quagga a viable and reliable choice for anyone to build on. If we think on how the server market was stuck in the same situation before the breakthrough of the Linux OS, I believe something similar might happen in the network market in the next few years, and SDN/NFV is one of the early indications for the market opening up.

How can people get involved to help? How much money or how many developers will it take to keep Quagga alive and make it flourish?

Winter: Unfortunately, at this time, Quagga is on weak legs. We desperately need funding to continue to pay for the maintainer, bug fixing, and more testing. The amount of money will make the difference between us having to give up, keeping at least some minimum staff (maintainers) employed, expanding, fixing, and testing to get Quagga in better shape. We have a few months before we are out of money and have to get back finding “normal” jobs. Our minimum goal is around $150,000 to $250,000 per year, but we hope to get more money and be able to pay for serious testing, bug fixing, and even development in the future to get an active community of supporters and users behind it.

How can readers contact you? Are you going to be at the Open Networking Summit (ONS, March 3-5)?

Winter: We are an exhibitor at the ONS in the academic/non-profit section. Look for us at booth A-8. We are showing a sample setup of an OpenFlow switch controlled by Quagga interoperating with a pure software Quagga on Linux and off-the-shelf routers. We are open to any feedback and discussions (and donations). You can also contact us by email at info@opensourcerouting.org


Published at DZone with permission of Roy Chua , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}