Client drops when roaming from 3602 to 9120

[tvancamp6]

We are in the process of upgrading a 5520 with 3602 access points to a 9800 with 9120 access points. As we have a large number to replace and in high ceilings, we built a mobility peer between the 5520 running IRCM and the 9800 expecting roaming to be seamless. What we hadn't considered was the possibility of clients dropping when the protocol changes from 802.11n to 802.11ac. We are trying to confirm if this is the the issue or if there is something else going on, but I am wondering if it is possible to set the 9120's to supporting only up to 802.11n to prevent the clients from jumping to ac.

[tvancamp6]

I actually found where to modify this under Configuration>Radio Configuration>High throughput

[marce1000]

  - Good , does it help on the roaming issues ( I have doubts) ? ; anyway have a checkup review if the (new) 9800 controller configuration with the CLI command show tech wireless ; feed the output into :
                                 https://cway.cisco.com/wireless-config-analyzer/

    In essence for new 9800 setups this could be considered a requirement ; but WirelessAnalyzer remains very useful too after configuration changes (later on) and after upgrades , (e.g.)

 M.
                                         

[tvancamp6]

Thank you for this analyzer, I'll be reviewing it. I was under the impression that our roaming issue was mainly just that we were in the process of replacing 3602's, but even today during a test, I found that a client roaming between 9120's was changing the protocol each time it roamed. The client can support 802.11ac as I have seen it connect that way, but it is not always opting for that protocol and switching between 2.4GHz and 5GHz. I'm trying to see if we can force the client to stick with just one to see if the issue lessens, but I was quite surprised by this behavior. This is a snapshot of the same client roaming to all 9120 APs on the same controller:

Association Time	AP Name	Radio Type	SSID	Protocol	Session Duration	Reason
Wed Jul 26 13:15:51 UTC 2023	IT_OfficeW-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	9 min 35 sec	Disassociation detected
Wed Jul 26 13:25:26 UTC 2023	65MZ-AP	802.11a/n/ac	IO	802.11ac	50 sec	Disassociation detected
Wed Jul 26 13:26:17 UTC 2023	61KY-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	40 sec	Disassociation detected
Wed Jul 26 13:26:57 UTC 2023	65MZ-AP	802.11a/n/ac	IO	802.11ac	45 sec	New AP association detected
Wed Jul 26 13:27:42 UTC 2023	usok-lawton-40FY-AP	802.11a/n/ac	IO	802.11ac	35 sec	Disassociation detected
Wed Jul 26 13:33:32 UTC 2023	65MZ-AP	802.11a/n/ac	IO	802.11n(5GHz)	3 min 31 sec	Disassociation detected
Wed Jul 26 13:37:03 UTC 2023	61KY-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	45 sec	New AP association detected
Wed Jul 26 13:37:48 UTC 2023	WichitaE-AP	802.11a/n/ac	IO	802.11ac	5 sec	New AP association detected
Wed Jul 26 13:37:53 UTC 2023	56Q-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	2 min 30 sec	Disassociation detected
Wed Jul 26 13:40:23 UTC 2023	WichitaE-AP	802.11a/n/ac	IO	802.11ac	2 min 20 sec	Disassociation detected
Wed Jul 26 13:42:43 UTC 2023	58CZN-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	4 sec	Disassociation detected
Wed Jul 26 13:43:43 UTC 2023	65MZ-AP	802.11a/n/ac	IO	802.11n(5GHz)	0 sec	Disassociation detected
Wed Jul 26 13:43:48 UTC 2023	63Q-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	1 min 5 sec	Disassociation detected
Wed Jul 26 13:44:53 UTC 2023	IT_OfficeW-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	40 min 9 sec	Disassociation detected
Wed Jul 26 14:25:03 UTC 2023	ITOffice-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	1 min 40 sec	Disassociation detected
Wed Jul 26 14:26:43 UTC 2023	IT_OfficeW-AP	802.11a/b/g/n	IO	802.11n(2.4GHz)	29 min 19 sec	Disassociation detected

