@Pedro fantastic news!, it is very good to hear it. ... View more

@alyssafriesen on the other hand, I see yours are also separated by days, so there shouldn't be anything to worry about. The device seems to be leaving the AP (maybe because it is a saver power mode specific to this device). ... View more

I have an MR33 at home and using Speedtest.net on my 75/20 Mbps line, I get 72 Mbps download and 17 upload.   If I do an iPerf TCP test between my Macbook Pro and my Windows machine (On the LAN) I get this:   Connecting to host 172.20.Y.Y, port 5201 [ 4] local 172.20.X.X port 60762 connected to 172.20.Y.Y port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 36.6 MBytes 307 Mbits/sec [ 4] 1.00-2.00 sec 36.8 MBytes 309 Mbits/sec [ 4] 2.00-3.00 sec 34.4 MBytes 289 Mbits/sec [ 4] 3.00-4.00 sec 32.3 MBytes 271 Mbits/sec [ 4] 4.00-5.00 sec 31.0 MBytes 260 Mbits/sec [ 4] 5.00-6.00 sec 33.9 MBytes 285 Mbits/sec [ 4] 6.00-7.00 sec 34.7 MBytes 291 Mbits/sec [ 4] 7.00-8.00 sec 32.9 MBytes 276 Mbits/sec [ 4] 8.00-9.00 sec 31.1 MBytes 261 Mbits/sec [ 4] 9.00-10.00 sec 34.8 MBytes 292 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 338 MBytes 284 Mbits/sec sender [ 4] 0.00-10.00 sec 338 MBytes 284 Mbits/sec receiver Accepted connection from 172.20.Y.Y, port 51240 [ 5] local 172.20.X.X port 5201 connected to 172.20.Y.Y port 51241 [ ID] Interval Transfer Bandwidth [ 5] 0.00-1.00 sec 39.4 MBytes 330 Mbits/sec [ 5] 1.00-2.00 sec 38.6 MBytes 324 Mbits/sec [ 5] 2.00-3.00 sec 41.1 MBytes 344 Mbits/sec [ 5] 3.00-4.00 sec 34.2 MBytes 287 Mbits/sec [ 5] 4.00-5.00 sec 35.5 MBytes 298 Mbits/sec [ 5] 5.00-6.00 sec 40.2 MBytes 337 Mbits/sec [ 5] 6.00-7.00 sec 42.6 MBytes 357 Mbits/sec [ 5] 7.00-8.00 sec 38.5 MBytes 323 Mbits/sec [ 5] 8.00-9.00 sec 33.9 MBytes 284 Mbits/sec [ 5] 9.00-10.00 sec 32.6 MBytes 273 Mbits/sec [ 5] 10.00-10.05 sec 1.90 MBytes 327 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-10.05 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-10.05 sec 378 MBytes 316 Mbits/sec receiver   Keep in mind these are Lab tests (I am like 1 meter away from the AP) and very synthetic in the end, but I would definitely recommend you to upgrade to our latest beta version (and you can go back anytime you need) and see if it improves the speed. By the way, I'm using 80 MHz channels (my neighbors haven't crowded the 5 GHz band, at least for now).   Of course, as mentioned by @MerakiDave, SNR, Signal, Noise, Spatial Streams and the number of antennas are very important (SNR & number of Spatial Streams above everything). ... View more

It really depends on your implementation. Those messages are basically the STAs leaving the AP without sending a disassociation message first, or the AP not being able to hear it.   Said that, it's not like they are occurring several times a minute, so I wouldn't worry about them, as some devices do not send any disassociation message before leaving the AP or turning off its wireless LAN radios,  ... View more

Unfortunately, it is currently not supported at the moment. There are only three events that can generate an email.   A gateway goes offline for X minutes A repeater goes offline for X minutes A gateway becomes a repeater   If you set a syslog server you can see more events being reported to your syslog server:   https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/Syslog_Event_Types_and_Log_Samples#Meraki_MR_Access_Points   But it does not include DFS events    You can make a wish (the button is located in the lower right corner in your Dashboard), so our dev team can take this suggestion to be incorporated into a new feature.   Hope it helps!!!    ... View more

Yes, it is currently incompatible with 802.11r, as explained here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Layer_3_Roaming#Tunneling     ... View more

@Pedro I think the best way to go would be to give us a call, but basically, what I can point is this documentation about troubleshooting VoIP deployments.   https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/VoIP_on_Cisco_Meraki%3A_F.A.Q._and_Troubleshooting_Tips   We enable the user to have more than 3 SSID because there are some cases where you would like to enable some SSIDs on especific APs (and not in others, i.e. Meeting Room XYZ), so this way you can creater them.   I would also like to point that usually these kind of scenarios are complicated in the sense that it is not only one problem, if not more than one, and dividing the big issues into multiple ones is quicker. For the roaming issue, I would take monitor mode PCAPs on the wireless (at the source AP and at the destination AP), as well as PCAPs on the wired side of the APs.   There must be a reason why the device is having issues doing the roaming and usually in the reassociation response frames you can see what was the reason. ... View more

@Pedro from my personal point of view this can be looked more into with a monitor mode packet capture.   It's very unfortunate that you've had a bad experience with our devices, but, what I can offer you, is that if you send me a private message with the case number you opened so I can look more into this. ... View more

