- mice-discuss - lists.micemn.net

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike Horwath

On Thu, Oct 27, 2016 at 02:07:39PM -0500, Doug McIntyre wrote: > On Thu, Oct 27, 2016 at 08:21:54AM -0500, Mike Horwath wrote: > > > EX4550 is 32 ports base, 48 ports with addon cards. > > It is 32 + 8 ports if you want to use the back expansion slot to house > a VC card instead. The 4550 doesn't have built-in VC (unlike the 4200/4500) > (technically the VC card is slotted into the 4500, but I've never seen one > bought without it there). So the EX4500 can do more ports than a EX4550. Ooh I didn't know that! Thanks! > The QFX5200-32C can get into newer technologies like adding 25G/50G > and 100G capable ports. Again using breakout cables to breakout ports > into the "slower" speeds we are running, and can get into the range of > 128 x 10GB ports with breakout cables in 1U. > > The QFX10002-36Q is much like the above, and can get into 144 x 10G > ports with breakout cables, but I know the price on this switch pushes > now into 6 figures. I have to assume that regardless they are expensive. If only that non-profit thing were in place *today*. A lot of work and I don't envy anyone having to do it. But I, and I don't think I am alone, am not donating money until there is a formal organization wrapped up in pretty bows. I have faith, though. This is coming and there will be much celebration. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 28, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike Horwath

On Tue, Oct 25, 2016 at 01:56:32PM -0500, Richard Laager wrote: > 3) asking for a MICE-TECH and/or MICE-OPS list be created (depending > on whether we have distinct groups and what those people want). I > expect at least one list will be closed to members only. Give the word and it can be done. Hell both could be done though they seem a little redundant in naming. :) -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 28, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Jeremy Lumby

I do believe the result of that discussion is that we will not offer service level agreements, and that whenever a new member agreement was drafted, it would essentially say that we cannot guarantee uptime, or resolution response time, and the solution would be that the member would responsible to disconnect themselves if quality/reliability issues arose that the member found unacceptable. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Mike Horwath Sent: Friday, October 28, 2016 9:40 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT On Tue, Oct 25, 2016 at 09:58:06AM -0500, Colin Baker wrote: > I remember some discussion in a MICE UG meeting a few years back that > some larger networks may have strict requirements that must be met in > order to connect to the exchange. We've added some big content > providers recently, which I'm thrilled to see, but I think establishing > some defined and documented standards can only help continue the growth. Confirm and agree. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 28, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike Horwath

On Tue, Oct 25, 2016 at 10:10:00AM -0500, Jeremy Lumby wrote: > I agree standards would help, however I know that my personal > donations to MICE would probably have been far less if I was forced > to do it on a corporate standard schedule, and lets remember > donations like that got us here, and I would prefer not to lose > donors over standards, and I do not feel membership will be impacted > because of lack of standards since all of our current members have > gotten along quite well all this time without them. These aren't corporate standard schedules. While I am now on the outside of the service provider world, and no longer a direct member of MICE in any capacity (mailing list doens't count), I do feel that we should have something defined and adhered to for the benefit of the group as a whole. We didn't get here all willy nilly, using 1994 ISP style operations. Should there be defined announcement windows for scheduled maintenance? I think most everyone would agree that would be a yes. Should there be notifications of unscheduled outages, maintenance, lunch changes? Yes but this would be looser for timeframes. In the heat of the moment would you rather see work done to further forward the repair or would you like notifications every 15 minutes that things are still broken? Tough stuff.. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 28, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike Horwath

On Tue, Oct 25, 2016 at 09:58:06AM -0500, Colin Baker wrote: > I remember some discussion in a MICE UG meeting a few years back that > some larger networks may have strict requirements that must be met in > order to connect to the exchange. We've added some big content > providers recently, which I'm thrilled to see, but I think establishing > some defined and documented standards can only help continue the growth. Confirm and agree. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 28, 2016

BGP with BFD support

by Doug McIntyre

We had been testing BFD support for BGP in the last few days, and I specificly watched it during the maintenance last night. I currently have route server 1 configured for passive BFD for a couple members, and that has been working just fine as far as I can tell for myself. I'm ready to open it up to any member that wants to test, just let me know your ASN and that you want passive BFD setup, and I can get that going on route-server 1. I'll do IPv4 and IPv6 sessions both. I assume everybody wants more of a gradual test. Otherwise I could enable it on route-server 2 as well. Finally, since this is a passive setting until triggered.. Should this get applied for every member by default? As long as the member side doesn't trigger it, it sits dormant. I could see that being part of the default template rollout for everybody, as well as every member retroactively, so it is totally controlled by what the member wants to do. If they want it, they do it. If they don't care to, it just sits passive not doing it. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by David Farmer

On Thu, Oct 27, 2016 at 2:07 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Thu, Oct 27, 2016 at 08:21:54AM -0500, Mike Horwath wrote: > > On Thu, Oct 27, 2016 at 08:06:45AM -0500, Jason Hanke wrote: > > > There aren't enough ports on the 4550 to swap it in we would need > > > two. We are due for a fabric upgrade. > > Correct, while one could be brought in with additional cards in both, > that would barely cover us with zero future growth without adding > in a 2nd one. The U of MN expressed interest in a 40Gbps connection, > and doing just one switch would knock that out of contention, (or > we keep the EX4500 and run it knowing that it is EOL, and software will > probably stop being available within 14 months). > Don't worry about a 40G for us I'm looking past that now to 100G. I think the priority is to stabilize what we have and add a 100G/50G/40G/25G capability soon next two or three months. 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 ===============================================

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Levi Pederson

Doug, We've just finished some research into 10Gig + 40 to 100Gig Density mapping in Juniper. I'll collect my notes and send them to the list with my thoughts. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Thu, Oct 27, 2016 at 2:07 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Thu, Oct 27, 2016 at 08:21:54AM -0500, Mike Horwath wrote: > > On Thu, Oct 27, 2016 at 08:06:45AM -0500, Jason Hanke wrote: > > > There aren't enough ports on the 4550 to swap it in we would need > > > two. We are due for a fabric upgrade. > > Correct, while one could be brought in with additional cards in both, > that would barely cover us with zero future growth without adding > in a 2nd one. The U of MN expressed interest in a 40Gbps connection, > and doing just one switch would knock that out of contention, (or > we keep the EX4500 and run it knowing that it is EOL, and software will > probably stop being available within 14 months). > > > EX4550 is 32 ports base, 48 ports with addon cards. > > It is 32 + 8 ports if you want to use the back expansion slot to house > a VC card instead. The 4550 doesn't have built-in VC (unlike the 4200/4500) > (technically the VC card is slotted into the 4500, but I've never seen one > bought without it there). So the EX4500 can do more ports than a EX4550. > > So, the back slot on a 4550 could be another 8x10G, but that loses the > VC port, which means we then have to take multiples of 10G ports on > both switches to devote to VC instead, probably at least 4 x 10GB on > both switches, which is a losing of 8 ports either way. > > Effectively making the stacked EX4550 only 40 ports instead of the 48 ports > on the 4500. > > > Is the current EX4500 running with 40 ports or 48? > > It has 48 ports, with 47 ports plugged in. (didn't count how many as lit, > but we just did an inventory and I know how few empty ports we have). > > The EX4550 is the direct replacement for the EX4500. I've run multiple > stacks of them myself, and they are solid boxes. > > Juniper also has newer switches at higher price points (and not as > easy upgrade path). The EX4600 can do 72 x 10GB in 1U. It has 40 fixed > 10G, 4 x 40G. BUT no VC ports. You use the 40G ports for VC > functions. To get the 72 port density, you'd add in a 14 x 40G card, > and any and each 40G port can be broken out to 4 x 10G port with breakout > cables. So, stacking the EX4600's typically takes out the fixed 4x40G > ports with the QSFP+ DAC cabling up and down, but adding on the 14 x 40G > card > brings back many ports and capabilities. > The EX4600 won't VC with the EX4550 so it becomes another stack connected > in. > > The QFX5200-32C can get into newer technologies like adding 25G/50G > and 100G capable ports. Again using breakout cables to breakout ports > into the "slower" speeds we are running, and can get into the range of > 128 x 10GB ports with breakout cables in 1U. > > The QFX10002-36Q is much like the above, and can get into 144 x 10G > ports with breakout cables, but I know the price on this switch pushes > now into 6 figures. > > > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades >

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Doug McIntyre

