Great to see @PhilipDAth, I see lots of familiar faces!  Great to hear you enjoyed it, I'm sure you had some great discussions and provided some great feedback, and hope you got a few new nuggets from the lab exercises. ... View more

Generally speaking, I'd say to avoid that situation where you're purchasing fresh licenses for equipment that has gone End-of-Support, which it typically 5 to 6 years after the End-of-Sale date.  EOST equipment is considered obsolete.  You can generally purchase fresh licenses before the EOST date, but not after.    For example, the MS22/22P and MS42/42P switches all went End-of-Sale back in April 2014, and they can no longer be purchased.  The licenses however, can be.  I confirmed just now in CCW (Cisco Commerce Workspace) that the license SKUs are still in the system, and they do have "EOS" in the description but they are still orderable.  I would not expect them to be orderable after EOST.  But I suppose you could purchase a 5-year license today, which would last until 2023, even though the switches go EOST in 2021.  That would perhaps keep Dashboard happy from a licensing perspective, but you'd have no support, could run into firmware upgrade issues, have no RMAs for a failed switch for example.  And when there was a "License Problem" warning message come 2023, that would be almost 10 years after the equipment was announced EoS, and should be retired if it wasn't already.     If you wanted to keep some equipment around like in a lab (I have some Cisco switches that went EOST like 3 or 4 years ago) then I suppose you could keep them in a separate network and purchase the appropriate licensing before the EOST date.   Hope that helps.  I'll double check on this and post back if I find out something different.   ... View more

Thanks @Mr_IT_Guy I'll bounce this to the documentation team! ... View more

Hi Ritchie, Not sure if I follow the question exactly, but you certainly have the ability to add firewall rules to allow whatever specific traffic needs to get out, followed by a deny any/any/any rule, which would drop everything else.  But you also mentioned allowing access to specific IP addresses in the Meraki cloud.  If you happened to be looking at the Help > Firewall Rules page, you do not need to configure the MX itself with any of those firewall rules to allow cloud connectivity.   That's usually not something you need to worry about unless you're equipment is behind a more restrictive perimeter firewall or proxy that blocks all outbound connections by default, in which case you would refer to the Help > Firewall Rules page.  That page shows you a snapshot of any/all FW rule info the Meraki equipment is expecting to have for all of the Dashboard comms, live tools, etc.     Let me know if I misunderstood the question. ... View more

The throughput test under any of the live tools pages is just measuring back-end mtunnel throughput for the control channel between your Meraki device and the Dashboard shard it's connected to back in the data center (cloud).  You can see what the speed test is actually doing (nothing exciting) by running a pcap and looking at all the TCP/7752 traffic.  It's not meant to be an indication of throughput for your clients to/from the Internet, so you're correctly using something like speedtest for that.  Thanks @PhilipDAth for sharing that docs link, that's the one to reference. ... View more

Another option regarding the 802.11r question is that if you have some percentage of devices that may not support it, and you want to give 11r benefits to those that do, and you're running r25, perhaps consider the "Adaptive" setting instead of just the enabled/disabled settings.  Clients who don't support it should still be able to join the SSID and just not leverage 11r.   ... View more

Agreed, we're assuming the 2nd MX has been claimed and is already in your Dashboard inventory?  If so, you should certainly be able to add it as a warm spare, either from the Appliance Status page or the way @PhilipDAth mentioned.  If still not working, I'd check with Support.  ... View more

For starters, consider running the SRC (Stable Release Candidate) firmware 25.9 if you're not already.  You could check with Meraki Support first to scrub your config and confirm 25.9 is a good choice, just in case there's a known issue specific to your environment or AP models.   Remember that it's ALWAYS the clients (not the APs) that ultimately make the roaming decisions, and it varies wildly by device vendor, by operating system, and by device driver versions. I've seen devices cling for dear life to an AP 50 feet away when it's right underneath another AP. It's very device-dependent.   So we cannot control the clients, but we try to get them behaving well via best practice settings. And even then, they don't always behave well, and still varies by device type, OS and driver version.  And don't forget that every RF environment is going to be different, and in a given RF environment, every client is going to have a different perception of it.  Different vendors and different operating systems will use different methods, often based on RSSI, which is typically proprietary and different phone/laptop/tablet manufacturers implement in different ways.   So it's entirely possible that client devices can stay "sticky" to an AP even on a floor above or below (through a ceiling or floor) even with another AP in the same room. Obviously there's going to be signal attenuation through a ceiling/floor, but there could still be enough signal strength to keep the client happily associated at a reasonable data rate.   Newer clients that support 802.11k, 11v, 11r (all of which are there in r25 firmware) can leverage neighbor reports to interact with APs to make optimal roaming decisions, and APs can assist with client balancing, but still, it's the client who makes the decision and initiates the roam. And that decision process is a dynamic one with constantly changing variables, such as people (attenuators) moving around.   I've observed similar behavior in my own home, where I have an AP in my basement office and an AP in a 2nd floor bedroom. Some devices will consistently roam from AP1 to AP2 when I get within 15 feet of the AP, while other devices will stay associated to AP1 no matter how close I get to AP2. The behavior isn't perfect but improved with newer firmware.   And implement standard best practices, like setting minimum bit rates to 12Mbps (for example), using automatic power reduction, band steering to favor 5GHz, minimizing the number of SSIDs, using an appropriate channel width, including DFS channels if appropriate, etc.    And of course you can always get with Meraki Support to take a closer look at your specific APs and clients where you’re seeing roaming issues.  Many "roaming issues" can actually be normal behavior given client dependencies and so many variables.  Still, Support has additional tools on the back-end to get some insight on how the APs are behaving and communicating regarding client roaming and steering.     More info https://documentation.meraki.com/MR/Other_Topics/Client_Balancing https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Roaming_Technologies   ... View more

