Why not to use EAP-FAST: Part One

Recently I recommended against the EAP-FAST authentication protocol whilst writing a WLAN design and instead recommended that either EAP-TLS or PEAPv0 (EAP-MSCHAPv2) be used. There were a number of reasons for this recommendation and in this short post I will discuss the first reason - the lack of WLAN chipset support.

For the uninitiated, EAP-FAST is Cisco's answer to the cracked-back-in-'03 LEAP authentication protocol. LEAP was also courtesy of Cisco. EAP-FAST was Cisco-proprietary, became an IETF draft in 2004 and then err, a non-draft fully fledged, fair dinkum IETF RFC in 2007.

Few WLAN chipsets supported EAP-FAST initially but since 2009 it been added to the Wi-Fi Alliance certification program.

Edit (10th Jan 2012): Whilst the numbers below were correct as of November 2011 comments about these figures have made me realise that my methodology was flawed. Whilst I mention below that EAP-FAST has only had since 2009 to be included in the Wi-Fi Alliance certified client listings, I didn't take into account clients that supported EAP-FAST, prior to the Wi-Fi Alliance certification. I doubt even Cisco has an accurate idea of how many clients this includes. In addition, clients that did not originally support EAP-FAST may have since received support via a driver update.

Whilst the numbers may not represent the true extent of EAP-FAST support, my experience has been that fewer clients support EAP-FAST, particularly non-laptop based Wi-Fi devices..Whilst laptop-based driver updates may be available for some clients, driver management in most enterprises is almost non-existent so updating a large enterprise for support of a new authentication protocol would typically not be a light undertaking. This does not even touch on the work required to update devices such as phones, barcode scanners, medical equipment, etc.

Although accurate numbers may be difficult to determine when it comes to EAP-FAST client support, unless you can be sure that the vast majority of your EAP-capable clients do in fact support EAP-FAST I would suggest looking towards PEAP or EAP-TLS in most cases. Part two of this post will document other factors that weigh in when considering an EAP-FAST implementation.

Of the current ~10,000 Wi-Fi Alliance certified WLAN products, ~1,300 support EAP-FAST. By contrast, PEAPv0 is supported by ~4400 products and EAP-TLS by ~5400. Keep in mind that these figures include both enterprise and SOHO products and generally SOHO gear does not support any flavour of EAP. 

So of the three most popular flavours of EAP, the break-down is, as of November 2011:

• EAP-TLS                           : ~54% of Wi-Fi Alliance certified products support it
• PEAPv0 (EAP-MSCHAPv2) : ~44% of Wi-Fi Alliance certified products support it
• EAP-FAST                         : ~13% of Wi-Fi Alliance certified products support it

The number of devices supporting EAP-FAST has been steadily growing but it is still far behind EAP-TLS and PEAPv0. To be fair, EAP-FAST has only had since 2009 as far as Wi-Fi Alliance certification goes whilst EAP-TLS and PEAPv0 certification from the Wi-Fi Alliance has been occurring for much longer. For the time being however, deploying EAP-FAST today means that you may be stuck using (if you're lucky) WPA2-Personal (Pre-shared Key) on some of your managed devices which is far from desirable when alternatives exist.

Cisco Mesh - Ethernet VLAN tagging

The following documents the steps required to get Ethernet VLAN tagging working in a Cisco mesh deployment. This allows you to hang either a single wired client or a switch off of a MAP and allow it to communicate with the rest of the network, via the mesh. This is essentially the mesh-based equivalent of a work-group bridge. The configuration documented below is for connection of a switch to the MAP.

The Cisco documentation for this configuration is ridiculously confusing, contradictory and contains numerous mistakes so much of the following was determined by nutting it out. As such, there may be modifications to the configuration below that also work, depending on requirements but the following has been tested and deployed. There is a BugID for the poor state of the documentation - 'nuff said!

Assumptions

• You have a working knowledge of Cisco mesh deployments
• Having read through the Cisco documentation on Ethernet VLAN tagging and banged your head against the wall may also help
• The following configuration is based on this example topology
• [ACCESS-LAYER SWITCH] --> [MAP] --> [MAP] --> [RAP] --> [CORE SWITCH]

Configuration

VLAN Transparent

• Disable the global parameter VLAN Transparent
• WLC GUI --> WIRELESS --> Mesh --> Un-tick 'VLAN Transparent'

Ethernet Bridging

• Enable Ethernet Bridging on ALL RAPs and MAPs in the mesh network
• If Ethernet Bridging is not enabled on all MAPs and RAPs and the MAP changes its backhaul path through the network, the MAPs and RAPs in the new path may not be able to dynamically create the required VLANs / sub-interfaces on their radio interfaces

• WLC GUI --> WIRELESS --> Access Points --> All APs --> <ap-hostname> --> Mesh -> Tick 'Ethernet Bridging'
• Depending on the number of APs, a quicker way may be to use the WLC CLI command:
• config ap bridging enable <ap-hostname>

 RAP Wired Ethernet Interface (Configured on the WLC)

• If not already set, configure ALL RAPs wired Ethernet interfaces (usually GigabitEthernet0 or GigabitEthernet3) to Normal Mode. This is the default so they probably won't need to be changed
• Contradictions exist in Cisco documentation as to whether Trunk or Normal mode is required. Both work but changing from Normal to Trunk produces a warning that indicates the change hasn't taken place so in effect, the port is still set to Normal, despite being set to Trunk
• The RAP does actually trunk traffic to the switch but the VLANs / sub-interfaces on the GigabitEthernetX wired Ethernet interface are created automatically using a VLAN registration mechanism.
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <rap-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Normal

RAP Wired Switchport Interface (Configured on the switch)

• The switchport(s) on the [CORE SWITCH] that the RAP(s) wired Ethernet interface connects to must be configured as a trunkport.
• In the switchport configuration example below:
• VLAN 100 is the Native VLAN and the VLAN that the RAPs and MAPs management IP resides in
• VLAN 200 is the Management VLAN used by the [ACCESS-LAYER SWITCH](es) attached to the MAPs
• VLAN 300 is the User-access VLAN used by wired clients that connect to the [ACCESS-LAYER SWITCH]. Multiple User-access VLANs may be used, if required

• Example switchport configuration:
• interface GigabitEthernet0/1
•  description *** Connection to RAP01 ***
•  switchport trunk encapsulation dot1q
•  switchport trunk native vlan 100
•  switchport trunk allowed vlan 100,200,300
•  switchport mode trunk

• Assuming the [CORE SWITCH] is the appropriate layer 3 point in the network, SVIs for all three VLANs should be created

MAP Wired Ethernet Interface (Configured on the WLC)

• Only the MAP(s) that have an [ACCESS-LAYER SWITCH] connected to them require VLANs configured. All of the other MAPs that act as backhauls for the MAP(s) connected to the [ACCESS-LAYER SWITCH] will automatically pass the VLAN-tagged packets through their radio interfaces.
• Configure the MAP(s) that have an [ACCESS-LAYER SWITCH] connected, by configuring the wired Ethernet interface (usually GigabitEthernet0).
• Configure the same native VLAN and additional VLAN IDs as that configured in the RAP Wired Switchport Interface section above
• These additional VLANs are:
• Management VLAN used by the [ACCESS-LAYER SWITCH] that attaches to the MAPs
• User-access VLAN used by wired clients that connect to the [ACCESS-LAYER SWITCH]

• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Trunk
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Native VLAN Id --> <VLAN100>
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Trunk VLAN Id --> <VLAN200>
• WLC GUI --> WIRELESS --> Access Points --> All APs --> <map-hostname> --> Mesh --> <GigabitEthernetX> --> Mode --> Trunk VLAN Id --> <VLAN300>

MAP Wired Switchport Interface (Configured on the switch)

• The switchport(s) on the [ACCESS-LAYER SWITCH] that the MAP(s) wired Ethernet interface connects to must be configured as a trunkport.
• In the switchport configuration example below:
• VLAN 100 is the native VLAN and the VLAN that the RAPs and MAPs management IP resides in
• VLAN 200 is the Management VLAN used by the [ACCESS-LAYER SWITCH] currently being configured
• VLAN 300 is the VLAN used by wired clients that connect to the [ACCESS-LAYER SWITCH] currently being configured

• Example switchport configuration:
• interface GigabitEthernet0/48
•  description *** Connection to MAP01 ***
•  switchport trunk native vlan 100
•  switchport trunk allowed vlan 100,200,300
•  switchport mode trunk

• An SVI & default gateway for management of the [ACCESS-LAYER SWITCH] should also be configured:
• interface Vlan200
•  description ***** [ACCESS-LAYER SWITCH] Management *****
•  ip address 192.168.1.10 255.255.255.0

• ip default-gateway 192.168.1.1

• It is recommended that VTP is set to transparent on this switch

EOF... almost
Cisco Mesh Ethernet VLAN Tagging configuration - what could be simpler? :|

Bad Wi-Fi Never Dies

I am currently in hospital because well, you know, needles are fun and I am sadistic. After going nuts without any mental stimulation all day I finally got a hold of my laptop and was curious to check out the WLAN environment.

Up until now all I could tell was that Cisco 1130 APs are used. The AP density seems to be overly high but without knowing whether some are used for security or location (monitor mode) it is hard to sure. I lost track of those APs with a blue ring after being moved down countless corridors ;).

