- [Narrator] We now will look at how
Cisco Lightweight Access Points operate
with a wireless LAN controller.
Specifically, we want to look at the different states
that they progress through during the discovery process
and what the discovery process looks like.
Cisco designs their Lightweight Access Points to be
a touch free deployment.
That is to say there's no need for any configuration
to take place on the access point itself.
As long as the switch port where the access point connects
into the network is configured with the correct POE settings
and VLAN assignment,
there's really nothing you need to do
other than plug in the access point.
It's important to understand what happens
once that's plugged in and how the access point progresses
through each state of discovery.
We'll examine the most common sequence of states here,
which includes eight different states steps in the sequence.
First is the boot state.
A Cisco Lightweight Access Point will have a small IOS image
that begins the entire process.
This is the point where the access point
would receive an IP address
either through DHCP or from a static address assignment.
Next is the WLC discovery state.
This is where the access point is actively looking for
a wireless LAN controller to which it can be joined.
The access point will send out
CAPWAP Discovery Request messages in a number of ways.
Those could be broadcast messages over port UDP 5246
or those could be specifically sent to
known controller IP addresses if it is aware of any.
Third is the CAPWAP tunnel request state
recall from previous videos that CAPWAP tunnels
are established between each access point and the controller
in order to carry management and user data
between the devices through a secured tunnel.
This tunnel is established once the devices authenticate
one another by exchanging their digital certificates.
Next is the WLC join state.
Once an acceptable controller is seen by the access point,
a series of CAPWAP messages will be exchange.
Those are join request and join response messages
exchanged over the CAPWAP tunnel.
This completes the attempt by the access point
to join itself to the wireless LAN controller.
After this happens, the access point has
a secured communication channel with the controller
so it moves on to the image download state.
The access point will compare its own software image version
to that of the one found on the wireless LAN controller
and if needed, that is if the releases do not match
the access point will download the appropriate image update
via the wireless LAN controller.
The access point will apply the image
and if an update was performed,
it will reboot to complete that process
and it will start again at the beginning of this process
back at the boot state.
In order to reestablish communication with the controller.
This software image release
is something that you cannot control by the way.
You can't choose which release to use on the access point,
the wireless LAN controller itself that is being joined too.
That's going to determine the release version that's needed
based on its own software.
If everything matches and everything is compatible,
no download will take place and the access point,
will move on to the download config state.
During this state, the access point will pull
the wireless LAN controller for configuration information.
That would be things such as the security parameters,
QoS considerations, the SSIID, and much more.
Once all of the necessary configuration items are in place,
the access point is operational
and moves into the run state.
The access point will now be providing a basic service set
and allowing users to join the wireless network.
The final state is the reset state.
If a reset is pushed out to the access point
from the wireless LAN controller,
then the access point will tear down
any existing CAPWAP tunnels
and erase existing client associations.
The access point will move back to the first state again,
the boot state and start this entire process over.
Now let's zoom in on a couple of these states closer,
particularly the process where the controllers
are discovered and then how the access point selects
a specific wireless LAN controller.
Because there could be an environment where there
are multiple wireless LAN controllers.
First, as we mentioned, the discovery process happens
via CAPWAP now when the access point is going through
the discovery process,
the goal is to find as many controllers as possible
and to build a list of those controllers.
So it doesn't just stop as the...
first controller that it finds.
The access point wants to know about everything.
So first the access point would send out
a CAPWAP Discovery Request message as a broadcast message
on the local subnet to which it is connected.
Any controllers that are found on the local subnet,
those would respond with a CAPWAP Discovery response
back to the access point.
Next, the access point would use any locally stored
controller addresses which are known about.
So if this was a previously deployed access point
that has maybe been relocated or maybe simply rebooted,
it will already have a list of known
wireless LAN controllers stored in the non-volatile RAM.
The access point will attempt to communicate over
UDP port 5246 to as many of these as possible
to continue to build the list
of wireless LAN controller candidates.
Next Discovery Process can happen via DHCP.
If you're using a DHCP server and you've configured
DHCP Option 43 with your wireless controllers IP address
or addresses if you have multiple controllers,
that can be pushed out to the access point
by the DHCP server using DHCP Option 43.
And the fourth step in discovery is through DNS.
The access point will attempt to resolve the domain name,
CISCO-CAPWAP-CONTROLLER.localdomain
and the .localdomain that's going to be replaced with the
actual domain name that is learned from DHCP communication.
If the name resolves to an IP address,
then this address will be added to that discovery list.
If all of this fails to find a wireless LAN controller
anywhere on the network, the access point will reset itself
and restart the discovery process all over again.
Once the discovery is completed,
the access point will have a list
of potential controller candidates
and after that it will take this list
and it will move to the selection state.
The selection state consists of three separate steps.
First being the attempt to join
a previously known controller.
If an access point has already been joined to
a wireless LAN controller before
and the wireless LAN controller appears on the network,
this is the first preference.
If that fails or if the access point is brand new
and has never been in the network at all.
The next step is to look for a master controller.
This is only relevant in an environment where there are
multiple wireless LAN controllers.
So if you do have multiple controllers,
you should configure one of those as the master controller
so they can respond to the access point messages
that are sent out as a broadcast on the local subnet.
Finally, the third step
is to join the least-loaded controller.
So in other words, if we see multiple controllers
and if none of those are a master controller,
if all these are new to us,
the controller with the least amount of access points
already associated is going to be chosen.
This is a built in attempt to load balance our network.
Once the access point finds an acceptable controller
through these three steps.
A determination is made
and the access point will be joined
to the wireless LAN controller.
So that's a look at how a Lightweight Access Point
discovers and joins itself to a centralized
wireless LAN controller.