Something observed while doing IRR cleanup (generic name collisions)
Job Snijders
job at fastly.com
Mon Apr 11 17:32:19 UTC 2022
Hi Dan!
You highlight a common pitfall in IRR-based prefix filter generation.
On Mon, Apr 11, 2022 at 09:56:59AM -0700, Dan Mahoney (Gushi) wrote:
> [snip]
> as-set: AS-PEERS
> descr: Peer AS Numbers
> members: AS132251,AS132561,AS132516
> source: APNIC
>
> as-set: AS-PEERS
> descr: swell.network Peers
> members: AS-HE,AS-NTT
> source: ARIN
>
> ..four separate organizations felt it would be clever to create a
> vaguely-named AS-PEERS object, each in a different IRR, because the various
> IRR's all allow this, and don't check for the existence of objects in
> another. No IRR's require any special names, nor do they block on any
> generic names. No IRR sends a member warnings when their objects exist in
> more than one registry with different data.
The RPSL RFCs permit a syntax which helps increase the potential for
'uniqueness' of object names across multiple databases: the trick is to
prepend the object with one's ASN. An example: "AS15562:AS-SNIJDERS"
This approach is also known as "hierarchical AS-SET naming". IRRd v4.2
instances require this naming approach for newly created objects.
Because of this feature the LACNIC IRR data source contains only
hierarchically named AS-SETs! Progress might seem slow, but all journeys
start with a few small steps. :-)
Hierarchical naming does not prevent the existence of duplicate names
across IRR databases, but it sure does help!
> I haven't tried to query the peeringdb API to see if any of these are
> used as advertised AS-Sets for public use, or if people just created
> public objects for their own internal tools. I'm sure this is not the
> only case of this.
>
> This might be why we can't have nice things.
Patience is the path towards nice things :-)
Kind regards,
Job
More information about the NANOG
mailing list