Here's my understanding... The MX67 and Z3 count towards the site-to-site VPN number (and if you need to calculate the number of tunnels if you are using dual WAN/internet connections) The Windows 10 VPN client counts towards the maximum client VPN tunnels, and the 500 client devices (since they are both a client, and they are establishing a VPN tunnel) The recommended number of client devices is the number of devices on the 'inside' of the MX, so pretty much the devices that are listed when you look on the Network-wide -> Clients page of a network I believe other than the 'Max concurrent site-to-site VPN tunnels' they are all recommendations and your mileage will vary depending upon traffic flows and the other features you have enabled on the device. Any VPN terminations have a high impact on performance due to the encryption/decryption that the processor has to do.   Best approach is to monitor the appliance utilisation, under the organisation -> summary reports -> then select the appropriate appliance network, and when you start seeing utilisation consistently getting towards the 80% mark then I'd start planning the upgrade. ... View more

You’ll still see the apps, group policy doesn’t remove them. You need to test them and see if they work... ... View more

I'm going with @cmr being correct... ... View more

Yes, its possible but you have to rely on RSTP itself to block one of the links, as you know there is no link aggregation on the MX devices. Although the MX doesn't participate in RSTP it will forward BPDUs.   Configure another port on the MS355 stack the same as the one currently connected to the MX, and likewise on the MX configure another port that is identical to the one connecting to the MS355 stack, and then put a cable between them.   BPDUs will be sent up the links, forwarded by the MX, and then down the other link back to MS355 stack. On receiving its own BPDUs the MS355 stack will block one of the ports based on the interface/port number (which goes towards determining the superior BPDU), so one of the ports will be blocked, and the other will become designated. Then if you experience a failure BPDUs will cease to be received on the blocked port and it will move into the designated state.   Couple of points: the ports will ideally need to be trunk ports on the MS. Ensure RSTP is enabled on the MS. If they are access ports then they'll run PortFast by default which will cause an initial issue, but it should recover. You shouldn't need to run Loop Guard or Root Guard, and you definitely don't want BPDU Guard on the ports. ... View more

Tricky one this week 😀 ... View more

I’d have the native VLAN as the Meraki management network, which will also be the one that RSTP runs over (if the network is all Meraki, doesn’t need to be VLAN 1, RSTP just runs untagged on a trunk, technically it has no VLAN assigned). The management VLAN being native also makes things easier when the switch first boots, as it will look for connectivity to the Dashboard on an untagged network first. Then you just have one other VLAN for your transit network.   Just one other comment, in the Meraki network all switches pass all VLANs, and all trunks carry all VLANs initially, so if you really want to keep VLAN 10 and 20 out of your data centre you’ll need to prune them off of the trunk - same applies for VLAN 100 and 200 (keeping them out of head office). ... View more

@whistleblower personally I’d go with plan-1. For a network this size I’d try and keep dynamic routing out of it and if you can achieve your high availability goals using LACP then that’s likely to give you less problems. Dynamic routing has its place - where you expect to add or remove subnets and that would cause a lot of changes to static routes - but I probably  wouldn’t use it here.   You’ll probably want to allow for a management VLAN too, which is the one the Meraki switches internal management interface will use to connect to the Dashboard. It is highly recommended (basically don’t do it) that the management interface VLAN for a switch doesn’t have a SVI on the switch itself. So your management VLAN will likely terminate on a router or firewall facing the internet, and would be a second VLAN between the head office and data centre - another reason to use plan-1 (unless you have internet access from both locations).   I’d also consider not using the 192.168.x.x subnets if you can. These are commonly used in home networks and if you start using remote access VPN then you can have issues if someones home IP addresses overlap with these. I’d stick with subnets in the 10.0.0.0/8 or 172.16.0.0/12 range if you can. ... View more

@whistleblower from a practical perspective there is no difference between the LAG types, they both do the same thing and potentially both use the same control protocols - it’s more above how it’s configured. With regards to the traffic hashing, as @GIdenJoe noted, the document I referenced states both source and destination addresses are used, so a connection between the same client and server, on the same ports will always hash to the same path, but the minute one of the parameters change, source or destination addresses or ports the hash will change, and thus potentially the choice of path. ... View more

