Top Ten Tune-up Tips

Much of the work I do on customer networks these days is repetitive. That’s not to say that it’s always simple work, but I do see the same things over and over again.

This blog does not take into consideration minor/unique system configuration tweaks. It does, however, take into consideration that some features should be enabled by default on ALL vendors’ systems. Such an example would be Block Acknowledgements (BlockAcks). BlockAcks are optional, but enabled by default on most vendors’ systems for 802.11n/ac.

Another example is frame aggregation. 802.11n and 802.11ac require that frame aggregation be supported, and there’s no reason that comes to mind as to why you would ever want to disable it anyway.

One last example is WMM QoS. Since WMM QoS must be enabled (per the Wi-Fi Alliance) to support 802.11n and 802.11ac MCS rates, most vendors enable it by default. It’s noteworthy that some vendors enable the minimum WMM features required by default (not allowing you to disable them), but allow additional WMM features to be enabled or disabled. This configuration “scheme” prevents the end user from accidentally disabling 802.11n/ac data rates.

This blog does not address 802.11a/b/g systems because the obvious answer to performance improvement for these networks is to upgrade your system to something more modern. 802.11n/ac systems are available from a wide variety of vendors in a wide variety of costs. There’s something available for everyone. Without further ado, let’s get into it.

#1 Minimize (or Remove) 2.4GHz

I’ve written a whitepaper on why this is important and a blog on how to begin making this transition. If you still have questions on why this is important or how to do it, please offer your questions in the comments section below. Many individual performance improvement tips can be ignored if you’ll just stop using this band wherever possible.

If use of 2.4GHz is required at some level, then it’s very important to do a spectrum analysis to see what types and how much RF interference you’re dealing with. There’s ALWAYS interference.

#2 Optimize Infrastructure Data Rates

A close 2^nd place, the importance of optimizing data rates cannot be overstated. Vendors offer different capabilities on how and how much data rates can be tweaked. For example, Aerohive offers the following, very granular, configuration settings in the SSID profile.

As another example, in an attempt to hide complexity, Ruckus Wireless makes you dig a little for data rate settings and has less granular configuration settings for data rate optimization. Going into the CLI via SSH (or Telnet or Console) and using the bss-minrate X command (where X is the data rate) is required to set a minimum basic rate. Note that some rates are not allowed when using this command simply because Ruckus chose not to allow them.

My preference, based on experience, is to go with 12Mbps as the minimum basic rate (“Basic” means “Required”), with no data rates supported below it (as shown in the Aerohive screenshot above). The reason that I choose this rate, when possible, is:

• Some clients experience issues with 18Mbps minimum rates
• 12Mbps allows the beacons to be decoded reliably during client handoff
• When combined with other features, can assist in forming smaller cells, which increase overall network capacity
• It disallows all 802.11b clients

If transitioning from a coverage-based design (often having a 1Mbps minimum basic rate for 2.4GHz and 6Mbps minimum basic rate for 5GHz) to a capacity-based design, making such a drastic change without optimizing AP placement can create coverage gaps. Making this kind of change is best accomplished when you are willing to move and add APs as needed to optimize the network design.

#3 Upgrade Your Client Devices

Client devices make up most of the radios on the network in most cases. Strategies to upgrade your client radios include:

• When laptop refreshes happen, make sure to buy laptops with integrated 802.11ac radios
• Buy tablets and smart phones (or encourage employees to do this if it’s a BYOD environment) with 802.11ac when possible

If you’ve optimized your data rates as I’ve suggested above, you won’t have to worry about 802.11b clients connecting to your network. It’s important to get 802.11a/g clients permanently off the network at your earliest convenience because they cause the use of protection mechanisms such as RTS/CTS and CTS-to-Self. These (and other) protection mechanisms can cause an instant loss of up to 40% of a channel’s airtime.

#4 Minimize SSIDs (Beacons)

I define a “beacon stream” as a set of beacons, being transmitted at ~10/second, from an AP radio. A beacon stream is created by adding an SSID to an AP radio. Beacons can be quite large (250+ bytes), and when transmitted at ~10/second at a low data rate, a huge amount of airtime can be consumed. To give you perspective on just how much airtime, my friend Andrew Von Nagy has created an extremely useful tool called the SSID Overhead Calculator. Download it and change the Beacon Data Rate in the top-left corner. Then look at the number of SSIDs you have. This is a great tool to aid understanding of why you must minimize the number of SSIDs on every radio in order to enhance performance.

Many end users that I work with have as many as 10 SSIDs per radio using 1Mbps (2.4GHz) and 6Mbps (5GHz) minimum basic rates. This is airtime death due solely to beacon streams. When modulated and unmodulated non-WiFi interference is then factored in, you begin to understand why this is so important.

#5 Channel Width

In 2.4GHz, you should always use 20MHz channel widths. In 5GHz UNII bands, the channel width you choose should be based on your design goals, your AP and client device capabilities, and the level/type of interference in the 5GHz bands.

If your APs and clients are capable of using DFS bands, then you (or your vendor’s RRM algorithm) will have significantly more frequency space to work with in forming a channel reuse plan. In this case, I recommend use of 40MHz channels. I’m not yet confident in using 80MHz channels, even when there is enough channel space for a 3 or 4 channel reuse pattern. I’m hopeful that my mind on this matter will change with the introduction of equipment that complies with the new FCC rules of April 2014. The reason that I recommend 40MHz channels is because they offer significantly higher throughput at only slightly-decreased range (-3dB), and best of all, 40MHz channels allow data from 802.11n or 802.11ac to move across the channel faster, conserving airtime.

