Slashdot Mirror
Ask Slashdot: How Do You Deploy Small Office Wi-Fi SSIDs?
First time accepted submitter junkfish writes "I am not able to install a controller based Wi-Fi solution in my office due to cost, but I like presenting my users with a single SSID rather than an array of four or five differently named SSIDs from different access points. What is your experience deploying multiple wireless access points with the same SSID and password? I have been doing this with Cisco 1040 series Access Points this year, and have had good success. It seems like the client is able to determine which AP is best to connect to, and is able to roam around the office without too much of an interruption when it connects to a different AP. Is this sloppy practice? Or does the general state of the 802.11 provide for this sort of resiliency? I am really interested in your opinion because I have not seem too much documented on this subject."
I've seen it work with multiple AP's in an office that all had the same SSID. Just cloned the boxes (some cheap Cisco thing, can't remember the part number) and never had any issues with conflicts.
Do not mock my vision of impractical footwear
I thought that was the standard way of doing it anyway. Is it not?
I would highly encourage you to look at the Ubiquiti UniFi system. Software based centralized computer and basic APs are only $66. We're switching to them from Cisco and have been very happy.
http://www.ubnt.com/unifi
Is there another way to do it? I've always set office (and my home) Wifi networks up like this -- as long as the AP's are all on the same subnet, roaming among them should be fairly transparent.
Try to use non-overlapping channels as much as possible. (i.e. channel 1 at the east end of the office, channel 6 in the middle and channel 11 at the west end). If you can't use non-overlapping channels, some tuning of power levels to prevent interference between nodes can help -- i.e. if you have a long office with 4 nodes on 3 channels: [1, 6, 11, 1] you may see better performance if you turn down the transmit levels on the two channel 1 nodes so they don't interfere with each other as much. And dual-band 802.11n can help even more both because there's more channels on 5Ghz, and because the 5Ghz signals will be attenuated more.
In my current office, I have about 120 Wifi nodes (through a Cisco WLAN controller), all are broadcasting the same SSID.
If the only think keeping you from a controller based solution is cost try Ubiquiti's Unifi. You can run without a controller and if you need one you can use any old embedded box. http://www.ubnt.com/unifi
Because the power to run a Pentium 4 for 2 years would cost more than getting a modern little embedded box.
the options are limited. You can use the same SSID on the various APs (separating channels as mentioned). So long as the clients are all on the same vlan (usually a DHCP scope), it will work reasonably well. Most of the protocols are fairly forgiving. If you have WDS capability, by all means use it.
802.1x adds complications, but if you have a RADIUS type server a WLAN controller should be a more realistic consideration.
WRONG!
This is *NOT* what WDS was designed to do. There seems to be quite a lot of people under the impression that if you want multiple access points co-operating with one another such that clients can roam between them seemlessly, you need WDS. Not sure where that came from but its got nothing to do with that.
WDS is about peer-to-peer AP connections such the data is travelling wirelessly between access points, and while WDS can be the "backbone" of a seemlessly-roaming SSID-consistent WiFi network, its an inherently flawed system. This is typically used for places where you need to bridge networks wirelessly when you cant put down a cable (for eg, you might have two offices across the road from one another).
WDS will also chew up a considerable amount of wifi bandwidth doing this (and the problem gets exponentially worse as you add more AP's/clients).
The point being though that WDS wasnt designed for the purposes of providing distributed access to a wifi network with a single SSID, but to allow AP's to also be clients to each other while still being AP's.
Ultimately the way the guy describes his setup is the correct method of deployment, multiple AP's with the same SSID and encryption parameters, thats all there is to it.
Set the SSID the same for each AP. Set them on different channels so that the AP's don't "step on" each other's bandwidth. Roaming is a station-side (client in common usage) decision, so your PCs will automatically pick the AP with the best signal strength.
As far as authentication goes, this all depends on the AP. All should support PSK (preshared secret keys, aka passwords) and in that scenario, set them all to the same value on each AP. The PSK should be at least 24 characters long, and the SSID for the net unique to keep the security at acceptable levels and reduce the possibility of offline dictionary attacks against the PSK.
Assuming the APs support it, Enterprise grade authentication with individual per-user passwords is within reach at little to no cost. You can tie into Active Directory or set up a free AS (Authentication Server) using FreeRadius on a linux box. The definitive reference for doing this with an MS server is a book titled "Deploying Secure 802.11 Wireless Networks with Microsoft Windows". Make sure you check for updates to the book online, and there is an appendix which details how to set it all up in a lab environment, which will let you prove principle without screwing with the production network.
Google around and you will find loads of information on how to do this with Open Source, the key articles being some from Linux Journal from about 6-8 years ago.
Hope this Helps......
Controllers came well after AP's were invented, so people had to solve this problem for years without them as an option at all. Multiple AP's sharing the same SSID and key is exactly how the standard was designed, and was the best practice for deployment for many years. The short answer is, it works great, and is how you should be deploying.
For the long answer, you have to understand what happens when a user needs to switch AP's, and how the controllers improve that process. When a client wants to switch from one AP to another it must dissociate from the first, associate with the second which includes exchanging new session keys, gratuitous ARP to inform the L2 network, and then carry on. This process typically takes between 100-500ms, depending on the client, AP, and random luck. For most users doing most things this is all fine, if you're browsing the web and chatting on IM it's a non-issue.
However, for some clients like VoIP phones and video chat a 100-500ms pause is a disaster. Enter the controller solution. The WiFi protocol was divided between things that require hardware (transmitting at the right time, rf modulation, etc) and things that were all in software, just on the AP like exchanging key material. The hardware kept doing the hardware things, but the software activities were moved to the controller. The advantage is that the entire session does not need to be torn down, the radio can switch AP affinity (BSSID) while using the same key material since the key material is tunned back to the controller from both AP's. A client can now switch AP's in 10-50ms, which for most VoIP apps and video conferencing means seamless connections.
Note to the pedantic: yes, there are some other details, controllers enable triangulation features and some other RF analysis, there are a few protocol nits I omitted, and this omits a lot of important design considerations like proper AP placement and channel selection.
Now, go back to the requirements. If you don't deploy WiFi VOIP phones, and don't have other real time streams, controllers may be a total waste of your money. If the goal is to get users e-mail and web access when sitting in the conference room or courtyard, vendors are selling something not needed when they push controllers.
Second note to the pedantic: Controllers can make networks scale better, so if you're deploying 25+, or more likely 100+ AP's my previous paragraph doesn't apply, but that's not what most people reading this are doing.
So to the OP, yes, put them on the same channel. For less than 10 AP's with no real time requirements it is the best practice, and a perfectly valid way to deploy a WiFi network. A controller may be able to get some advanced features (auto-channel management, threat detection, triangulation), but in most small businesses they are features that would rarely if ever be used. There are thousands of WiFi networks deployed without controllers that work quite well. Do read a good document on how to place AP's and select channels, you'll want to use non-overlapping channels in a grid pattern and try and get it to where clients can always see 2-3 AP's, no more, no less.
If you really want a controller, there are some lower cost options than the big players. Ubiquity has a nice solution in their UniFi line, and Netgear now offers an appliance based controller. Aruba has several mid priced offerings. They don't all have the features of say high end Cisco gear, but offer a lower cost solution.
Generally you'd want to use some other device for DHCP, probably your router in a SOHO setup.
Oh crap, totally missed that in my proof reading. It should have said "put them on the same SSID", not channel.
I 100% agree that a proper channel plan is necessary using non-overlapping channels. And you're right that 802.1x caching can help.
Folks, mod up, not down the AC post I'm replying to, he's right and I made an important typo.