Yes. The remote switch terms cover this for sharing a single MICE uplink. Also, when a problem arises, we can kill a port without doing a packet capture and only the offending member can be shut off. On Wed, Nov 2, 2022 at 3:23 PM David Farmer <0000000e7948cb21-dmarc-request@lists.iphouse.net> wrote:
And if we statically define the MAC to port mapping do we care?
On Wed, Nov 2, 2022 at 3:01 PM Jay Hanke <jayhanke@southfront.io> wrote:
The hard limit is to keep someone from stacking networks behind a port.
On Wed, Nov 2, 2022 at 2:58 PM David Farmer <0000000e7948cb21-dmarc-request@lists.iphouse.net> wrote:
Maybe we don't need to define a hard limit of 1 or 2, but only that the list needs to be static, as in not auto-detected but a defined list; the point is to be able to quash/filter unknown unicast traffic.
On Wed, Nov 2, 2022 at 9:33 AM Jay Hanke <jayhanke@southfront.io> wrote:
What if we raised the maximum number of static mac addresses to 2 (to allow for migrations and to allow Jeremy to sleep) in the mac acl?
On Mon, Oct 31, 2022 at 12:48 PM Mike Johnston <mjohnston@wiktel.com> wrote:
Well articulated, as always, David. Thank you.
I am in favor of the use of static MAC ACL, even if that requires manual changes to that ACL, and the additional coordination that may consume. A few thoughts, though....
Maybe 1G links are exempt from this? Since a couple second switching loop from a 1G port is not as impactful? ????? Thoughts from others, please.
Using a static MAC ACL could make troubleshooting a failure more problematic. For example, replacing a line card to "see if that fixes the issue" could send a tech down a trail of red hearings. Even if the member is fully aware that they need to coordinate the MAC change, this sort work is often being done in response to an unexpected outage. The added time spend on the coordination could be seen as frustrating. But, for some members it's not a big deal, and can use other links until their MICE connectivity is restored.
I've heard that some members are using a virtual MAC address, which is probably the way to avoid needing to coordinate in the first place.
-- Jay Hanke, President South Front Networks jayhanke@southfront.io Phone 612-204-0000
-- =============================================== 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 ===============================================
________________________________
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@southfront.io Phone 612-204-0000
-- =============================================== 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 ===============================================
________________________________
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@southfront.io Phone 612-204-0000