CSCti89945 Bug Details
wlc upgrade to 126.96.36.199, N breaks requires wlan deletion-readdition.
when a wlc is upgrade from say 188.8.131.52 or later to 184.108.40.206 the wlans do not work with the N rates. a/b/g regular rates work on N capable clients
Issue is seen specifc to N rates when upgrade from lower versions to 220.127.116.11
Delete the WLAN and recreate or add the WLANs back for N rates to start working on wlc.
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
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
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 18.104.22.168 to both 22.214.171.124 and 126.96.36.199.
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.