[ITNOG] FW: ARIN removed 154 as-set's from it's IRR a week+ ago
Brian Turnbow
b.turnbow@twt.it
Gio 25 Giu 2020 09:43:03 CEST
Questo da Nanog,
non so se qualcuno usa IRR di ARIN, ma è info utili.
Brian
Brian Turnbow
CTO
TWT S.p.A.
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+b.turnbow=twt.it@nanog.org] On
> Behalf Of Martin J. Levy
> Sent: Thursday, June 25, 2020 3:37 AM
> To: nanog@nanog.org
> Subject: ARIN removed 154 as-set's from it's IRR a week+ ago
>
> This is a quick note about as-set's.
>
> First some background. For those that followed the ARIN to ARIN & ARIN-
> NONAUTH split a few weeks ago, you'll know that ARIN moved around 56% of
> all their IRR route/route6 objects into the ARIN-NONAUTH source database.
> This was based on objects that are not owned within ARIN managed space.
> For more on this; review the ARIN mailing lists and the video from their
> meeting a few weeks ago.
>
> But what about all those as-set objects within ARIN IRR? This wasn't really
> reviewed heavily and so I thought, I'd dump some info everyone's-way. Yes
> there are objects and yes, some moved to ARIN-NONAUTH (and hence maybe
> aren't being used for route filtering anymore).
>
> First off - this data is based on the ARIN IRR database dump of 24/June/2020.
> You can find the current IRR data at ftp://ftp.arin.net/pub/rr/ - it's easy to
> download the dataset. Here's the raw numbers:
>
> $ gunzip < arin-nonauth.db.gz | egrep -i '^as-set:' | wc -l
> 154
> $ gunzip < arin.db.gz | egrep -i '^as-set:' | wc -l
> 1413
> $
>
> Only around 154 as-set objects were placed into ARIN-NONAUTH. Around
> 9.8% of the total number of objects.
>
> Running a quick script against the RADB combined IRR database shows that of
> those 154 as-set objects that ARIN moved; there're 133 as-set objects that are
> only in ARIN-NONAUTH. An object with that name doesn't exist in any other
> IRR (like ARIN, ALTDB, RADB, etc.)
>
> Of the remaining 21 as-set objects, the object names (but maybe not the same
> content???) exist in various other IRR registries. As
> follows:
>
> AS-RAWBW | |ALTDB| | |
> AS-NFCR | |ALTDB|RADB| |
> AS-CTA |ARIN| | |RIPE|
> AS-27299 | | |RADB| |
> AS-33251-TRANSIT-CUSTOMERS | | |RADB| |
> AS-46844 | | |RADB| |
> AS-7349-TRANSIT-CUSTOMERS | | |RADB| |
> AS-ELI | | |RADB| |
> AS-MEEBO | | |RADB| |
> AS-MFT | | |RADB| |
> AS-28140 | | | |RIPE|
> AS-FUZENET | | | |RIPE|
> AS-MM | | | |RIPE|
> AS-NETLOGIC | | | |RIPE|
> AS-PCNET | | | |RIPE|
> AS-SVINE | | | |RIPE|
> AS-BLUENET | | |RADB|RIPE|
> AS-LIUXYON | |ALTDB| |RIPE|
> AS-NITAET | |ALTDB| |RIPE|
> AS-NITAETv6 | |ALTDB| |RIPE|
> AS-VIATEL | | |RADB|RIPE|
>
> I didn't try to check the content of these - but then again; comparing as-set's
> across IRRs is a thankless task - even in the best of days.
>
> So where does this leave us? We have various networks that own as-set's that
> are now potentially unavailable to upstreams or transit providers for creating
> customer filters. Keep in mind that ARIN-NONAUTH exists within RADBs IRR
> datasets - so it's possible that some upstream transits may use that data.
> Some may not. YMMV.
>
> Now onto the next step - answering that question.
>
> Of the 154 as-set objects, only 29 names appear in other as-set objects. (BTW:
> Thanks to "irrexplorer" for that information!). It does not mean that the 125
> other entries are unused - they may be used; but not referenced by their
> transits (doubly so if the transit is a tier1).
>
> Focusing on the 29 that are referenced somewhere else; you end up with this
> listing showing the as-set object name that they appear in. If they appear in
> ARIN-NONAUTH that's kinda zero sum game. If they show as being referenced
> in other IRRs then there's hope - but not really, as they are ARIN-NONAUTH
> objects. Basically - however, you look at it; lesser filters are being created and
> maybe routing is affected.
>
> AS-23016:AS-BACKBONE
> ARIN-NONAUTH mentioned-in AS-23016
> AS-23073
> ARIN-NONAUTH mentioned-in AS-23073
> AS-6653
> RADB mentioned-in AS-COMCAST-IBONE
> AS-AHS
> LEVEL3 mentioned-in AS-BANDCON
> LEVEL3 mentioned-in AS-ISOMEDIA
> RADB mentioned-in AS-ISOFUSION
> AS-AS36412-CUSTOMERS
> ARIN-NONAUTH mentioned-in AS-AS36412-ALL
> AS-CBSI
> RIPE mentioned-in AS-TELIANETNA
> RIPE mentioned-in AS-TELIANETNA-V6
> AS-CDSTEPHENS
> RIPE mentioned-in AS-4IXP
> AS-CRM-AR
> RIPE mentioned-in AS-TDATANETSA
> AS-FCH-Customers
> ARIN-NONAUTH mentioned-in AS-FCH
> AS-IMGIX
> NTTCOM mentioned-in AS2914:AS-US
> AS-IRONP-1
> ALTDB mentioned-in AS-NLAYER-CUSTOMERS
> AS-LOGIN
> ARIN mentioned-in AS-DECIX-DFW
> ARIN mentioned-in AS-DECIX-DFW-V6
> AS-MCBB-INTERNAL
> ARIN-NONAUTH mentioned-in AS-MCBB
> AS-MCBB-TRANSIT
> ARIN-NONAUTH mentioned-in AS-MCBB
> AS-MEDIA-HOSTS
> ALTDB mentioned-in AS-NETELLIGENT
> AS-MQCUSTOMERS
> ARIN-NONAUTH mentioned-in AS-MARQUISNET
> ARIN-NONAUTH mentioned-in AS35937:AS-MARQUISNET
> AS-PEACHNET
> RADB mentioned-in AS-DEFENSE
> AS-SAIX
> ARIN-NONAUTH mentioned-in AS-SAIX-ALLCUST
> BBOI mentioned-in AS-OCCAID6-CUSTOMERS
> RADB mentioned-in AS-MZIMA-CUSTOMERS
> RADB mentioned-in AS3491:AS-CUSTOMERS-EU
> RADB mentioned-in AS37271:AS-PEERS:AS5713
> AS-SAIX-PEER
> ARIN-NONAUTH mentioned-in AS-SAIX-ALLCUST
> AS-SAIX-TRANSIT
> ARIN-NONAUTH mentioned-in AS-SAIX
> AS-SAIX-TRANSIT-ZA
> ARIN-NONAUTH mentioned-in AS-SAIX-ALLCUST
> BBOI mentioned-in AS-OCCAID6-CUSTOMERS
> AS-SELECTNET-TRANSIT
> ARIN-NONAUTH mentioned-in AS-SELECTNET
> AS-TELEFONICAMUNDO
> LEVEL3 mentioned-in AS-LEVEL3-POLICY-AS-SETS
> RIPE mentioned-in AS-TDATANETSA
> AS-TELNETCOMM
> RADB mentioned-in AS4470:AS-TORIX-PEERS
> AS13773:AS-CUSTOMERS
> ARIN-NONAUTH mentioned-in AS-TELNETCOMM
> AS19539:AS-IPO-US
> RIPE mentioned-in AS-IPO-EU
> AS21719:ASCUSTOMERS
> ARIN-NONAUTH mentioned-in AS21719:ASORIGIN
> AS21719:ASPEERS
> ARIN-NONAUTH mentioned-in AS21719:ASORIGIN
> AS6140:AS-CUSTOMERS
> BBOI mentioned-in AS-OCCAID6-CUSTOMERS
>
> (If I may interject with a commentary: what a mess!)
>
> I would urge anyone that sees their objects listed above to review their
> entries and if-possible delete/cleanup/consolidate whatever they have into
> just one IRR.
>
> I could continue deep-diving into this area; but it gets very messy very quickly.
> It's best to simply list what's going on and see if folks can help clean-up their
> own data.
>
> Summary: IRR cleanup is hard. Having *-NONAUTH database feels like a good
> thing; but just leaves more of a mess in the global tables.
>
> Happy IRR database hunting!
>
> Martin
Maggiori informazioni sulla lista
itnog