On Thu, Oct 27, 2016 at 08:21:54AM -0500, Mike Horwath wrote: > On Thu, Oct 27, 2016 at 08:06:45AM -0500, Jason Hanke wrote: > > There aren't enough ports on the 4550 to swap it in we would need > > two. We are due for a fabric upgrade. Correct, while one could be brought in with additional cards in both, that would barely cover us with zero future growth without adding in a 2nd one. The U of MN expressed interest in a 40Gbps connection, and doing just one switch would knock that out of contention, (or we keep the EX4500 and run it knowing that it is EOL, and software will probably stop being available within 14 months). > EX4550 is 32 ports base, 48 ports with addon cards. It is 32 + 8 ports if you want to use the back expansion slot to house a VC card instead. The 4550 doesn't have built-in VC (unlike the 4200/4500) (technically the VC card is slotted into the 4500, but I've never seen one bought without it there). So the EX4500 can do more ports than a EX4550. So, the back slot on a 4550 could be another 8x10G, but that loses the VC port, which means we then have to take multiples of 10G ports on both switches to devote to VC instead, probably at least 4 x 10GB on both switches, which is a losing of 8 ports either way. Effectively making the stacked EX4550 only 40 ports instead of the 48 ports on the 4500. > Is the current EX4500 running with 40 ports or 48? It has 48 ports, with 47 ports plugged in. (didn't count how many as lit, but we just did an inventory and I know how few empty ports we have). The EX4550 is the direct replacement for the EX4500. I've run multiple stacks of them myself, and they are solid boxes. Juniper also has newer switches at higher price points (and not as easy upgrade path). The EX4600 can do 72 x 10GB in 1U. It has 40 fixed 10G, 4 x 40G. BUT no VC ports. You use the 40G ports for VC functions. To get the 72 port density, you'd add in a 14 x 40G card, and any and each 40G port can be broken out to 4 x 10G port with breakout cables. So, stacking the EX4600's typically takes out the fixed 4x40G ports with the QSFP+ DAC cabling up and down, but adding on the 14 x 40G card brings back many ports and capabilities. The EX4600 won't VC with the EX4550 so it becomes another stack connected in. The QFX5200-32C can get into newer technologies like adding 25G/50G and 100G capable ports. Again using breakout cables to breakout ports into the "slower" speeds we are running, and can get into the range of 128 x 10GB ports with breakout cables in 1U. The QFX10002-36Q is much like the above, and can get into 144 x 10G ports with breakout cables, but I know the price on this switch pushes now into 6 figures. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Reid Fishler

Thanks, team! Reid On Oct 27, 2016 2:29 PM, "Doug McIntyre" <merlyn(a)iphouse.net> wrote: > On Thu, Oct 27, 2016 at 07:03:41AM -0500, Mike O'Connor wrote: > > i think we owe you one, Doug > > > > thanks! > > No problem. Anthony was there too checking out things and helping, > so thanks out to him too. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > >

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Levi Pederson

Kudos to Anthony as well. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Thu, Oct 27, 2016 at 1:29 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Thu, Oct 27, 2016 at 07:03:41AM -0500, Mike O'Connor wrote: > > i think we owe you one, Doug > > > > thanks! > > No problem. Anthony was there too checking out things and helping, > so thanks out to him too. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades >

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Doug McIntyre

On Thu, Oct 27, 2016 at 07:03:41AM -0500, Mike O'Connor wrote: > i think we owe you one, Doug > > thanks! No problem. Anthony was there too checking out things and helping, so thanks out to him too. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 27, 2016

Re: Peering with research orgs

by DeLong, Owen

I’m not entirely sure this is true in all cases. Owen On Oct 26, 2016, at 9:28 PM, Reid Fishler <rfishler(a)he.net<mailto:rfishler@he.net>> wrote: Just keep in mind we don't want to give away data that people are going to sell...unless we get something from it. Reid On Thu, Oct 27, 2016 at 12:15 AM, Richard Laager <rlaager(a)wiktel.com<mailto:rlaager@wiktel.com>> wrote: On 10/26/2016 11:07 PM, Frank Bulk wrote: > Does MICE have a policy regarding peering its router reflectors with research/data gathering orgs like Cymru, Dyn, Norse, ThousandEyes, QRator, etc. AFAIK, no policy. Somewhat related: I peer with BGPmon.net<http://bgpmon.net>, which is not on your list. Apparently they have been acquired by OpenDNS since I last looked at their website. I'm not aware of Cymru having a data gathering thing. Do you have a link? I peer with their bogons, UTRS, and IXP services. The IXP one was just added today actually: https://www.team-cymru.org/IXP/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.team-2Dcymru.org_I…> When I turned it up, I saw they were missing the IP ranges used by MICE and several others, so I let them know. -- Richard -- Reid Fishler Director Hurricane Electric +1-510-580-4178 ________________________________ 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…>

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Ryan Goldberg

