- mice-discuss - lists.micemn.net

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Steve Howard

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Chris Wopat

Hi folks, thanks for the lively discussion so far. A few notes and comments about the more recent technical part of the discussion. In our shared switch scenario, we intend to limit mac addresses per our downstream customers on the MICE vlan itsself, not per physical interface. This seems fairly standard, we would hope that as many as possible are already doing this. We would advocate this as a requirement for all customer-facing ports on all switches, remote or otherwise, dedicated or not dedicated. We would also welcome an mac limit on the Arista Core set to something reasonable facing us and other remote switches as well. The current non-remote switch limit of 5 would work perfectly fine in our scenario. Perhaps a limit per remote switch based on N+something should also be enforced as long as it's not a large burden on the MICE operators. We also use BGP session culling, it's deactivated by default. We'd activate on the MICE vlan during maintenance. #### Junos config example for mac limits #### interfaces { ae0 { description "WiscNet Router"; unit 100 { description "MICE :RP:"; vlan-id 100; } } et-0/0/25 { description "MICE Arista Core"; unit 0 { family ethernet-switching { interface-mode access; vlan { members 100; } } } } } vlans { vlan-100 { description "MICE Peering"; vlan-id 100; interface ae0.100; inactive: forwarding-options { /* based on https://tinyurl.com/junos-bgp-culling */ filter { input CullBGP-MICE; output CullBGP-MICE; } } switch-options { interface ae0.100 { interface-mac-limit { 1; packet-action drop-and-log; } } } } } As far as graphing per-vlan, this works well on Q5 based systems such as our Juniper QFX10k. This + buffers is part of the reason we chose this platform instead of a cheap Broadcom device. This is also a part of the reason we would prefer to *not* shove a cheap Broadcom/chinaswitch device in the middle. We also support SNMP polling per interface. In our case we'd expose just the MICE interfaces using views. 630 below is a subinterface's snmp ifIndex. 1.10, 1.11, etc are ifOctests, ifUcastPkts, and so on for that interface. This is manual, but with only a handful of interfaces, totally do-able: snmp { view view-mice { oid .1 exclude; oid .1.3.6.1.2.1.2.2.1.10.630 include; oid .1.3.6.1.2.1.2.2.1.11.630 include; oid .1.3.6.1.2.1.2.2.1.13.630 include; oid .1.3.6.1.2.1.2.2.1.14.630 include; oid .1.3.6.1.2.1.2.2.1.16.630 include; oid .1.3.6.1.2.1.2.2.1.17.630 include; oid .1.3.6.1.2.1.2.2.1.18.630 include; oid .1.3.6.1.2.1.2.2.1.19.630 include; oid .1.3.6.1.2.1.2.2.1.20.630 include; } community wiscnet-mice { view view-mice; authorization read-only; } } Cheers, -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Jay Hanke

MICE has had several requests from ethernet transport vendors to hand customers to MICE on individual vlans over a single port. It might be worth looking into a bridge domain offering where MICE pops the tags off and enforces the required security. If this were added MICE would have two types of remote connectivity, full remote switch and MICE transport provider. This service is already available from several of the remotes by stacking a transport switch in front of the remote and breaking the customers out into their own ports. To my knowledge, this setup has been very effective at isolating issues down to a single customer/port. I believe this is supported in newer Arista code but was a bit of a mess to get the graphing and security to to work. If we did something like this the best course of action might be to place a pizza box and do and uplink into the main fabric. Connecting to one of the "local" remote switches is also a very viable option. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Andrew Hoyos

On Dec 3, 2019, at 3:34 AM, Richard Laager <rlaager(a)wiktel.com> wrote: > > 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. Juniper QFX and MX have options for limiting number of mac addresses per logical interface and/or VLAN. A quick scrub of other common vendors (Cisco, Arista) have the same. I wouldn’t see it as unreasonable to *require* a remote switch operator by whatever means necessary to enforce a one MAC address limit on their extension switch per logical participant handoff.

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Richard Laager

