- mice-discuss - lists.micemn.net

Please welcome Christensen Communications to MICE!
by Jason Hanke Jan. 5, 2017

Jan. 5, 2017

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

2 1

Amazon on MICE
by Justin Krejci Jan. 5, 2017

Jan. 5, 2017

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

5 6

Amazon Peering
by Jason Hanke Jan. 4, 2017

Jan. 4, 2017

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

1 0

Route server #2 copper connection
by Jeremy Lumby Dec. 22, 2016

Dec. 22, 2016

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

2 2

RR#2 cable?
by Doug McIntyre Dec. 22, 2016

Dec. 22, 2016

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

6 9

UG 22 Minutes
by Richard Laager Dec. 19, 2016

Dec. 19, 2016

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

1 0

MICE UG Reminder
by Jason Hanke Dec. 12, 2016

Dec. 12, 2016

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

3 2

MN VoIP Remote Switch
by Jason Hanke Dec. 9, 2016

Dec. 9, 2016

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

2 1

Participants leaking BGP routes for the MICE IXP Block
by David Farmer Dec. 6, 2016

Dec. 6, 2016

I have BGPmon set up to notify me of the MICE IXP blocks (IPv4 and IPv6) are being announce in BGP by any other AS that MICE itself. The current BPC is to not even put a route in your IGP for for an exchange block, let alone originate a BGP route for it. http://www.bgp4all.com.au/dokuwiki/_media/conferences/apnic42-ixp-design-bc… See slide 45. In the last 2 or 3 months I have seen three different participant ASNs originate routes for 206.108.255.0/24, haven't seen any for do it for 2001:504:27::0/48. I'm not going to name and shame, at least for past events. But, what should we do about this going forward? 1. Ignore it 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) 5. Other ideas? (electro-shock for transgressors :) ) Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

5 5

Route Server Filtering
by Richard Laager Dec. 5, 2016

Dec. 5, 2016

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

7 9