The last part of the doc is actually incorrect. You don't need to unbind anything to add a MG into a bound network. Steps to get it done are this. I also created a video walking through it.   1. Ensure your template supports the MG device type which is outlined in this section of the doc. More recently created combined templates should already have MG, MV, MT device groups in them. 2. Create new MG network 3. Bind that MG network to your template (requires step 1 to be completed) 4. Optional, combine the previous MX, MS, MR network with the new MG network into one bound combined network ... View more

As mentioned here if you need to set a static IP on a MX you can use the local status page accessible by the dedicated mgmt port (if your MX model has one) or connect a laptop to a LAN port.   After initial setup you no longer use any LAN port in Concentrator mode. Reference   Mgmt of any MX regardless of mode is via the WAN port(s) talking to dashboard.   At a branch a guest tunneled SSID looks like this example config. In my example VLAN 600 only exists in the DMZ and the upstream edge MX. The DMZ MX is what places the tunneled guest onto the (local to the DMZ MX) VLAN.   And yes your DHCP server, whatever it is, needs to be scoped to have enough IPs for all guests.   And yes in Concentrator mode the HA VRRPs go out on the WAN interface. Again, you don't use any LAN ports.   All that said, is your branch using a MX appliance and if so is it doing AutoVPN back to the same guest anchor MX? If so, this likely won't work as outlined in this doc mentioning the double tunnel problem.   Also, is there a specific reason to tunnel guests back to a central location? The far easier way to provide guest WLAN in Meraki is by using NAT mode. Guests are segmented from corp devices, P2P isolation is enabled, no need to manage any DHCP scopes, and no need for more MXs sitting in a DMZ. ... View more

It would essentially be this. I have this set up in my lab.   I'll attempt to answer all the questions from above.   The VPN MX will only have one IP on the WAN 1 interface. This is the mgmt IP and how it talks to dashboard (of course via upstream NAT). A guest SSID can tunnel via L2 from the AP to the MX and egress onto a L2 VLAN present on the switchport connected to the MX. In my example, that's VLAN 600. That VLAN only exists on the link between the VPN MX and the core switch, and the core switch up to the edge firewall which has the L3 interface and DHCP scope for VLAN 600.   In concentrator mode you don't use the MX LAN ports at all.   As long as there's a route between the AP and MX the tunnel should form over the LAN path.   For your branch question. With a tunneled SSID the addressing works the same way it would with a WLC. The client VLAN only exists at the VPN MX and doesn't need to exist as the edge/branch.   In my example below I have firewall rules in two places. On the guest SSID I use L3 firewall rule deny to Local LAN. The Local LAN object means 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.   Also, at my edge MX I have another rule denying VLAN 600 to the RFC1918 nets. Redundant but it's a failsafe should the MR rule be changed or I want a wired guest.   ... View more

Two options.    Option 1 - Clone the MX68 network and place the MX75 (or whatever MX you move to) in the new network. It will copy all of the config over   Option 2 - Remove the MX68 from the network (with the remove button on the MX page) and then add the MXxx back to this network and it will assume all settings.   The couple of exceptions I can think of that get reset when you do either option is making sure the LAN port mapping aligns as MX models can have different LAN port counts. https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX#Port_Mapping_for_different_MX_models   And, if you have site to site VPN configured I believe it resets back to disabled when you remove a MX from a network or clone a MX network. So, just reenable S2S VPN if needed. ... View more

Per the doc    "It is recommended that Root Guard be applied to ports connecting to neighboring, downstream switches that should not be the Root Bridge, to prevent a superior BPDU from being received on the port and causing the election of an unexpected Root Bridge." ... View more

Do you mean a MV connected directly to a LAN port of a MG or just MV(s) on a LAN with the MG being the upstream WAN connection? Performance over cellular is going to depend on your connection quality/speed. ... View more

When you say "The RF scanners in the other warehouse do not have the consistent disconnects and use the same PSK." are those the same model APs and scanners? And if yes, is there a config difference between those APs are your problematic warehouse site? ... View more

Tags for what? Networks, devices, clients? You should be able to edit (add/delete) any tags on whatever page you're on. ... View more

When API is enabled and a key is created per account each admin has a unique API key. That key has the same permissions as the user. ... View more

A simple L2 roam should be the fastest and most reliable. Your issue is likely around the SSID RF config. Can you post your RF profile config for these APs?   Also, have you opened a Support case? ... View more

I can see they're rebooting. You need to engage Support. ... View more

Yes and it worked as advertised in my experience ... View more

MS120-8FP is not a layer 3 switch. So, in this design you'll need to put all the L3 interfaces on your MX and use your switch has basic L2 transport.   So, make port 1 on the switch a trunk. Create the L3 interfaces/subnets on the MX. I assume the /30 to the main site is just a LAN type link essentially? What traffic will take that route? You'll need static(s) on the MX to send traffic destined for the main site to the next hop 10.1.1.1 (guessing that's the IP of the far end). ... View more