I am in the bowel of a large hospital and I can't see many APs but despite this I have noticed a number of issues from the small sample size (5 APs). The low AP count is likely to stem from the fact that the hospital was built in the 1850s and therefore the walls are as thick as one would expect - top quality craftsmanship from the convicts!. The particular walls of my room are no doubt newer but this stuff ain't no drywall! Oh, this floor or section of the floor clearly has no APs deployed either.

Five APs and five Wi-Fi sins

• 2 x APs on adjacent channels (channels 2 and 8 in this case);
• 1 x AP using a 40 MHz channel at 2.4 GHz;
• 2 x APs running WEP;
• 1 x AP running WPA using the TKIP cipher (WPA w/TKIP still hasn't been cracked in any useful way so this may not be a massive issue but WPA2 w/AES is preferred);
• 50% of packets transmitted at 802.11b rates (lower than I usually see but far from fantastic).

Interestingly, there are some 802.11b-only devices (bad) but they are probing for WLANs at 11 Mbps. This is a good thing assuming the lower 802.11b data rates have been disabled on the WLAN they are trying to connect to. If you must support 802.11b-only clients, just supporting 11 Mbps is recommended assuming cell coverage allows for it. The MAC OUI vendor of the clients originating these probes is Abbott Labs HPD and a quick search confirms that Abbott Laboratories is a <markting spiel removed> health care company. This makes sense as hospitals are one of the remaining places that you may still find 802.11b-only clients as Wi-Fi equipped medical equipment will generally have a longer usable life than your average laptop. Likewise, WEP and WPA-TKIP may be supported as these 802.11b devices are unlikely to support WPA2 with AES. If you must run WEP still, Dynamic WEP is preferred (if available) along with MAC filtering and one of the few times SSID hiding is recommended. A separate tightly ACLed subnet would be good too. Multiple layers to the onion, no matter how easy to peel ;)

Even though the particular area I am currently in only has a small amount of Wi-Fi activity, many bad practices can be seen with a dash of best practice thrown in. Oh, one last thing - according to the nurse I hit up, Vocera badges don't recognise Irish accents very well and there are an influx of them in Perth at the moment (Irish people; not Vocera badges :)). Something to do with the Western Australian mining boom and Ireland in the hole, one suspects ;)

High Channel Utilisation: Part One

This is part one in a gripping two part series!

Yesterday I was performing a WLAN audit for a client. As part of this audit, I noticed that APs were reporting a high level of channel utilisation whilst the Tx and Rx utilisation was either very low (<5%) or in most cases 0%. Most of the APs I looked at had 0 clients associated which explains the Tx and Rx utilisation of 0%. The channel utilisation generally ranged from 20% to 60% and in the case of one AP, was 92% with 0 clients associated. In the case of the 92% utilised AP, this means that 92% of the airtime is unavailable before a single client even associates. This directly correlates to how much bandwidth is available for clients once they do associate. If I associated a client to this AP and ran iperf, instead of the ~20 Mbps of real throughput at a 54 Mbps data rate, I would achieve a maximum of a few Mbps. The most common cause of this high utilisation is an excessive number of low data rate frames - almost always 1 Mbps frames. This was suspected but I passed through the motions to determine the cause.