On 12/2/19 6:08 PM, Justin Krejci wrote: > I advocate an official MICE position that switch fabric hardware be > dedicated to MICE but allow the board to make exceptions to this > position on a case by case basis, where the requesting entity can plead > a case and provide justification/explanation on why they feel it > necessary to provide remote access via a shared switch fabric, eg as in > this case it would allow WiscNet to provide additional networks to > connect to MICE that otherwise would not, while WiscNet otherwise has a > clean reputation within MICE and nobody has any reason to suspect they > are up to anything shady, and they are intending to use modern hardware > not some ancient 2000's era hunk o junk. The board can then measure the > request and approve or reject the exception request as they deem best > for the exchange using their own prerogative. I think the board is hesitant to go down the road of making judgements based on _who_ is making a proposal. Treating all participants equally has been a very high priority. The "who", in terms of organization, can change through acquisitions. I realize that's not going to be the case with an organization like WiscNet, but we already saw this with the Neutral Path remote. The "who", in terms of people, can also change through staffing changes. -- Richard

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Richard Laager

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? -- Richard

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Justin Krejci

I advocate an official MICE position that switch fabric hardware be dedicated to MICE but allow the board to make exceptions to this position on a case by case basis, where the requesting entity can plead a case and provide justification/explanation on why they feel it necessary to provide remote access via a shared switch fabric, eg as in this case it would allow WiscNet to provide additional networks to connect to MICE that otherwise would not, while WiscNet otherwise has a clean reputation within MICE and nobody has any reason to suspect they are up to anything shady, and they are intending to use modern hardware not some ancient 2000's era hunk o junk. The board can then measure the request and approve or reject the exception request as they deem best for the exchange using their own prerogative. As the request for remote switches is a fairly low volume in the first place and the request for remote switches that would be deployed as a mixed use switch is even lower, I suspect this would not cause an undue burden on the board to handle requests of this nature. The board can easily dismiss frivolous requests, citing the relevant MICE policy. I feel this would provide continuing good network stability as I agree that dedicated hardware would be less susceptible to problems stemming from mixed use conditions but still allowing the best benefit to the exchange as a whole by allowing it to happen with control when it makes sense. The requesting entity still needs to go through the regular process of discussion on the list and what not as well, it would just need the extra step of being pre-screened by the board for shared use fabric switches. ________________________________ From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Gary Glissendorf <Gary.Glissendorf(a)SDNCOMMUNICATIONS.COM> Sent: Monday, December 2, 2019 4:27 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches SDN would be in support of a 1 mac per external interface from the a participant connected at the Core or a connected to a Remote switch. A standard practice is to isolate any broadcast chances leaving a providers network put placing a point-point subnet or point-point VLAN on the interfaces directly leaving the network. But in the case of connecting to a Exchange and the need to support connectivity into a L2 topology the opportunities is broadcast loops/storms does increase. SDN was a early participant in the Exchange and I recall outages that we started minimizing traffic that was traversing the exchange. In the recent years the exchange has become a important source for content and keeping the network stable and secure is a benefit to all of the participants. Gary Glissendorf | Network Architect gary.glissendorf(a)sdncommunications.com 2900 W. 10th St. | Sioux Falls, SD 57104 (w) 605.978.3558 | (c) 605.359-3737 | (tf) 800.247.1442 SDN NOC 877.287.8023 NOC Support email: sdnsupport(a)sdncommunications.com “Ausgezeichnet Zueinander Sein” [cid:image001.jpg@01D27592.E0CCAA30] <http://www.facebook.com/sdncommunications> [cid:image002.jpg@01D27592.E0CCAA30] <http://twitter.com/sdncomm> [cid:image003.jpg@01D27592.E0CCAA30] <http://plus.google.com/107192460129695945716/posts> [cid:image004.jpg@01D27592.E0CCAA30] <http://www.linkedin.com/company/sdn-communications> [cid:image005.jpg@01D27592.E0CCAA30] <http://www.youtube.com/user/sdncomm> From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Monday, December 2, 2019 4:13 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches CAUTION: This email originated from outside of SDN Communications. Exercise caution when opening attachments or clicking links, especially from unknown senders. One reason I am very much in favor of dedicated hardware is isolation of the unknown. As any seasoned network professional knows, things rarely fail in a way that you expect. The more complicated things are, the more likely that unintended things can happen, especially in the case of a failure, and the more functions a piece of equipment is doing the more widespread the failure. I think those of us that have been on MICE for some time can even remember some examples. The one that comes to mind is when the MICE core was 100% Juniper. We would have IX wide outages caused by the Juniper switches flooding everyone’s ports to capacity with other member’s unicast traffic. This was obviously not a feature, user error, or a setting in the switch. On at least one occasion a software update was done that specifically stated it fixed the bug, and unfortunately it did not. Some of these Juniper switches are still in operation in the MICE core for the 1G ports. Since the switches were connected with proprietary Juniper stacking cables, they acted as one amplifying the problem. The switches still have the unicast flooding problem 1-2 times per year. The difference is that it is isolated to those 1G members, so it is not as noticeable since it is isolated, and no longer impacting the majority of members on the IX. We see that the larger networks/CDNs that connect to MICE always request as much diversity as possible whether it be on separate linecards, or switches. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Ben Wiechman Sent: Monday, December 02, 2019 2:18 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches My concern would be protecting the integrity of the exchange. Just because there have been no issues, doesn't mean there will be no issues at some point. This doesn't necessarily require dedicated hardware, nor does dedicated hardware necessarily guarantee this. A request to disclose practices in place today sent to those that currently maintain shared extension switches would be a good starting point in achieving a better understanding of the potential risks and help identify potential best practices that are already in place in addition to the suggestions already offered by Steve. Ben Wiechman Director of IP Strategy and Engineering 320.247.3224 | ben.wiechman(a)arvig.com<mailto:ben.wiechman@arvig.com> Arvig | 224 East Main Street | Melrose, MN 56352 | arvig.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2farvig.com&c=E,1,Y6eUwUEC…> On Mon, Dec 2, 2019 at 12:09 PM Jeremy Lumby <jlumby(a)mnvoip.com<mailto:jlumby@mnvoip.com>> wrote: In my opinion the single MAC address per participant facing MICE is the most important requirement for the protection of MICE. I feel it is so important that I had contacted the board/received approval so that I could restrict my extension switch to 1 MAC address per participant regardless of if MICE requires it or not. I think short term exceptions for maintenance/upgrades are fine. I feel that trying to implement the 1 MAC address rule on a shared extension switch would be very problematic (mostly for other traffic that could be going across the same switch). I do not feel that the added cost/complexity of requiring a dedicated extension switch would deter any network from connecting. As an extension switch operator that offers multiple different services I offer MICE completely for free to anyone with no requirements that they connect to anything other than MICE. With this being said they are responsible to getting one connection to me, however once I receive that connection all services are broken out onto separate dedicated hardware free of charge in a manner that would satisfy any IX that allows a connection to anything other than their own core switches. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Steve Howard Sent: Monday, December 02, 2019 10:31 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches I am not in favor of requiring MICE remote switches to be dedicated solely to MICE. I think the proposed policy adds unnecessary complexity and costs (one-time hardware, monthly cross-connects, space at 511, and environmental) for remote switch operators. It also discourages additional membership (WiscNet) and, in my opinion, results in very little real value to MICE. Why institute a policy with real costs to MICE members and not much real value? Sometimes the MICE community seems to worship larger exchanges, most notably, SIX and AMS-IX. MICE should make decisions based upon what is best for MICE. Just because the “big” exchanges do something doesn’t necessarily mean it is best for MICE. We are not SIX. We are not AMS-IX. Sometimes it is better to be a leader at not a follower! I’d rather not have unnecessary rules and burdens. I’m not exactly sure what real problem this proposed rule is trying to solve. But, if there truly is a technical problem here that needs to be solved, I’d like to propose a couple of suggestions for discussion that could help protect the exchange: 1) If supported by the remote switch, enforce a specific MAC address requirement on the MICE VLAN for remote switches. Typically this would be one MAC address on the MICE VLAN, but there are a few cases where an additional MAC would be required. This could create some challenges when changing routers, but, in many cases, these can be resolved with some prior planning. For example: Paul Bunyan uses a switched virtual interface (a Cisco BVI) for its connection to SIX. This gives us the flexibility to move that interface to any device without having to contact people at SIX. Yet, it still gives SIX the protection of a single MAC address per port. MICE could also have a policy to briefly allow an extra MAC address when there is planned maintenance. 2) MICE could institute a “probationary” status for remote switches that have a history of problems at MICE. MICE has had non-dedicated remote switches from its beginning. To the best of my knowledge, this has never caused a problem. However, we’ve all seen the recent history of a single MICE remote switch operator that has had issues with packet loss, apparently slow downtime responses, etc. Fortunately, those problems have only affected their customers. Remote switch operators that have a history of poor performance could have additional requirements placed upon them until they’ve operated well for a period of time. Additionally, if a remote switch operator’s non-dedicated use causes problems at MICE, the remote switch operator could lose the privilege of having a non-dedicated switch. 3) MICE could determine an appropriate level of broadcast traffic and institute broadscast storm control based upon a multiplier of of the typical levels. Disclaimers: I work for Paul Bunyan Communications which connects to MICE via the CNS remote switch; Paul Bunyan is a founder and part-owner of CNS; I help manage the CNS remote switch; I am one of the co-founders of MICE. I try to be loyal to Paul Bunyan, CNS, and MICE. It gets complicated sometimes! ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ***This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.*** ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 3, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Gary Glissendorf

