- mice-discuss - lists.micemn.net

UG 27 / MTA

by Richard Laager

MTA has agreed to give us a table across from the registration desk. Ideally, we would have someone sit there to talk about MICE with anyone interested. Here are the MTA registration times: Monday, March 26 - 12:00 pm - 6:30 pm Tuesday, March 27 - 7:30 am - 5:00 pm Wednesday, March 28 - 7:30 am - 12:00 pm I'd imagine most people will be registering on Monday or early Tuesday. I'm happy to sit there, but our UG 27 meeting is currently scheduled for Monday at 3:00, which pretty much shoots the whole Monday timeslot. At best, I could setup some things on the table and then rush to 511 for the UG meeting. One option is to move the UG meeting to Tuesday, March 27 at 3:00. This would allow me (and/or anyone else interested) to sit at the MICE table on Monday afternoon and Tuesday morning. On the other hand, if someone was planning on attending both MTA and UG 27, it seems like this would create a conflict. Another option would be to leave the meeting as is, and have someone else (who would skip the UG meeting) volunteer to sit at the table on Monday. A third option would be to reschedule the UG meeting to Wednesday, after MTA concludes. How do you feel about these options? Any other suggestions? -- Richard

Jan. 17, 2018

Please Welcome Coloplast to MICE!

by Jason Hanke

Name: Coloplast Port: ge-0/0/19 (Copper Main) ASN: 25111 IPv4: 206.108.255.91/24 IPv6: 2001:504:27:0:0:6217::1/64 Peering Contact: plmgaw(a)coloplast.com Route Server: Yes BFD: NO Please update your peeringdb information as soon as you have the chance. Thanks! -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Jan. 16, 2018

Re: MICE route reflect hiccup last night?

by Doug McIntyre

It is set for missing 3 BFD updates will drop it, but I believe an error condition like "invalid flags (248)" is what caused the issue. I don't see any flags in RFC5880, I suspect source code reading would be next to see what BIRD thought of flags in BFD that aren't mentioned in the RFC. On Tue, Jan 09, 2018 at 10:07:17PM +0000, Frank Bulk wrote: >Thanks. This is why BFD can be so frustrating. So just one bad packet and the BFD session was torn down? Or three in a row? > >Frank > >-----Original Message----- >From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre >Sent: Tuesday, January 09, 2018 3:08 PM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >Subject: Re: [MICE-DISCUSS] MICE route reflect hiccup last night? > >On Tue, Jan 09, 2018 at 08:25:44PM +0000, Frank Bulk wrote: >>Our logs show that MICE RR #1 had a hiccup overnight ... none of our other BGP sessions to MICE were interrupted. Did something scheduled happened? > >No, but your BFD session received.. > >2018-01-09 03:41:40 <RMT> bfd1: Bad packet from 206.108.255.67 - invalid flags (248) > >That's all I've got related to it in the logs. > >-- >Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Jan. 10, 2018

Re: MICE route reflect hiccup last night?

by Frank Bulk

Thanks. This is why BFD can be so frustrating. So just one bad packet and the BFD session was torn down? Or three in a row? Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, January 09, 2018 3:08 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE route reflect hiccup last night? On Tue, Jan 09, 2018 at 08:25:44PM +0000, Frank Bulk wrote: >Our logs show that MICE RR #1 had a hiccup overnight ... none of our other BGP sessions to MICE were interrupted. Did something scheduled happened? No, but your BFD session received.. 2018-01-09 03:41:40 <RMT> bfd1: Bad packet from 206.108.255.67 - invalid flags (248) That's all I've got related to it in the logs. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Jan. 9, 2018

Re: MICE route reflect hiccup last night?

by Doug McIntyre

On Tue, Jan 09, 2018 at 08:25:44PM +0000, Frank Bulk wrote: >Our logs show that MICE RR #1 had a hiccup overnight ... none of our other BGP sessions to MICE were interrupted. Did something scheduled happened? No, but your BFD session received.. 2018-01-09 03:41:40 <RMT> bfd1: Bad packet from 206.108.255.67 - invalid flags (248) That's all I've got related to it in the logs. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Jan. 9, 2018

MICE route reflect hiccup last night?

by Frank Bulk

Our logs show that MICE RR #1 had a hiccup overnight ... none of our other BGP sessions to MICE were interrupted. Did something scheduled happened? Jan 9 03:41:41 192.168.0.85 BFD: Session DOWN for 206.108.255.1 on eth 2/2 Reason:Detection Time Expired Jan 9 03:41:41 192.168.0.85 BFD: Session UP for 206.108.255.1 on eth 2/2 Jan 9 03:41:41 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Rcv Notification:CEASE Message) Jan 9 03:41:41 192.168.0.85 BFD: Session DOWN for 206.108.255.1 on eth 2/2 Reason:Administratively Down Jan 9 03:41:41 192.168.0.85 BFD: Session DOWN for 2001:504:27::d1af:0:1 on eth 2/2 Reason:Detection Time Expired Jan 9 03:41:41 192.168.0.85 BGP: Peer 2001:504:27::d1af:0:1 DOWN (Rcv Notification:CEASE Message) Jan 9 03:42:36 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Jan 9 03:42:36 192.168.0.85 BFD: Session UP for 206.108.255.1 on eth 2/2 Jan 9 03:42:41 192.168.0.85 BGP: Peer 2001:504:27::d1af:0:1 UP (ESTABLISHED) Frank

Jan. 9, 2018

MICE Looking Glass router

by David Farmer

The MICE Looking Glass router doesn't seem to be supporting 4-byte ASNs. Could someone upgrade the code please. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Jan. 5, 2018

Re: Passive BFD support on Route-Server #1

by Frank Bulk

Great, thanks! -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Friday, December 29, 2017 11:13 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Passive BFD support on Route-Server #1 On 12/29/2017 09:38 PM, Frank Bulk wrote: > Can the documentation at http://www.micemn.net/participants.html reflect that the RR's are now using BFD? Good idea. Done. > And maybe it can be noted on PeeringDB, too. I don't know who has the PeeringDB login. Jay? -- Richard

Jan. 1, 2018

Re: Passive BFD support on Route-Server #1

by Richard Laager

I have emailed their support address for help. -- Richard > On Dec 30, 2017, at 09:55, Jason Hanke <jayhanke(a)NEUTRALPATH.NET> wrote: > > I haven't been able to update the mice entry for peeringdb for quite some time. > > It might be a good idea for one of the board members or tech members to get added as a contact as well. > >> On Dec 29, 2017 11:13 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: >> I haven't been able to update the mice entry in peeringdb for quite some time. >> >> It might be a good idea for one of the board members or tech members to get set up as the contact. >> >>> On Dec 29, 2017 11:13 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: >>> On 12/29/2017 09:38 PM, Frank Bulk wrote: >>> > Can the documentation at http://www.micemn.net/participants.html reflect that the RR's are now using BFD? >>> >>> Good idea. Done. >>> >>> > And maybe it can be noted on PeeringDB, too. >>> >>> I don't know who has the PeeringDB login. Jay? >>> >>> -- >>> Richard > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 30, 2017

Re: Passive BFD support on Route-Server #1

by Jason Hanke

I haven't been able to update the mice entry for peeringdb for quite some time. It might be a good idea for one of the board members or tech members to get added as a contact as well. On Dec 29, 2017 11:13 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: > I haven't been able to update the mice entry in peeringdb for quite some > time. > > It might be a good idea for one of the board members or tech members to > get set up as the contact. > > On Dec 29, 2017 11:13 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: > >> On 12/29/2017 09:38 PM, Frank Bulk wrote: >> > Can the documentation at http://www.micemn.net/participants.html >> reflect that the RR's are now using BFD? >> >> Good idea. Done. >> >> > And maybe it can be noted on PeeringDB, too. >> >> I don't know who has the PeeringDB login. Jay? >> >> -- >> Richard >> >

Dec. 30, 2017

Re: Passive BFD support on Route-Server #1

by Jason Hanke