Spectrum Analysis was performed to rule out any Layer 1 (non-Wi-Fi) interference. The spectral density view in Metageek's Channelyzer Pro showed three clearly defined 802.11 channels but nothing else of significance. The integrated spectrum analysis functionality in the Cisco CleanAir APs was also checked and showed the usual low duty cycle interferers (Bluetooth and DECT phones) but nothing to accountant for such high channel utilisation.

Next, layer 2 analysis was performed by way of packet sniffing. It was immediately obvious that the excessive 1 Mbps frame hypothesis was correct. These frames accounted for between 70% and 80% of all frames. There are a number of factors that can contribute to an excessive number of 1 Mbps frames:

1 Mbps frames allowed on the WLAN
Obviously enabling low data rates such as 1 Mbps on the WLAN will account for some of the frames seen. A frame transmitted at 1 Mbps takes significantly longer than even the slowest 802.11g frame (6 Mbps) and therefore many 1 Mbps frames can take up a significant portion of available airtime. Common management frames such as beacons, probe requests and probe responses are sent at the lowest configured manatory data rate (1 Mbps in this case). These frames are sent even with no clients associated to the AP. In addition because 1 Mbps is an 802.11b data rate, a protection mechanism such as RTS/CTS or CTS-to-Self is needed to allow 802.11b clients and APs to interoperate with 802.11g clients and APs. RTS/CTS results in around a 30% to 40% reduction in throughput and this does not include the reduction in throughput caused by the actual 1 Mbps data frames. RTS and CTS frames are usually also transmitted at the lowest mandatory data rate.

All 802.11b data rates were enabled on this clients’ WLAN, which includes the 1 Mbps data rate. This accounts for some of the 1 Mbps frames seen but it was not the largest contributing factor.

Excessive co-channel interference (CCI) caused by a high density of APs within the WLAN
The higher the density of APs within the WLAN, the more beacons, probes and control frames (RTS and CTS) will be transmitted within the environment. As detailed above, these frames are typically transmitted at the lowest mandatory data rate.

The AP density of this clients’ WLAN was low and although CCI at 2.4 GHz is usually present to some degree in most WLANs, it wasn't a major contributing factor in this case due to the low AP density.
     
Number of SSIDs broadcast by the WLAN
The more SSIDs supported by the WLAN, the more management frames will be transmitted (beacons, probes, etc) to support these additional SSIDs. A maximum of four to six SSIDs per WLAN is typically recommended. 1 Mbps data rate support exacerbates this problem significantly. Hiding the SSID does not help.

This was not a contributing factor as the client is currently only supporting a single SSID.

Rogue APs within the businesses premises
SOHO APs are often brought in by employees or purchased by departments within the organisation without the knowledge of the IT department. Employee's using smart-phone tethering is becoming increasingly common also. Essentially this turns the smart-phone into a Wi-Fi hot-spot. These APs almost always support the 1 Mbps data rate.

This was a small contributing factor in the case of this client.

Rogue APs outside the businesses premises 
Essentially a neighbouring businesses’ poorly designed or maintained WLAN can affect your WLAN. In this context, the definition of poorly designed or maintained is support for 802.11b / 1 Mbps data rates. Very few WLANs in late 2011 should support 802.11b and 1 Mbps data rates but unfortunately many still do. Within a WLAN context, these businesses are often referred to as bad neighbours.

This was the major cause of high channel utilisation in the case of this client.Further details of this can be found in part two detailed at the end of this post.
   
Solutions
There are a number of changes that can be made to help mitigate the low data rate problem.

1 Mbps frames allowed on the WLAN
Where possible, disabled 802.11b entirely which will drop support for 1 Mbps, 2 Mbps, 5.5 Mbps and 11 Mbps data rates. However there may be cases where you have to continue supporting 802.11b. I can see two such scenarios.

1. You have a significant 802.11b-only client-base. For example, if 10 of your 1000 laptops are 802.11b-only, drop support and if they really require WLAN access, provide them with a PCMCIA or USB 802.11a/g/n WLAN client. If however, 300 of your 1000 laptops are 802.11b-only, you will likely need to maintain support. This is particularly uncommon as of late 2011 or late 2008 for that matter!
2. You have some very expensive 802.11b clients. For example, you have 10 pieces of 802.11b-only medical equipment but each piece of kit costs six-to-seven figures.

If 802.11b cannot be disabled entirely, consider disabling 1 Mbps, 2 Mbps and 5.5 Mbps data rates so that you are left with only 11 Mbps in addition to your 802.11g data rates.
  
Excessive co-channel interference (CCI) caused by a high density of APs within the WLAN
One option is to re-survey and reposition your APs to lower the density although this is unlikely to be feasible in most cases. A better option is to consider disabling the 2.4 GHz radio on dual-band APs or entirely removing single-band APs.

Number of SSIDs broadcast by the WLAN
Consolidate your SSIDs to ensure a maximum of four to six. Dynamic VLAN allocation can help with this.

Rogue APs within the businesses premises
Locate and either remove or disable rogue APs. I have previously posted about how to narrow down which Rogue's are within the businesses premises, when running Cisco kit.

Rogue APs outside the businesses premises
It is typically stated that you have little control over bad neighbours however this discounts the usefulness of social engineering. If the neighbouring businesses WLAN is compliant with the Australian Radiocommunications (Low Interference Potential Devices) Class License 2000 or your countries equivalent then your best option is a little social engineering. You may have some luck approaching either the relevant technical contact responsible for the WLAN or otherwise you might need to speak with the big cheese. Explaining that 802.11b support is hurting not only your but also their WLAN is recommended. They may have a legitimate use for 1 Mbps data rates but this is rare as of late 2011. This approach is useful when you only have one or two bad neighbours. My client however has a large building in the middle of the Perth CBD. The layer 2 analysis revealed a large number of 802.11b-supporting bad neighbours and approaching all of them is unlikely to be feasible. The worst of these bad neighbours is actually a well-known municipal Wi-Fi implementation in the Perth CDB which will be detailed in part two.
 
EOF... almost
There are many causes of high channel utilisation and most have relatively easy solutions. The one over which you have minimal control is that of rogue APs outside the businesses premises. One particular bad neighbour is having a severe impact on my clients WLAN and this will be detailed in the gripping conclusion to this two part series!

Cisco WCS HA and WCS Navigator HA

A few gotcha's I have noticed regarding WCS High Availability and WCS Navigator High Availability, in no particular order.

WCS

• During installation, you specify that the instance of WCS you are installing is the primary.