Having been through exact same scenario with one of our datacenter stacks, I feel yah. Thank you On Oct 27, 2016, at 8:53 AM, Levi Pederson <levipederson(a)MANKATONETWORKS.NET<mailto:levipederson@MANKATONETWORKS.NET>> wrote: Doug, Thanks Doug for all the work and effort. Levi Pederson Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net<mailto:levipederson@mankatonetworks.net> [http://www.mankatonetworks.com/images/mn_logo_email.png] On Thu, Oct 27, 2016 at 8:42 AM, David Farmer <farmer(a)umn.edu<mailto:farmer@umn.edu>> wrote: +1 Thanks for the good work On Thu, Oct 27, 2016 at 7:03 AM, Mike O'Connor <mike(a)haven2.com<mailto:mike@haven2.com>> wrote: i think we owe you one, Doug thanks! m > On Oct 27, 2016, at 2:07 AM, Doug McIntyre <merlyn(a)iphouse.net<mailto:merlyn@iphouse.net>> wrote: > > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: >> On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: >>> We're going to upgrade the core MICE 10G switches coming up this week >>> on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 October. >> >> The upgrade is NOT going as planned, and we discovered our maintenance >> support has run out again, and JTAC will not help us (even at a pay >> per-incidence event). In fact, since the EX4500 has reached EOL, (although >> not EOM), and we let the contract expire, Juniper says we will be unable to >> renew maintenance support on the EX4500 at all. >> >> I'm looking at ways to bring the VC cluster fully back online now. >> >> If it comes down to it, I should have non-production hardware that could >> temporarily go in. > > Okay, I'm going to have to drive in. > > Right now, the state of things. > > The primary boot partition on the EX4500 took a digger, so we have bad > hardware. I was able to boot off the backup boot partition on the > EX4500, but this is still the older software version since I was in > the middle of the upgrade and the upgrade process didn't get to the > 2nd partition to upgrade it yet. > > The virtual chassis is now split version, which means VC won't work. > > Furthmore, networking is not working on either unit, even to the OOB. > > I am going to have to drive in to be physically in front of the box. > > I have two plans of attack. I will put the install image on a USB > drive and load it off USB onto the unit. IIRC, having done this > before long ago, this takes *ages* to do. > > If I can get both units happy with the same software versions, VC can > reestablish, and things can go along. > > I also have two EX4550's not-in-production right now, I'll bring them > along just in case. If things are really to the point of no return on > the EX4500, I can put in one or two and bring them up, restoring the > saved configs onto them. Of course, things will have to shuffle a little > then. This will delay me a bit in unmounting them from where they are, > but I think it is a safe backup plan. > > Another option would be to make the EX4550 standalone, but I have to > unhook the VC cables before this can happen, and it only helps along > a portion of the members. I don't think this is worthwhile to pursue. > > So, it'll be another hour before I can get downtown to my place, get > hardware, and get over to 511. > > -- > Doug McIntyre <merlyn(a)iphouse.net<mailto:merlyn@iphouse.net>> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades WI:(715) 598-4284<tel:%28715%29%20598-4284> MN:(651) 647-6109<tel:%28651%29%20647-6109> Toll Free:(800) 896-0907<tel:%28800%29%20896-0907> Fax:(866)-280-2356<tel:%28866%29-280-2356> -- =============================================== 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-626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel: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

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Levi Pederson

Doug, Thanks Doug for all the work and effort. *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Thu, Oct 27, 2016 at 8:42 AM, David Farmer <farmer(a)umn.edu> wrote: > +1 Thanks for the good work > > On Thu, Oct 27, 2016 at 7:03 AM, Mike O'Connor <mike(a)haven2.com> wrote: > >> i think we owe you one, Doug >> >> thanks! >> >> m >> >> > On Oct 27, 2016, at 2:07 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: >> > >> > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: >> >> On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: >> >>> We're going to upgrade the core MICE 10G switches coming up this week >> >>> on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 >> October. >> >> >> >> The upgrade is NOT going as planned, and we discovered our maintenance >> >> support has run out again, and JTAC will not help us (even at a pay >> >> per-incidence event). In fact, since the EX4500 has reached EOL, >> (although >> >> not EOM), and we let the contract expire, Juniper says we will be >> unable to >> >> renew maintenance support on the EX4500 at all. >> >> >> >> I'm looking at ways to bring the VC cluster fully back online now. >> >> >> >> If it comes down to it, I should have non-production hardware that >> could >> >> temporarily go in. >> > >> > Okay, I'm going to have to drive in. >> > >> > Right now, the state of things. >> > >> > The primary boot partition on the EX4500 took a digger, so we have bad >> > hardware. I was able to boot off the backup boot partition on the >> > EX4500, but this is still the older software version since I was in >> > the middle of the upgrade and the upgrade process didn't get to the >> > 2nd partition to upgrade it yet. >> > >> > The virtual chassis is now split version, which means VC won't work. >> > >> > Furthmore, networking is not working on either unit, even to the OOB. >> > >> > I am going to have to drive in to be physically in front of the box. >> > >> > I have two plans of attack. I will put the install image on a USB >> > drive and load it off USB onto the unit. IIRC, having done this >> > before long ago, this takes *ages* to do. >> > >> > If I can get both units happy with the same software versions, VC can >> > reestablish, and things can go along. >> > >> > I also have two EX4550's not-in-production right now, I'll bring them >> > along just in case. If things are really to the point of no return on >> > the EX4500, I can put in one or two and bring them up, restoring the >> > saved configs onto them. Of course, things will have to shuffle a little >> > then. This will delay me a bit in unmounting them from where they are, >> > but I think it is a safe backup plan. >> > >> > Another option would be to make the EX4550 standalone, but I have to >> > unhook the VC cables before this can happen, and it only helps along >> > a portion of the members. I don't think this is worthwhile to pursue. >> > >> > So, it'll be another hour before I can get downtown to my place, get >> > hardware, and get over to 511. >> > >> > -- >> > Doug McIntyre <merlyn(a)iphouse.net> >> > ~.~ ipHouse ~.~ >> > Network Engineer/Provisioning/Jack of all Trades >> >> WI:(715) 598-4284 MN:(651) 647-6109 Toll Free:(800) 896-0907 Fax: >> (866)-280-2356 >> > > > > -- > =============================================== > 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 >

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by David Farmer

+1 Thanks for the good work On Thu, Oct 27, 2016 at 7:03 AM, Mike O'Connor <mike(a)haven2.com> wrote: > i think we owe you one, Doug > > thanks! > > m > > > On Oct 27, 2016, at 2:07 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > > > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: > >> On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: > >>> We're going to upgrade the core MICE 10G switches coming up this week > >>> on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 > October. > >> > >> The upgrade is NOT going as planned, and we discovered our maintenance > >> support has run out again, and JTAC will not help us (even at a pay > >> per-incidence event). In fact, since the EX4500 has reached EOL, > (although > >> not EOM), and we let the contract expire, Juniper says we will be > unable to > >> renew maintenance support on the EX4500 at all. > >> > >> I'm looking at ways to bring the VC cluster fully back online now. > >> > >> If it comes down to it, I should have non-production hardware that could > >> temporarily go in. > > > > Okay, I'm going to have to drive in. > > > > Right now, the state of things. > > > > The primary boot partition on the EX4500 took a digger, so we have bad > > hardware. I was able to boot off the backup boot partition on the > > EX4500, but this is still the older software version since I was in > > the middle of the upgrade and the upgrade process didn't get to the > > 2nd partition to upgrade it yet. > > > > The virtual chassis is now split version, which means VC won't work. > > > > Furthmore, networking is not working on either unit, even to the OOB. > > > > I am going to have to drive in to be physically in front of the box. > > > > I have two plans of attack. I will put the install image on a USB > > drive and load it off USB onto the unit. IIRC, having done this > > before long ago, this takes *ages* to do. > > > > If I can get both units happy with the same software versions, VC can > > reestablish, and things can go along. > > > > I also have two EX4550's not-in-production right now, I'll bring them > > along just in case. If things are really to the point of no return on > > the EX4500, I can put in one or two and bring them up, restoring the > > saved configs onto them. Of course, things will have to shuffle a little > > then. This will delay me a bit in unmounting them from where they are, > > but I think it is a safe backup plan. > > > > Another option would be to make the EX4550 standalone, but I have to > > unhook the VC cables before this can happen, and it only helps along > > a portion of the members. I don't think this is worthwhile to pursue. > > > > So, it'll be another hour before I can get downtown to my place, get > > hardware, and get over to 511. > > > > -- > > Doug McIntyre <merlyn(a)iphouse.net> > > ~.~ ipHouse ~.~ > > Network Engineer/Provisioning/Jack of all Trades > > WI:(715) 598-4284 MN:(651) 647-6109 Toll Free:(800) 896-0907 Fax: > (866)-280-2356 > -- =============================================== 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 ===============================================

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike Horwath

On Thu, Oct 27, 2016 at 08:06:45AM -0500, Jason Hanke wrote: > There aren't enough ports on the 4550 to swap it in we would need > two. We are due for a fabric upgrade. EX4500 is 40 ports base, 48 ports with addon cards. EX4550 is 32 ports base, 48 ports with addon cards. Is the current EX4500 running with 40 ports or 48? Could a EX4550 be brought into the fabric with addon cards to match up? (not disagreeing about fabric upgrade though will be much easier once non-profit status is done and some of us can donate cleanly) -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike Horwath

On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: > If it comes down to it, I should have non-production hardware that > could temporarily go in. Haven't read the rest of the thread yet. Thanks for your work, Doug. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Jason Hanke

There aren't enough ports on the 4550 to swap it in we would need two. We are due for a fabric upgrade. On Oct 27, 2016 7:23 AM, "Ben Wiechman" <ben.wiechman(a)arvig.com> wrote: > What would be the proposed solution? Replace the failing EX4500 with a > 4550? If so, what does one of those run? > > > Ben Wiechman > Network Engineer IV | Arvig > Direct: 320.256.0184 > Cell: 320.247.3224 > Office: 320.256.7471 > ben.wiechman(a)arvig.com > > On Thu, Oct 27, 2016 at 7:03 AM, Mike O'Connor <mike(a)haven2.com> wrote: > >> i think we owe you one, Doug >> >> thanks! >> >> m >> >> > On Oct 27, 2016, at 2:07 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: >> > >> > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: >> >> On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: >> >>> We're going to upgrade the core MICE 10G switches coming up this week >> >>> on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 >> October. >> >> >> >> The upgrade is NOT going as planned, and we discovered our maintenance >> >> support has run out again, and JTAC will not help us (even at a pay >> >> per-incidence event). In fact, since the EX4500 has reached EOL, >> (although >> >> not EOM), and we let the contract expire, Juniper says we will be >> unable to >> >> renew maintenance support on the EX4500 at all. >> >> >> >> I'm looking at ways to bring the VC cluster fully back online now. >> >> >> >> If it comes down to it, I should have non-production hardware that >> could >> >> temporarily go in. >> > >> > Okay, I'm going to have to drive in. >> > >> > Right now, the state of things. >> > >> > The primary boot partition on the EX4500 took a digger, so we have bad >> > hardware. I was able to boot off the backup boot partition on the >> > EX4500, but this is still the older software version since I was in >> > the middle of the upgrade and the upgrade process didn't get to the >> > 2nd partition to upgrade it yet. >> > >> > The virtual chassis is now split version, which means VC won't work. >> > >> > Furthmore, networking is not working on either unit, even to the OOB. >> > >> > I am going to have to drive in to be physically in front of the box. >> > >> > I have two plans of attack. I will put the install image on a USB >> > drive and load it off USB onto the unit. IIRC, having done this >> > before long ago, this takes *ages* to do. >> > >> > If I can get both units happy with the same software versions, VC can >> > reestablish, and things can go along. >> > >> > I also have two EX4550's not-in-production right now, I'll bring them >> > along just in case. If things are really to the point of no return on >> > the EX4500, I can put in one or two and bring them up, restoring the >> > saved configs onto them. Of course, things will have to shuffle a little >> > then. This will delay me a bit in unmounting them from where they are, >> > but I think it is a safe backup plan. >> > >> > Another option would be to make the EX4550 standalone, but I have to >> > unhook the VC cables before this can happen, and it only helps along >> > a portion of the members. I don't think this is worthwhile to pursue. >> > >> > So, it'll be another hour before I can get downtown to my place, get >> > hardware, and get over to 511. >> > >> > -- >> > Doug McIntyre <merlyn(a)iphouse.net> >> > ~.~ ipHouse ~.~ >> > Network Engineer/Provisioning/Jack of all Trades >> >> WI:(715) 598-4284 MN:(651) 647-6109 Toll Free:(800) 896-0907 Fax: >> (866)-280-2356 >> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Ben Wiechman

What would be the proposed solution? Replace the failing EX4500 with a 4550? If so, what does one of those run? Ben Wiechman Network Engineer IV | Arvig Direct: 320.256.0184 Cell: 320.247.3224 Office: 320.256.7471 ben.wiechman(a)arvig.com On Thu, Oct 27, 2016 at 7:03 AM, Mike O'Connor <mike(a)haven2.com> wrote: > i think we owe you one, Doug > > thanks! > > m > > > On Oct 27, 2016, at 2:07 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > > > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: > >> On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: > >>> We're going to upgrade the core MICE 10G switches coming up this week > >>> on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 > October. > >> > >> The upgrade is NOT going as planned, and we discovered our maintenance > >> support has run out again, and JTAC will not help us (even at a pay > >> per-incidence event). In fact, since the EX4500 has reached EOL, > (although > >> not EOM), and we let the contract expire, Juniper says we will be > unable to > >> renew maintenance support on the EX4500 at all. > >> > >> I'm looking at ways to bring the VC cluster fully back online now. > >> > >> If it comes down to it, I should have non-production hardware that could > >> temporarily go in. > > > > Okay, I'm going to have to drive in. > > > > Right now, the state of things. > > > > The primary boot partition on the EX4500 took a digger, so we have bad > > hardware. I was able to boot off the backup boot partition on the > > EX4500, but this is still the older software version since I was in > > the middle of the upgrade and the upgrade process didn't get to the > > 2nd partition to upgrade it yet. > > > > The virtual chassis is now split version, which means VC won't work. > > > > Furthmore, networking is not working on either unit, even to the OOB. > > > > I am going to have to drive in to be physically in front of the box. > > > > I have two plans of attack. I will put the install image on a USB > > drive and load it off USB onto the unit. IIRC, having done this > > before long ago, this takes *ages* to do. > > > > If I can get both units happy with the same software versions, VC can > > reestablish, and things can go along. > > > > I also have two EX4550's not-in-production right now, I'll bring them > > along just in case. If things are really to the point of no return on > > the EX4500, I can put in one or two and bring them up, restoring the > > saved configs onto them. Of course, things will have to shuffle a little > > then. This will delay me a bit in unmounting them from where they are, > > but I think it is a safe backup plan. > > > > Another option would be to make the EX4550 standalone, but I have to > > unhook the VC cables before this can happen, and it only helps along > > a portion of the members. I don't think this is worthwhile to pursue. > > > > So, it'll be another hour before I can get downtown to my place, get > > hardware, and get over to 511. > > > > -- > > Doug McIntyre <merlyn(a)iphouse.net> > > ~.~ ipHouse ~.~ > > Network Engineer/Provisioning/Jack of all Trades > > WI:(715) 598-4284 MN:(651) 647-6109 Toll Free:(800) 896-0907 Fax: > (866)-280-2356 >

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Mike O'Connor

i think we owe you one, Doug thanks! m > On Oct 27, 2016, at 2:07 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: >> On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: >>> We're going to upgrade the core MICE 10G switches coming up this week >>> on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 October. >> >> The upgrade is NOT going as planned, and we discovered our maintenance >> support has run out again, and JTAC will not help us (even at a pay >> per-incidence event). In fact, since the EX4500 has reached EOL, (although >> not EOM), and we let the contract expire, Juniper says we will be unable to >> renew maintenance support on the EX4500 at all. >> >> I'm looking at ways to bring the VC cluster fully back online now. >> >> If it comes down to it, I should have non-production hardware that could >> temporarily go in. > > Okay, I'm going to have to drive in. > > Right now, the state of things. > > The primary boot partition on the EX4500 took a digger, so we have bad > hardware. I was able to boot off the backup boot partition on the > EX4500, but this is still the older software version since I was in > the middle of the upgrade and the upgrade process didn't get to the > 2nd partition to upgrade it yet. > > The virtual chassis is now split version, which means VC won't work. > > Furthmore, networking is not working on either unit, even to the OOB. > > I am going to have to drive in to be physically in front of the box. > > I have two plans of attack. I will put the install image on a USB > drive and load it off USB onto the unit. IIRC, having done this > before long ago, this takes *ages* to do. > > If I can get both units happy with the same software versions, VC can > reestablish, and things can go along. > > I also have two EX4550's not-in-production right now, I'll bring them > along just in case. If things are really to the point of no return on > the EX4500, I can put in one or two and bring them up, restoring the > saved configs onto them. Of course, things will have to shuffle a little > then. This will delay me a bit in unmounting them from where they are, > but I think it is a safe backup plan. > > Another option would be to make the EX4550 standalone, but I have to > unhook the VC cables before this can happen, and it only helps along > a portion of the members. I don't think this is worthwhile to pursue. > > So, it'll be another hour before I can get downtown to my place, get > hardware, and get over to 511. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades WI:(715) 598-4284 MN:(651) 647-6109 Toll Free:(800) 896-0907 Fax:(866)-280-2356

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Doug McIntyre

On Thu, Oct 27, 2016 at 02:07:46AM -0500, Doug McIntyre wrote: > On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: > > On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: > > > We're going to upgrade the core MICE 10G switches coming up this week > > > on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 October. > > > > The upgrade is NOT going as planned.. The USB recovery did go as planned, so the 4500 is back up, the 4500 and 4550 are VC'd together, and everything is looking good pingwise, trafficwise, so I brought up BGP for everybody again as well. Traffic is picking up across the Exchange. I see lots of routes, especially from HE, so things should be picking up for everybody. Anthony and I have checked out a lot of members traffic levels and they look like they are returning to normal ranges. We're calling it a night. End result, we are up to date on software, everything should be normalled up, and now we have to determine what to do about end of life, semi-broken hardware that is the 4500 box. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Doug McIntyre

On Thu, Oct 27, 2016 at 01:35:06AM -0500, Doug McIntyre wrote: > On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: > > We're going to upgrade the core MICE 10G switches coming up this week > > on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 October. > > The upgrade is NOT going as planned, and we discovered our maintenance > support has run out again, and JTAC will not help us (even at a pay > per-incidence event). In fact, since the EX4500 has reached EOL, (although > not EOM), and we let the contract expire, Juniper says we will be unable to > renew maintenance support on the EX4500 at all. > > I'm looking at ways to bring the VC cluster fully back online now. > > If it comes down to it, I should have non-production hardware that could > temporarily go in. Okay, I'm going to have to drive in. Right now, the state of things. The primary boot partition on the EX4500 took a digger, so we have bad hardware. I was able to boot off the backup boot partition on the EX4500, but this is still the older software version since I was in the middle of the upgrade and the upgrade process didn't get to the 2nd partition to upgrade it yet. The virtual chassis is now split version, which means VC won't work. Furthmore, networking is not working on either unit, even to the OOB. I am going to have to drive in to be physically in front of the box. I have two plans of attack. I will put the install image on a USB drive and load it off USB onto the unit. IIRC, having done this before long ago, this takes *ages* to do. If I can get both units happy with the same software versions, VC can reestablish, and things can go along. I also have two EX4550's not-in-production right now, I'll bring them along just in case. If things are really to the point of no return on the EX4500, I can put in one or two and bring them up, restoring the saved configs onto them. Of course, things will have to shuffle a little then. This will delay me a bit in unmounting them from where they are, but I think it is a safe backup plan. Another option would be to make the EX4550 standalone, but I have to unhook the VC cables before this can happen, and it only helps along a portion of the members. I don't think this is worthwhile to pursue. So, it'll be another hour before I can get downtown to my place, get hardware, and get over to 511. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 27, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Doug McIntyre

On Mon, Oct 24, 2016 at 01:20:45PM -0500, Doug McIntyre wrote: > We're going to upgrade the core MICE 10G switches coming up this week > on Wednesday night/ Thursday morning at 12:30AM-1:00AM CDT on 27 October. The upgrade is NOT going as planned, and we discovered our maintenance support has run out again, and JTAC will not help us (even at a pay per-incidence event). In fact, since the EX4500 has reached EOL, (although not EOM), and we let the contract expire, Juniper says we will be unable to renew maintenance support on the EX4500 at all. I'm looking at ways to bring the VC cluster fully back online now. If it comes down to it, I should have non-production hardware that could temporarily go in. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 27, 2016

Re: Peering with research orgs

by David Farmer

On Wed, Oct 26, 2016 at 11:07 PM, Frank Bulk <fbulk(a)mypremieronline.com> wrote: > Does MICE have a policy regarding peering its router reflectors with > research/data gathering orgs like Cymru, Dyn, Norse, ThousandEyes, QRator, > etc. A number of MICE participants peer with various of these and other services from their own networks, exposing some or all of the routes available through MICE to many of those services, at least indirectly. Do you see a particular advantage to MICE's participants, or the Internet, by making MICE's routes more directly available to such projects? 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 ===============================================

Oct. 27, 2016

Re: Peering with research orgs

by Richard Laager

On 10/27/2016 12:20 AM, David Farmer wrote: > ARIN documents the IXP assignment it makes at the following; > > https://www.arin.net/knowledge/micro_allocations.html Thanks! I've brought that to the attention of Team Cymru too. -- Richard

Oct. 27, 2016

Re: Peering with research orgs

by David Farmer

On Wed, Oct 26, 2016 at 11:15 PM, Richard Laager <rlaager(a)wiktel.com> wrote: > On 10/26/2016 11:07 PM, Frank Bulk wrote: > > Does MICE have a policy regarding peering its router reflectors with > research/data gathering orgs like Cymru, Dyn, Norse, ThousandEyes, QRator, > etc. > > AFAIK, no policy. > > Somewhat related: > > I peer with BGPmon.net, which is not on your list. Apparently they have > been acquired by OpenDNS since I last looked at their website. > > I'm not aware of Cymru having a data gathering thing. Do you have a > link? I peer with their bogons, UTRS, and IXP services. > > The IXP one was just added today actually: > https://www.team-cymru.org/IXP/ > > When I turned it up, I saw they were missing the IP ranges used by MICE > and several others, so I let them know. > FYI, ARIN documents the IXP assignment it makes at the following; https://www.arin.net/knowledge/micro_allocations.html -- =============================================== 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 ===============================================

Oct. 27, 2016

Re: Peering with research orgs

by Reid Fishler

Just keep in mind we don't want to give away data that people are going to sell...unless we get something from it. Reid On Thu, Oct 27, 2016 at 12:15 AM, Richard Laager <rlaager(a)wiktel.com> wrote: > On 10/26/2016 11:07 PM, Frank Bulk wrote: > > Does MICE have a policy regarding peering its router reflectors with > research/data gathering orgs like Cymru, Dyn, Norse, ThousandEyes, QRator, > etc. > > AFAIK, no policy. > > Somewhat related: > > I peer with BGPmon.net, which is not on your list. Apparently they have > been acquired by OpenDNS since I last looked at their website. > > I'm not aware of Cymru having a data gathering thing. Do you have a > link? I peer with their bogons, UTRS, and IXP services. > > The IXP one was just added today actually: > https://www.team-cymru.org/IXP/ > > When I turned it up, I saw they were missing the IP ranges used by MICE > and several others, so I let them know. > > -- > Richard > > -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Oct. 27, 2016

Re: Peering with research orgs

by Richard Laager

On 10/26/2016 11:07 PM, Frank Bulk wrote: > Does MICE have a policy regarding peering its router reflectors with research/data gathering orgs like Cymru, Dyn, Norse, ThousandEyes, QRator, etc. AFAIK, no policy. Somewhat related: I peer with BGPmon.net, which is not on your list. Apparently they have been acquired by OpenDNS since I last looked at their website. I'm not aware of Cymru having a data gathering thing. Do you have a link? I peer with their bogons, UTRS, and IXP services. The IXP one was just added today actually: https://www.team-cymru.org/IXP/ When I turned it up, I saw they were missing the IP ranges used by MICE and several others, so I let them know. -- Richard

Oct. 27, 2016

Peering with research orgs

by Frank Bulk

Does MICE have a policy regarding peering its router reflectors with research/data gathering orgs like Cymru, Dyn, Norse, ThousandEyes, QRator, etc. Frank

Oct. 27, 2016

Re: BFD support on BGP sessions

by Doug McIntyre

On Tue, Oct 25, 2016 at 02:11:20PM -0500, Andrew Hoyos wrote: > Looks as expected here. Thanks for getting this set up on rs1. > Maybe let buck for a few days and we can confirm no issues on either side? Yep, I'll let it run, and check on it and announce it to the list for whoever wants to, and then see if we want to default to everybody. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 25, 2016

Re: MICE Port Runout

by Andrew Hoyos

Also, just a note on this for those thinking in 501(c)3 lines. My understanding of a 501(c)6 is that the donations/contributions from outside parties to MICE are *not* tax deductible for the contributor. https://www.irs.gov/charities-non-profits/other-non-profits/tax-treatment-o… -- Andrew Hoyos hoyosa(a)gmail.com > On Oct 24, 2016, at 9:56 PM, Larry Patterson <larry(a)atomicdata.com> wrote: > > So assuming paperwork happens in a timely fashion, donations after the filing date would be tax deductible for 2016? Is that the agreed upon direction? If so, I would suggest we get some end of year charitable giving going on. I would be interested in participating. What do the lawyers say about 2016 vs. 2017 status? > > Sent from my iPhone > > > > > > > > > > > > > > > > > > > > > > Larry Patterson > Chief Technology Officer > ---- > Atomic Data® // Safe. Simple. Smart.™ > 615 North 3rd Street > Minneapolis, MN 55401 > Main // 612.466.2000 > Direct // 612.466.2080 > > It's official. We're SOC 3 Certified, again! > > > > On Oct 24, 2016, at 21:47, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > > >> On 10/24/2016 08:54 PM, Larry Patterson wrote: > >> Is MICE a non-profit yet or will it be by End of year? > > > > Not yet, and I can't guarantee it. > > > > I'm currently waiting on the Minnesota Secretary of State's office to > > accept a filing. I expected it to be done last week. I'm doing some > > overnight maintenance, so my schedule is off-cycle of normal business > > hours. I've emailed them just now to inquire about the status. > > > > Once that is done, I'll request certified copies, which I expect to take > > a few days. Assuming the rest of the board has no objections, I'll sign > > and file the IRS form. > > > > I'm gone for a couple weeks starting next week. So this may get delayed > > until I'm back. But worst case, this really should be mailed to the IRS > > no later than November 18th. > > > > -- > > Richard > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Levi Pederson

Andrew, We have an IXP Manager (they just simplified their install a great deal) setup running now for just the metrics. Except for bursty MAX bits feeds it's pretty good (Real max of 25, system shows full burst max at 28 still working on why it's less consistent than our cacti). I am going to attempt a roll out of the Route Servers config additions in the next couple of weekends. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Tue, Oct 25, 2016 at 2:05 PM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > The folks on NWAX are using IXPManager (https://github.com/inex/IXP- > Manager), as well as others. AFAIK, this automates lots of this process > (DNS, route-servers, etc) and pulls things from PeeringDB. > Might be worth a look. > > -- > Andrew Hoyos > hoyosa(a)gmail.com > > > > > On Oct 25, 2016, at 2:00 PM, Jason Hanke <jayhanke(a)NEUTRALPATH.NET> > wrote: > > > > There is also a peeringDB API. > > > > It might be time for a database driven documentation. Then we could > > export/import to dns or switch configs. > > > > An online request form might be a good start. > > > > On Tue, Oct 25, 2016 at 1:56 PM, Richard Laager <rlaager(a)wiktel.com> > wrote: > >> The exchange only cares about the max prefix value if it's larger than > >> our default route server limit of 1000. That's a big network, and I > >> think we've only hit that once. I'm not sure we need to bother getting > >> an explicit number from every network on turn-up. > >> > >> On the PeeringDB thing... I've thought about that before too. Is > >> *requiring* an entry going too far? I'm on the fence about that. > >> > >> I see that SIX links the AS number in the participants list to PeeringDB > >> rather than bgp.he.net. I like the bgp.he.net links, but I should see > if > >> I can find some place on the list to put a PeeringDB link. > >> > >> -- > >> Richard > > > > > > > > -- > > 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 >

Oct. 25, 2016

Re: BFD support on BGP sessions

by Andrew Hoyos

On Oct 25, 2016, at 1:15 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > >> Sure, feel free to enable on the v6 sessions facing 53597, and I can >> fire up on this side and see if it works. > > Sure, I've added that to your IPv6 neighbor area. Looks as expected here. Thanks for getting this set up on rs1. hoyosa(a)er1.511.msp> show bfd session | match d1af 2001:504:27::d1af:0:1 Up xe-0/0/0.0 1.500 0.500 3 2001:504:27::d1af:0:2 Down xe-0/0/0.0 0.000 2.000 3 Maybe let buck for a few days and we can confirm no issues on either side? -- Andrew Hoyos hoyosa(a)gmail.com

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Andrew Hoyos

The folks on NWAX are using IXPManager (https://github.com/inex/IXP-Manager) as well as others. AFAIK, this automates lots of this process (DNS, route-servers, etc) and pulls things from PeeringDB. Might be worth a look. -- Andrew Hoyos hoyosa(a)gmail.com > On Oct 25, 2016, at 2:00 PM, Jason Hanke <jayhanke(a)NEUTRALPATH.NET> wrote: > > There is also a peeringDB API. > > It might be time for a database driven documentation. Then we could > export/import to dns or switch configs. > > An online request form might be a good start. > > On Tue, Oct 25, 2016 at 1:56 PM, Richard Laager <rlaager(a)wiktel.com> wrote: >> The exchange only cares about the max prefix value if it's larger than >> our default route server limit of 1000. That's a big network, and I >> think we've only hit that once. I'm not sure we need to bother getting >> an explicit number from every network on turn-up. >> >> On the PeeringDB thing... I've thought about that before too. Is >> *requiring* an entry going too far? I'm on the fence about that. >> >> I see that SIX links the AS number in the participants list to PeeringDB >> rather than bgp.he.net. I like the bgp.he.net links, but I should see if >> I can find some place on the list to put a PeeringDB link. >> >> -- >> Richard > > > > -- > 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

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Jason Hanke

There is also a peeringDB API. It might be time for a database driven documentation. Then we could export/import to dns or switch configs. An online request form might be a good start. On Tue, Oct 25, 2016 at 1:56 PM, Richard Laager <rlaager(a)wiktel.com> wrote: > The exchange only cares about the max prefix value if it's larger than > our default route server limit of 1000. That's a big network, and I > think we've only hit that once. I'm not sure we need to bother getting > an explicit number from every network on turn-up. > > On the PeeringDB thing... I've thought about that before too. Is > *requiring* an entry going too far? I'm on the fence about that. > > I see that SIX links the AS number in the participants list to PeeringDB > rather than bgp.he.net. I like the bgp.he.net links, but I should see if > I can find some place on the list to put a PeeringDB link. > > -- > Richard -- 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

Oct. 25, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Richard Laager

On 10/25/2016 09:40 AM, Andrew Hoyos wrote: > My suggestion would be for the formal creation of a technical committee by the board This is something I intend to work on soon, but the tax-exempt thing is higher priority. I'm envisioning: 1) making a page on the MICE website like the following page: https://www.seattleix.net/whos-who 2) asking the board to ACK its contents 3) asking for a MICE-TECH and/or MICE-OPS list be created (depending on whether we have distinct groups and what those people want). I expect at least one list will be closed to members only. -- Richard

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Richard Laager

The exchange only cares about the max prefix value if it's larger than our default route server limit of 1000. That's a big network, and I think we've only hit that once. I'm not sure we need to bother getting an explicit number from every network on turn-up. On the PeeringDB thing... I've thought about that before too. Is *requiring* an entry going too far? I'm on the fence about that. I see that SIX links the AS number in the participants list to PeeringDB rather than bgp.he.net. I like the bgp.he.net links, but I should see if I can find some place on the list to put a PeeringDB link. -- Richard

Oct. 25, 2016

Re: Please Welcome Unggoy Broadband to MICE!

by Jason Hanke

Assignment sheet updated On Tue, Oct 25, 2016 at 1:37 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Tue, Oct 25, 2016 at 01:28:27PM -0500, Richard Laager wrote: >> On 10/25/2016 01:15 PM, anthonyanderberg(a)nu-telecom.net wrote: >> > Anyway NU-Telecom is in 2/0/7 now >> >> The original (off-list) email about the bad port swap said 2/0/2. (I >> checked.) Given that NU-Telecom is actually in 2/0/7, I've fixed that on >> the website. >> >> Unless we hear differently from Jay, the obvious answer is that Unggoy >> Broadband is now assigned 2/0/2. That's what I put on the website, but >> obviously I can change it if need be. > > > Sounds good to me, I updated the port description since there aren't > optics in xe-2/0/2, and we'll leave xe-2/0/7 to NU-Telecom. > > -- > 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

Oct. 25, 2016

Re: Please Welcome Unggoy Broadband to MICE!

by Doug McIntyre

On Tue, Oct 25, 2016 at 01:28:27PM -0500, Richard Laager wrote: > On 10/25/2016 01:15 PM, anthonyanderberg(a)nu-telecom.net wrote: > > Anyway NU-Telecom is in 2/0/7 now > > The original (off-list) email about the bad port swap said 2/0/2. (I > checked.) Given that NU-Telecom is actually in 2/0/7, I've fixed that on > the website. > > Unless we hear differently from Jay, the obvious answer is that Unggoy > Broadband is now assigned 2/0/2. That's what I put on the website, but > obviously I can change it if need be. Sounds good to me, I updated the port description since there aren't optics in xe-2/0/2, and we'll leave xe-2/0/7 to NU-Telecom. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 25, 2016

Re: Please Welcome Unggoy Broadband to MICE!

by Richard Laager

On 10/25/2016 01:15 PM, anthonyanderberg(a)nu-telecom.net wrote: > Anyway NU-Telecom is in 2/0/7 now The original (off-list) email about the bad port swap said 2/0/2. (I checked.) Given that NU-Telecom is actually in 2/0/7, I've fixed that on the website. Unless we hear differently from Jay, the obvious answer is that Unggoy Broadband is now assigned 2/0/2. That's what I put on the website, but obviously I can change it if need be. -- Richard

Oct. 25, 2016

Re: Please Welcome Unggoy Broadband to MICE!

by anthonyanderberg＠nu-telecom.net

Sorry, that's my fault - after the copper switch work a couple weeks ago the my NU-Telecom port 0/0/15 didn't come back up. After different SFP+ didn't fix the issue we moved NU-Telecom to port 2/0/7 but I hadn't gotten documentation cleaned up yet; shoe maker's kid phenomenon I guess. Anyway NU-Telecom is in 2/0/7 now - we haven't had a chance to test 0/0/15 but were going to do that after the upgrade/reboot. Cheers, anthony -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, October 25, 2016 12:51 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Please Welcome Unggoy Broadband to MICE! On Mon, Oct 24, 2016 at 05:04:56PM -0500, Jason Hanke wrote: > Name: Unggoy Broadband LLC > ASN: 393846 > IPv4: 206.108.255.41/24 > IPv6: 2001:504:27:0:6:0276::1/64 > BFD: Available > Contact: support(a)unggoy.net > Route Servers: Yes > Port: Main Switch xe-2/0/7 Umm, I currently show this port for Nu-Telecom and it has been up for 2w, and Nu-Telecom's assigned port of xe-2/0/2 currently has no optics in that port. Perhaps somebody's 7 turned into a 2 or vice-versa wrongly? -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Doug McIntyre

On Tue, Oct 25, 2016 at 09:20:52AM -0500, Jason Hanke wrote: > Name: Fastly, Inc > ASN: 54113 > IPv4: 206.108.255.72/24 > IPv4: 206.108.255.73/24 > IPv6: 2001:504:27:0:0:d361::1/64 > IPv6: 2001:504:27:0:0:d361::2/64 > Ports: Main Switch xe-2/0/25, xe-2/0/26 (NO LAG) > Contact: peering(a)fastly.com > > Route Server and website please, I'm checking on BFD support. Sure, I've got the route servers, switch description and reverse PTRs all set for both these and the Unggoy Broadband entry (once the port assignment is cleared up). Welcome! -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 25, 2016

Re: Please Welcome Unggoy Broadband to MICE!

by Doug McIntyre

On Mon, Oct 24, 2016 at 05:04:56PM -0500, Jason Hanke wrote: > Name: Unggoy Broadband LLC > ASN: 393846 > IPv4: 206.108.255.41/24 > IPv6: 2001:504:27:0:6:0276::1/64 > BFD: Available > Contact: support(a)unggoy.net > Route Servers: Yes > Port: Main Switch xe-2/0/7 Umm, I currently show this port for Nu-Telecom and it has been up for 2w, and Nu-Telecom's assigned port of xe-2/0/2 currently has no optics in that port. Perhaps somebody's 7 turned into a 2 or vice-versa wrongly? -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Doug McIntyre

On Tue, Oct 25, 2016 at 04:35:59PM +0000, Justin Krejci wrote: > For example, I notice we don't have an official position (at least not a documented official position which arguably means we don't have a position) on PTR records for the member IP addresses. I realize PTRs are not significantly important but they can be useful when troubleshooting and having them I feel gives a little extra polish to the exchange in general. ... Documentation and policy writing sucks loads and loads of time out of people, just as an experience point. It is difficult to get anybody to do that sort of thing in general. I've switched on the PTR updates from batches to doing it more on demand on turn up notices from Jay now. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 25, 2016

Re: Please welcome Fastly to MICE!

by Justin Krejci

Awesome! Welcome Fastly! TL;DR: Things are good and happy. The people doing the work are doing a good job. I have some ideas/comments on ways we could improve. As I was reading this e-mail I did some quick checking on the newly joining organization, as I do with all of the new member joining announcements. It is nice to see another CDN joining in this case. I then like to see how many prefix counts they may be contributing to the exchange so I typically check them out in peeringdb.com. This got me thinking that it may be a good idea to have a requirement that joining networks have and maintain their peeringdb.com record. I am guessing many others find it useful like I do to have an approximate prefix count expected. I know some people like to keep their max-prefix limits set near to the expected prefix count when on the route servers. A joining company's prefix count could also be requested up front, especially if they do intend to peer to the route servers, which then could be included in the new member announcement e-mail. This way people can adjust their max prefix settings accordingly in advance. This is especially useful in the case of a larger prefix count network before they unload onto the exchange, like HE has recently done. (thumbs up on that) >From my perspective, it's been consistent and smooth on the turn ups of new networks on the exchange so I am not criticizing at all but similar to a line of discussion on a different thread, it may not be a bad idea to have a documented template/process for all of the things needed in the turn up of a new network. Plus I like the idea of sharing our collectively learned knowledge in building up the exchange with the general internet for others to potentially benefit from or even possibly for others to offer suggestions to us to help us improve our exchange. For example, I notice we don't have an official position (at least not a documented official position which arguably means we don't have a position) on PTR records for the member IP addresses. I realize PTRs are not significantly important but they can be useful when troubleshooting and having them I feel gives a little extra polish to the exchange in general. To reiterate/elaborate, I think that Jay, Doug, Richard, Anthony, etc. have been doing an excellent job with getting new organizations up and running and getting the requisite website/cacti components updated to reflect the changes. ________________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Jason Hanke [jayhanke(a)NEUTRALPATH.NET] Sent: Tuesday, October 25, 2016 9:20 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Please welcome Fastly to MICE! Name: Fastly, Inc ASN: 54113 IPv4: 206.108.255.72/24 IPv4: 206.108.255.73/24 IPv6: 2001:504:27:0:0:d361::1/64 IPv6: 2001:504:27:0:0:d361::2/64 Ports: Main Switch xe-2/0/25, xe-2/0/26 (NO LAG) Contact: peering(a)fastly.com Route Server and website please, I'm checking on BFD support. 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

