03-21-2014 03:11 AM
I have been running tests on Central to discover how it recognises IAPs, and the actions that it takes - all IAPs have been added to Central manually, and I am using an ACL on a switch to allow or deny IAP access to the Central site, thereby simulating a loss of connection to Central and allowing the IAPs to be managed locally via the VC GUI.
Step 1. With the ACL denying IAP access to Central:
I modify a configuration on an IAP via the VC GUI (including adding new networks, deleting the existing network that is configured in the IAP's group in Central, changing the IAP and VC names, chaging the VC IP address, and setting a static IAP IP address instead of the DHCP configuration in the IAP's Central group).
Step 2. Remove the ACL to allow IAP access to Central.
The IAP connects to Central, is placed automatically in the group in which it was previously, and the configurations added through the VC GUI are overwritten by the group configuration in Central.
This is what I would expect, except that VC name and IP address are not overwritten by the group configuration in Central - why is this?
Perform steps 1 and 2, but instead of modifying the configuration, I have reset the IAP to factory default.
When the ACL is removed, the IAP successfully connects to Central, displays the IP address that I would expect it to have, but it is placed in the "default" group. Why is this?
I assumed following the tests that IAPs had to be recognised in Central by their MAC address, but this is clearly not the case, otherwise the IAP in step 3 would have been placed into the Central group in which it was previously configured.
Can anyone clarify the mechanisms by which Central recognises an IAP in order to place it into the group in which it was previously configured, and why it is not placed into it's Central group if it has been reset to factory defaults.
Solved! Go to Solution.
03-21-2014 04:37 PM
Johnny - the short and direct answer to your question as to why we are not placing the IAP in the pre configured group in Step 3 is because, today we use something called a VC GUID to tie a device to a group. When you factory default an IAP, the GUID gets reset hence we take the device back to the default group.
Due to the nature of the IAP architecture, we need to tie an IAP to the virtual controller before we can tie it to a group in central. When you are factory resetting a device we are assuming that you want to start from scratch and hence placing it in the default group. if you want to re-apply the config you simply have to move the AP back to the pre-configured group.