- mice-discuss - lists.micemn.net

Re: MICE Blackhole IP Allocation

by Richard Laager

On 11/22/20 8:11 AM, Jay Hanke wrote: > SIX has a /23 for the peering subnet and the blackhole address sits on > the middle .0 which is old school cidr legal. Good point. > The mice 0 is also the network address which could cause issues arping > with some gear. Fair enough. -- Richard

Nov. 22, 2020

Re: MICE Blackhole IP Allocation

by Jay Hanke

> > Why not .0, as SIX does? > SIX has a /23 for the peering subnet and the blackhole address sits on the middle .0 which is old school cidr legal. The mice 0 is also the network address which could cause issues arping with some gear.

Nov. 22, 2020

Re: MICE Blackhole IP Allocation

by Richard Laager

On 11/21/20 2:20 PM, Jay Hanke wrote: > The following IP addresses have been allocated for the upcoming > blackhole project on the MICE Internet Exchange. > > MICE-BH > IPv4: 206.108.255.228/24 Why not .0, as SIX does? > IPv6: 2001:504:27::6666:dead:beef/64 > > We will be using 66:66:de:ad:be:ef as the mac-address and inject the > arp entry from a virtual machine on the SFN-Remote until a permanent > solution on the main switch is worked out. A VM on the same setup as the route server is a reasonable permanent plan (and I believe was the plan). -- Richard

Nov. 22, 2020

MICE Blackhole IP Allocation

by Jay Hanke

The following IP addresses have been allocated for the upcoming blackhole project on the MICE Internet Exchange. MICE-BH IPv4: 206.108.255.228/24 IPv6: 2001:504:27::6666:dead:beef/64 We will be using 66:66:de:ad:be:ef as the mac-address and inject the arp entry from a virtual machine on the SFN-Remote until a permanent solution on the main switch is worked out. Thanks! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 21, 2020

Re: Update PTR

by Frank Bulk

Great, thank you. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Wednesday, November 18, 2020 5:00 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Update PTR On Wed, Nov 18, 2020 at 10:02:16PM +0000, Frank Bulk wrote: >Premier is no longer a part of MICE. > >Can the PTR for 206.108.255.67 be updated so that it doesn't list AS53347.micemn.net? Okay, that is done. I also removed the IPv6 reverse that was setup as well.

Nov. 20, 2020

Re: Update PTR

by Doug McIntyre

On Wed, Nov 18, 2020 at 10:02:16PM +0000, Frank Bulk wrote: >Premier is no longer a part of MICE. > >Can the PTR for 206.108.255.67 be updated so that it doesn't list AS53347.micemn.net? Okay, that is done. I also removed the IPv6 reverse that was setup as well.

Nov. 18, 2020

Update PTR

by Frank Bulk

Premier is no longer a part of MICE. Can the PTR for 206.108.255.67 be updated so that it doesn't list AS53347.micemn.net? Thanks, Frank

Nov. 18, 2020

Re: PeeringDB Audit Emails

by Jay Hanke

Yes, we have been through this process without progress. :( On Wed, Nov 18, 2020 at 2:56 PM James Urwiller <james.urwiller(a)turnkey-telecom.com> wrote: > > After talking to a few people at Zayo through normal support channels. They > said that an email has to be sent to peering(a)zayo.com to get this the > visibility it needs. Sorry I couldn’t get any further with this! > > James Urwiller > Network Architect > Stealth Broadband > james.urwiller(a)stealthbroadband.com > > > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke > Sent: Wednesday, November 18, 2020 11:52 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] PeeringDB Audit Emails > > I've gotten several emails from MICE members about IX-F export issues on > PeeringDB. > > MICE provides a list of port/peering information to PeeringDB in JSON format > and they started auditing against what users have entered into the site. The > export is generated from our IXP Manager platform we deployed a couple > months ago. > > The most common mismatch is the user not having the IPv6 address loaded in > PeeringDB. MICE allocates an IPv6 address with every IPv4 allocation. > [insert ipv6 pitch here] > > Members on the Zayo Remote switch in Belle Plaine are currently not > currently included in the export. There is an issue with loading the ports > into IXP manager and we need an admin at Zayo to make a couple of > routing/snmp changes. All of the other switches were completed and loaded > several months ago. > > If someone has a good contact at Zayo for this please let me know. > > -- > Jay Hanke, President > South Front Networks > jayhanke(a)southfront.io > Phone 612-204-0000 -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 18, 2020

