- mice-discuss - lists.micemn.net

IPv6 neighbor solicitation at the exchange
by James Stahr July 21, 2014

July 21, 2014

First off, Did anyone make any changes on 07/15/2014 around 08:00? The reason is that I think I've resolved an issue with our IPv6 peering with the MICE route servers, Charter, and TDS and I'm looking for a larger audience to see if it's my issue or perhaps an issue at the exchange. I believe it to be the latter, but I'm not an IPv6 expert. Starting two days ago around 8am CDT, we started experiencing BGP timeouts on some of our IPv6 BGP sessions. I was able to work around the issue by removing our COPP policy and the BGP sessions were stable for 24 hours. Reapplied the policy, sessions started to drop again. Looked at the policy to see which category is being exceeded, it's not the routing section which allows BGP/BFD/etc, but the ICMP-v6 one: ipv6 access-list COPP-icmp-v6 remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 permit icmp any any destination-unreachable permit icmp any any packet-too-big permit icmp any any time-exceeded permit icmp any any parameter-problem remark nd-na, nd-ns, ra, rs permit icmp any any nd-na permit icmp any any nd-ns permit icmp any any router-advertisement permit icmp any any router-solicitation remark MLD - query, report_v2 permit icmp any any mld-query permit icmp any any 143 which is being policed like this: class Icmp-v6 police 32000 60000 120000 conform-action transmit exceed-action drop I've worked around the issue by making a 4x increase in the policing, but the question I have is what happened at the exchange to provoke my COPP policy? Alternatively, is this normal or indicate who has the problem: r-pop-min-1#deb ipv6 icmp ICMP Packet debugging is on r-pop-min-1# Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 r-pop-min-1# Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 r-pop-min-1# Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 r-pop-min-1# Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 I'm thinking that the answer is that this is not normal, as it looks like I'm getting duplicate solicitations in the same second. -James ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

4 5

MICE UG 13 - Duluth July 24th Note 2PM start
by Mike Hemphill July 21, 2014

July 21, 2014

Good Afternoon All! MICE UG 13 has been scheduled, as follows: Date: Thursday, July 24th Time: 2:00 pm (1400 Hours) David Farmer has the facility reserved until 5PM Location: University of Minnesota, Duluth campus, Griggs Center, located in the *Kirby Student Center (KSC) * http://www.d.umn.edu/maps/KSC/ Please send your agenda items when you have a chance! Also please invite business & other entities that may have an interest in connecting to MICE. Our goal is to extend the reach of MICE connectivity to outstate institutions & companies. Thanks! Reid, Shaun & Mike *Mike Hemphill* *General Manager | **Cologix, Inc. <http://www.cologix.com/>* *511 11th Ave S, Suite 450 | Minneapolis, MN 55415P: 1+612.333.1922 | M: 1+612.812.5242mike.hemphill(a)cologix.com <mike.hemphill(a)cologix.com>* ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

6 5

Please welcome 702 Communications to MICE
by Jay Hanke July 10, 2014

July 10, 2014

Name: 702 Communications Port: CNS switch gi0/4 ASN: 15627 IPv4: 206.108.255.54/24 IPv6: 2001:504:27:0:0:3d0b::1/64 Peering Contact: dpoehls(a)702communications.com Route Servers and website please! Welcome aboard! -- Jay Hanke CEO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke(a)mankatonetworks.net http://www.mankatonetworks.com http://www.neutralpath.net ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

2 1

Please Welcome Acentek to MICE
by Jay Hanke July 4, 2014

July 4, 2014

Acentek ASN: 40328 Port: Kato Remote Switch ge-0/0/15 IPv4: 206.108.255.109/24 IPv6: 2001:504:27:0:0:9D88::1/64 Peering contact: peering(a)acentek.net Estimated activation 8/1/14 Website and route servers please. Welcome aboard! -- Jay Hanke CEO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke(a)mankatonetworks.net http://www.mankatonetworks.com http://www.neutralpath.net ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

3 2

