Route leak in Bangladesh
Hugo Slabbert
hugo at slabnet.com
Thu Jul 2 17:48:10 UTC 2015
On Wed 2015-Jul-01 17:02:13 +0200, Mark Tinka <mark.tinka at 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
upstream's AS-SET in their own or something) aside, the deagg issue should
be handled by the tools, no? We do automated prefix gen from IRR data, and
I know IRRPT will aggregate the route records before spitting out the
prefix list. I would have assumed that other tools do the same? Options
are available to define your max prefix length and then build your filters
off of that, e.g. <aggregated route object> upto /<max prefix len>. You
still face issues with people people registering discontiguous blocks (e.g.
network has a.b.0.0/22 but creates records for a.b.0.0/23 and a.b.3.0/24,
but leaves out a.b.2.0/24), but there isn't much we can do about that
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150702/cc9e6e5f/attachment.sig>
More information about the NANOG
mailing list