[127741] in North American Network Operators' Group
Re: Route reflector/server appliance for access router aggregation
daemon@ATHENA.MIT.EDU (Andy Davidson)
Tue Jul 13 10:46:01 2010
From: Andy Davidson <andy@nosignal.org>
In-Reply-To: <AANLkTilUUL14XZg0oPdiSOsnVdU7cLzR_1h62HWxztpf@mail.gmail.com>
Date: Tue, 13 Jul 2010 15:45:49 +0100
To: Jack Carrozzo <jack@crepinc.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 13 Jul 2010, at 15:06, Jack Carrozzo wrote:
> On the subject of route reflection, I've run into a few people happy =
with
> Quaggo or openBGPd on intel hardware. You can throw a 1U box together =
with
> dual PSUs, a bunch of ram, and SSD/CF disks for far less than a C or J =
setup
> and won't be wasting money on ASICs you aren't using. If I recall =
correctly
> this is what Any2 was using when I spoke to them some years ago, but
> perhaps someone here can offer more specifics.
A side note - There is not a total commonality of behaviour/featureset =
between a reflector service at an IXP, and on a single AS. IXP =
route-servers tend to be deployed on pc servers, because the C and J =
units don't have features required[1] for IXP operation (unmodified =
AS-path, filtering between participants, multiple RIBs for shadow-free =
filtering.)
That's not to say that white-box solutions wont work well on your =
network. It's easy to make the reflector highly available too - just =
run multiple reflectors, and build multiple adjacencies on your =
forwarding routers.
Andy
[1] Some slides on this topic should you be interested :
General explanation :
=
http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-0=
9-15-01.pdf
http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-00
Further reading on specific implementations:
=
http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteS=
erver_N48.pdf
=
http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_fina=
l_N48.pdf=
