The error disable takes 1-2 seconds to clamp down and disable the
port. This results in a short, but severe, broadcast storm.

The churn rate on members changing mac addresses is fairly low.

I agree that we should automate the process so it can be done via
self-service by the members.

On Mon, Oct 31, 2022 at 8:59 AM Steve Howard <[log in to unmask]> wrote:
>
>
> Below is a message indicating the current policy as decided by the MICE Board in December 2019 is that the MAC address limit is 1.
>
>
> The subject of Jay's message indicates "Static" MAC, but, the text seems to indicate a limit of 1.  I like the 1 address limit, but, am not a fan of Static.  Was the current issue caused by somebody not having a proper MAC address limit installed?
>
>
> On 12/13/19 18:00, Richard Laager wrote:
>
> The board has approved the change in MAC address limit from 5 to 1.
>
> NOTE: This is orthogonal to the dedicated remote switch question, which
> is still pending. Non-dedicated remote switches can, for example,
> enforce this per-VLAN.
>
> We have already confirmed that most participants are using only 1 MAC
> address, and some that were using more than 1 have addressed that after
> being contacted. As discussed below, this change will be rolled out in a
> way to keep everyone working, by grandfathering if necessary.
>
> On 10/28/19 3:25 PM, Richard Laager wrote:
>
> We have discussed this a bit in the past, and this came up at the last
> UG. I'm looking for feedback from the group before formally proposing
> this to the board for a vote.
>
> I first brought this up to the technical committee, CCing the board. I
> have heard no objections. Jeremy is "in favor of it 100%".
>
> Based on our quick conversation after the UG, I _think_ Anthony is in
> favor as well; we both made notes to follow up on this.
>
> -----
>
> I am proposing that MICE change its MAC address limit from 5 MACs per
> port to 1 MAC per port. 1 MAC address is enough for normal scenarios and
> this would further limit the potential for problems on the fabric. This
> restriction is one that SIX and AMS-IX both have, with the latter being
> known for their excellent configuration guide for participants:
> https://www.ams-ix.net/ams/documentation/config-guide
>
> To be clear, this is still only for end ports, not ports facing remote
> switches, of course. The remote switches are responsible for enforcing
> the current MAC limit, and would be responsible for changing those
> settings as described here.
>
> If someone is swapping their MICE-facing router, the resulting port flap
> on the MICE/remote switch will clear the limit anyway, if they are
> directly connected. If they are unable to flap the port (e.g. because
> they have someone else's layer 2 gear in the middle), they will have to
> either work with that carrier or their switch operator (MICE/remote) to
> flap the port. This is a non-zero burden, but I think it's pretty
> minimal in practice. Additionally, if someone plans to make an equipment
> swap, we would increase the limit in advance, temporarily, upon request.
>
> For reference, SIX goes further and locks you to a particular MAC
> address in an ACL, so you have to contact them to change your MAC. I am
> not proposing that. Still, I've been through that a couple of times, and
> even that isn't really too big of a deal. So I don't think the change to
> a limit of 1 MAC at MICE will be particularly onerous.
>
> There are a couple of participants who have two IP address sets (one
> IPv4 and one IPv6) on the same port. For those ports, the limit
> obviously must be at least 2 MACs, but I propose 3 MACs as the limit. If
> they're using two IPs, they probably are doing so to get some redundancy
> out of it. For this particular use case, needing to flap the port
> defeats that redundancy goal, as it breaks the other router. Having a
> MAC limit of 3 would allow them to swap a device without needing to flap
> the port. We would grandfather these setups until they are looking for a
> port-type upgrade; at that point they would need to get to one IP
> address set per port (by splitting into two ports or reducing to one IP
> address set) or request an exception as outlined below. The exception
> process would allow us to better evaluate this use case at that time.
>
> There are some members who have multiple MACs showing up now, despite
> using only one device. For those, I am proposing we set the MAC limit to
> however many MACs are currently showing up on their port. That is, they
> would be grandfathered at their current situation for now. At the time
> of this change, we would encourage them to investigate and fix the
> multiple MACs issue at their leisure. In the future, if they are doing a
> equipment swap (especially like-for-like), we would again encourage them
> to address it, but would otherwise leave their higher limit in place. If
> they do a port-type upgrade, we would not bring the grandfathering over.
> If they needed, they could ask for an official exception at that time.
>
> There may be cases where people cannot reasonably fix their routers to
> use only 1 MAC, other scenarios I haven't considered, or things that may
> come up in the future. For that reason, I think we should allow for the
> possibility of exceptions upon request to the board. In practice, I
> would expect the board would confer with the technical committee and/or
> the technical committee would be bringing these to the board anyway. The
> goal is to strike a reasonable balance between protecting the fabric
> without preventing networks from connecting.
>
>
>
>
> On 10/31/22 08:27, Jay Hanke wrote:
>
> 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.
>
>
>
> ________________________________
>
> 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
[log in to unmask]
Phone  612-204-0000