I haven't been able to update the mice entry in peeringdb for quite some time. It might be a good idea for one of the board members or tech members to get set up as the contact. On Dec 29, 2017 11:13 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: > On 12/29/2017 09:38 PM, Frank Bulk wrote: > > Can the documentation at http://www.micemn.net/participants.html > reflect that the RR's are now using BFD? > > Good idea. Done. > > > And maybe it can be noted on PeeringDB, too. > > I don't know who has the PeeringDB login. Jay? > > -- > Richard >

Dec. 30, 2017

Re: Passive BFD support on Route-Server #1

by Richard Laager

On 12/29/2017 09:38 PM, Frank Bulk wrote: > Can the documentation at http://www.micemn.net/participants.html reflect that the RR's are now using BFD? Good idea. Done. > And maybe it can be noted on PeeringDB, too. I don't know who has the PeeringDB login. Jay? -- Richard

Dec. 30, 2017

Re: Passive BFD support on Route-Server #1

by Frank Bulk

Can the documentation at http://www.micemn.net/participants.html reflect that the RR's are now using BFD? And maybe it can be noted on PeeringDB, too. Thanks, Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Monday, December 11, 2017 12:23 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Passive BFD support on Route-Server #1 On Mon, Dec 04, 2017 at 03:12:28PM -0600, Doug McIntyre wrote: >Just to close this project out, I'll set a schedule to get this done. > >On Monday, 12/11/2017 at 12:30AM, I'll turn on passive BFD on the MICE route >server #1 (206.108.255.1/ 2001:504:27::d1af:0:1) for all connections. This was completed. No complications as far as I can see. I'll let this config run for a week and schedule up the other route server. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 30, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by Andrew Hoyos

On Dec 29, 2017, at 8:43 PM, Frank Bulk <fbulk(a)mypremieronline.com> wrote: > > Is there a toolset that could generate a filter based on several common IRR’s and ARIN information see what kind of coverage there would be? IRR Explorer is your friend: http://irrexplorer.nlnog.net/ <http://irrexplorer.nlnog.net/> (search for your ASN, or whatever your AS-SET is) Also, IRRToolset: https://github.com/irrtoolset/irrtoolset <https://github.com/irrtoolset/irrtoolset> — Andrew Hoyos hoyosa(a)gmail.com

Dec. 30, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by Frank Bulk

Is there a toolset that could generate a filter based on several common IRR’s and ARIN information see what kind of coverage there would be? I just fixed up several of my $DAYJOB’s ARIN records tonight. Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Wednesday, December 20, 2017 12:36 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [routing-wg] a new source for authoritative routing data: ARIN WHOIS I see the disconnect now. I said,"because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE." Richard's questions was "which IRR should we(MICE) recommend networks use, if they aren't already using one, not which IRR MICE should use." And the answer to that question is use ARIN ONLINE and not an IRR. And yes they would be to a network that received it's block from ARIN, which is the case for the vast majority of MICE connected networks. I wasn't suggesting the MICE could only use ARIN WHOIS info. MICE would have to generate filters based on ARIN WHOIS and all the IRRs. Hope that clarifies things. Thanks. On Wed, Dec 20, 2017 at 11:11 AM, DeLong, Owen <00000005a669d12e-dmarc-request(a)lists.iphouse.net<mailto:00000005a669d12e-dmarc-request@lists.iphouse.net>> wrote: If MICE starts building filters based on ARIN whois, that won’t include data from other IRRs or IRR data at all. If MICE is building filters from IRR databases, it won’t include the ARIN whois information. We’d have to merge data from both sources in order to have a workable solution that doesn’t ignore important data. Thus, David’s suggestion that we could “just use ARIN ONLINE” without using any IRR doesn’t match my understanding of Job’s message. Owen On Dec 20, 2017, at 08:52 , David Farmer <farmer(a)UMN.EDU<mailto:farmer@UMN.EDU>> wrote: No, it is simply another option to provide Prefix/ASN binding information for address blocks registered with ARIN, you can still do it with an IRR if you wish. On Wed, Dec 20, 2017 at 10:38 AM, DeLong, Owen <00000005a669d12e-dmarc-request(a)lists.iphouse.net<mailto:00000005a669d12e-dmarc-request@lists.iphouse.net>> wrote: This assumes that all prefixes advertised at MICE are issued by ARIN. Owen On Dec 19, 2017, at 14:54 , David Farmer <farmer(a)umn.edu<mailto:farmer@umn.edu>> wrote: FYI, A very interesting development in light of our discussions about doing route filtering at MICE. With this development I enthusiastically support moving forward with route filtering because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE. Thanks. ---------- Forwarded message ---------- From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg(a)ripe.net<mailto:routing-wg@ripe.net> Dear RIPE WG, I'm sharing a copy of what I sent to NANOG. This is specifically of interest to networks and route server operators that have customers who also operate in the ARIN region. In the RIPE region we've always had the convenience that the "WHOIS" ('inetnum') and "IRR" ('route/route6') components of the database were interleaved. Only the IP block's owner can create or authorise others regarding creation of route-objects. This coupling of WHOIS and IRR doesn't exist at rr.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=…> vs whois.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ…> - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> To: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: a new source for authoritative routing data: ARIN WHOIS Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters…<https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_0…> That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ…>) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/<https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedoc…>) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job@vurt:~$ whois -h rr.ntt.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> -- "-sARIN-WHOIS 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…>" route: 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1<https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_ne…> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job(a)ntt.net<mailto:job@ntt.net> 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(612)%20812-9952> =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(612)%20812-9952> =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 30, 2017

Super Bowl Street Closures

by David Farmer

Attached is the street closure map for the Super Bowl 52 around US Bank Stadium and the 511 Building. Most of the closures are for the week before or the weekend of the game itself, but some begin as early as next week and continue more than a week following the game. Particularly of interest, 5th street on the north side of 511 will be closed 1/2 - 2/11. More details are available at; http://www.ci.minneapolis.mn.us/VISITORS/SUPERBOWL/WCMSP-195148 If you are headed to 511 in the next month or so, beware it could be an adventure. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 27, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by David Farmer