Just adding a few comments to this thread that may help. Feel free to make comments if you feel that I’ve got something wrong.   You need to follow Crestron’s recommendations and requirements for the network - not only because they won’t support you otherwise, but because NVX is terribly bandwidth hungry (and that’s a whole other conversation) For every encoder on the network you need to ensure there is at least 1Gbps of uplink bandwidth for wherever that traffic needs to go - especially to your RVP if you’re using PIM and multicast routing. So if you have 20 encoders downstream of a core then you’ll need at least 20Gbps of uplink to the core from these. Yes, for a large NVX deployment it can end up being crazy numbers, but that’s what you need. When you consider the above, avoid putting the stream through any MX. The MX devices just replicate multicast traffic to all other ports in the same broadcast domain (there is no IGMP smarts) - my guess, although one of the Meraki team will need to confirm, is that this is done in software. With this replication and the bandwidth of the stream that the NVX encoders produce you’ll likely overwhelm almost any MX to the point of complete meltdown. From what I’ve seen the encoders produce a continual multicast stream whether or not anything is listening to it. So the minute any encoder boots expect to see a huge amount of multicast date on the network. Admittedly this may just be poor configuration of encoders for what I’ve seen, but be aware. (And obviously make sure broadcast/storm controls are set appropriately). Never flood multicast - even if you have only a few NVX encoders on your network and you flood multicast traffic your network will meltdown. The amount of traffic produced by a few of these encoders will easily overwhelm a 1Gbps port if not controlled with IGMP. So you will need IGMP snooping and an IGMP querier on the Layer 3 interface, and PIM-SM/multicast routing if you expect to go across VLANs (i.e. a MX with a Layer 3 interface isn’t going to cut the mustard). As others have said, if the NVX traffic doesn’t need to go somewhere make sure that you prune those VLANs from any trunks that you have. In this regard it’s critical that you understand your STP topology and where that multicast traffic is going. Ironically the MS390 switches appear to do a better job with multicast and IGMP (especially at this scale) than the traditional Meraki switches - it’s just a shame that there are currently so many other limitations with them. I can’t guarantee that this will get the Crestron NVX solution to work every time, but it’s going to give you the best chance of getting it to work. ... View more

The Meraki devices don’t have a Layer 3 LAG, in the same way you can’t make a port a Layer 3 interface. The closest you can get is create an SVI (Layer 3 interface) for a specific VLAN on the switch at each end, and the use a LAG which contains only that VLAN.  The Meraki LAG - which uses LACP - makes use of the IP addresses, MAC and port in its hashing algorithm to determine the member to use, and it not configurable. Please see here, https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Link_Aggregation_and_Load_Balancing. ... View more

@johnnyngena No, if you've a separate Cisco Umbrella subscription purchased with the Cisco Umbrella SKUs then you can integrate your Umbrella Dashboard with your Meraki Dashboard using API keys, see here https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Manually_Integrating_Cisco_Umbrella_with_Meraki_Networks.   If you purchase the MR Advanced license you get four pre-defined (non-customisable) Cisco Umbrella profiles that you can apply to wireless SSIDs. These are predefined and you don't get access to the full Cisco Umbrella Dashboard/product, but it can be useful for some instances - e.g. another malware protection layer, or basic protection and filtering of guest user traffic. See towards the bottom of this page for the pre-defined policies, https://documentation.meraki.com/MR/Other_Topics/Cisco_Meraki_and_Umbrella_Integration_-_MR_Advanced%2F%2FUpgrade_License.  ... View more

In theory if you have a single switch fail in the stack then the stack should continue to operate as a stack, so long as you have stacked the switches in a complete loop (i.e. Sw1 -> Sw2 -> Sw3 -> Sw4 -> back to Sw1). Which means your aggregated ports should remain aggregated. However, you do need to be aware that there is a period of time where the stack re-converges depending on the failure.   With regard to Loop Guard and Root Guard, Loop Guard should be enabled on the trunk ports, but there should be no reason to enable Root Guard. Root Guard is to prevent a switch receiving a superior BPDU on a port. If the switches are all within your control you should be configuring the switch priorities to ensure that you know where the root is. There Meraki recommendations for Loop Guard, Root Guard, etc. are here if you haven't seen them, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices ... View more

I believe the category filtering still uses the BrightCloud feed. You can go to the BrightCloud website to check how a URL is being categorised and it’s reputation. I’m not sure how quickly they update the categories   If you want to block a URL before it gets categorised, you’ll just have to block it with the URL filtering. That should provide a temporary fix until it falls into a proper category. ... View more

Not that I know of. What are you trying achieve? ... View more