[179704] in North American Network Operators' Group
No subject found in mail header
daemon@ATHENA.MIT.EDU (Sebastian Spies via NANOG)
Mon May 4 06:50:22 2015
To: nanog@nanog.org
In-Reply-To: <002201d07f93$478fc970$d6af5c50$@rs>
From: Sebastian Spies via NANOG <nanog@nanog.org>
Reply-To: Sebastian Spies <s+Mailinglisten.nanog@sloc.de>
Errors-To: nanog-bounces@nanog.org
Date: Mon, 4 May 2015 10:50:21 +0000 (UTC)
--===============8135819809905088007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
This post was from a subscriber whose From: address domain has a DMARC
policy of reject or quarantine. The NANOG mailing list has
automatically wrapped this message to prevent other subscribers mail
systems from rejecting it.
--===============8135819809905088007==
Content-Type: message/rfc822
MIME-Version: 1.0
Content-Disposition: inline
Return-Path: <s+Mailinglisten.nanog@sloc.de>
X-Original-To: nanog@nanog.org
Delivered-To: nanog@nanog.org
Received: from mail.sloc.de (mail.sloc.de [178.63.28.75])
by mail.nanog.org (Postfix) with ESMTP id BC2542C0120
for <nanog@nanog.org>; Mon, 4 May 2015 10:50:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by mail.sloc.de (Postfix) with ESMTP id C25041880430;
Mon, 4 May 2015 12:50:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mail.sloc.de
Received: from mail.sloc.de ([127.0.0.1])
by localhost (sloc.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Azc67P5nyBdJ; Mon, 4 May 2015 12:50:17 +0200 (CEST)
Received: from [IPv6:2a02:3100:4a0b:e800:31ff:eba1:f567:db70] (unknown [IPv6:2a02:3100:4a0b:e800:31ff:eba1:f567:db70])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: sspies@sloc.de)
by mail.sloc.de (Postfix) with ESMTPSA id 3F88E188010B;
Mon, 4 May 2015 12:50:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sloc.de; s=201210;
t=1430736617; bh=vX1yy6CAhsAa0U3f7pzyR5NsRdB9CDkajLB0VH+Xk9w=;
h=Date:From:To:Subject:References:In-Reply-To;
b=AfV5pQEudLOzqh9fCgKBxoR6rxiGW4jyY85tRrjOUKjV9CHjqDv3jeCC+UKTGtVFb
tnLFY6qEkzB4RnW1sk3jCkkLRNB8pgegRKUTA5x9PL9JMrZXIXREETRmIh9Oc/8Ino
t0aprk80TdRJUsbx6RTlnQ5xZyRimddX2a5QsveQ=
Message-ID: <55474EE1.2090402@sloc.de>
Date: Mon, 04 May 2015 12:50:09 +0200
From: Sebastian Spies <s+Mailinglisten.nanog@sloc.de>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: nanog@nanog.org
Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga
stable download and implementation]
References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <Pine.LNX.4.64.1504241408490.4408@picard.noaccess.com> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs>
In-Reply-To: <002201d07f93$478fc970$d6af5c50$@rs>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
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@nosignal.org]
> Sent: Saturday, 25 April 2015 21:34
> To: Goran Slaviæ
> Cc: nanog@nanog.org
> Subject: Re: Euro-IX quagga stable download and implementation
>
>
> On 25 Apr 2015, at 15:16, Goran Slaviæ <gslavic@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=
>
>
--===============8135819809905088007==--