• Likewise, you specify the secondary WCS instance during installation on the second box / VM or blade.

• You cannot browse to the secondary WCS web interface until you have failed-over to it. In other words, during normal operation, you cannot browse to the secondary instance.

• You can however browse to the WCS Health Monitor on the default port of 8082 on the secondary WCS, even when the primary WCS is active (non-failover state) - e.g. https://wcs02.deadbeef.com.au:8082/

• The WCS v7 configuration guide states that you must purchase a HA license. This is not required if you are using the Enterprise version of WCS. If you buy WCS with a 1000 AP (or greater) license, you are using the Enterprise license and so automatically get the HA capability.

• Consequently, only a single WCS Enterprise license is required for HA - you do not have to split your license in two (e.g., a 1000 x AP license can remain that way and does not need to be split into 2 x 500 AP licenses).

• In Windows, you cannot test failover by using the GUI tool to shutdown the primary instance. You either need to use the CLI command "nmsadmin.bat -switchover stop" or simulate it through more realistic means (shutdown the primary WCS, yank the cable or shutdown the switchport, etc). Personally I prefer a closer-to-the-real-world test by shutting down the server or switchport but the CLI command method is useful if these methods are not practical. More details at http://www.cisco.com/en/US/docs/wireless/wcs/7.0/configuration/guide/7_0main.html#wp1072955.

• One secondary WCS instance can provide HA for multiple primary WCS instances. This point does not seem to be particularly well-known. The box / VM or blade providing your secondary HA instance may need to be beefier than the primary WCS boxes if you want to allow for multiple primary failover's. That is, two primary's requiring 4 GB of RAM each may need 8 GB in the secondary in the case of both primary's failing.

• You must either manually point (your browser) to the secondary in a failover scenario, employ some DNS redirection tricks or similar redirection bizness.

• When you first log in to the WCS Health Monitor, the authentication key requested as your login credential is not the key you have specified during HA configuration but in fact the root password for WCS. Later you can use the key to login.

• Do not have the WCS directory or WCS log files open when testing failover. This will prevent failover from... failing over, presumably due to database file access issues. This is stated in the doco but is easy to forget when trouble-shooting. Ironically, I had log files open to troubleshoot a separate failover issue, which caused this (second) failover issue. Doh!

WCS Navigator

• WCS Navigator is not available in a HA configuration. I don't see this as a major issue as it is really just a WNMS of WNMS's. Your WLCs and WCS instances will not be affected if Navigator goes down.

• In the case of a WCS failover from primary to secondary, the WCS v7 configuration guide states that Any Navigators in the network start monitoring the secondary WCS - this is not the case. WCS Navigator does not support WCS HA. In a failover scenario, the primary WCS is shown as down and WCS Navigator has no knowledge of the secondary WCS. If you add the secondary WCS to Navigator, it shows as a completely separate WCS instance and therefore it appears that you have double the number of WLCs and APs. Apparently a feature request is in.

Cisco 3602i and Cisco 3602e APs

Edit (6th Nov 2011): Cisco has officially announced the 3600 series APs - the data sheet is pretty much identical to that detailed below. In addition a few more details of ClientLink 2.0 are available as is a white paper discussing the 3600 series.

This PDF shows that the antennas to be used on the 3602e are dual-band as speculated below. Ironically the gain on the external antennas for the 3602e are slightly lower than the internals at 5 GHz and equal at 2.4 GHz - still you might require the 3602e for ruggedised deployments or of course, other antennas.

Edit (17th Nov 2011):  Cheers to Marcus Burton for correcting me regarding dual-band antennas.That is, no antenna magic is needed for an antenna to utilise two frequencies simultaneously..

For the last few months there has been murmurs in the WiFi-Nerd... err, underground... yer, let's go with that, regarding the pending release of Cisco's new 3600 series access points. These APs have not been officially announced on the Cisco website as yet but 900-odd Google results for the model numbers, mostly from retailers, must mean they are no longer under NDA. In fact, the 3600 series was listed on Cisco's website however they have pulled the details but you know... this is the Internet's and ahh, Google cache exists. A few months ago, waking up in the middle of the night, thinking about wireless as I often do, I speculated that the soon to be released WLC code 7.2 would likely coincide with the 3600 series being released. Well 7.2 has not been released but the 3600 series data sheet lists it as required. Instead we have the recently released WLC code 7.0.220.0. There was no mention in the release notes of 3600 series support however. Google cache again to the rescue; this time for a "no longer listed on cisco.com" 7.1.91.0 WLC code release. The release notes mention that this release is a restricted limited lifetime release specifically for the 3600 series. The rest of the details are uneventful and in-line with the 7.0.220.0 more or less. Finally, a snazzy photo exists on this Ingram Micro hosted PDF data sheet.

The Cisco 3602e. Now featuring less antennas!

Initially, I had heard that this AP would support four MIMO streams. I thought this was logical considering Cisco is late to the game with their 'better-than-two-stream' offering. Sure, you're almost 12 months behind the earliest three-stream enterprise offerings, but you'll jump straight to four MIMO streams... kind of like Gillette's five-blade razor. However, since hearing this news I began to doubt that this AP would support four streams. Specifically, speculation from Cisco and Aerohive that enterprise vendors may skip four streams and jump straight to 802.11ac, though this really only makes sense if 802.11ac arrives on-time which is unlikely, given the history. 802.11ac delays aside, another issue with a four stream AP arriving now is the lack of client support; specifically there are none. Lastly, the Wi-Fi Alliance does not have a certification program to test four stream APs or clients.

So, a Cisco four stream in 2011 seemed unlikely... and the data sheet indicates exactly that. The 3600 series supports three streams - 4x4:3 but three streams none-the-less. An "in-no particular-order", "assuming the data sheet is accurate" list of my 3600 musings:

4x4:3: I imagine the reason I had been told four-streams was because of some confusion originating from the 4x4 nature of the AP. 4x4:3 means that the AP has four transmit antennas, four receive antennas but only supports three spatial streams. Keeping in mind, this is per band. More correctly, radio chains instead of antennas but antennas are easier to picture so we'll stick with that! So if you are only transmitting or receiving a maximum of three streams concurrently, what are the fourth antennas for? The extra antennas are used in 802.11n MIMO devices for similar reasons to those used in 802.11a/g devices - diversity and in the case of 802.11n, some particularly advanced diversity techniques. Space Time Block Coding (STBC), Cyclic Shift Diversity (CSD), Transmit Beam-forming (TxBF), Maximal Ratio Combining (MRC) are all 802.11n techniques which help to increase the signal strength or reliability available to the client or AP which can result in increased link reliability and throughput. Both the 3500 and 3600 series of APs support CSD, TxBF and MRC however the 3600 series now supports TxBF for a larger range of clients, detailed below. So 4x4:3 gives us three streams (450 Mbps maximum data rate) but with the benefit of 4x4. For reference, the 3500 series does 2x3:2. 