Oct. 25, 2016

Re: Donation Thank You

by Richard Laager

On 10/25/2016 09:24 AM, Jason Hanke wrote: > Please thank Hoyos Consulting for a $2100 Paypal donation this morning! Thanks! I updated the website donations page. -- Richard

Oct. 25, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Jeremy Lumby

I agree standards would help, however I know that my personal donations to MICE would probably have been far less if I was forced to do it on a corporate standard schedule, and lets remember donations like that got us here, and I would prefer not to lose donors over standards, and I do not feel membership will be impacted because of lack of standards since all of our current members have gotten along quite well all this time without them. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Colin Baker Sent: Tuesday, October 25, 2016 9:58 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT On 25.10.2016 09:40, Andrew Hoyos wrote: > > Lack of a surplus of cash or charging fees seems to have little if > nothing to do with having some operational norms and > processes/timelines that we could all agree to follow. > > I’m not discounting Doug’s willingness to do the upgrade at all, it’s > the process by which it’s happened, and I think we can do better as a > group to bring some sane operational due process and some standards we > can all agree to follow as a community when it comes to things like > this (upgrades, changes, etc) to minimize impact to the IX and it’s > members. > > If folks feel differently as a group, I’ll bite my tongue and turn the > other way — but we’re big enough now where folks are paying attention > to this sort of thing. > > My suggestion would be for the formal creation of a technical > committee by the board, which can work on and implement these > operational details in a way that works for everyone. > I remember some discussion in a MICE UG meeting a few years back that some larger networks may have strict requirements that must be met in order to connect to the exchange. We've added some big content providers recently, which I'm thrilled to see, but I think establishing some defined and documented standards can only help continue the growth. -- Colin Baker SupraNet Communications, Inc. (608) 572-7634 colinb(a)supranet.net This message is subject to the SupraNet Email Confidentiality Policy which is located at http://supranet.net/confidentiality

