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:
> 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.