Can you please post a screenshot of what you see on Wireless > Air Marshal?   Please also check if you see many DFS events on Network-wide > Event log (You can filter it here)   These messages are usually sent from the device to tell the AP that it is leaving the AP (for example, when it is changing to another SSID, or simply losing coverage) ... View more

Hi Marcio,   As it was pointed before, it is not a good idea to put 200 clients on a single AP. The end user experience would be horrible. Although I have seen an MR53 with more than 120 clients at the same time, I would strongly recommend you to use at least three APs to share this user load. The reason is not only the AP itself, is also about using different channels on each of them, which makes it easier to every end device (STA) to content for medium.   In wireless, before any transmission is made, every STA and AP needs to go through the process of CSMA/CA, which takes a lot of time itself, and the more devices, there are more chances of collisions, therefore retries, which roughly translates to slowness. Even with a mechanism like RTS/CTS, collisions cannot be completely avoided.   Additionally, I would suggest setting the minimum bitrate to a value of at least 11 Mbps (though I would personally recommend 12).   Depending on the environment itself, you may want to use directional antennas instead of Omnidirectional antennas, basically to have cells where you will serve the users (it really depends where you're planning where to deploy the APs)     Also, for Pedro, while there is no mechanism to limit the devices that can be associated with an AP, you can limit it by:   - Limit the signal spread (by using directional antennas) - Increase the minimum bitrate (it will also effectively limit the cell size) - Enable client balancing (https://documentation.meraki.com/MR/Other_Topics/Client_Balancing)   Also, we have a really good guide for deploying APs in High Density (HD) environments:   https://documentation.meraki.com/MR/Deployment_Guides/High_Density_Wi-Fi_Deployment_Guide_(CVD)   Hope it helps  ... View more

In addition to the guide provided by Sameh_Sackla, I would not recommend by any means using 802.11r with this Cisco Phone.   It comes from a time where 802.11r did not exist, and while it can still theoretically connect to a network where 802.11r is enabled (from what I can see in the Cisco forums) it is strongly recommended not to turn it on.   Have you done an active Site Survey? It is very important to see these parameters are on comply with VoIP requirements (plus any additional ones you see on the deployment guide, but these are the main ones):   - Co-Channel Interference (no more than three APs heard at the same time, with a difference of at least 20-25 dBm SNR on the non-overlapping part) - Signal received (between -67 and -65 dBm over all the cell) - SNR (more than 20 dBm if possible). - Jitter(the closest to 0 the better). This can have a high impact on your calls.   Additionally, on the LAN side, everything should be able to handle QoS marking and prioritize the traffic accordingly to this tagging. Here are some documentation you would like to see about how to deploy a wireless network and how to tune it:   https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Channel_Planning_Best_Practices https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wireless_fundamentals%3A_Signal-to-Noise_Ratio_(SNR)__and_wireless_signal_strength   And we also have a general guide to deploy voice over Wireless, you may find it very useful:   https://documentation.meraki.com/MR/Deployment_Guides/Wireless_Voice_Deployment_Guide_(CVD)   And two very specific - the first one is part of the deployment guide, the second one a Cisco guide for deploying this phone with Cisco Meraki wireless infraestructure.   https://documentation.meraki.com/MR/Deployment_Guides/Wireless_Voice_Deployment_Guide_(CVD)#Cisco_7925G_Phones https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cuipph/7925g/7_0/english/deployment/guide/7925_Meraki_dply.pdf   Hope this helps      ... View more

Good to know this helps you. I would also recommend for such a large deployment (17 floors) to plan the deployment using a tool like Airmagnet or Ekahau (there are more but these are the ones I've worked more with) because signal tends to leak between floors and the channel planning and transmit power needs to take that into account, and these tools are very good to simulate it, and after the deployment, they are also good for validating the whole deployment. ... View more

To be totally honest the definitive way is to do a Site Survey that includes a Spectrum analyzer. And even while this is very useful when it comes to intermittent interference (i.e. an engine in a warehouse that only works for 20 minutes a day), it can be very difficult to pinpoint if the issue is related to interference.   As it was pointed before, if you go to Wireless > RF spectrum you can see the actual RF surrounding the AP.   It is also very helpful if you go to Wireless > Access Points and click on the RF tab, where you will see a log that includes channel utilization, clients, usage and most important of all, events, over a period of up to 1 month. ... View more

The major problem with having many concurrent users on an AP is the contention window each end device has to go through for actually being able to transmit something into the air.    This is usually solved by:   - Deploying more APs. - Reducing the effective cell size by reducing the transmit power and increasing the minimum bitrate. - Placing the APs nearby the end devices.   If you want to see if the issue is related to channel utilization, you can look at Wireless > RF Spectrum which will tell you the actual utilization of the channels you are using.   Additionally, if you think this may be due to cells being too large and frames collisions, you can capture a monitor mode PCAP nearby one of the APs.   Here we have a really good document on how to do this monitor mode captures:   https://documentation.meraki.com/MR/Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Client_Machine   Alternatively, I would recommend Airtool by Adrian Granado's if you're using a MacOS device to do the captures. After taking the PCAP, apply this filter on Wireshark: (wlan.fc.retry == 1) which will show retries percentage.   As a guideline, anything above 10% is usually not acceptable in most designs. We have a really good KB for channel deployment best practices.   https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Channel_Planning_Best_Practices   Hope it helps  ... View more