- mice-discuss - lists.micemn.net

Code42

by Jason Hanke

Is there someone from Code42 that could reach out to me off list? MICE needs help with a potential peer. -- 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. 5, 2017

Re: Please welcome Christensen Communications to MICE!

by Doug McIntyre

On Thu, Jan 05, 2017 at 10:57:26AM -0600, Jason Hanke wrote: > Name: Christensen Communications > ASN: 46494 > IPv4: 206.108.255.74/24 > IPv6: 2001:504:27:0:0:b593::1/64 > Port: Neutral Path Remote ge-0/0/5 > Contact: shannons(a)chriscomco.net > BFD: NO > Route Server: YES I've got the route servers setup and ready to go for them. Welcome! -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Jan. 5, 2017

Port Fees

by Richard Laager

The board has approved port fees in line with the discussion from the most recent UG meeting. The details are documented on the services page on the website: http://micemn.net/services.html If you have one or more ports on the *main* switches, please send accounts payable information to Kayla Powers, our treasurer, at: kpowers(a)neutralpath.net -- Richard

Jan. 5, 2017

Please welcome Christensen Communications to MICE!

by Jason Hanke

Name: Christensen Communications ASN: 46494 IPv4: 206.108.255.74/24 IPv6: 2001:504:27:0:0:b593::1/64 Port: Neutral Path Remote ge-0/0/5 Contact: shannons(a)chriscomco.net BFD: NO Route Server: YES 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

Jan. 5, 2017

Re: Amazon on MICE

by Frank Bulk

Graph shows they dropped to zero overnight: [cid:image001.png@01D26734.735227D0] Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Michael Hare Sent: Wednesday, January 04, 2017 12:28 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Amazon on MICE AS3128 is actively peering with Amazon at MICE and we do not get v4 or v6 icmp responses. -Michael From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Wednesday, January 04, 2017 12:06 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Amazon on MICE Yep, that's the address that we are peering with, and it responds to pings from me. Maybe the have an ACL only allowing their peers through. On Wed, Jan 4, 2017 at 11:46 AM, Richard Laager <rlaager(a)wiktel.com<mailto:rlaager@wiktel.com>> wrote: Can either of you confirm that they are on 206.108.255.111? It does not respond to pings for me, though their IPv6 address does. -- Richard -- =============================================== 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 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Jan. 5, 2017

Amazon Peering

by Jason Hanke

Amazon confirmed that they are up and ready for additional peers on MICE. peering(a)amazon.com -- 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. 4, 2017

Re: Amazon on MICE

by Michael Hare

AS3128 is actively peering with Amazon at MICE and we do not get v4 or v6 icmp responses. -Michael From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Wednesday, January 04, 2017 12:06 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Amazon on MICE Yep, that's the address that we are peering with, and it responds to pings from me. Maybe the have an ACL only allowing their peers through. On Wed, Jan 4, 2017 at 11:46 AM, Richard Laager <rlaager(a)wiktel.com<mailto:rlaager@wiktel.com>> wrote: Can either of you confirm that they are on 206.108.255.111? It does not respond to pings for me, though their IPv6 address does. -- Richard -- =============================================== 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

Jan. 4, 2017

Re: Amazon on MICE

by David Farmer

Yep, that's the address that we are peering with, and it responds to pings from me. Maybe the have an ACL only allowing their peers through. On Wed, Jan 4, 2017 at 11:46 AM, Richard Laager <rlaager(a)wiktel.com> wrote: > Can either of you confirm that they are on 206.108.255.111? It does not > respond to pings for me, though their IPv6 address does. > > -- > Richard > -- =============================================== 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. 4, 2017

Re: Amazon on MICE

by Richard Laager

Can either of you confirm that they are on 206.108.255.111? It does not respond to pings for me, though their IPv6 address does. -- Richard

Jan. 4, 2017

Re: Amazon on MICE

by David Farmer

Yep we see them too. I see 9 IPv4 routes and 2 IPv6 routes from the peering at MICE, where as I see 1600+ IPv4 routes and 450+ IPv6 routes globally from Amazon. I believe they are only making their Edge Services available here, that is primarily Amazon CloudFront (CDN) and maybe Amazon Route53 (DNS), AWS Shield (DDOS Protection), and AWS WAF (Web Application Firewall) as well. But I'm less certain on the last three services. https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-cloudfront-adds-n… https://aws.amazon.com/about-aws/global-infrastructure/regional-product-ser… On Tue, Jan 3, 2017 at 9:43 PM, Frank Bulk <fbulk(a)mypremieronline.com> wrote: > Our BGP sessions with Amazon came alive around 4 pm today, and the graphs > confirm the same: > > http://micelg.usinternet.com/cacti/graph.php?action=view& > local_graph_id=497&rra_id=all > > > > Frank > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Justin Krejci > *Sent:* Wednesday, December 21, 2016 12:56 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* [MICE-DISCUSS] Amazon on MICE > > > > From one of their peering engineers, Amazon estimates early January to be > live on MICE. > > -- =============================================== 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. 4, 2017

Re: Amazon on MICE

