The process begins with the discovery of a controller. Because the lightweight APs are by definition “zero-touch” when deployed, you should only need to plug them in and let them do the rest. On the back end, the part you do not see is a little more complex. The steps in this process, beginning with discovery, are as follows:
Step 1. The APs send LWAPP discovery request messages to WLCs. This is broadcast at Layer 2. Because Layer 3 mode is what you want to use, this should fail.
Step 2. Upon failing, the AP proceeds to Layer 3 by checking its configuration for an IP address. If no IP address exists, the client uses DHCP to obtain one.
Step 3. The AP uses information obtained in the DHCP response to contact a con- troller.
Step 4. Any WLC receiving the LWAPP discovery request message responds with an LWAPP discovery response message. If no controller responds, the AP reverts to Layer 2 broadcasts and starts the process again.
The Cisco implementation uses the hunting process and discovery algorithm to find as many controllers as possible. The AP builds a list of WLCs using the search and discovery process, and then it selects a controller to join from the list. The controller search process repeats continuously until at least one WLC is found and joined. IOS-based APs only do a Layer 3 discovery.
The Layer 3 discovery process follows a certain order:
Step 1. The AP does a subnet broadcast to see if a controller is operating in Layer 3 mode on the local subnet.
Step 2. The AP does an over-the-air provisioning (OTAP).
Step 3. When other APs exist and are in a joined state with a controller, they send messages that are used for resource management. These messages have the IP address of the controller in it. The AP can listen to these messages and get the controller IP address. The AP can then send a directed discovery message to the controller.
Step 4. The next process is called AP priming.
How an LWAPP AP Chooses a Controller and Joins It
Now that the AP potentially has numerous controllers to join, it must choose one and send it a join request message. Figure 11-3 illustrates this portion of communication.
A join request message contains the following information:
- Type of controller
- MAC of controller
- AP hardware version
- AP software version
- AP name
- Number and type of radios
- Certificate payload (x.509)
- Session payload to set up the session values
- Test payload to see if jumbo frames can be used
How an LWAPP AP Receives Its Configuration
After joining, the AP moves to an image data phase, as shown in Figure 11-6, but only if the image on the AP is not the same as the image on the controller. If they are the same, this step is skipped and the image is used.
The controller upgrades or downgrades the AP at this point, and then it resets the AP. Af- ter a reset, the process begins again. The code is downloaded in LWAPP messages.
After the process of discovery and join happen and the image is the same on the controller and the AP, the AP gets its configuration from the controller. This happens during the con- fig data stage, as illustrated in Figure 11-7.
The AP then prompts the controller for a config by sending an LWAPP configure request message that contains parameters that can be configured as well as any values that are currently set; however, most of these values are empty.
When the controller gets the request, it sends a configure response message, which has the configuration values.
The AP then applies the configuration values in RAM. It is important to understand that these values are not stored in flash. If the AP reboots, the process begins again.
After applying the configuration, the AP is up and running.
No comments:
Post a Comment