[marce1000]

 - Client roaming decisions are independent forcing to stay on a particular band may lead to coverage issues and or has a wireless site survey be done for the particular places too ? Besides the mentioned procedure concerning WirelessAnalyzer (don't forget to run it) you can also do client debugging on the 9800 platform according to : 
                                          https://logadvisor.cisco.com/logadvisor/wireless/9800/9800ClientConnectivity

 You can have client debugs analyzed with : https://cway.cisco.com/tools/WirelessDebugAnalyzer/
 

  M.

[JPavonM]

Yes there is the possibility to disable both phys VHT and HE on the dot11 networks from the WLCs thus supporting only HT as maximum (WiFi4 or 802.11n). this will prevent clients from negotiating new assocaitions with different standards and parameters.

In addition to the previous one, I would recommend you to avoid from broadcasting a production SSID (and maybe critical) in both bands, as roaming decitions that are always on the client side could make it to connect to either band. As the device is constantly scanning the medium for better connections (based on vendor's logic) this could drive to disconnections when selecting differnt bands, specially noted on real-time applications and remote connections.

To avoid from having coverage holes on a specific band, it would be useful to conduc a passive/active survey to identify them, if any, and if there is no one, disable the band (I would recommend to disable 2.4GHz band as CCI is higher on it).

By the way, don't ever use band-steering if dropping connections is critical for you.

[Rich R]

You didn't mention what version of software you're using on 9800 - make sure it's up to date as per TAC recommended link below.

[tvancamp6]

Hello Rich,

We're running 8.5.164.0 on the 5520 and 17.3.6 (which was recommended version at the time, but I see it has changed to .7) on the 9800

[Rich R]

Hmmm 8.5.164.0 is not an IRCM release so IRCM is not supported on that! It would have to be 8.5.164.216 to support IRCM.

But really you should have upgraded to the latest for best interoperability with 9800 - currently 8.5.182.108 (link below).

I'm not a fan of 17.3 release but at least 17.3.6 isn't too out of date but I'd highly recommend looking at 17.9.3 (soon 17.9.4) as the TAC recommended doc says next to 17.3: "Cisco recommends 17.3.7 as minimum code and for customers looking to adopt WiFi-6E technology, new hardware or features beyond 17.3, Cisco recommends 17.9.3 CCO image." because 17.3 has already reached end of software maintenance meaning no more bug fixes.

[tvancamp6]

Thanks Rich for the insight. 8.5.164.0 is IRCM and supports secure mobility. We have several controllers running this version with successful mobility peering to 9800's. As most of our controllers are in a manufacturing environment, it can be tough to get the downtime to upgrade and we started the 8.5.164.0 upgrades shortly after IRCM was released. As these controllers are in the process of being replaced, we just needed to support roaming until the migration to 9800 is complete. We have a decent number of model 2700/3700 APs in the environment which were not supported on versions 17.4.1 - 17.9.2. I didn't know that they reintroduced support for 17.9.3 so we will investigate pursuing that as an option...our only other issue making upgrades difficult is Prime (probably just opened myself up for a lecture about moving to DNA center

[Rich R]

I understand that IRCM *might* work (some of the time) on 8.5.164.0 but it is not (and has never been) supported for IRCM with 9800.  You may not have realised it, but each 8.5 release had a parallel release purely for 9800 IRCM support and IRCM is only supported on that IRCM build.  In your defence the release notes don't make that completely clear
https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn85mr6_ircm.html but it's clear from the resolved caveats that the IRCM/mobility fixes went into 8.5.164.216 not 8.5.164.0:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn85mr6_ircm.html#resolved-caveats

https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#toc-hId--805306453
"The 8.5 Mainline branch supports 5508/8510/5520/8540/3504/2504/7510/WiSM2/vWLC controllers.  It supports intercontroller mobility (IRCM) between AireOS and old "New Mobility" ("Converged Access") controllers (5760/3850/3650.)  It does not support IRCM with 9800 controllers."
"The 8.5 IRCM branch supports only 5508/8510/5520/8540/3504 controllers.  It supports IRCM between AireOS and 9800 controllers"

So at this point you probably don't care - best to get the migration finished but what you've done there is not a Cisco supported configuration so no surprise at all that it doesn't work properly with 9800.

As for Prime - we've binned it completely (turned the servers off recently) as total operating cost far exceeded the value we got from it, and no DNAC. So I will not be the one to lecture you on that lol