[quagga-dev 10873] Re: Vyatta & quagga - VyOS direction
quagga-users at alexis.users.panix.com
Wed Oct 30 12:33:09 GMT 2013
[CCed to the users list, where I suggest followups go, instead of -dev]
We use Vyatta Core, with some significant modifications. I've been concerned about changes at Vyatta for a while now, and the announcement of VyOS reminds me that I need to make some strategic decisions about what we're going to be doing for routing platforms soon. No doubt there are a lot of others on this list in a similar predicament. For that matter, all users of Quagga must think about this from time to time. Quagga has indeed come back from the edge of irrelevance, as a nearly unmaintained project, but the pace of change is still very slow, with many patches still rotting years after submission. (Witness, for example, the current discussion of unnumbered support, which I'm glad to see might finally produce a merged patch, four (?) years after Jocke first submitted a set.)
If VyOS takes off, it's my hope that some of the project maintainers will become maintainers of Quagga as well, sharing the load and increasing the pace of change, which is so desperately needed. VyOS could also be a valuable source of field experience for patches that the Quagga maintainers aren't ready to merge.
In the meantime, I'd like to bring up the topic of performance. While not purely Quagga, it's so closely related that it's likely to be of interest to many (most?) reading this list.
Ubiquiti's fork of Vyatta includes a huge performance boost, which I think is based on [ http://info.iet.unipi.it/~luigi/netmap/ ]. Does anyone know if that's so? If not, where's the code from? At one time Vyatta was talking about similar improvements on their web site, but I can no longer find any of that text.
I don't know enough about that work to know if it's truly production-grade (Ubiquiti seems to think so), but it would be fairly revolutionary in terms of what you can do with commodity hardware in the network core. It was only a couple of years ago, with the advent of the first Xeon E3 CPUs, that a single-chip box could forward gigE at line rate (look for posts to this list from me, at that time, for detailed performance analyses). But with netmap or similar technology, it would perhaps be feasible to forward multiple 10GbE links at line rate, opening up new options for larger networks.
Can anyone comment on how well this works in production? What works and what doesn't work when using this new technology (filtering, throttling, queuing, etc.)? Paul, can you say anything about whether VyOS will be using this (or similar) code?
On Oct 28, 2013, at 8:19 PM, Paul Gear <quagga at libertysys.com.au> wrote:
> I'm trying to help out with the VyOS project  by building packages, especially quagga. (For those who don't know about it, VyOS is a fork of the last released version of Vyatta Core, which Brocade don't seem to be developing any more. There's discussion about this at , if anyone wants to read more.)
> Vyatta seems to have integrated a number of third-party patches into their quagga build, such that merging the current stable version of quagga (0.99.22.4) from git://git.savannah.nongnu.org/quagga.git was less than successful Before I attempt manual fixing of the merge conflicts, I thought I'd check in here.
> In my searches, I found the following additional repos which seem to be relatively well-updated:
> Can anyone who has worked on quagga for a while suggest which is likely to be the most profitable upstream (and most closely related to Vyatta's version) to work from? My main priorities for this work are stability and maintaining close proximity with upstream so that security fixes can be integrated easily.
> Thanks in advance,
>  http://vyos.net/
>  http://www.vyatta.org/node/62075
>  http://www.reddit.com/r/networking/comments/1ielhy/100_open_source_vyatta_alternative/
>  http://www.reddit.com/r/networking/comments/1o7n16/vyatta_now_rehosted_to_github_as_vyos/
More information about the Quagga-dev