I see the disconnect now. I said,"because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE." Richard's questions was "which IRR should we(MICE) recommend networks use, if they aren't already using one, not which IRR MICE should use." And the answer to that question is use ARIN ONLINE and not an IRR. And yes they would be to a network that received it's block from ARIN, which is the case for the vast majority of MICE connected networks. I wasn't suggesting the MICE could only use ARIN WHOIS info. MICE would have to generate filters based on ARIN WHOIS and all the IRRs. Hope that clarifies things. Thanks. On Wed, Dec 20, 2017 at 11:11 AM, DeLong, Owen < 00000005a669d12e-dmarc-request(a)lists.iphouse.net> wrote: > If MICE starts building filters based on ARIN whois, that won’t include > data from other IRRs or IRR data at all. > > If MICE is building filters from IRR databases, it won’t include the ARIN > whois information. > > We’d have to merge data from both sources in order to have a workable > solution that doesn’t ignore important data. > > Thus, David’s suggestion that we could “just use ARIN ONLINE” without > using any IRR doesn’t match my understanding of > Job’s message. > > Owen > > On Dec 20, 2017, at 08:52 , David Farmer <farmer(a)UMN.EDU> wrote: > > No, it is simply another option to provide Prefix/ASN binding information > for address blocks registered with ARIN, you can still do it with an IRR if > you wish. > > On Wed, Dec 20, 2017 at 10:38 AM, DeLong, Owen <00000005a669d12e-dmarc- > request(a)lists.iphouse.net> wrote: > >> This assumes that all prefixes advertised at MICE are issued by ARIN. >> >> Owen >> >> On Dec 19, 2017, at 14:54 , David Farmer <farmer(a)umn.edu> wrote: >> >> FYI, >> >> A very interesting development in light of our discussions about doing >> route filtering at MICE. >> >> With this development I enthusiastically support moving forward with >> route filtering because it provides an easy answer to Richards question >> about which IRR to use, you don't have to use any of them you can do it all >> in ARIN ONLINE. >> >> Thanks. >> >> ---------- Forwarded message ---------- >> From: Job Snijders <job(a)ntt.net> >> Date: Tue, Dec 19, 2017 at 4:37 PM >> Subject: [routing-wg] a new source for authoritative routing data: ARIN >> WHOIS >> To: routing-wg(a)ripe.net >> >> >> Dear RIPE WG, >> >> I'm sharing a copy of what I sent to NANOG. This is specifically of >> interest to networks and route server operators that have customers who >> also operate in the ARIN region. >> >> In the RIPE region we've always had the convenience that the "WHOIS" >> ('inetnum') and "IRR" ('route/route6') components of the database were >> interleaved. Only the IP block's owner can create or authorise others >> regarding creation of route-objects. This coupling of WHOIS and IRR >> doesn't exist at rr.arin.net >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=…> >> vs whois.arin.net >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ…> >> - so I consider the >> following a significant improvement. >> >> Kind regards, >> >> Job >> >> ----- Forwarded message from Job Snijders <job(a)ntt.net> ----- >> >> Date: Tue, 19 Dec 2017 22:18:20 +0000 >> From: Job Snijders <job(a)ntt.net> >> To: nanog(a)nanog.org >> Subject: a new source for authoritative routing data: ARIN WHOIS >> >> Dear NANOG, >> >> I'd like to share an update on some routing security activities that >> ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG >> Foundation, and the arouteserver project have been collaborating on. >> Quite some puzzles pieces were brought together! :) >> >> Traditionally, there are two commonly-used methods to signal to your >> peers or upstream providers what Origin ASN(s) are allowed to originate >> a given IP prefix. As an operator, you can either create a "route >> object" in the IRR, or you can compose a Letter Of Agency (LOA) and send >> that to your upstream providerfor manual verification. >> >> When it comes to manual verification of routing data (such a LOA), one >> of the big questions is "what data source is actually authoritative for >> the verification?". In the ARIN registry the so-called "OriginAS" >> attribute can be used for this purpose. The OriginAS attribute can only >> be set or modified by authorized accounts (such as the holder of the IP >> space). This makes the OriginAS attribute a very reliable source of >> truth! ARIN shared some notes on LOAs & OriginAS in the following article: >> https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-v >> alidate-letters-of-authority/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_0…> >> >> That teamarin posting got me thinking: clearly there is a lot of >> valuable routing information in the ARIN WHOIS registry. What if we make >> the process such that you don't have to email in a LOA, and, have the >> recipient verify it against against the web interface output (which you >> updated before sending in the LOA). What if the prefix-filter generation >> software could just programmatically fetch all (CIDR, OriginAS) tuples >> from the ARIN WHOIS registry and load that into the list of prefixes a >> customer is allowed to announce. Just like we do with IRR objects! >> >> A few weeks ago I approached John Curran from ARIN asking whether we >> could work out a mechanism to somehow obtain a computer parsable >> rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path >> forward turned out to be an agreement between the NLNOG Foundation and >> ARIN, which authorises NLNOG to publish a subset of the bulk whois data >> in the convenient format (JSON) for operational purposes. The ARIN WHOIS >> (CIDR, OriginAS) tuples can be downloaded in JSON format here: >> http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> >> >> Because of the JSON dump, the ARIN WHOIS data can now be easily consumed >> by software programs. For example, the JSON file is now loaded into IRR >> Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> >> You can see the 'arin-whois' column which lists what ASN(s) are >> authorized to announce the blocks (this, in addition to what is signaled >> in IRR or RPKI). >> >> The novel thing here is that JSON file not only allows you to look up an >> OriginAS using the IP prefix as a lookup key, but the reverse can now >> also be done: lookup what IP prefixes an ASN is allowed to originate >> (based on ARIN WHOIS data). >> >> Deployment Experience YYCIX: >> >> At this point you may be wondering - what does any of the above have to >> do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ…> >> ) >> or a python-based IXP Route Server management software from Italian >> origins (http://arouteserver.readthedocs.io/en/latest/ >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedoc…>) >> ? :-) >> >> As an experiment to explore real world use of the ARIN WHOIS data and >> prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo >> de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source >> in the prefix filter generation process governing the YYCIX route >> servers. The YYCIX route servers see roughly 80,000 prefixes. >> >> The results are fantastic: ~ 1,700 IPv4 prefixes that were previously >> rejected by the YYCIX route servers (because no IRR route object >> exists), are now accepted because those announcements can be verified >> against data from ARIN's WHOIS registry. This resolved roughly 23% of >> invalid path announcements sent to the YYCIX route servers. >> >> Deployment Experience NTT: >> >> Based on the above positive results, starting today, NTT is also >> accepting ARIN WHOIS OriginAS information in conjunction with IRR route >> objects. Our implementation fetches the ARIN WHOIS data, transforms it >> into RPSL format, and imports it into our IRRd instance at rr.ntt.net >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> >> as >> IRR objects. This way we don't need to update our toolchain to make use >> of this new data source. An example is here: >> >> job@vurt:~$ whois -h rr.ntt.net >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> >> -- "-sARIN-WHOIS 204.209.252.0/23 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> >> " >> route: 204.209.252.0/23 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> >> descr: NET-204-209-252-0-1 >> origin: AS22512 >> remarks: This route object represents authoritative data retrieved >> from ARIN's WHOIS service. >> remarks: The original data can be found here: >> https://whois.arin.net/rest/net/NET-204-209-252-0-1 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_ne…> >> remarks: This route object is the result of an automated >> WHOIS-to-IRR conversion process. >> mnt-by: MAINT-JOB >> changed: job(a)ntt.net 20090220 >> source: ARIN-WHOIS >> >> NTT also observed a substantial number (similar to YYCIX) of BGP >> announcements from its customers that were previously rejected because >> of the lack of an IRR object, but now are validated via ARIN WHOIS. >> >> Conclusion: >> >> It is great to be able to offer network operators a choice: either >> register your BGP announcements as route objects in RPSL format in IRR, >> or use the ARIN WHOIS web interface, (or both) - either way, as IP >> transit carrier, we can now pick up your attestations in an automated >> fashion. This which improves accuracy and reduces red tape! :) >> >> Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source >> in their automation toolchain. The code & procedures to make use of this >> source are open. I'm happy to help you both on-list and off-list. >> >> Kind regards, >> >> Job >> >> ----- End forwarded message ----- >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> >> >> >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> >> > > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> > > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 20, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by Richard Laager

I understood it as: A network could use just ARIN (or an IRR of their choice). MICE would look at multiple IRRs plus the ARIN-based data. -- Richard

Dec. 20, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by DeLong, Owen

If MICE starts building filters based on ARIN whois, that won’t include data from other IRRs or IRR data at all. If MICE is building filters from IRR databases, it won’t include the ARIN whois information. We’d have to merge data from both sources in order to have a workable solution that doesn’t ignore important data. Thus, David’s suggestion that we could “just use ARIN ONLINE” without using any IRR doesn’t match my understanding of Job’s message. Owen On Dec 20, 2017, at 08:52 , David Farmer <farmer(a)UMN.EDU<mailto:farmer@UMN.EDU>> wrote: No, it is simply another option to provide Prefix/ASN binding information for address blocks registered with ARIN, you can still do it with an IRR if you wish. On Wed, Dec 20, 2017 at 10:38 AM, DeLong, Owen <00000005a669d12e-dmarc-request(a)lists.iphouse.net<mailto:00000005a669d12e-dmarc-request@lists.iphouse.net>> wrote: This assumes that all prefixes advertised at MICE are issued by ARIN. Owen On Dec 19, 2017, at 14:54 , David Farmer <farmer(a)umn.edu<mailto:farmer@umn.edu>> wrote: FYI, A very interesting development in light of our discussions about doing route filtering at MICE. With this development I enthusiastically support moving forward with route filtering because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE. Thanks. ---------- Forwarded message ---------- From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg(a)ripe.net<mailto:routing-wg@ripe.net> Dear RIPE WG, I'm sharing a copy of what I sent to NANOG. This is specifically of interest to networks and route server operators that have customers who also operate in the ARIN region. In the RIPE region we've always had the convenience that the "WHOIS" ('inetnum') and "IRR" ('route/route6') components of the database were interleaved. Only the IP block's owner can create or authorise others regarding creation of route-objects. This coupling of WHOIS and IRR doesn't exist at rr.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=…> vs whois.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ…> - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> To: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: a new source for authoritative routing data: ARIN WHOIS Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters…<https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_0…> That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ…>) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/<https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedoc…>) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job@vurt:~$ whois -h rr.ntt.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> -- "-sARIN-WHOIS 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…>" route: 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1<https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_ne…> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job(a)ntt.net<mailto:job@ntt.net> 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(612)%20812-9952> =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…>

