April 2020 - mice-discuss - lists.micemn.net

Re: [ADV] [MICE-DISCUSS] Savage Communications Upgrade

by Jeremy Lumby

4/33 has been added -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Mike Danielson Sent: Thursday, April 16, 2020 9:23 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [ADV] [MICE-DISCUSS] Savage Communications Upgrade We have cut our traffic over to the new port 5/33 and we are ready for port 4/33 to be put into the LAG group. Thanks, Mike Danielson Savage Communications Inc. Office: 320-384-7442 x717 Cell: 651-343-4241 scibroadband.com -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Thursday, April 02, 2020 4:04 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [ADV] [MICE-DISCUSS] Savage Communications Upgrade On Thu, Apr 02, 2020 at 03:03:34PM -0500, Jay Hanke wrote: >Savage Communications is upgrading from 1x10G to 2x10G LAG. > >Please allocate Ethernet 5/33 on the Main switch. This will require a >new LAG and then their existing port (4/33) will be migrated into the LAG. Okay, Port-Channel36 setup, Eth 5/33 put into the LACP lag, and ready to go for them to cut their traffic over to it when they are ready. Once traffic has stopped over 4/33, we can put that into the LAG group and they can continue along when they want. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

April 16, 2020

Re: [ADV] [MICE-DISCUSS] Savage Communications Upgrade

by Mike Danielson

We have cut our traffic over to the new port 5/33 and we are ready for port 4/33 to be put into the LAG group. Thanks, Mike Danielson Savage Communications Inc. Office: 320-384-7442 x717 Cell: 651-343-4241 scibroadband.com -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Thursday, April 02, 2020 4:04 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [ADV] [MICE-DISCUSS] Savage Communications Upgrade On Thu, Apr 02, 2020 at 03:03:34PM -0500, Jay Hanke wrote: >Savage Communications is upgrading from 1x10G to 2x10G LAG. > >Please allocate Ethernet 5/33 on the Main switch. This will require a >new LAG and then their existing port (4/33) will be migrated into the LAG. Okay, Port-Channel36 setup, Eth 5/33 put into the LACP lag, and ready to go for them to cut their traffic over to it when they are ready. Once traffic has stopped over 4/33, we can put that into the LAG group and they can continue along when they want. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

April 16, 2020

100G Linecard EMERGENCY MAINTENANCE

by Jeremy Lumby

In troubleshooting the 100G line card, Arista has requested that the line card be power cycled. Being that there is a possibility that the line card would not recover from a restart, I am working with Dave @ the UofM to have a spare available in the event that the card fails to restart. I plan on blocking BGP to all ports on the card before restarting the card. Based on the current state of the card, I am unsure that it will block BGP properly. I plan on restarting the card tomorrow at 4PM CDT. In the past I have noticed that the 100G cards take a long time to boot up, so I would anticipate a minimum of 15 minutes of downtime if everything goes perfectly. 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 -----Original Message----- From: Jeremy Lumby [mailto:jlumby@mnvoip.com] Sent: Wednesday, April 15, 2020 4:18 PM To: MICE Discuss Subject: 100G Linecard I wanted to let everyone know that we are experiencing an issue with the 100G linecard on the MICE Arista core switch. The card is currently outputting errors and not detecting new optics. I am currently working with Arista to troubleshoot the issue. At the moment any 100G upgrades would need to be on hold until the issue is resolved. All established connections seem to be working fine. I will report back as soon as I have more information. 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

April 15, 2020

100G Linecard

by Jeremy Lumby

I wanted to let everyone know that we are experiencing an issue with the 100G linecard on the MICE Arista core switch. The card is currently outputting errors and not detecting new optics. I am currently working with Arista to troubleshoot the issue. At the moment any 100G upgrades would need to be on hold until the issue is resolved. All established connections seem to be working fine. I will report back as soon as I have more information. 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

April 15, 2020

SDN Upgrade

by Jay Hanke

SDN will be upgrading their existing LAG configuration to 1x100G. The new port assignment on the main switch is Ethernet3/23/1. Welcome aboard again! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

April 15, 2020

Re: Port was down

by Todd Mueller