With 80MHz channels, you will lose another 3dB of signal strength, decreasing rate-over-range. Very high power is required to obtain 256QAM modulation with 80MHz channels, so careful channel planning must be done in order to minimize CCC and ACI.

If most/all of your clients do not support DFS bands, then I recommend using only 20MHz channels, as use of DFS bands on your APs could create areas of no 5GHz coverage for non-capable clients. In the US, this would still give you 8+ channels to work with across UNII-1, UNII-3, and Channel 165.

#6 Get Rid of TKIP

I previously mentioned that WMM QoS must be enabled before you can use 802.11n/ac MCS rates. The same holds true of getting rid of the TKIP cipher suite. If TKIP is enabled on an SSID, then clients connected to that SSID will be limited to using data rates up to 54Mbps. No 802.11n/ac data rates will be used by the AP or client device for that SSID. This means that you must configure the cipher suite to CCMP (AES) only on all SSIDs where you want encrypted data. “Open” SSIDs (no encryption) may also use 802.11n/ac MCS rates. You may not use “Auto” as the cipher suite, such that both CCMP and TKIP are supported, as that will disable 802.11n/ac MCS rates. TKIP must be fully disabled.

#7 Do an RF Site Survey

Just do it. Please do it. If you won’t or can’t pay for it or don’t know how to do it, you’re in the majority. In these cases, there are some options that are better than nothing.

• A basic scanning tool such as Wi-Fi Scanner or Wi-Fi Explorer
• A rudimentary surveying tool such as Netspot or Heatmapper

Without being able to see anything, everything related to performance improvement becomes guesswork. The more comprehensive and accurate your site survey, the better decision you can make on what changes to make to positively affect performance. It’s as simple as that.

#8 Disable Background Scanning (if possible)

Many end users over the years have chosen to take the least expensive road to wireless intrusion prevention services (WIPS) by using their APs as background scanners. The industry has nicknamed this technique “time slicing” because APs must periodically go off the channel where they are serving clients in order to scan for rogue devices or policy violations. This approach can severely degrade an AP’s performance (and hence the entire system’s performance) because the AP isn’t constantly serving client devices. As client densities increase, performance degrades even more quickly.

For this reason, it’s strongly suggested that you disable background scanning if possible. The highest performance monitoring solution will always be an overlay WIPS….and before you go and get bent out of shape, hear me out on this. An overlay WIPS doesn’t require a second, specialized vendor, but rather can be an overlay of more of your own vendor’s APs that are set to “scanning only”. Your vendor’s WIPS feature set may be just fine to meet your needs, but it is worth noting that most infrastructure vendors’ WIPS features do not compare well against dedicated WIPS vendors (for obvious reasons). Your decision on which vendors’ WIPS to go with should be based on your specific organizational security requirements.

#9 Continuous Monitoring

This is not a sales pitch. J You can’t measure what you can’t see, and therefore I suggest that continual performance monitoring is imperative to maintaining good performance over time. Some performance problems are intermittent, and the only way to catch them is with continuous monitoring. Consider the dreaded “beacon stuck” problem that so many vendors’ APs deal with. When beacons stop (due to a code bug), then clients disconnect and roam to another, likely sub-optimal AP. The AP experiencing the “beacon stuck” problem may automatically reboot or may remain stuck indefinitely. The only way to know what kind of problems are happening, and if they get fixed (perhaps with a code upgrade) is to continually monitor the network.

There are a variety of systems on the market (AirMagnet Enterprise, 7signal, and others) that can help with performance monitoring, and some infrastructure vendors have integrated performance-monitoring features. If using infrastructure-integrated performance-monitoring features, you should test those features and see if the tests and reporting features give you what you’re looking for. Compare those integrated features to those dedicated performance-monitoring vendors on the market to see where they are deficient.

It’s important to note that a site survey is not a substitute for continual monitoring by a system with the right kind of performance-monitoring features. Client devices cause a tremendous amount of RF interference, and many times that wouldn’t be seen by an RF Site Survey because: 1) passive scans monitor only beacons, 2) active surveys would have to take place during business hours to be affected by client interference.

#10 Other Stuff

While this blog isn’t meant to be comprehensive, there are many other factors that cause performance degradation, such as:

• Nearby cellular (e.g. Distributed Antenna Systems (DAS)) and whether or not your AP has a cellular frequency band filter.
• Poor quality, misaligned, or wrong type (e.g. wrong impedance) external antennas on APs
• Saturated channels
• Load balancing isn’t working properly (too many clients on an AP while other APs are under-utilized)
• Band steering isn’t working properly
• 11 Management traffic overload
• High retransmissions
• Output power at the AP or client is too high or low (could be a malfunctioning RRM algorithm)
• Issues with the wired infrastructure (slow Ethernet switching, slow AAA services, insufficient PoE budget, old cabling, etc.)
• Excessive client roaming (including thrashing between APs)
• Software-based performance tweaks in the management system (e.g. SGI, Aggregated Frame Size, Probe Response thresholds, etc.)
• Coexisting systems (from different vendors) on the same Ethernet network. There are a variety of configuration issues that must be addressed for this to work properly.

It’s important to mention that there are some “tweaks” that I don’t recommend, such as changing the beacon interval (ever!) or the DTIM interval (usually). There are corner cases where adjustment of the DTIM interval can help with handset battery life, but it’s rarely so important that you should mess with it. It’s almost always defaulted to 1, and that’s good in 99% of the use cases. If I casually strolled through a Wi-Fi Management System’s GUI, I’m sure I could be here for 5 years writing about what “to do” and what “not to do” in various cases, but hopefully this blog has served its purpose of getting your network into reasonable shape.

As always, your comments, feedback, and suggestions are welcomed!