My favourite thing about Configuration Templates is the ability to unbind while retaining configurations 😀. It's a get of jail free card that wasn't always there for people who later regretted choosing this feature: https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates#Unbinding_Networks_from_a_Template Based on my experience, I only recommend Configuration Templates for initial provisioning of networks (e.g. if you really want to use the Switch Templates). Even then, if I can get away with a non-template empty network that serves as something to clone from, I do. Once provisioned, I recommend unbinding any templated networks (while retaining configurations) because: It's difficult to phase the rollout of new firmware or architecture changes as all template-bound networks upgrade/change on the same schedule. Firmware regressions or upgrade issues can therefore have a nationwide impact. Technician/Operator human-error mistakes have a nationwide impact. In practice, Meraki Dashboard controls and warnings about the impact of Configuration Template changes have proven ineffective (e.g. someone wanting to change a SSID's PSK at one location without realising the wider impact). Meraki's back-end infrastructure supporting Configuration Templates has proven unreliable between 2021-2024, hindering fast paced provisioning of networks at scale. Configuration Template bound networks have historically shared certain resources in Meraki's back-end infrastructure which has been found to hinder scalability (e.g., whitelisted client limits). Configuration Templates are often late to support new features (e.g. IPv6, VLAN names, MultiWAN Backup Uplink). ... View more

HI Alex, That documentation section mostly gave me the clarity that I was looking for. The only lack of clarity is due to issues which are separate to the topic at hand. I think it's understandable why people are asking questions about the MX84 and MX100 since they have similar 18.1 firmware limitations as the MX64 and MX65. But the documentation covers that if you read carefully - so I think it's optional whether or not to explicitly call that out. I also think it's understandable why people are getting confused about the MX's (lack of consistent) firmware versioning notation. Until this is fixed everywhere, it should probably be a requirement of your documentation to help customers to navigate this conundrum. My suggestions for an edit to the section follow in red: WARNING: MX64 and MX65 devices on firmware releases prior to MX 18.1.7.13 (a.k.a. "18.107.13"), and all other MX devices on firmware prior to MX 17.6 run versions of Snort 2 that will stop receiving updates after December 18, 2025. All network traffic will continue to pass normally and be inspected using outdated signatures, which may expose clients to a reduced security posture until the firmware is updated. To ensure that such devices continue to receive updated rule sets, please ensure they have been upgraded to MX 18.1.7.13 (a.k.a. "18.107.13") or any higher firmware version before the above date. For more information, please refer to this Snort blog post. Note: MX84 and MX100 devices on firmware releases ≥ 17.6 are not impacted by the Snort announcement. ... View more

I WANT IT ... View more

This reminds me of this bug fix: Makes me wonder if the same thing need to be applied in a future firmware release for the MS130 series... 🤔 ... View more

Assuming you're using a Microsoft Windows NPS (RADIUS) server, here's some more up to date Microsoft documentation for adding the IP address of the Meraki switch(es) to the server: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-radius-clients-configure Without first adding those IPs to the RADIUS server, RADIUS requests may just be ignored. Further, you can confirm the IP address that the switches are using to communicate with the RADIUS server by taking a packet capture (filtered for UDP port 1812 on whichever port is connecting to the RADIUS server) while attempting to authenticate a network client. Then look at the "NAS-IP-Address" attribute field for each switch:   It'll likely just be the management IP address, but if you're using Layer 3 routing on the switches, it might be good idea to confirm. ... View more

This announcement: MS 15.21 Stable (GA) is available for install! ...says that MS 15.21 introduces port isolation under "new features". But then links to this old article :Restricting Traffic with Isolated Switch Ports ...which says: Firmware MS 11.22 adds support for Port isolation on the following. MS Switch Stacks All ports on the MS210, MS225, and MS250 series switches. Prior to MS 11.22, these switch models supported Port isolation on ports 1 - 24 only. But that same article as recently as October 2022 use to say: For MS210, MS225, and MS250 series switches, port isolation is only supported on the first 24 ports   Port isolation is not supported across stack members Back in October 2022, MS 11.22 was ~3 years old. Colour me confused by the mixed messaging! 😕   ... View more

I FOUND THE GNOMES! https://community.meraki.com/t5/Security-SD-WAN/Sign-up-to-participate-in-future-Mobile-research-studies/m-p/177470#M41988 ... View more

Kudos Brash! I didn't even know how to get to that forum! ... View more