Dec. 20, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by David Farmer

No, it is simply another option to provide Prefix/ASN binding information for address blocks registered with ARIN, you can still do it with an IRR if you wish. On Wed, Dec 20, 2017 at 10:38 AM, DeLong, Owen < 00000005a669d12e-dmarc-request(a)lists.iphouse.net> wrote: > This assumes that all prefixes advertised at MICE are issued by ARIN. > > Owen > > On Dec 19, 2017, at 14:54 , David Farmer <farmer(a)umn.edu> wrote: > > FYI, > > A very interesting development in light of our discussions about doing > route filtering at MICE. > > With this development I enthusiastically support moving forward with route > filtering because it provides an easy answer to Richards question about > which IRR to use, you don't have to use any of them you can do it all in > ARIN ONLINE. > > Thanks. > > ---------- Forwarded message ---------- > From: Job Snijders <job(a)ntt.net> > Date: Tue, Dec 19, 2017 at 4:37 PM > Subject: [routing-wg] a new source for authoritative routing data: ARIN > WHOIS > To: routing-wg(a)ripe.net > > > Dear RIPE WG, > > I'm sharing a copy of what I sent to NANOG. This is specifically of > interest to networks and route server operators that have customers who > also operate in the ARIN region. > > In the RIPE region we've always had the convenience that the "WHOIS" > ('inetnum') and "IRR" ('route/route6') components of the database were > interleaved. Only the IP block's owner can create or authorise others > regarding creation of route-objects. This coupling of WHOIS and IRR > doesn't exist at rr.arin.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=…> > vs whois.arin.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ…> > - so I consider the > following a significant improvement. > > Kind regards, > > Job > > ----- Forwarded message from Job Snijders <job(a)ntt.net> ----- > > Date: Tue, 19 Dec 2017 22:18:20 +0000 > From: Job Snijders <job(a)ntt.net> > To: nanog(a)nanog.org > Subject: a new source for authoritative routing data: ARIN WHOIS > > Dear NANOG, > > I'd like to share an update on some routing security activities that > ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG > Foundation, and the arouteserver project have been collaborating on. > Quite some puzzles pieces were brought together! :) > > Traditionally, there are two commonly-used methods to signal to your > peers or upstream providers what Origin ASN(s) are allowed to originate > a given IP prefix. As an operator, you can either create a "route > object" in the IRR, or you can compose a Letter Of Agency (LOA) and send > that to your upstream providerfor manual verification. > > When it comes to manual verification of routing data (such a LOA), one > of the big questions is "what data source is actually authoritative for > the verification?". In the ARIN registry the so-called "OriginAS" > attribute can be used for this purpose. The OriginAS attribute can only > be set or modified by authorized accounts (such as the holder of the IP > space). This makes the OriginAS attribute a very reliable source of > truth! ARIN shared some notes on LOAs & OriginAS in the following article: > https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-v > alidate-letters-of-authority/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_0…> > > That teamarin posting got me thinking: clearly there is a lot of > valuable routing information in the ARIN WHOIS registry. What if we make > the process such that you don't have to email in a LOA, and, have the > recipient verify it against against the web interface output (which you > updated before sending in the LOA). What if the prefix-filter generation > software could just programmatically fetch all (CIDR, OriginAS) tuples > from the ARIN WHOIS registry and load that into the list of prefixes a > customer is allowed to announce. Just like we do with IRR objects! > > A few weeks ago I approached John Curran from ARIN asking whether we > could work out a mechanism to somehow obtain a computer parsable > rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path > forward turned out to be an agreement between the NLNOG Foundation and > ARIN, which authorises NLNOG to publish a subset of the bulk whois data > in the convenient format (JSON) for operational purposes. The ARIN WHOIS > (CIDR, OriginAS) tuples can be downloaded in JSON format here: > http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> > > Because of the JSON dump, the ARIN WHOIS data can now be easily consumed > by software programs. For example, the JSON file is now loaded into IRR > Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> > You can see the 'arin-whois' column which lists what ASN(s) are > authorized to announce the blocks (this, in addition to what is signaled > in IRR or RPKI). > > The novel thing here is that JSON file not only allows you to look up an > OriginAS using the IP prefix as a lookup key, but the reverse can now > also be done: lookup what IP prefixes an ASN is allowed to originate > (based on ARIN WHOIS data). > > Deployment Experience YYCIX: > > At this point you may be wondering - what does any of the above have to > do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ…> > ) > or a python-based IXP Route Server management software from Italian > origins (http://arouteserver.readthedocs.io/en/latest/ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedoc…>) > ? :-) > > As an experiment to explore real world use of the ARIN WHOIS data and > prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo > de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source > in the prefix filter generation process governing the YYCIX route > servers. The YYCIX route servers see roughly 80,000 prefixes. > > The results are fantastic: ~ 1,700 IPv4 prefixes that were previously > rejected by the YYCIX route servers (because no IRR route object > exists), are now accepted because those announcements can be verified > against data from ARIN's WHOIS registry. This resolved roughly 23% of > invalid path announcements sent to the YYCIX route servers. > > Deployment Experience NTT: > > Based on the above positive results, starting today, NTT is also > accepting ARIN WHOIS OriginAS information in conjunction with IRR route > objects. Our implementation fetches the ARIN WHOIS data, transforms it > into RPSL format, and imports it into our IRRd instance at rr.ntt.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> > as > IRR objects. This way we don't need to update our toolchain to make use > of this new data source. An example is here: > > job@vurt:~$ whois -h rr.ntt.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> > -- "-sARIN-WHOIS 204.209.252.0/23 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> > " > route: 204.209.252.0/23 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> > descr: NET-204-209-252-0-1 > origin: AS22512 > remarks: This route object represents authoritative data retrieved > from ARIN's WHOIS service. > remarks: The original data can be found here: > https://whois.arin.net/rest/net/NET-204-209-252-0-1 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_ne…> > remarks: This route object is the result of an automated > WHOIS-to-IRR conversion process. > mnt-by: MAINT-JOB > changed: job(a)ntt.net 20090220 > source: ARIN-WHOIS > > NTT also observed a substantial number (similar to YYCIX) of BGP > announcements from its customers that were previously rejected because > of the lack of an IRR object, but now are validated via ARIN WHOIS. > > Conclusion: > > It is great to be able to offer network operators a choice: either > register your BGP announcements as route objects in RPSL format in IRR, > or use the ARIN WHOIS web interface, (or both) - either way, as IP > transit carrier, we can now pick up your attestations in an automated > fashion. This which improves accuracy and reduces red tape! :) > > Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source > in their automation toolchain. The code & procedures to make use of this > source are open. I'm happy to help you both on-list and off-list. > > Kind regards, > > Job > > ----- End forwarded message ----- > > > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> > > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 20, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by Andrew Hoyos

