[181772] in North American Network Operators' Group
Re: Route leak in Bangladesh
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Thu Jul 2 13:50:11 2015
X-Original-To: nanog@nanog.org
Date: Thu, 2 Jul 2015 10:48:10 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Mark Tinka <mark.tinka@seacom.mu>
In-Reply-To: <559400F5.60401@seacom.mu>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed 2015-Jul-01 17:02:13 +0200, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
>
>On 1/Jul/15 16:54, Nick Hilliard wrote:
>> you probably want to ignore more rpsl constructs and depend solely on
>> as-sets, aut-nums and route/route6 objects. RPSL is not going to live up
>> to your expectations.
>
>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.
>
>What I'm more focused is how we can continue to scale our current
>system, which is much more strict, focuses on deploying customer
>aggregates + le 24 & le 128, instead of enumerating all possible
>de-aggregates that have been registered in the IRR (helps keep the
>configuration file small and manageable, without sacrificing
>reachability). And then see how we can add RPKI into the mix to make
>things even simpler, if at all.
Orphaned/crufty data and braindead moves (e.g. someone including a large=20
upstream's AS-SET in their own or something) aside, the deagg issue should=
=20
be handled by the tools, no? We do automated prefix gen from IRR data, and=
=20
I know IRRPT will aggregate the route records before spitting out the=20
prefix list. I would have assumed that other tools do the same? Options=
=20
are available to define your max prefix length and then build your filters=
=20
off of that, e.g. <aggregated route object> upto /<max prefix len>. You=20
still face issues with people people registering discontiguous blocks (e.g.=
=20
network has a.b.0.0/22 but creates records for a.b.0.0/23 and a.b.3.0/24,=
=20
but leaves out a.b.2.0/24), but there isn't much we can do about that=20
without human interaction to verify the actual allocation.
Also:
>focuses on deploying customer aggregates + le 24 & le 128...
Jeebuz; you accept /128s? Perhaps "le 24 & le 48"?
>
>Mark.
--
Hugo
--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJVlXlaAAoJEJqxD/2xeDE+pAAQAK1Wjsd/D9fb9KAYFSHqjA5Q
xXlp/CshcE+Tg4hJVZNioE8z5MGJ29INdmFwgyJ0uyiTKCORhJJzfT3R2diH0s9V
Y+KxHSszRuy03WG8QSRp/bOeO5vPPRIcbSqV9uOLDfY0MMHgN+a16vZhQqYhGlTg
DDwriUvKKpLYqzUqWjI0X87PAz+JDnM++zYJQ2hey893Y8r33Yt/n5EzZZoJ3F9a
vrSB5FLWiqRWMZ0aCJYjDMQFTp5rkFuQbNz0WN+V6QFL5HjuSv1n81KzH2ILgKMV
ipAMwvUmLIgq/b8eDHjHN7s/Lubv+BnqbP/qiSXfYrK/MAobJOUt0N8WzPmNZVQ5
Neguoh5AccQx9OzEafahGa45SuJhMXYjfHwFwVxyxYWIGSSWBOTrWxYAC2B+hxhE
TvrV3C/goZofARuk68SFGTVmpFbzl89fzy2HqCYolb2O6+ALA69QVZWOlfrpZe6n
ov+yozQnBIPDJGIGBLUQWYtfwMU66XJnXOWLnnHj+/ysZFk4usMAQBH/xUu34JKh
Sw/SA+X8wCKQBGCszluwbrghoXynuIwj+qHQv74D5Xf1yxscqfoZpLTzaNnCkfwr
pir8dRGP3AuXghWefiWPdjVvNI2DWe8+q7V+XlkCUlVhesiTHVbbZVuhk7GI4axo
NddA01nrLJU1bm9gIiiS
=98WV
-----END PGP SIGNATURE-----
--8t9RHnE3ZwKMSgU+--
