C9800 upgrade 17.9.6 to 17.12.4 wave 1 AP issue

[pengus]

After upgrading the C9800-80 WLC from version 17.9.6 to 17.12.4, access points of models 1700, 2700, and 3700 reverted to their default configuration, including hostname and tags. What could have caused this behavior?

[Leo Laohoo]

I have about 4k x 3700 and I've never seen a behaviour like this.

How are the tags applied to the APs, are they statically assigned tags or filter?

[pengus]

Yes i use AP Filter for tagging with hostname. Cause of this tag configuration, changing AP name to default APXXXX... 

[Leo Laohoo]

If this WiFi network has Cheetah OS-based APs (non-2700/3700/1540), I'd recommend moving off 17.12.4 and go to 17.12.5 because CSCwm08044, CSCwm72142, CSCwe97901, CSCwm07499, CSCwo05017, CSCwo61838 is guaranteed to hit after 140 days of AP uptime.

[marce1000]

  -  You say you upgraded to 17.12.4 can you confirm that with the show version command
                     (to get the current version in case mistakes where made)
      Check this document : https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/222431-upgrade-the-catalyst-9800-wlc-quick-st.html
     For instance don't forget to the install commit command when finishing the upgrade

   - Issue the CLI command : wireless config validate 

   - Verify and analyze the current configuration of the C9800 using the CLI command :
      show tech wireless and feed the output from that into Wireless Config Analyzer
            Use the full command denoted in green, do not use  a simple show tech-support for this procedure.

  M.

[Saikat Nandy]

Since you have specifically mentioned about 1700,2700 & 3700 series AP, does that mean other APs successfully kept the configuration post upgrade? As @Leo Laohoo pointed, please have a look into the AP filter config. That could be the source of this issue. Also I feel the issue might get reproduced, if you just reload an AP (since upgrade is reloading the AP too). So you can try this and see if that gives you any clue about the config.

[Rich R]

> Cause of this tag configuration, changing AP name to default APXXXX
So the actual root cause of the problem here was that the APs lost their hostnames and reverted to their default hostname (based on MAC address).

I've never seen or heard of that happening before.  My best guess would be that there was something about those names which caused them to be rejected and replaced with the defaults.  The change in tags was just a side-effect result of the name change.  I'd expect to see something in the AP or WLC logs which would explain why the names were rejected.
How long were the AP names (they should not be longer than 31 characters, ASCII only), did they contain any special characters?

[pengus]

Approximately 100 model 1702 access points experienced this issue, and there was no hostname conflict that could have caused a problem. In fact, the reason I opened this post was to see if others had experienced the same thing—so I could determine whether it was a bug or a mistake I made during the upgrade process. Since no one else reported the same issue, I now believe it was due to an error on my part.

[Rich R]

I personally doubt that, unless you accidentally initiated a factory default reset on those APs.

But without seeing the logs from the WLC and an affected AP, it's impossible to say.

We log everything we do so that if something does go wrong we can look back through the logs and see what might have been mis-typed or done in the wrong order etc.  If you have logs of what you did then review those carefully.  If you don't, then this might be a good time to turn on terminal logging for future.  You never know when you might want to look back at exactly what you did.  Of course if you did it all on the GUI then your options are limited to what the WLC and APs themselves logged, which can still sometimes tell you something useful.  That's another reason I prefer to do everything I can on CLI.  Even the old IOS APs keep some basic logs after a restart so there might be something useful there if they haven't been reloaded again since then (the log gets replaced each time).  Look for event.log on the AP flash.  The COS APs have more comprehensive persistent logging now.