[181730] in North American Network Operators' Group
Re: Route leak in Bangladesh
daemon@ATHENA.MIT.EDU (Mike Hammett)
Wed Jul 1 11:53:50 2015
X-Original-To: nanog@nanog.org
Date: Wed, 1 Jul 2015 10:53:42 -0500 (CDT)
From: Mike Hammett <nanog@ics-il.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
In-Reply-To: <55940311.9060401@foobar.org>
Errors-To: nanog-bounces@nanog.org
That they do. Thanks for a great system, BTW!
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest Internet Exchange
http://www.midwest-ix.com
----- Original Message -----
From: "Nick Hilliard" <nick@foobar.org>
To: "Mark Tinka" <mark.tinka@seacom.mu>, "Jared Mauch" <jared@puck.Nether.net>
Cc: "North American Network Operators' Group" <nanog@nanog.org>
Sent: Wednesday, July 1, 2015 10:11:13 AM
Subject: Re: Route leak in Bangladesh
On 01/07/2015 16:02, Mark Tinka wrote:
> Honestly, I'm ambivalent about using the IRR data for prefix-list
> generation (even without RPSL), also because of how much junk there is
> in there, and also how redundant some of it really is, e.g., someone
> creating a /32 (IPv4) route object and yet we only accept up to a /24
> (IPv4) on the actual eBGP session, e.t.c.
We went through this a couple of years ago at INEX and ended up with a
provisioning system which allows the operator to only allow specific IRRDB
source: entries, customisable per customer. You're right that it would be
foolish to accept any IRRDB source because a lot of them are complete trash.
Otherwise, it works incredibly well for us and has stopped innumerable
prefix leaks and other silly misconfigs.
The source code is available on github.com/inex. Lots of IXPs use it in
production.
Nick