Define the Customer Requirements
As part of defining the customer requirements, the following questions should be asked:
| 1. | What type and number of wireless devices need to be supported? Here are some considerations:
-
Is existing WLAN or RF equipment in place? Existing WLAN equipment will need to be integrated, and the impact of existing RF devices should be mitigated. -
Will the WLAN be used only for data, or will wireless phones also be supported? If wireless phones will be used, the wireless network needs to be built with better receive signal strength to support the required QoS. -
Are there peak periods to support? For example, use of wireless services in a conference room will peak during meetings.
|
| 2. | Will users be stationary or on the move while using the WLAN? If users are mobile, high-quality hand-offs during client roaming are required. |
| 3. | Where should wireless coverage be supported? How many buildings, floors, and areas should be supported? Are outdoor bridged links needed? |
| 4. | What level of support should be provided? What level of redundancy and self-healing is needed in the wireless infrastructure? |
The answers to these questions are important to defining the scope of the wireless infrastructure design.
Identify Coverage Areas and User Density
Part of the site survey report should include a floor plan showing coverage areas and areas that the customer has defined as no-coverage areas. A sample floor plan is shown in Figure 9-23. The floor plan provides the customer, installer, and troubleshooter with some indication of what coverage each AP should be providing. The expected density of the wireless devices, which might be one or two per office and 20 or more per conference room, should be identified.
The facility should be visually inspected to identify potential issues, such as metal racks, elevator shafts, stairwells, and microwave equipment.
Determine Preliminary AP Locations
The next step in the RF site survey process is to identify preliminary AP locations based on the planned coverage area and user density. This step can be supported with several tools. For example, you can import real floor plans and assign RF characteristics to building components in the Cisco WCS to increase design accuracy. WCS has a planning mode feature that estimates how many APs are needed for a given floor in a building, based on the floor plan; an example is provided in Figure 9-24. When predicting range and coverage, the planning mode feature takes into account the following:
| Note | Recall that, after implementation, the Cisco UWN can adjust power and channels so that APs create the least amount of interference with each other. |
The WCS can be used to estimate the quantity and preliminary locations of APs at the start of a site survey. This approach is most successful in simple carpeted office environments that are less RF-challenging than other environments, such as warehouses.
The Cisco WCS also provides an integrated RF prediction tool that can be used to visualize the detailed WLAN design, including lightweight AP placement, configuration, and performance/coverage estimates. Graphical heat maps, as illustrated in Figure 9-25, help IT staff visualize anticipated WLAN behavior for easier planning and faster rollout. A heat map diagrammatically represents signal strength—the warmer the color, the stronger the signal.
| Note | The accuracy of this heat map greatly depends on the effort spent adjusting RF loss characteristics of building components such as walls, solid doors, and stairways. |
Perform the Actual Survey
The next step in the process is to conduct the actual survey to determine the coverage based on the planned AP locations. The process to determine the coverage characteristics of an enterprise office site includes the following:
-
Measure the radius of the coverage area for a given data rate.
-
Move from the corner to the edge of the coverage area, and measure the data rate.
-
Determine the coverage range behind stairwells, offices, supply rooms, cubicles, and so on.
-
With as many APs as available, build the planned wireless coverage.
-
Establish nonoverlapping channels as often as possible to reduce contention.
-
Repeat this process until all the required coverage areas are set up.
A tool, such as AirMagnet Survey PRO, can be used to perform a manual site survey; results include the following:
-
Signal strength
-
Noise level
-
Signal-to-noise ratio
-
Channel interference
-
Data rate
-
Retry rate
-
Loss rate
| Note | AirMagnet Survey PRO information is available at http://www.airmagnet.com/. |
A free tool available for Cisco 802.11a/b/g client cards is the Cisco Aironet Site Survey Utility. The following information is provided by the tool:
-
AP IP and MAC address
-
Channel
-
Signal strength
-
Noise level
-
Signal-to-noise ratio
-
Link speed
| Note | Information about the Aironet Site Survey Utility is available at http://www.cisco.com/en/US/products/hw/wireless/ps4555/products_installation_and_configuration_guide_chapter09186a0080796b85.html. |
Coverage holes are areas where clients cannot receive a signal from the wireless network. When deploying a network, there is a trade-off between the cost of the initial network deployment and the percentage of coverage hole areas. A reasonable goal for launch is to have between 2 and 10 percent coverage holes; in other words, between two and ten test locations out of 100 random test locations might receive marginal service. After launch, RRM identifies these coverage areas and reports them to the WCS, allowing the network manager to correct the holes, based on user demand.
Document the Findings
After completing the site survey, the final step in the process is to document the findings. A proper site survey report provides detailed information that includes customer requirements, AP coverage, interference sources, equipment placement, power considerations, and wiring requirements. The site survey documentation serves as a guide for the wireless network design, and for the installation and verification of the wireless communication infrastructure. The site survey report should also contain a list of the parts that will be needed, including the following:
-
The total number of APs, and a recommendation that a spare be kept on hand in case of emergency
-
The total number and type of antennas required and how they will be mounted
-
Any proposed accessories and network components
The site survey report should include diagrams showing the facility, AP locations and coverage, and proposed cable runs. Covered areas, as well as those not needing coverage, should be indicated. Whenever possible, include photographs of the planned AP location or proposed antenna installation to make it very clear how and where the equipment should be installed. The tools and methods used for the site survey should be described.
If wireless voice support is required, the site survey methodology needs to be enhanced to plan for voice coverage and capacity. For example, wireless data is less susceptible to disruption than wireless voice when it comes to cell overlap, RF noise, and packet delay. Therefore, surveying for wireless voice coverage requires more effort and time than for data-only coverage at the same site.
| Note | Further discussion of site surveys to support voice over WLANs is available in Design Principles for Voice over WLAN at http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/networking_solutions_white_paper0900aecd804f1a46.shtml. |
Controller Redundancy Design
Recall that the AP discovery and join decision process first looks for a defined primary, secondary, or tertiary WLC (as specified by the controller’s sysName). An AP’s second choice is to join a WLC configured as a master controller. This is typically used only on initial AP deployment to find an initial controller, at which time the AP should be configured with its deterministic controllers.
The last choice in the AP join decision algorithm is to try to dynamically choose a WLC based on the greatest availability for AP associations. Using this process, WLCs can support either dynamic or deterministic redundancy.
Dynamic Controller Redundancy
The LWAPP protocol supports dynamic controller load balancing and redundancy. In the controller LWAPP Discovery Response, the WLC embeds information about its current AP load (defined as the number of APs joined to it at the time), its AP capacity, and the number of wireless clients connected to the controller.
With dynamic load balancing, an AP attempts to join the least-loaded controller, defined as the controller with the greatest available AP capacity. Dynamic load balancing works best when the controllers are clustered in a centralized design.
This dynamic load balancing can also be the basis for a dynamic controller redundancy scheme. Recall that when an AP misses a heartbeat acknowledgment from a WLC, the AP resends the heartbeat messages up to five times at 1-second intervals. If no acknowledgment is received after five retries, the AP declares the controller unreachable, releases and renews its IP address, and looks for a new controller. The advantages of dynamic controller redundancy are that it is easy to deploy and configure, and that APs dynamically load-balance across WLCs. Disadvantages include the following:
-
More intercontroller roaming
-
More operational challenges because of the unpredictability of traffic patterns
-
Longer failover times (than with deterministic redundancy)
With dynamic load balancing, the APs can join controllers in no particular order or sequence, which might be acceptable if there are not many roaming clients. However, if many clients are roaming, many intercontroller roaming events can have a potential impact on aggregate network performance.
Traffic patterns from wireless clients are unpredictable, making it difficult to implement stateful security mechanisms in the infrastructure and take advantage of some other security features in Cisco switches. For example, if the APs are enabled sequentially with dynamic redundancy, the network can develop a “salt and pepper” AP design, where adjacent APs are joined to different controllers, as shown in Figure 9-26. Every odd-numbered AP is joined to WLC1, and every even-numbered AP is joined to WLC2. In theory, this design provides for dynamic traffic load-balancing across WLCs and coverage redundancy in the event of a WLC failure. However, in actual practice, this type of design can result in a large number of intercontroller roaming events and therefore generally is not widely recommended or deployed.
| Note | LAG supports dynamic controller redundancy. |
Deterministic Controller Redundancy
With deterministic controller redundancy, the network administrator statically configures a primary, a secondary, and, optionally, a tertiary controller. Advantages of using deterministic controller redundancy include the following:
-
Predictability (easier operational management)
-
Higher network stability
-
More flexible and powerful redundancy design options
-
Faster failover times
-
Fallback option in the case of failover
When an AP determines, from missed heartbeat acknowledgments, that its primary controller is unreachable, it attempts to join the secondary controller. If the AP fails to join the secondary controller, it attempts to join the tertiary controller. If the primary, secondary, and tertiary controllers are not available, the AP resorts to the dynamic LWAPP algorithms to connect to the least-loaded available controller.
With this process, the network administrator can deterministically predict the results of an AP reassociation, resulting in easier operational management of the WLAN. The network can be designed for WLC infrastructure redundancy, and extra capacity on the secondary and tertiary controllers can be provisioned to be available in the event of catastrophic WLC failures.
WLCs have a configurable parameter for AP fallback. When the WLC AP fallback option is enabled, APs return to their primary controllers when the primary controller comes back online after a failover event. This feature is enabled by default, and some administrators choose to leave the AP fallback default value in place. However, when an AP falls back to its primary controller, there is a brief window of time, usually approximately 30 seconds, during which service to wireless clients is interrupted because the APs are rejoining the primary WLC. Also, if connectivity to the primary WLC has become unstable for some reason, the AP might “flap” back and forth between a primary and the backup WLCs. Many WLAN administrators prefer to disable the AP fallback option and move the APs back to the primary WLC in a controlled manner, during a scheduled service window.
A disadvantage of deterministic controller redundancy is that it requires more upfront planning and configuration. The configuration of primary, secondary, and tertiary WLCs can be performed somewhat laboriously on each AP, or more easily using templates with the Cisco WCS.
Figure 9-27 shows three APs configured with primary, secondary, and tertiary WLCs. If WLC-B fails, its attached AP connects to WLC-C. If WLC-A fails while WLC-B is down, its APs connect to WLC-C.
Deterministic Redundancy Options
There are three options for the design of deterministic controller redundancy, as described in the following sections.
N + 1 Redundancy Design
This scenario is illustrated in Figure 9-28. Each AP is configured with a WLC as primary; all APs are configured with the one redundant controller as secondary.
One issue with this design is that the redundant controller could become oversubscribed in the unlikely event of multiple primary WLC failures. When a WLC has reached the maximum number of joined APs, it does not accept any more LWAPP Join requests. Consequently, if the backup WLC becomes oversubscribed, some APs might not be able to join with a WLC. Therefore, when designing an N + 1 redundant solution, you should assess the risks of multiple WLC failures and the consequences of an oversubscribed backup WLC.
N + N Redundancy Design
For example, Figure 9-29 has two controllers. Some of the APs are configured with controller A as primary and controller B as secondary; the other APs are configured to use controller B as primary and controller A as secondary.
In this design, the AP capacity across both controllers should be balanced. APs should also be logically grouped on controllers to minimize intercontroller roaming events. For example, in a four-floor building with two redundant controllers, the APs on floors 1 and 2 could be configured to use one controller as primary and the APs on floors 3 and 4 could be configured to use the other controller as primary. Enough excess capacity must be provisioned on each controller to handle a failover situation.
N + N +1 Redundancy Design
For example, in Figure 9-30 some of the APs are configured with controller A as primary and controller B as secondary; the other APs are configured with controller B as primary and controller A as secondary. All the APs are configured to use the same backup controller as tertiary. Typically, the primary and secondary controllers are placed at the network distribution level, and the single tertiary controller is placed in a NOC or data center. Multiple distribution blocks can be configured with the same tertiary controller.
When selecting a redundancy option, consider the risks of WLC failure and the service level agreement (SLA) required to be maintained by the WLAN. The higher the SLA, the more robust redundancy scheme your designed solution should provide.
Design Considerations for Guest Services in Wireless Networks
Providing wireless guest services with traditional autonomous APs poses significant challenges. To maintain internal corporate network security, guest traffic must be restricted to the appropriate subnet and VLAN; these guest VLANs must extend throughout the infrastructure to reach every location where guest access is required. Reconfiguring of the access switches that serve conference rooms, offices, and cubicles to selectively adjust VLANs for guest access can involve many network staff hours.
The Cisco UWN supports simplified configuration and deployment of guest access for customers, vendors, and partners through deployment of lightweight APs. In a basic scenario, WLCs centralize the configuration and management of the APs and segregate internal user traffic from guest user traffic with VLANs. With this architecture, VLAN and subnet configuration occurs only at the wired network where the controller is connected, as shown in Figure 9-31. The result is a dramatic reduction in time to configure the network.
If the guest network SSID is the only one broadcast, unauthorized users might make fewer attempts to access the internal private WLANs. To increase security, the Cisco UWN ensures that all clients gain access within the number of attempts specified by the administrator. Should a client fail to gain access within that limit, it is automatically excluded (blocked from access) until the administrator-set timer expires.
In this scenario, however, traffic isolation is provided by VLANs, only up to the switch to which the controller is connected. For many enterprises, guest traffic isolation via a VLAN may not provide a sufficient level of security.
In such cases, the Cisco UWN can provide path isolation using a Layer 2 (EtherIP) tunnel to direct all guest traffic to a WLC dedicated to guest services (called the anchor WLC) in a demilitarized zone (DMZ), a secured network zone between the private (inside) network and a public (outside) network. EtherIP tunnels logically segment and transport the guest traffic between Edge and Anchor WLCs, whereas other traffic (for example, employee traffic) is still locally bridged on the corresponding VLAN. This scenario is illustrated in Figure 9-32.
The guest VLANs do not need to be defined on the switches connected to the edge controllers; the original Ethernet frame from the guest client is maintained across the LWAPP and EtherIP tunnels to the anchor WLC. This WLC applies the appropriate policies before Internet access is granted. Corporate wireless use policies are managed by the WLCs internal to the enterprise.
| Note | EtherIP tunnels are supported across all Cisco WLCs. The 2006 WLC, however, cannot anchor the EtherIP connections. |
Path isolation allows the guest traffic to be separated and differentiated from the corporate internal traffic and to be securely transported across the internal network infrastructure.
Design Considerations for Outdoor Wireless Networks
Traditional outdoor wireless deployment options include point-to-point or point-to-multipoint bridging between buildings. Outdoor wireless mesh is a relatively new option in which the APs are connected in a mesh with many redundant connections between nodes. Figure 9-33 illustrates these options.
Mesh APs discover each other automatically and select the best path through the mesh for maximizing system capacity and minimizing latency. APs continuously communicate with other nodes in the mesh, evaluating the potential of each link to improve performance. If a link degrades, the AP determines whether a better path exists and routes traffic through a more optimal node. A mesh network eliminates the need to wire every AP in the network, making it easier and more cost-effective to extend the network’s reach. It is easy to connect an existing indoor wired or wireless network with the outdoor mesh network so that users can roam from one area to another without reconnecting. Perhaps more importantly, administrators can set up one access policy that works across all environments, increasing security and making the systemwide network infrastructure more manageable.
Wireless Mesh Components
A mesh network consists of two or more indoor or outdoor Cisco LWAPP-enabled mesh APs, communicating with each other over one or more wireless hops (using 802.11a) to join multiple LANs or to extend IEEE 802.11b/g wireless coverage. Cisco LWAPP-enabled mesh APs are configured, monitored, and operated from and through any Cisco WLC deployed in the network. The wireless mesh solution consists of several components, as illustrated in Figure 9-34:
-
Cisco WCS: WCS includes easy-to-use and intuitive software for wireless mesh management and enables networkwide policy configuration and device management. WCS provides the overall view of the wireless mesh and supports Simple Network Management Protocol and Syslog.
-
Cisco WLC: The WLC connects the wireless mesh APs to the wired network.
-
Rooftop APs (RAP): A RAP is connected to the wired network and serves as the root or gateway to the wired network. As its name implies, a RAP is typically located on a rooftop or tower. A RAP uses wireless 802.11a to communicate with up to 32 neighboring poletop mesh APs (MAP).
-
Poletop MAPs: The poletop MAPs are the remote APs that provide 802.11b/g wireless client access. MAPs are typically located on top of a pole such as a lamppost and connect through a separate 802.11a wireless interface to a RAP as the gateway to the wired network. MAPs require AC or DC power and might support PoE. MAPs typically also have an Ethernet port for connecting peripheral devices, such as a camera.
MAP-to-RAP Connectivity
The outdoor component of the Cisco wireless mesh networking solution is based on the Cisco Aironet 1500 Series, an outdoor Wi-Fi (802.11/a/b/g) mesh AP using Cisco’s patent-pending Adaptive Wireless Path Protocol. The 1500 series uses a two-radio design where the radios have dedicated roles. One radio provides local access for client devices, and the second radio provides the wireless backhaul for network connectivity. The network’s overall throughput is controlled by topology and path considerations in the mesh network.
During bootup, an AP tries to become a RAP if it is connected to the wired network. If a RAP loses its wired network connection, it attempts to become a MAP and searches for an appropriate RAP. By default, the backhaul interface (to the MAPs) on the RAP uses the 802.11a 5 GHz radio and is set to a speed of 18 Mbps. A RAP is the parent node to any bridging or mesh network and connects a bridge or mesh network to the wired network. By default, only one RAP can exist for any bridged or mesh network. A mesh algorithm enables APs to find the least-cost path back to the controller or RAP to minimize latency and maximize usable bandwidth. The algorithm takes into account total hop count and throughput at each hop to determine the best path back to a RAP.
MAPs are typically installed in places where a wired connection cannot be provided, but power can be made available. The MAP provides IEEE 802.11b/g client access via the 2.4 GHz radio and connects wirelessly to the RAP via the 802.11a backhaul radio. MAPs can connect back to a RAP using one or multiple hops, thereby providing a broader coverage area than a typical wireless bridge device. Figure 9-35 illustrates a sample deployment.
Mesh Design Recommendations
Figure 9-36 illustrates the throughput in a mesh network. Notice that each hop reduces the throughput by half because the data has to be re-sent across the same half-duplex network. The MAP connection back to the RAP can support eight hops on a 1500 Series AP, although Cisco recommends four or fewer hops for best performance because each hop can add 1 to 3 ms of latency.
RAPs can connect up to 32 MAPs. Cisco recommends connecting only 20 to 25 MAPs to a RAP; a maximum of 20 MAPs provides the best performance.
Design Considerations for Campus Wireless Networks
This section reviews design considerations for enterprise campus wireless networks.
Common Wireless Design Questions
To develop an enterprise campus wireless network design, the following questions need to be answered:
-
How many APs are needed? Sufficient APs to provide RF coverage, with the required features to support the wireless clients, are needed. Different APs have different features, including internal or external antenna, single or dual radios, and number of devices supported. Optimally, deploy more APs than indicated by the client density requirements to allow for overdeployment and to ensure seamless coverage and future higher capacity. For example, a few extra APs can be used to cover unforeseen coverage holes or as spares. The Cisco UWN compensates for RF overlap.
-
Where should the APs be located? The APs should be located where WLAN clients will be located. APs should be placed in central locations that can cover several walled offices or cubicle areas. APs typically are not as effective deployed in a wiring closet as when placed close to users. An AP deployed in a meeting room can support peak wireless requirements during a meeting better than an AP in an adjacent hallway that might also be used for day-to-day office requirements.
-
How will the APs receive power? PoE is typically used to minimize power cabling requirements for APs, especially those mounted on ceilings. Traditional power sources can also be used.
-
How many WLCs will be needed? The number of APs that a controller can support varies depending on the selected controller. Enough controllers to support the required number of APs and provide redundancy as dictated by the location’s reliability requirements should be provisioned. Higher redundancy is needed for mission-critical applications and voice over wireless.
-
Where should the WLCs be located? WLCs should be located in a secure area such as a wiring closet or data center. Placing WLCs in multiple wiring closets improves reliability in the event of a power loss to one wiring closet.
Controller Placement Design
WLCs in the enterprise campus can be placed in the distribution layer or centralized in the core layer. As much as possible, controllers should be placed to minimize intercontroller roaming and traffic flow latency over the wireless media. LWAPP tunneling separates the physical controller placement from the subnets so that the WLCs can be positioned where they are connected, secured, and powered, and where traffic flows work well. As noted earlier, controllers should be deployed using deterministic redundancy to avoid unnecessary intercontroller roaming that results from dynamic redundancy.
Although distributed controller deployment might work well with existing networks or focused wireless coverage areas, the general recommendation from Cisco is to use a centralized design for controller placement to minimize operational complexity and support. However, the decision should be based on the design’s capability to support the current network and policies as well as future growth plans.
Figure 9-37 illustrates a distributed WLC design with the APs in the access layer and WLCs in the distribution layer. The distributed WLC design can easily support coverage areas that are isolated by building and where mobility between buildings is not implemented.
Figure 9-38 illustrates a centralized WLC design with the APs in the access layer and WLCs in a service block in the core layer. The centralized WLC design provides simplified management with fewer endpoints and fewer locations to manage for issues such as high availability, routing, and power needs. A centralized WLC design also supports the most efficient mobility.
Campus Controller Options
Depending on the size of the campus and whether integration with Layer 3 infrastructure devices is desired, one of two categories of WLCs is typically deployed in the enterprise campus.
Appliance controllers from the Cisco 4400 Series can be used to support from 6 to 100 APs. These controllers can support from 40 to 2000 wireless devices, depending on the mix of data and voice clients. Layer 3 routing would need to be supported on another platform, not on the 4400 WLC. Recall that WLC appliances connect to the enterprise network over an 802.1Q trunk.
Controllers integrated in Layer 3 devices such as the Cisco Catalyst 3750G Switch with integrated WLC (for small to medium deployments or an individual building) or the Cisco Catalyst WiSM (for medium to large deployments) support a centralized design and control 25 to 300 APs. In this case, Layer 3 routing can be supported on the same platform. Recall that the integrated controllers support Layer 2 connections internally and can use Layer 2 or Layer 3 connections to the wired enterprise network.
Design Considerations for Branch Office Wireless Networks
This section reviews design considerations for branch wireless network design, including REAP and H-REAP.
Branch Office Considerations
The following are several key design considerations for branch office wireless networks:
-
How many APs are needed, and what are their requirements? Recall that, generally, an AP can support 7 to 8 wireless phones or 20 or more data-only devices. Ports must be available on the local switch to connect the APs to the wired network. Power to the APs, either through PoE or traditional power cabling, is also required.
-
What is the cost of the WLC? It might not be economically feasible for small sites to implement local controllers.
-
What are the bandwidth requirements? Sufficient bandwidth to support the required wireless traffic is needed. If a centralized controller supports branch office APs, the RTT latency between the APs and the WLC should not exceed 200 ms, and only REAPs or H-REAPs should be used, as discussed in the upcoming “REAP” and “Hybrid REAP” sections.
Local MAC
Recall that in a typical LWAPP deployment, the AP MAC functions are split between the lightweight AP and the WLC. LWAPP also supports a local MAC feature in which the full 802.11 functionality is on the lightweight AP; this solution might be appropriate for branch wireless deployments.
With local MAC, the AP provides the MAC management support for association requests and actions. Local MAC allows for the decoupling of the data plane from the control path by terminating all client traffic at the AP’s wired port. This allows direct wireless access to resources local to the AP and provides link resiliency because wireless service persists if the LWAPP control path (between the AP and the controller) goes down. This functionality is particularly useful in small remote and branch offices across WAN links where only few APs are needed and the cost of a local controller is not justified. Table 9-7 summarizes the lightweight AP and WLC MAC functions with the local MAC feature; compare this to Table 9-3.
Table 9-7: Local MAC Lightweight AP and WLC MAC Functions
Open table as spreadsheet | Lightweight AP MAC Functions | WLC MAC Functions |
| 802.11: Beacons, probe response | 802.11 Proxy association requests and actions |
| 802.11 Control: Packet acknowledgment and transmission | 802.11e Resource reservation 802.11i Authentication and key management |
| 802.11e: Frame queuing and packet prioritization | |
| 802.11i: MAC layer data encryption/decryption | |
| 802.11 MAC management: Association requests and actions | |
REAP
Connecting lightweight APs to a WLC over a WAN is not recommended unless a REAP or H-REAP is used.
The Cisco 1030 series APs are Cisco first-generation REAP devices (versus the second-generation H-REAP devices described in the next section). REAP capabilities allow a lightweight AP to be deployed remotely from the WLC, to extend wireless management and control support to branch office and small retail locations.
The 1030 series AP is a superset of the 1010 and 1020 APs that can operate as a campus access point or as a REAP device and that delivers the same LAN security, performance, and RF management capabilities as the campus 1010 and 1020 APs. The 1030 AP can operate via most standard WAN technologies, including T1, Frame Relay, and so forth, enabling IT managers to centrally control SSIDs, security parameters, and software loads for unified, enterprise-wide WLAN services.
With a REAP, all control traffic is LWAPP-encapsulated and sent to a Cisco WLC, as it is with other APs. With a REAP, however, client data traffic is not LWAPP-encapsulated, but is locally bridged onto the WAN.
All management control and RF management are available when the WAN link is up and connectivity is available to a Cisco WLC. The REAP continues to provide connectivity to local wireless clients and local network resources if the WAN goes down.
First-generation REAP devices do have a few limitations (which are addressed by H-REAP devices):
-
The Cisco 1030 series AP does not support 802.1Q trunking. All WLANs terminate on a single local VLAN/subnet.
-
With connectivity to the controller, the Cisco 1030 series APs support multiple (up to 16) WLANs. During a WAN outage, the AP goes into standalone mode, and all WLANs except the first WLAN configured on the AP, WLAN 1, are disabled and unavailable. Therefore, multiple WLANs are not recommended.
-
With REAP devices, only Layer 2 security using WEP or WPA-PSK is supported in standalone mode. Layer 3 security polices are not supported on REAP devices.
-
REAPs and clients require a routable IP address, but the embedded Cisco WLC DHCP server is not supported; a local DHCP server must provide IP addresses locally. Network address translation (NAT) is also not supported.
Hybrid REAP
An H-REAP is another option for branch office and remote office deployments. An H-REAP is an enhancement to a REAP that enables customers to configure and control two or three APs in a branch or remote office from the corporate office through a WAN link without deploying a controller in each office. The H-REAPs can switch client data traffic locally and perform client authentication locally when their connection to the controller is lost. When they are connected to the controller, they can also send traffic back to the controller.
An H-REAP supports simultaneous tunneling and local switching. Local switching bridges traffic onto local VLANs, whereas central switching tunnels traffic to a WLC. An H-REAP provides more security options than a REAP for the remote site:
-
Standalone mode: When the H-REAP cannot reach the WLC, it goes into standalone mode and performs its own client authentication; WPA-PSK and WPA2-PSK are supported in standalone mode.
-
Connected mode: When the H-REAP can reach the controller, it is in a connected state and gets help from the controller to complete client authentication. In connected mode, an H-REAP supports many client authentication protocols, including WPA-PSK, WPA2-PSK, VPNs, Layer 2 Tunneling Protocol, 802.1X EAP, and web authentication.
An H-REAP is more delay-sensitive than a REAP; round-trip latency must not exceed 200 ms between the AP and the controller, and LWAPP control packets must be prioritized over all other traffic. An H-REAP supports a one-to-one NAT configuration. It also supports port address translation for all features except true multicast. Multicast is supported across NAT boundaries when configured by using the Unicast option.
An H-REAP can be deployed with a static IP address or it can obtain its IP address via DHCP. The DHCP server must be available locally and must be able to provide the IP address for the H-REAP at bootup.
H-REAP is supported on all the LWAPP WLCs, but only on the 1130AG and 1240AG APs. Figure 9-39 illustrates a typical H-REAP deployment. H-REAP APs should be connected using trunk ports to support switched VLANs.
| Note | Although H-REAP functionality is limited to three units per site in Cisco UWN code version 4.0, an increase to six units might be available in a maintenance release. Refer to http://www.cisco.com/ documentation for the latest features and limitations of H-REAP. |
Branch Office WLAN Controller Options
Depending on the size of the branch and whether integration with Layer 3 infrastructure devices is desired, one of two categories of WLCs is typically deployed in a branch office.
Appliance controllers such as the Cisco 2006 and the Cisco 4400 Series are often used to support six to 25 APs (although versions of the 4400 that support more APs are available). For example, the 4402-12 and 4402-25 could be used in a branch office to support 12 or 25 APs, respectively. These appliance controllers can support from 40 to 500 wireless devices, depending on the mix of data and voice clients. Depending on redundancy requirements, one or two routers would be needed for WAN connectivity to the enterprise network.
Controllers integrated in Layer 3 devices, such as the WLCM for ISRs or the integrated WLC for the Cisco Catalyst 3750G switch, also support six to 25 APs. WAN redundancy can be supported with another router or a pair of these devices.
0 comments
Post a Comment