The schedule upgrades tab current firmware column should show a firmware version matching the version on the device status pages.   The overview tab only shows every current version available it does not mean those versions have been applied to your networks.       If you are saying the schedule tab and the device status show different versions AND it's not an instance where the device doesn't support the latest version, then there is some sort of GUI bug and you should open a support ticket. ... View more

You'd setup a group policy with the appropriate firewall rules to apply to it and apply it to that VLAN on the MX. Whether you want to connect the cable directly to the MX or trunk it to your switch and put an access port there is more a physical design consideration. It only being on the MX does provide a slight bit more security as you can prevent the VLAN from existing on the switches. No matter what the vlan does have to have it's gateway be on the MX for this to work properly. It can't be a static route to a L3 switch for example.   Group Policy info: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies ... View more

I'm not sure where that URL is from (perhaps an older version of the api?) but the API to update radius for Wireless is this one: https://developer.cisco.com/meraki/api-v1/update-network-wireless-ssid/   You have to do it per SSID. Org Wide Radius does exist but only for wired devices at this point.   ... View more

I don't work in a lot of low bandwidth environments, so generally the default policies seem to suffice these days for me.  However I'm sure some others here will have thoughts. Here is an older thread on the subject: https://community.meraki.com/t5/Security-SD-WAN/QoS-for-Teams/m-p/102045#M25647 It's technically relating to MXs but many of the same ideas would apply   ... View more

I presume this also exists in AWS, but I know azure keeps stats on traffic utilization that may be helpful for calculating throughput used. ... View more

I've seen zero indications of new models coming, including as a partner. I would also add that the recent software changes have come with a goal of increasing the performance of the existing models and presumably extending their lifespan.   I would ask your account rep this question as its highly unlikely anyone who knows can comment on an open forum. Although I'm definitely all ears as well if someone would! ... View more

The 9800-40 is an older model for the previous generation of 9800s. 9800-40s are monitorable: https://documentation.meraki.com/Cloud_Monitoring_for_Catalyst/Getting_Started/Cloud_Monitoring_for_Catalyst_Wireless_Requirements The CW9800M is supposed to be monitorable per the Cisco Data Sheet: https://www.cisco.com/c/en/us/products/collateral/networking/wireless/wireless-lan-controllers/catalyst-cw9800m-wireless-controller-ds.html But as best I'm aware that feature is not live yet. You may be able to get info from your account team on an ETA. If you are looking at purchasing, I would definitely get the CW model and then just waiting to onboard to the dashboard once that's available. The 9800-40 has an announced End of Sale date and the CWs are the recommended migration path.   ... View more

Yeah, it's not the easiest thing to do yourself. Depending on the size of your deployment there may be third party tools like the other commenter posted about that could do it more cost effectively. ... View more

Edit: I think I misunderstood the translation I got. I presumed license meant Meraki license but the other reply may be more what you were asking. The only free equipment program I'm aware of was the CMNA program and that ended in 2022. ... View more

These two: https://developer.cisco.com/meraki/api-v1/get-organization-uplinks-statuses/ https://developer.cisco.com/meraki/api-v1/get-device-loss-and-latency-history/   would be what I think you would want. Mostly the first, but the second may provide additional data you want.   ... View more

1. No, the only windows would be the same ones where the dashboard is also unavailable. 2. The dashboard maintenance windows are published on the dashboard ahead of time. There may also be a way to get emails, but I'm actually unsure of this. Someone else may know. They do send them for firmware upgrade windows, but I don't recall seeing one for overall outages. 3. I'm not aware of an endpoint that shows this. For an unscheduled issue you may be able to use the various ways the status page is published to create your own integrations. There are RSS, Atom, and Slack options: https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Status_Page     ... View more

This should work as long you use compatible but matching (speed/duplex/media type) sfps at each end. I.e. if you use a Multi Mode MA-SFP-1GB-SX on the Meraki you need to use a multimode linksys compatible sfp on that end. Here is the Meraki SFP list:  https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Small-Form_Factor_Pluggable_(SFP)_and_Stacking_Accessories   I will say I've never not had a third party sfp work on my Merakis but officially the above link is the only supported hardware. ... View more

