December 2019 - mice-discuss - lists.micemn.net

Re: MICE graphs - gap from today?

by Justin Krejci

US Internet experienced a server storage issue that affected the cacti server. Unfortunately the data in that time span was not captured and saved. [☹] ________________________________ From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Andrew Hoyos <hoyosa(a)GMAIL.COM> Sent: Tuesday, December 3, 2019 7:00 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MICE graphs - gap from today? Hi folks, Looks like the Cacti graphs are showing a gap from this afternoon. Anyone know what happened? — Andrew Hoyos hoyosa(a)gmail.com<mailto:hoyosa@gmail.com> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 4, 2019

MICE graphs - gap from today?

by Andrew Hoyos

Hi folks, Looks like the Cacti graphs are showing a gap from this afternoon. Anyone know what happened? — Andrew Hoyos hoyosa(a)gmail.com <mailto:hoyosa@gmail.com>

Dec. 4, 2019

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Brady Kittel

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(a)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 >

Dec. 4, 2019

Re: Internet Wether Report

by Jeremy Schmeichel

Interesting. Halo: Reach released today for the PC at 10AM PST and is delivered via Steam, so I’d assume that was related to the Akamai traffic spike. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Gary Glissendorf Sent: Tuesday, December 3, 2019 1:20 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Internet Wether Report Thanks for the update. I saw Akamai and Edgecast blow up our links to them. 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<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of David Farmer Sent: Tuesday, December 3, 2019 1:31 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Internet Wether Report CAUTION: This email originated from outside of SDN Communications. Exercise caution when opening attachments or clicking links, especially from unknown senders. Anyone notice the somewhat impressive approximately 100G traffic spike on MICE just after 12 noon today, I'm told that is Halo for XBox One. https://www.express.co.uk/entertainment/gaming/1211738/Halo-Reach-Release-D… -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ________________________________ 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 CONFIDENTIAL: This email and any files transmitted with it are confidential and intended solely for the use of Vast Broadband/NTS and to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. CONFIDENTIAL: This email and any files transmitted with it are confidential and intended solely for the use of Vast Broadband/NTS and to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Dec. 3, 2019

Re: Internet Wether Report

by Gary Glissendorf

Thanks for the update. I saw Akamai and Edgecast blow up our links to them. 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 David Farmer Sent: Tuesday, December 3, 2019 1:31 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Internet Wether Report CAUTION: This email originated from outside of SDN Communications. Exercise caution when opening attachments or clicking links, especially from unknown senders. Anyone notice the somewhat impressive approximately 100G traffic spike on MICE just after 12 noon today, I'm told that is Halo for XBox One. https://www.express.co.uk/entertainment/gaming/1211738/Halo-Reach-Release-D… -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ________________________________ 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. 3, 2019

Internet Wether Report

by David Farmer

Anyone notice the somewhat impressive approximately 100G traffic spike on MICE just after 12 noon today, I'm told that is Halo for XBox One. https://www.express.co.uk/entertainment/gaming/1211738/Halo-Reach-Release-D… -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 3, 2019

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