cancel
Showing results for 
Search instead for 
Did you mean: 

AP pulling original configs in or out of the staging zone

kristphr
New Contributor III

Hello,

I have something weird going on, but I'm trying to figure out how to fix this issue. I have an AP with FW: 6.0.0.0.1594, and I reset its configurations via the physical AP & via the vSZ-E (FW: 6.0.0.0.1331). The issue I'm encountering is - once those configs are reset (AP), it connects back to the vSZ, however instead of having default configs (Staging Zone), it goes back to the original config (AP Zone) that it was initially placed in. 

To my knowledge, any new AP that gets connected to the vSZ is placed in a staging zone (no config) until it's moved to a proper zone with the appropriate parameters set for that zone. However in this case, it continually gets those initial configs post-reset. Any idea what it is that I'm doing wrong?

I have 2 zones set, along with 2 AP's - an H510, and an R550. The H510 is set in its respective zone, and even when I place the R550 back in the "staging zone" it still acts as if it has the H510's parameters. This worked in the initial install (when everything was freshly set up), and I was able to test the functionality of both the vSZ & the remote AP's. But now it's acting weird. 

Random thoughts:

  1. The AP's firmware is higher than the AP controller's firmware - could that be an issue? 
  2. This is still a testing environment (no valid RTU license on the server other than the default licenses - but it still worked when I originally set everything up)

any ideas? Thanks for the help!

3 REPLIES 3

Vineet_nejwala
Moderator
Moderator

@kristphr 

Two things to check :

1) Go to Network > Wireless > AP Settings > AP Registration and validate if any rule configured ?

2) Though this shouldn't be an issue, can you make sure to delete this AP entry if still on that old zone ?

Best Regards

Vineet

@vineet_nejawala this is weird.

I did a restart on the cluster and it solved this issue. I had applied a patch for log4j earlier (but forgot to restart cluster for it to take effect)

But I believe it probably just needed a restart. 

@kristphr

Glad this has been sorted now.

Best Regards

vineet