[179637] in North American Network Operators' Group
RE: Euro-IX quagga stable download and implementation
daemon@ATHENA.MIT.EDU (=?iso-8859-2?Q?Goran_Slavi=E6?=)
Sat Apr 25 19:39:58 2015
X-Original-To: nanog@nanog.org
From: =?iso-8859-2?Q?Goran_Slavi=E6?= <gslavic@sox.rs>
To: "'Martin Winter'" <mwinter@noaccess.com>,
"'Andy Davidson'" <andy@nosignal.org>
In-Reply-To: <Pine.LNX.4.64.1504241408490.4408@picard.noaccess.com>
Date: Sat, 25 Apr 2015 21:16:59 +0200
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
Hello Andy, Martin and everyone else
First I would like to thank you all on extremely well written and
well-argumented posts. SOX operated Quagga route servers for many years =
but
as the number of peers (and more importantly prefixes) has grown we =
began to
see very disturbing warning signs that the stability of those servers is =
at
peril. "Clear" commands that take forever, over processing of requests =
that
makes Quagga forget to send keep-alive pockets to peers, constant memory
leakage etc. Considering that those problems have began to multiply and
escalate with every new peering - I was tasked to find and implement the
alternative for current route servers in order to improve stability or =
find
the alternative to program packages we currently use.
Considering what I have learned in your posts (and on other places
that I have informed myself) I will definitely suggest to SOX management =
to
go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) =
for
the simple reason that 2 different solution provides more security in
context of "new program update->new bugs" problems and incidents and
prevents other potential problems.
I am extremely grateful for your help specially in the context of
how much time it has saved me and good arguments it has given me for the
solution I plan to implement. I hope we will continue future discussions =
and
exchange of ideas on Euro-IX forums/mailing lists.
Regards,
Goran Slavi=E6
SOX
-----Original Message-----
From: Martin Winter [mailto:mwinter@noaccess.com]=20
Sent: Saturday, 25 April 2015 03:41
To: Andy Davidson
Cc: Goran Slavic; nanog@nanog.org
Subject: Re: Euro-IX quagga stable download and implementation
Andy, Goran (and everyone else)
Disclaimer first: I work full-time for OpenSourceRouting on Quagga.
On Fri, 24 Apr 2015, Andy Davidson wrote:
>
> Hi, Goran, everyone --
>
> On 23 Apr 2015, at 09:06, Goran Slavic <gslavic@sox.rs> wrote:
>
>> at the mailing list and have an interest in downloading and=20
>> implementing the Euro-IX version of Quagga in our Internet exchange. =
My=20
>> questions are simple:
>> - Considering the time when the post is written (2012) - what is the=20
>> current status of the Euro-IX Quagga ?
>> - Where can it be downloaded as a stable release / version ?
>
[...]
> Quagga's vanilla build will fail to stay up with large numbers of=20
> tables and participants. Chris Hall did an amazing job at making a=20
> build that was more prone to staying up and his build is doing a=20
> sterling job at LINX (alongside BIRD) but I understand that this =
source=20
> tree is no longer maintained and that the task of merging his =
stability=20
> fixes into the mainline or OSR (https://www.opensourcerouting.org)=20
> version is not a simple job and has not been done. This gives me a=20
> serious concern about the future of this branch.
On the Chris Hall branch: Chris did some great work fixing many issues,=20
but unfortunatly, mostly in a solo mission on it's own. The idea (from
the beginning when Euro-IX sponsored his work) was to get this=20
integrated back into the mainline Quagga.
However, by the time we got access to the code, it was a basically one
large diff of 1000's of lines with no git history. This would be a lot
of work to pick it apart again, review the code and commit it (in =
pieces)
into the mainline. We talked about supporting it as an alternative BGP=20
daemon, but he changed quite a bit in zebra as well, so this was still
too much work. When I say "too much", the issue was that noone was =
willing
to sponsor the work (person or money) to get this integrated.
We did (actually multiple times) look into the issues and made different =
plans on how to get the BGP performance fixed. But so far (in the past), =
everyone who sponsors us doesn't care much about the BGP scale and cares
more on IPv6 with OSPFv3, ISIS etc. So that's where most of our work =
went.
(Plus a lot of testing. I think Quagga is the only Open Source routing=20
platform which is tested against protocol fuzzers and for RFC =
compliance)
There is now (again) some interest (mainly form european IX'es) to look=20
into the problems and we started (again) to evaluate, measure and see =
how
we can fix it on a limited budget. The idea is to really get Quagga =
usable
as a RouteServer to have a 2nd choice (beside Bird). Happy to get=20
donations (We are a US 501c3 non-profit) to actually make it happen.
Overall, if everyone here who complains would just donate a little bit
money (or some work), then the whole issue would be long solved.
> BIRD just doesn't die, no matter what scale we seem to throw at it.=20
> This thing just keeps flying.
Short term, if you are ok with a single solution and need something now=20
for a route-server, I think Bird is the solution.
Long term, I hope to get Quagga as an alternative (and for everyone who=20
wants 2 different solutions).
Bird initially was (and still is) focused to the Route server & Route=20
reflector application and has some unique features there. Quagga is =
today=20
more focused as a full routing daemon and mostly used in virtual =
routers,=20
SDN applications and ToR routers.
Regards,
Martin Winter
(OpenSourceRouting, NetDEF)
