Catalyst 9800 with 9115 AP strange datarate behavior

[joey.debra]

Ok, amongst all the bugs I have encountered with the Catalyst 9800 running 16.12.1 this one is just weird.

Certain types of clients who only support 2.4GHz are denied onto the network due to missing datarates.
The funny thing is two-fold.

The AP's on the WLC received an RF-tag which in the beginning disabled the b-datarates and put 12 and 24 as mandatory rates.  However the main network setting is still at default where 1,2,5.5,11 are mandatory rates.  I didn't realise this until after I "solved" the problem another way.  However I believe the AP should use the datarates as mandated by it's RF profile.

So the errors spewed from the debug on the WLC showed this:
[dot11-validate] [24082]: (ERR): MAC: 0024.e4xx.xxxx Dot11 validate radio rates. Missing Supported Rate for index = 7, encode value: 24, radio type: DOT11_RADIO_TYPE_BG
[ewlc-infra-evq] [24082]: (ERR): 0024.e4xx.xxxx CLIENT_ASSOC_FAIL Failure = IE_VALIDATION_FAILURE Validation Failure Type = 18WLAN profile = PROF-WIFI-XXXX, Policy profile = PROF-POL-XXXX
[dot11] [24082]: (debug): MAC: 0024.e4xx.xxxx Dot11 update co assoc fail. Sending association failure to client: DOT11_STATUS_DENIED_RATES
[dot11] [24082]: (debug): MAC: 0024.e4xx.xxxx dot11 send association response. Sending association response with resp_status_code: 18

So then I did an over-the-air capture and found the tags in the beacons, probes and association frames:

AP beacon
Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 18, 24, 36, 54, [Mbit/sec]
Tag: Extended Supported Rates 6, 9, 12, 48, [Mbit/sec]

Client probe request
Tag: SSID parameter set: xxxxx
Tag: Supported Rates 1, 2, 5.5, 11, [Mbit/sec]
Tag: Extended Supported Rates 6, 9, 12, 18, 24, 36, 48, 54, [Mbit/sec]

AP probe response
Tag: SSID parameter set: xxxxx
Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 18, 24, 36, 54, [Mbit/sec]
Tag: Extended Supported Rates 6, 9, 12, 48, [Mbit/sec]

Client association request
Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 18, 24, 36, 54, [Mbit/sec]
Tag: Extended Supported Rates 6, 9, 12, 48, [Mbit/sec]

AP assocation response
Tag: Supported Rates 5.5, 11, 9, 12(B), 18, 24(B), 36, 48, 54, [Mbit/sec]
Tag: Extended Supported Rates: Undecoded
Tag Number: Extended Supported Rates (50)
Tag length: 0
Tag Data: <MISSING>

So basically the AP only uses the RF profile datarates in the association response frame while falling back to the defaults for all the rest of the mgmt frames.
And even worse is that the client even supported all the necessary datarates but put the necessary datarates in the extended datarates IE because it received other mandatory rates in the probe responses.

After playing a bit with the datarates I finally just put all datarates on supported and 11Mbps as mandatory and then the clients were allowed on the network.
I'll have to wait to change the network parameters since that requires disabling the entire band and downtime needs to be in a window.

Any thoughts/suggestions?

[Scott Fella]

You have to look at this the same as AireOS. Your RF Profiles takes precedence over global configuration. I also have some devices that only support 2.4ghz and evening though they are 802.11bgn, the device requires 1mbps as mandatory or else it will not connect. When I brought up my 9800-L at home:), I basically took what I already had on my 2504/5520 and copied it as close as possible. When I converted to my 9800-L with 9120’s and 9130’s, everything joined and never had any issues.

[joey.debra]

I did look at it the same so I expected the RF profile and RF tag to take full precedence over the global network config.
But in some bastardized way it used global for the probes and beacon but uses the RF profile for the actual association.  Probably another bug.

I truly hope there is a truly stable release upcoming soon!

[Scott Fella]

Well to rule that out, change the global to match your RF profile tag.

[Scott Fella]

Come to think about it. I think what you see is correct. The probes will be sent on the lowest supported rate by the client. The probe response happens only on the lowest mandatory rate.

[joey.debra]

Hmm I disagree.

It's true the beacons are sent at 1 Mbps, but the fields I gave are the actual tagged parameters inside all the frames.
Even if a beacon or probe response is sent at 1 Mbps, it should still list the datarate set the AP supports and which speeds are mandatory.

If I check this at home on my mobility express AP's the tagged parameters datarates and extended datarates never change between beacons, probes or assoc response frames.

[AKohler07]

Hello, I'm seeing some similar behavior.

RF Profile on Cat 9880 the same as on WISM. But Client goes in Exclusion List.

In the Logs: 

CO_CLIENT_DELETE_REASON_DOT11_DENIED_RATES, fsm-state transition 

my workaround:

                Cat 9800  WISM

1 Mbps     Disable    Disable
2 Mbps     Disable    Disable
5.5 Mbps  Disable    Disable
6 Mbps    Disable     Disable
9 Mbps    Supported Disable
11 Mbps  Mandatory Disable
12 Mbps  Supported Supported
18 Mbps  Supported Mandatory
24 Mbps  Supported Supported
36 Mbps  Supported Supported
48 Mbps  Supported Supported
54 Mbps  Supported Supported

any idea?

Andreas

[Scott Fella]

I have a 2504/5520/9800-L-C and 9130 eWLC. I have devices that only support 2.4ghz and requires 1mbps. When I look at the pcap's, I see the same supported and mandatory rates from my aireos and ios-xe. There is a default for data rates if your rf profile tag is using default or you can specify the rates when using rf-tags. I'm running the latest 17.2 on my 9800 and eWLC.

[AKohler07]

Hi,

please note this bug:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt37835

Symptom:
Client is not able to associate to 2.4ghz SSID when 11b is disabled and client is sending assoc_req with 11b as supported and 11g as extended supported rates.
Client receives an assoc_resp failure
Following logs are seen in ra_traces:
Dot11 validate radio rates. 11g rates are set to basic. Rejecting association request of 11b client on radio: DOT11_RADIO_TYPE_BG
Dot11 update co assoc fail. Sending association failure to client: DOT11_STATUS_DENIED_RATES
dot11 send association response. Sending association response with resp_status_code: 18

Conditions:
Observed in 9800 when 11b rates are disabled and only 11g rates are enabled
NOTE - This issue is specific to this particular type of zebra clients. this config would work with many of the clients in market

Workaround:
Enable 11b rates, and remove mandatory rates in 11g rates.