H-REAP Versus REAP (Cisco Wireless LAN Controllers)

With the advent of centralized wireless networking, you can take advantage of the benefits of a single point of administration for hundreds of APs. Using Wireless Control System (WCS) and WCS Navigator, you can centrally administer tens of thousands of APs from a single device. Wireless controllers, WCS, and Navigator, however, are expensive products. Should you need to implement a wireless solution at a remote office connected to your central network via a WAN, it can be cost prohibitive to install even a 2100 series controller to service only one or two APs.

Also, with Lightweight Access Point Protocol/Control and Provisioning of Wireless Access Points (LWAPP/CAPWAP), all the client traffic, even to the local network, would be tunneled back to the controller across the WAN, put back out on the network, only to go back across the WAN to reach its destination. This traffic flow pattern is inefficient and would eat up limited WAN bandwidth. Should you decide to install standalone access points (AP) in this situation, you lose the ease of central administration. The solution to this problem is to install a lightweight AP in Hybrid Remote Edge Access Point (H-REAP) mode at the remote location.

The H-REAP feature allows central administration of the APs and, depending on the configuration, keeps local traffic local. It also provides link resiliency in the event of a WAN outage. Should the WAN link between the AP and the controller be lost, an AP in local mode stops servicing clients even though the AP and the controller are operational. An AP in H-REAP mode, however, transitions to standalone mode and can continue to service existing, and even new, clients in certain cases until the WAN link is restored. This is a valuable feature if you have unreliable WAN links or an unscheduled WAN outage; it keeps the local users happy because they can continue working.

H-REAP is actually an enhanced version of the Remote Edge Access Point (REAP) feature. With REAP, you had centralized administration of the APs and link resiliency if the WAN link failed, but two fundamental limitations existed.

The first limitation was that only a single model of AP supported REAP mode: the 1030 series. The second limitation was that when the 1030 series AP lost communication to the controller across the WAN, it had no support for multiple wireless LANs (WLAN) or VLANs because of a lack of 802.1Q tagging support. The lack of VLAN tagging support exists because the 1000 series APs were never designed to be standalone units. The idea was that all traffic would be tunneled back to the controller and the controller would be responsible for bridging to the correct subnet.

If a controller was servicing three WLANs at the remote site and the WAN link was lost with a 1030 in REAP mode, only WLAN ID 1 would still be available and all client traffic would be on the same VLAN as the AP. Cisco introduced H-REAP in code Release 4.0 to overcome these limitations.

H-REAP supports multiple WLANs on different VLANs and is supported on 1130, 1140, 1240, 1250, and AP801 APs and all the controller platforms.

Split MAC Versus Local MAC Architecture

To fully understand how an H-REAP AP functions, you need to understand the difference between the Split MAC and Local MAC architectures.

With Split MAC, the 802.11 protocol functionality is divided between the wireless termination point (the AP) and the access controller (controller). Table 13-1 outlines the division of responsibility between the AP and controller with Split MAC.

As you can see from Table 13-1, the network distribution and integration functionality resides with the controller. This means that all the client data must be tunneled between the AP and the controller. The controller is also responsible for associations, reassocia-tions, disassociations, and 802.1x/EAP and key management services. The AP, however, handles the beacons, probe responses, 802.11 encryption and decryption, and all other real-time 802.11 protocol services.

In a Local MAC architecture, however, the division of 802.11 protocol services is different. Table 13-2 outlines the Local MAC division of responsibility.

One of the first things you will notice in the Local MAC scenario is that every service except for 802.1x/EAP and key management resides with the AP. The 802.1x/EAP and key management service remain at the controller because the controller must be aware of any client mobility events between the APs. For the controller to be aware of mobility events, the AP must forward association requests to the controller.

The Local MAC mode of operation allows for the data frames to be either locally bridged (also known as Local Switching) or tunneled as 802.3 frames. The latter implies that the AP performs the 802.11 integration function. In either case, the Layer 2 wireless management frames are processed locally by the AP and then forwarded to the controller.

H-REAP APs take advantage of both Split MAC and Local MAC to provide wireless resiliency. So even though the AP may not be registered to a controller, it can service wireless clients.

Table 13-1 Split MAC Architecture_

Table 13-2 Local MAC Architecture