Thanks @AnnaT for the update (I do recall now there were 14 stations a few weeks ago in NYC!) and taking care of @GabrielGamarra. ... View more

@ITzhak I had to hold off on replying with AP models until the new Meraki product announcements came out this week at Cisco Live and everything's up on the web site now.  Since this is warehouse based and you have 30-foot ceilings, you might consider the MR42E or MR53E indoor APs with external antennas, along with the D series antenna which is the omni but with 45-degree downtilt.  More info on the web site.  Post back if questions. ... View more

Agreed could be firmware, maybe try 25.9 (Stable Release Candidate) as @PhilipDAth suggested and also check your 802.11r setting, as a test if it's already enabled try adaptive instead.  Like @MilesMeraki said probably worth opening a case, probably best to call in so you can do some live troubleshooting and connect an iOS device to the repeater AP while they run some pcaps. ... View more

Thanks, wishes are good, but please also get that info to local Meraki reps.  Make a wish does filter back to the product teams but is not a feature request tool.  We have a formal FR mechanism that Meraki reps can access and update accordingly. ... View more

The "top 10 list" for most of my own customers are usually these (give or take a few): Adult and Pornography Bot Nets Confirmed SPAM Sources Malware Sites Nudity Peer to Peer Phishing and Other Frauds Proxy Avoidance and Anonymizers SPAM URLs Spyware and Adware   These 10 seem to be a fairly common theme, will have you very well covered in most content filtering situations, and only tend to generate the occasional false positive.  I also have many K12 customers who get more restrictive for obvious reasons and start adding additional categories like Gambling, Drugs, Hate and Racism, etc.   ... View more

Correct there is not an MV option today for changing settings in bulk.  But this is becoming a more common wish.  Please do share your requirements and use case with your Meraki reps so they can add to the feature request, and hopefully you'll see this feature sooner rather than later. ... View more

Correct, the WAN interfaces were designed to be SFP+ for that reason, to maximize flexibility so you could use 1G copper or fiber SFP transceivers or use 10G SFP+ depending on what Internet-facing handoff you have. ... View more

Got it, sounds like progress, and the issue stuck with that physical port.  Will need to try that same and/or other devices on what might be a faulty switch port and see if you can reproduce the problem at will.  Then I'd open a case with Meraki Support in case they might have some back-end tools or visibility to investigate further.  Certainly doesn't sound like anything configuration related, worst case they may need to RMA the switch if it actually has a faulty port. ... View more

Sounds like a plan @Uberseehandel let's see if we can get this problem to follow the PC to another port (and if it then continues to occur around the same time of day).  And in the process, let's get some other device connected to that first port, and see if the problem sticks on that same port, but with a different end device.  Also, not to introduce too many variables at once, but maybe just for the heck of it, adjust the DHCP lease time to a week instead of a day and watch for identical versus different behavior.   ... View more

If you have an MR-only wireless network, the best way to add this functionality is by adding a Meraki Systems Manager (MDM) network, and you can kick off a free trial with support to test it out.  It's very easy in Systems Manager to create a geofence and then send alerts when a specific device leaves that geofence, as well as make changes or enforce restrictions depending on if the device in inside or outside the geofence, and also based on time of day for example, you can push/pull specific apps, enable/disable restrictions, etc.  You can configure alerts if a client violates a geofence, comes back inside the geofence, or goes offline for more than a configurable number of minutes (regardless of geofencing status).   ... View more