Re: PeeringDB Audit Emails

by James Urwiller

After talking to a few people at Zayo through normal support channels. They said that an email has to be sent to peering(a)zayo.com to get this the visibility it needs. Sorry I couldn’t get any further with this! James Urwiller Network Architect Stealth Broadband james.urwiller(a)stealthbroadband.com -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke Sent: Wednesday, November 18, 2020 11:52 To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] PeeringDB Audit Emails I've gotten several emails from MICE members about IX-F export issues on PeeringDB. MICE provides a list of port/peering information to PeeringDB in JSON format and they started auditing against what users have entered into the site. The export is generated from our IXP Manager platform we deployed a couple months ago. The most common mismatch is the user not having the IPv6 address loaded in PeeringDB. MICE allocates an IPv6 address with every IPv4 allocation. [insert ipv6 pitch here] Members on the Zayo Remote switch in Belle Plaine are currently not currently included in the export. There is an issue with loading the ports into IXP manager and we need an admin at Zayo to make a couple of routing/snmp changes. All of the other switches were completed and loaded several months ago. If someone has a good contact at Zayo for this please let me know. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 18, 2020

Re: PeeringDB Audit Emails

by James Urwiller

I have zero good contacts there.. I will just create a service ticket and see where it gets me James Urwiller Network Architect Stealth Broadband james.urwiller(a)stealthbroadband.com -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke Sent: Wednesday, November 18, 2020 11:52 To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] PeeringDB Audit Emails I've gotten several emails from MICE members about IX-F export issues on PeeringDB. MICE provides a list of port/peering information to PeeringDB in JSON format and they started auditing against what users have entered into the site. The export is generated from our IXP Manager platform we deployed a couple months ago. The most common mismatch is the user not having the IPv6 address loaded in PeeringDB. MICE allocates an IPv6 address with every IPv4 allocation. [insert ipv6 pitch here] Members on the Zayo Remote switch in Belle Plaine are currently not currently included in the export. There is an issue with loading the ports into IXP manager and we need an admin at Zayo to make a couple of routing/snmp changes. All of the other switches were completed and loaded several months ago. If someone has a good contact at Zayo for this please let me know. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 18, 2020

PeeringDB Audit Emails

by Jay Hanke

I've gotten several emails from MICE members about IX-F export issues on PeeringDB. MICE provides a list of port/peering information to PeeringDB in JSON format and they started auditing against what users have entered into the site. The export is generated from our IXP Manager platform we deployed a couple months ago. The most common mismatch is the user not having the IPv6 address loaded in PeeringDB. MICE allocates an IPv6 address with every IPv4 allocation. [insert ipv6 pitch here] Members on the Zayo Remote switch in Belle Plaine are currently not currently included in the export. There is an issue with loading the ports into IXP manager and we need an admin at Zayo to make a couple of routing/snmp changes. All of the other switches were completed and loaded several months ago. If someone has a good contact at Zayo for this please let me know. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 18, 2020

IPv6 BGP Peering to Netflix bouncing 60+ days

by Jesse Reed

All: We have been tracking our IPv6 peering via our MICE path to Netflix and noticed it bouncing consistently since at least September (probably longer). All other peerings on this path (both v4 and v6) have been stable and are not experiencing these drops. Is anyone else in the group experiencing similar drops to their IPv6 only peerings w/Netflix? The peer that we see this occurring w/is: 2001:504:27::b5a:0:1 Thanks so much ahead of time, Jesse

Nov. 18, 2020

SFN Remote Switch Backhaul Upgrade

by Jay Hanke

Please allocate Ethernet1/1 on the MN VoIP 100G remote switch for a new SFN remote uplink. When completed the link from the SFN Remote switch will increase from 40G to 100G. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 13, 2020

Re: Nuvera Upgrade to 1x4x10G

by Doug McIntyre

On Thu, Nov 12, 2020 at 12:00:18PM -0600, Jay Hanke wrote: >Please allocate and add the following ports to the existing Nuvera LAG group. > >Ethernet4/14 >Ethernet5/14 > >The new group will be 4x10G I added the two ether interfaces to the existing LAG on PC33. This is complete and waiting for their circuits to be installed.

Nov. 12, 2020

Nuvera Upgrade to 1x4x10G

by Jay Hanke

Please allocate and add the following ports to the existing Nuvera LAG group. Ethernet4/14 Ethernet5/14 The new group will be 4x10G -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Nov. 12, 2020

