I am currently setting up a 4402 controller and lwapps. Our wireless right now is all managed by corp and is a combination of autonomous and lwapp. Here is my problem.
I have setup option43 in my dhcp scope. When I connect a fresh radio to the same subnet as the controller I see that the radio goes to the controller but then there is a message and the radio goes to the corp controller.
Here is the boot log from a new radio.
%LWAPP-3-CLIENTEVENTLOG: Controller address 10.200.190.10(MINE) obtained through DHCP
%LWAPP-3-CLIENTEVENTLOG: Did not get log server settings from DHCP.
%LWAPP-3-CLIENTEVENTLOG: Performing DNS resolution for CISCO-LWAPP-CONTROLLER.gtna.gt.ds
%LWAPP-3-CLIENTEVENTLOG: Controller address 10.148.198.7(CORP) obtained through DNS
I see that message about a log server. Did I miss something?
So the real question here, is which discovery method has priority? If DHCP gives it an address, but the controller is able to resolve the DNS discovery address, which controller will the AP go to?
Because your AP is getting told about both servers. If it isn't registering to your controller, than I'm thinking DNS must have priority?
How the heck is that incorrect information?
The log says it pulled the controller address from DHCP and then it shows it resolved through DNS the other controller address.
So, which takes priority. If it shows both were found, then which will it register with?
Note: as you answered below, appearently DHCP takes priority. So that answers my question
Actually, I was about to edit my message, as it is actually not even DNS or DHCP taking priority. I will explain in the original reply to keep the post clean.
According to the documentation is should join the DHCP received address, unless the list of controllers that is build upon startup contains a master controller.
The list of controllers build upon startup is build using DHCP discovery, DNS resolving, L3 broadcast and over the air provisioning, plus previous stored info in NVRAM (if any).
I would bet your CORP controller is set as master controller, and then the behavior you are seeing is suppose to happen ;-)
Hope this helps,
Mmm, and after reading the documentation again, I have to admit it is even different. Still the same conclusion though.
As I listed out in the other reply, the LAP builds a list of controllers based on L2 and L3 discovery mechanisms.
Then, after building the list is checks the built list with previous info stored in NVRAM and checks for a match to primary, secondary and tertiary controller. If one of these match (in priority order) the LAP will join that controller.
If there is no match, or that join fails, it will check if one of the controllers is set as master controller. If so, it will try to join that master controller.
If that step fails as well, the LAP will select one of the remaining controllers in the list, and the selction criteria in this step is the controller with the greates excess capacity.
See this doc for reference.
Still brings me to the same initial conclusion that the CORP controller is probably set as master controller.
Hope this helps,
I just thought that I would link this info for the LWAPP Layer 3 startup. +5 points for both Wesley and Leo for your ongoing great work here :)
The LWAPP AP goes through this process on startup for Layer 3 mode:
The LAP boots and DHCPs an IP address if it was not previously assigned a static IP address.
The LAP sends discovery requests to controllers through the various discovery algorithms and builds a controller list. Essentially, the LAP learns as many management interface addresses for the controller list as possible via:
DHCP option 43 (good for global companies where offices and controllers are on different continents)
DNS entry for âcisco-lwapp-controllerâ (good for local businesses - can also be used to find where brand new APs join)
Management IP addresses of controllers the LAP remembers previously
A Layer 3 broadcast on the subnet
Over the air provisioning
Statically configured information
From this list, the easiest method to use for deployment is to have the LAPs on the same subnet as the management interface of the controller and allow the LAP's Layer 3 broadcast to find the controller. This method should be used for companies that have a small network and do not own a local DNS server.
The next easiest method of deployment is to use a DNS entry with DHCP. You can have multiple entries of the same DNS name. This allows the LAP to discover multiple controllers. This method should be used by companies that have all of their controllers in a single location and own a local DNS server. Or, if the company has multiple DNS suffixes and the controllers are segregated by suffix.
DHCP option 43 is used by large companies to localize the information via the DHCP. This method is used by large enterprises that have a single DNS suffix. For example, Cisco owns buildings in Europe, Australia, and the United States. In order to ensure that the LAPs only join controllers locally, Cisco cannot use a DNS entry and must use DHCP option 43 information to tell the LAPs what the management IP address of their local controller is.
Finally, static configuration is used for a network that does not have a DHCP server.You can statically configure the information necessary to join a controller via the console port and the AP's CLI. For information on how to statically configure controller information using the AP CLI, refer to Manually Configuring Controller Information Using the Access Point CLI.
For a detailed explanation on the different discovery algorithms that LAPs use to find controllers, refer to LAP Registration with WLC.
For information on configuring DHCP option 43 on a DHCP server, refer to DHCP OPTION 43 for Lightweight Cisco Aironet Access Points Configuration Example.
Send a discovery request to every controller on the list and wait for the controller's discovery reply which contains the system name, AP-manager IP addresses, the number of APs already attached to each AP-manager interface, and overall excess capacity for the controller.
Look at the controller list and send a join request to a controller in this order (only if the AP received a discovery reply from it):
Primary Controller system name (previously configured on LAP)
Secondary Controller system name (previously configured on LAP)
Tertiary Controller system name (previously configured on LAP)
Master controller (if the LAP has not been previously configured with any Primary, Secondary, or Tertiary controller names. Used to always know which controller brand new LAPs join)
....continued on next page
.....from previous page.
If none of the above are seen, load balance across controllers using the excess capacity value in the discovery response.
If two controllers have the same excess capacity, then send the join request to the first controller that responded to the discovery request with a discovery response. If a single controller has multiple AP-managers on multiple interfaces, choose the AP-manager interface with the least number of APs.
The controller will respond to all discovery requests without checking certificates or AP credentials. However, join requests must have a valid certificate in order to get a join response from the controller. If the LAP does not receive a join response from its choice, the LAP will try the next controller in the list unless the controller is a configured controller (Primary/Secondary/Tertiary).
When it receives the join reply, the AP checks to make sure it has the same image as that of the controller. If not, the AP downloads the image from the controller and reboots to load the new image and starts the process all over again from step 1.
If it has the same software image, it asks for the configuration from the controller and moves into the registered state on the controller.
After you download the configuration, the AP might reload again to apply the new configuration. Therefore, an extra reload can occur and is a normal behavior.
Hope this helps!
Always good to see you reply ;-)
Yep, that's exactly the same info as the doc I found and the link I posted.
The OTP always make me think out loud, how on earth does that work? I have never been able to find good info on that one.
Any guidance about the OTP?
OMG, this is getting better and better. Last friday we had a wireless specialist (sales engineer) in from Cisco. He stated that this document is outdated and all changed with version 5.2 when changing from LWAPP to CAPWAP.
He states that DHCP is in the lead, as soon as it is configured. I told him the behavior I see is different then that statement and asked him to provide the supporting documents for his statement.