by Frank Bulk

Our BGP sessions with Amazon came alive around 4 pm today, and the graphs confirm the same: http://micelg.usinternet.com/cacti/graph.php?action=view&local_graph_id=497… Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Justin Krejci Sent: Wednesday, December 21, 2016 12:56 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Amazon on MICE >From one of their peering engineers, Amazon estimates early January to be live on MICE. ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Jan. 4, 2017

Re: Route server #2 copper connection

by Mike Horwath

As an aside: you didn't give the 3 month notification of emergency remediation. #happyholidays from the troll! -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Dec. 22, 2016

Re: Route server #2 copper connection

by Mike Horwath

On Thu, Dec 22, 2016 at 03:53:00PM -0600, Jeremy Lumby wrote: > When I went to insert my optic into the switch for my upgraded 10G > connection, I noticed that the cable for route server#2 was against > the cabinet door, and simply opening/closing the door caused the > link to bounce. Since the link had gone down from just opening the > door, I switched the Copper SFP adapter to a different model, and it > appears to be more compatible with the RJ45 connector on the patch > cable since the link now stays up when the cable is moved in a > normal manner. THANKS! -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Dec. 22, 2016

Route server #2 copper connection

by Jeremy Lumby

When I went to insert my optic into the switch for my upgraded 10G connection, I noticed that the cable for route server#2 was against the cabinet door, and simply opening/closing the door caused the link to bounce. Since the link had gone down from just opening the door, I switched the Copper SFP adapter to a different model, and it appears to be more compatible with the RJ45 connector on the patch cable since the link now stays up when the cable is moved in a normal manner. Jeremy

Dec. 22, 2016

Re: RR#2 cable?

by Frank Bulk

Looks like our BGP session with MRS2 bounced around 3:47 pm. Can someone who has access confirm that the copper link bounced, too? Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Nevin Lyne Sent: Monday, December 19, 2016 11:34 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] RR#2 cable? I think I have a pair of fiber NICs and optics I can donate for the two systems. I will touch bases with you next time I am in the IPHouse data center, Doug. -Nevin On Monday, December 19, 2016 11:23pm, "Doug McIntyre" <merlyn(a)IPHOUSE.NET> said: > On Mon, Dec 19, 2016 at 10:34:28PM -0600, Matthew Beckwell wrote: >> I reseated the SFP/cable. Appears to be back up and passing traffic. >> Although it didn't seem particularly loose to me. > > Thanks! > > I've seen in the past just certain Cat5e cables and certain manufactorer > machines just didn't play too well together. Swap out one for the other > and it works fine. Probably the race to the bottom/cheapest in commodity > parts gives some pretty loose tolerances sometimes. > > I think Jeremy has some spares, although I don't know what. We could > probably also do a fiber NIC in the RR's at some point as well if we > didn't want to get a copper SFP involved. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Dec. 22, 2016

Amazon on MICE

by Justin Krejci

>From one of their peering engineers, Amazon estimates early January to be live on MICE.

Dec. 21, 2016

Re: RR#2 cable?

by Nevin Lyne

I think I have a pair of fiber NICs and optics I can donate for the two systems. I will touch bases with you next time I am in the IPHouse data center, Doug. -Nevin On Monday, December 19, 2016 11:23pm, "Doug McIntyre" <merlyn(a)IPHOUSE.NET> said: > On Mon, Dec 19, 2016 at 10:34:28PM -0600, Matthew Beckwell wrote: >> I reseated the SFP/cable. Appears to be back up and passing traffic. >> Although it didn't seem particularly loose to me. > > Thanks! > > I've seen in the past just certain Cat5e cables and certain manufactorer > machines just didn't play too well together. Swap out one for the other > and it works fine. Probably the race to the bottom/cheapest in commodity > parts gives some pretty loose tolerances sometimes. > > I think Jeremy has some spares, although I don't know what. We could > probably also do a fiber NIC in the RR's at some point as well if we > didn't want to get a copper SFP involved. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Dec. 20, 2016

Re: RR#2 cable?

by Doug McIntyre

On Mon, Dec 19, 2016 at 10:34:28PM -0600, Matthew Beckwell wrote: > I reseated the SFP/cable. Appears to be back up and passing traffic. > Although it didn't seem particularly loose to me. Thanks! I've seen in the past just certain Cat5e cables and certain manufactorer machines just didn't play too well together. Swap out one for the other and it works fine. Probably the race to the bottom/cheapest in commodity parts gives some pretty loose tolerances sometimes. I think Jeremy has some spares, although I don't know what. We could probably also do a fiber NIC in the RR's at some point as well if we didn't want to get a copper SFP involved. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 20, 2016

Re: RR#2 cable?

by Dean Bahls

