October 2022 - mice-discuss - lists.micemn.net

Please welcome T-Mobile USA, Inc to MICE!
by Jeremy Lumby Aug. 8, 2025

Aug. 8, 2025

Name: T-Mobile USA, Inc Switch: MICE Main Port: Ethernet 6/15/1 ASN: 21928 IPv4: This is a port addition to an existing LAG, all IP info remains the same. The new connection will be 3x100G IPv6: Peering Contact: peering(a)t-mobile.com Route Servers: Yes BFD: No Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

2 7

Please welcome Hiawatha Broadband Communications to MICE!
by Jeremy Lumby May 9, 2025

May 9, 2025

Name: Hiawatha Broadband Communications Switch: MICE Core Port: E5/41 ASN: 14828 IPv4: IPs remain the same. This is a port addition bringing capacity to 40G on portchannel 32 IPv6: Peering Contact: noc(a)hbci.com Route Servers: YES BFD: YES Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

3 21

Please welcome Express Data Solutions LLC to MICE!
by Jeremy Lumby Dec. 13, 2024

Dec. 13, 2024

Name: Express Data Solutions LLC Switch: MICE MAIN Port: Ethernet4/2 ASN: 31834 IPv4: 206.108.255.183/24 IPv6: 2001:504:27:0:0:7C5A::1/64 Peering Contact: peering(a)express-ds.com Route Servers- Yes BFD: Yes Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 M: 612-355-7740 D: 612-392-6814 F: 952-873-7425 jlumby(a)mnvoip.com

3 10

Please welcome G-Core Labs S.A. to MICE!
by Jeremy Lumby Sept. 7, 2023

Sept. 7, 2023

Name: G-Core Labs S.A. Switch: MICE Core Port: E 4/7 ASN: 199524 IPv4: 206.108.255.191/24 IPv6: 2001:504:27:0:3:0B64::1/64 Peering Contact: noc(a)gcore.lu Route Servers: YES BFD: No Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

2 3

Please welcome UnitedHealth Group to MICE!
by Jeremy Lumby Dec. 12, 2022

Dec. 12, 2022

Name: UnitedHealth Group Switch: MICE Main Ports: 3/28/1 & 6/24/1 (200G Po 12) ASN: 10879 IPv4: 206.108.255.198/24 IPv6: 2001:504:27:0:0:2A7F::1/64 Peering Contact: inet_ops(a)uhc.com Route Servers: YES BFD: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

3 3

Please welcome Truestream to MICE!
by Jeremy Lumby Nov. 21, 2022

Nov. 21, 2022

Name: Truestream Switch: MICE Core Port: E 5/2 ASN: 398143 IPv4: 206.108.255.188/24 IPv6: 2001:504:27:0:6:133F::1/64 Peering Contact: peering(a)truestreamfiber.com Route Servers: No BFD: No Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

1 1

Anyone lose peering with CloudFlare this morning at 4:13 am?
by Frank Bulk Nov. 14, 2022

Nov. 14, 2022

Both IPv4 and IPv6. I didn't see any exceeding of prefix limits. Frank Oct 12 04:13:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 206.108.255.45 (AS13335.micemn.net) (AS 13335 CLOUDFLARENET, US) old state Established event HoldTime new state Idle Oct 12 04:13:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::3417:0:1 (AS13335.micemn.net) (AS 13335 CLOUDFLARENET, US) old state Established event HoldTime new state Idle

4 9

Proposal: MICE Static MAC address Only
by Jay Hanke Nov. 3, 2022

Nov. 3, 2022

I propose we change the MICE required port security settings to be hard filtered for a single static mac address per port. Over the years, we've had several incidents where floods have occurred prior to port being error-disabled during a looping event. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

10 30

MICE - IXP Manager - Change Control Access
by Justin Krejci Oct. 31, 2022

Oct. 31, 2022

Spinning off a new thread from the static/mac-limit/port-security conversation. The IXP Manager can generate an instruction command and makes it available to the Arista(s). The switch(es) could pull the config using a script that further sanitizes/validates the config its pulling before applying. This would prevent IXP Manager from having its own direct access to the switch. This could also be the case for pulling data from the switch(es) as well. Patterned after a TR-069 or similar concept, the switch could phone home to the IXP manager (once a minute cronjob for example) and see if there is anything the IXP manager wants done. A simple text based file (json, etc) is generated by the IXP manager and the Arista would then just query this file and parse out instructions and perform actions as instructed or ignore them if malformed or otherwise not allowed. Obviously this is would be only for Arista switch(es) managed by MICE. I don't have any IXP Manager experience beyond simple user but I know Arista can do this fairly easily. It could also just be a RESTful API even. Maybe something like this already exists I have no idea but I would highlight the two things this concept does 1: Allows IXP manager to affect change without direct access to the switch(es) 2: Allows the Arista switch(es) to ultimately decide to accept or ignore instructions to make config changes, send info, perform other actions like bounce my member port, apply TCP/179 filtering to my port, show me some log data, etc. This concept could also apply to the route servers too since they also run a *nix OS like Arista. This would not be a simple/quick idea but I feel would check various boxes for people: air gap, allows automation/self-service, and if automation fails it results in a fallback to manual only changes like we are doing today anyways, etc. Since I know MICE does have money, it could be dev work hired out to someone or a team to produce and then MICE retains rights to the resultant code. We have enough people across our membership that I am sure we could validate the code is sound and also perform bugfixes as needed going forward, perhaps even make it public, GPL style. Maybe IXP Manager already has some of this functionality? Last second additional thought, simple instructions (eg add a second MAC address, show me log data for my port) get automatically approved. Bigger changes (remove/change my MAC address, some other action) need to get some sort of manual approval by the tech team so it can be scrutinized first. None of this needs to be done in IXP Manager either but some other custom, purpose built web portal. Maybe I'm way overthinking this. Food for thought at any rate. -Justin

1 0

Re: Proposal: MICE Static MAC address Only
by Jeremy Lumby Oct. 31, 2022

Oct. 31, 2022

I second that proposal Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington MN 55425 Main 612-355-7740 Direct 612-392-6814 EFax 952-873-7425 jlumby(a)mnvoip.com -------- Original message -------- From: Jay Hanke <jayhanke(a)SOUTHFRONT.IO> Date: 10/31/22 8:27 AM (GMT-06:00) To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Proposal: MICE Static MAC address Only _____ >From : Jay Hanke [jayhanke(a)SOUTHFRONT.IO] To : MICE-DISCUSS(a)LISTS.IPHOUSE.NET [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] Date : Monday, October 31 2022 08:27:14 I propose we change the MICE required port security settings to be hard filtered for a single static mac address per port. Over the years, we've had several incidents where floods have occurred prior to port being error-disabled during a looping event. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

1 0