What worked for me was changing the management vlan to your VLAN association for the subnet.  in Switching, Configuaration, Switch Settings, VLAN configuration. ... View more

I think the feature has already been buried 😑 ... View more

The Umbrella > Network Tunnels page should only be referenced for IPsec connectivity today. The Secure Connect-[DC location] tunnels you see on the page are not indicative of any AutoVPN tunnels. For AutoVPN tunnel status, please leverage the Meraki dashboard pages:   Organization > VPN Status (select network) > Security & SD-WAN > VPN Status   We're planning on consolidating both configuration and visibility of Meraki SD-WAN, Catalyst SD-WAN & IPsec implementations into the Meraki dashboard relatively soon. Please reach out to your Cisco reps if you'd like more information. ... View more

If you are only doing Monitoring then there are no specific limitations to the various features available in full blown IOS beyond keeping the requirements for cloud monitoring active. So the answer to your questions is: 1) Yes you can still use TACACS for admin logins 2) Yes you can continue to use other monitoring solutions, just be careful not to interfere with the Meraki configs (they are quite extensive) Cloud Monitoring details here: https://documentation.meraki.com/Cloud_Monitoring_for_Catalyst/Onboarding/Cloud_Monitoring_for_Catalyst_Onboarding_Guide ... View more

Spoke to spoke communication does work. It appears to transit through the Meraki VPN Concentrator (non-Umbrella) hub. ... View more

I got Static Public IP Address from ISP for one of my location and the issue got resolved. ... View more

This is an old chain but I had the same question.  Where is the setting?  Thought about it and wondered, is it possible that your APs are those with network ports on them and you activated a Port Profile or have a device attached to them that joined that SSID? ... View more

Note that the MG21 is having issues (some firmware near future should fix this though)..   MTU size is default 1280 on a MG21. Call support for a patch they can run. So the MG21 will start to use MTU1500. ... View more

if I`d understood the documentation (linked by @PhilipDAth) correct, than the order should be... enroll -> define tags -> create profile -> add settings profile -> apply profile   Solution Deployment Concepts The following key concepts will be helpful in understanding how to set up your Cisco Meraki Systems Manager environment. Thinking about these steps beforehand will simplify initial deployment and ongoing management. Enrollment: When devices enroll into Systems Manager, they give you full device access for setting user restrictions, managing applications, and enabling device visibility and management. Tags: Systems Manager uses tags to verify that the right devices get the right applications, profiles, and restrictions. Tags can be applied manually, automatically, and even dynamically, based on a device’s status. Profiles: Profiles control device configurations and enable or restrict device access, depending on the use case. Applications: Systems Manager enables application delivery and management through public app stores and custom applications hosted in a cloud-based repository. Security: Security-solution sets within Systems Manager include securing the device itself, verifying that only secure corporate applications are installed, and processes to wipe data in the case a device is lost or stolen. Troubleshooting: Systems Manager has built-in tools to troubleshoot mobile and desktop devices. ... View more

but there is an important thing to notice! the difference in using a Group-Policy with Layer3 Firewalling is, that the behavior is stateless while it`s stateful doing it on the firewall page of the Security Appliance! ... View more

@Bruce using the WAN 1 as 802.1q trunk port is it therefore necessary too to define a specific VLAN-ID under the MX uplink settings or will the MX in 1-armed mode use that port as trunk with native/untagged VLAN-ID: 1 anyway? ... View more

No, as it was something critical I didn't take the time to investigate further.   But I've noticed complaints from other members and Meraki never spoke or gave more details. ... View more