Seems that someone beat us to the punch. We didn't get down there as early as hoped. Sorry about that. Dean -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Monday, December 19, 2016 5:56 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] RR#2 cable? Sure, in the MICE cabinet (which I'm not sure of the number, it is in the row parallel against the back wall in Suite 100 farthest way from the entry door, in the top of a 1/3rd cabinet with MICE name on a label..) On the EX4550 switch (there's only one EX4550 switch, it is the 1U fiber switch), in port ge-2/0/0 (ie. the first port), is a copper SFP (again, the only one there is). All that needs to happen is to push that copper cross-connect in, the spring action has probably pushed it just a little too far out for good contact. That is what it was last time. And I think in general we should probably move that copper connection back to the copper switches, but for now, just pushing it in would be good to go. On Mon, Dec 19, 2016 at 05:42:33PM -0600, Dean Bahls wrote: > We have someone going down there in about an hour or two. He's never > been in that cabinet so if you have VERY EXPLICIT instructions, we can > have him do it. > > Lemme know. > > Dean > > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf > Of Doug McIntyre > Sent: Monday, December 19, 2016 5:37 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] RR#2 cable? > > Anybody close to 511 today? > > Looks like the cable has snaked its way out again for RR#2. > > Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN > > The machine is up and talking back on the mgmt link. It is link down > on both the switch and the machine for the link into the switch stack. > > I'm sure if somebody goes and pushes on the cable again it'll be link up. > > Looks like that cable and that copper-SFP aren't too compatico. > It might be better to not have switch diversity for them. > > -- > 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

Dec. 20, 2016

Re: RR#2 cable?

by Matthew Beckwell

I reseated the SFP/cable. Appears to be back up and passing traffic. Although it didn't seem particularly loose to me. ~Matthew On Mon, Dec 19, 2016 at 5:37 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > Anybody close to 511 today? > > Looks like the cable has snaked its way out again for RR#2. > > Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN > > The machine is up and talking back on the mgmt link. It is link down > on both the switch and the machine for the link into the switch stack. > > I'm sure if somebody goes and pushes on the cable again it'll be link up. > > Looks like that cable and that copper-SFP aren't too compatico. > It might be better to not have switch diversity for them. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades >

Dec. 20, 2016

Re: RR#2 cable?

by Frank Bulk

Just saw it come back up -- thanks. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Monday, December 19, 2016 5:37 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] RR#2 cable? Anybody close to 511 today? Looks like the cable has snaked its way out again for RR#2. Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN The machine is up and talking back on the mgmt link. It is link down on both the switch and the machine for the link into the switch stack. I'm sure if somebody goes and pushes on the cable again it'll be link up. Looks like that cable and that copper-SFP aren't too compatico. It might be better to not have switch diversity for them. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 20, 2016

Re: RR#2 cable?

by Justin Krejci

Assuming it is the same problem as before, does it just need a new SFP or a new RJ45 end on the cable? US Internet would be happy to donate either as needed. ________________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Doug McIntyre [merlyn(a)IPHOUSE.NET] Sent: Monday, December 19, 2016 5:55 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] RR#2 cable? Sure, in the MICE cabinet (which I'm not sure of the number, it is in the row parallel against the back wall in Suite 100 farthest way from the entry door, in the top of a 1/3rd cabinet with MICE name on a label..) On the EX4550 switch (there's only one EX4550 switch, it is the 1U fiber switch), in port ge-2/0/0 (ie. the first port), is a copper SFP (again, the only one there is). All that needs to happen is to push that copper cross-connect in, the spring action has probably pushed it just a little too far out for good contact. That is what it was last time. And I think in general we should probably move that copper connection back to the copper switches, but for now, just pushing it in would be good to go. On Mon, Dec 19, 2016 at 05:42:33PM -0600, Dean Bahls wrote: > We have someone going down there in about an hour or two. He's never been > in that cabinet so if you have VERY EXPLICIT instructions, we can have him > do it. > > Lemme know. > > Dean > > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug > McIntyre > Sent: Monday, December 19, 2016 5:37 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] RR#2 cable? > > Anybody close to 511 today? > > Looks like the cable has snaked its way out again for RR#2. > > Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN > > The machine is up and talking back on the mgmt link. It is link down on both > the switch and the machine for the link into the switch stack. > > I'm sure if somebody goes and pushes on the cable again it'll be link up. > > Looks like that cable and that copper-SFP aren't too compatico. > It might be better to not have switch diversity for them. > > -- > 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

Dec. 19, 2016

Re: RR#2 cable?

by Doug McIntyre

Sure, in the MICE cabinet (which I'm not sure of the number, it is in the row parallel against the back wall in Suite 100 farthest way from the entry door, in the top of a 1/3rd cabinet with MICE name on a label..) On the EX4550 switch (there's only one EX4550 switch, it is the 1U fiber switch), in port ge-2/0/0 (ie. the first port), is a copper SFP (again, the only one there is). All that needs to happen is to push that copper cross-connect in, the spring action has probably pushed it just a little too far out for good contact. That is what it was last time. And I think in general we should probably move that copper connection back to the copper switches, but for now, just pushing it in would be good to go. On Mon, Dec 19, 2016 at 05:42:33PM -0600, Dean Bahls wrote: > We have someone going down there in about an hour or two. He's never been > in that cabinet so if you have VERY EXPLICIT instructions, we can have him > do it. > > Lemme know. > > Dean > > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug > McIntyre > Sent: Monday, December 19, 2016 5:37 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] RR#2 cable? > > Anybody close to 511 today? > > Looks like the cable has snaked its way out again for RR#2. > > Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN > > The machine is up and talking back on the mgmt link. It is link down on both > the switch and the machine for the link into the switch stack. > > I'm sure if somebody goes and pushes on the cable again it'll be link up. > > Looks like that cable and that copper-SFP aren't too compatico. > It might be better to not have switch diversity for them. > > -- > 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

