Confirm DNAC resets radios during WLC Provision

[t-roy]

After an upgrading our standby 9800 to 17.9.4a our DNAC integration appears happy, but when we provision from the UI we get the above warning.  I haven't kicked any APs over to the standby pair yet to verify, but has anyone else seen this actually reset the radios in real world operation?  Not sure why Cisco would make this change, not being able to deploy APs during business hours is a real step backwards.

[Haydn Andrews · Accepted solution]

I can confirm that it only resets the radios if you are pushing config that would normally cause a radio reset like:

Adding SSID to Wireless Profile

Changing the Wireless Profile for a site

Etc

I did question this with the BU, it appears that they went with a blanket everything causes a radio reset, rather than doing what a WLC has done for years and only flag if it was going to cause impact.

This from running 17.9.3 in an enviroment where a radio reset to all APs would have people screaming

[t-roy]

Thanks!  I'm failing over one site today so I can confirm as well.  If it's only a potential disruption if the config elements require a radio reset, it's frustrating they wouldn't word it as such.

[t-roy]

In my testing I was also able to confirm that if we're not making changes to a wireless profile, or editing the profile assigned to a site, although we received the message:

Provisioning a Controller upgraded to version 17.7 or higher with WPA2+WPA3/WPA3 Enterprise WLANs, will cause the WLANs to momentarily be disabled and radio reset, which may result in loss of connectivity for some clients.
To avoid disruption, Provisioning can be scheduled at a later time.

This wasn't the case, not a single ping packet from a client attached to an AP managed by the WLC was dropped during the provision.