This topic is a chance to discuss more about the best practices, considerations and proved guidelines to configure, monitor and troubleshoot 802.11 wireless services under Meraki Cloud-Based architecture. The session focuses in the following topics:
To participate in this event, please use thebutton below to ask your questions
Ask questions from Monday 6 to May 17th, 2019
Edgar Monroy is a Support Engineer for Cisco Meraki Products, he covers MX, MS, MR, MV and SM. Before joining Meraki’s team he worked as a Cisco Customer Support Engineer for Cisco’s TAC for 4 years. He specializes in 802.11 technology and he has experience in the entire Cisco Wireless Portfolio, including CUWN, Mobility Express, Prime Infrastructure, MSE, CMX and Meraki MR Products. Edgar holds a Bachelor’s Degree in Electronics Engineering from the UDFJC University in Colombia. He holds a CWNA and a CCNP R&S certification.
Remember that you can continue the conversation on the Wireless and Mobility community.
**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions
I've two questions:
First- Before Implementing, is here any software or steps to follow in order to set the necessary Aps (quantity) you need to implement on the location?
Second- Which are the features that remarks Meraki technology against other competitors?
Hello @Daniel Martinez,
The success of any wireless implementation is proper design and analysis of the RF conditions before the deployment. Meraki solution provides a way to get the necessary information to understand the AP cell propagation so you can use that information to determine the position of the APs, then confirm proper coverage and an appropriate cell overlapping between APs. Meraki Access Points can work in Site Survey mode, this mode creates a test SSID that you can use to perform passive or active site surveys. Details on how to convert a Meraki AP into site survey mode can be found at:
There are multiple factors to take into account at the moment of designing a wireless network and choose the appropriate number of APs, depending if you need to provide service for a high number of clients on "small" areas (high density), or have few clients but with the maximum throughput, you may want to use different approaches. Take a look at the following link that describes some key considerations for specific wireless network scenarios:
The most important factor that differentiates Meraki against other vendors (and not only for wireless applications but for the entire Meraki portfolio) is simplicity. Meraki provides one of the most simple ways to deploy a powerful wireless network with the least required effort, this differentiator does not only apply for the implementation but also for the management and monitoring of the Network:
The best way to understand how simple and powerful Meraki products are is by hands-on experience, I invite you to apply for a free trial so you can try all the features that Meraki wireless can offer. go to https://meraki.cisco.com/lp/free-demo
Thank you for this event. I have two questions:
1. How do I enable site survey mode using 5ghz only?
2. I have an android device that will associate with the AP but is unable to view the splash screen to accept and authorize. What steps can I take to troubleshoot a device like this from the Meraki side since I don't have access to clients?
When converting a Meraki AP to Site Survey mode, you have the option to define the power that will be used by each radio, including the option to keep the radio OFF. The following image will show how to make the AP broadcast the Site survey SSID on 5GHz only:
Here is the expected traffic flow between the wireless device and the Access Point that allows the redirection to the login page:
Full details of the splash redirect flow at: https://documentation.meraki.com/MR/Splash_Page/Splash_Page_Traffic_Flow_and_Troubleshooting#Splash_Flow_Breakdown
Remember that before a client can initiate an HTTP request, it should have already been able to get a valid IP address, get proper connectivity to its gateway (ARP resolution), and resolve DNS. Once DNS provides the IP address to the web resource, the client should then send the HTTP GET which is intercepted by the AP who replies with an HTTP 307 'temporary redirect'.
In order to verify the proper traffic flow between the device and the Access Point, we have 2 options:
Full details on how to set up a packet capture, not only for wireless but for any other interface of any of the Meraki appliances, at:
NOTE: Over-the-air packet captures won't display the Layer 3 traffic information if the data payload is encrypted. In order to get the necessary information (DHCP, ARP, DNS, HTTP), the SSID must be configured without any encryption method (Association Requirements: Open, No encryption).
We currently have Meraki deployed and want to use Traffic Shaping to help with UDP Loss Rate for Webex. We use this page to do our testing - https://mediatest.ciscospark.com/#/main On wireless we still get 2% to 4% loss sometimes - seems random.
We have enabled the default rules (which include Webex, Skype). We also "Shape traffic on this SSID" enabled.
We have "mls qos trust dscp" setup on the switchports that the AP are connected to.
Is there anything else we can configure/setup to help us with this?
Wireless QoS relies on the DSCP marking of the packets done by the wireless client to assign the packet into the proper priority queue so the upstream traffic can have better chances to avoid losses over the air. As long as the packets are not marked properly before they are sent to the air, you will be susceptible to delays and potential drops.
Meraki Access Points can identify the traffic based on the application type, and they can override the DSCP marking of the packets in the case that the packets are not marked properly by the end device.
This is an example of the Webex meeting traffic using UDP 9000 (Webex UDP test seems to use UDP port 5004), the wireless client did not mark the packet with QoS priority going to the air. Without Meraki QoS traffic shaping, the traffic is not enforced with the appropriate DSCP when it goes to the switch:
When Meraki QoS is enabled, you will notice that the DSCP vlaue is modified and the upstream traffic is now passing to the switch with the proper DSCP value:
As you are trusting the DSCP value, the switch will effectively manage the upstream traffic accordingly.
In order to enable the default QoS markings, go to 'Wireless - Configure - Firewall and Traffic Shaping. Make sure that the Traffic Shaping rules are enabled.
UDP port 5004 is not currently considered as Webex traffic, so you may need to also setup a custom QoS rule. See the image below that will describe the proper QoS configuration:
Besides QoS marking, there are other considerations to mitigate issues that can impact the performance when the packets travel over wireless. Meraki has a really nice configuration guide to provide the best experience for real-time applications. Please refer to the following link:
In summary, make sure that the SSID provides the best conditions to reduce frame loss (proper site survey, use of 5GHz-only, proper bitrate limit to non-media applications).
I would like to know if Meraki offers custom application detectors, something like what Firepower offers for FMC+FTD.
if not what do you suggest to be the best option to classify traffic for voice via softphones at the APs? simply destination IP ranges?
Meraki Access Points are capable to perform traffic analysis to determine the application used by the wireless clients, this information can be used to enforce layer 7 Firewall rules and Traffic shaping (Bandwidth Limitation and QoS Marking).
Meraki provides pre-defined application categories for the most popular services, but you can also define custom signatures that detect the attributes of HTTP hostname, port number, and IP range:
For voice applications, the current pre-defined applications are for Dropcam, SCCP, SIP, Skype, Vocera and WebEx.
Details for traffic shaping over wireless at:
Hi Edgar, I have 2 questions:
1.-Does Meraki support Bonjour like Cisco WLC?
2.-Why the dashboard does not work properly when the AP renew its IP?. my AP renewed the IP from the one registered initially on the dashboard, now the dashboard is unable to manage the AP. Unclaiming, removing from the network the AP, etc did not help. Any clues?
Yes, Meraki SSIDs can forward the mDNS requests from the wireless devices to the specified VLAN where the Servers are located, you can also select which services will be forwarded. Many rules can be created if different services are located on different VLANs.
The Bonjour gateway configuration is applied by SSID. It is supported if Bridge mode (client traffic is placed to a VLAN existent at the AP trunk) or Layer 3 roaming mode are used. Details at:
Assuming that the new IP address on the AP allows it to reach back to the Meraki cloud, the dashboard should report the AP as connected regardless of the previous IP configuration.
I suggest the following steps to try to recover the IP connectivity to the Dashboard:
If the issue persists, feel free to reach to the Meraki Technical Support Service, which is available for every Meraki Customer. I recommend calling the phone numbers as this is the fastest way to get an expert and get the AP connected back in minutes: https://meraki.cisco.com/support