Three spatial streams: Three streams with 40 MHz channels and a 400ns Guard Interval tops out at 450 Mbps. One of the major advantages of three streams is the ability to move back to 20 MHz channels at 5 GHz whilst still achieving a maximum data rate of 216 Mbps. Not quite the 300 Mbps afforded by using 40 MHz channels but much better than the 144 Mbps from 20 MHz channels. These extra channels are particularly important in Australia where we currently only have access to six 40 MHz channels and potentially four, if radar starts causing you significant grief. Whilst there aren't many three-stream clients available, your APs are going to be in place for several years at which point there will hopefully be a significant portion of three-stream enabled laptops - I doubt we'll ever see a three or four stream smart-phone on the other hand. 450 meg clients, where art thou!

ClinkLink 2.0: Cisco's beefed up transmit beam-forming (TxBF) offering. For reference, the 3500 series (amongst others) offers TxBF in the form of ClinkLink (1.0). A few weeks back, I was pondering why Cisco only offered ClientLink to legacy (802.11a/g) clients. I thought that 802.11n single-stream devices (smart-phones, tablets, etc) could benefit greatly from beam-forming - these are precisely the sorts of devices that could see a benefit from a few extra dB due to their generally weak receive sensitivity. To support two or three stream clients though you need an extra antenna and the 3500 series only does 2x3:3 (two transmit antennas) and therefore does not have a spare transmit antenna free when servicing a two stream client. This is where the 4x4:3 comes in handy - that fourth transmit antenna can be used to provide beam-forming to one, two and three-stream 802.11n clients. So now we have TxBF for legacy, one, two and three stream 802.11n clients. Hopefully ClientLink 2.0 implements some antenna beam-forming action over the ClientLink 1.0 on-chip beam-forming where marginal gains were, at least originally, achieved. Count-down to a Ruckus blog post dissing this TxBF implementation as half-assed ;). To be fair, Ruckus are the bomb when it comes to antenna magic!

200 mW (23 dBm) of transmit power: The 3500 series only offered 200 mW for 802.11b data rates which should be disabled in almost every new deployment anyway. As it is best practice to match the APs maximum transmit power to that of the poorest client, I can't see where this extra power would come in handy. If you were using the 3602e for a bridge link perhaps but a higher gain antenna would be a better bet. I can't help but think that this power may be spread between the antennas when performing one of the supported types of transmit diversity though... hmm.

Antenna gain: Down from 4 dbi on the 3500 series to 2 dbi on the 3600 series at 2.4 GHz. Up from 3 dbi on the 3500 series to 5 dbi on the 3600 series. With only four external antennas on the 3602e my guess is that they are dual-band antennas. Whilst this works fine on a client as it is only associated to one band at a time, pretty much all decent APs must be able to use both bands concurrently. For an AP to transmit or receive on both bands simultaneously I imagine some sort of smart antenna technology is being employed - pure speculation on my part and all based on the photo! We will see.


PoE: Powered by 802.3af like all other two and three stream enterprise APs (the EOL Cisco 1250 not with-standing). Surely it is in the various Cisco switching business units interests to require 802.3at for the AP ;). Of course, customers would not be happy knowing that all other three stream APs run off a mere 12.95W!. At this rate we will have to wait for 802.11ac to see some 30W AP lovin!

Band support: The 3600 series appears to only be available in a dual-band version. About time really, as I find the single-band APs to be a waste of silicon!

Weight: Light! Like the 3500 series, due to the CleanAir capabilities, this AP is light-weight only. Now the question is, which autonomous AP IOS can be used to survey with the 3600 series!

The LED: It's bigger - surely its most impressive feature, by far! ;) 

EOF... almost
Like most vendors with a large market share, Cisco receives their fair share of flack regarding a lack of innovation, resting on ones laurels and so on. As the first enterprise vendor to offer 4x4:3, up to three stream beam-forming and the 'not-really-that-long-ago' CleanAir (AP spectrum analayser integration) I think at least the Cisco Wireless Business Unit still has the ability knock out an innovative product. Now I wait for the official release to get my hands on one and do some testing!

Since the first three-stream enterprise AP was released I kept seeing Cisco down-play the importance of three-streams. I assume that downplay will end right about ... ;)

Cisco WLC 7.0.220.0 and WCS 7.0.220.0 Released

A few notes regarding the recently released WLC and WCS software updates.

WLC 7.0.220.0
Release Notes: http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn7_0_220_0.html

• There are only a couple of new features with the rest of the update comprised of bug fixes:
• Online Certificate Status Protocol (OCSP) support. OCSP is an updated method of certificate revocation over the older Certificate Revocation Lists (CRL).
• Ability to view AP images stored in WLC flash by way of the new CLI command show ap bundle {all | primary | secondary} 
• Band Select and Load Balancing Support on Cisco Aironet 1040 series Access Points
• Support for AIR-CAP1552SA-x-K9 & AIR-CAP1552SD-x-K9 mesh APs
• I had heard that support for the 2100 and 4400 WLCs was meant to be dropped in this release but the release notes still show them as supported
• There is a note detailing that WCS will loose connectivity if you are upgrading from 7.0.116.0 to 7.0.220.0 AND using SNMPv3. Workarounds are provided.
• The rest is comprised of the usual assortment of bugs fixes

WCS 7.0.220.0
Release Notes: http://www.cisco.com/en/US/docs/wireless/wcs/release/notes/WCS_RN7_0_220.html

• There are no new features however support for a few WLCs has been dropped. It seems strange that WCS has dropped support for these WLCs but support has not been dropped in the paired WLC 7.0.220.0 image. Perhaps this is an oversight in the WLC 7.0.220.0 release notes. The following Location Appliances and WLCs have been dropped:
• Cisco 2700 Series Location Appliance
• Cisco 2000 Series Wireless LAN Controllers
• Cisco 4400 Series Wireless LAN Controllers
• There is now version consistency between WLC and WCS images
• The rest is comprised of the usual assortment of bugs fixes

