Re: Fwd: Fw: HOST IRR Retirement
Hello Ross , I do not see a host name or IP4or6 in the below . Hth , JimL On Mon, 11 Apr 2022, Ross Tajvar wrote: I tried sending the below message from my work account, but it's not a nanog subscriber, so the email was rejected. If anyone doubts the authenticity, feel free to reach out to me at rtaj...@365datacenters.com. -- *From:* Ross Tajvar *Sent:* Monday, April 11, 2022 3:53 PM *To:* nanog@nanog.org *Subject:* HOST IRR Retirement Hi all, We (365 Datacenters) inherited the HOST IRR. We have removed all stale objects from it, and moved all valid objects to other IRRs. We will eventually (hopefully soon) turn it off altogether. Please, if you are mirroring it, stop doing that. If you maintain documentation that lists IRRs, please update it to reflect that HOST is no longer in use. Thanks! P.S. If anyone thinks I should also announce this somewhere else, please let me know. *Ross Tajvar* Network Engineer Office: (571)-341-8899 Support: (866)-365-6246 -- +-+ | James W. Laferriere| SystemTechniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | j...@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +-+
Fwd: Fw: HOST IRR Retirement
I tried sending the below message from my work account, but it's not a nanog subscriber, so the email was rejected. If anyone doubts the authenticity, feel free to reach out to me at rtaj...@365datacenters.com. -- *From:* Ross Tajvar *Sent:* Monday, April 11, 2022 3:53 PM *To:* nanog@nanog.org *Subject:* HOST IRR Retirement Hi all, We (365 Datacenters) inherited the HOST IRR. We have removed all stale objects from it, and moved all valid objects to other IRRs. We will eventually (hopefully soon) turn it off altogether. Please, if you are mirroring it, stop doing that. If you maintain documentation that lists IRRs, please update it to reflect that HOST is no longer in use. Thanks! P.S. If anyone thinks I should also announce this somewhere else, please let me know. *Ross Tajvar* Network Engineer Office: (571)-341-8899 Support: (866)-365-6246
Re: Something observed while doing IRR cleanup (generic name collisions)
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
Something observed while doing IRR cleanup (generic name collisions)
All, The dayjob has a LOT of ASes (we peer with a unique AS per-site), so our IRR entries are kind of a lot. When "email templates" was the only way to do things, this was really annoying to update and maintain. I will say that having RPKI roas for the correct ASes for all of our entries has given my stale-object-deletion-requests more "authoritah" than those requests would have had a few years ago. Job's excellent IRRexplorer tool has been wonderful in helping figure this out and display it all at a glance, and also in finding cases where "we no longer peer with this group, but we're still in the as-set", and a few where "they peer with us, but not with this AS". I don't know how many people use irrd or rtconfig or whatever to generate your filter-lists. But even with all the work we (the operator community) is doing to widely deploy RPKI and authenicated IRRs, we still have stuff like this: $ whois -h whois.radb.net AS-PEERS | grep 'as-set\|descr\|source\|members\|^\s*$' as-set: AS-PEERS descr: autonomous systems that OpenDNS peers with members:[like 30 of them, one per line, snipped for brevity] source: RADB as-set: AS-PEERS descr: 4b42 Peering Autonomous System Numbers [no members: line!] source: RIPE 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. 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. -Dan --