SDN would be in support of a 1 mac per external interface from the a participant connected at the Core or a connected to a Remote switch. A standard practice is to isolate any broadcast chances leaving a providers network put placing a point-point subnet or point-point VLAN on the interfaces directly leaving the network. But in the case of connecting to a Exchange and the need to support connectivity into a L2 topology the opportunities is broadcast loops/storms does increase. SDN was a early participant in the Exchange and I recall outages that we started minimizing traffic that was traversing the exchange. In the recent years the exchange has become a important source for content and keeping the network stable and secure is a benefit to all of the participants. Gary Glissendorf | Network Architect gary.glissendorf(a)sdncommunications.com 2900 W. 10th St. | Sioux Falls, SD 57104 (w) 605.978.3558 | (c) 605.359-3737 | (tf) 800.247.1442 SDN NOC 877.287.8023 NOC Support email: sdnsupport(a)sdncommunications.com “Ausgezeichnet Zueinander Sein” [cid:image001.jpg@01D27592.E0CCAA30] <http://www.facebook.com/sdncommunications> [cid:image002.jpg@01D27592.E0CCAA30] <http://twitter.com/sdncomm> [cid:image003.jpg@01D27592.E0CCAA30] <http://plus.google.com/107192460129695945716/posts> [cid:image004.jpg@01D27592.E0CCAA30] <http://www.linkedin.com/company/sdn-communications> [cid:image005.jpg@01D27592.E0CCAA30] <http://www.youtube.com/user/sdncomm> From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Monday, December 2, 2019 4:13 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches CAUTION: This email originated from outside of SDN Communications. Exercise caution when opening attachments or clicking links, especially from unknown senders. One reason I am very much in favor of dedicated hardware is isolation of the unknown. As any seasoned network professional knows, things rarely fail in a way that you expect. The more complicated things are, the more likely that unintended things can happen, especially in the case of a failure, and the more functions a piece of equipment is doing the more widespread the failure. I think those of us that have been on MICE for some time can even remember some examples. The one that comes to mind is when the MICE core was 100% Juniper. We would have IX wide outages caused by the Juniper switches flooding everyone’s ports to capacity with other member’s unicast traffic. This was obviously not a feature, user error, or a setting in the switch. On at least one occasion a software update was done that specifically stated it fixed the bug, and unfortunately it did not. Some of these Juniper switches are still in operation in the MICE core for the 1G ports. Since the switches were connected with proprietary Juniper stacking cables, they acted as one amplifying the problem. The switches still have the unicast flooding problem 1-2 times per year. The difference is that it is isolated to those 1G members, so it is not as noticeable since it is isolated, and no longer impacting the majority of members on the IX. We see that the larger networks/CDNs that connect to MICE always request as much diversity as possible whether it be on separate linecards, or switches. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Ben Wiechman Sent: Monday, December 02, 2019 2:18 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches My concern would be protecting the integrity of the exchange. Just because there have been no issues, doesn't mean there will be no issues at some point. This doesn't necessarily require dedicated hardware, nor does dedicated hardware necessarily guarantee this. A request to disclose practices in place today sent to those that currently maintain shared extension switches would be a good starting point in achieving a better understanding of the potential risks and help identify potential best practices that are already in place in addition to the suggestions already offered by Steve. Ben Wiechman Director of IP Strategy and Engineering 320.247.3224 | ben.wiechman(a)arvig.com<mailto:ben.wiechman@arvig.com> Arvig | 224 East Main Street | Melrose, MN 56352 | arvig.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2farvig.com&c=E,1,Y6eUwUEC…> On Mon, Dec 2, 2019 at 12:09 PM Jeremy Lumby <jlumby(a)mnvoip.com<mailto:jlumby@mnvoip.com>> wrote: In my opinion the single MAC address per participant facing MICE is the most important requirement for the protection of MICE. I feel it is so important that I had contacted the board/received approval so that I could restrict my extension switch to 1 MAC address per participant regardless of if MICE requires it or not. I think short term exceptions for maintenance/upgrades are fine. I feel that trying to implement the 1 MAC address rule on a shared extension switch would be very problematic (mostly for other traffic that could be going across the same switch). I do not feel that the added cost/complexity of requiring a dedicated extension switch would deter any network from connecting. As an extension switch operator that offers multiple different services I offer MICE completely for free to anyone with no requirements that they connect to anything other than MICE. With this being said they are responsible to getting one connection to me, however once I receive that connection all services are broken out onto separate dedicated hardware free of charge in a manner that would satisfy any IX that allows a connection to anything other than their own core switches. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Steve Howard Sent: Monday, December 02, 2019 10:31 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches I am not in favor of requiring MICE remote switches to be dedicated solely to MICE. I think the proposed policy adds unnecessary complexity and costs (one-time hardware, monthly cross-connects, space at 511, and environmental) for remote switch operators. It also discourages additional membership (WiscNet) and, in my opinion, results in very little real value to MICE. Why institute a policy with real costs to MICE members and not much real value? Sometimes the MICE community seems to worship larger exchanges, most notably, SIX and AMS-IX. MICE should make decisions based upon what is best for MICE. Just because the “big” exchanges do something doesn’t necessarily mean it is best for MICE. We are not SIX. We are not AMS-IX. Sometimes it is better to be a leader at not a follower! I’d rather not have unnecessary rules and burdens. I’m not exactly sure what real problem this proposed rule is trying to solve. But, if there truly is a technical problem here that needs to be solved, I’d like to propose a couple of suggestions for discussion that could help protect the exchange: 1) If supported by the remote switch, enforce a specific MAC address requirement on the MICE VLAN for remote switches. Typically this would be one MAC address on the MICE VLAN, but there are a few cases where an additional MAC would be required. This could create some challenges when changing routers, but, in many cases, these can be resolved with some prior planning. For example: Paul Bunyan uses a switched virtual interface (a Cisco BVI) for its connection to SIX. This gives us the flexibility to move that interface to any device without having to contact people at SIX. Yet, it still gives SIX the protection of a single MAC address per port. MICE could also have a policy to briefly allow an extra MAC address when there is planned maintenance. 2) MICE could institute a “probationary” status for remote switches that have a history of problems at MICE. MICE has had non-dedicated remote switches from its beginning. To the best of my knowledge, this has never caused a problem. However, we’ve all seen the recent history of a single MICE remote switch operator that has had issues with packet loss, apparently slow downtime responses, etc. Fortunately, those problems have only affected their customers. Remote switch operators that have a history of poor performance could have additional requirements placed upon them until they’ve operated well for a period of time. Additionally, if a remote switch operator’s non-dedicated use causes problems at MICE, the remote switch operator could lose the privilege of having a non-dedicated switch. 3) MICE could determine an appropriate level of broadcast traffic and institute broadscast storm control based upon a multiplier of of the typical levels. Disclaimers: I work for Paul Bunyan Communications which connects to MICE via the CNS remote switch; Paul Bunyan is a founder and part-owner of CNS; I help manage the CNS remote switch; I am one of the co-founders of MICE. I try to be loyal to Paul Bunyan, CNS, and MICE. It gets complicated sometimes! ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.iphouse.net%2fcgi-…> ***This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.***