FCC crackdown on RF jammers

I just read an article concerning the FCC cracking down on US websites selling RF jammers. This made me wonder whether the Wi-Fi-nerd-pleasing NutsAboutNets AirHORN jammer... ahem, signal generator, is affected. Well, from looking at the list of websites in the 'Citation and Order', the AirHORN is safe.

To be fair, whilst the AirHORN could be classed as a wideband jammer, it doesn't take out the whole 2.4 GHz or 5 GHz band at once. It therefore isn't the same as the traditional jammers that the FCC is targeting which are all-band jamming, affecting the entire 2.4 GHz band for example. When you use the AirHORN, you can see that it is a modulated 802.11 signal. It is really a glorified Wi-Fi client which is why you have to pick the 802.11 channel to start the signal generation or allow it to sweep through the channels. I can't help but think that the AirHORN is just using a modified version of the Queensland Attack. This shows that it really isn't intended for jamming and is meant to be used as a signal generator - therefore it wouldn't be affected by this FCC crackdown.

I have used the AirHORN during training to demonstrate spectrum analysis. It (should) also be useful for testing device classification in the big three Spectrum Analysers (Cisco SpectrumExpert, AirMagnet SpectrumXT and Metageek Channelyzer Pro). In addition, it (should) be useful for testing / demonstrating a high duty-cycle interferer in the new breed of AP-integrated spectrum analysis implementations (Cisco CleanAir, Aruba RFProtect, Aerohive Spectrum Analysis, Motorola AirDefense Spectrum Analysis, etc).

AirHORN aide, this citation from the FCC will have little effect on those in the US wishing to purchase all-band jammers because apparently you can now buy goods on-line... from overseas no less! What an age to be alive! Additionally, publicising this issue may well bring about the Streisand Effect. I am not advocating malicious use of a jammer however getting a hold of one will remain easy. Globalisation biting the US in the ass, yet again! One of the great ironies of those advocating, selling or actually using all-band jammers maliciously is their total ignorance as to their operation. Many people who would use these jammers would inflict more damage on their own Wi-Fi communications without realising it. From one of the sellers websites - "Place in your friends home as a prank or use it to secure you own Wi-Fi.". Well I guess if even you can't access your Wi-Fi, it could be deemed secure!

If the goverment can't help me, who can?
So if the FCC crackdown has little effect in helping reduce the market for jammers what are your options? The key for those operating Wi-Fi networks is to have the right tools on hand to address the issue - namely, a Spectrum Analyser. Metageek has made this particularly easy in recent years with their affordable analysers as have Wi-Fi vendors rolling out their AP-integrated offerings. Also, this is yet another reason to purchase 5 GHz capable Wi-Fi clients, where possible. The vast majority of all-band jammers transmit at 2.4 GHz as do the majority of other high duty cycle transmitters (baby monitors, A/V transmitters, wireless video cameras, etc). Whilst 5 GHz all-band jammers exist, they are few and far between and no where near as cheap.

EOF.... almost
As for the FCC crack-down, the Streisand Effect has worked and reminded me that I have been meaning to buy a cheap all-band jammer for (isolated) demonstrations and spectrum analysis testing. I've thrown an analogue video camera and A/V transmitter into the cart for good measure. Thank you FCC!

WLAN Controller Discovery Best Practices

The methods that APs use to discovery the WLAN controller(s) in a Cisco environment are relatively well known. Andrew vonNagy has documented them quite thoroughly. Take a look at his post if you are not familiar with these methods.

Whilst Andrew has covered the details of how these discovery methods work I thought I would provide my best practices as to when you may use one method for controller discovery over another. As I have referenced Andrew's post, I will copy his list of discovery methods verbatim in order to maintain a blog post SOE ;).

WLAN controller discovery methods
1.       Broadcast on the local subnet
2.       Local NVRAM list of the previously joined controller, previous mobility group members, and administrator primed controller through the console
3.       Over the Air Provisioning (OTAP) (subsequently removed in version 6.0.170.0 code)
4.       DHCP Option 43 returned from the DHCP server
5.       DNS lookup for "CISCO-CAPWAP-CONTROLLER.localdomain"

Broadcast
I never rely on this method nor would I recommend it. I have encountered issues with its use though these may be bugs long since squashed, none the less I prefer not to rely on it. The only time I would consider it is if I the server team was not willing or able to modify DNS or DHCP in order to implement the DNS or DHCP discovery methods. Though you can bypass the server team and run DHCP on a router, this means you are likely not maintaining consistency with your SOE and additionally Option 43 on a router is quite messy. If the controller is on a different subnet to the APs you will need to configure an ip-helper. This will result in the WLAN controller receiving other forwarded protocols (by default this includes, TFTP, DNS, NETBIOS, DHCP, TACACS amongst a few others however these defaults can be disabled using 'no ip forward-protocol up <protocol>').

Local NVRAM or Primed
Whilst the APs can store details in NVRAM of controllers they have previously associated to, they have to get this information to begin with so this method is not going to work as your only method of discovery. In other words, know that it exists but use another method.

APs can also be primed which involves manually configuring them with an IP, Mask, Gateway and WLAN controller address. The APs IP address could in fact come via DHCP and then you would just prime it with the controllers IP address. But if you have a DHCP server available why not configure DHCP Option 43? Perhaps such a scenario exists but it wouldn't be common to do this in any enterprise WLAN deployment. But then, priming more than half a handful of APs in any enterprise deployment would likewise be a pain. The only time I prime an AP is when I have a one or two APs to be deployed for use in a temporary office or when I have done WLAN training and needed to get an AP up and running before the server-side infrastructure was in place.

I find that sometimes a company will associate an AP with a local controller in order to download the appropriate code and then ship the AP to site for connection to the remote sites controller. Once on-site the AP is powered up and attempts to connect to a controller. The issue with this comes with the AP having saved the local controllers details to NVRAM and may result in the AP connecting to the local controller if the primary controller configuration is not performed on the AP, instead of the remote sites own controller. I am unsure what the logic is here as the code upgrade will be performed over the sites LAN so no time or WAN bandwidth is saved. Basically, don't bother as there is no benefit and it will just result in more trouble-shooting on your part. The number of times I have seen APs connect to the wrong controller due to a poorly thought out design...