Not necessarily. Any sane IRR filtering solution would match against some sort of IRR DB that mirrors ARIN/RIPE/RADB/etc. I think David is getting at more about which IRR to use to register your objects. -- Andrew Hoyos hoyosa(a)gmail.com > On Dec 20, 2017, at 10:38 AM, DeLong, Owen <00000005a669d12e-dmarc-request(a)LISTS.IPHOUSE.NET> wrote: > > This assumes that all prefixes advertised at MICE are issued by ARIN. > > Owen > >> On Dec 19, 2017, at 14:54 , David Farmer <farmer(a)umn.edu> wrote: >> >> FYI, >> >> A very interesting development in light of our discussions about doing route filtering at MICE. >> >> With this development I enthusiastically support moving forward with route filtering because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE. >> >> Thanks. >> >> ---------- Forwarded message ---------- >> From: Job Snijders <job(a)ntt.net> >> Date: Tue, Dec 19, 2017 at 4:37 PM >> Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS >> To: routing-wg(a)ripe.net >> >> >> Dear RIPE WG, >> >> I'm sharing a copy of what I sent to NANOG. This is specifically of >> interest to networks and route server operators that have customers who >> also operate in the ARIN region. >> >> In the RIPE region we've always had the convenience that the "WHOIS" >> ('inetnum') and "IRR" ('route/route6') components of the database were >> interleaved. Only the IP block's owner can create or authorise others >> regarding creation of route-objects. This coupling of WHOIS and IRR >> doesn't exist at rr.arin.net vs whois.arin.net - so I consider the >> following a significant improvement. >> >> Kind regards, >> >> Job >> >> ----- Forwarded message from Job Snijders <job(a)ntt.net> ----- >> >> Date: Tue, 19 Dec 2017 22:18:20 +0000 >> From: Job Snijders <job(a)ntt.net> >> To: nanog(a)nanog.org >> Subject: a new source for authoritative routing data: ARIN WHOIS >> >> Dear NANOG, >> >> I'd like to share an update on some routing security activities that >> ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG >> Foundation, and the arouteserver project have been collaborating on. >> Quite some puzzles pieces were brought together! :) >> >> Traditionally, there are two commonly-used methods to signal to your >> peers or upstream providers what Origin ASN(s) are allowed to originate >> a given IP prefix. As an operator, you can either create a "route >> object" in the IRR, or you can compose a Letter Of Agency (LOA) and send >> that to your upstream providerfor manual verification. >> >> When it comes to manual verification of routing data (such a LOA), one >> of the big questions is "what data source is actually authoritative for >> the verification?". In the ARIN registry the so-called "OriginAS" >> attribute can be used for this purpose. The OriginAS attribute can only >> be set or modified by authorized accounts (such as the holder of the IP >> space). This makes the OriginAS attribute a very reliable source of >> truth! ARIN shared some notes on LOAs & OriginAS in the following article: >> https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters… >> >> That teamarin posting got me thinking: clearly there is a lot of >> valuable routing information in the ARIN WHOIS registry. What if we make >> the process such that you don't have to email in a LOA, and, have the >> recipient verify it against against the web interface output (which you >> updated before sending in the LOA). What if the prefix-filter generation >> software could just programmatically fetch all (CIDR, OriginAS) tuples >> from the ARIN WHOIS registry and load that into the list of prefixes a >> customer is allowed to announce. Just like we do with IRR objects! >> >> A few weeks ago I approached John Curran from ARIN asking whether we >> could work out a mechanism to somehow obtain a computer parsable >> rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path >> forward turned out to be an agreement between the NLNOG Foundation and >> ARIN, which authorises NLNOG to publish a subset of the bulk whois data >> in the convenient format (JSON) for operational purposes. The ARIN WHOIS >> (CIDR, OriginAS) tuples can be downloaded in JSON format here: >> http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 >> >> Because of the JSON dump, the ARIN WHOIS data can now be easily consumed >> by software programs. For example, the JSON file is now loaded into IRR >> Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 >> You can see the 'arin-whois' column which lists what ASN(s) are >> authorized to announce the blocks (this, in addition to what is signaled >> in IRR or RPKI). >> >> The novel thing here is that JSON file not only allows you to look up an >> OriginAS using the IP prefix as a lookup key, but the reverse can now >> also be done: lookup what IP prefixes an ASN is allowed to originate >> (based on ARIN WHOIS data). >> >> Deployment Experience YYCIX: >> >> At this point you may be wondering - what does any of the above have to >> do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) >> or a python-based IXP Route Server management software from Italian >> origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) >> >> As an experiment to explore real world use of the ARIN WHOIS data and >> prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo >> de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source >> in the prefix filter generation process governing the YYCIX route >> servers. The YYCIX route servers see roughly 80,000 prefixes. >> >> The results are fantastic: ~ 1,700 IPv4 prefixes that were previously >> rejected by the YYCIX route servers (because no IRR route object >> exists), are now accepted because those announcements can be verified >> against data from ARIN's WHOIS registry. This resolved roughly 23% of >> invalid path announcements sent to the YYCIX route servers. >> >> Deployment Experience NTT: >> >> Based on the above positive results, starting today, NTT is also >> accepting ARIN WHOIS OriginAS information in conjunction with IRR route >> objects. Our implementation fetches the ARIN WHOIS data, transforms it >> into RPSL format, and imports it into our IRRd instance at rr.ntt.net as >> IRR objects. This way we don't need to update our toolchain to make use >> of this new data source. An example is here: >> >> job@vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" >> route: 204.209.252.0/23 >> descr: NET-204-209-252-0-1 >> origin: AS22512 >> remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. >> remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 >> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. >> mnt-by: MAINT-JOB >> changed: job(a)ntt.net 20090220 >> source: ARIN-WHOIS >> >> NTT also observed a substantial number (similar to YYCIX) of BGP >> announcements from its customers that were previously rejected because >> of the lack of an IRR object, but now are validated via ARIN WHOIS. >> >> Conclusion: >> >> It is great to be able to offer network operators a choice: either >> register your BGP announcements as route objects in RPSL format in IRR, >> or use the ARIN WHOIS web interface, (or both) - either way, as IP >> transit carrier, we can now pick up your attestations in an automated >> fashion. This which improves accuracy and reduces red tape! :) >> >> Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source >> in their automation toolchain. The code & procedures to make use of this >> source are open. I'm happy to help you both on-list and off-list. >> >> Kind regards, >> >> Job >> >> ----- End forwarded message ----- >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 20, 2017

Re: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by DeLong, Owen

This assumes that all prefixes advertised at MICE are issued by ARIN. Owen On Dec 19, 2017, at 14:54 , David Farmer <farmer(a)umn.edu<mailto:farmer@umn.edu>> wrote: FYI, A very interesting development in light of our discussions about doing route filtering at MICE. With this development I enthusiastically support moving forward with route filtering because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE. Thanks. ---------- Forwarded message ---------- From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg(a)ripe.net<mailto:routing-wg@ripe.net> Dear RIPE WG, I'm sharing a copy of what I sent to NANOG. This is specifically of interest to networks and route server operators that have customers who also operate in the ARIN region. In the RIPE region we've always had the convenience that the "WHOIS" ('inetnum') and "IRR" ('route/route6') components of the database were interleaved. Only the IP block's owner can create or authorise others regarding creation of route-objects. This coupling of WHOIS and IRR doesn't exist at rr.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=…> vs whois.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ…> - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> To: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: a new source for authoritative routing data: ARIN WHOIS Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters…<https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_0…> That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_s…> You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ…>) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/<https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedoc…>) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job@vurt:~$ whois -h rr.ntt.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=9…> -- "-sARIN-WHOIS 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…>" route: 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMF…> descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1<https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_ne…> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job(a)ntt.net<mailto:job@ntt.net> 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(612)%20812-9952> =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…>

Dec. 20, 2017

Fwd: [routing-wg] a new source for authoritative routing data: ARIN WHOIS

by David Farmer

FYI, A very interesting development in light of our discussions about doing route filtering at MICE. With this development I enthusiastically support moving forward with route filtering because it provides an easy answer to Richards question about which IRR to use, you don't have to use any of them you can do it all in ARIN ONLINE. Thanks. ---------- Forwarded message ---------- From: Job Snijders <job(a)ntt.net> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg(a)ripe.net Dear RIPE WG, I'm sharing a copy of what I sent to NANOG. This is specifically of interest to networks and route server operators that have customers who also operate in the ARIN region. In the RIPE region we've always had the convenience that the "WHOIS" ('inetnum') and "IRR" ('route/route6') components of the database were interleaved. Only the IP block's owner can create or authorise others regarding creation of route-objects. This coupling of WHOIS and IRR doesn't exist at rr.arin.net vs whois.arin.net - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)ntt.net> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job(a)ntt.net> To: nanog(a)nanog.org Subject: a new source for authoritative routing data: ARIN WHOIS Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-v alidate-letters-of-authority/ That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job@vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" route: 204.209.252.0/23 descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job(a)ntt.net 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> ===============================================

