As @alemabrahao mentioned you can use the License Calculator to figure out exactly how adding a license will impact the co-term date. Here's an example of the tool modeling current expiration of Sept 22, 2027 and the impact of adding a 3 year renewal license. It would move the co-term date to Sept 21, 2030.     When using the tool always start with your current org license state on line 1 (license level, mode "add", default start & claim date of current date, then add the device models and quantities. Sept 22, 2027 is 755 days from today (Aug 28, 2025). So I used 755 days as the term on line 1.   Line 2 is where you can simulate a new license or type Add or Renewal. In your example of just wanting to extend time you would want the type to be renewal. If you wanted to both add devices and time you'd use a mode type of Add. ... View more

@denstov  We've seen some cases of this in the past. If you haven't already I would open a Support case and have them see if this matches the previous cases or if this is something different. ... View more

I also had a chat with Support and showed them the ways it's accessible. So, hopefully that will help you get case moving. ... View more

Documentation covers the Local Status Page in great detail https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page   Specifically your question is covered in this section https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page#Controlling_Remote_Access_to_the_Local_Status_Page ... View more

Hmm, I don't see it under network wide with RO admins. Only using the little loophole routes do I find it.   ... View more

Same loophole when using the new Client360 page too   ... View more

Same happens for a local admin with RO permissions. Seems to be a UI loophole.   I will ping Support and let them know it happens to SAML and non SAML admins along with a quick video showing exactly how it's accessible.   To confirm the way you're accessing it is going to a switch, clicking on a port, then down in the tools section clicking the packet capture link yes? Also, it only applies to the new version page. The old version doesn't appear to show the pcap link. ... View more

As others mentioned for your protection you should never post a Meraki serial number. If you’re just trying to find the approximate date in which a Meraki model was introduced one approach is to find a corresponding product launch announcement on the Meraki blog. Here for example is the announcement for the MR 46 AP.  https://meraki.cisco.com/blog/2020/02/new-decade-new-wi-fi-6/ ... View more

Templates are meant for bulk config both for initial deployment and ongoing operations. They’re not intended to be for staging usage or config snippets like perhaps other platforms.  In the steps you listed above if the end goal is API then you could remove steps 1-3 and accomplish it all with API.  ... View more

This feature only applies to MX/MX VLAN interfaces today. I'm not following your comment about applying it to Switch and Wireless networks. ... View more

Example template and network with edited subnets post initial binding and auto address assignment. Is this what you're after?     ... View more

The status definitions are mentioned here https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades#Firmware_Version_Status ... View more

Looking at the internal bug notes seems to be related to high rate of DNS packets hitting a rate limit and being dropped. Support might be able to give more details if you open a case.   And it appears to be MS130 specific. ... View more

Pretty sure it used to work as intended. Or rather has this hack config intends. Not quite sure this type of config was ever envisioned to be used. The safer approach is probably to have cameras in their own networks. Then regular RBAC for non camera networks can work and access to camera networks would be blocked without this "allow" no access type config. Just my 2 cents. ... View more

Seeing same behavior ... View more

Yes the browser tab name needs fixing ... View more

It's a GP that today can apply to MX VLAN interfaces. Broader use cases are in the future. ... View more

You can definitely put a DHCP server on the far end and that's what documentation recommends. Or, swap to a switch that supports DHCP server itself. But the relay design works too. Is it supported per documentation? Well, that's another matter that I cannot address.    The SSID you have configured as the "Clients wired directly to Meraki access points" under the network wide page is the VLAN the repeater's eth port will be mapped to. So, if that SSID is tagged with a VLAN ID traffic on the repeater eth will be on that VLAN. If the SSID is untagged then it will use whatever the gateway side AP's native VLAN is per the switch trunk port it's connected to. So, if you use a dedicated SSID for this mesh link purpose you might consider editing the config and have it tagged for a specific VLAN to ensure the mesh link is on the intended transit VLAN.   But this also brings into question how you want the switch mgmt IP to function. This diagram in documentation shows VLAN 20 being the mesh SSID VLAN and hence the repeater side switch is on VLAN 20 for its mgmt IP and its "transit" VLAN SVI for the next hop back to the MX. Why documentation shows that switchport being a trunk, native 20, allow 20 I'm not sure. That's just the same as access VLAN 20. And, the repeater eth port isn't a trunk anyway in that diagram.   If you want a unique switch mgmt VLAN different from the mesh/transit VLAN then you need to have Support enable multi-VLAN mesh. And the diagram here covers this design. In your case Support has already enabled multi-VLAN mesh per your Support case. I also have a slide of this topology with more detailed config bits than official documentation. This is exactly what I have running in my lab today.   So I would build this out link by link and make sure each step works. When you bring up the repeater and switch ensure the switch gets an IP (or static) and you can ping back to the MX SVIs. The MX should be able to ping all the SVIs on the switch assuming you have the static routes in place on the MX. If that all works maybe first try a wired client on the switch and make sure it can get an IP via relay back to the MX. If that's not working no reason to jump to adding APs on that far end as something isn't configured correctly. ... View more

DHCP relay on a MS210 in this design works. See this diagram.   You mentioned Meraki Support enabled multi-VLAN mesh? That is a different thing from LAN extension for repeater side LAN APs. The latter is the L3 switch design.   Multi-VLAN mesh is simply converting the mesh link to a trunk. So, the repeater side switch can support multiple L2 VLANs extended from the gateway AP side/network.   When you have repeater side LAN AP(s) you need the L3 switch whether DHCP is sourced on that remote side or relayed to the gateway side of the network. The risk I see with the DHCP relay design is if the relay fails the AP(s) will attempt to mesh and potentially cause issues. I prefer to make the repeater side switch and AP(s) a separate network not only for visual/mgmt clarity but it also then allows you to disable mesh (on network wide page) so those AP(s) don't attempt to mesh.    The multi-VLAN mesh (Support enablement) and L3 switch (because of repeater side AP) designs can be combined. Example. ... View more

MA-ANT-C2-B for the MG52 is backwards compatible with MG51/41. ... View more

MA-ACC-MGKIT-1   https://community.meraki.com/t5/Cellular-Gateways/SKU-for-Additional-MG51-Mounting-Kits/m-p/264514/highlight/true#M1432   But, if it arrived damaged as @alemabrahao said I would first contact Support ... View more

A diagram would help better understand exactly how you plan to deploy. But in general MX HA monitors reachability both on the WAN and LAN side in different ways. This doc (and linked docs within) cover the process in detail.   https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Underlying_Concepts_and_Technologies ... View more

Do they all show "source" as your IdP? The Users page will combine IdP synced users as well as Systems Manager and VPN users. If all from your IdP are they duplicates?  ... View more