SMB Wi-Fi done right: 7 best practices you likely aren't following
If there is one thing that doesn't shock me anymore, it's the fact of how prevalent and pervasive incorrectly deployed Wi-Fi is across the small to midsize business (SMB) landscape. The sober reality is that Wi-Fi has an extremely low barrier to entry thanks to a bevy of options on the market.
But a well-tuned setup that accounts for proper coverage levels, speeds, and client counts in a measured manner is almost as much of an art as it is a science. Hence why more often than not, clients are calling us for an SOS to help save them from their own Wi-Fi hell.
A few years ago, I penned a fairly detailed article outlining some of the key best practices that we were using in the field for our client-facing deployments. While much of that piece is still fairly accurate, a few years have gone by and in that time, the new realities of 802.11AC and high-density Wi-Fi environments have become commonplace. As such, I'm of the opinion that a 2019 edition of these best practices focusing on the missteps we are consistently seeing in the field is warranted.
This collection of best practices is gleaned from many years of high stakes installs that my company FireLogic has done across numerous verticals; for offices of all shapes and sizes; with endpoint counts of just a few up to nearly a thousand concurrent users.
I won't toot my own horn to say we've seen it all, but we've seen quite a bit over the years. These diverse environments all have their strategic challenges that require following some basic principles which are fairly universal in their applicability, and scale quite well.
Where exactly is your SMB falling short when it comes to your Wi-Fi deployment? Here's a few key areas that we're consistently cleaning up at client sites.
8. Hardline Access Points Always Beat Mesh Wi-Fi
Yes, I get it. The promises of mesh Wi-Fi are all the rage of 2019, and while I don't dismiss the technology entirely, there is a constant truth that has yet to be disproven in our installs: if you can hardline a wireless access point (WAP), it will always outperform a comparable mesh unit.
There is just no way around it. While the marketing gurus pushing mesh systems like Eero and Google Wi-Fi and Orbi are keen to outline all the great points about mesh, they fail to shed light on many technical realities of mesh that will be hard to overcome. I'm not the only one willing to point out these shortfalls; vendors like Engenius (who, full disclosure, indeed even sell mesh Wi-Fi devices) have KB articles which admit that mesh networks will never perform as well as hardline-based WAP networks.
Without getting too technical, a couple of technical roadblocks hamper mesh Wi-Fi from the outset. First, by their very nature, they rely on wireless backhaul between downstream units. Some of the manufacturers do a better job than others, by utilizing dedicated 5Ghz radios for backhaul duties, but even still, there is only so much airspace available to share.
And this airspace is ever more congested, especially in the dense urban areas of metro Chicago where our company services clients. 2.4GHz spectrum is almost becoming unusable due to competing networks, and 5GHz is running up against similar realities due to sloppy fat-channel broadcasts that eat gobs of airspace so they can achieve fancy throughput levels.
This constant fight over airspace plays into less available spectrum for, you guessed it, that wireless backhaul mesh units rely upon.
While mesh Wi-Fi vendors don't want to admit it, hardline access points will outperform a mesh deployment any day of the week. The problem with mesh is twofold. Not only do wireless links between mesh units rely on already overly congested Wi-Fi airspace to transmit their backhaul traffic, but they introduce latency for every extra hop which is amplified the further this chain gets. All in all, mesh is an imperfect solution that should never be used when hardline WAPs are a viable option. (Image Source: UBNT)
Hardline access points, like the kind we routinely install at offices and even larg homes, rely upon dedicated CAT6 feeds that don't have any airspace congestion to worry about, and they can push a solid 1000Mbps connection to each access point with no speed degradation (assuming clean switching and cabling, of course).
This means that not only are we avoiding congesting limited airspace with backhaul traffic between mesh units, but we are offering higher overall bandwidth ceilings to clients being fed from access points.
An added bonus for CAT6-fed access points: They can be fed via Power over Ethernet (PoE) which means zero unsightly, honking power adapters that need AC outlets for each mesh unit location. In general this means we can end up with cleaner installs with no cables showing of any sort - something mesh installs can rarely achieve.
If you are going to be using mesh, it's likely as a last-resort only due to an inability to run CAT6 lines or some other circumstance-specific reality.
But I would never, ever consider mesh my first choice for office-wide Wi-Fi.
7. Stop Splitting Up Distinct SSIDs For Separate 2.4GHz and 5GHz Broadcasts
For a practice that is so 2005, this is a pet peeve of mine that is not dying easily. And it seems to be coming down to a lack of concerted end-user education, and vendors which are sloppily still recommending this practice during self-staged setup of gear. In short, there is zero reason to configure a modern commercial Wi-Fi network with a separate 2.4 and 5GHz broadcast SSID and there are numerous reasons for this.
First, modern devices have Wi-Fi chipsets which are smart enough to choose the proper band, for the given time and location, on their own. Years back when Wi-Fi was still immature, this logic wasn't as great and devices couldn't handle this with great confidence. But the maturity of dual-band chipsets for at least half a decade now has negated this need. Even in situations where you think you've got better insight into the airspace realities, the device usually has the upper hand since it's calculating spectrum decisions in real time.
Second, the splitting of SSIDs into 2.4 and 5GHz networks simply leads to user error which causes more issues than anything nowadays. End users may be at one end of an office and connect to the 5GHz variant naturally and then roam to another part of the office where that broadcast may fall off (since 5GHz can only travel about half as far as a comparable 2.4GHz broadcast) and then they are in a never ending decision loop about what Wi-Fi to be on. Simply stay on the 2.4GHz variant and deal with more interference and slower speeds or disconnect/reconnect when in different spots in the office to a 5GHz signal?
It's a ridiculous rodeo that I see all too often and have to shake my head at.
Commercial Wi-Fi gear these days, such as Cisco Meraki's MR access points we use heavily, can broadcast a unified SSID across both spectrums and allow devices to connect on whichever band is the better option. For high density deployments, you can enable band steering which can force 5GHz capable clients to move to that band when possible, to reduce 2.4GHz spectrum usage.
But it still goes without saying: there is zero logical reason to be doing segregated 2.4/5GHz SSID names anymore as it serves little functional benefit and ends up hurting end users more than it helps.
6. Any Deployment Beyond a Single Access Point Needs a Wi-Fi Controller
If your SMB has any sizable deployment of wireless access points (WAPs) beyond a single unit, you should be using a proper Wi-Fi controller to manage the devices. In the wild west days of Wi-Fi, this was not as much of a concern since airspace control used to be quite primitive and outright sloppy. But modern deployments have to deal with innumerable sources of ongoing airspace congestion, client load levels, Wi-Fi power levels, and roaming concerns, to name just a few key management concerns for today's WAPs.
Especially on very large deployments, controllers play "quarterback" of the entire WAP rollout to ensure many factors are being actively managed and adjusted. For example, they enable for clean seamless roaming between access points so endpoints can "hop" with little to no loss of data transmission. They're also watching over how competing networks are hammering your internal access points and adjusting power and channel levels accordingly to ensure the best airspace is being chosen at all times.
But they are also key in providing metrics for when issues occur, and very importantly, ensuring that WAPs are being kept up to date on the latest firmware levels. Vulnerabilities like KRACK and other newfound threats cannot be taken lightly in this Wi-Fi-dependant age we are in, and controllers can roll out updates in a concerted manner that manual WAP-by-WAP updating cannot compete with.
Most business class WAP systems rely on a hardware controller, but our company has chosen to standardize primarily on Cisco Meraki which relies on a fully cloud hosted controller that Meraki manages and keeps updated.
For our budget conscious clients, Unifi comes in at a distant second but has similar foundations of getting away from the legacy hardware controller mentality the rest of the industry followed. In the end, choose a product line which meets your needs and budget, but stay away from the "WAP silo" mentality which too many offices fall victim to. The few bucks you are saving on bypassing a controller-based solution is likely causing (or going to cause) innumerable more in troubleshooting and upkeep costs.
5. Don't Mix and Match Wi-Fi Access Point Vendors At A Given Site
Another no-no we see constantly at new client sites is the usage of disparate, mixed vendors at play with regards to access points chosen. While this may be done for budget reasons, or as different waves of IT staff come and go trying to recommend their own favorite Wi-Fi gear, this is an ill-conceived path to go down for a number of reasons.
First off, the largest sore thumb about this approach is that different vendors' WAPs will always see the others' gear as competing rogue networks. This means that things like cohesive channel hopping and power level adjustments will not be pacifist in nature. Instead, each vendors' access points will try to outdo each other in power levels and channel placement, leading to an airspace war where the ultimate victim is the end user.
Another area that will also suffer is the lack of consolidated seamless roaming between access points. A central controller is key to this operation having success across WAPs, and differing vendors' controllers (as far as I have seen) will not interoperate with one another.
This means you may have some areas of seamless roaming, if any, and the symptoms seen by end users will be periods of packet loss or degraded speeds as devices try to out-maneuver the actions of the access points warring above them.
Choose a single vendor and standardize on that party. Not only does it ensure full hardware compatibility across the Wi-Fi stack, but has the added benefit of having a "single throat to choke" when Wi-Fi isn't performing how it should.
4. Access Points Work Best Out in the Open, Up High
I harped on this same point in my 2015 article on Wi-Fi best practices, as it's such a critical aspect to any clean rollout which will stand the test of time. But it's so commonly done poorly, that I have to dedicate some pen space to the point again.
Is it always practical to keep your access points out in the open, visible, and not hidden behind ceiling tiles or walls? Of course not. But it should be an aspirational goal that is to be followed as a matter of best practice where possible, when possible.
There are a few main reasons why Wi-Fi signals always do best when exposed to open airspace:
- Every layer of material cuts signal penetration by a given percentage. Metal-based materials are of course the worst culprits, but stone/cement are also rough on Wi-Fi, along with other common construction materials (like sheetrock). Seeing that many offices are trying to cut costs by reducing the number of access points to as minimal as possible, giving your WAPs the best possible starting point for blanketing a signal is critical.
- Don't forget that 5GHz based 802.11AC signals travel about half as far as 2.4GHz signals, on average. The newest Wi-Fi standards promise awesome speeds, but you're dealing with a signal that only goes about half the distance as 2.4GHz transmissions can push. Every extra layer of obstruction that the WAP needs to push through is that much less signal your client devices will be seeing.
Go into any establishment that has access points setup in what I consider a best practices fashion, and you will find a few things in common. WAPs are always high up (but not too high; stay at 15-20ft or less); facing inward towards the desired coverage zone; and exposed in the open with little to no obstructions.
Some of the largest high-density installs we have done in areas like conference rooms and banquet halls always follow this standard, and as such, our results have been highly successful.
3. Turn Off Easy Sources of Interference
In the early days of Wi-Fi, airspace was clean and relatively uncongested, with strong signals being relegated primarily to commercial and enterprise environments. Now, even the average multi-tenant office building can have 15+ unique sources of SSID broadcast in any given location -- and we've seen much worse, like some condo buildings in downtown Chicago, where this ranges in the couple dozen and up.
What does this mean? Wi-Fi airspace is extremely congested these days, and everyone is fighting for their share of the pie. Whether it's radios that are pushing stronger signals, or merely more access points to blanket zones, or a combination of the above, this is the new standard.
But the other side of this reality is that there are only so many unique channels available for Wi-Fi to work cleanly. 2.4Ghz is plagued with only having 3 distinct non-overlapping channels, and 5GHz (depending on channel width chosen; read below for more on that) gives us about 23-25 distinct channels depending on the vendor.
Compound the issue of 40MHz and 80MHz fat channel widths eating up swathes of channels at a time on the 5GHz spectrum, and the problem is starting to look a lot more like 2.4GHz at the end of the day.
The moral of the story here is simple: Ensure you are keeping as clean of an airspace as you can by disabling easy interference sources. What do these look like?
- Wi-Fi Direct-enabled Printers. A must-check for any new install we are doing these days, almost every Wi-Fi capable printer above bargain bin pricing has this dirty feature which almost no one uses. Turn this off on each printer which you find to be broadcasting this feature to gain some airspace back.
- ISP-issued Combo Modem/Routers. Comcast, ATT, all the big players are guilty of this. They provide modem/router combos to customers that almost always have Wi-Fi enabled. If you are using commercial grade WAPs in your environment, these signals need to be taken down. In the case of Comcast, they also broadcast their "Xfinity" public SSID off most modems, which is a by-request-only item that needs to be disabled with a support rep. These devices are especially nasty as they sometimes like to eat a lot of airspace with very fat channels.
- ZigBee Devices. This smarthome technology is becoming more prevalent, and not surprisingly, tends to interfere with traditional Wi-Fi on the 2.4GHz spectrum. If you can, disable this gear or choose an alternate solution stack that can achieve the same results which works on different airspace.
- Other less common sources. I won't go into an exhaustive list, as Apple has a support article which covers a fairly extensive list of other sources of Wi-Fi interference. See if your office or home has any of these which may need to be tended to.
Also keep in mind one important point which some people forget: in most circumstances, you won't be able to mitigate all sources of outside interference. Even if all internal interference is shut down, you will still likely have outside sources which will be slamming your internal SSIDs that you have zero control over.
But the keystone of this best practice is the notion that you should be limiting and eliminating all interference you have full capability to limit or disable. This provides the easiest operating baseline for your WAP deployment, and with most controller-based platforms like Meraki, they have built-in capabilities to navigate around reasonable levels of interference.
2. For High Density Environments, Use Smaller Channel Width & Band Steering
Some of the most challenging installations we've had to deploy are those which combine large numbers of users in relatively crammed spaces. The industry calls these situations "high density" environments. These can range from auditoriums, to banquet halls, to conference rooms, and other similar places where device counts are staggering in small spaces.
Without getting into a full technical discussion that may be over many peoples' heads, I wanted to summarize some of the finer points of how you should be staging access points for such setups.
One of the most critical aspects which come into play for these high density scenarios is the concept of channel width. Perhaps a few graphics can help explain what this represents.
First, here is a graphic of all the available 2.4GHz channels (blue represents the only non-overlapping channels of 1/6/11):
(Image Source: Engenius)
And for the 5GHz channels, here is how they look from an airspace width perspective:
(Image Source: Engenius)
Curious what you should be looking at? The concept of most importance here is look at how few (non-overlapping) channels are available the larger the width gets. 2.4GHz really only has three distinct channels to use that don't overlap, so there is no discussion to be had there.
But this same points explains why everyone considers 2.4GHz airspace to be "dirty as heck." There just aren't enough channels to choose from for all the competing networks that want their piece of the pie.
While 5GHz has a relatively clean airspace at standard 20MHz channel width, you start cutting your channel choices in half for each raise in channel width, going from 20 to 40 to 80MHz. Not counting DFS channels (which many vendors don't even allow you to use, since they overlap with government radar) you have 9 distinct channel choices which is a comfortable amount.
But bump up to 40MHz channel widths, and the chart lays this bare: you're down to only 4 non-overlapping channels.
At fat 80MHz channel widths, you are only down to two distinct channels to use. And the proposed 160MHz extra fat channel widths bring this down to arguably only one option (and even that isn't super great, since you are eating into that DFS airspace which I don't like biting into in metro areas like Chicago with lots of airport activity).
Why do channel widths matter?
Simple. The fatter the channel width, the faster speeds you can achieve on a per client basis. This is how the vendors achieve those fancy figures that are printed on boxes about how great the theoretical maximums for operating bandwidth get.
But there isn't such a thing as no pain with this gain in speed. The downside is that the number of clients you can support in the same airspace when using these fat widths decreases by wide margins, without interference between clients becoming considerable. For conference halls and auditoriums and meeting rooms with large client counts, high bandwidth levels are not as important as signals which have clean latency levels.
People in high density scenarios aren't downloading massive files all day or doing other bandwidth intensive applications. They're checking email. They want to interact with their social media and mobile apps. They may want to browse the web. Activities which are all more interested in clean latency levels and average bandwidth instead of terrible latency and high bandwidth.
As such, channel widths should be kept to a minimum to allow for a higher density of client counts without too much traffic latency. For spaces like this, I prefer sticking to 20MHz channel widths as I have the max number of non-overlapping channels available to my access points. No more than 40MHz, if warranted. The small bite in max bandwidth is greatly overcome by the cleaner levels of latency that clients will see on their connections.
And on a similar note, band steering is something that more and more vendors are supporting, and you should take advantage of it if you can. This feature allows the Wi-Fi controller to determine if a connected client is capable of operating well at the 5GHz spectrum without issue, and if so, "forcibly" asks clients to use that side of the Wi-FI table.
This has a twofold benefit:
- It allows more open airspace for older, non-5GHz devices which can only work at 2.4GHz. While less common today, they still exist.
- It allows capable clients of using 5GHz signal which is better suited for high density environments, ideally creating a better overall experience for the end user.
You may need to experiment with channel widths and band steering, but in general, these two pieces of advice have meant the difference from having crud Wi-Fi (like is common in too many hotels) to Wi-Fi which people can actually call home about.
If you want to learn more about band steering, Meraki has a nice support article that goes into the concept at length with some decent visuals to boot.
1. You Should Always Have Separate Guest and Staff SSIDs w/ VLANs
While this concept may not be the sexiest one to highlight as the most important, from a security perspective, it surely should be top of mind.
And you wouldn't believe how often we walk into some fairly large environments where staff and guests are using the same SSID, on the same local network, with all of the gaping security holes that go along with a consolidated setup of this nature.
Most modern Wi-Fi controllers and access points make guest SSID setup and proper segregation relatively easy, with some elbow grease required. But either due to ease of deployment, or an installer's oversight (or incompetence) this is not always implemented properly.
From a high level, separate SSIDs and associated VLANs basically just take devices and corral them into security zones that are illustrated in this nature:
(Image Source: Alduras.com)
While there is no hard and fast rule for how many SSIDs and VLANs you should have, this really should be planned out by an IT person that can match business requirements to a technical design that can be properly implemented.
In general, most organizations where we are deploying Wi-Fi these days (usually commercial, but even high end residential as well) have the following baseline networks:
- Staff or Private SSID: Used only by trusted devices issued by the organization and by staff members approved to be on such a private network.
- Guest SSID: This is where anyone "untrusted" ends up, such as outsiders with mobile phones and laptops. Such an SSID would usually disallow access to any local LAN on the network, and also enable client isolation if available.
- Vendors SSID: Occasionally, there are devices or users which need to be placed into a purgatory area of the network that has special rules where, say, perhaps certain devices can be reached but not others from the local LAN. We use this frequently at hospitality and restaurant locations for things like multimedia devices where limited cross-network access is needed, but full trust is not provided.
- Other special purpose SSIDs: Some locations may desire that additional SSIDs be created. An example that comes to mind are shared workspaces where numerous tenants share a common larger office space but need segregated VLAN space to access their own printers without others getting in. Use these sparingly, but opt for more SSIDs to uphold security between sets of users as opposed to just dumping everyone into a singular SSIDs, jeopardizing everyone at play.
And be mindful that differing SSIDs alone are not the full answer here. You need to ensure that segregated VLANs with dedicated address spaces are being used, and firewall rules are being implemented to ensure that traffic cannot touch other VLANs.
A sample addressing setup you can use that would achieve a very easy rollout for a larger office could look like:
- Staff SSID: 192.168.50.0 /24
- Guest SSID: 10.50.0.0 /24
- Vendor SSID: 192.168.60.0 /24
The above address ranges are only examples, and there are hundreds of combinations you could choose from. The underlying concepts are what matter most to ensure security is upheld and that infections aren't allowed to run rampant across VLANs. Nightmares like modern ransomware, which take advantage of large unsegregated networks, can easily take down an organization; something my firm has had to help clean up first hand and it's never pretty.
No, Modern Wi-Fi Done Right Isn't Rocket Science
More than anyone, I lay a lot of the blame on our wonderful Wi-Fi vendors for why kosher installations are far and few between. Between a myriad of Wi-Fi standards out there; differing implementation approaches pitched; and features galore which are left to the whims of inexperienced installers, achieving enterprise grade Wi-Fi is a promise rarely upheld once all is said and done.
I'm really hoping that this piece allows you to wade through some of the marketing speak which has overtaken the Wi-Fi discussion, and boil down the crux of your problems in a fact-driven approach. While there are no guarantees that the best practices in this piece will fix every subpar installation from top to bottom, you should have some nuggets to take away which can turn around even the worst situations.
Remember: Even the best Wi-Fi hardware can fall flat on its face without the proper planning needed to drive a successful deployment.
Derrick Wlodarz is President and Founder of Des Plaines, IL (USA) based Managed IT Service firm FireLogic. He has 13+ years of IT industry experience spanning the private and public sectors. His firm specializes in providing SMB clients with managed IT support, consulting, and training. Derrick is a long-serving member of CompTIA's Subject Matter Expert Technical Advisory Council that shapes the future of CompTIA exams across the world. In addition to being an IT industry speaker, his work has been academically published in The Journal For Social Era Knowledge. You can reach him via email at firstname.lastname@example.org.