MN VoIP Remote Switch Upgrade

by Jay Hanke

Port Ethernet6/6/1 on the main switch has been allocated to MN VoIP. The port will be in a LAG configuration with their existing 100G port for a total of 2x100G IP addresses will remain the same. Welcome aboard! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Oct. 27, 2020

Fwd: [arin-announce] Vote Now in the 2020 ARIN Elections

by David Farmer

It's that time of year, again. Voting has opened for the ARIN election and will remain open to 5:00 PM ET, Friday, October 30th. Please take the time to vote if you are a designated voting contact for ARIN for your organization. Thank you, and Please VOTE!! ---------- Forwarded message --------- From: ARIN <info(a)arin.net> Date: Fri, Oct 23, 2020 at 2:00 PM Subject: [arin-announce] Vote Now in the 2020 ARIN Elections To: arin-announce(a)arin.net <arin-announce(a)arin.net> Eligible Voting Contacts from General Members in Good Standing may now cast online ballots in the 2020 ARIN Elections to fill two seats on the ARIN Board of Trustees and five seats on the ARIN Advisory Council. Ballots may be cast now through 5:00 PM ET, Friday, 30 October. To vote, simply log in to ARIN Online with a user account associated with a voting contact for an eligible Member in Good Standing and look for the “Vote Now” link on your dashboard. Additional instructions are available at https://www.arin.net/voting/ For information about the candidates, there are several options: * You may view video of candidate speeches and review statements of support and candidate questionnaire responses at https://www.bigpulse.com/p60984/ * Read the collected candidate biographies in the ARIN Elections 2020 Voter Guide at https://www.arin.net/participate/oversight/elections/candidate_bios.pdf * Starting Monday, 26 October, you can view the Board and Advisory Council Candidate Forums that took place during the virtual ARIN 46 Members Meeting at https://www.arin.net/elections/ Statements of Support are still open for submissions through 30 October. To view or submit a Statement of Support, please visit the link above. Anyone, regardless of voter status, is eligible to submit a Statement of Support for a candidate. During the week of 26 – 30 October, all eligible Voting Contacts will receive regular email reminders and may receive a personal call from an ARIN representative reminding them to please vote. Those who have already voted should not receive any further reminders. As the voting contact for an eligible member organization, participation in ARIN Elections requires only minutes of your time and is not only a key member responsibility, but is an opportunity to shape the future of ARIN, our community, and the Internet. For questions about voting, or if you encounter an issue with the election system, please contact us immediately at members(a)arin.net. You may also submit a question via ARIN Online and direct it to Meetings/Elections. Thank you for your participation in the 2020 ARIN Elections! Regards, Jason Byrne Senior Customer Success Analyst American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net) Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues. -- =============================================== 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 ===============================================

Oct. 23, 2020

UG 36 Meeting (1 Hour Reminder)

by Richard Laager

On 9/14/20 3:55 PM, Richard Laager wrote: > The MICE UG 36 meeting will be held Wednesday, October 7, 3:00 pm, > online at: https://meet.google.com/zgg-eeyu-dxz > > The agenda and draft UG 35 minutes are attached. > > If something goes wrong with the Google Meet, we can fall back to the > phone conference: 952-562-5400 passcode MICE (6423). Note that the > phone conference will /not/ connect you to the Google Meet meeting; > this is purely a backup plan. > > *Election* > > At this meeting, we will be holding an election for a board seat. The > board consists of three seats with staggered terms, such that one seat > comes up for re-election each year (at the fall meeting). This year, > Anthony's seat is up for election. > > As in the past, we will close nominations in advance of the meeting so > people have a chance to instruct a proxy appropriately. *Nominations > will be open for two weeks (so until the end of September 28).* > > If we end up with only one person running (like last time), then > voting is a formality. But if we end up with a contested election, we > will need to vote. I don't know of a good way to do secret balloting > by Google Meet, nor am I particularly familiar with separate services > to do the same. Suggestions are welcome if you don't like the > following plan: > > My current plan is to roll call for (public) votes at the meeting to > give people that option, but in practice, I'm guessing people will > want to vote by email for convenience. > > The bylaws state that you send proxies to the Chief Manager (me, > Richard Laager), and electronic means are acceptable. So a simple > email is sufficient: rlaager(a)wiktel.com <mailto:rlaager@wiktel.com> > or, if you prefer, chiefmanager(a)micemn.net > <mailto:chiefmanager@micemn.net> works too. > > If you send me a /vote/ by email (e.g. "We vote for <X>."), I will > treat it as an a proxy appointment, appointing me to vote on your > behalf, but restricted to /only/ the election item and to /only/ vote > for the candidate you expressed. So then at the meeting, I will say > something like, "On behalf of members X, Y, and Z, I cast 1 vote for A > and 2 votes for B." This will provide /some/ anonymization (obviously, > /I/ will know how you voted). > > If you send me a proxy with different instructions (e.g. "We appoint > <Y> to vote for us."), obviously that will be honored as written. > > -- > Richard > -- Richard

