 |
 |
I disagree with static MAC address filtering unless we beef up operational ability to change/adjust in a reasonable timeframe, or offer a self service portal to do so (ie IXP Manager implementation first) Sent from my iPhone > On Oct 31, 2022, at 9:59 PM, 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