Dec. 19, 2016

Re: RR#2 cable?

by Dean Bahls

We have someone going down there in about an hour or two. He's never been in that cabinet so if you have VERY EXPLICIT instructions, we can have him do it. Lemme know. Dean -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Monday, December 19, 2016 5:37 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] RR#2 cable? Anybody close to 511 today? Looks like the cable has snaked its way out again for RR#2. Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN The machine is up and talking back on the mgmt link. It is link down on both the switch and the machine for the link into the switch stack. I'm sure if somebody goes and pushes on the cable again it'll be link up. Looks like that cable and that copper-SFP aren't too compatico. It might be better to not have switch diversity for them. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 19, 2016

RR#2 cable?

by Doug McIntyre

Anybody close to 511 today? Looks like the cable has snaked its way out again for RR#2. Dec 19 17:04:19 micemn-02 kernel: bge1: link state changed to DOWN The machine is up and talking back on the mgmt link. It is link down on both the switch and the machine for the link into the switch stack. I'm sure if somebody goes and pushes on the cable again it'll be link up. Looks like that cable and that copper-SFP aren't too compatico. It might be better to not have switch diversity for them. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 19, 2016

UG 22 Minutes

by Richard Laager

Draft minutes available here: http://micemn.net/files/MICE%20UG%2022%20-%20Minutes.pdf If you have any corrections, please let me know. -- Richard

Dec. 19, 2016

Re: MICE UG Reminder

by Richard Laager

On 12/12/2016 10:51 AM, Jason Hanke wrote: > The MICE Users Group is Wednesday. > > There is a proposal for new port fees on the docket. > > Please RSVP here: > > https://www.facebook.com/events/179450035795693/ I have attached the agenda for UG 22 and the minutes from UG 21. Remote Conferencing: 952-562-5400 passcode MICE (6423) -- Richard

Dec. 12, 2016

Re: MICE UG Reminder

by Jeremy Lumby

I do not have a Facebook account to RSVP, and clicking on the link asks me to sign in, however count me as being there. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jason Hanke Sent: Monday, December 12, 2016 10:51 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MICE UG Reminder The MICE Users Group is Wednesday. There is a proposal for new port fees on the docket. Please RSVP here: https://www.facebook.com/events/179450035795693/ -- 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 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, 2016

MICE UG Reminder

by Jason Hanke

The MICE Users Group is Wednesday. There is a proposal for new port fees on the docket. Please RSVP here: https://www.facebook.com/events/179450035795693/ -- 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. 12, 2016

Re: MN VoIP Remote Switch

by Doug McIntyre

On Fri, Dec 09, 2016 at 10:07:03AM -0600, Jason Hanke wrote: > Please allocate xe-2/0/7 to the MN VoIP remote switch. Per the new policy > for remote switches, please provision the initial port as a single member > LAG. Sure, all set, allocated LAG group ae15 for this, and have xe-2/0/7 made to be the single member of this LAG. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 9, 2016

MN VoIP Remote Switch

by Jason Hanke

Please allocate xe-2/0/7 to the MN VoIP remote switch. Per the new policy for remote switches, please provision the initial port as a single member LAG. 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. 9, 2016

Re: Participants leaking BGP routes for the MICE IXP Block

by DeLong, Owen

Couldn't we automate private notification followed by public if not resolved within 24 hours? Wouldn't that be the best of both worlds? Owen On Dec 1, 2016, at 23:11, David Farmer <farmer(a)UMN.EDU<mailto:farmer@UMN.EDU>> wrote: I didn't think of that variant, but that's why we discuss these kind of things. I'm willing to give that a try. Heck, I might even give people two or three strikes, especially if the actually respond to my email rather than ignore me. :) However, I thought of one advantage of #4 after sending the email. In the case on non-nuisance incidents, like an actual hijack event, everyone is notified immediately. Otherwise, it has to wait for me to forward the email in the case of an actual event. BGPmon pages me, because the University has the paid service, but I'm only human and therefore fallible. Any other comments? On Thu, Dec 1, 2016 at 8:02 PM, Russell Berg <berg(a)wins.net<mailto:berg@wins.net>> wrote: I agree... first strike private, second strike public. Automatic if you don't want to be the transgressor tracker. Russ -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Richard Laager Sent: Thursday, December 01, 2016 8:00 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE IXP Block On 12/01/2016 06:56 PM, David Farmer wrote: > 2. Notify transgressors PRIVATELY > 3. Manually, Name and Shame transgressors 4. Automated, Name and Shame > of transgressors (setup a BGPmon account to mail to MICE-DISCUSS) If you are willing to do the work, I like 2, followed by 3. If you don't want to do the work, then 4. -- Richard -- =============================================== 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. 6, 2016