Dec. 2, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Andrew Hoyos

I’d argue that dedicated hardware could fail in an unknown way, just the same as a shared device. To the "MICE Core", the action to fix it would hopefully be the same - sever the connection to the downstream switch and isolate the failure area (whether automated - pps limits for bcast/mcast traffic, mac limits, etc, or manual port shutdown). MICE should enforce certain standards that ensure remote switch operators are following any requirements - same if dedicated hardware or shared hardware. — Andrew Hoyos hoyosa(a)gmail.com <mailto:hoyosa@gmail.com> > On Dec 2, 2019, at 4:13 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > One reason I am very much in favor of dedicated hardware is isolation of the unknown. As any seasoned network professional knows, things rarely fail in a way that you expect. The more complicated things are, the more likely that unintended things can happen, especially in the case of a failure, and the more functions a piece of equipment is doing the more widespread the failure. > > I think those of us that have been on MICE for some time can even remember some examples. The one that comes to mind is when the MICE core was 100% Juniper. We would have IX wide outages caused by the Juniper switches flooding everyone’s ports to capacity with other member’s unicast traffic. This was obviously not a feature, user error, or a setting in the switch. On at least one occasion a software update was done that specifically stated it fixed the bug, and unfortunately it did not. Some of these Juniper switches are still in operation in the MICE core for the 1G ports. Since the switches were connected with proprietary Juniper stacking cables, they acted as one amplifying the problem. The switches still have the unicast flooding problem 1-2 times per year. The difference is that it is isolated to those 1G members, so it is not as noticeable since it is isolated, and no longer impacting the majority of members on the IX. We see that the larger networks/CDNs that connect to MICE always request as much diversity as possible whether it be on separate linecards, or switches. > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Ben Wiechman > Sent: Monday, December 02, 2019 2:18 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches > > My concern would be protecting the integrity of the exchange. Just because there have been no issues, doesn't mean there will be no issues at some point. This doesn't necessarily require dedicated hardware, nor does dedicated hardware necessarily guarantee this. A request to disclose practices in place today sent to those that currently maintain shared extension switches would be a good starting point in achieving a better understanding of the potential risks and help identify potential best practices that are already in place in addition to the suggestions already offered by Steve. > > Ben Wiechman > Director of IP Strategy and Engineering > 320.247.3224 | ben.wiechman(a)arvig.com <mailto:ben.wiechman@arvig.com> > Arvig | 224 East Main Street | Melrose, MN 56352 | arvig.com <http://arvig.com/> > > > > On Mon, Dec 2, 2019 at 12:09 PM Jeremy Lumby <jlumby(a)mnvoip.com <mailto:jlumby@mnvoip.com>> wrote: > In my opinion the single MAC address per participant facing MICE is the most important requirement for the protection of MICE. I feel it is so important that I had contacted the board/received approval so that I could restrict my extension switch to 1 MAC address per participant regardless of if MICE requires it or not. I think short term exceptions for maintenance/upgrades are fine. I feel that trying to implement the 1 MAC address rule on a shared extension switch would be very problematic (mostly for other traffic that could be going across the same switch). > > I do not feel that the added cost/complexity of requiring a dedicated extension switch would deter any network from connecting. As an extension switch operator that offers multiple different services I offer MICE completely for free to anyone with no requirements that they connect to anything other than MICE. With this being said they are responsible to getting one connection to me, however once I receive that connection all services are broken out onto separate dedicated hardware free of charge in a manner that would satisfy any IX that allows a connection to anything other than their own core switches. > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Steve Howard > Sent: Monday, December 02, 2019 10:31 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches > > I am not in favor of requiring MICE remote switches to be dedicated solely to MICE. > > I think the proposed policy adds unnecessary complexity and costs (one-time hardware, monthly cross-connects, space at 511, and environmental) for remote switch operators. It also discourages additional membership (WiscNet) and, in my opinion, results in very little real value to MICE. Why institute a policy with real costs to MICE members and not much real value? > > Sometimes the MICE community seems to worship larger exchanges, most notably, SIX and AMS-IX. MICE should make decisions based upon what is best for MICE. Just because the “big” exchanges do something doesn’t necessarily mean it is best for MICE. We are not SIX. We are not AMS-IX. Sometimes it is better to be a leader at not a follower! > > > I’d rather not have unnecessary rules and burdens. I’m not exactly sure what real problem this proposed rule is trying to solve. But, if there truly is a technical problem here that needs to be solved, I’d like to propose a couple of suggestions for discussion that could help protect the exchange: > > 1) If supported by the remote switch, enforce a specific MAC address requirement on the MICE VLAN for remote switches. Typically this would be one MAC address on the MICE VLAN, but there are a few cases where an additional MAC would be required. This could create some challenges when changing routers, but, in many cases, these can be resolved with some prior planning. For example: Paul Bunyan uses a switched virtual interface (a Cisco BVI) for its connection to SIX. This gives us the flexibility to move that interface to any device without having to contact people at SIX. Yet, it still gives SIX the protection of a single MAC address per port. MICE could also have a policy to briefly allow an extra MAC address when there is planned maintenance. > > 2) MICE could institute a “probationary” status for remote switches that have a history of problems at MICE. MICE has had non-dedicated remote switches from its beginning. To the best of my knowledge, this has never caused a problem. However, we’ve all seen the recent history of a single MICE remote switch operator that has had issues with packet loss, apparently slow downtime responses, etc. Fortunately, those problems have only affected their customers. Remote switch operators that have a history of poor performance could have additional requirements placed upon them until they’ve operated well for a period of time. Additionally, if a remote switch operator’s non-dedicated use causes problems at MICE, the remote switch operator could lose the privilege of having a non-dedicated switch. > > 3) MICE could determine an appropriate level of broadcast traffic and institute broadscast storm control based upon a multiplier of of the typical levels. > > Disclaimers: I work for Paul Bunyan Communications which connects to MICE via the CNS remote switch; Paul Bunyan is a founder and part-owner of CNS; I help manage the CNS remote switch; I am one of the co-founders of MICE. I try to be loyal to Paul Bunyan, CNS, and MICE. It gets complicated sometimes! > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <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 <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 <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 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>

