yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation]

[s+Mailinglisten.nanog at sloc.de (Sebastian Spies)]

Hey there,

considering the state of this discussion, BIRD seems to be the only
scalable solution to be used as a route server at IXPs. I have built a
large code base around BGP for the hoofprints project [1] and BRITE [2]
and would enjoy building another state-of-the-art open-source
route-server implementation for IXPs. Would you be so kind to send me
your feedback on this idea? Do you think, it makes sense to pursue such
a project or is it not relevant enough for you?

Best regards,
Sebastian

1: https://github.com/sspies8684/hoofprints/
2: https://brite.antd.nist.gov/statics/about

Am 25.04.2015 um 22:06 schrieb Goran Slavi?:
> Andy,
> 	
> 	Believe me when I say: I would never have the idea to think about
> attempting to try to test my ability to generate configurations for this "2
> route servers/ 2 different programs that run them" solution without the IXP
> Manager :-)
>
> 	I am familiar with the work INEX has been doing with IXP Manager and
> have for some time attempted to find time from regular SOX operation to
> implement it in our IX. This migration gives me the excellent opportunity
> and arguments to finally allocate time, resources and manpower for
> installation and implementation of IXP Manager as the route server
> configuration generator at SOX.
> 	
> 	Regards
> 	G.Slavic
>
>
> -----Original Message-----
> From: Andy Davidson [mailto:andy at nosignal.org] 
> Sent: Saturday, 25 April 2015 21:34
> To: Goran Slavi?
> Cc: nanog at nanog.org
> Subject: Re: Euro-IX quagga stable download and implementation
>
>
> On 25 Apr 2015, at 15:16, Goran Slavi? <gslavic at sox.rs> wrote:
>
>> 	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.
> Goran - glad to have helped.
>
> One last piece of advice which might be useful - to help to guarantee
> consistency of performance between the two route-servers, you should
> consider a configuration generator so that your route-server configs are in
> sync.  The best way to implement this at your exchange is to use IXP
> Manager, maintained by the awesome folks at the Irish exchange point, INEX.
> https://github.com/inex/IXP-Manager
>
> IXP Manager will get you lots of other features as well as good route-server
> hygiene.
>
> There's also a historic perl-script that does this on my personal github.
> Both of these solutions allow you to filter route-server participants based
> on IRR data, which has proved to be a life-saver at all of the exchanges I
> help to operate.  Having my horrible historic thing is maybe better than no
> thing at all, but I deliberately won't link to it as you should really use
> IXP Manager. :-)
>
> Andy=
>
>