New versions, in particular 5. Cisco Systems, Inc. This new approach to the wireless networks was designed to have nodes or points of presence throughout a network. These node devices would not require configuration and would rely on a master device for their configurations and instructions. These nodes would exist to provide a point in the network to which a wireless user can connect.
After a user connects, all traffic going to this node would be sent to the master device. This approach offers many advantages over the single device configuration setup but requires a protocol to provide constant connectivity and direction for these devices to operate. LWAPP provides the solution. APs can be networked together in a variety of architectures.
The size and scalability of the network determine which architecture is most suited for a given implementation. Figure Autonomous APs. Cloud-based AP management is an alternative to purchasing a management platform. The AP management function is pushed into the Internet cloud. These APs can then be managed from the Meraki cloud web interface dashboard. In Figure , the same APs shown in Figure are now managed in the cloud.
Notice that there are two distinct paths for data traffic and for management traffic, corresponding to the following two functions:. A control plane: Traffic used to control, configure, manage, and monitor the AP itself. LAPs are useful in situations where many APs are required in the network. Notice in Figure that the WLC has four ports connected to the switching infrastructure.
These four ports are configured as a link aggregation group LAG so they can be bundled together. These functions must stay with the LAP hardware, closest to the clients. The management functions are not integral to handling frames but are things that should be centrally administered. Therefore, those functions can be moved to a centrally located platform away from the AP.
CAPWAP uses two tunnels—one for control and one for data—as shown in Figure and described in the list that follows:. The control messages are authenticated and encrypted, so the LAP is securely controlled by only the appropriate WLC and then transported over the control tunnel using UDP port Data packets are transported over the data tunnel using UDP port but are not encrypted by default.
I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.
Pearson Education, Inc. This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site.
Please note that other Pearson websites and online products and services have their own separate privacy policies. To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:. For inquiries and questions, we collect the inquiry or question, together with name, contact details email address, phone number and mailing address and any other additional information voluntarily submitted to us through a Contact Us form or an email.
Often refered to as remote antennas, Thin APs lower price allow for a more thorough wireless coverage at a given price point, and are attractive offerings for large deployments. Non-realtime capabilities are authentication procedures, fragmenting and defragmenting frames, and more. Fit APs are a combination of the Thin and Thick metaphors. Fit APs still rely on the controller for configuration and some frame processing. It is important to realize that the definition of what a controller is is not clearly defined.
It usually falls to the vendor to create a specific implementation. Many vendors use this to their advantage, and create product differentiation by including features into their wireless products, such as firewall capability in their controller hardware. CAPWAP only seeks to relay what a device is and is not capable of, in order to classify and provision the device into operation.
It was initially designed by Airespace, which was later bought out by Cisco in Discovery - New APs must seek out a controller with which to associate.
This is accomplished by the AP broadcasting a Discovery Request. A controller must respond with a Discovery Response. The AP then joins to a controller, and is acknowledged by the controller. Image Download - The newly joined AP then may request a firmware update, upon seeing the controller advertise a higher version of code. The AP then downloads the firmware, and once completed, enters the Reset state, and then attempts to rejoin a controller.
Configure - An AP with a sufficient version of code may then request to be configured by the controller. The AP sends the controller its current configuration, and the controller responds with an updated configuration. Once the AP has received the configuration, it may enter the Run state. Run - Both the controller and AP operate in the Run state. The AP forwards packets to the controller, and maintains normal operation. From the Run state, an AP and controller may exchange new key material, by entering the Key Update state.
This state updates the encryption keys on both devices, which is used to encrypt all further messages, until a new key is requested. However, the header does not warrant any particular attention, and as such, will not be covered by this paper. A full specification is preserved in [RFC]. LWAPP defines certain operation modes for compliant hardware. The controller has a fixed set of The only duties that the controller is responsible for under this scheme is wireless key management and authentication proxying.
The AP handles the encryption of traffic between itself and its clients, with the controller provided keys. Communication between a controller and AP must be encrypted, as all data sent to and received by the AP will be tunneled over the local LAN to or from the controller. It claims that the physical security of the LAN prevents most attackers from accessing the stream between controller and AP, but does not guarantee against traffic sniffing beyond the scope of LWAPP, and suggests that in the requirement of full end to end encryption, IPsec be used.
The controller and AP will exchange 2 types of messages: control messages, and data messages. The proposal cites the availability of IPsec for general data traffic, and does not provide any mechanism of encrypting data messages between the controller and AP, only control messages, and the key exchange process between both devices. However, some control messages are transmitted unencrypted, such as Discovery Requests and Responses, because of the lack a preexisting association between the 2 devices.
The wireless key exchange is handled in a fully encrypted fashion, by utilizing preshared keys PSKs , or a security certificate model. Vendors such as Trapeze criticized the specification, as it makes assumptions about the topology of the network that the WLAN will be deployed on, as well as assumptions about the complexity and functionality implemented by the AP, by allowing only Local and Split MAC implementations.
It was seen as overly complex, as well as lacking in security, as portions of the control stream are unencrypted, and the entire data stream between controller and AP are unencrypted.
SLAPP was designed as a simple, extensible protocol that could be extended to other wireless standards, and allow for newer authentication schemes and control protocols to be implemented on top of SLAPP.
Rather, it attempts to provide the framework with which devices may request a specific configuration method, which is then layered on top of SLAPP. SLAPP operates as the framework to make a connection between two devices, and negotiate a protocol.
In [fig6] , the same SLAPP protocol would be used by an AP to decide how to download updated firmware, as would be used to determine a protocol to communicate with the controller. The state machine in [fig6] show the 4 states attainable during protocol negotiation by a device. Discovery - Discovery is the initial broadcast from an AP, informing controllers that they are interested in communicating in a specific protocol.
The controller awaits a Discovery Request from an AP. The autonomous version can be later upgraded for lightweight operation. The AG possesses external connections for antennas in both bands. For greatest flexibility, the autonomous version can be upgraded later to lightweight mode of operation. It comes with an integrated antenna or can be ordered with RP-TNC connectors to support external antenna applications. APs in this category consist of the original Airespace product line, but also include select autonomous AP models above.
The following lightweight models can be used only in WLC topologies:. The comes with dual internal sector antennas. Table and Table provide a comparison summary of the APs discussed above. YES 1. Within the Cisco Unified Wireless Architecture, the following are three important concepts in grouping devices:. This section describes their purpose in the Cisco Unified Wireless Architecture. For more details on operation and configuration these groups, see the following URLs:.
The WLC is able to make decisions based on the data from the entire mobility group domain rather than simply from its own connected APs and clients. Creating mobility groups is simple and well documented, but there are the following important considerations:.
The primary purpose of a mobility group is the creation of a virtual WLAN domain between multiple WLCs, providing a comprehensive wireless view for client roaming. The creation of a mobility group makes sense only when there is overlapping wireless coverage between APs connected to different WLCs.
For example, there is nothing to be gained in having campus and branch WLCs in the same mobility group. Mobility group members of a mobility anchor do not have to have a mobility group connection between each other, but must be in the mobility list of the anchor controller. Consider a deployment scenario, where you have a WLC supporting the maximum number of APs Now consider a scenario with 25 users associated to each AP.
In the default configuration, you have users on the same VLAN. However, there can be broadcast- or multicast-intensive applications running on the wireless LAN end clients, and this leads to a need to break up the number of clients on a single subnet. Also, you may want to distribute the end client load across multiple interfaces in the infrastructure.
Note AP groups do not allow multicast roaming across group boundaries; this is discussed in more detail later in this design guide. RF groups, also known as RF domains, are another critical deployment concept.
An RF group exists for each RF RRM is discussed in more detail in a later chapter of this document, but can be summarized as follows:. APs sharing the same secret are able to validate messages from each other via the MIC.
The end result is dynamically calculated, near-optimal power and channel planning that is responsive to an always changing RF environment. Between update intervals, the RF group leader sends keepalive messages to each of the RF group members and collects real-time RF data. Roaming in an enterprise Depending on the network features and configuration, a lot may occur between the clients, WLCs, and upstream hops in the network, but at the most basic level, it is simply a change of association.
0コメント