Update: WLC Upgrade Issue Affects 11n Data Rates

Update Sep. 20, 2010: Cisco has created new bug ID CSCti89945 for this issue.

CSCti89945 Bug Details


wlc upgrade to 7.0.98.0, N breaks requires wlan deletion-readdition.

Symptom:

when a wlc is upgrade from say 4.2.176.0 or later to 7.0.98.0 the wlans do not work with the N rates. a/b/g regular rates work on N capable clients

Conditions:

Issue is seen specifc to N rates when upgrade from lower versions to 7.0.98.0

Workaround:

Delete the WLAN and recreate or add the WLANs back for N rates to start working on wlc.

Original Post:
It appears that I have found a bug affecting Cisco wireless LAN controllers when upgrading code from 4.2 to either 6.0 or 7.0. This effect has been found on both 4400 series controllers and WiSM blades in our environment.

After upgrading, everything appears to be correct, but mysteriously the 802.11n data rates do not take effect. Clients can still authenticate and connect to the network, but the highest achievable data rate is 54 Mbps.

Digging into the issue, it appears there may be corruption of the configuration file during the upgrade which prevents 11n APs from being allowed to use the 11n MCS data rates.

To verify the data rates in effect on the AP, open a terminal session and enter the "show controllers d0" command (or "d1" for the 5GHz radio):

AP# sh controllers do 0 

interface Dot11Radio0

Radio AIR-AP1140G, Base Address omitted, BBlock version 0.00,

Software version 3.00.75

Serial number: omitted

Number of supported simultaneous BSSID on Dot11Radio0: 16

Carrier Set: Americas (US) (-A)

Uniform Spreading Required: No

Configured Frequency: 2412 MHz  Channel 1

output trimmed

Receive Antennas : right-a left-b middle-c

Transmit Antennas : right-a left-b, cck single, ofdm all

Antenna: internal, Gain: Allowed 8, Reported 0, Configured 0, In Use 8

Active Rates:  basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.

Current Rates:  basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.

Allowed Rates:  1.0 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0

All Rates:  1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.

Default Rates:  basic-1.0 basic-2.0 basic-5.5 basic-11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15

Here you can clearly see that the allowed rates are limited to the legacy 802.11b/g rates and do not include the 11n MCS rates.

A workaround is to delete the existing SSID configuration and re-create it from scratch. This seems to allow the AP to transmit at the 11n rates and fixes the issue. However, this is not a very scalable workaround for large deployments such as ours. With hundreds of controllers it will not be feasible to manually delete and re-create SSIDs across all of them.

I have also tried exporting the existing configuration prior to upgrade and re-importing it after upgrade, but the same issue results. Specific code versions tested include 4.0.205.0 to both 6.0.196.0 and 7.0.98.0.

I have an open Cisco TAC case on this issue and will post an update on any resolution they provide to prevent the issue from occurring.

-Andrew