so just as I had already thought! no matter how many different entries are defined in one rule, it`s an OR behavior and the entries are not dependent on each other! hm, hasn't any of you had such a requirement so far? ... View more

It will send all networks that have VPN mode enabled, I don't know the engineering behind it, because Non-Meraki VPN is very limited, so it would be better to contact Meraki.   Not sure if it would work, but limiting via L3 firewall rules is a possible solution if you don't feel secure. ... View more

Yes. One option is have the MX in the DC as a one arm concentrator. https://documentation.meraki.com/MX/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS. And the management traffic of that MPLS remote link IP would have to go through a central DC firewall that is not the MX. Other option would be to have the remote MPLS link cloud mgmt traffic traverse the MPLS cloud, into the DC or central location, and then cross a meraki MX in routed/firewall mode that is there, from its LAN through its WAN. In that case, a tunnel would be established from remote WAN MPLS link, to central MX LAN side. Could not find documentation on that. ... View more

yes, correct! @GreenMan @maybe you‘ve a suggestion how the cabling should look in such a case too? ... View more

I absolutely agree on that. It would be helpful to have an up-to-date overview of all the bugs that have been identified on a particular software version. Our experience is that the "Known Issues" gives a (very) limited overview of the actual issues that are known, not just for the MG but in general. ... View more

hi, i‘m currently facing the same problem between a meraki MS425 and an Aruba VSF stack… every basic settings is correct but one link does‘nt work! @TheBR did you found a solution for the issue already?  ... View more

As having experience with networks halting endpoints even at 1% broadcast storm there is no reason not to choose 1% for 100/1000 links and higher. I found that on Catalyst switches where you can also limit on packets per second that alot of hosts/access points start having big issues around 80-100 pps of broadcast traffic.  Since those frames usually are a few kilobytes in size you can imagine that even a 1% of 1 Gig = 10 Mbps is still enough to hamper your network.  Of course this was at that specific situation.  Ultimately I had to configure a forced shutdown if broadcast packets exceeded 50 pps which still is way higher than the normal 0 - 3 pps broadcast on that network.   Alas you can't configure packets per second or do a shutdown of the port if this happens so testing with a dumb switch is required to determine at what point your network becomes unstable.  If your network is predominantly 100/1000 Mbps links you could use these: Broadcast: 1% Unknown unicast: 1% Multicast: 1% if you don't actively use audio/video streams in multicast over your network (if you do then you need to figure out total bandwidth for these). ... View more

Meraki has not implemented MST at all.  It has implemented RSTP.   You use MST on Cisco Enterprise switches in a mixed Meraki environment because MST is compatible. ... View more

Hi,   I´d like to ask a question regarding to this! Is there anyhting else what should be considered when using this? e.g. BPDU-Filter or BPDU-Guard on the used ports on each side or other STP related topics to avoid possible Loops?   Is this also a Meraki suggested solution with official documentation? ... View more

@whistleblower that's interesting, on the one hand I can see you don't see the 15.42.3 option required, but on the other, you still have MS12.28.1 which is no longer an option for me.   It looks like Meraki maintain legacy stable versions in an organisation dashboard where they are upgrades, but not downgrades.  I have an MX HA pair as a VPN concentrator running 15.42, and you must have some 12.<28.1 switches...   In this case I'd ask support to apply 15.42.3 to your MX pair. ... View more

will the specified "Exit"-Hub also advertise a default-route via Auto-VPN to another "normal" Hub which has the checkbox set automatically? because I´m facing the issue that the default-route is active on the spokes but not on the second hub in the network 😕 ... View more

>> I have to assume if incoming traffic is received on the one armed concentrator coming from WAN1 of the branch, that the return traffic will be sent to the same tunnel.   This is definitely the case. It’s how if traffic originates at the concentrator end it eventually ends up on the ‘correct’ (based on the SD-WAN rules at the spoke) site. Initially traffic initiated at the VPN concentrator end is just placed into one of the two tunnels to the spoke (no logic is applied). The SD-WAN rules are then applied to traffic as it returns from the spoke to the VPN concentrator and it’s put into the ‘correct’ tunnel. Then when the traffic is received at the VPN concentrator it then know the tunnel to use based on the rules applied by the spoke.   >> for question number two: this was not based on any documentation.  I was able at that time to do a poc for a client with demo MX'es and we simply observed the behavior by using iperf testing and checking the uplink statistics on both MX'es at the same time.   I haven’t seen this documented anywhere either, but have heard that the MXs will always try and make the connection to the actual IP address assigned to a WAN interface first. If that fails they’ll then try and use the public IP address (I’ve never done a packet capture to see if this is actually true though). The VPN registry provides both the public address that it sees, and the IP address assigned to the WAN interface to the peer MXs (the MXs themselves send their Interface IP address to the VPN registry as part of the registration process). ... View more

@whistleblower thanks for updating the thread, that documentation is new since the Group Policy ACL went into public beta and it nicely completes it. Your questions around multiple authentications is a good one, and I don’t know the answer - I’d need to try it to confirm. Below is what I’d expect to happen (based on experience and ‘guess-work’), but would be great for someone that knows to update this thread.   1. Single-Host, easy and just as expected.   2. Multi-Domain, I would expect that the Group Policy ACL will only be triggered by the data domain, and that will be enforced on the port. I doubt very much whether the voice domain will trigger Group Policy ACL - the only question will be whether or not the ACL will apply to traffic in the voice domain (my gut feel would be that it won’t, but needs to be confirmed).   3. Multi-Auth, I expect this will work as it does for VLANs where all authentications have to return the same VLAN or they are denied. In this case I expect they’d have to return the same Group Policy ACL or they’ll be denied. The voice domain will be as per above.   4. Multi-Host, isn’t supported with Group Policy ACL.   Would be great if someone that actually knows could confirm this, or add the correct results. ... View more