Re: Participants leaking BGP routes for the MICE IXP Block

by Gary Glissendorf

Everyone should not be sending that range but if they are can the import filters for each bgp neighbor to ignore drop for that routes if one is received. Just like the private IP list and AS list. gary.glissendorf(a)sdncommunications.com<mailto:gary.glissendorf@sdncommunications.com> <gary.glissendorf(a)sdncommunications.com<mailto:gary.glissendorf@sdncommunications.com>> 2900 W. 10th St. | Sioux Falls, SD 57104 (w) 605.978.3558 | (c) 605.359-3737 | (tf) 800.247.1442 SDN NOC 877.287.8023 NOC Support email: sdnsupport(a)sdncommunications.com<mailto:sdnsupport@sdncommunications.com> <sdnsupport(a)sdncommunications.com<mailto:sdnsupport@sdncommunications.com>> “Be Excellent to Each Other” From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Thursday, December 1, 2016 10:12 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE IXP Block I didn't think of that variant, but that's why we discuss these kind of things. I'm willing to give that a try. Heck, I might even give people two or three strikes, especially if the actually respond to my email rather than ignore me. :) However, I thought of one advantage of #4 after sending the email. In the case on non-nuisance incidents, like an actual hijack event, everyone is notified immediately. Otherwise, it has to wait for me to forward the email in the case of an actual event. BGPmon pages me, because the University has the paid service, but I'm only human and therefore fallible. Any other comments? On Thu, Dec 1, 2016 at 8:02 PM, Russell Berg <berg(a)wins.net<mailto:berg@wins.net>> wrote: I agree... first strike private, second strike public. Automatic if you don't want to be the transgressor tracker. Russ -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Richard Laager Sent: Thursday, December 01, 2016 8:00 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE IXP Block On 12/01/2016 06:56 PM, David Farmer wrote: > 2. Notify transgressors PRIVATELY > 3. Manually, Name and Shame transgressors 4. Automated, Name and Shame > of transgressors (setup a BGPmon account to mail to MICE-DISCUSS) If you are willing to do the work, I like 2, followed by 3. If you don't want to do the work, then 4. -- Richard -- =============================================== 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 ________________________________ ***This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.***

Dec. 5, 2016

Re: Route Server Filtering

by Gary Glissendorf