Keep in mind that APs can also find a controller based on the mobility group of any controller they have already associated with. I was recently trouble-shooting an issue that involved an AP joining the wrong controller. After verifying DHCP, DNS and priming methods I checked the mobility group of both controllers. Sure enough they were in the same mobility group - the local AP had learned about the remote controller by means of the local controller passing the details on. A typo in the primary and secondary controller configuration meant that it disregarded these controllers and used the information it learnt via the mobility group configuration. The secondary issue here was a design issue - the controllers should not have been in the same mobility group. 

Over the Air Provisioning (OTAP)
No longer available nor should it have been in my opinion - it was always a bad idea.

DHCP Option 43
OK, now we get to the first of the two recommended methods of controller discovery. Option 43 seems to be the most common method used for discovery. I recommend its use whenever you have a controller at each of your sites and therefore you want each of the 'Site XX APs' to connect to the 'Site XX WLAN controller'. In each of the DHCP scopes for each site, configure Option 43 for the particular models of APs at that site, pointing the APs to the appropriate sites controller.

The problem with the DHCP discovery method can come when you need to configure Option 43 for each model of AP at each of your sites. Not an issue with one site and one model of AP. But take 30 sites, 30 DHCP scopes, potentially 30 DHCP servers and a few models of AP at each site. In addition, in 18 months when you have left the business, is someone going to know that some DHCP modifications are required when a new model of AP is rolled out? If you have a separate WLAN controller at each site however, then it really is the best method despite the extra admin overhead. On the other hand, if you have either a centralised controller or a single / pair of controllers at a single site, I would recommend using the DNS method.

Another time to look at the DNS method is if you happen to be hosting DHCP on one of your routers. The Option 43 router configuration is messy compared with the ease of configuration involved in getting DHCP Option 43 up and running on a Windows Sever 2003 / 2008 box so stick with DNS in this case.

DNS
The time to use DNS is when all of your APs connect back to the same WLAN controller(s). This could either be remote sites using a centralised controller or perhaps you just have a single site. Let’s say you have 30 sites. Instead of configuring 30 DHCP scopes or 30 DHCP servers with Option 43, just configure an A or CNAME record for CISCO-CAPWAP-CONTROLLER.localdomain pointed at your centralised controller(s). If any new model of AP is rolled out, you don't have to change anything regarding your discovery method, unlike with the DHCP method. This assumes of course that all of your sites fall under the same .localdomain. You can a create global scope option in Windows Server 2003 / 2008 but then Option 43 will apply to all your scopes - not just the AP scopes. This may or may not be of concern.

If however your 30 sites each have their own controller and assuming you DON'T have a separate sub-domain for each site you are going to have problems with APs associating to the wrong controller. You would need to create 30 A or CNAME records for the 30 WLAN controllers but how do you direct APs to the correct controller? You can't do it in any reasonable fashion. Yes, you can specify primary and secondary controllers but this occurs after the AP has associated. You could also configure the master controller option but this is messy. Someone will without a doubt forget to specify the primary controller at some point and you will end up with APs associated to the wrong controller. Inexperienced engineers trouble-shooting the issue will scratch their head as to why the AP has not associated - not realising that it has but is associated to another controller.

Logging
Though not directly related to controller discovery, I will discuss a little know DHCP option that can greatly aid in trouble-shooting AP join issues.

Out-of-the box APs transmit syslogging messages as limited broadcasts (255.255.255.255). When you have an AP that is receiving a DHCP address but is not associating to the controller you may need to console in to see where the issue lies - not very convenient as the AP is typically mounted or often at another site. You cannot telnet or ssh as this is disabled by default and you cannot enable it until after the AP has associated.

The solution - configure DHCP Option 7. This will cause the APs to transmit their logging messages to your syslog server. You can now grep your logs to try and establish why the AP cannot associate.

EOF... almost

Priming - use it when you need to temporarily setup a small number of APs
DHCP - use it when DHCP Option 43 can easily be configured and when you have multiple sites each with their own controller and a global domain used throughout all of your sites.
DNS - use it when you have a centralised controller, a single site or controllers at each site and a sub-domain for each of the sites. This is my preferred method where possible.

Rogue AP Classification

When I configure a Cisco WLAN controller, one of the configuration steps I normally take is to configure a Rogue Classification Rule that marks as malicious any rogue AP detected with a signal of -70 dBm or greater (I used to configure the rule for -69 but got sick of the giggles when explaining the implementation). This figure can obviously be tweaked - somewhere between -65 dBm and -75 dBm would be appropriate for most environments. So what is the significance of -70 dBm? Well it is the signal strength that I feel is a good middle-ground in locating rogue APs that are probably on the premises whilst eliminating most of the false positives from surrounding homes and businesses. Sure, a small number of false positives will occur depending how close surrounding businesses and homes are but without this rule, locating which rogue APs are actually within the business is like finding a needle in a haystack. Likewise, in most modern WLANs designed for capacity, the vast majority of rogue APs which are in fact on the businesses premises should be detected with of signal of -70 dBm or greater due to the high density of APs.

The configuration required for the -70 dBm rule

Without this rule...
If you do not have Cisco WCS running, you would have to click on every single rogue on the WLAN controller GUI to find the strongest signal strength heard by one of your APs. Unless you have only a handful of rogues, this is unlikely to happen as it is far too time consuming - looking on my current work WLAN controller shows close to 400 rogue APs. Things are a little better if you have WCS as you can see a large number of rogues and their associated signal strengths on a single screen. None the less, having to constantly check this list of rogues should not be required.

With this rule...
Creation of this rogue rule eases this pain. Once the rule is configured, on the WLAN controller GUI you can navigate to MONITOR --> Rogues --> Malicious APs and all rogues detected at -70 dBm or greater will be listed. Some of the rogues I see listed have a signal strength lower than -70 dBm, even from the detecting AP with the strongest strength. I am unsure if this is a bug (running 7.0.116 code) or that this rogue was previously detected with a stronger signal but has not yet been removed from the malicious list. Regardless, the list of rogues is far more manageable.

In WCS, things are even easier. Modify your general tab so that one of the components you see is 'Recent Malicious Rogue AP Alarms' or 'Malicious Rogue APs'. Now every time you log into WCS you will see if you have any potential rogues worth investigating..

