Combining networks shouldn’t affect anything... the configurations stay the same, it’s just how it appears and how it’s reported in the Dashboard. (Although as with everything I’d do it at a suitable time). ... View more

No, you can just use static routes on the router. The Meraki MS410 doesn't support RIP, you could do OSPF if the router supports it and if you know what you're doing with OSPF, but the easiest option is to just configure static routes on the router pointing towards the MS410 for the relevant subnets. ... View more

I believe this was the way that Meraki networks were designed/configured before the advent of the 'combined' network. Sometimes there are reasons to keep them separate (e.g. client tracking by IP on an MX), but more often than not they can be combined if they are all at a single site.    Under the Networks drop down on the Meraki Dashboard, go to display all networks. Then select the networks you want to combine and hit the Combine button.   https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Combined_Dashboard_Networks provides detail on some of the benefits of Combined networks, and how to combine them. ... View more

>Note too that the multigig ports do not support 10GBase-T.   Yep, this isn't quite correct. Agreeing with Philip, the MS350-24X will do 10GBase-T, and it does state 10Gbps on the datasheet, although not 10GBase-T specifically (although I've deployed them for 10GBase-T and they work). I would expect the MS355 with the mGig ports to behave the same way.   The MS390 switches are different (aren't they always 🙂) - you need to check the datasheet carefully on these - depending on the model some of the ports will only go to 2.5Gbps, some to 5Gbps, and some will go right to 10Gbps (assuming they work the same as the MS350-24X and Catalyst 9300, then I expect this would support 10GBase-T).   Would be good to get clarity on this, as this would trip up a number of people. ... View more

Do you have another switch then, the MS120 is only a Layer 2 switch? I guess you could get a cheap unmanaged PoE switch to go between the APs on the wired side, that's all it should need (it's just Ethernet connecting them from what I can tell, nothing more). ... View more

I believe it should work. As @cmr said you'll lose 50% bandwidth per hop, but you can do multiple hops - what you're describing is about the limit you want to push though, ideally every mesh AP will connect back to a gateway (i.e. a wired AP). The Meraki Mesh design guide is here, https://documentation.meraki.com/MR/Deployment_Guides/Mesh_Deployment_Guide.   I'd see if you can actually get a direct connection from AP3 to AP1 - you might get better performance even if it is at a lower bandwidth (due to distance) than putting the extra hop in the middle. Although that may also need some careful planning to make sure that is the way it meshes. ... View more

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

The Meraki configuration looks fine. Can you ping the router’s IP address (10.15.255.254) from VLAN 300? If no, do you have return routes configured on the router? I.e. something to tell it to reach 10.15.0.0/16 it needs to go via 10.15.255.1?   ... 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

What IP address, subnet mask and default gateway are devices on VLAN 300 getting? How is your DHCP server configured? ... View more

Start without any ACLs (i.e. have only the default Allow rule). Make sure that you can access the internet from all the VLANs that should have access to it, and likewise make sure all the VLANs that should be able to access the data centre can access it. Once you've got this working then you can apply ACLs.    Your ACLs will likely be Deny ACLs like you have, and will Deny Any Source to the IP subnets that represent the data centre (and potentially any other internal networks) for each VLAN that shouldn't be able to access the data centre. Remember that the IP address of the router (10.15.255.254) is not the IP destination address of the traffic, the IP destination address of the traffic will either be the address or a server in the data centre, or a server somewhere out on the internet. ... View more

Do you have any ACLs configured yet? What default gateway are you giving clients that connect to VLAN 300, for instance? ... View more

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

Is 10.15.255.254 the IP address of the router that is connecting to the internet? ... 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

Yep, you’ve got it 😀 ... View more

The document that Philip referenced previously, and this one, https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing, provide the information you require on how to configure Layer 3 interfaces - in the document Philip references, it is the Distribution switch. ... View more