Dec. 19, 2017

Re: Level3/Centurylink Interconnected in Twin Cities

by John McLaughlin

Hello MICE Members: Please join us for this fun event tomorrow night if you can! If you plan to attend please use the link below to register and submit. Corey and I will be there at the theatre handing out movie and concession tickets between 5-6pm. Movie starts at 6pm. Hope to see you there! You're Invited To an Exclusive Showing of Star Wars: The Last Jedi Wednesday, December 20th <https://solutions.arista.com/e1t/c/*W6-QG1v2PfN4_W4WXmF-2HR2WW0/*W8ZXj7v99D…> On Wednesday, December 20th at 6PM, Arista is sponsoring an exclusive showing of Star Wars: The Last Jedi, and you're invited! This showing will be taking place at: Showplace Icon Theater 1625 West End Blvd <https://maps.google.com/?q=1625+West+End+Blvd+St+Louis+Park,+MN+55416&entry…> St Louis Park, MN 55416 <https://maps.google.com/?q=1625+West+End+Blvd+St+Louis+Park,+MN+55416&entry…> Doors open at 5:00PM. We look forward to seeing you there! <https://solutions.arista.com/e1t/c/*W6-QG1v2PfN4_W4WXmF-2HR2WW0/*W8zlyt11Ft…> ARISTA NETWORKS, INC. 5453 GREAT AMERICA PKWY <https://maps.google.com/?q=5453+Great+America+Pkwy%C2%A0%C2%A0Santa+Clara+C…> SANTA CLARA CA 95054 UNITED STATES <https://maps.google.com/?q=5453+Great+America+Pkwy%C2%A0%C2%A0Santa+Clara+C…> John McLaughlin 612-816-9024 Major Accounts Manager jmclaughlin(a)arista.com https://www.businesswire.com/news/home/20171206005205/en/Arista-EOS-Advance… > On Dec 16, 2017, at 1:12 PM, David Farmer <farmer(a)umn.edu> wrote: > > This is not directly related to MICE, but I suspect it will be of interest to many of you, so I figured I would share it anyway; > > Within the last week or two it appears that as part of the Level3/CenturyLink merger they have interconnected their two IP networks here in the Twin Cities. That is AS209(Centurylink) and AS3356(Level3) appear to have interconnected a pair of routers here in the Twin Cities. However, the interconnection doesn't seem appear in the BGP routing tables we are receiving as a customer of Level3. From that perspective the closest interconnection appears to be in Chicago like it has always been. However, based on traceroutes there appears to be more specific routes being exchanged here in the Twin Cities that are not being announced to us as BGP customer of Level3. > > Further, the interconnection doesn't seem to include local Twin Cites BGP customer of Centurylink or any Centurylink outstate Minnesota customers at all, as those destinations seem to route through the Chicago still. So this primarily provides a shortcut from Level3 Twin Cities customers to Centurylink's Twin Cities broadband customers and vice vesra. This has reduced our latency to Twin Cities Centurylink broadband customers; for fiber customers from ~20ms to ~5ms or less, and DSL customers from ~40ms to ~25ms, most of remaining latency being from DSL interleaving. > > So, if you are a BGP customer of Level3 here in the Twin Cites at least, you may want to ensure that you are routing to Centurylink through Level3, to take advantage of this shortcut. > > Thanks. > > -- > =============================================== > David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu> > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>

Dec. 19, 2017

Level3/Centurylink Interconnected in Twin Cities

by David Farmer

This is not directly related to MICE, but I suspect it will be of interest to many of you, so I figured I would share it anyway; Within the last week or two it appears that as part of the Level3/CenturyLink merger they have interconnected their two IP networks here in the Twin Cities. That is AS209(Centurylink) and AS3356(Level3) appear to have interconnected a pair of routers here in the Twin Cities. However, the interconnection doesn't seem appear in the BGP routing tables we are receiving as a customer of Level3. From that perspective the closest interconnection appears to be in Chicago like it has always been. However, based on traceroutes there appears to be more specific routes being exchanged here in the Twin Cities that are not being announced to us as BGP customer of Level3. Further, the interconnection doesn't seem to include local Twin Cites BGP customer of Centurylink or any Centurylink outstate Minnesota customers at all, as those destinations seem to route through the Chicago still. So this primarily provides a shortcut from Level3 Twin Cities customers to Centurylink's Twin Cities broadband customers and vice vesra. This has reduced our latency to Twin Cities Centurylink broadband customers; for fiber customers from ~20ms to ~5ms or less, and DSL customers from ~40ms to ~25ms, most of remaining latency being from DSL interleaving. So, if you are a BGP customer of Level3 here in the Twin Cites at least, you may want to ensure that you are routing to Centurylink through Level3, to take advantage of this shortcut. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 16, 2017

Re: Attribute Length Error today

by DeLong, Owen

I believe we publish IRR records automatically through our IPAM. IIRC, we use the RIPE and RADB IRRs. Owen > On Dec 14, 2017, at 12:18 , Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > At the last UG, we discussed IRR-based filtering. Does Akamai publish IRR records? > > -- > Richard

Dec. 15, 2017

Re: Attribute Length Error today

by Andrew Hoyos

On Dec 14, 2017, at 4:22 PM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > I'm still interested in their opinion, as well as anyone else's, on IRR. I’d fully support IRR based filtering on the route servers. Maintaining an AS-SET and associated route objects is pretty trivial. We’re already doing this today on a number of IX’s (Equinix, SIX, NWAX, etc) -- Andrew Hoyos hoyosa(a)gmail.com

Dec. 14, 2017

Re: Attribute Length Error today

by Richard Laager

On 12/14/2017 02:22 PM, Jeremy Lumby wrote: > Didn't Akamai stop using the route servers? Therefore it wouldn't really > matter. I'm not sure if they use the route servers. I'm still interested in their opinion, as well as anyone else's, on IRR. -- Richard

Dec. 14, 2017

Re: Attribute Length Error today

by Jeremy Lumby

Didn't Akamai stop using the route servers? Therefore it wouldn't really matter. Jeremy LumbyMinnesota VoIP9217 17th Ave SSuite 216Bloomington MN 55425Main 612-355-7740Direct 612-392-6814EFax 952-873-7425jlumby(a)mnvoip.com <div> </div><div> </div><div>-------- Original message --------</div><div>From: Richard Laager <rlaager(a)WIKTEL.COM> </div><div>Date: 12/14/17 2:18 PM (GMT-06:00) </div><div>To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET </div><div>Subject: Re: [MICE-DISCUSS] Attribute Length Error today </div><div> </div>-------- Original message --------From: Richard Laager <rlaager(a)WIKTEL.COM> Date: 12/14/17 2:18 PM (GMT-06:00) To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today At the last UG, we discussed IRR-based filtering. Does Akamai publish IRR records? -- Richard

Dec. 14, 2017

Re: Attribute Length Error today

by Richard Laager

At the last UG, we discussed IRR-based filtering. Does Akamai publish IRR records? -- Richard

Dec. 14, 2017

Re: Attribute Length Error today

by DeLong, Owen