Thanks for checking Jeremy, I am not sure how that could have happened yet but the MAC address should be helpful in tracking that down. Todd From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Tuesday, April 14, 2020 4:25 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Port was down Looks like the switch detected a second MAC address, and errordisabled the port: Apr 14 10:06:34 core-sw0 PortSec: %PORTSECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 64:9e:f3:eb:6e:b0 on vlan 1 interface Ethernet4/21. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Todd Mueller Sent: Tuesday, April 14, 2020 4:06 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Port was down Our (Velocity Telephone) MICE port physically went down at 10:06A and came back up at 2:31P today. Anyone aware of maintenance or anything else? Thanks! Todd _____ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1 _____ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1

April 14, 2020

Re: Port was down

by Jeremy Lumby

Looks like the switch detected a second MAC address, and errordisabled the port: Apr 14 10:06:34 core-sw0 PortSec: %PORTSECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 64:9e:f3:eb:6e:b0 on vlan 1 interface Ethernet4/21. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Todd Mueller Sent: Tuesday, April 14, 2020 4:06 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Port was down Our (Velocity Telephone) MICE port physically went down at 10:06A and came back up at 2:31P today. Anyone aware of maintenance or anything else? Thanks! Todd To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 14, 2020

Port was down

by Todd Mueller

Our (Velocity Telephone) MICE port physically went down at 10:06A and came back up at 2:31P today. Anyone aware of maintenance or anything else? Thanks! Todd

April 14, 2020

Giga Pop Additional MICE Connection

by Jay Hanke

The UofM Gigapop will be adding an additional connection to MICE via the new WiscNet Remote Switch. Name: University of Minnesota Port: WiscNet Remote Switch ASN: 57 IPv4: 206.108.255.162/24 IPv6: 2001:504:27:0:0:0039::3/64 Route Server: Yes BFD: Yes Please report back the port assignments for our records. Welcome aboard again! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

April 7, 2020

Re: Blackhole IP if needed?

by Andrew Hoyos

On Apr 6, 2020, at 6:46 PM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > On 4/6/20 6:38 PM, Andrew Hoyos wrote: >> >> On Apr 6, 2020, at 5:25 PM, Richard Laager <rlaager(a)WIKTEL.COM <mailto:rlaager@WIKTEL.COM>> wrote: >>> >>> On 4/6/20 5:17 PM, Andrew Hoyos wrote: >>>> This came up in two different conversations in June and January (per >>>> mice-discuss archives) >>>> I think the concern here is that the route servers aren’t doing IRR >>>> filtering of members yet. >>>> I agree 100% with the approach below, but with one caveat - we need to >>>> be filtering members on the route servers first via IRR. >>>> Otherwise, nothing preventing a member from advertising a /32 tagged >>>> with a blackhole community of 8.8.8.8, or another member’s IP address. >>> >>> Nothing is stopping me from announcing 8.8.8.0/24 right now, right? >> >> I agree, that’s true in the current scenario. Nothing preventing you from doing that towards the route servers. >> >> As it stands right now, though, we wouldn’t necessarily have to accept that route, and we’d have local control to reject/block or filter your ASN, drop RPKI invalid prefixes, etc, and to react as we please (ie: operational processes to fix the issue without reliance on MICE intervention, and without completely dropping our route server sessions). >> >> Or perhaps folks are already doing self-generated prefix lists and actions towards route server prefixes already (we, for example, passively keep an eye on ASNs/IRR data vs routes learned from MICE route servers). >> >> In short, we’ve got tools to deal, if you do. > ... >> In the case we enable a RTBH community without strict filtering, we’ve taken the control out of the members hands, and put a powerful tool in any members hands with no regard to security. > I'm still not understanding the difference between someone originating 8.8.8.0/24 and 8.8.8.8/32+65535:666. In either case (with blackholing support added), the route server will accept and propagate that to route server users. Whether they choose to accept that announcement is up to them the same either way. > > Note that announcements to the route server do not directly result in blackholing traffic across the fabric. It simply sets a special next-hop.* If a participant chooses to accept that BGP route and route traffic to that next-hop*, only then will the traffic will be eaten. To put a finer point on this: if someone does not use the route servers, this change does not affect them in any way no matter what anyone announces as a blackhole route to the route servers. Ack, thanks. Perhaps I misunderstood intent of actually dropping in flight traffic on switch fabric - this makes more sense and lessens my concern. Still think we should get IRR filtering in place first.

April 7, 2020