a poll about operators (that's you) participating in the IETF
by Mike O'Connor June 14, 2014

June 14, 2014

hi all, thought that some of you might find this interesting. and some of you might want to blast through the poll. mikey http://www.circleid.com/posts/20140612_the_ietfs_other_diversity_challenge/ The IETF's *Other* Diversity Challenge Jun 12, 2014 10:32 AM PDT Comments: 0 Views: 1,013 Print Comment By Chris Grundemann The Internet Engineering Task Force (IETF) is the standards body for the Internet. It is the organization that publishes and maintains the standards describing the Internet Protocol (IP – versions 4 and 6), and all directly related and supporting protocols, such as TCP, UDP, DNS (and DNSSEC), BGP, DHCP, NDP, the list goes on, and on. In their own words: The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. But how do they do that? How does the IETF produce documents, and ensure that they are high quality, relevant, and influential? Without going into too much boring detail here, the IETF uses a system of grassroots collaboration that is really quite revolutionary in many ways. The IETF is split into broad focus "Areas" and then again into specific "Working Groups" that each target a single problem or technical topic. While there is leadership at each level, the real power of the IETF is that all the real innovation and decision making happens out on the edges, from the bottom-up rather than the top-down. Combine this grassroots collaboration within each working group with the bottom-up decision making power vested in them and then add in the openness for anyone to join any working group any time, and you start to see the magic of the IETF. All work is contributed by individuals, all decisions are based on rough consensus and running code, and the whole thing "just works." But does it work as well as it could? Nothing is perfect, of course, so shouldn't we always strive for improvement? One area that can almost always be improved in any global organization is diversity. The great benefit of an open organization, like the IETF, is that anyone can have his or her voice heard. The great tragedy is that only those who speak up can ever be heard. This makes who is participating very important indeed. We want as many voices from as many backgrounds as possible to ensure the best achievable outcome. Without having all the right people involved, we run the risk of missing something key, for lack of their perspective. The IETF is already aware of the importance of diversity and steps are being taken to help ensure representation in the IETF from all areas of the world, and more equal representation from both genders. The Internet Society Fellows program helps bring folks from around the globe who wouldn't otherwise be able to participate to IETF meetings and there is a diversity design team with an open mailing list for community (that's you) feedback to help them in "identifying diversity related issues that the IETF faces and making practical recommendations that can help in this regard." I applaud these efforts! Each of us should contribute to them, and to the overall diversity dialogue, in every way we can. But I see another diversity issue at play in the IETF as well, and I've come to learn that I'm not alone. This "other diversity challenge" may be a bit more subtle and harder for those not familiar with the Internet industry to see. The physical differences between Operators, Vendors, and Academics are markedly less than those between men and women. The differences in perspective, however, may actually be far greater in both scope and scale. The differences in the way that someone actively running a network views a problem, and the way that same problem is seen by someone writing code for routers are significant. The same goes for either of those two and someone conducting network research. We need all three of these broad views, and all the myriad of views that each contain, informing our innovation and our decision making at the IETF. Currently, it seems, that is not entirely the case. Many believe that the level of operational input into the IETF is too low. That's not to say there are no operators at the IETF, nor to infer that the operators who do participate already are somehow inadequate. Quite the opposite. Just as the first women, or Latin Americans, or Africans, or Asians to participate in the IETF paved the way for more diversity, those operators who participate today, who have participated in the past — and especially those who have participated all along — have kept the door open for additional operator input. One shining example of this is the IEPG, or Internet Engineering and Planning Group, who meet the Sunday before every IETF meeting to discuss operational issues. How do we expand on that? How do we ensure that network operators, those folks responsible for keeping the packets flowing across their (service provider, enterprise, data-center, campus, cloud, etc.) networks, are always included in those who are working to influence the way we design, use, and manage the Internet? To answer that, my team at the Internet Society decided first to research the issue. We want to know if there are, in fact, barriers to operator involvement in the IETF, and if so, what they are. This is where *you* come in. We have an informal survey posted specifically to gather information from network operators about the IETF. We particularly want to hear from folks who are network operators but do not currently participate in the IETF; we want to know why! So if you operate a network, please take our survey, and whether you do or not, please share it as well. We want to hear from people you know, in your part of the world, as well as everywhere else! The survey will close after the last day of June. On the first of July we'll begin synthesizing everything we've heard. Then we'll present it back to the global network engineering community, to network operators the world round. We'll also present it to the IETF, to share our findings and amplify the voice of the operators. Once we know we've heard everything, and recorded it correctly, we'll start working on solutions to any identified problems. I believe we'll be able to classify the solutions we find based on who is needed to implement them. There will likely be a set of things that operators themselves, or more likely operator groups, can do to help. There will probably be another set of improvements or changes that the IETF itself can make to improve operator engagement and operational input. Finally, I think we may also find some things that the Internet Society can do to help facilitate these interactions. But before we can even think about solutions, we must first define the problems. Please help us in this effort, take and share this survey before 31 June 2014 (shortlink: http://bit.ly/opsietfsurvey) Thank you! By Chris Grundemann, Internet Technologist, Author, and Speaker. All opinions are his and his alone. More blog posts from Chris Grundemann can also be read here. PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

1 0

Please welcome Code42 to MICE
by Jay Hanke June 10, 2014

June 10, 2014

Name: Code42 ASN: 62715 Main switch port xe-0/0/19 IPv4: 206.108.255.32/24 IPv6: 2001:504:27:0:0:f4fb::1/64 Contact: peering(a)code42.com Route servers and website please. Welcome aboard! -- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke(a)mankatonetworks.net http://www.mankatonetworks.com http://www.neutralpath.net ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

4 3

Akamai (20940) < > MICE IXP Brief Maintenance
by Hannigan, Martin June 9, 2014

June 9, 2014

Folks, You may have seen our traffic drop off. We are conducting a brief maintenance. Traffic should return to normal levels shortly. Best, -M< ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

1 1

Please welcome Monticello Fibernet to MICE
by Jay Hanke May 21, 2014

May 21, 2014

Monticello Fibernet will be connecting to port ge-0/0/8 of the Mankato Networks remote switch. I have assigned 206.108.255.108 for their IPv4 connection. Their ASN is pending with ARIN. Please update the website. I will send out another announcement with their ASN and IPv6 subnet as soon as the ASN has been assigned. Thanks! -- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke(a)mankatonetworks.net http://www.mankatonetworks.com http://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

1 0

Wrapping up my time at ICANN
by Mike O'Connor May 10, 2014

May 10, 2014

hi all, just a quick note to announce my retirement from ICANN. i know i haven’t deluged you with lots of posts and rumpus, but i did my best to represent the views of MICE while i was there. my focus was almost entirely on nudging ICANN to do a better job at the security and stability of the DNS. thanks for letting me do that. mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

2 1

Port Security
by Jeremy Lumby May 6, 2014

May 6, 2014

At the last meeting there was a group that was going to email out the proposed process to secure the ports on the MICE switches. I was just wondering how that was coming along. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

2 1