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