Akamai has no plans to publish ROAs at this time. The reality is that in its current state RPKI is a high overhead method for explaining to the world which origin ASN to prepend in order to more convincingly hijack routes. Owen > On Dec 13, 2017, at 12:46 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > On Fri, Dec 08, 2017 at 11:06:50PM -0600, Richard Laager wrote: >> Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. > > > BIRD is probably the best tool for the job for doing the import BGP filtering for > conditions based on either AS Path = 0 or start with their AS. > It sounds like people want the BGP import function to change to include something like > > function route_import(int asn) > { > .... > if bgp_path.first != asn then return false; > if bgp_path.len > 25 then return false; > if bgp_next_hop != from then return false; > return true; > } > > Are there other conditions that should be filtered on? (this is taken > mostly from Ondřej Surý's examples). > > As for doing RPKI, it looks like BIRD v2.0 supports that in some fashion, but that > would have to be tested out in a lab. How many members would have an ROA already? > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades

Dec. 14, 2017

Re: Attribute Length Error today

by Richard Laager

On 12/13/2017 02:46 PM, Doug McIntyre wrote: > if bgp_path.first != asn then return false; > if bgp_path.len > 25 then return false; > if bgp_next_hop != from then return false; While I am not familiar with BIRD's syntax, if I am reading these correctly, they seem like reasonable conditions. -- Richard

Dec. 13, 2017

Re: Attribute Length Error today

by Jason Hanke

This is the tool we're using at IX Denver: https://arouteserver.readthedocs.io/en/latest/index.html RPKI is currently turned off at IX Denver. Doug,If you're interested then I'll unicast you the output of the script. It's a bit large for the list. On Wed, Dec 13, 2017 at 2:46 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Fri, Dec 08, 2017 at 11:06:50PM -0600, Richard Laager wrote: >> >> Zero length is a subset of “doesn’t start with their AS”, so if we filter >> on that condition, hopefully we will catch that too. > > > > BIRD is probably the best tool for the job for doing the import BGP > filtering for > conditions based on either AS Path = 0 or start with their AS. > It sounds like people want the BGP import function to change to include > something like > > function route_import(int asn) > { > .... > if bgp_path.first != asn then return false; > if bgp_path.len > 25 then return false; > if bgp_next_hop != from then return false; > return true; > } > > Are there other conditions that should be filtered on? (this is taken > mostly from Ondřej Surý's examples). > > As for doing RPKI, it looks like BIRD v2.0 supports that in some fashion, > but that > would have to be tested out in a lab. How many members would have an ROA > already? > > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Dec. 13, 2017

Re: Attribute Length Error today

by Doug McIntyre

On Fri, Dec 08, 2017 at 11:06:50PM -0600, Richard Laager wrote: >Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. BIRD is probably the best tool for the job for doing the import BGP filtering for conditions based on either AS Path = 0 or start with their AS. It sounds like people want the BGP import function to change to include something like function route_import(int asn) { .... if bgp_path.first != asn then return false; if bgp_path.len > 25 then return false; if bgp_next_hop != from then return false; return true; } Are there other conditions that should be filtered on? (this is taken mostly from Ondřej Surý's examples). As for doing RPKI, it looks like BIRD v2.0 supports that in some fashion, but that would have to be tested out in a lab. How many members would have an ROA already? -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 13, 2017

Re: Please Welcome SW MN Broadband to MICE!

by Doug McIntyre

On Wed, Dec 13, 2017 at 11:20:34AM -0600, Jason Hanke wrote: >Name: Southwest MN Broadband >Port: xe-0/0/12 (NP Remote) >ASN: 25715 >IPv4: 206.108.255.40/24 >IPv6: 2001:504:27:0:0:6473::1/64 >Peering Contact: support(a)mysmbs.com > >Route Server: Yes The route servers are all set for them. Welcome! -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 13, 2017

Please Welcome SW MN Broadband to MICE!

by Jason Hanke

Name: Southwest MN Broadband Port: xe-0/0/12 (NP Remote) ASN: 25715 IPv4: 206.108.255.40/24 IPv6: 2001:504:27:0:0:6473::1/64 Peering Contact: support(a)mysmbs.com Route Server: Yes BFD: No Welcome aboard! -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Dec. 13, 2017

Re: Attribute Length Error today

by Frank Bulk

Here’s a tweet to the list that Jay is referring to: https://twitter.com/JobSnijders/status/939280110607327232 Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jason Hanke Sent: Saturday, December 9, 2017 7:01 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today it's time for secure route servers. Job sent out a list of ixp and quite a few of them are already doing rpki or irr filtering. On Dec 8, 2017 11:06 PM, "Richard Laager" <rlaager(a)wiktel.com<mailto:rlaager@wiktel.com>> wrote: Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. -- Richard > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM<mailto:fbulk@MYPREMIERONLINE.COM>> wrote: > > If the issue was that the AS PATH was zero length, can BIRD filter those out? > > Frank > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Doug McIntyre > Sent: Friday, December 8, 2017 6:15 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. > > They do have filters for bogons + default route. > > I suspect bad AS attribute processing is part of what made it get leaked onwards. > The BIRD servers were logging that as well during this period. > >> On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. > > Possibly. > > > -- > Doug McIntyre <merlyn(a)iphouse.net<mailto:merlyn@iphouse.net>> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 12, 2017

Re: Super Bowl Change Freeze

by DeLong, Owen

If you aren’t yet peering with Akamai and would like to before this event starts streaming, please get your peering requests in to us soon. Don’t count on a route-server session to cover this. It is greatly preferable to peer directly with our router. Details are in peeringdb and we encourage you to peer both IPv4 and IPv6. Owen > On Dec 11, 2017, at 16:19 , Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > As you have probably heard, the Super Bowl is being held in Minneapolis > on February 4. We discussed at UG 26 that it would be a good idea to > institute a change freeze for a few days to a week before. > > If you need to upgrade your port capacity or make other changes at MICE, > please plan to have those *complete* by January 26th. > > If it were me, I wouldn't even cut it that close. > > -- > Richard

Dec. 12, 2017

Super Bowl Change Freeze

by Richard Laager

As you have probably heard, the Super Bowl is being held in Minneapolis on February 4. We discussed at UG 26 that it would be a good idea to institute a change freeze for a few days to a week before. If you need to upgrade your port capacity or make other changes at MICE, please plan to have those *complete* by January 26th. If it were me, I wouldn't even cut it that close. -- Richard

Dec. 12, 2017

Re: Passive BFD support on Route-Server #1

by Doug McIntyre

On Mon, Dec 04, 2017 at 03:12:28PM -0600, Doug McIntyre wrote: >Just to close this project out, I'll set a schedule to get this done. > >On Monday, 12/11/2017 at 12:30AM, I'll turn on passive BFD on the MICE route >server #1 (206.108.255.1/ 2001:504:27::d1af:0:1) for all connections. This was completed. No complications as far as I can see. I'll let this config run for a week and schedule up the other route server. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 11, 2017

Re: Attribute Length Error today

by Andrew Hoyos

On Dec 9, 2017, at 7:00 PM, Jason Hanke <jayhanke(a)NEUTRALPATH.NET> wrote: > > it's time for secure route servers. Job sent out a list of ixp and quite a few of them are already doing rpki or irr filtering. I second this. IXPmanager makes this easy. > >> On Dec 8, 2017 11:06 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: >> Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. >> >> -- >> Richard >> >> > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> wrote: >> > >> > If the issue was that the AS PATH was zero length, can BIRD filter those out? >> > >> > Frank >> > >> > -----Original Message----- >> > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre >> > Sent: Friday, December 8, 2017 6:15 PM >> > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >> > Subject: Re: [MICE-DISCUSS] Attribute Length Error today >> > >> >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. >> > >> > They do have filters for bogons + default route. >> > >> > I suspect bad AS attribute processing is part of what made it get leaked onwards. >> > The BIRD servers were logging that as well during this period. >> > >> >> On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. >> > >> > Possibly. >> > >> > >> > -- >> > Doug McIntyre <merlyn(a)iphouse.net> >> > ~.~ ipHouse ~.~ >> > Network Engineer/Provisioning/Jack of all Trades >> > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 10, 2017

Re: Attribute Length Error today

by Jason Hanke

it's time for secure route servers. Job sent out a list of ixp and quite a few of them are already doing rpki or irr filtering. On Dec 8, 2017 11:06 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: > Zero length is a subset of “doesn’t start with their AS”, so if we filter > on that condition, hopefully we will catch that too. > > -- > Richard > > > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> wrote: > > > > If the issue was that the AS PATH was zero length, can BIRD filter those > out? > > > > Frank > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Doug McIntyre > > Sent: Friday, December 8, 2017 6:15 PM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: > >> The more important question - why didn’t the route servers drop that? > I’d assume there should be inbound filters to drop > bogons+default+$otherbadstuff. > > > > They do have filters for bogons + default route. > > > > I suspect bad AS attribute processing is part of what made it get leaked > onwards. > > The BIRD servers were logging that as well during this period. > > > >> On a larger scale, this sort of thing begs the question - do we need to > have folks in some sort of isolated VLAN with test sessions to the route > servers upon turnup? SIX does this, as well as others, I suspect to prevent > these exact issues from happening. > > > > Possibly. > > > > > > -- > > Doug McIntyre <merlyn(a)iphouse.net> > > ~.~ ipHouse ~.~ > > Network Engineer/Provisioning/Jack of all Trades > > >

Dec. 10, 2017

Re: Attribute Length Error today

by Richard Laager

Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. -- Richard > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> wrote: > > If the issue was that the AS PATH was zero length, can BIRD filter those out? > > Frank > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre > Sent: Friday, December 8, 2017 6:15 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. > > They do have filters for bogons + default route. > > I suspect bad AS attribute processing is part of what made it get leaked onwards. > The BIRD servers were logging that as well during this period. > >> On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. > > Possibly. > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades >

Dec. 9, 2017

Re: Attribute Length Error today

by Frank Bulk

If the issue was that the AS PATH was zero length, can BIRD filter those out? Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Friday, December 8, 2017 6:15 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. They do have filters for bogons + default route. I suspect bad AS attribute processing is part of what made it get leaked onwards. The BIRD servers were logging that as well during this period. >On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. Possibly. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 9, 2017

Re: Attribute Length Error today

by Andrew Hoyos

> On Dec 8, 2017, at 6:14 PM, Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. > > They do have filters for bogons + default route. Cool. > I suspect bad AS attribute processing is part of what made it get leaked onwards. > The BIRD servers were logging that as well during this period. Gotcha, while extra work, would it be easy enough to add first hop AS path filters on sessions on the route servers? Or do these already exist as well? Without testing, I’m not sure if that even would have prevented this specific scenario, but it seems like one we should prevent in the future, somehow. -- Andrew Hoyos hoyosa(a)gmail.com

Dec. 9, 2017

Re: Attribute Length Error today

by Doug McIntyre

On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. They do have filters for bogons + default route. I suspect bad AS attribute processing is part of what made it get leaked onwards. The BIRD servers were logging that as well during this period. >On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. Possibly. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 9, 2017

Re: Attribute Length Error today

by Jeremy Lumby

The route servers are dropping it, however I wonder if the error is being generated in the process of dropping it. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, December 08, 2017 6:03 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. And yes, "set-bgp-prepend=0” on the inbound filter on the session is the correct way to handle a similar behavior to ‘no bgp enforce first-as’ in Tik world. This causes the MICE ASN to be removed from the AS Path. -- Andrew Hoyos hoyosa(a)gmail.com > On Dec 8, 2017, at 5:55 PM, Darin Steffl <darin.steffl(a)MNWIFI.COM> wrote: > > It's possible it was sending default earlier and our consultant fixed it when he logged in between 1:27pm and 1:45pm. If someone wants to verify, that'd be great. > > On Fri, Dec 8, 2017 at 5:48 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I do not know much about how Mikrotik works. I agree that the filters do not look like you are sending default, I was just seeing it from Andy's post. > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:39 PM > > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. > > > > I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. > > > > > > > > On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > In looking at it, do you happen to know why you were sending a default route? Has that been corrected? > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:16 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks > > > > My cell is 507-261-7690 > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 9, 2017

Re: Attribute Length Error today

by Andrew Hoyos

The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. And yes, "set-bgp-prepend=0” on the inbound filter on the session is the correct way to handle a similar behavior to ‘no bgp enforce first-as’ in Tik world. This causes the MICE ASN to be removed from the AS Path. -- Andrew Hoyos hoyosa(a)gmail.com > On Dec 8, 2017, at 5:55 PM, Darin Steffl <darin.steffl(a)MNWIFI.COM> wrote: > > It's possible it was sending default earlier and our consultant fixed it when he logged in between 1:27pm and 1:45pm. If someone wants to verify, that'd be great. > > On Fri, Dec 8, 2017 at 5:48 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I do not know much about how Mikrotik works. I agree that the filters do not look like you are sending default, I was just seeing it from Andy's post. > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:39 PM > > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. > > > > I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. > > > > > > > > On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > In looking at it, do you happen to know why you were sending a default route? Has that been corrected? > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:16 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks > > > > My cell is 507-261-7690 > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 9, 2017

Re: Attribute Length Error today

by Darin Steffl

It's possible it was sending default earlier and our consultant fixed it when he logged in between 1:27pm and 1:45pm. If someone wants to verify, that'd be great. On Fri, Dec 8, 2017 at 5:48 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I do not know much about how Mikrotik works. I agree that the filters do > not look like you are sending default, I was just seeing it from Andy's > post. > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Darin Steffl > *Sent:* Friday, December 08, 2017 5:39 PM > > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Attribute Length Error today > > > > Looking at route filters right now and that I attached, I don't see that > I'm advertising a default route unless I'm looking in the wrong spot. I did > not setup any portion of the BGP as I know I'm not an expert or comfortable > setting it up, thus why I hired a consultant to do it for me. They're a big > Mikrotik consultant from Missouri. > > > > I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route > filters right now that I sent. > > > > > > > > On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > In looking at it, do you happen to know why you were sending a default > route? Has that been corrected? > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Darin Steffl > *Sent:* Friday, December 08, 2017 5:16 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and > his response is below. Anyone familiar with Mikrotik that knows the easy > way to do this? We have MICE filters setup but not sure the correct way to > do this without messing anything up further. He had the route filters out > of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he > fixed that, we're now receiving 500+ mbps from MICE and its stable on our > end. But if we're still sending incorrect route announcements, I want to > fix that so I don't cause issues. I found two related forum posts on how to > change this in my router but I have a couple MICE filters as shown in the > attachment. Thanks > > > > My cell is 507-261-7690 <(507)%20261-7690> > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html > I see the following note "Note that your BGP sessions to the route servers > likely need no bgp enforce-first-as or similar. The route servers do not > add the MICE AS to the AS path." A quick search of Mikrotik forums shows > that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE > peer. I'm not sure of this so want clarification to see if we need to make > this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were > advertising your prefixes to them. Their BGP session should not add their > AS, so that should not matter. You should not need to change that, I would > have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF > FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE > 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > <http://www.facebook.com/minnesotawifi> Like us on Facebook > <http://www.facebook.com/minnesotawifi> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > <http://www.facebook.com/minnesotawifi> Like us on Facebook > <http://www.facebook.com/minnesotawifi> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

Dec. 8, 2017

Re: Attribute Length Error today

by Jeremy Lumby

I do not know much about how Mikrotik works. I agree that the filters do not look like you are sending default, I was just seeing it from Andy's post. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl Sent: Friday, December 08, 2017 5:39 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: In looking at it, do you happen to know why you were sending a default route? Has that been corrected? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl Sent: Friday, December 08, 2017 5:16 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today Hey all, I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks My cell is 507-261-7690 My email to consultant: Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. https://forum.mikrotik.com/viewtopic.php?t=55798 https://forum.mikrotik.com/viewtopic.php?t=43498 Consultant response: Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: On 08 December 2017 at 16:15:59, Justin Krejci wrote: > Yup > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 >From this UPDATE dump, this parser helps quite a bit to decode what is going on: http://bgpaste.convergence.cx/ Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's router did the only thing it knows to do on BGP errors - drop the session. Further from the decode: The NEXT_HOP was 206.108.255.89 And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 Looks like Minnesota WiFi should check on their route announcements. HTH, Andy -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 8, 2017