Oct. 7, 2020

Re: TDS Peer Down

by Deprez, Rich

I can confirm there was a transport disruption to both 10G's into MICE for us. 1 of the 2 restored shortly after and we're investigating why the second did not restore. Rich Deprez TDS Telecom – IP Network Operations -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Dean Bahls Sent: Saturday, September 26, 2020 5:03 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] TDS Peer Down AT&T had a scheduled maintenance along I94 today.... Yes, during the day on a Saturday. Seems a bit arrogant when they demand maintenance windows during the week IMHO. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke Sent: Saturday, September 26, 2020 3:11 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] TDS Peer Down It looks like there was a transport hiccup on one of the routes coming into Minneapolis from the NW (several members connections bounced). TDS appears to be coming back online with other peers. If you're bilateral, make sure to hit their peering contact directly with issues. On Sat, Sep 26, 2020 at 3:04 PM Keith Wirch <kwirch(a)atomicdata.com> wrote: > > Lost Peering with TDS @ 14:45. For now we have the neighbor shutdown incase flapping happens. > > > > atomic-router#ping 206.108.255.4 > > > > Type escape sequence to abort. > > Sending 5, 100-byte ICMP Echos to 206.108.255.4, timeout is 2 seconds: > > ..... > > Success rate is 0 percent (0/5) > > > > > > > Keith Wirch > Infrastructure Engineer > ---- > Atomic Data® // Safe. Simple. Smart.® > 250 Marquette Avenue > Minneapolis, MN 55401 > Main // 612.466.2000 > Direct // 612.466.2106 > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Sept. 28, 2020

Re: TDS Peer Down

by Dean Bahls

AT&T had a scheduled maintenance along I94 today.... Yes, during the day on a Saturday. Seems a bit arrogant when they demand maintenance windows during the week IMHO. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke Sent: Saturday, September 26, 2020 3:11 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] TDS Peer Down It looks like there was a transport hiccup on one of the routes coming into Minneapolis from the NW (several members connections bounced). TDS appears to be coming back online with other peers. If you're bilateral, make sure to hit their peering contact directly with issues. On Sat, Sep 26, 2020 at 3:04 PM Keith Wirch <kwirch(a)atomicdata.com> wrote: > > Lost Peering with TDS @ 14:45. For now we have the neighbor shutdown incase flapping happens. > > > > atomic-router#ping 206.108.255.4 > > > > Type escape sequence to abort. > > Sending 5, 100-byte ICMP Echos to 206.108.255.4, timeout is 2 seconds: > > ..... > > Success rate is 0 percent (0/5) > > > > > > > Keith Wirch > Infrastructure Engineer > ---- > Atomic Data® // Safe. Simple. Smart.® > 250 Marquette Avenue > Minneapolis, MN 55401 > Main // 612.466.2000 > Direct // 612.466.2106 > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Sept. 26, 2020

Re: TDS Peer Down

by Jay Hanke

It looks like there was a transport hiccup on one of the routes coming into Minneapolis from the NW (several members connections bounced). TDS appears to be coming back online with other peers. If you're bilateral, make sure to hit their peering contact directly with issues. On Sat, Sep 26, 2020 at 3:04 PM Keith Wirch <kwirch(a)atomicdata.com> wrote: > > Lost Peering with TDS @ 14:45. For now we have the neighbor shutdown incase flapping happens. > > > > atomic-router#ping 206.108.255.4 > > > > Type escape sequence to abort. > > Sending 5, 100-byte ICMP Echos to 206.108.255.4, timeout is 2 seconds: > > ..... > > Success rate is 0 percent (0/5) > > > > > > > Keith Wirch > Infrastructure Engineer > ---- > Atomic Data® // Safe. Simple. Smart.® > 250 Marquette Avenue > Minneapolis, MN 55401 > Main // 612.466.2000 > Direct // 612.466.2106 > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Sept. 26, 2020