SDN Supports the filtering. The AS and the - reject 0/0 - reject RFC1918 - reject bogon ASNs - reject /25 - /32's Keep it as clean as possible. We only want member routes nothing else. gary.glissendorf(a)sdncommunications.com <gary.glissendorf(a)sdncommunications.com> 2900 W. 10th St. | Sioux Falls, SD 57104 (w) 605.978.3558 | (c) 605.359-3737 | (tf) 800.247.1442 SDN NOC 877.287.8023 NOC Support email: sdnsupport(a)sdncommunications.com <sdnsupport(a)sdncommunications.com> "Be Excellent to Each Other" -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, December 2, 2016 9:08 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Route Server Filtering On Dec 1, 2016, at 8:32 PM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > I'm looking for feedback on a filtering proposal. I propose that, on > the route server, by default, we filter incoming routes to block > anything > matching: > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|64 > 61|6762|6939|7018|12956)_ I fully support this. Also would suggest blocking bogon ASNs on the route servers too (good list/examples in Job's presentation as well) For those doing bilateral peering, I'd also highly suggest applying sane import filters on peers to catch folks that aren't behaving properly. We do something like: - reject 0/0 - reject RFC1918 - reject bogon ASNs - reject /25 - /32's -- Andrew Hoyos hoyosa(a)gmail.com ________________________________ ***This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.***

Dec. 5, 2016

Re: Route Server Filtering

by Ben Wiechman

Arvig would also support this. Ben Wiechman Network Engineer IV | Arvig Direct: 320.256.0184 Cell: 320.247.3224 Office: 320.256.7471 ben.wiechman(a)arvig.com On Fri, Dec 2, 2016 at 11:11 AM, Richard Laager <rlaager(a)wiktel.com> wrote: > On 12/02/2016 09:07 AM, Andrew Hoyos wrote: > > - reject 0/0 > > - reject RFC1918 > > - reject bogon ASNs > > Is this what you had in mind? Any changes? > > Specifically, is blocking AS_TRANS 23456 good or bad? I did not block > it in the list below. > > > Block (original, plus additions from David Farmer): > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549| > 5511|6453|6461|6762|6939|7018|11164|11537|12956)_ > > exception: remove 6939 from this list on HE's connection > > Block private AS using this or something with the same effect: > _(6449[6-9])_|_(6450[0-9])_|_(6451[0-1])_|_(6553[6-9])_|_( > 6554[0-9])_|_(6555[0-1])_ > _6(4(5(1[2-9]|[2-9][0-9])|[6-9][0-9][0-9])|5([0-4][0-9][0- > 9]|5([0-2][0-9]|3[0-5])))_ > _6555[2-9]_|_655[6-9][0-9]_|_65[6-9][0-9][0-9]_|_6[6-9][0-9][0-9][0-9]_ > _[7-9][0-9][0-9][0-9][0-9]_|_1[0-2][0-9][0-9][0-9][0-9]_|_ > 130[0-9][0-9][0-9]_ > _1310[0-6][0-9]_|_13107[0-1]_ > _42[0-8][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_ > _(429[0-3][0-9][0-9][0-9][0-9][0-9][0-9])_|_(4294[0-8][0-9][ > 0-9][0-9][0-9][0-9])_ > _(42949[0-5][0-9][0-9][0-9][0-9])_|_(429496[0-6][0-9][0-9][0-9])_ > _(4294967[0-1][0-9][0-9])_|_(42949672[0-8][0-9])_|_(429496729[0-5])_ > > AS0 is a bogon AS we could block: > _0_ > > Block default and RFC 1918, etc. > ip prefix-list upstream-in seq 900 deny 0.0.0.0/8 le 32 > ip prefix-list upstream-in seq 905 deny 10.0.0.0/8 le 32 > ip prefix-list upstream-in seq 910 deny 127.0.0.0/8 le 32 > ip prefix-list upstream-in seq 915 deny 169.254.0.0/16 le 32 > ip prefix-list upstream-in seq 920 deny 172.16.0.0/12 le 32 > ip prefix-list upstream-in seq 925 deny 192.0.0.0/24 le 32 > ip prefix-list upstream-in seq 930 deny 192.0.2.0/24 le 32 > ip prefix-list upstream-in seq 935 deny 192.168.0.0/16 le 32 > ip prefix-list upstream-in seq 945 deny 198.51.100.0/24 le 32 > ip prefix-list upstream-in seq 950 deny 203.0.113.0/24 le 32 > ip prefix-list upstream-in seq 955 deny 224.0.0.0/3 le 32 > ip prefix-list upstream-in seq 990 deny 0.0.0.0/0 le 7 > > Similar for IPv6: > ipv6 prefix-list upstream-in seq 900 deny 3ffe::/16 le 128 > ipv6 prefix-list upstream-in seq 901 deny 2001:db8::/32 le 128 > ipv6 prefix-list upstream-in seq 910 permit 2001::/32 > ipv6 prefix-list upstream-in seq 911 deny 2001::/32 le 128 > ipv6 prefix-list upstream-in seq 920 permit 2002::/16 > ipv6 prefix-list upstream-in seq 921 deny 2002::/16 le 128 > ipv6 prefix-list upstream-in seq 930 deny ::/8 le 128 > ipv6 prefix-list upstream-in seq 940 deny fe00::/9 le 128 > ipv6 prefix-list upstream-in seq 941 deny ff00::/8 le 128 > > -- > Richard >

Dec. 2, 2016

Re: Route Server Filtering

by Richard Laager

On 12/02/2016 09:07 AM, Andrew Hoyos wrote: > - reject 0/0 > - reject RFC1918 > - reject bogon ASNs Is this what you had in mind? Any changes? Specifically, is blocking AS_TRANS 23456 good or bad? I did not block it in the list below. Block (original, plus additions from David Farmer): _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|6939|7018|11164|11537|12956)_ exception: remove 6939 from this list on HE's connection Block private AS using this or something with the same effect: _(6449[6-9])_|_(6450[0-9])_|_(6451[0-1])_|_(6553[6-9])_|_(6554[0-9])_|_(6555[0-1])_ _6(4(5(1[2-9]|[2-9][0-9])|[6-9][0-9][0-9])|5([0-4][0-9][0-9]|5([0-2][0-9]|3[0-5])))_ _6555[2-9]_|_655[6-9][0-9]_|_65[6-9][0-9][0-9]_|_6[6-9][0-9][0-9][0-9]_ _[7-9][0-9][0-9][0-9][0-9]_|_1[0-2][0-9][0-9][0-9][0-9]_|_130[0-9][0-9][0-9]_ _1310[0-6][0-9]_|_13107[0-1]_ _42[0-8][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_ _(429[0-3][0-9][0-9][0-9][0-9][0-9][0-9])_|_(4294[0-8][0-9][0-9][0-9][0-9][0-9])_ _(42949[0-5][0-9][0-9][0-9][0-9])_|_(429496[0-6][0-9][0-9][0-9])_ _(4294967[0-1][0-9][0-9])_|_(42949672[0-8][0-9])_|_(429496729[0-5])_ AS0 is a bogon AS we could block: _0_ Block default and RFC 1918, etc. ip prefix-list upstream-in seq 900 deny 0.0.0.0/8 le 32 ip prefix-list upstream-in seq 905 deny 10.0.0.0/8 le 32 ip prefix-list upstream-in seq 910 deny 127.0.0.0/8 le 32 ip prefix-list upstream-in seq 915 deny 169.254.0.0/16 le 32 ip prefix-list upstream-in seq 920 deny 172.16.0.0/12 le 32 ip prefix-list upstream-in seq 925 deny 192.0.0.0/24 le 32 ip prefix-list upstream-in seq 930 deny 192.0.2.0/24 le 32 ip prefix-list upstream-in seq 935 deny 192.168.0.0/16 le 32 ip prefix-list upstream-in seq 945 deny 198.51.100.0/24 le 32 ip prefix-list upstream-in seq 950 deny 203.0.113.0/24 le 32 ip prefix-list upstream-in seq 955 deny 224.0.0.0/3 le 32 ip prefix-list upstream-in seq 990 deny 0.0.0.0/0 le 7 Similar for IPv6: ipv6 prefix-list upstream-in seq 900 deny 3ffe::/16 le 128 ipv6 prefix-list upstream-in seq 901 deny 2001:db8::/32 le 128 ipv6 prefix-list upstream-in seq 910 permit 2001::/32 ipv6 prefix-list upstream-in seq 911 deny 2001::/32 le 128 ipv6 prefix-list upstream-in seq 920 permit 2002::/16 ipv6 prefix-list upstream-in seq 921 deny 2002::/16 le 128 ipv6 prefix-list upstream-in seq 930 deny ::/8 le 128 ipv6 prefix-list upstream-in seq 940 deny fe00::/9 le 128 ipv6 prefix-list upstream-in seq 941 deny ff00::/8 le 128 -- Richard

