In wired as well as wireless networks, there is a great deal of oversubscription. That email server with a single a dual gigabit connection could not possibly serve all of those wired clients in that organization, can it? But it does. Everyone who has been in the business long enough remembers having a very sub-par connection to the internet, and somehow it still served everyone who needed access to it. Today, we still have the same issue, where the resources that serve users is much lower than the aggregate user need in both wired and wireless networks. Wireless networks need different consideration.
In most circumstances, there is some sort of time slicing mechanism that gives each user some of what they need and to the user, it appears that he/she has good access to their resources. In wired networks it is somewhat predictable to understand what clients are where and what resources they will need because they are for the post part immobile. Traffic patterns can be modeled fairly easily. Switches arbitrate traffic between clients and buffer traffic to be delivered in a predictable fashion. In a wireless network your clients can show up anywhere, so planning is much more difficult and there are issues like contention and interference that will rob you of time slices that you could give to your clients to provide better service. The key to providing consistent service is to remove alot of the things that could cause you issues ahead of time, so if there is something that you CANNOT remove, you will at least have enough headroom to deal with issues you must accept. Here are a few things that you can do to make sure you reserve enough headroom for your clients:
- When planning a site, try to do a spectrum analysis to determine if any device that interfere with your wireless frequencies exist. Non-wifi compliant interfering devices do not know the rules of the road, so they will not attempt to play nice or share the spectrum with your wifi clients and access points. That can impose a serious penalty on the available throughput in the medium. Frequently, people who do not run the wireless like security and building service people will put up wireless devices, not knowing that it punishes the user experience. Start off on the right foot by identifying these issues and then dealing with them. Turn on hybrid spectrum analysis on ArubaOS once in a while when you have any suspicions to determine of a mystery interferer has taken up residence.
How to turn on Spectrum Analysis in Instant http://www.arubanetworks.com/techdocs/Instant_41_WebHelp/InstantWebHelp.htm#UG_files/Spectrum_monitor/Creating_Spectrum_Monito.htm
How to turn on Spectrum in Controller-Based APs (Requires the RF Protect License)
- Use The Right Encryption Type and only choose and purchase clients that support them - The only encryption types that support 802.11n speeds are Open and AES (WPA-AES, WPA2-AES and Open Encryption allow full speed). Anything in between like the flavors of WEP and TKIP support a maximum association rate of 54megs an realistically that is cut in half, due to overhead. Those clients with the wrong encryption type will drag your WLAN down to the least common denominator and will hurt the performance of every client within earshot. How would you like it if the highway was only a single right lane?
- Correctly Space Your Access Points - Most office environments that use regular drywall work best with a spacing of one 802.11n access point for every 50 or 60 feet for coverage in open areas. If you make it closer than that, you run the risk of introducing contention which puts 2.4ghz access points near each other and into each other's broadcast domain if they share the same channel. This will drag down your performance even in an 802.11n network because clients have to see, hear and wait on each other. In a high density environment it could be necessary to put them closer, so please adhere to the high density VRD for instructions on how to deploy in those scenarios. There are some circumstances, where the most efficient way to deploy is an access point every other room or every room due to density. Survey before your deploy to understand how your RF propagates. It will still not hurt to first survey at every 50 or 60 feet to give yourself an idea of coverage and AP density.
- Deploy Your Access Points Closest to your Users - If you are planning a deployment and you have areas like a conference room where users congregate, deploy access points to those areas first in your plan. Clients have much better performance and maintain higher rates when they are closest to the access point they are connected to. If you have areas where users gather and need wifi, place access points in those high density areas on the floor first, then go back and fill in other areas where you only need coverage. If your clients in a conference room also have to connect to their nearest access point through a wall, it will decrease performance and increase issues like hidden node: http://en.wikipedia.org/wiki/Hidden_node_problem
- Keep access points of different phy types (a/n/ac) access points separate from each other if possible - Access points within earshot of each other that have different phy types will can provide uneven roaming. At maximum your clients will favor 802.11n/ac access points, even though a non-802.11n/ac access point is closer and could possibly cause performance issues. It also will make your RF less predictable. Try to keep your deployment areas uniform to avoid such issues.
- Pay Attention to Floors Above and Below - RF operates in 3 dimensions and there are few floors that absolutely block all RF unless they are concrete. Access points right above or below each other create contention domains, so be sure to make a conscious effort to stagger your access points from floor to floor, so that you get them as close to the every 60 feet rule as possible.
- Enable as few SSIDs and BSSIDs as possible - Every WLAN that you broadcast has to send out beacons every second, so the more you broadcast, the more management traffic you send out and the less data you can support. Anything more than 4 SSIDs and you are punishing your data traffic by putting too much management traffic in the air (http://www.revolutionwifi.net/revolutionwifi/p/ssid-overhead-calculator.html). If clients can use the same encryption, for example WPA2-PSK, you can use a user derivation rule to differentiate by manufacturer OID to place clients that associate into different roles/VLANs so that you don't have to bring up a separate SSID for different devices. If you know that devices will not support 802.11a, do not broadcast the SSID on that band, to free up airtime for 802.11a clients. If you are using 802.1x and need to put different clients on different VLANs or roles, use your radius server to send back different attributes to the controller, which can in turn segregate your traffic without having to enable another separate SSID for different users.
- Enable Drop Broadcast and Multicast on all of your Virtual APs - Broadcast and multicast traffic punish wireless and are very rarely used for current applications today. In addition, Airgroup (on by default) can forward and proxy mDNS and DLNA discovery packets with "drop broadcast and multicast" on to maintain performance. This is the main reason users say that their wireless works one day and without any changes, it gets worse and worse. In Aruba Instant it is setting the "Broadcast Filtering" parameter to ALL, under Advanced. Dropping broadcast and multicast results in a huge improvement in performance and reduces phantom performance issues generated by devices that send out random broadcasts.
For Controller-Based Access Points, you drop the Broadcasts at the Virtual AP level - http://www.arubanetworks.com/techdocs/ArubaOS_64x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/VirtualAPs/Virtual_AP_Profiles.htm?Highlight=drop broadcast and multicast
For Instant APs, you Enable Broadcast Filter Arp - http://www.arubanetworks.com/techdocs/Instant_41_WebHelp/InstantWebHelp.htm#CLI_commands/wlan ssid-profile.htm?Highlight=broadcast filter arp
- Start by Setting Set the ARM Min and Max TX power to 12 and 18 respecitvely - The #1 reason for sporadic disconnects and roaming issues is that the power on access points are too high. If the power on an access point is at 19 or greater, clients will hold onto that access point longer, because they believe they have a great connection and will not attempt to roam to other access points. By the time the power falls off, the client is 3 floors away from the access point, but has been slowing down the performance of all the other clients on that AP, the whole time. Clientmatch can kick in eventually and move that user, but setting the power on the AP properly will avoid the performance issue between when the client has moved far out of coverage and when ClientMatch can kick in to put it on the closest AP (sticky move). ARM min and max TX power is in dbm which is logarithmic, so every 3 db increase results in a doubling of power: By the time you get to above 18dBm the access point's power will be almost double that of most devices, so clients will be able to hear access points, when access points cannot hear them as well. That will result in (1) clients hanging on to APs longer, because they think that they can speak to them as well as they hear them (2) disconnects due to clients missing beacons due to distance (3) excessive clientmatch moves due to the access point disagreeing with the client's perspective of the network:
- 0dBm = 1mW
- 10dBm = 10mW
- 12dBm = 15mW
- 18dBm = 63mW
- 20dBm = 100mW
- 21dBm = 125mW
- 22dBm = 158mW
- 23dBm = 199mW
- 24dBm = 251mW
As a reference iphone5 = 13dbm (20mw) max output
In Controller-Based APS, the Minimum and Maximum Transmit Power is Set in the ARM Profile - http://www.arubanetworks.com/techdocs/ArubaOS_64x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/ARM/ARM_Profiles.htm?Highlight=arm profile tx
In Instant APs, the minimum and Maximum Transmit power are set under RF> Show Advanced.
- Make sure your 802.11n/AC access points are on gigabit ethernet ports so that your physical interface does not become the bottleneck.
- Do not enable "Local Probe Request Threshold" with Clientmatch. - ClientMatch should fully replace the functionality of local probe request threshold in the SSID profile. Enabling lprt unfortunately, will have access points ignoring clients that it should be servicing, unfortunately when ClientMatch is enabled. Leave it at zero (the default).
- Make sure your wired uplinks are correctly subscribed - A good ballpark calculation for controllers is to have one gigabit ethernet port for every 100 access points that terminate on it. That will give you enough headroom for the burst that is not always seen when measuring interfaces using management software. Random congestion can cause client issues. Access points that rebootstrap with missed heartbeats is a symptom of possible oversubscription.
- Make sure all of your access points and controllers negotiate properly on wired interfaces and that your access points are not bootstrapping - Access points that do not negotiate properly and have errors on their wired interface is a common and silent cause of network degradation. It can also cause mystery "coverage holes" due to access points being unavailable. Periodically check your interface for errors and your access points and logs for rebootstraps (show ap debug counters) to deal with this silent but important issue.
- 80 mhz channels are enabled by default and it does not give enough channels for separation in high density. You should go to 40mhz channels by disabling 80 mhz support in the ARM profile. You could even go all the way to 20mhz channels if you are still having issues by making sure "allowed bands for 40mhz" is set to "none" in the ARM profile. That will give you the most channels to work with without enabling DFS.
In Controller-Based APs, you can set devices to 40mhz channels in the ARM profile by unchecking 80 mhz channels and make sure "allowed band for 40mhz" is for 5ghz only. You can enable 20 mhz in Controller-Based by making "allowed band for 40mhz" to "none".
In Instant APs, you can enable 40 mhz channels by going to RF> Advanced and making sure that 80mhz channels is unchecked. You can enable 20 mhz channels by making sure that "Wide Channel Bands" is also set to "none".
Lastly, do not run 802.11r on an SSID in a mixed client environment. There are some clients that like it, others that do not, and others that show intermittent connectivity issues. Don't bother, because it is not required for good roaming performance, but it can cause issues.
Well, that is all for now. There are quite a few other things that can be checked to ensure you have good performance, but those are most of the big ones. See you next time...