Oct. 25, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Colin Baker

On 25.10.2016 09:40, Andrew Hoyos wrote: > > Lack of a surplus of cash or charging fees seems to have little if > nothing to do with having some operational norms and > processes/timelines that we could all agree to follow. > > I’m not discounting Doug’s willingness to do the upgrade at all, it’s > the process by which it’s happened, and I think we can do better as a > group to bring some sane operational due process and some standards we > can all agree to follow as a community when it comes to things like > this (upgrades, changes, etc) to minimize impact to the IX and it’s > members. > > If folks feel differently as a group, I’ll bite my tongue and turn the > other way — but we’re big enough now where folks are paying attention > to this sort of thing. > > My suggestion would be for the formal creation of a technical > committee by the board, which can work on and implement these > operational details in a way that works for everyone. > I remember some discussion in a MICE UG meeting a few years back that some larger networks may have strict requirements that must be met in order to connect to the exchange. We've added some big content providers recently, which I'm thrilled to see, but I think establishing some defined and documented standards can only help continue the growth. -- Colin Baker SupraNet Communications, Inc. (608) 572-7634 colinb(a)supranet.net This message is subject to the SupraNet Email Confidentiality Policy which is located at http://supranet.net/confidentiality

Oct. 25, 2016

Re: MICE core switch maintenance window - 10/27/2016 12:30AM-1:00AM CDT

by Andrew Hoyos

> On Oct 25, 2016, at 7:34 AM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > If MICE had been built on a surplus of cash, and not donated time/hardware, then I would feel much different. Lack of a surplus of cash or charging fees seems to have little if nothing to do with having some operational norms and processes/timelines that we could all agree to follow. I’m not discounting Doug’s willingness to do the upgrade at all, it’s the process by which it’s happened, and I think we can do better as a group to bring some sane operational due process and some standards we can all agree to follow as a community when it comes to things like this (upgrades, changes, etc) to minimize impact to the IX and it’s members. If folks feel differently as a group, I’ll bite my tongue and turn the other way — but we’re big enough now where folks are paying attention to this sort of thing. My suggestion would be for the formal creation of a technical committee by the board, which can work on and implement these operational details in a way that works for everyone. -- Andrew Hoyos hoyosa(a)gmail.com

Oct. 25, 2016