I haven't read up on the solution specifics but I'm guessing the PFC requirements is for East-West storage replication/communication between servers. You could use a datacenter switch that only handles this traffic while using Meraki for the host/VM network traffic. Even if it were supported on an enterprise core or access switch, I'd probably avoid it anyway given the need for large buffers and very fast ASIC's. PFC on slow(er) switches or across multiple hops can cause huge performance issues that are just awful to troubleshoot. ... View more

I haven't seen any documentation suggesting that support is present or is planned. I would say it doesn't align with Meraki's typical target market.   PFC is most commonly used for FCOE which you'll primarily find on datacenter switches rather than enterprise core and edge. ... View more

Seems correct. The VLAN number itself shouldn't matter, so long as you're tagging the incoming VPLS traffic onto the right VLAN so it can hit the SVI. ... View more

Your main issue I can see is that both MX's will use the same external port for Meraki client VPN, so unless you have multiple external IP's, there's no way you can get both VPN's working from the same IP. Is the issue here that you have users who are configured to VPN to Site-A that you don't want to re-configure for Site-B, or are you just trying to avoid changing the IP on the server? ... View more

Looks like you've got the parameters correct. Potentially your JSON body is malformed (end of line character or other hidden character causing issues)? I just did a quick test using Postman. PUT: .../v1/networks/<NetworkID</clients/<clientID>/policy Body: {     "devicePolicy": "Group policy",     "groupPolicyId": "100" } Response: {     "mac": "<Mac Address>",     "groupPolicyId": "100",     "devicePolicy": "Group policy" } ... View more

It looks like you haven't specified "devicepolicy" in the body.   Device Policy The policy to assign. Can be 'Whitelisted', 'Blocked', 'Normal' or 'Group policy'. Required.   Assumedly for your API call, it should be set to "Group policy" ... View more

Meraki MX devices are security gateways. Only 1 is allowed in each Meraki network. You won't be able to add a second one unless it is acting simply as a backup to the primary one - (see hot spare).   What are you trying to achieve with the second MX? ... View more

Good find. Certainly better than having to re-run cables. ... View more

I thought that might be the case given MiM for HTTPS inspection is beginning to get steered away from. That said another service means another additional cost 😞  ... View more

This is typically seen when devices go into power saving mode. The following thread has some additional detail Switch port change link speed - The Meraki Community ... View more

No, port-channels are not configurable on MX devices. The MX does however pass through STP packets so you can connect 2 cables to the same network. One will be brought down (due to STP loop prevention) but can be used as a backup if the primary connection fails. ... View more

In that case, to keep the network traffic on the Mikrotik switch, you'll need to create a VLAN interface on the Microtik switch for the VLAN's and set it as the default gateway instead.  Otherwise you can connect both the NAS and the client on the same VLAN. In theory you can also  ... View more

For the traffic flow you described, it sounds like the default gateway for VLAN 4 or VLAN 12 (or both) reside on the upstream MX. ... View more

You're bang on that CRC's are a Layer 1 or Layer 2 issue. Most commonly it's dirty/loose/broken cables, or occasionally a bad SFP/switchport. It can also be due to MTU mismatch. If it's a 10Gb fiber link, interference is highly unlikely as fiber is relatively unaffected by RF as opposed to copper. In terms of the consistency in timing, a couple of things to note are:  - Higher CRC counts will generally correlate with higher network traffic (more packets = more likely for one to be corrupted). Is it possible that at these times the link had a higher utilization in general?  - Do you have any scheduled traffic around those times where higher MTU data is being sent (and where a mismatch might be present in the network)? In any circumstance, I would definitely suggest starting with swapping out the cable and continue troubleshooting up the stack from there. ... View more

You won't find an official document as it's 'technically' not supported, but generally speaking Cisco SFP's will work. ... View more

According to Meraki's SFP Datasheet, it is supported (bottom of the first page) meraki_datasheet_sfp.pdf (cisco.com)     ... View more

It's likely that there would be some small performance impact from enabling detailed traffic analysis but I personally haven't noticed anything. That said, my networks have a fair bit of capacity overhead so utilization isn't a noticeable problem.   With basic analysis, you can see the categories of traffic but get no further breakdown. With detailed analysis, you can see a breakdown of classified traffic into destination hostnames/IP's of each flow. An example view of the detailed traffic analysis is in the image in the below link. Switch Traffic Analytics - Cisco Meraki ... View more

Enabling MFA for a user is done in the dashboard by clicking your account name (top right) and going to profile.  To enforce MFA for the organization, go to Organization -> Settings.   As for logging, all event logging for a given network is under Network-Wide -> Event Log. You can then use filters there to narrow down what you're looking for. If you have a specific client in mind, you can also select the client from Network-Wide -> clients and click "event log" or "timeline". Edit: It just occurred to me you we looking specifically at client VPN. Meraki client VPN doesn't natively support MFA but can incorporate 3rd party solutions Two-Factor Authentication - Cisco Meraki The above info about logging is still applicable for VPN connections, you would just filter to event type. ... View more

Ok Perfect. That makes much more sense now. I had an automatic upgrade notification for a different site but it looks like that's because it has an MX75 and is getting moved from an early-stage beta release to a stable release.   Thanks @cmr  ... View more

Adding to @KarstenI 's reply. The firewall rule you've got in the screenshot is for SSH connections initiated inside your network with a destination of 1.2.3.4. It does not apply to SSH connections inbound from 1.2.3.4.   If you have inbound connections from specific IP's that you want to port forward, you can apply them in the port forwarding rule under "Allowed Remote IP's" ... View more

Right, that makes sense. I manually configured an upgrade for the switch and I can see it now set as an option. The remaining question is: With the current configuration, will the switch and MX be automatically upgraded if I leave them? I would have expected the MX to have automatically upgraded by now since the stable release available is from August.   ... View more

For Meraki switches, the different models generally coincide with features and port speed.  So which model you opt for generally depends on your architecture and need for various features. MS12x are perfectly suitable for L2 switching with no frills. MS2xx introduce physical stacking and routing MS3xx and MS4xx move into higher bandwidth and multigig territory https://meraki.cisco.com/product-collateral/ms-family-datasheet/?file   Within the models, you also need to look at the different amounts of power available for PoE+ output to connected AP's.   Generally speaking, your bottlenecks will always be the WAN connection from the MX rather than bandwidth across the switch, so a switch upgrade may not do anything to improve file transfers if they're going cross-site. ... View more