Im general you bridge clients to the LAN (as in Network 1) to allow direct connectivity between the wired and wireless devices. This allows broadcast traffic to work, etc. You would use NAT mode (Network 2) for a variety of reasons including conserving IP addresses, security (can combine with firewall settings and use for a guest ssid), or perhaps something else. It also could have just been a misunderstanding by whomever originally set things up. The understanding of why yours is that way, that you have presented doesn't make much sense to me as a reason. Suffice it to say there could be valid reasons to have your setup that way. In general you mention eliminating SSIDs, you may want to look into : https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_Authentication_without_RADIUS This allows you to consolidate SSIDs while still providing different firewalling and vlans and other rules to clients. The caveat being you can't mix match NAT Mode/Bridge mode, all clients need to be one way. ... View more

Are you planning on replacing the primary with something new? If so I'd leave things as-is and just move the settings for now. If you aren't and you have a model where the second WAN is a combo port that also can be LAN (MX64/67/MX100), I'd strongly consider moving it as I've occasionally seen these models get configs screwed up during a power outage or similar scenario and lose that WAN designation for the secondary port, and recovering becomes more work. If it's a model where the secondary WAN is always a WAN it's a bit more of a personal preference thing. As far as I know, there is no technical reason to make the change. ... View more

I'm not sure of the international FCS dates, they may not be available there yet, your Meraki rep may be able to clarify or help point your reseller in the right direction. ... View more

Cisco doesn't post the pricing publically, you need to get that from your reseller. Even the pricing Thomas posted above is just list which is not reflective of even base discounting that everyone gets. With the quantities you are talking about I would expect you to get hefty discounts but your reseller must work with your Cisco account teams to get that pricing to you. ... View more

You can certainly use templates: https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates but they do have limitations, definitely read the documentation, they may work for you, they may not. You can also create the original network and just clone it. Future changes would have to be done individually. You can also use the API to do the deployment or future changes. This is what I do, with postman and the ability to use runners you can do some stuff fairly easily without having to learn a lot of coding. I would not put ALL the aps in the same network. I always divide up by site, but I also deploy the whole stack and need client tracking data to work properly. ... View more

You are going to want to check the corresponding NPS logs for anything that failed. They are generally pretty good. For timeouts if it's easily replicable you can do packet captures on the NPS server itself or somewhere along the way to see if perhaps packets are getting dropped. It certainly could be some sort of configuration on the server. The Meraki logs are only going to tell you one side of the story. ... View more

Is the printer on the same vlan or a different vlan? If a different VLAN you can create a group policy with the relevant Layer 3 rules and attach it to that VLAN. If it's the same VLAN the MX is not involved in that layer 2  communication and I would recommended moving to seperate vlans to facilitate with a group policy. You can do intra-vlan blocking with more advanced switching options, if you wanted to investigate that, but if the site is small enough for a MX64W then its likely not worth it, in most cases. ... View more

There is no specific way to do that in Meraki that I'm aware of. If a specific AP was the only AP broadcasting the SSID you could blacklist clients and thus only allow the ones you want but that's going to be a manual thing to maintain. Even with more advanced security, I've never seen a way to do this. For example ISE doesn't have a policy option where if X number of devices are already authenticated don't authenticate further devices to a specific network device. What is your goal here? ... View more

There is no requirement for source and destination mirror ports physical proximity, beyond they must be in the same switch or stack. https://documentation.meraki.com/MS/Monitoring_and_Reporting/Packet_Captures_and_Port_Mirroring_on_the_MS_Switch ... View more

I've never encountered this specifically. Have you packet captured the lan of the MX to verify the packets are arriving?  I'd perhaps test with AMP or IPS turned off temporarily. I've seen and heard them incorrectly blocking things over the years. You also may just want to call support as they can trace down the packets inside the MX and see if something else is causing them to drop. ... View more