This week in wireless we have a round of news to cover. Below are what we discuss on the show with our opinions. I apologize for the briefness of the show notes. I, Rowell, am traveling this week.
Rowell and François discuss their tips and advice when running a Meraki Wi-Fi network in challenging environments such as warehouse, hospitals, and dense office environments.
Meraki Wi-Fi Tips
There’s a big appeal for organizations to use Meraki. The ease of management is the biggest factor. With the management interface being user friendly and the hardware having a very minimalistic look and feel, there’s no question why it’s so popular.
But making something easy to use does create other challenges when it comes to Wi-Fi. Some scenarios are not as easily solved with Meraki, or any other vendor for that matter. There are a lot of configurations which could lead to poor performance. We’ve seen it before with our existing clients and wanted to offer our tips.
Design
We’ve noticed many people opt to skip design altogether. Or maybe they are unaware that a design is needed. This is the biggest mistake. Before we dive into Meraki specifics, we wanted to take this chance to remind everyone to have a design completed by a Wi-Fi expert.
Know your devices and applications
Planning and design are critical. This involves knowing what type of devices will be using Wi-Fi. Those devices will dictate how your configuration will be for your Meraki network. We’ve seen many misconfigurations which lead to users complaining about Wi-Fi performance due to not knowing how the devices utilize Wi-Fi and what applications are being used.
Turn off 2.4 GHz radios
By default, every single 2.4 GHz radio is enabled. In a warehouse, every AP can hear each other because of reflections and open space. Signal travels very far. In one example, a warehouse was seeing over 60% channel utilization on every AP in the 2.4 GHz spectrum. After about half of the radios were disabled, the channel utilization dropped to under 20%. A design will provide indicate which AP should or should not have a 2.4 GHz radio enabled. Coverage holes should not be created if devices must use 2.4 GHz.
Channels
With every radio being enabled by default, we must keep in mind what channels are being used and how much we can reuse. Using wider channel widths can look appealing because of the high throughput but at the cost of minimizing how many channels you can reuse in your environment before causing co-channel contention. Again, a design will produce a channel plan in both 2.4 GHz and 5 GHz. Our guidance is to stick to 20 MHz or 40 MHz wide channels.
Transmit Power
All we have to say here is tune down the power. There’s no need to transmit at full power. That signal travels very far and can contribute to co-channel contention. Sometimes the AP cannot hear the client device transmitting back to the AP because clients don’t have the same power capabilities as APs. Use a design to determine the transmit power settings of an AP.
Placement is key
Again, we must reiterate the benefits of doing a design. Placement is important especially when dealing with scanner guns, roaming clients, and VoIP calls. APs placed away from obstruction will provide the best performance and will minimize the amount of client issues.
External antennas help tremendously
Sometimes omnidirectional antennas just don’t do the job. We need to provide better quality signal to the clients and this is where antennas help a lot. You can shape the signal you want, for example, down an isle. Or if you need to wall mount an AP but direct a signal to a specific area then an antenna can do that job for you.
Client balancing
Sometimes the client balancing feature within Meraki can cause issues with clients on voice calls. I’ve seen clients on a VoIP call get dropped due to client balancing. In a warehouse, scanner guns weren’t roaming properly because some APs had more users than others so client balancing was affecting how users were roaming.
Band steering
Clients ultimately decide where they want to go. So why force them over to 5 GHz if 2.4 GHz is better? Or maybe the device is a 2.4 GHz only client? Another way of doing this is to create two specific SSIDs for each band. Either way, sometimes band steering doesn’t work the way we expect it to because clients control where they want to go.
RRM
RRM can be a very useful feature if you have many APs. It can help tune your environment. But most people don’t tune their settings in favor of RRM. So we see suboptimal settings selected for each AP. Honestly, sometimes the Meraki algorithm doesn’t pick ideal settings. Sometimes static configuration can be beneficial if RRM isn’t making the right choices.
Hidden network for mesh
If you aren’t using mesh capabilities, submit a ticket to have this feature turned off. By default there are hidden networks being broadcasted for mesh. You don’t see them but they show up on a validation survey.
Meraki Weirdness
Are you seeing these narrowband spikes when viewing the RF Spectrum within the dashboard? Do you see the same thing at channel 1, 4, 5, 9, and 11? Here are examples from our networks:
Cisco Meraki is rolling out the new Meraki Health dashboard to customers. The goal is to allow IT staff to quickly identify root causes to various Wi-Fi issues. It’s the common trend amongst cloud-managed Wi-Fi vendors.
Troubleshooting Wi-Fi connectivity is a difficult skill to master by an individual. Without the in-house expertise, IT is often left relying on dashboards to tell them what’s wrong.
Heuristic Approach
Meraki Health is taking a heuristic approach to troubleshooting. The dashboard uses a technique to help in problem-solving by learning and discovering what’s happening on the Wi-Fi network. Then those root causes are presented on-screen.
This new visual method of troubleshooting allows a quick look into what types of issues clients are experiencing. It can be narrowed down to specific access points and into types of applications.
The Client Journey
We’re provided insight into the client journey on a Wi-Fi network. Meraki Health takes a look at 5 different steps of the client journey:
Association
Authentication
DHCP
DNS
Latency
At each step there’s a visualization into the percentage of successful or failed connections. Breaking out each step provides a simple approach to troubleshooting and getting down to the real cause of the issue.
An example could be at the authentication step with a user incorrectly typing in the password for the SSID.
Latency visibility offers insight into how applications are performing over Wi-Fi. Latency is broken down into traffic types, drawing similarities to QoS traffic types. The visualization indicates the percentage of latency traffic encountering poor performance.
The scope can then be narrowed down to specific applications such as YouTube, Skype, or other applications.
Spotting the anomalies
Rowell’s Take
It’s a great addition to the Meraki solution. By giving the power to network operators, they are more capable of solving some of the most common Wi-Fi issues. The biggest advantage with Meraki Health is the ability to solve these issues quickly.
What I find interesting is Meraki Health takes a heuristic approach rather than stepping into artificial intelligence and machine learning to take troubleshooting to the next level.
Meraki can leverage their cloud infrastructure to build a solution which can help solve issues automatically by learning client traffic patterns and flows to help the network tune itself. For example, seeing where an area is about to become highly dense with devices and capacity is to increase.
The dashboard can help network operators become more proactive over these situations by bringing it to attention before the event impacts clients.
François’ Take
Meraki is often used by customers having a small IT team without extensive Wi-Fi expertise. So this new feature is a great tool which will help them to troubleshooting day-to-day Wi-Fi issues. I won’t be surprised if this feature keeps getting better over time so it can be used and understood by most IT professionals.
I believe it is very interesting to see network companies spending more and more time on developing software which will help the customer provide a better over solution. It is just the beginning. I am expecting to see more and more vendors coming out with software solutions in order to complement their hardware offers and help the users better take advantage of the hardware. It is also a way for them to create a competitive advantage over the competition.
User experience is very important for me on every project I work on and that’s why I like this new Health feature as it helps us to provide a better user experience overall.
What’s coming up for Wi-Fi with developers and how can we learn to automate our Wi-Fi day-to-day?
DevNet Create 2018
I was expecting to be amongst the developers but I left feeling inspired about what we can create while working with Wi-Fi. This was my first time attending DevNet Create and it certainly won’t be my last.
The event was held at the Computer History Museum in Mountain View, California.
It’s not too far from Googleplex so I could already smell the scent of developer..just kidding.
This small event had maybe around 300 attendees. Each workshop was held on in a large room where the presenter spoke to a small crowd. Very intimate.
DevNet Create had an interesting agenda line up. I was primarily interested in the workshops which had to do with Wi-Fi. The sessions I joined in on were:
NetDevOps Engineer Everyday Skills
Gabriel Zapodeanu | Cisco, Global Partner Organization
Do you want to learn how to write simple ChatOps apps for IOS XE network devices? This session will explore a few IOS XE device programmability capabilities to help you create your first ChatOps application using NETCONF, RESTCONF, and Guest Shell.
Planning to join the workshop?
Indoor Location-based Services Using Wi-Fi
Mathieu Gerard | Mapwize
In this workshop, we will build a simple mobile application allowing users to view the map of the building, see their position provided by the Cisco CMX or Meraki infrastructure, and get directions across multiple floors.
Automate your Network with Python and Meraki
Colin Lowenberg | Cisco, Meraki George Dorsey | Cisco, Meraki
You only need a basic understanding of programming and Meraki to complete this quick lab. Take Cisco’s own internal training on Python for network automation. We will walk through the setup on your laptop and use a pre-written Python script to interact with the Meraki Dashboard API.
Introduction to Meraki API’s Through Node Red
Michael Chenetz | Cisco
Meraki is intended to be an easy platform. So why not have any equally easy way to program interactions through the use of visual programming? In this talk I’ll introduce you to Node Red for Meraki. Learn programming by combining objects to create applications.
Planning to join the workshop?
Anyone who attended the event had a chance to get a free Meraki switch with a 3-year license by just completing a Meraki challenge. You yourself can try out the challenge (minus receiving the free switch).
Overall, I thought it was a great event. I was able to meet up with good friends and learn how automation and coding can help us in our day-to-day jobs. I feel very inspired about what I may be able to do in the near future. At the end of the conference I purchased my own copy of Learn Python 3 The Hard Way.
The earliest Cisco WLC version where Cisco CleanAir was released dates back to the 7.0 days. Sometime around the year 2010. Cisco CleanAir is always on within an AP, granted if it is Enabled in the WLC. There is a Spectrum Analysis Engine (SaGE) chip built into the AP. This is important to know because it doesn’t prevent the AP from serving clients. SaGE works alongside the Wi-Fi chip. There is no affect to client throughput or traffic.
To enhance Cisco RRM’s features, CleanAir plays a critical role in allowing RRM to change channels if persistent interference is detected. CleanAir will field the appropriate algorithms to help the WLC make changes to improve an environment.
Cisco CleanAir produces two important elements:
Interference Device Report
Air Quality Index
The Interference Device Report (IDR) provides information on detected interference. It will provide a class type, what band the interference was detected on and on what channel(s), the severity of the interference, it’s duty cycle, and the interference signature.
The Air Quality Index (AQI) provides a quality score, from 0 – 100%, with 100% being good. The index will display total channel power, total channel duty cycle, the power of the interferer and total interference duty cycle.
A benefit of using Cisco CleanAir is having the ability to troubleshoot the shared spectrum remotely and without any additional hardware. A CleanAir supported access point can be utilized for this purpose. Some things to keep in mind when using your CleanAir access point for troubleshooting interference:
There are three modes:
Local – The AP will continue to serve clients on its operating channel. But any spectrum monitoring is performed on that channel only.
Monitor – The AP doesn’t server any clients but provides full time scanning.
Spectrum Expert Connect – This is a dedicated spectrum sensor and doesn’t serve any clients.
In times when the best response is to use technical support hands to troubleshoot the issue, having a method of automatically mitigating an interference issue can be highly beneficial. It can cut time to resolution down and react faster than a support team that is reactionary.
What we’d like to see from CleanAir is the ability to tell an administrator whether any action needs to be performed. While interference and air quality is determined on any given channel, does it even matter? Are any users impacted negatively? A smarter system would be able to detect interference and provide exactly which users are having issues directly related to this interferer and what kind of impact that is. And a step further would be to automatically adjust the system to fix the problem.
We’ve included some images of Cisco CleanAir in action from within Spectrum Expert and Metageek Chanalyzer.
