- mice-discuss - lists.micemn.net

Re: UG 27 / MTA
by Reid Fishler Jan. 17, 2018

Jan. 17, 2018

I can't make Wed after the show, I have to run out back to NY. Reid On Jan 17, 2018 1:07 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: 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

1 0

UG 27 / MTA
by Richard Laager Jan. 17, 2018

Jan. 17, 2018

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

1 0

Please Welcome Coloplast to MICE!
by Jason Hanke Jan. 16, 2018

Jan. 16, 2018

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

1 0

MICE route reflect hiccup last night?
by Frank Bulk Jan. 10, 2018

Jan. 10, 2018

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

2 3

Passive BFD support on Route-Server #1
by Doug McIntyre Jan. 1, 2018

Jan. 1, 2018

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. In our testing, we've seen passive listening does pretty much what everybody expects, if you want to talk BFD, it is ready to go for you off the bat, if you don't want to do it, then nothing breaks. This will be the standard moving forward, and has been testing for sometime for 17 participants already (5 active, 12 not actively partipatching). If you don't want even passive BFD enabled for your route-server connection, let me know and I can specificly configure you out of passive participation. But we have had zero problems or comments on the dozen that are in now. If it all goes well, I'll do the same on Route server #2 (206.108.255.2/2001:504:27::d1af:0:2) by the end of the year. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

4 7

Fwd: [routing-wg] a new source for authoritative routing data: ARIN WHOIS
by David Farmer Dec. 30, 2017

Dec. 30, 2017

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> ===============================================

5 8

Super Bowl Street Closures
by David Farmer Dec. 27, 2017

Dec. 27, 2017

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 ===============================================

1 0

Level3/Centurylink Interconnected in Twin Cities
by David Farmer Dec. 19, 2017

Dec. 19, 2017

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 ===============================================

2 1

Attribute Length Error today
by Frank Bulk Dec. 15, 2017

Dec. 15, 2017

Anyone else see this today with both MICE route reflectors? Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:44:36 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:45:23 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Frank

10 23

Re: Attribute Length Error today
by Jeremy Lumby Dec. 14, 2017

Dec. 14, 2017

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

3 2