Configuring this rule on a recent WLAN deployment caused 5 of the 86 APs to be marked as malicious. One of these was in fact on the premises with the other four false positives. In this case, the figure of -70 dBm could be tweaked to around -65dBm to reduce the number of false positives and due to the high density of APs installed (the WLAN was surveyed for 5 GHz VoWiFi) I would still be confident of detecting any 'on-premises' rogues. Unfortunately malicious is not an accurate term but it cannot be changed on the WLAN controller.

Are these APs really malicious?
Usually not, as I explain below. I classify rogues into one of three categories:

1. Real malicious rogue APs
2. Employee supplied or otherwise 'on-the-premises' APs
3. False positives from nearby businesses or homes

Real malicious rogue APs
The term 'rogue AP' and certainly 'malicious' exist for this category of AP but ironically it would be under rare circumstances that you would actually catch a hacker with the default rules. To have some chance of doing so you would have needed to have configured this -70 rule, actively (on a daily basis) monitor your WLAN controller, WCS or other WNMS, actively track down each malicious rogue so as to eliminate category two and three rogues and finally the hacker would need to have placed this rogue on your premises in an easy to find location or actually still be on the premises. Hello hacker from several kilometres away and hello 24dB parabolic antenna! How many WLAN security breaches have actually taken place via these circumstances? I realise an evil-twin attack could occur but you would have to be very conscientious to capture one by this method.

Your best bet here is to rely on your (hopefully) well-designed and therefore well-secured WLAN alongside your wIDS or wIPS for signs of spoofed deauthentication or disassociation frames. Cisco's Management Frame Protection (MFP) would he helpful here but unfortunately requires CCXv5 clients. Your only hope of enabling it would therefore be on a voice WLAN where you had all Cisco 7925G phones which are CCXv5 compliant. I find most non-Cisco clients these days are CCXv4 and CCXv5 clients are uncommon. The standardised version of MFP is 802.11w and I did see a reference that there may be a Wi-Fi Alliance certification for clients in the works which would be great, if I interpreted correctly.

Employee supplied or otherwise 'on-the-premises' APs
This is the category that we are trying to identify with this -70 dBm rule. This is also the category that is mentioned in every article or book that discusses rogues. I have found that these APs typically fall into one of three categories:

Employee-supplied APs
Occasionally I have found employees to bring in a SOHO Wi-Fi router or AP so that they may access Wi-Fi at work. Jennifer points out that this is increasingly unlikely and I agree to some degree. Western Australia is not the US however. We actually still have an economy and many very highly paid workers where the cost of an AP purchased for work would be considered chump-change. In addition, in many regional areas 3G coverage is poor or non-existent unless your carrier is Telstra where you have traditionally paid through the nose for data. Consequently, I feel you are more likely to see user-supplied rogues here. I have certainly seen them but it is not the most common type within this category in my experience.

Business-supplied APs
I find these to be much more common than employee-supplied APs. Often in a large multi-site enterprise, the local site will use their own funds to purchase a SOHO Wi-Fi solution where a business-supplied WLAN does not exist, regardless of your businesses polices on the matter. In addition, many businesses do not have WLAN policies in place, particularly if they are yet to deploy their own WLAN. These rogues are typically detected upon roll-out of the new WLAN and should be eliminated at this time.

Business within the business
Ahh! The ol' business within the business trick! Many of the rogues I see are from a small business that operates from the main businesses premises. A school book-shop within the school or a GP / dentist within the hospital. These businesses usually operate with some autonomy, often have their own ADSL connection and consequently have a SOHO ADSL Wi-Fi router. This can present a security issue as often this associated business shares the main businesses wired LAN and of course, rarely is the SOHO Wi-FI router going to be sufficiently secure. It can also present performance issues - 802.11b enabled, adjacent channels configured, 40 MHz 2.4 GHz channels configured, etc. Many times the Wi-Fi isn't even used, so getting it disabled is not much of an issue.

False positives from nearby businesses or homes
This is the category that we are trying to eliminate with the -70 dBm rule and these make up the vast majority of detected rogues thanks to the pervasiveness of Wi-Fi. Whilst these can generally be ignored I do find them interesting to look at to get a gauge of 'APs in the area'. What percentage are 2.4 GHz vs. 5 GHz, what are the most common vendors, how much WEP is still in use - you know, all of those things that seemed cool when Netstumbler and War-driving was all the rage back in the early 2000s! I should mention, Western Australia via the WAFreeNet was the first community wireless network to perform WarFlying back in the day... or at least the first to get slashdotted for it!

Whilst it is commonly said that you have no control over these types of rogues I tend to disagree. If a rogue is being a bad neighbour by exhibiting any of the following behavior, it may be worthwhile getting in contact with the businesses IT person and explaining that these issues are negatively affecting both his or her business and your own. It is in their interest to fix the issue. Of course if they don't comply, you could always try gentle persuasion via the AirHORN 2.4 GHz jammer + high-gain antenna - just make sure it has very small side and back-lobes!... I'm kidding of course ;)

The following are reasons to hit up your 'bad neighbour' with some advice:

• 802.11b enabled where client support is not required (you would have to take a stab here and assume they have no 802.11b-only clients)
• Adjacent channels in use at 2.4 GHz (At 2.4 GHz, in most circumstances only channels 1, 6 and 11 should be used)
• Overly high transmit power from APs (this may be difficult to determine however)
• 2.4 GHz 40 MHz channel usage

EOF... almost
Whilst rogue detection rules may not be particularly useful at actually finding real malicious APs, creating this rogue rule can still help you improve the security and performance of your WLAN by identifying employee-supplied, business-supplied, business within the business and bad neighbour rogues.

Eliminating 802.11a clients from your WLAN

Several years ago I was working on a large-scale Cisco WLAN deployment where my number one technical goal was achieving a high performance WLAN design. This was due to the high user density and high bandwidth requirements. In other words, I was trying to wring every last piece of bandwidth out of the WLAN!

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 
My last attempt was to disable 802.11a support on a best effort basis. Unfortunately, low-level client configuration of laptops on an enterprise scale has not yet been worked out by vendors. Disabling 802.11a in Windows can be done from the advanced tab of the WLAN client driver.

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
This is a solution that is worth the effort where performance is key and you have a detailed insight into the client population. In your average office WLAN where there are far easier wins to be had and performance isn't nearly as critical, this would not be worth the effort. I have suggested this solution to a few clients since but as it requires a fairly solid device inventory tool and a willingness to get the hands dirty, few clients would have implemented it themselves.