06-13-2016 12:16 PM
We are setting up a new site with brand new 7205 controllers and AP-225's. I configured basic connectivity on our controllers, but we are waiting on licenses before we can activate any AP's.
While waiting I wanted to verify the ap's would boot properly, and enabled the switch ports they connect to. Suddenly the AP's are broadcasting the SSID's of our other office from 3400 controllers. I logged onto that set of controllers and found the new AP's had registered to them instead of the new 7205's.
I am wondering why this may be, and how we can hard code the controller ip into the new AP's so that they will not try to register to any other site's controllers. Any documentation I can review would be helpful.
My best guess is that since we have no licenses on the new controllers, the AP's defaulted to broadcasting to anyone else in the network who may have some, and registered to the old ones since we still had a couple AP licenses left on it.
Solved! Go to Solution.
06-13-2016 12:38 PM
AP can discover master controller with few conditions met. In this scnario, AP would have discovered the master controller through ADP or any other method to go and terminate on other site where your 3400 controller resides since you dont have licenses as well on this. You could either set the static or dns or DHCP options to terminate the AP on the new controller 7205 or simply re-provision the AP but we need to make sure licenses are present.
Below link would give info about AP finding master controller.
show log system all | include <ap-name or mac address of the AP> will give the info why the AP was unable to terminate on 7205 say like "AP license not available rebooting" something like that.
06-13-2016 01:30 PM - edited 06-13-2016 01:35 PM
We have already set dhcp options 43 and 60 on our scope, and I have a helper address on the vlan they are on that points to the correct dhcp server ip. So I thought that would be enough to point the AP to only our new controller.
After looking into the logs, it looks like we're being blocked by control plane security:
Jun 13 04:43:19 :311020: <ERRS> |AP 40:e3:d6:c7:37:firstname.lastname@example.org sapd| An internal system error has occurred at file sapd_cfg.c function send_papi_message_to_ble_daemon line 1660 error Error when sending msg to bd.
Jun 13 04:43:19 :305049: <WARN> |stm| Unsecure AP "40:e3:d6:c7:37:46" (MAC 40:e3:d6:c7:37:46, IP 10.x.x.x) has been denied access because Control Plane Security is enabled and the AP is not approved.
Which can be fixed following the info here:
06-13-2016 05:00 PM
Oh great finding by running the command which indicates cert trust between AP and controller. By default it is enabled on controller. To fix this, we need to either disable the CPSEC which will bypass the certificate trust between AP and controller result in AP to come back online.
Else add the range of addresss for the controller to scan, evaluate and allow them to connect.
The advantage of CPSec enabling on the controller is to
1. Prevent any unathorized AP joining the network where the Network Administrator will have more control inside the network for any devices been connected.
2. All control plane traffic between AP and controller is encrypted.