- mice-discuss - lists.micemn.net

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