- mice-discuss - lists.micemn.net

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