Dec. 2, 2016

Re: Route Server Filtering

by Steve Howard

Dec. 2, 2016

Re: Route Server Filtering

by Doug McIntyre

On Fri, Dec 02, 2016 at 09:07:50AM -0600, Andrew Hoyos wrote: > - reject /25 - /32’s OOTH, filtering small prefixes would block dDoS blackholing. I know I've received dDoS traffic directed at me across the Exchange. (via HE, not really their fault). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 2, 2016

Re: Route Server Filtering

by Doug McIntyre

On Fri, Dec 02, 2016 at 08:59:05AM -0600, Steve Howard wrote: > I am curious what routes would be blocked if we ran that regex > against the existing route table in the servers? 31 route prefixes from one connection. They've already been contacted. Zero private ASNs. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 2, 2016

Re: Route Server Filtering

by Andrew Hoyos

On Dec 1, 2016, at 8:32 PM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > I'm looking for feedback on a filtering proposal. I propose that, on the > route server, by default, we filter incoming routes to block anything > matching: > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|6939|7018|12956)_ I fully support this. Also would suggest blocking bogon ASNs on the route servers too (good list/examples in Job’s presentation as well) For those doing bilateral peering, I’d also highly suggest applying sane import filters on peers to catch folks that aren’t behaving properly. We do something like: - reject 0/0 - reject RFC1918 - reject bogon ASNs - reject /25 - /32’s -- Andrew Hoyos hoyosa(a)gmail.com

Dec. 2, 2016

Re: Route Server Filtering

by Steve Howard

Dec. 2, 2016

Re: Participants leaking BGP routes for the MICE IXP Block

by David Farmer

I didn't think of that variant, but that's why we discuss these kind of things. I'm willing to give that a try. Heck, I might even give people two or three strikes, especially if the actually respond to my email rather than ignore me. :) However, I thought of one advantage of #4 after sending the email. In the case on non-nuisance incidents, like an actual hijack event, everyone is notified immediately. Otherwise, it has to wait for me to forward the email in the case of an actual event. BGPmon pages me, because the University has the paid service, but I'm only human and therefore fallible. Any other comments? On Thu, Dec 1, 2016 at 8:02 PM, Russell Berg <berg(a)wins.net> wrote: > I agree... first strike private, second strike public. Automatic if you > don't want to be the transgressor tracker. > > Russ > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Richard Laager > Sent: Thursday, December 01, 2016 8:00 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE > IXP Block > > On 12/01/2016 06:56 PM, David Farmer wrote: > > 2. Notify transgressors PRIVATELY > > 3. Manually, Name and Shame transgressors 4. Automated, Name and Shame > > of transgressors (setup a BGPmon account to mail to MICE-DISCUSS) > > If you are willing to do the work, I like 2, followed by 3. If you don't > want to do the work, then 4. > > -- > Richard > > -- =============================================== 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. 2, 2016

Re: Route Server Filtering

by David Farmer

On Thu, Dec 1, 2016 at 8:32 PM, Richard Laager <rlaager(a)wiktel.com> wrote: > I'm looking for feedback on a filtering proposal. I propose that, on the > route server, by default, we filter incoming routes to block anything > matching: > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549| > 5511|6453|6461|6762|6939|7018|12956)_ > > We can, of course, create exceptions if necessary. One obvious one is > that HE's connection would need their own AS (6939) removed from the > block list. > > This particular list is from here, with 6939 added by me: > https://www.nanog.org/sites/default/files/Snijders_ > Everyday_Practical_Bgp.pdf I'm fine with this. If we do this, I request that 11537 and 11164 be added to the list as well, these are the Internet2 R&E backbone and commercial peering service respectively, a doubt we, UW-Sysnet, or Wiscnet would leak these, but never say never. -- =============================================== 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. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Richard Laager

