I agree with Richard that we shouldn't put the board in the position up have to make judgement calls on a case by case basis. I'd rather see clear guidelines be established along with good language around when a misbehaving member port can be shutdown for non-compliance that provides the board with a reasonable level of latitude with regard to enforcement. 

I don't think it's good practice to put board members in that position either as it may expose them to some level of legal liability if their judgement call is later challenged versus basing decisions on guidelines that were approved by a majority of members. None of this would prevent amendments to those guidelines from being voted on later either so I'd look at this as an effort at getting it reasonably correct initially fully expecting to tweak and refine things later as issues are encountered with the language or things aren't totally clear.


-Brady Kittel
HCMC

On Tue, Dec 3, 2019, 10:46 AM Steve Howard <showard@paulbunyan.net> wrote:


On 12/03/2019 03:34 AM, Richard Laager wrote:
On 12/2/19 10:30 AM, Steve Howard wrote:

If supported by the remote switch, enforce a specific MAC address
requirement on the MICE VLAN for remote switches.

I'm not 100% sure I follow your example here.

Enforcing a single MAC address is straightforward if the only thing
plugged into the non-dedicated switch (on the "downstream" side) are
routers. But what happens if hypothetically Wiktel and Paul Bunyan want
to exchange an Ethernet circuit VLAN over the CNS switch? The CNS switch
is going to see more than just our router MAC addresses. CNS can't limit
us to one MAC on a per-port basis.

Are you saying that a remote switch would use a layer 2 ACL to limit the
source MAC transmitting into the MICE VLAN while allowing other MACs on
other VLANs? Is this a relatively common feature? Is this something that
you feel would be reasonable to _require_ of a non-dedicated switch?

I was thinking of Cisco's port-security feature for the CNS remote.  That would limit each VLAN to specific mac address(es).  Per Andrew's message, I believe this feature is available from other manufacturers. 

Below is an example config that I installed on the CNS remote for testing.  I think requiring something like this would provide a reasonable balance between protecting the exchange and allowing a switch to be non-dedicated.  Additionally, I'd be in favor of mac-address restrictions on all of the MICE switches whether dedicated or not.

interface Ethernet1/40
  description Test
  switchport mode trunk
  mtu 9216
  switchport port-security maximum 5
  switchport port-security
  switchport port-security mac-address AAAA.AAAA.AAAA vlan 847
  switchport port-security mac-address AAAA.AAAA.AA01 vlan 1067
  switchport port-security mac-address AAAA.AAAA.AA02 vlan 1068
  switchport port-security mac-address AAAA.AAAA.AA03 vlan 1068
  switchport port-security mac-address AAAA.AAAA.AA04 vlan 1068


To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1


To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1