TDS Peer Down

by Keith Wirch

Sept. 26, 2020

Re: MICE port down

by Todd Mueller

Gotcha, thanks. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke Sent: Monday, September 21, 2020 12:27 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE port down If it happens again, you should be able to disable the port on your side and then re-enable it after a minute and the error state should clear. On Mon, Sep 21, 2020 at 12:24 PM Doug McIntyre <merlyn(a)iphouse.net> wrote: > > On Mon, Sep 21, 2020 at 12:21:35PM -0500, Todd Mueller wrote: > >Could someone please check the MICE port for Velocity Telephone, I > >saw it go down about 15 minutes ago. > > > >I suspect it shut down because there was more than 1 MAC address coming in. > >I noticed the MAC address for a layer 2 interface from one of our > >switches showing up in the corresponding VLAN momentarily for some > >reason, but it is gone now. > > Yes, it was a MAC address security violation. I assume it'll be fine > to post it, so you can find what one is causing you grief. > > Sep 21 12:02:46 core-sw0 PortSec: %PORTSECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 64:9e:f3:ec:b9:73 on vlan 1 interface Ethernet4/21. > Sep 21 12:02:46 core-sw0 Ebra: %ETH-4-ERRDISABLE: portsec error detected on Ethernet4/21. > Sep 21 12:02:46 core-sw0 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on > Interface Ethernet4/21 (15250 - Velocity Telephone), changed state to > down Sep 21 12:02:46 core-sw0 Stp: %SPANTREE-6-INTERFACE_DEL: > Interface Ethernet4/21 has been removed from instance Vl1 > > I cleared the error from the port. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Sept. 21, 2020

Re: MICE port down

by Todd Mueller

Thanks Doug, I will try to track down what the deal is. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Monday, September 21, 2020 12:25 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE port down On Mon, Sep 21, 2020 at 12:21:35PM -0500, Todd Mueller wrote: >Could someone please check the MICE port for Velocity Telephone, I saw >it go down about 15 minutes ago. > >I suspect it shut down because there was more than 1 MAC address coming in. >I noticed the MAC address for a layer 2 interface from one of our >switches showing up in the corresponding VLAN momentarily for some >reason, but it is gone now. Yes, it was a MAC address security violation. I assume it'll be fine to post it, so you can find what one is causing you grief. Sep 21 12:02:46 core-sw0 PortSec: %PORTSECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 64:9e:f3:ec:b9:73 on vlan 1 interface Ethernet4/21. Sep 21 12:02:46 core-sw0 Ebra: %ETH-4-ERRDISABLE: portsec error detected on Ethernet4/21. Sep 21 12:02:46 core-sw0 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet4/21 (15250 - Velocity Telephone), changed state to down Sep 21 12:02:46 core-sw0 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Ethernet4/21 has been removed from instance Vl1 I cleared the error from the port.

Sept. 21, 2020

Re: MICE port down

by Jay Hanke

If it happens again, you should be able to disable the port on your side and then re-enable it after a minute and the error state should clear. On Mon, Sep 21, 2020 at 12:24 PM Doug McIntyre <merlyn(a)iphouse.net> wrote: > > On Mon, Sep 21, 2020 at 12:21:35PM -0500, Todd Mueller wrote: > >Could someone please check the MICE port for Velocity Telephone, I saw it go > >down about 15 minutes ago. > > > >I suspect it shut down because there was more than 1 MAC address coming in. > >I noticed the MAC address for a layer 2 interface from one of our switches > >showing up in the corresponding VLAN momentarily for some reason, but it is > >gone now. > > Yes, it was a MAC address security violation. I assume it'll be fine > to post it, so you can find what one is causing you grief. > > Sep 21 12:02:46 core-sw0 PortSec: %PORTSECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 64:9e:f3:ec:b9:73 on vlan 1 interface Ethernet4/21. > Sep 21 12:02:46 core-sw0 Ebra: %ETH-4-ERRDISABLE: portsec error detected on Ethernet4/21. > Sep 21 12:02:46 core-sw0 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet4/21 (15250 - Velocity Telephone), changed state to down > Sep 21 12:02:46 core-sw0 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Ethernet4/21 has been removed from instance Vl1 > > I cleared the error from the port. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Sept. 21, 2020