On 12/01/2016 10:19 AM, Steve Howard wrote: > I'd like to see every member get the first year (or fraction of year > depending upon when they start service) free. This gives everybody a > chance to try it and see if it makes sense for them. Does this matter in practice? If they're committing to $200/month for 36 months with Cologix for the cross-connect, a few months of free 10G port fee is a drop in the bucket. And in Jay's proposal, they could simply start at 1G. If that fills, the exchange has obvious value and they can immediately upgrade to 10G. In your proposal, the 1G is similarly practically free, even though it isn't literally free. > For example: > $35/Gbps/year for everybody. First year (or fraction thereof free). > > 1Gbps=$35/Year > 10Gbps=$350/Year > 100Gbps=$3,500/Year >From my experience, very few costs in the telecom world scale linearly with bandwidth. That is, a 10x increase in bandwidth is usually not 10x the cost. -- Richard

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Richard Laager

On 12/01/2016 11:07 AM, Mike Horwath wrote: > 1Gbe ports - $250 annual per port, LAG allowed, max 2 > 10Gbe ports - $500 annual per port, LAG allowed, max 4 > 40Gbe ports - $2000 annual per port, cause why not just do 100Gbe!?!, > LAG max 2, and above no 40Gbe ports were listed so really, do > 100Gbe and let's move on, okay? > 100Gbe ports - $3000 annual per port, LAG allowed, max 4 40 Gb was not listed because a 40 Gb request uses the same switch port as a 100 Gb request. Accordingly, I would treat anything that consumes a 100G port the same. Also, as a nice side effect, this avoids "penalizing" someone who needs more than 10G because they have 100G gear and not 40G gear. -- Richard

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Richard Laager

I think everyone remembers I agree about PayPal being dangerous on arbitrary account freezes. :) On 12/01/2016 08:36 PM, Reid Fishler wrote: > I don't love PayPal, but with it, you can have the FUNDER pay the fee. > The last thing I want is MICE having to swallow the CC fees. We don't need platform support to make the member pay the fee. Let's say we used Stripe, as Nevin proposes. When the member says they want to pay via credit card, we simply send them a Stripe bill for $1,031 instead of $1,000. -- Richard

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Reid Fishler

I don't love PayPal, but with it, you can have the FUNDER pay the fee. The last thing I want is MICE having to swallow the CC fees. Reid On Thu, Dec 1, 2016 at 9:34 PM, Nevin Lyne <nevin(a)enginehosting.com> wrote: > > > >> We can use Paypal to process credit cards the fee > >> is about 3%. > > Just an FYI, I would highly recommend staying away from Paypal for this, > and use something like Stripe.com. I have seen too many businesses > including established conferences use Paypal that end up having frozen > accounts or other issues with them for random reasons. > https://stripe.com/us/pricing/ is the same pricing, 2 day fund deposits > and we run 100,000+ trasactions/yr through them without issue. > > -Nevin > > > -- Nevin Lyne > -- Founder & Director of Technology > -- Arcustech, LLC. - arcustech.com > -- Gippy's Internet Solutions, LLC. - enginehosting.com > > > -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Nevin Lyne

>> We can use Paypal to process credit cards the fee >> is about 3%. Just an FYI, I would highly recommend staying away from Paypal for this, and use something like Stripe.com. I have seen too many businesses including established conferences use Paypal that end up having frozen accounts or other issues with them for random reasons. https://stripe.com/us/pricing/ is the same pricing, 2 day fund deposits and we run 100,000+ trasactions/yr through them without issue. -Nevin -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Dec. 2, 2016

Route Server Filtering

by Richard Laager

I'm looking for feedback on a filtering proposal. I propose that, on the route server, by default, we filter incoming routes to block anything matching: _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|6939|7018|12956)_ We can, of course, create exceptions if necessary. One obvious one is that HE's connection would need their own AS (6939) removed from the block list. This particular list is from here, with 6939 added by me: https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.p… I've been using something similar in my own network for years because of a badly-behaved peer who I have been unable to set straight. They don't connect to MICE, though. This problem can and does occur at MICE. In fact, it's occurring right now. I've just emailed the relevant network. I suspect this happens because some networks filter their outgoing announcements using fixed prefix lists, not communities based on where they heard the route from. As a result, if their link to a customer goes down (temporarily or permanently), they start leaking transit routes for their customer AS. -- Richard

Dec. 2, 2016

Re: Participants leaking BGP routes for the MICE IXP Block

by Russell Berg

I agree... first strike private, second strike public. Automatic if you don't want to be the transgressor tracker. Russ -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Thursday, December 01, 2016 8:00 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE IXP Block On 12/01/2016 06:56 PM, David Farmer wrote: > 2. Notify transgressors PRIVATELY > 3. Manually, Name and Shame transgressors 4. Automated, Name and Shame > of transgressors (setup a BGPmon account to mail to MICE-DISCUSS) If you are willing to do the work, I like 2, followed by 3. If you don't want to do the work, then 4. -- Richard

Dec. 2, 2016