May 2023 - mice-discuss - lists.micemn.net

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

I added some bits about IXP Manager and IRR to the website: https://micemn.net/technical.html I also updated the communities bit to reflect what the new route servers will support. Suggestions welcome. -- Richard

May 23, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

This is the current cutover plan: Phase 1: On Tuesday, May 23, starting around 10:00 AM US/Central, we will upgrade route server 1. It will enforce the IRR as-set requirement for transit ASes, but will NOT enforce the IRR prefix requirement. Since route server 2 will still exist, even the as-set requirement is only a soft requirement. Phase 2: On Wednesday, May 31, starting around 10:00 AM US/Central, we will upgrade route server 2. It will be fully enforcing. At that point, the as-set requirement will be a hard requirement. The prefix IRR requirement will still be a soft requirement, as route server 1 will still not be enforcing. Phase 3: Tentatively, on Wednesday, June 7, starting around 10:00 AM US/Central, we will configure route server 1 to be fully enforcing. At that point, all IRR requirements will hard requirements. This date is subject to change based on what we see filtered. *We ask that you do /not/ take down your route server BGP sessions for these changes, as that will make it harder for us to know if things are working. If you are going to do so (e.g. because your organization's policies require it), then please let me know so I can expect your session to be down.* -- Richard

May 13, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

I am currently allowing the following sources across the board: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,NTTCOM,LEVEL3 On 2023-05-12 11:14, Michael Hare wrote: > It also handles the $REGISTRY::$THING model. Thanks for the tip! I switched from bgpq3 to bgpq4. IXP Manager doesn't support bgpq4, but the only difference was one flag. I used a wrapper script for now, and filed a feature request with IXP Manager: https://github.com/inex/IXP-Manager/issues/844 Arnold Nipper, via the IXP Manager mailing list, gave me an example of how to get this information out of PeeringDB. With that, I was able to write a script to interact with the IXP Manager database. It pulls the current settings from IXP Manager, pulls from PeeringDB, reports any changes, updates IXP Manager, and triggers the ASN & prefix updates in IXP Manager. I have that set to run hourly. The route servers will update their configuration hourly, offset by 30 minutes. That is, route server 1 will update at xx:08 and route server 2 will update at xx:38. -- Richard

May 13, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Michael Hare

FWIW, AS3128 uses some homegrown stuff to wrap bgpq4, bgpq4 provides an ability to deal with concern #3 below for recursion [if you choose to accept the caveats]. See https://github.com/bgp/bgpq4#notes-on-sources. It also handles the $REGISTRY::$THING model. This may just be cool info for the time being, but you may find it interesting. For AS3128 peers I've had to provide a way to list sources per peer; look up AS-SUPRANET in RIPE vs ARIN. The one I want is in ARIN so the ordering matters. Yes, I know AS-$number is a better idea and AS-UWSYSNET is also guilty as charged. -Michael > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of > Richard Laager > Sent: Thursday, May 11, 2023 11:27 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers > > On 2023-05-11 10:30, Chris Wopat wrote: > > Can't folks just specify which IRR in their IRR entry if desired? Ie > > > > ARIN::AS1234 > > 1. bgpq3 does not accept that format, at least in my limited testing. > > 2. IXP Manager would likely need changes to support that, specifically > not passing the argument for sources to bgpq3 if a disambiguation was > provided. > > 3. I think the more important fundamental issue is that a transit AS's > as-set might need to reference customer ASes/as-sets that are in other > registries. > > > FWIW we only use RADB but are fine if the common IRR's (but not legacy > > arin) are used. > > > > Also is there any reason at all to use non-ARIN teritory IRR data? Do > > any MICE participants have anything in RIPE for example? > > See #3 above. > > For example, someone like Hurricane Electric can't ask all of their > customers worldwide to be in ARIN. Given the way this has historically > developed, I don't think it's even reasonable to expect that only-RIR > registries are used. > > -- > Richard

May 12, 2023

Please welcome ImOn Communications to MICE!

by Jeremy Lumby

Name: ImOn Communications Switch: MN VoIP Port: Adding E40, E41 and E42 to Po5 for a total of 7x10G ASN: 393238 IPv4: This is a port addition. All IP info remains the same. IPv6: Peering Contact: imonadmins(a)imon.net Route Servers: Yes BFD: Yes Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 M: 612-355-7740 D: 612-392-6814 F: 952-873-7425 jlumby(a)mnvoip.com

May 12, 2023

Re: [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Miles McCredie

I did a spot check of a few ASNs and it looks to me as though the following ASNs have route(6) objects that only exist in NTTCOM: 2906, 20940 and 33438. (Stopped looking after I found these three.) My recommendation is to include NTTCOM. The cruft in the database should be suppressed according to https://www.gin.ntt.net/support-center/policies-procedures/routing-registry…. [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie(a)midco.com Midco.com From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 11:52 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers On 2023-05-11 05:58, Miles McCredie wrote: I think a global list of sources would be easier to maintain and document. Excellent point. Is NTTCOM no longer trusted? The available sources are here: https://www.radb.net/query/?advanced_query=1 That does include NTTCOM, so we could use it. But if nobody is speaking up in favor of it, I'm not currently planning on it. The list I gave was the union of all choices that exist in IXP Manager by default, minus ARIN-NONAUTH and RIPE-NONAUTH. -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 12, 2023

Re: [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-05-11 05:58, Miles McCredie wrote: > > I think a global list of sources would be easier to maintain and document. > Excellent point. > Is NTTCOM no longer trusted? > The available sources are here: https://www.radb.net/query/?advanced_query=1 That does include NTTCOM, so we could use it. But if nobody is speaking up in favor of it, I'm not currently planning on it. The list I gave was the union of all choices that exist in IXP Manager by default, minus ARIN-NONAUTH and RIPE-NONAUTH. -- Richard

May 12, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Jay Hanke

> For example, someone like Hurricane Electric can't ask all of their > customers worldwide to be in ARIN. Given the way this has historically > developed, I don't think it's even reasonable to expect that only-RIR > registries are used. The provided list is the list of IRR (+ IRR combinations) that shows up in the pulldown menu in the admin interface of IXP Manager. It points to the where the AS-SET record is located for the directly attached member. So when you put the information in you select the IRR and type in (or pull) the AS-SET record. bgpq3/4 will then pull all the prefixes and generate a filter list from the union of all the prefixes listed. The AS_set name in the DB::NAME format will just need to be reformatted when entered into IXP Manager web interface.

May 11, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-05-11 10:30, Chris Wopat wrote: > Can't folks just specify which IRR in their IRR entry if desired? Ie > > ARIN::AS1234 1. bgpq3 does not accept that format, at least in my limited testing. 2. IXP Manager would likely need changes to support that, specifically not passing the argument for sources to bgpq3 if a disambiguation was provided. 3. I think the more important fundamental issue is that a transit AS's as-set might need to reference customer ASes/as-sets that are in other registries. > FWIW we only use RADB but are fine if the common IRR's (but not legacy > arin) are used. > > Also is there any reason at all to use non-ARIN teritory IRR data? Do > any MICE participants have anything in RIPE for example? See #3 above. For example, someone like Hurricane Electric can't ask all of their customers worldwide to be in ARIN. Given the way this has historically developed, I don't think it's even reasonable to expect that only-RIR registries are used. -- Richard

May 11, 2023

Re: [External] Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Tom Krenn

Would it be safe to assume that squatting wouldn't happen in the RIR's authenticated IRRs? And that if multiple entries exist among them, that keeping them in sync or free of bad data would be on the individual participant? If so placing the authenticated RIRs above everything else seems a pretty safe bet. Order among them wouldn't really matter. Personally given that I would love to see us grab the sets from the aut-num object for the participants ASN. Seems like ignoring the routing policy in the aut-num object in favor of PeeringDB or a manual process is only half using the IRR system. (That said I understand that bgpq3 doesn't use the aut-num object.) Tom Krenn Network Architect Enterprise Architecture - Information Technology -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Chris Wopat Sent: Thursday, May 11, 2023 10:30 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [External] Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments. Can't folks just specify which IRR in their IRR entry if desired? Ie ARIN::AS1234 FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used. Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example? --Chris On 5/11/23 10:01, Jeremy Lumby wrote: > External > > I do not see a need for per participant IRR, I would rather that they > all just default to your example below. > > *From:*MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> *On Behalf Of > *Richard Laager > *Sent:* Thursday, May 11, 2023 3:58 AM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route > Servers > > On 2023-05-09 14:01, August Yang wrote: > > Should I reorder RADB,ARIN to be ARIN,RADB? > > Definitely. We have objects registered in all databases feasible to > prevent AS-SET squatting, which has occurred in the past, while only > RADB has the actual members listed. Turns out correct prefix list > can be generated using bgpq4 regardless of the order, so it's better > to prioritize authenticated sources. > > In thinking about this some more... Is IXP Manager's behavior of > per-participant IRR sources actually useful? In other words, what's > wrong with just setting everyone to: > ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? > > -- > > Richard > > ---------------------------------------------------------------------- > -- > > To unsubscribe from the MICE-DISCUSS list, click the following link: > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists > .iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7C > 01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8aef > df9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2FaF > NQAWWg%3D&reserved=0 > <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > s.iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7 > C01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8ae > fdf9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2Fa > FNQAWWg%3D&reserved=0> > > > ---------------------------------------------------------------------- > -- > > To unsubscribe from the MICE-DISCUSS list, click the following link: > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists > .iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7C > 01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8aef > df9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2FaF > NQAWWg%3D&reserved=0 > <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > s.iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7 > C01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8ae > fdf9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2Fa > FNQAWWg%3D&reserved=0> > -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965 Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.

May 11, 2023