One of tweaks I looked at was disabling 802.11a support. Disabling 802.11b support is well understood and an easy way to reclaim a large portion of 'lost' 2.4 GHz bandwidth. Disabling 802.11a support, on Cisco infrastructure at least, is not nearly as easy. Trying to disable all 802.11a data rates does not work on a Cisco WLAN controller as works when disabling 802.11b rate support. Attempting it results in the following:
 | |
| The error even comes complete with a missing whack of the space bar. Wait... should there be a space between space and bar?!? |
Perhaps Cisco will allow the disabling of 802.11a rates when they finally support the 802.11n Greenfield protection mechanism. A few posts on the Cisco forum suggest that a newer chipset is required, though these posts are from around 2009. Fair enough, but there has been plenty of 802.11n APs since the Cisco 1250 series APs but alas... still no support. Certainly, there would be very few environments were Greenfield could be enabled at 2.4 GHz currently due to the massive installed base of legacy 802.11g clients. 5 GHz is a different story however. Due to the remoteness and low population density of much of Western Australia, I can think of many WLANs where it could be enabled with few concerns for the 'bad neighbour' issues that enabling it can apparently present. To be fair, there seem to be few, if any, enterprise vendors that support Greenfield.
So, Greenfield - not an option. I next looked at disabling all 802.11a data rates apart from 54 Mbps. The logic was that I may at least be able to limit 802.11a client associations to only those that could achieve a 54 Mbps data rate. You have to be careful when disabling data rates as it can cause some clients to break... and that was exactly the result. A particular a/b/g client could authenticate (802.11 authentication) and associate but broke somewhere during the 802.1X authentication.
The Final Solution
 |
| This is a an 802.11a/b/g/n client but the same principle applies. |
This is a workable solution in a very small WLAN deployment. This particular deployment was designed for roll-out to between 100 to 200 sites covering several 10s of thousands of machines - manually disabling 802.11a support in the driver would not scale.
The solution? I got a list of NIC chipsets from the software deployment / device inventory tool. I culled the non-WLAN chipsets from the list and then pulled out all of the a/b/g chipsets from the list. There were no 802.11a-only chipsets as is to be expected in the vast majority of enterprise environments. Clients with a/b/g chipsets made up around 10% of the total number of WLAN clients - this was a high enough percentage to make this worth the effort. From this list, I pulled out the chipsets that accounted for the majority of a/b/g clients. Around 90% of the clients contained either a particular Atheros a/b/g or one of two Intel a/b/g chipsets.
For each of the three chipsets, I then found the registry key that contained all of the settings that the advanced driver tab modifies. I found a machine with each of these chipsets, RDP'ed into the machine and opened the registry key. I changed the setting under the advanced tab of the driver from the default of a/b/g to b/g, refreshed the registry key and noted the new value. 802.11b support was disabled on the WLAN controller so b/g instead of just 'g' was not an issue.
With these registry values in hand, I had a startup script written to detect the client chipset and if one of these three chipsets were detected, modify the registry value in order to disable 802.11a support. This worked very well and resulted in the vast majority of clients on the 5 GHz band being 802.11n clients. Not a 100% perfect solution but pretty close without needing to spend time disabling the small number of a/b/g chipsets that didn't contain one of these three chipsets.
EOF... almost
Great blog !
ReplyDeleteWhy would you disable 802.11a, what's the advantage ?
Cheers.
ReplyDeletePerformance! The performance advantages of disabling 802.11a are not as great as that seen when you disable 802.11b at 2.4 GHz but in an environment where you are trying to obtain the maximum performance from the WLAN, this is another tweak that can help.
The performance improvement comes by hopefully eliminating or at least reducing the number of frames sent at slower data rates. Whilst the lowest data rate of 802.11a and 5 GHz 802.11n is quite similar (6 Mbps for 802.11a and 6.5 Mbps for 802.11n) not many WLANs would have clients transmitting at these rates.
If we look at the middle rates though, you are much more likely to have 802.11a clients transmitting at 24 Mbps whereas a middle rate with 802.11n is somewhere around 58 Mbps (20 MHz channel) or 120 Mbps (40 MHz channel). This assumes two MIMO streams, 400 ns guard interval, etc. By eliminating or reducing these 802.11a clients, you are reducing the number of frames sent at 24 Mbps (for example) and allowing more frames of a higher data rate to be transmitted, improving performance.
Essentially, you are sacrificing 802.11a/b/g clients, forcing them to operate at 2.4 GHz where (depending on the design / environment) the performance may be worse for the benefit of your 5 GHz 802.11n clients.
Not appropriate or worth-while in many designs but another option where performance is key.
Not sure I understand anything you have done. The B/G and A bands have different radios and run on different frequencies. The two have absolutely no relation to each other. In fact the B/G radio can't even see the A radio and vice verse. So disabling the A band has no effect on the B/G side except that now all of your clients are on one of the 3 non-overlapping B/G channels. The A band has many more non overlapping channels giving the entire A spectrum more throughput availability. I think you should google some basic 802.11 websites and start to relearn what you think you know.
ReplyDeleteI have not stated that 802.11a has any effect on the 802.11b/g radio. I mentioned that disabling 802.11b is well understood but not so with 802.11a.
ReplyDeleteThe reason for disabling 802.11a is for the same reason you would typically disable any legacy protocol - performance. It is the same reason that if the 802.11n Greenfield protection mode was supported by Cisco you would see an increase in performance of 5 GHz 802.11n clients, as 802.11a clients would be eliminated, assuming the environment was appropriate for enabling Greenfield.
The point of this post was to demonstrate a way to disable 802.11a, moving a/b/g clients to the 2.4 GHz band, freeing the 5 GHz band up for 5 GHz-capable 802.11n clients. As stated in my comment above, "Essentially, you are sacrificing 802.11a/b/g clients, forcing them to operate at 2.4 GHz where (depending on the design / environment) the performance may be worse for the benefit of your 5 GHz 802.11n clients."
The arrogance of your last comment is galling. The irony of course is that you haven't properly read and comprehended what has been written. A casual read of this blog will show that there certainly is not a problem with a lack of understanding.