Dec. 2, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Jeremy Lumby

One reason I am very much in favor of dedicated hardware is isolation of the unknown. As any seasoned network professional knows, things rarely fail in a way that you expect. The more complicated things are, the more likely that unintended things can happen, especially in the case of a failure, and the more functions a piece of equipment is doing the more widespread the failure. I think those of us that have been on MICE for some time can even remember some examples. The one that comes to mind is when the MICE core was 100% Juniper. We would have IX wide outages caused by the Juniper switches flooding everyone’s ports to capacity with other member’s unicast traffic. This was obviously not a feature, user error, or a setting in the switch. On at least one occasion a software update was done that specifically stated it fixed the bug, and unfortunately it did not. Some of these Juniper switches are still in operation in the MICE core for the 1G ports. Since the switches were connected with proprietary Juniper stacking cables, they acted as one amplifying the problem. The switches still have the unicast flooding problem 1-2 times per year. The difference is that it is isolated to those 1G members, so it is not as noticeable since it is isolated, and no longer impacting the majority of members on the IX. We see that the larger networks/CDNs that connect to MICE always request as much diversity as possible whether it be on separate linecards, or switches. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Ben Wiechman Sent: Monday, December 02, 2019 2:18 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches My concern would be protecting the integrity of the exchange. Just because there have been no issues, doesn't mean there will be no issues at some point. This doesn't necessarily require dedicated hardware, nor does dedicated hardware necessarily guarantee this. A request to disclose practices in place today sent to those that currently maintain shared extension switches would be a good starting point in achieving a better understanding of the potential risks and help identify potential best practices that are already in place in addition to the suggestions already offered by Steve. Ben Wiechman Director of IP Strategy and Engineering 320.247.3224 | ben.wiechman(a)arvig.com Arvig | 224 East Main Street | Melrose, MN 56352 | arvig.com On Mon, Dec 2, 2019 at 12:09 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: In my opinion the single MAC address per participant facing MICE is the most important requirement for the protection of MICE. I feel it is so important that I had contacted the board/received approval so that I could restrict my extension switch to 1 MAC address per participant regardless of if MICE requires it or not. I think short term exceptions for maintenance/upgrades are fine. I feel that trying to implement the 1 MAC address rule on a shared extension switch would be very problematic (mostly for other traffic that could be going across the same switch). I do not feel that the added cost/complexity of requiring a dedicated extension switch would deter any network from connecting. As an extension switch operator that offers multiple different services I offer MICE completely for free to anyone with no requirements that they connect to anything other than MICE. With this being said they are responsible to getting one connection to me, however once I receive that connection all services are broken out onto separate dedicated hardware free of charge in a manner that would satisfy any IX that allows a connection to anything other than their own core switches. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Steve Howard Sent: Monday, December 02, 2019 10:31 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches I am not in favor of requiring MICE remote switches to be dedicated solely to MICE. I think the proposed policy adds unnecessary complexity and costs (one-time hardware, monthly cross-connects, space at 511, and environmental) for remote switch operators. It also discourages additional membership (WiscNet) and, in my opinion, results in very little real value to MICE. Why institute a policy with real costs to MICE members and not much real value? Sometimes the MICE community seems to worship larger exchanges, most notably, SIX and AMS-IX. MICE should make decisions based upon what is best for MICE. Just because the “big” exchanges do something doesn’t necessarily mean it is best for MICE. We are not SIX. We are not AMS-IX. Sometimes it is better to be a leader at not a follower! I’d rather not have unnecessary rules and burdens. I’m not exactly sure what real problem this proposed rule is trying to solve. But, if there truly is a technical problem here that needs to be solved, I’d like to propose a couple of suggestions for discussion that could help protect the exchange: 1) If supported by the remote switch, enforce a specific MAC address requirement on the MICE VLAN for remote switches. Typically this would be one MAC address on the MICE VLAN, but there are a few cases where an additional MAC would be required. This could create some challenges when changing routers, but, in many cases, these can be resolved with some prior planning. For example: Paul Bunyan uses a switched virtual interface (a Cisco BVI) for its connection to SIX. This gives us the flexibility to move that interface to any device without having to contact people at SIX. Yet, it still gives SIX the protection of a single MAC address per port. MICE could also have a policy to briefly allow an extra MAC address when there is planned maintenance. 2) MICE could institute a “probationary” status for remote switches that have a history of problems at MICE. MICE has had non-dedicated remote switches from its beginning. To the best of my knowledge, this has never caused a problem. However, we’ve all seen the recent history of a single MICE remote switch operator that has had issues with packet loss, apparently slow downtime responses, etc. Fortunately, those problems have only affected their customers. Remote switch operators that have a history of poor performance could have additional requirements placed upon them until they’ve operated well for a period of time. Additionally, if a remote switch operator’s non-dedicated use causes problems at MICE, the remote switch operator could lose the privilege of having a non-dedicated switch. 3) MICE could determine an appropriate level of broadcast traffic and institute broadscast storm control based upon a multiplier of of the typical levels. Disclaimers: I work for Paul Bunyan Communications which connects to MICE via the CNS remote switch; Paul Bunyan is a founder and part-owner of CNS; I help manage the CNS remote switch; I am one of the co-founders of MICE. I try to be loyal to Paul Bunyan, CNS, and MICE. It gets complicated sometimes! 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 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 2, 2019